web-dev-qa-db-ja.com

マスターへのキープアライブ不要な移行

AmazonでCloudformationを使用して2つのEC2インスタンスを開始しています。2番目のインスタンスは最初のインスタンスの約30秒後に開始します。

構成は次のようになります。

インスタンス2

    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 100
    unicast_peer {
        172.17.16.10
    }

インスタンス1

    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    unicast_peer {
        172.17.16.11
    }

どちらも、成功する同じヘルスチェックで構成されています。

フラッピングの問題が発生しないように同じ優先度を設定しました（MASTERがダウンした場合は、BACKUPを新しいMASTERとして移行しますが、OLD MASTERが戻った場合は、そのままにします）。

この問題は最初の開始時に発生しています：

  • ファーストインスタンスが起動し、マスター状態になります
  • 2番目のインスタンスは約30秒後に開始し、最初はBACKUP STATEに入りますが、何らかの理由でその後MASTERに移行します。

両方とも同じ優先順位を持つ必要があるのに、なぜですか？

カーネルIPVSとホストフィンガープリントの計算に関するログメッセージは、keepalivedが開始された後にのみ出力されることに気付きました。そのため、キープアライブは、システムがネットワークインターフェイスでパケットを交換し、どういうわけか不要なフェイルオーバーをトリガーするシステム上の最初のソフトウェアであると思います。

また、インスタンス2は、keepalivedが開始するとすぐにバックアップ状態になります。

Nov 17 17:43:58 ip-172-17-16-11 Keepalived_vrrp[2403]: Using LinkWatch kernel netlink reflector...
Nov 17 17:43:58 ip-172-17-16-11 Keepalived_vrrp[2403]: VRRP_Instance(VI_1) Entering BACKUP STATE
Nov 17 17:43:58 ip-172-17-16-11 Keepalived_vrrp[2403]: VRRP sockpool: [ifindex(2), proto(112), unicast(1), fd(15,16)]

一方、インスタンス1は、カーネルIPVSメッセージとフィンガープリントの後でのみMASTERになります。

Nov 17 17:44:28 ip-172-17-16-10 kernel: [  157.650360] IPVS: Registered protocols (TCP, UDP, SCTP, AH, ESP)
Nov 17 17:44:28 ip-172-17-16-10 kernel: [  157.654035] IPVS: Connection hash table configured (size=4096, memory=64Kbytes)
Nov 17 17:44:28 ip-172-17-16-10 kernel: [  157.658356] IPVS: Creating netns size=2048 id=0
Nov 17 17:44:28 ip-172-17-16-10 kernel: [  157.661163] IPVS: ipvs loaded.
Nov 17 17:44:28 ip-172-17-16-10 Keepalived_healthcheckers[2391]: Opening file '/etc/keepalived/keepalived.conf'.
Nov 17 17:44:28 ip-172-17-16-10 Keepalived_healthcheckers[2391]: Configuration is using : 5174 Bytes
Nov 17 17:44:28 ip-172-17-16-10 Keepalived_healthcheckers[2391]: Using LinkWatch kernel netlink reflector...
Nov 17 17:44:28 ip-172-17-16-10 Keepalived_vrrp[2392]: VRRP_Script(chk_haproxy) succeeded
Nov 17 17:44:29 ip-172-17-16-10 ec2:
Nov 17 17:44:29 ip-172-17-16-10 ec2: #############################################################
Nov 17 17:44:29 ip-172-17-16-10 ec2: -----BEGIN SSH Host KEY FINGERPRINTS-----

Nov 17 17:44:29 ip-172-17-16-10 ec2: -----END SSH Host KEY FINGERPRINTS-----
Nov 17 17:44:29 ip-172-17-16-10 ec2: #############################################################
Nov 17 17:44:29 ip-172-17-16-10 Keepalived_vrrp[2392]: VRRP_Instance(VI_1) Transition to MASTER STATE

-構成をテストするには：

  • 両方のキープアライブを停止します
  • インスタンス1でキープアライブを開始し、MASTERに移動します。
  • インスタンス2でキープアライブを開始します。バックアップに進み、フェイルオーバーをトリガーしません。

だから、すべてが大丈夫に見えます。

amazon-web-serviceskeepalivedamazon-cloudformation
1
Bastien974

設計上、優先度が等しい場合、VRRPはプライマリアドレスが最も高いノードをMASTERとして選択します。

https://www.juniper.net/techpubs/en_US/junose11.3/topics/concept/vrrp-router-election-rules.htmlhttp：//www.ietf。 org/rfc/rfc3768.txt

If the Priority in the ADVERTISEMENT is equal to the local
            Priority and the primary IP Address of the sender is greater
            than the local primary IP Address, then:

             o Cancel Adver_Timer
             o Set Master_Down_Timer to Master_Down_Interval
             o Transition to the {Backup} state
1
Bastien974