เก็บไว้ VRRP_script ไม่ได้ล้มเหลว

ดังนั้นฉันจึงเรียกใช้แบบต่อเนื่องบนเซิร์ฟเวอร์สองเครื่องและฉันไม่สามารถทำให้มันล้มเหลวได้

ด้านล่างฉันมีการกำหนดค่าของฉันสำหรับหนึ่งในเซิร์ฟเวอร์ ข้อแตกต่างระหว่างสองอย่างนี้คือหมายเลขลำดับความสำคัญหลักคือ 110 และหลังเป็น 109

แต่เมื่อฉันหยุดกระบวนการของฉันด้วย /etc/init.d/process หยุดเก็บไว้ไม่ได้ล้มเหลว ฉันเพิ่งทำให้ VRRP_Script (chk_script) ล้มเหลวและไม่มีอะไรอื่นอีก ไม่มีความล้มเหลวหรือไม่มีอะไร

vrrp_script chk_script {
script "/usr/local/bin/failover.sh"
interval 2
weight 2
}

vrrp_instance HAInstance {
state BACKUP
interface eth0
virtual_router_id 8
priority 109
advert_int 1
nopreempt
vrrp_unicast_bind 10.10.10.8
vrrp_unicast_peer 10.10.10.9
virtual_ipaddress {
  10.10.10.10/16 dev eth0
}
notify /usr/local/bin/keepalivednotify.sh
track_script {
  chk_script weight 20
}
}

นี่คือ chk_script ของฉันด้านล่าง ปัญหาเดียวกันนี้ยังเกิดขึ้นเมื่อฉันประมวลผล killall -0 เป็นสคริปต์ของฉัน

!/bin/bash
SERVICE='process'
STATUS=$(ps ax | grep -v grep | grep $SERVICE)

if [ "$STATUS" != "" ]
then
    exit 0
else
    exit 1
fi

ไม่มีใครรู้การแก้ไขสำหรับเรื่องนี้? ขอบคุณ

ฉันมีปัญหาเดียวกันอย่างแน่นอน แต่ปัญหาของฉันไม่ได้อยู่ในไฟร์วอลล์หรือในอะแดปเตอร์อีเธอร์เน็ตของฉัน แต่ในการตั้งค่า "น้ำหนัก" ของสคริปต์ตรวจสอบ

นี่คือการกำหนดค่าของฉัน:

MASTER:

vrrp_instance haproxy {
state MASTER
interface eth0
virtual_router_id 51
priority 150
advert_int 1

สำรอง:

vrrp_instance haproxy {
state BACKUP
interface eth0
virtual_router_id 51
priority 100
advert_int 1

Check_script:

vrrp_script chk_haproxy {
   script "python /root/ha_check.py"
   interval 2     # check every 2 seconds
   weight 2
   rise 2
   fall 2

}

เหตุผลที่อาจารย์ปฏิเสธที่จะปล่อยวีไอพีก็เพราะแม้ว่าสคริปต์จะล้มเหลว แต่ต้นแบบก็ยังคงมีหมายเลขลำดับความสำคัญสูงกว่าจากเซิร์ฟเวอร์ BACKUP สิ่งนี้เกิดขึ้นเนื่องจากการตั้งค่า "น้ำหนัก" ใน check_script นั้นไม่เพียงพอที่จะครอบคลุม "GAP" ระหว่างหมายเลขลำดับความสำคัญซึ่งหมายถึงการเพิ่มหมายเลขลำดับความสำคัญของเซิร์ฟเวอร์ BACKUP ที่ใหญ่กว่าหนึ่งในเซิร์ฟเวอร์หลัก ฉันจะอธิบายเพิ่มเติม:

ตามคู่มือการเก็บรักษาไว้ตัวเลขที่เป็นบวกในการตั้งค่า "น้ำหนัก" จะเพิ่มหมายเลขนั้นไปยังลำดับความสำคัญหากการตรวจสอบสำเร็จ
ตัวเลขติดลบจะลบจำนวนนั้นออกจากหมายเลขลำดับความสำคัญหากการตรวจสอบล้มเหลว

ดังนั้นตามการกำหนดค่าของฉัน:

ลำดับความสำคัญของเซิร์ฟเวอร์ความล้มเหลวก่อนหน้าของสคริปต์:
MASTER: 152
BACKUP: 100
Failover_IP: MASTER

ip failover "คว้า" อย่างถูกต้องโดยเซิร์ฟเวอร์หลักเนื่องจาก Master มีลำดับความสำคัญสูงกว่าเมื่อเทียบกับเซิร์ฟเวอร์สำรอง (152> 100)

ลำดับความสำคัญของเซิร์ฟเวอร์หลังจากความล้มเหลวของสคริปต์:
เซิร์ฟเวอร์ MASTER: 148
BACKUP เซิร์ฟเวอร์: 102
Failover_IP: STILL ON MASTER

ip failover ยังคงอยู่บนเซิร์ฟเวอร์หลักเนื่องจาก Master มีลำดับความสำคัญสูงกว่าอีกครั้งเมื่อเทียบกับ BACKUP (148> 102) เซิร์ฟเวอร์ MASTER ปฏิเสธที่จะปล่อย IP และถูกต้องเนื่องจากความสำคัญของเขาสูงกว่าเซิร์ฟเวอร์อื่น

ทางออกสำหรับสถานการณ์ของฉันคือ:

โซลูชัน -1: เปลี่ยนหมายเลขลำดับความสำคัญของเซิร์ฟเวอร์ทั้งสองเพื่อให้มี "GAP" ไม่มาก
ตัวอย่างเช่น:
ลำดับความสำคัญหลัก: 150
ลำดับความสำคัญสำรอง: 149
น้ำหนักที่ตรวจสอบ: ตามที่เป็น (2)

ด้วยการกำหนดค่าข้างต้นเมื่อสคริปต์ประสบความสำเร็จ (หมายถึงทุกอย่างก็โอเค) ลำดับความสำคัญจะเป็น:
Master: 152
Backup: 149
IP_Location: On Master (152> 149)

เมื่อสคริปต์ล้มเหลว:
Master: 150
Backup: 151
IP_Location: On Backup (151> 150)

โซลูชัน - 2: เปลี่ยนหมายเลขน้ำหนักของสคริปต์จาก 2 เป็น -60

ฉันมีปัญหาเดียวกัน - เซิร์ฟเวอร์ CentOS 7.1 สองเครื่องที่มี track_script และความล้มเหลว vrrp_script บน MASTER จะส่งผลให้ข้อความบันทึกโดดเดี่ยว "VRRP_Script (chk_script) ล้มเหลว" ไม่ใช่ในการเข้าแทนที่ อย่างไรก็ตามในเซิร์ฟเวอร์ BACKUP ฉันได้รับข้อความจำนวนมากที่พยายามติดตาม IP เสมือนจริงตราบเท่าที่ฉันมี track_script บนเซิร์ฟเวอร์ MASTER ล้มเหลว

วิธีแก้ไขในกรณีของฉัน: ไฟร์วอลล์ (iptables) บนเซิร์ฟเวอร์ MASTER ไม่ได้รับการกำหนดค่าอย่างถูกต้องเพื่ออนุญาตให้ใช้แพ็คเก็ต VRRP / แพ็คเก็ตหลายผู้รับในขณะเดียวกันก็ทำการกำหนดค่าไฟร์วอลล์บนเซิร์ฟเวอร์อื่นใน BACKUP อย่างถูกต้อง

ฉันได้ป้อนกฎ iptables เดียวกันลงในเซิร์ฟเวอร์ทั้งสองดังนี้:

iptables -A INPUT -i eth0 -d 224.0.0.0/8 -j ACCEPT
iptables -A INPUT -p vrrp -i eth0 -j ACCEPT

สิ่งนี้ใช้ได้กับเซิร์ฟเวอร์ตัวใดตัวหนึ่ง (เซิร์ฟเวอร์ BACKUP VRRP) แต่ไม่ใช่ MASTER เพราะฉันลืมไปว่าอินเตอร์เฟสไม่ได้ชื่อว่า 'eth0' บนเซิร์ฟเวอร์ MASTER ดังนั้นกฎทั้งสองจึงไม่มีผลเลย

สิ่งนี้อธิบายพฤติกรรมที่ฉันสังเกตเห็น:

หาก keepalived ไม่สามารถมองเห็นลำโพง VRRP อื่นสำหรับ virtual_router_id ตัวใดตัวหนึ่งมันก็ยังเชื่อว่าตัวเองเป็นลำโพงที่มีลำดับความสำคัญสูงสุด (เช่น MASTER ที่ถูกต้อง) แม้หลังจากการแก้ไขน้ำหนักเชิงลบเนื่องจากไม่เคยได้รับข้อความ VRRP ที่มีลำดับความสำคัญสูงกว่า เนื่องจากโฆษณาของลำโพงอื่นถูกบล็อกโดยไฟร์วอลล์และไม่สามารถเข้าถึงกระบวนการที่ทำให้เป็นจริงเพื่อให้ทราบได้) นั่นเป็นเหตุผลที่คุณไม่เห็นว่ามันปล่อยวีไอพี

อย่างไรก็ตามเซิร์ฟเวอร์ BACKUP สามารถเห็นโฆษณาของ MASTER (ตอนนี้ล้มเหลว) พบว่าลำดับความสำคัญในแพ็กเก็ตเหล่านั้นลดลงเป็นค่าที่น้อยกว่าของตัวเองและดำเนินการประกาศ MASTER และส่ง ARP ฟรีเพื่อเรียกร้องวีไอพี ดังนั้นเราจึงลงเอยในสถานการณ์ที่ทั้งสองเซิร์ฟเวอร์คิดว่าพวกเขาจะต้องให้บริการวีไอพีในฐานะมาสเตอร์

สรุป: - เสมอตรวจสอบการตั้งค่าไฟร์วอลล์ในลำโพง VRRP ทั้งหมดถ้าคุณพบพฤติกรรมแปลก (failover ไม่มีหลายโท) การบันทึกแบบต่อเนื่องนั้นไม่ค่อยมีประโยชน์เท่าที่ควร (ข้อความง่ายๆ "วีไอพียังไม่ออกเพราะฉันยังคงเป็นพรีโนที่สูงที่สุด" หลังจากบรรทัด "VRRP_Script (chk_script) ล้มเหลว" จะช่วยแก้ปัญหาได้อย่างมาก

• track_script ไม่ใช่สวิตช์เปิด / ปิด ("ถ้าสคริปต์ตกลง: มีสิทธิ์ได้รับการเลือกตั้งระดับ VIP ถ้าไม่ตกลง: ไม่มีสิทธิ์เข้าร่วมการเลือกตั้งระดับวีไอพี") - มันจะเพิ่ม / ลดโอกาสในการชนะการเลือกตั้งเท่านั้น เคยสังเกตุตัวเองว่าเป็นผู้พูด VRRP เพียงคนเดียวและไม่เคยได้รับข้อความใด ๆ จากผู้พูดคนอื่นเลยมีการเลือกตั้งไม่มากนัก - คุณจะชนะเสมอ

ฉันเพียงแค่ชนกับสถานการณ์เดียวกับคุณและได้เรียนรู้เกี่ยวกับการรักษาไว้ ให้คิดว่าเกิดอะไรขึ้นในแต่ละเซิร์ฟเวอร์ สมมติว่าคุณต้องการใช้สถาปัตยกรรมความล้มเหลวด้วยตนเอง

บนโหนดสำรองข้อมูลลำดับที่ 1

ทุกครั้งที่ track_script ล้มเหลวจำนวนครั้งการตกจะส่งโฆษณาไปยังโหนดสำรองข้อมูลลำดับที่ 2 จุดนี่คือลำดับความสำคัญที่กำหนดไว้ในโฆษณา ในกรณีของคุณ

129 (109 + 20)

ถูกส่งไปยังเซิร์ฟเวอร์สำรองที่สอง

บนเซิร์ฟเวอร์สำรองที่สอง

ถัดไปอยู่บนโหนดสำรองข้อมูลลำดับที่ 2

ตามRFC ,

If the Priority in the ADVERTISEMENT is Zero, then:

  o  Set the Master_Down_Timer to Skew_Time
else:

  If Preempt_Mode is False, or If the Priority in the
  ADVERTISEMENT is greater than or equal to the local
  Priority, then:

    o Reset the Master_Down_Timer to Master_Down_Interval
  else:

    o Discard the ADVERTISEMENT
  endif
endif

เนื่องจากคุณเปิดใช้งานnopreemptและรับ vrrp ที่มีลำดับความสำคัญสูงกว่าโหนดสำรองที่สองจะไม่เข้าสู่สถานะการเปลี่ยนแปลง

สารละลาย

ดังนั้นหากคุณต้องการให้การเปลี่ยนสถานะเกิดขึ้นบนโหนดที่ 2 คุณสามารถทำได้

1. ตั้งค่าน้ำหนักเป็น0บนโหนดสำรองข้อมูลลำดับที่ 1 สิ่งนี้จะส่งโฆษณาลำดับความสำคัญ0ไปยังโหนดสำรองข้อมูลลำดับที่ 2 หมออธิบายเพิ่มเติมเกี่ยวกับน้ำหนัก 0

2. ปิดnopreemptบนโหนด BACKUP ลำดับที่ 2

3. ตั้งค่าน้ำหนักอย่างน้อย-2บนโหนดสำรองข้อมูลลำดับที่ 1