keepalived VRRP_scriptがフェイルオーバーしない

そのため、2つのサーバーでkeepalivedを実行していますが、他のサーバーにフェイルオーバーできません。

以下に、サーバーの1つに対する設定があります。2つの唯一の違いは、優先順位番号masterが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の「重み」設定が優先度番号間の「GAP」をカバーするのに十分ではなかったために発生しました。つまり、バックアップサーバーの優先度番号をMASTERサーバーの優先順位よりも高くします。さらに説明します：

keepalivedのマニュアルによると、「重み」設定の正の数は、チェックが成功した場合、その数を優先度に追加します。
負の数は、チェックが失敗した場合に優先度の数からその数を減算します。

だから、私の設定によると：

サーバーの優先順位スクリプトの以前の失敗：
MASTER：152
BACKUP：100
Failover_IP：MASTER

マスターはバックアップサーバーと比較して優先度が高いため（152> 100）、フェイルオーバーIPはマスターサーバーによって正しく「グラブ」されます。

スクリプトの失敗後のサーバーの優先順位：
MASTERサーバー：148
BACKUPサーバー：102
Failover_IP：STILL ON MASTER

マスターはBACKUP（148> 102）と比較して再び高い優先度を持っているため、フェイルオーバーIPはまだマスターサーバー上にあります。MASTERサーバーは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を備えた2つのCentOS 7.1サーバーで、MASTERでvrrp_scriptに失敗すると、フェイルオーバーではなく、唯一のログメッセージ「VRRP_Script（chk_script）failed」が発生します。ただし、バックアップサーバーでは、MASTERサーバーのtrack_scriptが失敗する限り、仮想IPを引き継ごうとするkeepalivedのメッセージがたくさん表示されました。

私の場合の解決策：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

これはサーバーの1つ（BACKUP VRRPサーバー）では機能しましたが、MASTERサーバーではインターフェイスの名前が 'eth0'でなかったことを忘れていたため、2つのルールはまったく影響しませんでした。

これは私が観察した動作を説明しました：

keepalivedが特定のvirtual_router_idの他のVRRPスピーカーを認識できない場合でも、負の重みを変更した後でも、自身よりも高い優先度のVRRPメッセージを受信しないため、優先度が最も高い（したがって正当なマスター）と見なされます（他のスピーカーのアドバタイズはファイアウォールによってブロックされ、キープアライブプロセスに到達してそれらを認識させることができないためです。そのため、VIPが解放されません。

ただし、BACKUPサーバーは（現在失敗した）MASTERのアドバタイズを確認でき、それらのパケットの優先度が自身の値よりも低い値になっていることを発見し、自身をMASTERと宣言し、無償のARPを送信してVIPを要求しました。そのため、両方のサーバーがVIPをマスターとして提供する必要があると考えた状況になりました。

結論：- 奇妙な動作（フェイルオーバーなし、いくつかのマスター）が発生した場合は、常にすべてのVRRPスピーカーのファイアウォール構成を確認してください。Keepalivedロギングは、それほど有用ではありません（「VRRP_Script（chk_script）が失敗した」行の後の「VIPはまだ最高のプライオであるため解放されません」という単純なメッセージは、トラブルシューティングを非常に容易にします。

• track_scriptはスイッチのオン/オフタイプではありません（「スクリプトが正常な場合：VIP選挙に適格な場合。そうでない場合：VIP選挙に完全に不適格」）-選挙に勝つ可能性を増減するだけで、キープアライブのみ自分自身を唯一の VRRPスピーカーとして観察し、他のスピーカーのメッセージを受信することはありません。選挙はそれほど多くありません-あなたは常に勝ちます。

私はあなたと同じ状況にぶつかっただけで、keepalivedについて勉強しました。各サーバーで何が起こっているのか考えてみましょう。手動のフェールバックアーキテクチャを実装する場合、

1番目のバックアップノード

track_scriptは、落下回数に失敗するたびに、2番目のBACKUPノードに通知を送信します。ここでのポイントは、広告内に設定された優先度です。あなたの場合、

129（109 + 20）

2番目のバックアップサーバーに送信されます。

2番目のバックアップサーバー

次は2番目の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を受信しているため、2 番目のバックアップノードは状態遷移フェーズに移行しません。

解決

したがって、2番目のノードで状態遷移を発生させる場合は、次のいずれかを実行できます。

1. 最初のバックアップノードで重みを0に設定します。これにより、優先度0の通知が2番目のバックアップノードに送信されます。docは重み0についての詳細を説明しています。

2. 2番目のバックアップノードのnopreemptをオフにします。

3. 1番目のバックアップノードで重みを少なくとも-2に設定します。