ステップ 1 |
すべての neutron コントローラ ノードに AIM サービスをインストールして初期化します。この手順により、neutron ノードでインストール済みの統合プラグインを使用できるようになります。
-
a. AIM をインストールします。
# yum -y install aci-integration-module.noarch
-
neutron 設定を使用して、AIM DB 移行スクリプトを実行します。この手順を実行するのは 1 回のみで、すべてのコントローラで繰り返す必要はありません。
# aimctl -c /etc/neutron/neutron.conf db-migration upgrade
-
既存の neutron 設定から AIM 設定を作成するスクリプトを実行します。
# deployment_tool aim-config
/etc/aim/aim.conf ファイルと /etc/aim/aimctl.conf ファイルを調べて、VMM ドメイン、物理ドメイン、物理リンク、およびその他の状態の設定が neutron 設定ファイルから AIM 設定ファイルに正常に移行されたことを確認します。各状態がレガシー設定ファイルに含まれていない場合は、それぞれを手動で追加する必要があります。保持する必要があるスタティック
パス バインディングを設定ファイルに追加します。
-
次のコマンドは 1 回のみ実行する必要があります。1 台のコントローラで AIM 設定をインストールします。
|
ステップ 2 |
AIM サービスを開始します。AIM サービスを再開すると、新しい VMM ドメイン用に APIC リソースがプロビジョニングされます。L3out の使用状況によっては、外部トラフィックに影響する可能性があります。それ以外の場合は、分離されます。すべてのリソースが APIC と同期されるまで待ちます。
-
AIM/AID を起動します。
# systemctl start aim-event-service-rpc
# systemctl start aim-event-service-polling
# systemctl start aim-aid
-
次のコマンドは 1 回のみ実行する必要があります。1 台のコントローラで AIM 設定ファイルからインフラストラクチャを作成します。この手順によって、APIC に新しい VMM ドメインも作成されます。
|
ステップ 3 |
次のコマンドは 1 回のみ実行する必要があります。1 台のコントローラで、新しい VMM ドメインや新しいシステム ID を使って AIM を更新します。VMM ドメインをロードします。
# aimctl manager load-domains
|
ステップ 4 |
AIM サービスが正常にインストールされたら、すべての neutron ノードでサービスを再度シャットダウンします。AIM を使用するのは統合プラグインのみであり、現在 OpenStack は従来のプラグインを使用しているため、この手順が既存の
OpenStack ワークロードに影響することはありません。AIM/AID を停止します。
# systemctl stop aim-event-service-rpc
# systemctl stop aim-event-service-polling
# systemctl stop aim-aid
|
ステップ 5 |
エージェントを実行しているすべてのホストで、neutron-opflex-agents をシャットダウンします。
# systemctl stop neutron-opflex-agent
|
ステップ 6 |
neutron-server をシャットダウンします。
# systemctl stop neutron-server
neutron-server がシャットダウンされると、新しい OpenStack ワークロードをプロビジョニングすることも、既存のワークロードを更新することもできません。既存のワークロードのトラフィックは、それまでどおり引き続き機能します。
|
ステップ 7 |
現在の状態をバックアップします。
-
現在の neutron データベースをバックアップします。
-
現在の APIC 設定をバックアップします。
この手順でバックアップした neutron データベースと APIC 設定を復元すれば、ロールバックを実行できます。
|
ステップ 8 |
neutron で統合プラグインを使用する準備を行います。
-
この OpenStack インスタンスで使用する共通ユーザの既存の ACI テナントと契約を追跡します。
-
新しいプラグインを使用するように neutron 設定ファイルを再設定します。
# deployment_tool toggle-config --toggle new
-
前の OpenStack クラスタと異なるシステム ID、新しい VLAN プール、同じ AEP を使用するように設定ファイルを更新します。
-
neutron 設定ファイルに l3out DN を追加します。
[ml2_apic_aim]
migrate_ext_net_dns=<UUID of net>: <DN of External Network in APIC>
|
ステップ 9 |
修復モードで検証ツールを実行します。これにより、AIM データベースに新しい設定が作成されます。さらに、neutron-server の再起動時に更新を必要とするようにポートが設定されます。
-
検証ツールを実行します。
# gbp-validate --config-file \
/etc/neutron/neutron.conf --config-file \
/etc/neutron/plugins/ml2/ml2_conf.ini
すべての設定が「修復可能」であることを示すメッセージが表示されてツールが完了します。
-
修復モードで検証ツールを実行します。
# gbp-validate --repair --config-file \
/etc/neutron/neutron.conf --config-file \
/etc/neutron/plugins/ml2/ml2_conf.ini
いずれかの手順が失敗した場合は、ステップ 7 および 8 の変更を元に戻して移行手順を中止してください。失敗した場合はシスコ サポートで根本原因を分析し、今後の移行を成功させるために必要な変更を行う必要があります。
|
ステップ 10 |
すべてのノードで OpFlex エージェントをシャットダウンします。この手順を実行すると、ACI コントロール プレーンからの OpenStack ワークロードのトラフィックが切断されますが、既存のワークロードに影響することはありません。
-
OpFlex エージェントを停止します。
# systemctl stop opflex-agent
-
OpFlex エージェントの VMM ドメインの設定を取得します。
# deployment-tool get-domains
-
マッピング ファイル(デフォルトのファイル名:opflex_hosts.txt)の編集後に、新しい VMM ドメインを使用するように OpFlex エージェントの設定を更新します。
# deployment-tool update-domains
|
ステップ 11 |
一度に 1 台のコンピューティング ノードで、次の手順を順番に実行します。
-
Opflex エージェントを再起動して、約 60 秒待ちます。
# systemctl start opflex-agent
60 秒は一般に推定される待機時間です。実際の時間はインストールの規模によって異なります。
-
neutron-opflex-agent を再起動します。
# systemctl start neutron-opflex-agent
この手順では、このホストのすべての neutron ポートとそれぞれのフローティング IP を新しい VMM に移行します。
|
ステップ 12 |
AIM と neutron-server を起動します。
-
AIM を起動します。
# systemctl start aim-event-service-rpc
# systemctl start aim-event-service-polling
# systemctl start aim-aid
-
ステップ 8b では、統合プラグインへのアップグレード時にポート バインディングが成功するように、導入ツールの「toggle-config」コマンドで agent_down_time パラメータを大きな値に設定しました。意図する agent_down_time 値を使用するには、次のコマンドを実行する前に、このパラメータを目的の値に設定する必要があります(デフォルトは 60 秒)。
-
neutron-server を起動します。
# systemctl start neutron-server
|
ステップ 13 |
L3out ポリシーに使用された古いブリッジ ドメインのサブネットを削除します。これにより、ネットワーク アドレッシングと関連するポリシーに使用する必要があるブリッジ ドメインおよび外部エンドポイント グループが明確になります。移行中に外部接続が必要な場合は、この接続が必要なホストのブリッジ
ドメインにホスト ルート(つまり /32 アドレッシング)を追加できます。
|
ステップ 14 |
新しい VMM ドメインを AEP と関連付けます。
|
ステップ 15 |
次の点を確認します。
-
接続:各コンピューティング ノード上にあるサンプル VM の L2 および L3 接続。
-
移行後のセキュリティ グループが iptables ではなく OVS によって適用されている。
-
新しい VM を作成する際の DHCP とメタデータの使用状況。
-
フローティング IP および SNAT の接続(該当する場合)。
-
ステップ 1c で設定したスタティック パス。
-
新しい EPG による既存の契約の使用状況(該当する場合)。
-
移行後の LBaaS の使用状況(該当する場合)。
この手順が失敗した場合は、ロールバックを実行して移行手順で行われた変更を元に戻します。
|
ステップ 16 |
古い VMM ドメインと AEP の関連付けを削除します。
|
ステップ 17 |
APIC で残りのリソースをクリーンアップします。
-
古いシステム ID を持つ VMM を削除します。
-
古い APIC 設定またはステップ 7a で保存した関連付けを削除します。
|