インポート プロセスは 4 つのフェーズから構成されます。
フェーズ 1
マネージャ API からすべてのリソースを取得します。user-spec.yaml に指定された Kubernetes クラスタ タブ (ncp/cluster) または共有リソースに基づいてリソースをフィルタリングします。移行サーバに要求本文の送信を開始します。要求を生成できない場合、NCP はクラスタを移行せずに終了します。
- 接続の問題が原因でマネージャ API からリソースを取得できません
解決策：接続の問題を修正してから再試行します。
- Kubernetes にマネージャ API から取得したリソースが含まれていません
解決策：NCP をマネージャ モードで再度実行し、アイドル状態になるまで待機します。つまり、CRUD（作成、読み取り、更新、削除）操作を一切行いません。少なくとも 10 分は待機する必要があります。これは、NCP が再試行要求を送信するまでの最大間隔です。NCP ログにエラーが記録されていない場合は、問題は解決されています。
フェーズ 2
フェーズ 1 で作成されたインポート要求を移行 API に送信します。要求が正常に処理されたら、クライアントのローカル ディスクに、要求に含まれている manager_ids を記録します。要求が失敗した場合は、ローカル ディスクに保存された manager_ids を使用して、インポート済みのリソースをロールバックします。移行 API が重複要求を通知した場合、インポータはその manager_id を要求本文から削除し、要求を再送信します。
- 接続の問題
解決策：接続の問題を修正してから再試行します。
- 移行 API がエラーを返しました。
解決策：ポリシー API または移行 API に障害は発生した可能性があります。しばらくしてから再試行してください。問題が解決せず、config.yaml の rollback_imported_resources オプションでインポータが予期せず停止した場合は、インポートされたすべてのリソースをロールバックします。デフォルトでは、このフェーズで問題が発生すると、インポータがロールバックを行います。ただし、ロールバック中に問題が発生した場合は、手動で再試行する必要があります。mp_to_policy_importer を使用したロールバックに失敗した場合は、バックアップを使用して、Kubernetes クラスタをインポートする前の状態に NSX Manager を戻す必要があります。
注：DFW セクションとルールがインポートされ、その後にリソースのインポート要求が失敗した場合は、クラスタのインポートを再度開始する前に、作成したバックアップを使用してマネージャの状態をリストアする必要があります。
フェーズ 3
インポートされたすべてのリソースについて、ポリシー内のリソースに追加または削除が必要なタグを推測します。タグが推測できない場合（たとえば、対応する Kubernetes リソースが見つからない場合など）、インポータは、ローカル ディスクに保存されている manager_ids を使用して、インポート済みのリソースをロールバックします。この状況は、トランザクションの途中でマネージャ モードの NCP が停止した場合に発生する可能性があります。したがって、NCP をマネージャ モードで再起動して、しばらく待機する必要があります。
- Kubernetes にマネージャ API から取得したリソースが含まれていません
解決策：ロールバックの後、マネージャ モードで NCP を再度実行し、アイドル状態になるまで待機します。少なくとも 10 分は待機する必要があります。これは、NCP が再試行要求を送信するまでの最大間隔です。NCP ログにエラーが記録されていない場合は、問題は解決されています。
フェーズ 4
これは最も重要なフェーズです。このフェーズでは、予期しないエラーが発生しないようにすることを強くおすすめします。このフェーズで、インポータは新しいタグや追加情報を使用してポリシーのリソースを更新します。たとえば、インポータはセグメントの display_name を更新します。リソースを更新できない場合、インポータは更新されたポリシー リソースの本文とポリシー リソースの URL をクライアントのローカル ディスクに保存し、問題を解決した後に再試行するように指示します（問題はポリシー API または接続にあります）。
- 接続の問題
解決策：接続の問題を修正してから再試行します。
どのフェーズでも電源障害など予期しない問題が発生する可能性があります。問題の対処方法については、障害とリカバリを参照してください。
