LinuCレベル4 システムアーキテクト 可用性の設計 問17
可用性の設計／フェイルオーバークラスタkeepalivedでVRRPを使い、2台のサーバーの間で仮想IPアドレス（VIP）を引き継ぐ冗長構成を設計する。設計判断として適切でないものはどれか。
当サイトのオリジナル問題（LinuCレベル4 システムアーキテクトの出題範囲「可用性の設計」に対応。実際の試験問題ではありません）
- AVRRPの広告はマルチキャストで送られるため、マルチキャストを通さない仮想ネットワーク上では、相手のノードをユニキャストで指定する設定を使う
- BVRRPの広告はルーターを越えて相手に届くため、異なるサブネットにある別々のデータセンターのサーバー同士でも、同じVIPをそのまま引き継いで使える
- C障害から復旧したノードがVIPを取り戻すときの再度の切替による瞬断を避けたい場合は、優先度が高くても自動ではVIPを奪い返さない設定にする
- Dkeepalivedの既定の構成では、VIPを引き継いだノードがGratuitous ARPを送り、周辺の機器が持つVIPとMACアドレスの対応を新しいノードのものへ更新させる
正解：B
解説
VRRPは同じL2セグメント上のノード間で、広告を交換してマスターを選び、VIPを引き継ぐ仕組みです。広告はマルチキャスト（224.0.0.18）でTTLを255として送られ、受信側はTTLが255でない広告を破棄するため、ルーターを越えた冗長化には使えません。また、VIPはそのセグメントのアドレスなので、別のサブネットへ持っていっても経路が届きません。拠点をまたぐ冗長化には、DNSによる広域負荷分散や経路制御（BGPなど）を使います。keepalivedはマルチキャストを使えない環境向けにunicast_peerの設定を持ち、nopreemptで自動の奪い返しを抑止できます。
選択肢ごとの解説
- A誤り（正しい記述）。マルチキャストを通さないクラウドなどの仮想ネットワークでは、keepalivedのunicast_peerで相手を指定して広告をユニキャストで送ります。
- B正しい（誤っている記述）。VRRPの広告はTTL 255で送られ、ルーターを越えたものは破棄されます。VIPも同じL2セグメント内でしか引き継げないため、サブネットをまたぐ冗長化には別の方式が必要です。
- C誤り（正しい記述）。既定では優先度の高いノードが復旧するとVIPを奪い返し、そのたびに切替が起きます。これを避けるには、keepalivedではnopreemptなどで奪い返しを抑止します。
- D誤り（正しい記述）。keepalivedは既定では実際のインターフェースのMACアドレスでVIPを持つため、引き継ぎ時にGratuitous ARPを送って、周辺の機器のARPキャッシュを更新させます。