GSLB 展開で障害が発生した後の NSX Advanced Load Balancer の動作は、次に示す障害の状況によって異なります。

  1. リーダー サイトで発生しているのか、フォロワーの 1 つで発生しているのか。

  2. サイト全体で発生しているのか、NSX Advanced Load Balancer コントローラ でのみ発生しているのか。

フォロワー サイトの障害

注:

フォロワー サイトの障害の例では、サンタクララ、シカゴ、ニューヨークに展開されているインフラストラクチャに焦点を当てています。

サイト全体の障害
以下に示すように、NY-1 フォロワー サイトでサイト全体の障害が発生しています。

  1. サンタクララとシカゴのリーダーはアクティブ サイトであるため、障害を検出します。

  2. リーダーでは、GSLB 構成の管理上の変更は引き続き可能ですが、NY-1 サイトには反映されません。

  3. 制御プレーンとデータプレーンの両方の健全性モニターは、NY-1 の GS メンバーを「停止」とマークします。詳細については、NSX Advanced Load Balancer GSLB サービスおよび健全性モニターを参照してください。

  4. GSLB 構成の DNS サービスは、存続している 2 つのサイトで引き続き動作します。

  5. グローバル アプリケーション サービスは、存続するサイト(サンタクララ、シカゴ、および NY-2)で継続されます。

部分的なサイトの障害

NY-1 サイトの NSX Advanced Load Balancer コントローラ のみが失敗した場合、SE は引き続きヘッドレス モードでアプリケーションを提供します。

  1. リーダーとシカゴのコントローラは、制御プレーン モニターを使用して障害を検出します。

  2. リーダーで行われた管理上の変更は、NY-1 サイトには伝達されません。

  3. サンタクララとシカゴで実行されているデータ プレーンの健全性モニターは、NY-1 のメンバーを引き続き「稼動中」として認識します。

  4. GSLB 構成の DNS サービスは、3 つのサイトすべてで引き続き動作します(SE からのものであるため、いずれも失敗していません)。

  5. グローバル アプリケーション サービスは、4 つのサイト(サンタクララ、シカゴ、NY-1、および NY-2)のすべてで継続されます。

フォロワー サイトの回復

以下は、サイト全体または部分的なサイトの障害のいずれにも当てはまります。

  1. サンタクララのリーダー コントローラは、NY-1 の(新しく再起動された)フォロワー コントローラへの接続を検出します。最新の GSLB 構成がプッシュされます。

  2. 他のアクティブ サイトも同様に、制御プレーンの健全性モニターの結果として、NY-1 フォロワー コントローラへの接続の成功を検出します。

  3. データ プレーンが停止(部分的なサイトの障害)しなかった場合、これ以上のアクションは必要ありません。

  4. NY-1 の GS メンバーのデータ プレーン モニターが構成されていて、以前に NY-1 の GS メンバーを「停止」としてマークした場合、NY-1 のメンバーは「稼動中」とマークされ、それらのメンバーへのトラフィックは、それらのデータ プレーン モニターが健全であると再認識した後にのみ再開されます。

リーダー サイトの障害

サイト全体の障害
以下に示すように、サンタクララのリーダー サイトでサイト全体の障害が発生しています。

  1. それらはアクティブなサイトであるため、シカゴと NY-1 の両方が障害を検出します。

  2. GSLB 構成に管理上の変更を加えることはできません。

  3. 制御プレーンとデータ プレーンの両方の健全性モニターは、サンタクララの GS メンバーを「停止」としてマークします。

  4. GSLB 構成の DNS サービスは、存続している 2 つのアクティブ サイト(シカゴと NY-1)で引き続き動作します。

  5. グローバル アプリケーション サービスは、存続している 3 つのサイト(シカゴ、NY-1、および NY-2)で継続されます。

部分的なサイトの障害

サンタクララ サイトの NSX Advanced Load Balancer コントローラ のみが失敗する場合、サイトの SE は引き続きヘッドレス モードでアプリケーションを提供します。

  1. これらはアクティブなサイトであるため、シカゴとニューヨークの両方が、制御プレーン健全性モニターを使用してコントローラの障害を検出します。

  2. GSLB 構成に管理上の変更を加えることはできません。

  3. シカゴとニューヨークで実行されているデータ プレーンの健全性モニターは、引き続きサンタクララのメンバーを「稼動中」として認識します。

  4. GSLB 構成の DNS サービスは、サンタクララ、シカゴ、および NY-1 で引き続き機能します。

  5. グローバル アプリケーション サービスは、すべてのサイトで継続されます。

サイト構成エラー

サイト情報を保存すると、IP アドレスと認証情報に関連するサイト構成のエラーが表示されます。いくつかのエラー画面のサンプルは次のとおりです。

認証に失敗

ボストン サイトの管理者のユーザー名とパスワードは、そのサイトに固有のものにすることも、すべての NSX Advanced Load Balancer GSLB サイトで使用されるものと同じ認証情報にすることもできます。

ログインの最大再試行回数の失敗

適切に認証された個人がリーダーにログインして、GSLB 構成の読み取りや変更など、GSLB 関連の機能を実行します。また、その背後では、リーダー GSLB サイトがフォロワー GSLB サイトに無人でログインし、リーダーからのみ開始できる構成変更を渡します。どちらの場合も、ログイン試行のロックアウト ルールが有効である可能性があります。これにより、特定の数の失敗により、管理アカウントが指定された時間(デフォルト = 30 分)ロックアウトされます。

救済

新しい GSLB 構成を定義するとき、または GSLB サイトを既存の構成に追加するときは、サイトに関連付けるアカウントの認証情報を指定します。参加しているすべての GSLB サイトに同じ GSLB 管理アカウント(gslbadmin など)を定義することをお勧めします。以下に示すように、そのアカウントに No-Lockout-User-Account-Profile を関連付けることにより、ログインの最大再試行回数の失敗を減らすことができます。

GSLB 管理者の担当者とは別に無人の動作を追跡するには、スタッフ メンバーごとに異なる個別の ID を割り当てます。

HTTP 400 エラー

400 エラーが発生する可能性のある GSLB コンテキストがいくつかあります。この特定の例は、理解可能な制限を示しています。 NSX Advanced Load Balancer サイトは、1 つの GSLB 構成のみに参加できます。2 つ目の GSLB 構成に参加するための招待は拒否されます。