keepalived VRRP_script가 실패하지 않음

따라서 두 서버에서 keepalived를 실행 중이며 다른 서버로 장애 조치를 수행 할 수 없습니다.

아래에는 서버 중 하나에 대한 구성이 있습니다. 둘 사이의 유일한 차이점은 우선 순위 번호 마스터는 110이고 다시는 109입니다.

그러나 /etc/init.d/process stop keepalived를 사용하여 프로세스를 중지하면 실패하지 않습니다. 나는 단지 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

누구든지 이것에 대한 해결책을 알고 있습니까? 감사.

정확히 같은 문제가 있었지만 내 문제는 방화벽이나 이더넷 어댑터가 아니라 확인 스크립트의 "무게"설정에있었습니다.

이것은 내 구성이었습니다.

석사:

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

}

마스터가 VIP 릴리스를 거부 한 이유는 스크립트가 실패 했음에도 불구하고 마스터가 여전히 BACKUP 서버에서 우선 순위 번호가 높기 때문입니다. 이는 check_script의 "weight"설정이 우선 순위 번호 사이의 "GAP"를 포함하기에 충분하지 않기 때문에 발생했습니다. 즉, BACKUP 서버의 우선 순위 번호가 MASTER Server의 서버보다 우선 순위가 높아짐을 의미합니다. 더 설명하겠습니다 :

keepalived의 매뉴얼에 따르면, "체중"설정의 양수는 확인에 성공하면 해당 숫자를 우선 순위에 추가합니다.
검사에 실패하면 음수는 우선 순위 번호에서 해당 숫자를 뺍니다.

따라서 내 구성에 따르면 :

서버 우선 순위 스크립트의 이전 오류 :
MASTER : 152
백업 : 100
Failover_IP : MASTER

마스터는 백업 서버 (152> 100)보다 우선 순위가 높기 때문에 마스터 서버가 장애 조치 IP를 올바르게 "잡습니다"

서버 우선 순위 스크립트 실패 후 :
MASTER 서버 : 148
BACKUP 서버 : 102
Failover_IP : STILL ON MASTER

마스터가 BACKUP (148> 102)보다 우선 순위가 높기 때문에 장애 조치 IP는 여전히 마스터 서버에 있습니다. MASTER 서버는 IP 공개를 거부했으며 우선 순위가 다른 서버보다 높았으므로 IP를 해제했습니다.

내 상황에 대한 해결책은 다음과 같습니다.

해결 방법 -1 : "GAP"가 많지 않도록 두 서버의 우선 순위 번호를 변경하십시오.
예 :
마스터 우선 순위 : 150
백업 우선 순위 : 149
Check_script 가중치 : 그대로 (2)

위의 구성에서 스크립트가 성공하면 (모든 것이 정상임을 의미) 우선 순위는 다음과 같습니다.
마스터 : 152
백업 : 149
IP_Location : 마스터 (152> 149)

스크립트가 실패한 경우 :
마스터 : 150
백업 : 151
IP_Location : 백업 중 (151> 150)

솔루션-2 : 스크립트의 가중치 수를 2에서 -60으로 변경

같은 문제가 발생했습니다. track_script가있는 두 CentOS 7.1 서버에서 MASTER의 vrrp_script가 실패하면 장애 조치가 아닌 "VRRP_Script (chk_script) 실패"라는 로그 메시지 만 표시됩니다. 그러나 BACKUP 서버에서 MASTER 서버의 track_script가 실패하는 한 가상 IP를 인계하려고 시도하는 많은 메시지가 유지되었습니다.

내 경우의 해결책 : MASTER 서버의 방화벽 (iptables)은 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

이것은 MASTER 서버에서 인터페이스의 이름이 'eth0'이 아니었다는 것을 잊었 기 때문에 서버 중 하나 (BACKUP VRRP 서버)에서는 작동했지만 MASTER 서버에서는 작동하지 않았으므로 두 규칙은 전혀 영향을 미치지 않았습니다.

이것은 내가 관찰 한 행동을 설명했습니다.

keepalived가 특정 virtual_router_id에 대해 다른 VRRP 스피커를 볼 수없는 경우, 자체 가중치보다 우선 순위가 높은 VRRP 메시지를 수신하지 않으므로 음수 가중치 수정 후에도 여전히 자신이 가장 높은 우선 순위 (따라서 MASTER)라고 생각합니다 ( 다른 스피커의 광고는 방화벽에 의해 차단되며이를 알리기 위해 keepalived 프로세스에 도달 할 수 없기 때문입니다). 이것이 VIP가 공개되지 않는 이유입니다.

그러나 BACKUP 서버는 (현재 실패한) MASTER의 광고를 볼 수 있었으며 해당 패킷의 우선 순위를 자체 값보다 작은 값으로 줄인 다음 MASTER를 선언하고 VIP를 주장하기 위해 무상 ARP를 전송했습니다. 그래서 두 서버 모두 VIP로 MASTER를 제공해야한다고 생각하는 상황에 처하게되었습니다.

결론 :- 이상한 동작 (장애 조치, 여러 마스터)이 발생하면 항상 모든 VRRP 스피커의 방화벽 구성을 확인하십시오. Keepalived 로깅은 그다지 도움이되지 않습니다 ( "VRRP_Script (chk_script) 실패"라인 이후의 "메시지가 여전히 가장 높기 때문에 VIP가 릴리스되지 않았습니다"라는 간단한 메시지로 인해 문제 해결이 크게 완화되었습니다.)

• track_script는 켜기 / 끄기 유형의 스위치가 아닙니다 ( "스크립트 OK : VIP 선거 자격이있는 경우, NOT OK : VIP 선거 자격이없는 경우")-선거에서 이길 가능성을 높이거나 줄입니다. 유일한 VRRP 스피커 로 자신을 관찰하고 다른 스피커의 메시지를받지 못합니다. 선거가 많지 않습니다. 항상 승리하십시오.

방금 당신과 같은 상황에 부딪 쳤고 keepalived에 대해 공부했습니다. 각 서버에서 무슨 일이 일어나고 있는지 생각해 봅시다. 수동 장애 복구 아키텍처를 구현한다고 가정하면,

첫 번째 BACKUP 노드에서

track_script이 수 실패 할 때마다 하강 시간은 2 BACKUP 노드에 광고를 전송합니다. 여기서는 광고 내부에 설정된 우선 순위 입니다. 귀하의 경우

129 (109 + 20)

두 번째 BACKUP 서버로 전송됩니다.

두 번째 BACKUP 서버에서

다음은 두 번째 BACKUP 노드에 있습니다.

에 따르면 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

을 사용하여 선점을 사용하지 않고 우선 순위가 높은 vrrp를 수신 하므로 두 번째 BACKUP 노드는 상태 전이 단계가 아닙니다.

해결책

따라서 두 번째 노드에서 상태 전환을 수행하려면 다음 중 하나를 수행하십시오.

1. 첫 번째 BACKUP 노드에서 가중치 를 0 으로 설정 하십시오. 그러면 우선 순위 0 알림이 두 번째 BACKUP 노드로 전송됩니다. doc 은 가중치 0에 대해 자세히 설명합니다.

2. nopreempt on 2nd BACKUP 노드를 끄십시오 .

3. 첫 번째 BACKUP 노드 에서 가중치를 -2 이상으로 설정 하십시오.