このトピックでは、NSX Advanced Load Balancer Controller クラスタに関する基本的な質問に答えます。

  • NSX Advanced Load Balancer Controller クラスタでサポートされるノードの数はいくつですか。

    NSX Advanced Load Balancer Controller クラスタには、1 台のクラスタに 1 台（スタンドアローン モード）または 3 台のコントローラ ノードを含めることができます。

  • NSX Advanced Load Balancer Controller クラスタの動作に必要なノードの数はいくつですか。

    3 ノード クラスタでは、クラスタが動作するために、ノードのクォーラム（マジョリティ）があることが必要です。つまり、少なくとも 2 台のノードが稼動している必要があります。

  • 通常の動作で、NSX Advanced Load Balancer Controller 内の 3 台のノードがどのように使用されるかを説明してください。

    3 台のノードからリーダー ノードが選択され、クラスタのすべてのアクティブ メンバー間でプロセスの起動またはシャットダウンを調整します。構成データベースとメトリック データベースは、リーダー ノードでアクティブになり、フォロワー ノードでスタンバイ モードになるように構成されます。

    ストリーミング レプリケーションは、アクティブ データベースをスタンバイ データベースに同期するように構成されます。分析機能は、クラスタのすべてのノード間で共有されます。特定の仮想サービスは、ログとメトリックをクラスタのノードの 1 つにストリーミングします。

  • フォロワー ノードが停止したらどうなりますか。

    このノードはアクティブ メンバー リストから削除されます。このノードで実行された作業は、NSX Advanced Load Balancer Controller クラスタ内の残りのノード間で再分散されます。

  • リーダー ノードが停止したらどうなりますか。

    フォロワー ノードの 1 つがリーダーとして昇格します。これにより、クラスタ内の残りのノード間でプロセスのウォーム リスタートがトリガされます。新しいリーダーでスタンバイの構成とメトリック データベースをスタンバイからアクティブに昇格するには、ウォーム スタンバイが必要です。

    注：

    ウォーム リスタート中、Controller の REST API は 2 ～ 3 分間使用できません。

  • 2 台のノードが停止するとどうなりますか。

    少なくとも 1 台のノードが稼動するまで、クラスタ全体が動作しなくなります。クラスタを動作可能にするには、ノードのクォーラム（3 つのうち 2 つ）が稼動している必要があります。

  • クラスタ コンバージェンス（単一または複数のノードが停止して稼動状態に戻る）の間、トラフィックは中断されますか。

    単一または複数のノードが停止し、再び稼動すると、クラスタは動作しなくなり、SE は構成済みの仮想サービスのためにトラフィックを転送し続けます。これはヘッドレス モードと呼ばれます。

    分析（ログとメトリック）は SE でバッファされます。Controller クラスタが再び稼動状態になると、クラスタは SE と再同期し、メトリックとログの収集を開始します。この間、データ プレーンのトラフィックは正常に流れ続けます。

  • 3 台のノードのうち 2 つが完全に停止して回復できない場合は、動作しないクラスタをリカバリします。

    詳細については、「動作しない Controller クラスタのリカバリ」を参照してください。

  • 3 台の NSX Advanced Load Balancer Controller ノードがすべて完全に停止し、回復できない場合は、システムをリカバリします。

    詳細については、「NSX Advanced Load Balancer 構成のバックアップとリストア」を参照してください。

  • Controller クラスタのメンバーシップを再構成します。

    詳細については、「NSX Advanced Load Balancer Controller クラスタ構成の変更」を参照してください。

  • リソース割り当て（メモリ、CPU、ドライブ容量）が異なる NSX Advanced Load Balancer Controller のノードをクラスタに含めることはできますか。

    これらの同じリソースを、Controller クラスタ内の 3 台のノードそれぞれに割り当てることをお勧めします。時間の経過とともに、成長に合わせてクラスタ内の NSX Advanced Load Balancer Controller のサイズ変更（リソース割り当ての変更）が必要になったら、一度に 1 台の NSX Advanced Load Balancer Controller ノードでリソース割り当てを変更します。ただし、望ましいのは、クラスタ内のすべてのノードが最終的には同じ割り当てにサイズ変更されることです。

  • クラスタ内の NSX Advanced Load Balancer Controller を異なるサブネットに配置できますか。

    はい。この構成はサポートされており、特定のトポロジでは、フォルト トレランス向上のために推奨される場合さえあります。ただし、Controller を別々のサブネットに配置する場合の制約は、クラスタ IP アドレスがサポートされていないことです。クラスタ IP アドレスを使用するには、すべてのコントローラ ノードが同じサブネット内にあることが必要です。

  • クラスタ リーダーは手動で変更できますか。

    いいえ。現在、この操作はサポートされていません。リーダーは、クラスタの初期展開時、または完全に停止したクラスタを回復するときに選択できます。ただし、クラスタの動作中にリーダーを手動で変更することはできません。

    NSX Advanced Load Balancer Controller のコントローラは、リーダーの選出に参加し、障害発生時には新しいリーダーを自動的に決定します。

  • クラスタのフェイルオーバー中にはどのタイマーが使用されますか。クラスタのフェイルオーバー タイマーは構成可能ですか。

    リーダーの障害

    クラスタのリーダー Controller に障害が発生すると、Controller プロセスの内部ウォーム リスタートがトリガされます。通常、これには、リーダーに障害が発生したかどうかが検出されてから 2 ～ 3 分かかります。

    リーダーのグレースフル再起動

    グレースフル再起動の場合、障害の検出はほぼ瞬時に行われます。

    リーダーのグレースフルでないパワーオフ

    リーダーのグレースフルでないパワーオフの場合、リーダーに障害が発生したかを検出するのに最大 30 秒かかる場合があります。

    これらのタイマーはテストに基づいて調整されていますが、構成することはできません。

  • 構成変更をフォロワー コントローラで直接行うことはできますか。

    はい。ほぼすべての構成変更は、どのコントローラ ノードでも行うことができます。

    例外：

    クラスタ自体の構成（ノードの IP アドレスとクラスタ アドレス）。

    リーダー ノードでのみ実行されるアップグレード。

  • 異なるリージョンにある複数のデータセンターで推奨されるクラスタ展開オプションは何ですか。

    NSX Advanced Load Balancer は、Controller クラスタを単一のリージョン内にのみ展開することをお勧めします。ただし、メンバー ノードはリージョン内の複数のアベイラビリティ ゾーンに展開されます。リージョンが複数ある場合は、リージョンごとに 1 台の Controller クラスタを展開することをお勧めします（詳細については、「異なるネットワークの NSX Advanced Load Balancer Controller のクラスタリング」を参照してください）。

  • NSX Advanced Load Balancer メトリック データベースのインポート方法およびエクスポート方法を教えてください。

    バージョン 22.1.2 にアップグレードする前に、メトリック データベースをエクスポートすることをお勧めします。メトリック データベースをエクスポートするには、/var/lib/postgresql/10/pg_metrics/ ディレクトリをコピーし、コントローラ仮想マシンの外部に保存します。以前のリリースにロールバックする必要がある場合は、エクスポートされたメトリックをインポートできます。これにより、データの損失を防ぐことができます。

    メトリック データベースをインポートするには、次の手順を実行します。

    • 最初にフォロワー ノードで次のコマンドを実行し、次にリーダーで次のコマンドを実行して、プロセス スーパーバイザーを停止します。

      systemctl stop process-supervisor

    • コピーした pg_metrics ディレクトリをリーダーの /var/lib/postgresql/10/pg_metrics/ に移動します。

    • 次を実行して、まずリーダーでプロセス スーパーバイザーを起動し、次にフォロワーで起動します。これにより、インポートされた pg_metrics データがリーダーからフォロワーにレプリケートされます。

      python3 /opt/avi/scripts/pg_rec_fix_cluster.py --nodelist leader_ip follower_1_ip follower_2_ip
    注：

    メトリック データベースのサイズに基づいて、クラスタが HA_ACTIVE になるまでには時間がかかります。