VRRP_script giữ lại không thất bại


10

Vì vậy, tôi đang chạy liên tục trên hai máy chủ và tôi không thể chuyển nó sang máy chủ kia.

Dưới đây tôi có cấu hình của tôi cho một trong các máy chủ. Sự khác biệt duy nhất giữa hai là số chủ ưu tiên là 110 và trở lại là 109.

Nhưng khi tôi dừng quá trình của mình với /etc/init.d/ process thì việc giữ lại không bị thất bại. Tôi chỉ nhận được VRRP_Script (chk_script) không thành công và không có gì khác. Không có failovers hoặc không có gì.

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
}
}

Đây là chk_script của tôi dưới đây. Vấn đề tương tự cũng xảy ra khi tôi thực hiện quá trình killall -0 như kịch bản của mình.

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

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

Có ai biết sửa cái này không? Cảm ơn.


Ví dụ sao lưu của bạn có nhận thấy sự thay đổi ưu tiên hoặc ghi nhật ký gì không? Nhật ký từ cả hai sẽ hữu ích.
Jim G.

Không nó không. Lần duy nhất nó nhận thấy một sự thay đổi là khi chủ đi. Chẳng hạn như khi tôi ngừng giữ. Dừng quá trình tôi đang theo dõi chỉ hiển thị VRRP_Script (chk_script) không thành công trên bản gốc. Không có gì trên nô lệ.
Nvasion

Câu trả lời:


12

Tôi đã có chính xác vấn đề tương tự tuy nhiên vấn đề của tôi không nằm ở tường lửa cũng như trong bộ điều hợp Ethernet mà là ở cài đặt "trọng lượng" của tập lệnh kiểm tra.

Đây là cấu hình của tôi:

BẬC THẦY:

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

SAO LƯU:

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

Kiểm tra

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

}

Lý do chủ nhân từ chối phát hành VIP là vì mặc dù thực tế kịch bản đã thất bại, chủ vẫn có số ưu tiên cao hơn từ máy chủ BACKUP. Điều này xảy ra vì cài đặt "trọng lượng" trên check_script không đủ để bao phủ "GAP" giữa số ưu tiên, nghĩa là tăng số ưu tiên của máy chủ BACKUP lớn hơn cho máy chủ MASTER. Tôi sẽ giải thích thêm:

Theo hướng dẫn sử dụng được giữ lại, một số dương trên cài đặt "trọng lượng" sẽ thêm số đó vào mức ưu tiên nếu kiểm tra thành công.
Số âm sẽ trừ số đó khỏi số ưu tiên nếu kiểm tra không thành công.

Vì vậy, theo cấu hình của tôi:

Ưu tiên máy chủ Lỗi trước của tập lệnh:
MASTER: 152
BACKUP: 100
Failover_IP: MASTER

IP failover được "lấy" chính xác bởi máy chủ chính vì Master có mức độ ưu tiên cao hơn so với máy chủ Sao lưu (152> 100)

Ưu tiên máy chủ SAU thất bại của tập lệnh:
Máy chủ MASTER: 148
Máy chủ BACKUP: 102
Failover_IP: VẪN TRÊN MASTER

IP failover vẫn còn trên máy chủ chính vì Master có mức ưu tiên cao hơn so với BACKUP (148> 102). Máy chủ MASTER đã từ chối phát hành IP và anh ta đã làm đúng vì mức độ ưu tiên của anh ta cao hơn so với máy chủ khác.

Giải pháp cho tình huống của tôi là:

Giải pháp -1: Thay đổi số ưu tiên của cả hai máy chủ để chúng không có nhiều "GAP".
Ví dụ:
Ưu tiên chính: 150
Ưu tiên sao lưu: 149
Trọng lượng Check_script: Như hiện tại (2).

Với cấu hình trên, khi tập lệnh thành công (có nghĩa là tất cả đều ổn), các ưu tiên sẽ là:
Master: 152
Sao lưu: 149
IP_Location: On Master (152> 149)

Khi tập lệnh thất bại:
Master: 150
Sao lưu: 151
IP_Location: Khi sao lưu (151> 150)

Giải pháp - 2: Thay đổi số trọng số của tập lệnh từ 2, thành -60


Có vẻ như không chỉ định trọng lượng ở tất cả có nghĩa là track_script bị lỗi sẽ trực tiếp kích hoạt trạng thái lỗi
Oscar

@Nvasion: Vui lòng chấp nhận câu trả lời này vì tôi cũng đã giải quyết được vấn đề của mình.
Ankur Soni

4

Tôi đã gặp vấn đề tương tự - hai máy chủ CentOS 7.1 có track_script và việc không sử dụng vrrp_script trên MASTER sẽ chỉ dẫn đến thông báo nhật ký đơn độc "VRRP_Script (chk_script) không thành công", không chuyển đổi dự phòng. Tuy nhiên, trên máy chủ BACKUP, tôi nhận được rất nhiều thông báo về việc cố gắng chiếm lấy IP ảo miễn là tôi đã bị track_script trên máy chủ MASTER.

Giải pháp trong trường hợp của tôi: Tường lửa (iptables) trên máy chủ MASTER không được cấu hình đúng để cho phép các gói VRRP / gói đa tuyến, đồng thời tường lửa trên máy chủ khác, BACKUP, được cấu hình đúng.

Tôi đã nhập các quy tắc iptables giống nhau vào cả hai máy chủ như sau:

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

Điều này hoạt động trên một trong các máy chủ (máy chủ BACKUP VRRP) nhưng không phải là máy chủ MASTER vì tôi quên rằng giao diện không được đặt tên là 'eth0' trên máy chủ MASTER, do đó hai quy tắc không có hiệu lực.

Điều này giải thích hành vi tôi quan sát thấy:

Nếu được giữ lại không thể thấy bất kỳ loa VRRP nào khác cho một virtual_router_id nhất định, nó vẫn tin rằng mình là người có mức độ ưu tiên cao nhất (do đó là MASTER đúng) ngay cả sau khi sửa đổi trọng số âm vì nó không bao giờ nhận được tin nhắn VRRP có mức độ ưu tiên cao hơn chính nó ( bởi vì quảng cáo của các loa khác bị chặn bởi tường lửa và không bao giờ có thể đạt được quy trình được giữ lại để làm cho nó biết về chúng). Đó là lý do tại sao bạn không thấy nó phát hành VIP.

Tuy nhiên, máy chủ BACKUP đã có thể thấy các quảng cáo của MASTER (hiện không thành công), đã tìm thấy mức độ ưu tiên trong các gói đó giảm xuống một giá trị nhỏ hơn giá trị của chính nó và tiến hành khai báo MASTER và gửi ARP vô cớ để yêu cầu VIP. Vì vậy, chúng tôi đã kết thúc trong một tình huống mà cả hai máy chủ nghĩ rằng họ cần phục vụ VIP dưới dạng MASTER.

Kết luận: - Luôn kiểm tra cấu hình tường lửa trên tất cả các loa VRRP nếu bạn gặp phải hành vi lạ (không có chuyển đổi dự phòng, một số MASTER). Ghi nhật ký được giữ lại không hữu ích lắm vì nó có thể (một thông điệp đơn giản "VIP không được phát hành vì tôi vẫn là người cao nhất" sau khi dòng "VRRP_Script (chk_script) thất bại" sẽ giảm bớt sự cố.

  • Track_script không phải là loại công tắc bật / tắt ("nếu kịch bản OK: đủ điều kiện cho cuộc bầu cử VIP; nếu KHÔNG OK: hoàn toàn không đủ điều kiện cho cuộc bầu cử VIP") - nó chỉ làm tăng / giảm khả năng giành chiến thắng trong cuộc bầu cử và nếu chỉ được giữ nguyên tự nhận mình là người nói VRRP duy nhất và không bao giờ nhận được bất kỳ tin nhắn nào của những người nói khác, thực sự không có nhiều cuộc bầu cử - bạn luôn giành chiến thắng.

0

Tôi chỉ gặp phải trường hợp tương tự như bạn và đã nghiên cứu về việc giữ gìn. Hãy nghĩ những gì đang xảy ra trong mỗi máy chủ. Giả sử bạn muốn triển khai kiến ​​trúc failback thủ công,

Trên nút BACKUP đầu tiên

Mỗi lần track_script thất bại số lần rơi, nó sẽ gửi quảng cáo đến nút BACKUP thứ 2. Điểm ở đây là Ưu tiên được đặt bên trong quảng cáo. Trong trường hợp của bạn,

129 (109 + 20)

được gửi đến máy chủ BACKUP thứ 2.

Trên máy chủ BACKUP thứ 2

Tiếp theo là trên nút BACKUP thứ 2.

Theo 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

Kể từ đó, bạn đã nopreempt kích hoạt và nhận VRRP ưu tiên cao hơn, nút BACKUP thứ 2 sẽ không giai đoạn chuyển trạng thái.

Giải pháp

Vì vậy, nếu bạn muốn thực hiện chuyển đổi trạng thái trên nút thứ 2, bạn có thể,

  1. Đặt trọng số thành 0 trên nút BACKUP đầu tiên. Điều này sẽ gửi quảng cáo Ưu tiên 0 đến nút BACKUP thứ 2. doc mô tả thêm về trọng lượng 0.

  2. Tắt nopreem trên nút BACKUP thứ 2.

  3. Đặt trọng số thành ít nhất -2 trên nút BACKUP đầu tiên.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.