ネットワーク内の SafeKit mirror クラスターの仮想 IP アドレスをテストする
このガイドでは、SafeKit mirror クラスタークラスター（mirror モジュール）の仮想 IP アドレス（VIP）がネットワークで正しく機能することを確認する方法について説明します。仮想 IP（VIP）はプライマリサーバーによって保持され、フェイルオーバー後に新しいプライマリサーバーに再ルーティングされます。
1. 主要原則
前提条件: mirror クラスターの両方のノードは、同じレイヤー 2 IP サブネット（LAN、またはリモートサイト間で拡張された VLAN）に存在する必要があります。
- 仮想 IP（VIP）は、プライマリサーバー（PRIM または ALONE 状態）でのみアクティブです。モジュールがノード上でプライマリとして起動すると（
where="one_side_alias"設定）、そのアドレスのネットワークカード上の物理 IP アドレスのエイリアスとして設定されます。 - したがって、プライマリサーバの MAC アドレスは、ARP テーブル（ルータ、ゲートウェイ、同じサブネット内のクライアント）内の仮想 IP（VIP）に関連付けられた MAC アドレスです。仮想 IP（VIP）へのすべてのトラフィックは、プライマリに送信されます。
- フェイルオーバー中（プライマリの停止または障害時）、仮想 IP（VIP）は以前のプライマリから削除され、新しいプライマリにエイリアスとして設定されます。その後、2 つのメカニズムによって、ネットワークは仮想 IP（VIP）を新しいプライマリの MAC アドレスに関連付けることができます。
- 仮想 IP（VIP）がネットワークカードにエイリアスとして追加されたときにオペレーティングシステムによって送信されるネットワークメッセージ。
<vip>セクションでarpreroute="on"属性が設定されている場合、SafeKit によって送信される GARP（Gratuitous ARP）。
したがって、テストする必要があるのは次のとおりです。
- 仮想 IP（VIP）はプライマリサーバーが保持し、クライアントから到達可能です。
- プライマリサーバが変更されると、仮想 IP（VIP）に関連付けられた MAC アドレスは、ネットワーク（ルータ、ゲートウェイ、仮想化）内の新しいプライマリに再ルーティングされます。
2. 前提条件：仮想 IP（VIP）の設定
mirror モジュールの
userconfig.xmlで、<vip>セクションに仮想 IP（VIP）を設定します。arpreroutearpreroute="on"属性により、フェイルオーバー後に新しいプライマリが GARP を送信します。<vip> <interface_list> <interface arpreroute="on"> <real_interface> <virtual_addr addr="<VIP>" where="one_side_alias"/> </real_interface> </interface> </interface_list> </vip>両方のノードに設定を適用します。
モジュールを開始します。1 つのノードは PRIM（Ready） で、もう 1 つのノードは SECOND（Ready） である必要があります。
3. テスト 1 – プライマリサーバーが保持する仮想 IP（VIP）
手順
- プライマリサーバーで、
ipconfig(Windows) またはip addr show(Linux) を実行します。 →期待される結果： 仮想 IP（VIP）が、物理 IP アドレスのネットワークカードのエイリアスとして表示されます。 - セカンダリサーバーで、同じコマンドを実行します。 →期待される結果： 仮想 IP（VIP）が表示されない。
- クラスター外のクライアントワークステーションから、物理 IP アドレスと仮想 IP（VIP）の両方に
ping。 →期待される結果： 3 つのpingコマンドすべてが応答する（ファイアウォールによってフィルタリングされない限り）。 - SafeKit モザイクで仮想 IP（VIP）経由のアクセスを確認します。外部クライアントのブラウザから、
http://<VIP>:9010/safekit/mosaic.htmlに接続し（SafeKit ウェブサーバーとコンソールが HTTPS に切り替えられている場合はポート 9453 を使用）、mirror モジュール名を入力してテストを実行します。 →期待される結果： モザイクのすべてのセルにプライマリサーバーの名前が単色で表示されます。仮想 IP（VIP）へのすべての TCP 接続はプライマリによって処理されます。
4. テスト 2 – 手動フェイルオーバー（プライマリの停止）
このテストでは、プライマリサーバーでモジュールを停止してフェイルオーバーをトリガーした際に、仮想 IP（VIP）がプライマリサーバーに追従することを確認します。
手順
- SafeKit コンソール（またはコマンドラインで
safekit stop -m <module>）から、プライマリ（ノード 1）上のモジュールを停止します。 →期待される結果： ノード 1 は STOP（NotReady）になり、ノード 2 は ALONE（Ready）になります。新しいプライマリのログに、メッセージVirtual IP <VIP> setが表示されます。 - 新しいプライマリで、
ipconfigまたはip addr showを実行します。 →期待される結果： 仮想 IP（VIP）は、このノードのエイリアスとして表示され、以前のプライマリノードには表示されなくなります。 - クライアントのワークステーションから、3 つの
pingコマンドを繰り返し実行し、仮想 IP（VIP）でモザイク再度実行します。 →期待される結果： すべてが応答し、モザイクのすべてのセルに新しいプライマリの名前が単色で表示されます。 - ノード 1 でモジュールを再起動します。モジュールは再同期して SECOND (Ready) になり、ノード 2 は PRIM (Ready) になります。
5. テスト 3 – arp -a を使用した MAC ルーティングの確認
フェイルオーバー前に仮想 IP（VIP）に関連付けられている MAC アドレスをメモし、フェイルオーバー後にそれが変更されていることを確認します。
このテストは、クライアントのワークステーションがクラスターと同じ IP サブネットにある場合にのみ実行可能です。
クライアントとクラスターの間にルーターがある場合、クライアントの ARP テーブルには仮想 IP (VIP) は含まれず、クラスターのネットワークに到達するために使用されるゲートウェイのアドレスが含まれます。その場合は、ネットワークチームにルーターまたはゲートウェイの ARP テーブルを確認してもらってください。
手順
- モジュールはノード 1 で PRIM（Ready）、ノード 2 で SECOND（Ready）です。
- クライアントのワークステーションで、物理 IP アドレスと仮想 IP（VIP）の両方を
ping、次にarp -aを実行します。 →期待される結果： 仮想 IP（VIP）は、プライマリの物理 IP アドレスと同じ MAC アドレスに関連付けられます。 - プライマリ（ノード 1）でモジュールを
stop。 - 仮想 IP（VIP）に再度
ping、その後、arp -a再度実行します。 →期待される結果： 仮想 IP（VIP）は、新しいプライマリの物理 IP アドレスと同じ MAC アドレスに関連付けられます。
ARP テーブルを読み取る前に、仮想 IP（VIP）を再度
ping。エントリが期限切れとしてマークされ、ping後にのみ更新される場合があります。
プライマリを停止する前後の、期待される ARP テーブルの例：
| 住所 | 停止前の MAC | 停止後の MAC |
|---|---|---|
| ノード 1 の物理 IP | ノード 1 の MAC | ノード 1 の MAC |
| ノード 2 の物理 IP | ノード 2 の MAC | ノード 2 の MAC |
| 仮想 IP（VIP） | ノード 1 の MAC | ノード 2 の MAC |
6. テスト 4 – Wireshark (Windows) または tcpdump (Linux) を使用したエンドツーエンドチェック
クライアントと両方のノードでパケットをキャプチャすることで、仮想 IP（VIP）への TCP 接続を追跡できます。Windows マシンでは Wireshark を、Linux マシンでは tcpdump を使用します。
パケットの MAC（イーサネット）ヘッダーを確認する必要があります。宛先 IP アドレスは仮想 IP（VIP）のままであり、トラフィックを受信するノードを示すのは宛先 MAC アドレスです。
観察すべき点：
| いつ | パケットをキャプチャする場所 | 検出された MAC アドレス |
|---|---|---|
| フェイルオーバー前 | クライアント | クライアント MAC →ノード 1（プライマリ） の MAC |
| フェイルオーバー前 | ノード 1 | 仮想 IP（VIP）へのパケットは受信されますが、ノード 2 は何も受信しません。 |
| フェイルオーバー中 | ネットワーク | ノード 2 が仮想 IP（VIP）用に送信した MAC リルーティングメッセージ：エイリアスとして設定されたときに OS によって送信されたメッセージ、および SafeKit（arpreroute="on"）によって送信された GARP |
| フェイルオーバー後 | クライアント | クライアント MAC →ノード 2 の MAC（新しいプライマリ） |
クライアントワークステーションがクラスターとは異なるサブネットにある場合、ノードで認識される「クライアント MAC」は、クライアントワークステーションの MAC アドレスではなく、2 つのサブネットを接続するゲートウェイ（ルーター）の MAC アドレスです。
7. テストを行うワークステーション
動作は、クライアントとクラスター間のネットワークパスによって異なります。アーキテクチャに関連する各タイプのクライアントからテスト 1 と 2 を実行します。
| クライアントの所在地 | 検査で確認すること |
|---|---|
| クライアントがクラスターと同じサブネット内にある場合 | クライアントの ARP テーブルの更新（テスト 3 回可能） |
| 異なるサブネット内のクライアント（ルーター、ゲートウェイ、ハイパーバイザー仮想ネットワーク） | ルーターまたはゲートウェイにおけるクライアントの ARP テーブルの更新 |
| Mirror クラスターの 1 つの VM もホストしているハイパーバイザー上のクライアント VM | ハイパーバイザーの仮想スイッチの動作。内部スイッチングとルーティングも処理します。 |
8. 期待される結果の概要
| テスト | アクション | 期待される結果 |
|---|---|---|
| 1 | PRIM / SECOND、ipconfig、ping、モザイク | プライマリのみのエイリアスとしての仮想 IP（VIP）。3 つの ping コマンドに応答します（ファイアウォールによってフィルタリングされない限り）。モザイクプライマリのみを表示します。 |
| 2 | プライマリーの停止 | 新しいプライマリのエイリアスとしての仮想 IP（VIP）。Virtual IP <VIP> set。モザイクは新しいプライマリのみが表示されます。 |
| 3 | プライマリを停止する前後の arp -a | 仮想 IP（VIP）がノード 1 の MAC アドレスからノード 2 の MAC アドレスに移動します。 |
| 4 | フェイルオーバー前後の Wireshark または tcpdump によるキャプチャ | クライアントは新しいプライマリの MAC アドレスに送信します。 |
9. トラブルシューティング
- フェイルオーバー後、仮想 IP（VIP）が応答しなくなりました。MAC ルーティングメッセージがパス上のデバイス（ルーター、ゲートウェイ、仮想スイッチ）によって考慮されず、以前のプライマリの MAC アドレスにトラフィックを送信し続けています。ネットワークチームに MAC ルーティングメッセージの処理を確認してください。
- GARP の送信:
<vip>セクションのarpreroute="on"属性(arpintervalおよびarpelapseと共に)は、フェイルオーバー後に仮想 IP(VIP)上で定期的に GARP を送信します。ユーザーガイドのセクション 13.6.4「<vip>構文」を参照してください。 - 仮想 IP（VIP）と MAC アドレスの解決の診断： ユーザーガイドのセクション 7.24「仮想 IP（VIP）と MAC アドレスの解決のトラブルシューティング」およびセクション 7.16「フェイルオーバー後の仮想 IP の問題」を参照してください。
詳細はこちら：
- 高可用性クラスターリングにおける仮想 IP アドレスの仕組みとは？
- 仮想 IP アドレスを使用したロードバランシングについては、「SafeKit farm クラスターにおけるロードバランシング仮想 IP アドレスのテスト」を参照してください。
