web-dev-qa-db-ja.com

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

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

以下に、サーバーの1つに対する設定があります。 2つの唯一の違いは、優先番号が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

誰かがこれに対する修正を知っていますか？ありがとう。

linuxkeepalived
11
Nvasion

私はまったく同じ問題を抱えていましたが、私の問題はファイアウォールやイーサネットアダプターではなく、チェックスクリプトの「ウェイト」設定にありました。

これは私の設定でした：

マスター：

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=の解放を拒否した理由は、スクリプトが失敗したという事実にもかかわらず、マスターがまだバックアップサーバーからの優先順位番号が高いためでした。これは、「重み」設定が原因で発生しましたcheck_scriptでは、優先順位番号の間の「ギャップ」をカバーするのに十分ではなかったため、バックアップサーバーの優先順位番号をマスターサーバーの優先順位番号よりも高くすることを意味します。

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

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

サーバーの優先順位スクリプトの以前の失敗：
マスター：152
バックアップ：100
フェイルオーバーIP：MASTER

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

スクリプトの失敗後のサーバーの優先順位：
MASTERサーバー：148
バックアップサーバー：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：On Backup（151> 150）

ソリューション-2：スクリプトのウェイト数を2から-60に変更

13
giomanda

同じ問題が発生しました-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スピーカーは自分自身よりも高い優先順位のVRRPメッセージを受信しないため、自分自身が最も高い優先順位（正当なMASTER）であると信じています他のスピーカーの広告はファイアウォールによってブロックされ、キープアライブプロセスに到達してそれらを認識させることができないためです。 VIPが解放されないのはそのためです。

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

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

  • Track_scriptはスイッチのオン/オフタイプではありません（「スクリプトOKの場合：VIP選挙の対象となります。そうでない場合：VIP選挙の対象となりません。 ）-それは単に選挙に勝つ可能性を増加/減少させるだけであり、keepalivedが自分自身をonly VRRPスピーカーとしてのみ監視し、他のスピーカーのメッセージをまったく受信しない場合、実際には選挙はあまりありません-あなたはいつも勝つ。
4
Patrick Wagner

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

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

Track_scriptが失敗するたびに、fall回、2番目のBACKUPノードに通知が送信されます。ここでのポイントは、広告内に設定されたPriorityです。あなたの場合、

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

nopreemptが有効になっていて、優先度の高いvrrpを受け取っているため、2番目のバックアップノードは状態遷移フェーズに移行しません。

解決

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

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

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

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

0
Yu Watanabe