すべての neutron コントローラ ノードに AIM サービスをインストールして初期化します。この手順により、neutron ノードでインストール済みの統合プラグインを使用できるようになります。

1. a. AIM をインストールします。

   例:

   # yum -y install aci-integration-module.noarch

2. neutron 設定を使用して、AIM DB 移行スクリプトを実行します。この手順を実行するのは 1 回のみで、すべてのコントローラで繰り返す必要はありません。

   例:

   # aimctl -c /etc/neutron/neutron.conf db-migration upgrade

3. 既存の neutron 設定から AIM 設定を作成するスクリプトを実行します。

   例:

   # deployment_tool aim-config

   /etc/aim/aim.conf ファイルと /etc/aim/aimctl.conf ファイルを調べて、VMM ドメイン、物理ドメイン、物理リンク、およびその他の状態の設定が neutron 設定ファイルから AIM 設定ファイルに正常に移行されたことを確認します。各状態がレガシー設定ファイルに含まれていない場合は、それぞれを手動で追加する必要があります。保持する必要があるスタティック パス バインディングを設定ファイルに追加します。

4. 次のコマンドは 1 回のみ実行する必要があります。1 台のコントローラで AIM 設定をインストールします。

   例:

   # aimctl config replace

AIM サービスを開始します。AIM サービスを再開すると、新しい VMM ドメイン用に APIC リソースがプロビジョニングされます。L3out の使用状況によっては、外部トラフィックに影響する可能性があります。それ以外の場合は、分離されます。すべてのリソースが APIC と同期されるまで待ちます。

1. AIM/AID を起動します。

   例:

   # systemctl start aim-event-service-rpc
   # systemctl start aim-event-service-polling
   # systemctl start aim-aid

2. 次のコマンドは 1 回のみ実行する必要があります。1 台のコントローラで AIM 設定ファイルからインフラストラクチャを作成します。この手順によって、APIC に新しい VMM ドメインも作成されます。

   例:

   # aimctl infra create

次のコマンドは 1 回のみ実行する必要があります。1 台のコントローラで、新しい VMM ドメインや新しいシステム ID を使って AIM を更新します。VMM ドメインをロードします。

# aimctl manager load-domains

AIM サービスが正常にインストールされたら、すべての neutron ノードでサービスを再度シャットダウンします。AIM を使用するのは統合プラグインのみであり、現在 OpenStack は従来のプラグインを使用しているため、この手順が既存の OpenStack ワークロードに影響することはありません。AIM/AID を停止します。

# systemctl stop aim-event-service-rpc
# systemctl stop aim-event-service-polling
# systemctl stop aim-aid

エージェントを実行しているすべてのホストで、neutron-opflex-agents をシャットダウンします。

# systemctl stop neutron-opflex-agent

neutron-server をシャットダウンします。

# systemctl stop neutron-server

現在の状態をバックアップします。

1. 現在の neutron データベースをバックアップします。

2. 現在の APIC 設定をバックアップします。

neutron で統合プラグインを使用する準備を行います。

1. この OpenStack インスタンスで使用する共通ユーザの既存の ACI テナントと契約を追跡します。

2. 新しいプラグインを使用するように neutron 設定ファイルを再設定します。

   例:

   # deployment_tool toggle-config --toggle new

3. 前の OpenStack クラスタと異なるシステム ID、新しい VLAN プール、同じ AEP を使用するように設定ファイルを更新します。

4. neutron 設定ファイルに l3out DN を追加します。

   例:

   [ml2_apic_aim]
   migrate_ext_net_dns=<UUID of net>: <DN of External Network in APIC>

修復モードで検証ツールを実行します。これにより、AIM データベースに新しい設定が作成されます。さらに、neutron-server の再起動時に更新を必要とするようにポートが設定されます。

1. 検証ツールを実行します。

   例:

   # gbp-validate --config-file \ 
   /etc/neutron/neutron.conf --config-file \ 
   /etc/neutron/plugins/ml2/ml2_conf.ini

   すべての設定が「修復可能」であることを示すメッセージが表示されてツールが完了します。

2. 修復モードで検証ツールを実行します。

   例:

   # gbp-validate --repair --config-file \ 
   /etc/neutron/neutron.conf --config-file \ 
   /etc/neutron/plugins/ml2/ml2_conf.ini

すべてのノードで OpFlex エージェントをシャットダウンします。この手順を実行すると、ACI コントロール プレーンからの OpenStack ワークロードのトラフィックが切断されますが、既存のワークロードに影響することはありません。

1. OpFlex エージェントを停止します。

   例:

   # systemctl stop opflex-agent

2. OpFlex エージェントの VMM ドメインの設定を取得します。

   例:

   # deployment-tool get-domains

3. マッピング ファイル（デフォルトのファイル名：opflex_hosts.txt）の編集後に、新しい VMM ドメインを使用するように OpFlex エージェントの設定を更新します。

   例:

   # deployment-tool update-domains

一度に 1 台のコンピューティング ノードで、次の手順を順番に実行します。

1. Opflex エージェントを再起動して、約 60 秒待ちます。

   例:

   # systemctl start opflex-agent

   60 秒は一般に推定される待機時間です。実際の時間はインストールの規模によって異なります。

2. neutron-opflex-agent を再起動します。

   例:

   # systemctl start neutron-opflex-agent

AIM と neutron-server を起動します。

1. AIM を起動します。

   例:

   # systemctl start aim-event-service-rpc
   # systemctl start aim-event-service-polling
   # systemctl start aim-aid

2. ステップ 8b では、統合プラグインへのアップグレード時にポート バインディングが成功するように、導入ツールの「toggle-config」コマンドで agent_down_time パラメータを大きな値に設定しました。意図する agent_down_time 値を使用するには、次のコマンドを実行する前に、このパラメータを目的の値に設定する必要があります（デフォルトは 60 秒）。

3. neutron-server を起動します。

   例:

   # systemctl start neutron-server

L3out ポリシーに使用された古いブリッジ ドメインのサブネットを削除します。これにより、ネットワーク アドレッシングと関連するポリシーに使用する必要があるブリッジ ドメインおよび外部エンドポイント グループが明確になります。移行中に外部接続が必要な場合は、この接続が必要なホストのブリッジ ドメインにホスト ルート（つまり /32 アドレッシング）を追加できます。

新しい VMM ドメインを AEP と関連付けます。

次の点を確認します。

1. 接続：各コンピューティング ノード上にあるサンプル VM の L2 および L3 接続。

2. 移行後のセキュリティ グループが iptables ではなく OVS によって適用されている。

3. 新しい VM を作成する際の DHCP とメタデータの使用状況。

4. フローティング IP および SNAT の接続（該当する場合）。

5. ステップ 1c で設定したスタティック パス。

6. 新しい EPG による既存の契約の使用状況（該当する場合）。

7. 移行後の LBaaS の使用状況（該当する場合）。

古い VMM ドメインと AEP の関連付けを削除します。

APIC で残りのリソースをクリーンアップします。

1. 古いシステム ID を持つ VMM を削除します。

2. 古い APIC 設定またはステップ 7a で保存した関連付けを削除します。