高可用性クラスタリングにおける仮想 IP アドレス (VIP) はどのように機能しますか?

高可用性クラスターの仮想 IP アドレスとは何ですか?

• 定義: 仮想 IP (VIP) アドレス は、アプリケーションへの継続的なアクセスを保証するために 高可用性クラスタリング で使用されるフローティング ネットワーク アドレスです。標準 IP とは異なり、VIP は特定の物理ハードウェア インターフェイスにバインドされませんが、クラスター ノード間を移動して、クライアントの単一の永続的なエントリ ポイントを維持します。
• ハードウェアは不要: SafeKit は Gratuitous ARP (GARP) を使用してソフトウェア レベルで VIP を管理し、同じサブネット環境での外部ロード バランサーの必要性を排除します。
• アプリケーションの透明性: ローカル VIP にバインドすることにより、アプリケーションはフェイルオーバー イベントを認識せず、クライアントのソース IP と既存のセキュリティ構成を維持します。
• 災害復旧: 拡張 LAN を使用すると、リモート データセンター間で同じ VIP を使用できるため、複雑な DNS 再ルーティングや TTL キャッシュの遅延と比較して、サイト間のフェイルオーバーが簡素化されます。

SafeKit での仮想 IP の実装

• ミラー クラスター: リアルタイムのレプリケーションとフェイルオーバーを容易にするために、プライマリ サーバー上でのみアクティブになるフローティング IP を備えています。
• ファーム クラスター: すべてのノード間で VIP を同時に維持することで、ネットワークの負荷分散を有効にします。

主な利点: Gratuitous ARP (アドレス解決プロトコル) または MAC アドレス テイクオーバー を利用することで、VIP はクライアントを手動で再構成することなくシームレスなアプリケーション フェイルオーバーを可能にし、年中無休のビジネス継続性を確保します。

• クラウドとマルチサブネット: 外部ロード バランサーのヘルス チェック (AWS、Azure、GCP) によって管理され、異なるサブネット間でトラフィックをリダイレクトします。

SafeKit のミラー クラスターとファーム クラスターの仮想 IP 実装戦略。

目次

• 同一サブネット フェールオーバー (ミラー クラスター) での仮想 IP アドレス (VIP) の動作方法
• 仮想 IP (VIP) が異なるサブネット間で動作する仕組み (ミラー クラスター)
• 同じサブネット ファーム (ファーム クラスター) で負荷分散された仮想 IP がどのように動作するか
• 負荷分散された仮想 IP が異なるサブネット間で動作する方法 (ファーム クラスター)
• 仮想 IP と DNS リダイレクト: DNS フェイルオーバーが頻繁に失敗する理由
• 比較: 仮想 IP の実装、レイテンシー、アプリケーションの透明性
• ネットワーク負荷分散と高可用性のための仮想 IP アドレスの構成
• 仮想 IP (VIP) に関するよくある質問
• 🔍 SafeKit 高可用性ナビゲーション ハブ

同一サブネット フェールオーバー (ミラー クラスター) での仮想 IP アドレス (VIP) の仕組み

ローカルサブネットでの自動フェイルオーバーとネットワーク再ルーティング

ローカル インフラストラクチャ内でシームレスなビジネス継続性を必要とする組織に、SafeKit ローカル ネットワーク クラスター向けソフトウェア デファインド 高可用性 は、仮想 IP アドレスとリアルタイム アプリケーション フェイルオーバーを管理するための堅牢な自動ソリューションを提供します。

ローカル ミラー クラスター: シームレスな 2 ノード Windows または Linux フェイルオーバー

SafeKit VIP エイリアスと MAC アドレス マッピング 両方のノードが同じローカル サブネット内に存在する標準の SafeKit ミラー クラスターでは、ソフトウェア定義の仮想 IP (VIP) を通じて高可用性が実現されます。ハードウェアベースのソリューションとは異なり、SafeKit はこの VIP を OS ネットワーク スタック内で直接管理します。この VIP は、IP エイリアス を介してサーバー 1 とサーバー 2 の一意の物理 IP アドレスの上に重ねられ、クライアントの永続的な論理エントリ ポイントとして機能します。

SafeKit の高度な IP エイリアスと複数の VIP のサポート

SafeKit ソリューションの主な利点は、ネットワーク ID の管理における柔軟性です。 VIP は、ノード間で「浮動」する 3 番目の IP アドレスです。特に、SafeKit は単一クラスター内で 複数の仮想 IP アドレスを管理できます。これらは同じプライマリ イーサネット カードに割り当てることも、異なる物理カードに分散することもできるため、さまざまなサービスが特定の仮想 ID にバインドされる複雑な構成が可能になります。

フェイルオーバーメカニズム: Gratuitous ARP (GARP)

SafeKit は、ハードウェア障害時の手動介入をゼロにします。通常の操作では、VIP は サーバー 1 の MAC アドレス (mac1) にマッピングされます。 SafeKit がサーバー 1 でハートビート障害を検出した場合、次の 2 段階の回復を実行します。

• アプリケーションの回復: SafeKit は、サーバー 2 上の重要なアプリケーション サービスを自動的に再起動します。
• ネットワーク再ルーティング: SafeKit は、Gratuitous ARP (GARP) メッセージを即座にブロードキャストします。これにより、すべてのネットワーク スイッチと接続されているクライアントの ARP キャッシュが強制的に更新され、VIP が サーバー 2 の MAC アドレス (mac2) に再マッピングされます。

リモートデータセンターと拡張VLAN

SafeKit の同一サブネット アルゴリズムは、通常はローカル クラスタに使用されますが、拡張 LAN または拡張 VLAN を介して接続されたリモート サイト全体での 災害復旧 (DR) には推奨される選択肢です。この「拡張された」アーキテクチャにより、地理的な距離を超えて単一のサブネットを維持できるため、ネットワーク トポロジが大幅に簡素化され、複雑なルーティング プロトコルのオーバーヘッドが回避されます。

⚠️ 注: Gratuitous ARP を介したレイヤー 2 再ルーティングは、アプリケーションにとって 最も透明なソリューション です。ロード バランサーを使用したレイヤー 3 の再ルーティングとは異なり、送信元/宛先 IP 変換 (SNAT/DNAT) を回避します。アプリケーションは元のクライアント IP でトラフィックを直接受信し、仮想 IP はローカルに構成されます。 多くのアプリケーションは、仮想 IP をローカルで参照し、元のクライアント IP を直接受信することを好みます。この透明性がないと、複雑なネットワーク変換により 期待どおりに動作しない可能性があります。

仮想 IP (VIP) が異なるサブネット間でどのように動作するか (ミラー クラスター)

ロードバランサ統合によるクラウド対応トラフィックオーケストレーション

外部ネットワーク インフラストラクチャを活用することで、SafeKit マルチ AZ およびクラウド クラスター向けソフトウェア デファインド 高可用性 は ネットワーク ロード バランサー とシームレスに統合し、別個のサブネットと可用性ゾーンにわたるトラフィック フェイルオーバーを調整します。

クロスサブネット ミラー クラスター: Windows および Linux の実装

ロード バランサのヘルス チェックによるマルチサブネット トラフィック ルーティング クラスタ ノードが 異なるサブネット に存在する場合、標準の ARP ベースのフェイルオーバーはできません。このシナリオでは、仮想 IP (VIP) は、サーバーのイーサネット カードではなく ロード バランサー (LB) でホストされます。ロード バランサーはゲートウェイとして機能し、リアルタイムの可用性に基づいてプライマリ ノードとセカンダリ ノードの物理 IP アドレスにトラフィックを送信します。

SafeKit ヘルスチェックによる動的ルーティング

SafeKit は、各ノードに専用の ヘルス チェック URL を提供することでトラフィック ステアリングを管理します。ロード バランサは、次の URL にクエリを実行して、クラスタの状態を判断します。

• プライマリ ノード (PRIM): ヘルス チェックは HTTP 200 OK を返します。ロード バランサーはすべてのトラフィックをここに転送します。
• セカンダリ ノード (SECOND): ヘルス チェックは HTTP 404 NOT FOUND を返します。ロード バランサーは、このノードにトラフィックを送信しません。

フェイルオーバー イベント中、SafeKit はヘルス チェックの応答を即座に切り替え、ロード バランサーをトリガーしてクライアント トラフィックを新しいプライマリ サーバーに再ルーティングします。

⚠️ 注: SafeKit はヘルス チェック ロジックを提供します。物理または仮想ロード バランサーは、ネットワーク インフラストラクチャによって提供される必要があります。

クラウド統合: AWS、Azure、GCP

この「ロード バランサー + ヘルス チェック」モデルは、クラウド高可用性の業界標準です。これは、次のような環境で SafeKit を実装するために不可欠です。

• 💡 Amazon AWS (AWS ネットワーク ロード バランサー)
• 💡 Microsoft Azure (Azure ロード バランサー)
• 💡 Google Cloud (GCP) (Google Cloud 負荷分散)

ネットワークに関する考慮事項: ロード バランサーと拡張 LAN

ロード バランサが不要な場合は、サブネット間の 拡張 LAN (VLAN ストレッチング) の実装についてネットワーク チームに相談してください。これにより、より単純な「同一サブネット」VIP モデルに戻すことができます。

⚠️ 注: ロード バランサーを選択する場合は、アプリケーションが 送信元/宛先 IP 変換 (SNAT/DNAT) と互換性があることを確認してください。ロード バランサーを使用すると、アプリケーションが元のユーザーの ID を追跡できなくなったり、アプリケーション自体のネットワーク インターフェイス上で直接構成された仮想 IP が認識されなくなるため、起動に失敗したりする可能性があります。

同じサブネット ファーム (ファーム クラスター) で負荷分散された仮想 IP がどのように動作するか

スケーラブルなパフォーマンス: カーネルレベルの負荷分散と冗長性

高トラフィック環境については、アーキテクチャ ガイド: マルチノード ファーム クラスターによるスケーラブルな高可用性で、SafeKit が全体の冗長性を維持しながら複数のアクティブ サーバーにワークロードを分散する方法について説明しています。

ファーム クラスター アーキテクチャ: Windows または Linux ノード間の負荷分散

カーネル フィルタリングによる分散トラフィック処理 負荷分散ファーム クラスタ では、仮想 IP (VIP) アドレスを使用してクライアント要求を複数のサーバーに同時に分散します。この例には 2 つのノードがありますが、アーキテクチャは大規模なサーバー ファームをサポートするように拡張されます。同一サブネット構成では、VIP は IP エイリアスを介してクラスター内の すべてのサーバー のイーサネット カード上に構成されます。

トラフィック分散: カーネルレベルのフィルター

単純なフェールオーバー クラスターとは異なり、ファーム クラスターは特殊な カーネル レベルのフィルターを通じてトラフィックを管理します。プロセスは次のように機能します。

• ARP マッピング: クライアントの ARP キャッシュでは、VIP は最初に単一のハードウェア アドレス (例: サーバー 1 の mac1) に関連付けられます。
• パケット分割: サーバー 1 がトラフィックを受信すると、SafeKit カーネル フィルターが受信パケットの ID を分析します (クライアント IP または TCP ポートに基づいて)。
• 負荷共有: フィルタは、どのパケットをローカルで処理する必要があり、どのパケットを他のノード (サーバー 2 など) にリダイレクトして処理するかを決定し、ワークロードのバランスを確保します。

Gratuitous ARP によるフェイルオーバーと再ルーティング

プライマリ ノード (サーバー 1) に障害が発生した場合、クラスターは Gratuitous ARP (GARP) を通じて可用性を維持します。 SafeKit は、サーバー 2 の mac2 でクライアント ARP キャッシュを更新するための GARP メッセージをブロードキャストします。これにより、プライマリの「エントリ ポイント」に障害が発生した場合でも、クライアントはファーム内の生き残ったノードに即座に再ルーティングされます。

リモートサイトへの展開

リモート データ センター全体で運用している組織の場合、サイトが 拡張 LAN または VLAN 経由でリンクされていれば、この負荷分散アルゴリズムは機能し続けます。これにより、仮想の「同一サブネット」環境が作成されます。これは、地理的に分散されたファーム クラスターにとって最も効率的な構成です。

負荷分散された仮想 IP が異なるサブネット間でどのように動作するか (ファーム クラスター)

マルチゾーン スケーリング: クラウド サブネット間のトラフィックのオーケストレーション

アーキテクチャ ガイド: マルチゾーンおよびクラウド環境でのファーム クラスターのスケーリング では、アプリケーションのワークロードを個別のアベイラビリティ ゾーンおよびサブネットに分散するための青写真が提供されます。

クロスサブネット ファーム クラスター: マルチノード Windows および Linux のスケーラビリティ

外部負荷分散によるグローバル トラフィック分散 ファーム ノードが 異なるサブネットに分散されている場合 (マルチ AZ クラウド展開では一般的)、仮想 IP (VIP) は外部 ロード バランサー (LB) によって管理されます。 LB は VIP を保持し、受信トラフィックをそれぞれのサブネットにあるサーバーの物理 IP アドレスに送信します。

インテリジェントなトラフィック ルーティングと負荷分散ルール

ロード バランサーは、次の 2 つの主な要素に基づいてクライアント リクエストを分散します。

• 分散ルール: トラフィックは、セッション アフィニティまたは負荷分散アルゴリズム (クライアント IP アドレス または クライアント TCP ポートの分析など) に従って分割されます。
• ノードの可用性: トラフィックは、SafeKit ヘルスチェックによって決定された正常なノードにのみルーティングされます。

⚠️ 注: SafeKit はヘルス チェック ロジックを提供します。物理または仮想ロード バランサーは、ネットワーク インフラストラクチャによって提供される必要があります。

SafeKit ヘルスチェックの仕組み

SafeKit は、ファーム内のすべてのサーバーにリアルタイムの ヘルス チェック URL を提供し、その動作ステータスをロード バランサーに伝達します。

• ノード UP: ヘルスチェックは HTTP 200 OK を返します。ロード バランサーは、このサーバーをアクティブなローテーションに含めます。
• ノード ダウン/フェイルオーバー: サーバーまたはアプリケーションに障害が発生した場合、SafeKit は HTTP 404 NOT FOUND を返します (またはサービスが到達不能になります)。ロード バランサーは、障害が発生したノードへのトラフィックの送信を直ちに停止します。

クラウド導入標準: AWS、Azure、GCP

このアーキテクチャは Cloud Farm クラスタ の基本モデルであり、サブネットまたはゾーン全体がオフラインになった場合でも、残りのノードが負荷を処理し続けることが保証されます。これは以下によってネイティブにサポートされています。

• 💡 Amazon AWS (AWS ネットワーク ロード バランサー)
• 💡 Microsoft Azure (Azure ロード バランサー)
• 💡 Google Cloud (GCP) (Google Cloud 負荷分散)

仮想 IP と DNS リダイレクト: DNS フェイルオーバーが頻繁に失敗する理由

DNS 伝播トラップ: VIP が DNS リダイレクトよりも優れたパフォーマンスを発揮する理由

フェイルオーバーを DNS に依存すると、高可用性アーキテクチャにおいて 誤ったセキュリティ感が生じることがよくあります。バックアップ サーバーを指すように DNS レコードを変更することは簡単な回復パスのように見えますが、予測不可能な遅延という重要な変数が生じます。 DNS ベースのリダイレクトは、変更を認識して伝達するために中間再帰リゾルバーの制御されていないエコシステムに依存しているため、現代のエンタープライズ サービスの「ゼロ ダウンタイム」要件と根本的に互換性がありません。

技術的なシナリオ: DNS 解決と「スタック」クライアント

標準的なネットワーク設定では、仮想名 (DNS 名) は、ユーザーが判読できるエントリ ポイントとして機能します。ただし、データがネットワーク上を移動するには、その名前が特定の 物理 IP アドレスに解決される必要があります。

高可用性クラスター内の物理 IP 1 上の DNS 解決と「スタック」クライアント

現在の状態: 物理 IP 1 への解決

最初に、クライアント 1 と クライアント 2 が DNS システムに仮想名をクエリします。システムは 物理 IP 1 を返します。次に、クライアントは、その特定のハードウェア アドレスへの直接ネットワーク接続 (ソケット) を確立します。

フェイルオーバーの課題: 物理 IP 2 への再ルーティング

物理 IP 1 のサーバーに障害が発生した場合、管理者は 物理 IP 2 を指すように DNS レコードを更新します。クライアントを正常に再ルーティングするには、「完璧な」シーケンスが発生する必要があります。

• Time to Live (TTL) は、すべての中間 ISP および企業リゾルバーで期限切れになる必要があります。
• クライアント 1 とクライアント 2 の両方のローカル DNS キャッシュをフラッシュする必要があります。
• アプリケーションは既存のソケットを閉じて、新しい DNS ルックアップを開始する必要があります。

これらの手順のいずれかが行われていない場合、クライアント 1 とクライアント 2 は無効な物理 IP 1 との通信を試みたまま「スタック」したままとなり、DNS レコードが更新されているにもかかわらずサービスのダウンタイムが発生します。

DNS リダイレクトの 2 つの「ブラック ボックス」

• 再帰的キャッシュ: 多くのインターネット サービス プロバイダー (ISP) や企業の DNS リゾルバーは、トラフィックを削減するために低い TTL 設定を無視し、要求された有効期限を超えて数分から数時間にわたって「古い」物理 IP 1 をキャッシュすることがよくあります。
• アプリケーションの永続性: 最近のアプリケーション (Java ベースのマイクロサービスや Web ブラウザなど) は、多くの場合、起動時に DNS ルックアップを 1 回だけ実行します。 DNS レコードが物理 IP 2 に更新されても、アプリケーションは内部メモリに保存されている初期 IP を引き続き使用します。

結論

DNS リダイレクトは、高可用性ソリューションとしては一貫性のないソリューションです。ローカル環境または地域環境内での即時フェイルオーバーの場合、ソフトウェア定義の 仮想 IP (VIP) が、ゼロ ダウンタイムの永続性を保証する唯一の方法です。

比較: 仮想 IP の実装、レイテンシー、アプリケーションの透明性

高可用性と災害復旧のための仮想 IP (VIP) リダイレクト方式と DNS 再ルーティングの技術比較。

ネットワーク負荷分散と高可用性のための仮想 IP アドレスの構成

SafeKit ビデオ: ネットワーク負荷分散と仮想 IP 管理 (5:03)

このビデオでは、仮想 IP アドレスを実装して 2 ノード クラスターに単一のエントリ ポイントを提供する方法を学びます。 SafeKit は、仮想 IP を自動的に管理することでネットワークの負荷分散を簡素化し、クライアント トラフィックがノード間で分散され、フェールオーバー中に即座にリダイレクトされるようにします。このデモでは Windows 上の Apache を使用しますが、ソリューションは他のアプリケーションでも同様に機能します。

章

1. 🎬 アーキテクチャ: 共有仮想 IP 用に 2 つのノードを準備する (0:13)
2. 🎬 構成: farm.safe モジュールと仮想 IP アドレスのセットアップ (2:20)
3. 🎬 検証: サーバークラッシュ時のフェイルオーバーテストと仮想IPリダイレクト (2:30)

段階的な実装

• 🛠️ Windows でのファーム クラスターのセットアップに関するガイドを読む
• 🛠️ Linux でのファーム クラスターのセットアップに関するガイドを読む

仮想 IP (VIP) に関するよくある質問

仮想 IP (VIP) とネットワーキング

仮想 IP (VIP) とは何ですか?また、物理 IP との違いは何ですか?

物理 IP アドレスは特定のネットワーク インターフェイスにバインドされていますが、仮想 IP (VIP) はハードウェアから独立した「フローティング」アドレスです。 SafeKit クラスターでは、VIP は永続的なエントリー ポイントとして機能します。プライマリ サーバーに障害が発生した場合、VIP は正常なセカンダリ ノードに自動的に移行され、クライアントの再構成が不要になります。

仮想 IP を使用するにはハードウェア ロード バランサーが必要ですか?

いいえ。 SafeKit 高可用性ソフトウェア は、ソフトウェア レベルで仮想 IP を管理します。同一サブネット アーキテクチャでは、IP エイリアシング と Gratuitous ARP (GARP) を利用してトラフィックをリダイレクトします。これにより、外部ハードウェア ロード バランサーや専用プロキシ サーバーのコストと複雑さが解消されます。

Gratuitous ARP (GARP) とは何ですか? なぜ使用されるのですか?

Gratuitous ARP (GARP) は、ネットワーク スイッチおよびルーターの ARP テーブルを更新するネットワーク ブロードキャストです。フェイルオーバー中に、新しいプライマリ サーバーは GARP パケットを送信して、仮想 IP がその MAC アドレスにマッピングされたことを通知し、ネットワーク ファブリック全体でトラフィックの即時の再ルーティングを強制します。

DNS 名を仮想 IP に関連付けることはできますか?

はい。 標準の A レコードを作成することで、DNS 名を VIP に関連付けることができます。主な利点は、リダイレクトが DNS レベルではなく、VIP レベル (ARP またはネットワーク リダイレクト経由) で管理されることです。これにより、DNS の伝播と TTL の有効期限に関連する遅延が回避され、アプリケーションの透明性が確保されます。

クラウドと高度なアーキテクチャ

仮想 IP はクラウド (AWS、Azure、GCP) でどのように機能しますか?

レイヤ 2 (ARP) が制限されているクラウド環境では、SafeKit は クラウド ロード バランサ (AWS ELB、Azure LB、または Google GCLB) と統合します。 SafeKit は、SNAT/DNAT を使用してトラフィックをアクティブ ノードにルーティングするためにプラットフォームが監視する ヘルス チェック URL を提供します。

ディザスタリカバリには、ロードバランサよりも拡張 LAN の方が優れていますか?

はい。リモート データセンターの場合は、拡張 LAN (拡張 VLAN) がサイト全体で アプリケーションの透過性を維持するため、多くの場合優れています。 同じ仮想 IP を維持することで、アプリケーションとそのクライアントは同じ ID を使用して通信を継続し、データセンター間の移行を完全にシームレスにします。

DNS 再ルーティングと仮想 IP の制限は何ですか?

DNS 再ルーティングは TTL (Time to Live) とクライアント側のキャッシュによって制限されており、回復が数時間遅れる可能性があります。大きな欠点は、DNS 名を再解決しないクライアントが、障害が発生したサーバーへの接続を試行したままになることです。対照的に、仮想 IP は、すべてのトラフィックを即座に再ルーティングする瞬時のレイヤー 2 フェイルオーバーを提供し、クライアント側の DNS キャッシュのステータスに関係なく接続を確保します。

透明性とセキュリティ

アプリケーションの透明性にとってローカル仮想 IP が重要なのはなぜですか?

ローカル 仮想 IP (VIP) は、ソフトウェアが永続 VIP にバインドできるようにすることで、アプリケーションの透過性を保証します。 SafeKit は、カーネル レベル でリダイレクトを処理し、バインドされた IP が変更される DNAT ソリューションとは異なり、アプリケーションがクラスターのフェイルオーバーを認識しないようにします。

仮想 IP を使用すると、クライアントの元の IP アドレスが保持されますか?

はい。 SafeKit は送信元ネットワーク アドレス変換 (SNAT) を回避します。 VIP はアクティブ サーバーに対してローカルであるため、アプリケーションは 元のクライアント IP を受け取ります。これは、セキュリティ監査、セッションの永続性、および規制ログにとって重要です。

🔍 SafeKit 高可用性ナビゲーションハブ

SafeKit の探索：機能、技術ビデオ、ドキュメント、無料トライアル