次の手順に従って、上記のシナリオに対して GSLB サービスを構成します。

  • 個々の VIP IP アドレス(VIP1 IP1、VIP2 IP2 など)を使用して構成します。

  • これにより、個々の VIP をマルチ VIP 仮想サービス用に構成できます。GSLB サービスですべての VIP を追加する場合は、すべての VIP を手動で追加する必要があります。

  • クライアントが avi.app.gslb.com の要求を送信すると、要求は最初に NSX Advanced Load Balancer DNS 仮想サービスに送信され、次に構成された GSLB アルゴリズムに基づいて最適なエンドポイントが選択されます。

  • その後、DNS 仮想サービスは、VIP の IP アドレスの 1 つで応答します。

  • この方法では各 VIP が明示的に追加されているため、NSX Advanced Load Balancer はデータパスの健全性チェックを使用して各メンバーの健全性を個別に監視します。

概要を説明した、この 2 番目の方法にはいくつかの制限があります。

  • 新しい VIP がマルチ VIP 仮想サービスに追加される場合があります(つまり、VS1 IP3 が既存の 2 つの IP アドレスに追加されます)。その場合は、GSLB サービスを手動で編集し、新しい VIP を GSLB プールに追加する必要があります。

  • マルチ VIP 仮想サービスであるため、GSLB サービスでプールを手動で変更する限り、VIP の IP アドレスが変更され、不整合が生じる可能性があります。

    NSX Advanced Load Balancer GSLB プール メンバーは、仮想サービスです(関連 VIP:port_number 付き)。このようなメンバーを構成するには、ユーザーがサイト ID、サイト内の仮想サービス、および仮想サービスの対応する VIP を一意に識別する必要があります。関連するパラメータは、GslbPoolMember オブジェクト内の cluster_uuidvs_uuidGslbPoolMember.ip です。

    サイト管理者は、VIP1 が IP2 から IP4 に変更されるように、特定の仮想サービスの NSX Advanced Load Balancer のローカル構成を変更します。

    状況:ローカル VIP IP4 は動作していますが、そのアドレスは(まだ)GSLB 構成では認識されていません。これはグローバル アプリケーションの一部としてアドバタイズされなくなりました。IP2 への参照は無効です。GSLB リーダーとアクティブ メンバーは、VIP (IP2) と VIP (IP4) 間の不一致を検出します。次に、NSX Advanced Load Balancer は、問題の GSLB プール メンバーを無効にし、「構成済みで稼動状態の VIP が同期していない」ことを管理者に通知します。

    詳細については、GSLB プールのローカル仮想サービス メンバーの VIP の変更を参照してください。

    このような状況を回避するには、最初の方法を使用してマルチ VIP シナリオの GSLB プール メンバーを構成することをお勧めします。次のメリットがあります。

    • 個別の VIP を追加する必要はありません。

    • 仮想サービス レベルで、IP アドレスの変更イベントに不整合はありません。