---
title: "SafeKit mirror クラスターの仮想 IP アドレスをテストする"
canonical: "https://safekit.eviden.com/ja/best-practises/test-primary-backup-vip-mirror/"
description: "SafeKit mirror クラスターにおける仮想 IP の可用性とフェイルオーバーをテストします。GARP GARP、ARP チェック、パケットキャプチャを含みます。"
category: "best-practises"
lang: "ja"
topics: "1. 主要原則, 2. 前提条件：仮想 IP（VIP）の設定, 3. テスト 1 – プライマリサーバーが保持する仮想 IP（VIP）, 4. テスト 2 – 手動フェイルオーバー（プライマリの停止）, 5. テスト 3 – `arp -a` を使用した MAC ルーティングの確認, 6. テスト 4 – Wireshark (Windows) または tcpdump (Linux) を使用したエンドツーエンドチェック, 7. テストを行うワークステーション, 8. 期待される結果の概要, 9. トラブルシューティング"
translation: "translate_md 2026-11-05.10 | glossaire 2026-11-05.14 | Translation LLM | 23 expressions"
---

# ネットワーク内の SafeKit mirror クラスターの仮想 IP アドレスをテストする {#testing-the-virtual-ip-address-of-a-safekit-mirror-cluster-in-your-network}

このガイドでは、SafeKit mirror クラスタークラスター（mirror モジュール）の仮想 IP アドレス（VIP）がネットワークで正しく機能することを確認する方法について説明します。仮想 IP（VIP）はプライマリサーバーによって保持され、フェイルオーバー後に新しいプライマリサーバーに再ルーティングされます。

## 1. 主要原則 {#1-key-principles}

**前提条件:** 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）。

したがって、テストする必要があるのは次のとおりです。

1. 仮想 IP（VIP）はプライマリサーバーが保持し、クライアントから到達可能です。
2. プライマリサーバが変更されると、仮想 IP（VIP）に関連付けられた MAC アドレスは、ネットワーク（ルータ、ゲートウェイ、仮想化）内の新しいプライマリに再ルーティングされます。

## 2. 前提条件：仮想 IP（VIP）の設定 {#2-prerequisite-virtual-ip-vip-configuration}

1. mirror モジュールの `userconfig.xml` で、`<vip>` セクションに仮想 IP（VIP）を設定します。arpreroute `arpreroute="on"`属性により、フェイルオーバー後に新しいプライマリが GARP を送信します。

   ```xml
   <vip>
     <interface_list>
       <interface arpreroute="on">
         <real_interface>
           <virtual_addr addr="<VIP>" where="one_side_alias"/>
         </real_interface>
       </interface>
     </interface_list>
   </vip>
   ```

2. 両方のノードに設定を適用します。
3. モジュールを開始します。1 つのノードは **PRIM（Ready）** で、もう 1 つのノードは **SECOND（Ready）** である必要があります。

## 3. テスト 1 – プライマリサーバーが保持する仮想 IP（VIP） {#3-test-1--virtual-ip-vip-held-by-the-primary-server}

**手順**

1. プライマリサーバーで、`ipconfig` (Windows) または `ip addr show` (Linux) を実行します。
   →**期待される結果：** 仮想 IP（VIP）が、物理 IP アドレスのネットワークカードのエイリアスとして表示されます。
2. セカンダリサーバーで、同じコマンドを実行します。
   →**期待される結果：** 仮想 IP（VIP）が表示されない。
3. **クラスター外の**クライアントワークステーションから、物理 IP アドレスと仮想 IP（VIP）の両方に `ping`。
   →**期待される結果：** 3 つの `ping` コマンドすべてが応答する（ファイアウォールによってフィルタリングされない限り）。
4. SafeKit モザイクで仮想 IP（VIP）経由のアクセスを確認します。**外部**クライアントのブラウザから、`http://<VIP>:9010/safekit/mosaic.html` に接続し（SafeKit ウェブサーバーとコンソールが HTTPS に切り替えられている場合はポート 9453 を使用）、mirror **モジュール名**を入力してテストを実行します。
   →**期待される結果：** モザイクのすべてのセルに**プライマリサーバー**の名前が単色で表示されます。仮想 IP（VIP）へのすべての TCP 接続はプライマリによって処理されます。

![モザイクを使用して SafeKit mirror の仮想 IP アドレスをテストする](https://safekit.eviden.com/wp-content/uploads/2024/03/appli-20.png)

## 4. テスト 2 – 手動フェイルオーバー（プライマリの停止） {#4-test-2--manual-failover-stop-of-the-primary}

このテストでは、プライマリサーバーでモジュールを停止してフェイルオーバーをトリガーした際に、仮想 IP（VIP）がプライマリサーバーに追従することを確認します。

**手順**

1. SafeKit コンソール（またはコマンドラインで `safekit stop -m <module>`）から、プライマリ（ノード 1）上のモジュールを停止します。
   →**期待される結果：** ノード 1 は STOP（NotReady）になり、ノード 2 は ALONE（Ready）になります。新しいプライマリのログに、メッセージ `Virtual IP <VIP> set` が表示されます。
2. 新しいプライマリで、`ipconfig` または `ip addr show` を実行します。
   →**期待される結果：** 仮想 IP（VIP）は、このノードのエイリアスとして表示され、以前のプライマリノードには表示されなくなります。
3. クライアントのワークステーションから、3 つの `ping` コマンドを繰り返し実行し、仮想 IP（VIP）でモザイク再度実行します。
   →**期待される結果：** すべてが応答し、モザイクのすべてのセルに**新しいプライマリ**の名前が単色で表示されます。
4. ノード 1 でモジュールを再起動します。モジュールは再同期して SECOND (Ready) になり、ノード 2 は PRIM (Ready) になります。

## 5. テスト 3 – `arp -a` を使用した MAC ルーティングの確認 {#5-test-3--checking-mac-rerouting-with-arp--a}

フェイルオーバー前に仮想 IP（VIP）に関連付けられている MAC アドレスをメモし、フェイルオーバー後にそれが変更されていることを確認します。

このテストは、クライアントのワークステーションがクラスターと**同じ IP サブネット**にある場合にのみ実行可能です。

クライアントとクラスターの間にルーターがある場合、クライアントの ARP テーブルには仮想 IP (VIP) は含まれず、クラスターのネットワークに到達するために使用されるゲートウェイのアドレスが含まれます。その場合は、ネットワークチームにルーターまたはゲートウェイの ARP テーブルを確認してもらってください。

**手順**

1. モジュールはノード 1 で PRIM（Ready）、ノード 2 で SECOND（Ready）です。
2. クライアントのワークステーションで、物理 IP アドレスと仮想 IP（VIP）の両方を `ping`、次に `arp -a` を実行します。
   →**期待される結果：** 仮想 IP（VIP）は、**プライマリの物理 IP アドレスと同じ MAC アドレス**に関連付けられます。
3. プライマリ（ノード 1）でモジュールを `stop`。
4. 仮想 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) を使用したエンドツーエンドチェック {#6-test-4--end-to-end-check-with-wireshark-windows-or-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. テストを行うワークステーション {#7-which-workstations-to-test-from}

動作は、クライアントとクラスター間のネットワークパスによって異なります。アーキテクチャに関連する各タイプのクライアントからテスト 1 と 2 を実行します。

| クライアントの所在地 | 検査で確認すること |
|---|---|
| クライアントがクラスターと**同じサブネット**内にある場合 | クライアントの ARP テーブルの更新（テスト 3 回可能） |
| **異なるサブネット**内のクライアント（ルーター、ゲートウェイ、ハイパーバイザー仮想ネットワーク） | ルーターまたはゲートウェイにおけるクライアントの ARP テーブルの更新 |
| **Mirror クラスターの 1 つの VM もホストしているハイパーバイザー上の**クライアント VM | ハイパーバイザーの仮想スイッチの動作。内部スイッチングとルーティングも処理します。 |

## 8. 期待される結果の概要 {#8-summary-of-expected-results}

| テスト | アクション | 期待される結果 |
|---|---|---|
| 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. トラブルシューティング {#9-troubleshooting}

- **フェイルオーバー後、仮想 IP（VIP）が応答しなくなりました**。MAC ルーティングメッセージがパス上のデバイス（ルーター、ゲートウェイ、仮想スイッチ）によって考慮されず、以前のプライマリの MAC アドレスにトラフィックを送信し続けています。ネットワークチームに MAC ルーティングメッセージの処理を確認してください。
- **GARP の送信:**`<vip>` セクションの `arpreroute="on"`属性(`arpinterval` および `arpelapse` と共に)は、フェイルオーバー後に仮想 IP(VIP)上で定期的に GARP を送信します。ユーザーガイドのセクション 13.6.4「[`<vip>` 構文](https://safekit.eviden.com/ja/resources/safekit-user-guide-82/#_%3Cvip%3E_Syntax)」を参照してください。
- **仮想 IP（VIP）と MAC アドレスの解決の診断：** ユーザーガイドのセクション 7.24「[仮想 IP（VIP）と MAC アドレスの解決のトラブルシューティング](https://safekit.eviden.com/ja/resources/safekit-user-guide-82/#_Issue_with_VIP)」およびセクション 7.16「[フェイルオーバー後の仮想 IP の問題](https://safekit.eviden.com/ja/resources/safekit-user-guide-82/#_Problem_with_the_1)」を参照してください。

詳細はこちら：
- [高可用性クラスターリングにおける仮想 IP アドレスの仕組みとは？](https://safekit.eviden.com/ja/best-practises/how-a-virtual-ip-address-works/)
- 仮想 IP アドレスを使用したロードバランシングについては、[「SafeKit farm クラスターにおけるロードバランシング仮想 IP アドレスのテスト」を](https://safekit.eviden.com/ja/best-practises/test-load-balancing-vip-farm/)参照してください。