NCP クラスタと基盤をマネージャ モードからポリシー モードに移行できます。

NCP のアップグレード時に、NSX Manager モード リソースを NSX ポリシーに移行して、NCP をポリシー モードで実行できます。ドキュメントでは、移行は「インポート」とも呼ばれます。彼らは同じことを意味します。TAS 基盤を移行するこの機能は、NCP 4.1.2 以降で使用できます。TKGI クラスタと vanilla Kubernetes クラスタを移行する機能は NCP 4.0 以降で使用できます。

前提条件

  1. Kubernetes クラスタまたは TAS 基盤への移行には時間がかかる場合があり、NSX での制御プレーンのダウンタイム（作成、更新、削除は許可されません）が必要です。ダウンタイムは、次の 2 つがある移行方法に応じて持続します。
    1. 戦略 1：（TAS で推奨および必須）すべてのクラスタ（マネージャ モードまたはポリシー モードで実行）で制御プレーンのダウンタイムを同時にスケジューリングします。ダウンタイムは、すべてのクラスタがポリシーに移行されるまで継続します。この機能を使用すると、障害およびリカバリ中に NSX バックアップとリストア 機能を使用できます。
    2. 戦略 2:一度に 1 つのクラスタで制御プレーンのダウンタイムをスケジュール設定します。クラスタが移行されると、そのクラスタで NCP がポリシー モードで開始されます。NSXのバックアップとリストアは、現在のクラスタの移行中に他のクラスタがNSXに新しいワークロードを作成する可能性があるため、この方法では使用できません。このモードは、移行とロールバックが失敗した場合にクラスタを破棄できる場合に使用できます。
  2. NSX マネージャは、複数のクラスタまたは基盤でそれぞれ共有できます。同じ NSX Manager を共有する一度にポリシーに移行できるクラスタ/基盤は 1 つのみです。
  3. NCP で作成されたセクション間に存在し、手動で作成されたすべての DFW セクションを、NCP で作成された DFW セクションの範囲外に移動する必要があります。NSX 管理者によって作成された DFW セクションの処理を参照してください。
  4. NCP で作成されたセクション内でユーザーが作成したすべてのルールを、NCP で作成されたセクションから移動する必要があります。NSX 管理者によって作成された DFW セクションの処理を参照してください。
  5. NCP で作成されたマネージャ モードの LoadBalancer 仮想サーバには、255 個を超えるルールを設定しないようにする必要があります。つまり、Kubernetes のデフォルトの LoadBalancer に対する Ingress ルールは 255 個以下にする必要があります。255 を超える Ingress ルールがある場合は、NCP がマネージャ モードで実行されているときに、Ingress を複数の LoadBalancer CRD に分割する必要があります。
  6. NSX UA の前でロード バランサを使用している場合は、スクリプトによる移行中に行われたすべての API 呼び出しが同じ NSX アプライアンスに到達するように、ロード バランサにソース IP パーシステンス プロファイルを適用する必要があります。このパーシステンス プロファイルは、すべての基盤/クラスタがポリシー API に移行された後に削除する必要があります

制限事項と注意事項

  1. NSX マネージャが製品 TAS 基盤、TKGi、および Vanilla Kubernetes クラスタ間で共有されるシナリオはまだサポートされていません。同じNSX マネージャ ノードを使用して 1 つ以上の基盤と 1 つ以上の TKGi クラスタを実行する場合の例。
  2. ポリシー モードで NCP を移行して再起動すると、NCP は TAS Foundation または TKGI クラスタ内の既存のワークロードをNSXで調整します。調整時間は、既存のワークロード サイズに比例します。調整中に、ポッドやアプリケーション インスタンスの作成などの操作が失敗し、TAS および TKGI エンティティにマッピングされたNSXリソースの作成または削除に大幅な遅延が発生する可能性があります。NCP リソースの使用量がスケール制限に近い非常に大規模なクラスタまたは基盤の場合は、NCP がバックエンドと調整できるように、少なくとも 45 分をメンテナンス ウィンドウに追加することをお勧めします。調整が完了すると、NCP は失敗した操作の同期を自動的に再試行します。

プロセスの詳細

Kubernetes/TKGi クラスタまたは TAS 基盤がポリシー モードに移行されたときに移行されるNSX リソースには、次の 2 つのカテゴリがあります。
  1. 共有NSX リソース:これらのNSX リソースは管理者によって手動で作成され、TAS/TKGi の Opsmanager UI または vanilla Kubernetes の nsx-ncp-config Kubernetes 構成マップを介して NCP に提供されます。これらは、基盤とクラスタ間で共有できます。これらは、ユーザー仕様と呼ばれる YAML ファイルで基盤/クラスタの移行を開始する前に手動で指定する必要があります(「 Sample user-spec.yaml 」を参照)。
  2. NCP で作成されたNSX リソース:これらのNSX リソースは、基盤/クラスタ ワークロードに対応して NCP によって作成されます。これらは移行中に自動的に推定されます

注：NCP ポッドは、NCP で作成されたすべての NSX リソースがマネージャ モードの場合にのみ、マネージャ モードで動作できます。同様に、NCP ポッドは、NCP で作成されたすべての NSX リソースポリシー モードである場合にのみ、ポリシー モードで動作できます。

vanilla Kubernetes クラスタの移行は、「nsx-ncp-migrate-mp2p」という名前の Kubernetes ジョブによって実行され、TKGi クラスタと TAS 基盤は「migrate-mp2p」という名前の使用によって実行されます。このジョブ/使用は、Python プログラムを実行して、作成された共有リソースまたは NCP リソースNSX移行します。Python プログラムは、移行(「移行フェーズ」セクションを参照)とロールバック(「ロールバック モード」セクションを参照)の 2 つのモードで実行されます。使用/ジョブがトリガされる前に、まず、NSX ネットワーク（マネージャおよびポリシー クラスタ）を共有するすべてのクラスタで NCP を停止してから、NSX バックアップを作成する必要があります。詳細な手順については、Kubernetes クラスタまたは TAS 基盤の移行を参照してください。

移行モード

移行モードは、論理的に分離された 4 つのフェーズで実行されます。

フェーズ 1

検索 API を使用して、Manager API からすべてのNSX リソースを取得します。クラスタ タグ(NCP で作成されたリソースの移行時)またはユーザー仕様ファイルで指定された共有リソース(共有リソースの移行時)に基づいてリソースをフィルタリングします。移行サーバに要求本文の送信を開始します。要求を生成できない場合、NSX リソースは移行されません。

考えられる問題：
  • NSXとの接続の問題
  • Kubernetes API サーバに、NSX Manager リソースの移行に必要なリソースが含まれていません

フェーズ 2

フェーズ 1 で作成された移行要求を、 NSX で実行されている Migration Coordinator サービスに送信します。NSX によって要求が正常に処理されたら、要求を介して移行された NSX リソースの管理プレーン ID をローカル ディスクに保存します（これらは「移行レコード」と呼ばれます）。問題が発生した場合、プログラムは現在の実行中に移行されたすべての NSX リソースを、ローカル ディスクに保存されている管理プレーン ID を使用してマネージャ モードにロールバックします。

考えられる問題：
  • NSXとの接続の問題
  • 移行 API がエラーを返す

フェーズ 3

現在の実行中に移行されたNSX リソースで行う必要がある更新を推測します。これらは、NSX リソースのタグや表示名の更新のみを対象とします。更新を推測できない場合(対応する Kubernetes リソースが見つからない可能性がある場合)、すべてのNSX リソースがロールバックされます。

考えられる問題：
  • NSXとの接続の問題。
  • Kubernetes API サーバに、NSX ポリシー リソースの更新に必要なリソースが含まれていません。

フェーズ 4

フェーズ 3 で推測される情報を使用して、NSX ポリシー リソースを更新します。NSX リソースをその時点で更新できない場合は、更新されたポリシー リソースの本文とポリシー リソース URL をローカル ディスクに保存します。

考えられる問題：
  • NSXとの接続の問題。

移行中に問題が発生した場合は、「障害とリカバリ」セクションを参照してください。

ロールバック モード

このモードでは、Python プログラムはローカル ストレージの移行レコードに MP ID が存在するすべてのNSX リソースをロールバックしようとします(移行フェーズ 2 を参照)。正常にロールバックされると、NSX リソースの移行レコードが削除されます。ロールバック中に障害が発生した場合、実行は停止し、使用/ジョブを再度実行する必要があります。

プログラムが開始するとすぐに、ローカル ストレージに移行レコードが見つかると、ロールバック モードで自動的に実行されます(移行フェーズ 2 を参照)。

障害とリカバリ

電源障害、ディスクの枯渇、接続の問題、機能上の問題などの外部の問題が原因で、移行プロセスが正常に完了しないことがあります。このようなシナリオでは、いくつかのリカバリ方法があります。

最初に移行の使用/ジョブのログを確認することをお勧めします。これらは、次に実行するアクションを示している可能性があります。次のいずれかに属することができます。
  • (ログに示されていない場合のデフォルトの解決)移行の使用/ジョブを再度実行します。
    • 前の障害がフェーズ 1、2、または 3 で発生した場合、移行の使用/ジョブは移行レコードを使用してNSXリソースのロールバックを試みます(フェーズ 2 を参照)。これは、すべてのNSX リソースがロールバックされるまで実行する必要があります。
    • フェーズ 4 で以前の障害が発生した場合、移行の使用/ジョブはポリシー モードのNSX リソースの更新を再試行します。これは、すべてのNSX リソースが正常に更新されるまで実行する必要があります。
  • マネージャ モードで NCP を実行し、移行を再試行します。移行の errand/ジョブでクラスタを移行できない場合は、このクラスタ/基盤の NCP を再度マネージャ モードで実行する必要があります。ただし、これによりNSXバックアップが無効になります。そのため、このクラスタの移行を一時的にスキップします。他のすべてのクラスタをポリシー モードに移行したら、このクラスタの NCP をマネージャ モードで開始し、他のクラスタの NCP をポリシー モードで開始します。少なくとも 60 分間待ってから、最初から移行手順に従ってクラスタの移行を再試行します。

まれに、上記の手順でリカバリできないことがあります。その場合は、クラスタをポリシーに移行する前に作成した以前のバックアップ ポイントに NSX Manager をリストアし、すべてのクラスタの NCP を NSX のバックアップ実行時と同じモードで再起動し、再度移行を試みます。