コントローラが失われた場合の影響は、コントローラがスタンドアローンとして展開されているか、3 ノードの Controller クラスタの一部として展開されているかによって異なります。コントローラの障害は、ソフトウェア障害や基盤となるハードウェアの障害など、さまざまな理由で発生する可能性があります。コントローラの障害は、残りの NSX Advanced Load Balancer インフラストラクチャを含むネットワークへの接続を失うことでも発生する可能性があります。
Controller クラスタ
Controller クラスタでは、3 つのコントローラ間でワークロードが分割されます。1 つのコントローラに障害が発生した場合、残りの 2 つのコントローラは通常どおり操作を続行し、データ プレーン トラフィックに影響しません。
障害が発生したコントローラがクラスタ リーダーの場合、残りのコントローラの 1 つがクラスタ リーダーを引き継ぎます。このリーダーシップの変更は、運用に直接影響しません。Controller クラスタ IP アドレスが作成されている場合、その IP アドレスは新しいリーダーに移動し、アドレスの ARPing（アドバタイズ）が始まります。
クラスタ クォーラム
Controller クラスタでは、クォーラムを維持するために、3 台のノードのうち少なくとも 2 台が稼動している必要があります。これにより、2 台のデバイスが同時にアクティブ（プライマリ）となり、構成の更新が競合する可能性がある「スプリット ブレイン」シナリオを回避できます。
コントローラがオンラインのまま、他のコントローラとの接続が失われた場合は、接続が回復するまでクラスタの一部ではなくなります。したがって、3 つのデータセンターのそれぞれに 1 つのコントローラと複数のサービス エンジンが作成され、1 つのデータセンターが他の 2 つのデータセンターへの接続を失った場合、隔離されたデータセンターのコントローラは、スタンドアローンとしての構成変更を受け付けません。隔離されたコントローラは、クラスタに再接続するか、スタンドアローンに正式に降格する必要があります。
障害が発生したコントローラの置き換え
コントローラの障害が永続的な状態になっている場合は、次のアクションを実行してコントローラを削除し、完全な高可用性をクラスタにリストアします。
コントローラが仮想マシンにあった場合は、クラウド オーケストレータからその仮想マシンを削除します。
稼動中の別のコントローラの Web インターフェイスから、障害が発生したコントローラの IP アドレスを削除します。 の順に移動します。
新しいコントローラをインストールします。
注：新しいコントローラの Web インターフェイスにログインしないでください。クラウド オーケストレータの選択など、初期セットアップのみを実行してください。
既存のコントローラから、新しいコントローラの IP アドレスを追加します。数分後に、クラスタの状態が緑色に変わるはずです。
スタンドアローン コントローラ
スタンドアローン コントローラ構成では、コントローラ障害が発生すると、NSX Advanced Load Balancer システムがヘッドレス状態になります。ヘッドレス状態では、既存のサービス エンジン (SE) が、直前に指定された指示に従って引き続き動作します。
コントローラがリストアされるまで、新しい構成変更は行えません。これは、新しいコントローラを再構築する（既存の接続を中断）か、既存のコントローラをオンラインに戻す（既存のデータ トラフィックに対して透過的）ことによって実行できます。
ヘッドレス状態のとき、SE は十分なディスク容量がある場合にクライアント ログのバッファを試みます。コントローラのホストの再起動時など、コントローラが一時的にオフラインになると、SE はコントローラが戻った後で再接続し、バッファされたクライアント ログを取得できます。
