OpenStack環境でのAnsible Deployerのインサービスソフトウェアアップグレード手順を使用した、21.4.L2までのContrail Networkingのアップグレード
この手順を使用するタイミング
アップグレード手順を実行する前に、Docker をコンテナー上にシリアルにインストールします。ただし、スクリプトを使用して、Docker と並行してコンピューティングをアップグレードできます。各 Docker ホストをアップグレードしたら、contrail とサービスのステータスを確認します。contrail ステータス レポートのすべてのサービスが正常に実行されるまで、次のホストのアップグレードを続行しないでください。
Openstackオーケストレーションを使用するほとんどの環境で、ゼロインパクトアップグレード(ZIU)手順を使用して、ネットワーク障害を最小限に抑えてContrail Networkingをアップグレードすることを推奨します。
ZIU アップグレードを実行するには、「 Ansible Deployer を使用してゼロ インパクト Contrail Networking アップグレードを実行する方法」の手順に従います。Red Hat Openstack 13 または 16.1 を実行している場合は、「 Red Hat Openstack 13 を使用した環境でのゼロインパクトアップグレードプロセスを使用した Contrail Networking の更新」または「 Red Hat Openstack 16.1 を使用した環境でのゼロインパクトアップグレードプロセスを使用した Contrail Networking の更新」を参照してください。
また、このドキュメントの手順では、OpenStack オーケストレーションを使用する環境で Ansible Deployer を使用して、ネットワークの中断を最小限に抑えて Contrail Networking をアップグレードする方法についても説明します。
このドキュメントの手順は、Contrail Networking をリリース 3.2 以降からリリース 5.0 以降にアップグレードするために検証されています。このアップグレードの開始となる Contrail リリースは、リリース 3.2 以降の任意の Contrail Networking リリースで、Contrail Networking 4、5、19、20、21 から 21.4.L1 までのすべてのリリースを含みます。このアップグレードの対象となるリリースは、リリース 5.0 以降の任意の Contrail Networking リリースです。これには、Contrail Networking 5、19、20、21 から 21.4.L2 までのすべてのリリースが含まれます。
Contrail Networking リリースの開始 |
アップグレードされた Contrail Networking リリースをターゲットにする |
|---|---|
リリース 3.2 以降 リリース 4 任意のリリース 5 任意のリリース 19 すべてのリリース 20 21.4.L2より前のリリース21 |
任意のリリース 5 任意のリリース 19 すべてのリリース 20 21.4.L2までのリリース21 |
Contrail のインサービス ソフトウェア アップグレード(ISSU)の概要
インストールされているバージョンが Contrail リリース 3.2 以降の場合、ISSU(インサービス ソフトウェア アップグレード)を実行し、Ansible デプロイヤを使用してこのアップグレードを実行できます。ISSU を実行する際、Contrail コントローラ クラスタは並列セットアップと並行してアップグレードされ、コンピューティング ノードはその場でアップグレードされます。
アップグレード プロセスに進む前に、現在のシステムのスナップショットを作成することをお勧めします。
Contrail Ansible デプロイヤーを使用して ISSU を実行する手順は、以前の ISSU アップグレード手順と同様です。
この Contrail Ansible Deployer ISSU 手順には、OpenStack をアップグレードする手順は含まれていません。OpenStackのバージョンアップが必要な場合、該当するOpenStack手順を使用して実行する必要があります。
要約すると、ISSU プロセスは、順番に次の部分で構成されています。
新しいクラスターをデプロイします。
新しいクラスタと古いクラスタを同期します。
計算ノードをアップグレードします。
同期を完了し、アップグレードを完了します。
前提 条件
Contrail Ansible Deployer ISSU プロシージャを使用するには、次の前提条件が必要です。
リリース 3.2 以降の以前のバージョンの Contrail がインストールされている。
OpenStack コントローラおよび計算ノードと Contrail ノードがあります。
OpenStackはパッケージからインストールされている必要があります。
ContrailとOpenStackは、別々のノードにインストールする必要があります。
Ubuntu 14.04 を使用したコンピューティング ノードのアップグレードはサポートされていません。コンピューティング ノードは、最初に Ubuntu 16.04 にアップグレードする必要があります。
Ansible Deployer ISSU 手順のための Contrail システムの準備
要約すると、Contrail Ansible Deployer ISSU 手順のシステム準備フェーズの一般的な手順は次のとおりです。
-
Contrail Ansible Deployer を使用して新しいバージョンの Contrail を導入しますが、必ず次の Contrail コントローラ サービスのみを含めるようにしてください。
-
設定
-
コントロール
-
解析学
-
データベース
-
rmq、kafka、zookeeper などの追加サポート サービス。(vrouterサービスは、後で古い計算ノードにデプロイされます。
手記：セットアップには、キーストーン認証情報を提供する必要があります。
-
-
導入が完了したら、Contrail の Web インターフェイスにログインして動作することを確認できます。
ansible deployer を使用して新しいコントローラをデプロイする詳細な手順は次のとおりです。
-
新しいコントローラを展開するには、ジュニパーネットワークスのプロビジョニングホストに contrail-ansible-deployer-release-tag.tgz をダウンロードします。
-
新しいコントローラーファイル config/instances.yaml は次のように表示され、例に示すように変数の代わりに実際の値が表示されます。
provider_config: bms: domainsuffix: local ssh_user: user ssh_pwd: password instances: server1: ip: controller 1 ip provider: bms roles: analytics: null analytics_database: null config: null config_database: null control: null webui: null contrail_configuration: CONTROLLER_NODES: controller ip-s from api/mgmt network CONTROL_NODES: controller ip-s from ctrl/data network AUTH_MODE: keystone KEYSTONE_AUTH_ADMIN_TENANT: old controller's admin's tenant KEYSTONE_AUTH_ADMIN_USER: old controller's admin's user name KEYSTONE_AUTH_ADMIN_PASSWORD: password for admin user KEYSTONE_AUTH_HOST: keystone host/ip of old controller KEYSTONE_AUTH_URL_VERSION: "/v3" KEYSTONE_AUTH_USER_DOMAIN_NAME: user's domain in case of keystone v3 KEYSTONE_AUTH_PROJECT_DOMAIN_NAME: project's domain in case of keystone v3 RABBITMQ_NODE_PORT: 5673 IPFABRIC_SERVICE_HOST: metadata service host/ip of old controller AAA_MODE: cloud-admin METADATA_PROXY_SECRET: secret phrase that is used in old controller kolla_config: kolla_globals: kolla_internal_vip_address: keystone host/ip of old controller kolla_external_vip_address: keystone host/ip of old controller
-
最後に、Ansibleプレイブックを実行して、新しいコントローラーをデプロイします。
ansible-playbook -v -e orchestrator=none -i inventory/ playbooks/configure_instances.yml ansible-playbook -v -e orchestrator=openstack -i inventory/ playbooks/install_contrail.yml
これらのコマンドが正常に完了すると、新しいコントローラが起動し、有効になります。
制御ノードのプロビジョニングと同期手順の実行
要約すると、Contrail Ansible Deployer ISSU プロシージャのノードのプロビジョニングおよび同期フェーズの一般的な手順を次に示します。
古いクラスタで新しい制御ノードをプロビジョニングし、新しいクラスタで古い制御ノードをプロビジョニングします。
すべてのノードで、新しいクラスター内の次のコンテナーを停止します。
Contrailデバイスマネージャ
Contrailスキーマトランスフォーマー
Contrail-svcmonitor
新しいコントローラをメンテナンスモードに切り替えて、新しいクラスタでコンピューティングがプロビジョニングされないようにします。
ISSU の構成ファイルを準備します。
ISSU パッケージから同期前スクリプトを実行します。
ISSU パッケージから run-sync スクリプトをバックグラウンド モードで実行します。
制御ノードをプロビジョニングし、同期を実行する詳細な手順は次のとおりです。
-
新しいクラスタで古い制御ノードをペアリングします。任意のconfig-apiコンテナから実行することをお勧めします。
config_api_image=`docker ps | awk '/config-api/{print $1}' | head` -
古い制御ノードごとに次のコマンドを実行し、示されている実際の値を置き換えます。
docker exec -it $config_api_image /bin/bash -c "LOG_LEVEL=SYS_NOTICE source /common.sh ; python /opt/contrail/utils/provision_control.py --host_name hostname of old control node --host_ip IP of old control node --api_server_ip $(hostname -i) --api_server_port 8082 --oper add --router_asn 64512 --ibgp_auto_mesh \$AUTH_PARAMS"
-
古いクラスタの新しい制御ノードを同様のコマンドとペアにし(具体的な構文は古いクラスタの導入方法によって異なります)、示されている場所に実際の値を再度置き換えます。
python /opt/contrail/utils/provision_control.py --host_name new controller hostname --host_ip new controller IP --api_server_ip old api-server IP/VIP --api_server_port 8082 --oper add --admin_user admin --admin_password password --admin_tenant_name admin --router_asn 64512 --ibgp_auto_mesh
-
すべてのコントローラノード上の新しいクラスターで、contrail-device-manager、contrail-schema-transformer、および contrail-svcmonitor のすべてのコンテナを停止します。
docker stop config_devicemgr_1 docker stop config_schema_1 docker stop config_svcmonitor_1
-
Kolla/Juju のセットアップでは、contrail-device-manager コンテナの停止後に Contrail rabbitmq から contrail-device-manager キューを削除するには、次の手順を実行します。
手記：このステップでリストされているコマンドを、1 つの新しいコントローラからのみ実行します。
- 「Contrail rabbitmq」コンテナを入力します。
docker exec -it config_database_rabbitmq_1 bash
-
contrail-device-manager キューの名前を検索します。
rabbitmqctl list_queues | grep -F device_manager
-
contrail-device-manager キューを削除します。
rabbitmqctl delete_queue <device_manager.queue>
RHOSP セットアップの場合は、contrail-device-manager コンテナの停止後に、次の手順を実行して Contrail rabbitmq から contrail-device-manager キューを削除します。
- 「Contrail rabbitmq」コンテナを入力します。
podman exec -it contrail_config_rabbitmq bash
-
contrail-device-manager キューの名前を検索します。
rabbitmqctl list_queues | grep -F device_manager
-
contrail-device-manager キューを削除します。
rabbitmqctl delete_queue <device_manager.queue>
- 「Contrail rabbitmq」コンテナを入力します。
次の手順は、新しいコントローラから実行する必要があります。次に、ISSU 用に準備された設定が実行されます。(現時点では、手動の準備のみが可能です。
さまざまなデプロイで、古いcassandraはポート9160または9161を使用する場合があります。古いコントローラノード上の古いサービスの設定の詳細は、ファイル /etc/contrail-contrail-api.conf で確認できます。
設定は次のように表示され、ローカルに保存できます。
[DEFAULTS]
# details about oldrabbit
old_rabbit_user = contrail
old_rabbit_password = ab86245f4f3640a29b700def9e194f72
old_rabbit_q_name = vnc-config.issu-queue
old_rabbit_vhost = contrail
old_rabbit_port = 5672
old_rabbit_address_list = ip-addresses
# details about new rabbit
# new_rabbit_user = rabbitmq
# new_rabbit_password = password
# new_rabbit_ha_mode =
new_rabbit_q_name = vnc-config.issu-queue
new_rabbit_vhost = /
new_rabbit_port = 5673
new_rabbit_address_list = ip-addresses
# details about other old/new services
old_cassandra_user = controller
old_cassandra_password = 04dc0540b796492fad6f7cbdcfb18762
old_cassandra_address_list = ip-address:9161
old_zookeeper_address_list = ip-address:2181
new_cassandra_address_list = ip-address:9161 ip-address:9161 ip-address:9161
new_zookeeper_address_list = ip-address:2181
# details about new controller nodes
new_api_info = {"ip-address": [("root"), ("password")], "ip-address": [("root"), ("password")], "ip-address": [("root"), ("password")]}
config-apiイメージIDを検出します。
image_id=`docker images | awk '/config-api/{print $3}' | head -1`事前同期を実行します。
docker run --rm -it --network host -v $(pwd)/contrail-issu.conf:/etc/contrail/contrail-issu.conf --entrypoint /bin/bash -v /root/.ssh:/root/.ssh $image_id -c "/usr/bin/contrail-issu-pre-sync -c /etc/contrail/contrail-issu.conf"
run-synchronizationを実行します。
docker run --rm --detach -it --network host -v $(pwd)/contrail-issu.conf:/etc/contrail/contrail-issu.conf --entrypoint /bin/bash -v /root/.ssh:/root/.ssh --name issu-run-sync $image_id -c "/usr/bin/contrail-issu-run-sync -c /etc/contrail/contrail-issu.conf"
run-sync プロセスのログを確認します。これを行うには、run-sync コンテナーを開きます。
docker exec -it issu-run-sync /bin/bash cat /var/log/contrail/issu_contrail_run_sync.log
新しいクラスタへの計算ノードの転送
要約すると、Contrail Ansible Deployer ISSU プロシージャのノード転送フェーズの一般的な手順を次に示します。
コンピューティング ノードを新しいクラスターに転送する前に、Docker が正常に更新されたことを確認します。
-
新しいクラスターに転送するコンピューティング ノードを選択します。これにより、コンピューティング ノードの仮想マシンが選択されます。
-
仮想マシン (VM) を 1 つのコンピューティング ノードから別のコンピューティング ノードに手動で移行します。手順は次のとおりです。
手記：この手順は、ライブ マイグレーションを実行できない場合に便利です。
-
移行する VM とそのホストを特定します。次のコマンドを実行して、VM を停止します。
openstack server stop <vm-uuid>
-
VMインスタンスが起動されたソース・コンピュート・ノード上のVMディスク・イメージの場所を特定します。通常、ディスク・イメージの場所は次のとおりです。
/var/lib/docker/volumes/nova_compute/_data/instances/<vm-UUID>
-
このディレクトリを宛先コンピューティング ノードにコピーします。
-
宛先コンピュートノードで、次のコマンドを実行して、このディレクトリの権限を変更します。
chown -R 42436:42436 /var/lib/docker/volumes/nova_compute/_data/instances/<vm-UUID>
-
このインスタンスの nova データベースを新しいホストに更新します。
docker exec -it mariadb bash mysql -u <username> -p <password> nova update instances set node='new host fqname', host='new hostname' where uuid='<VM-UUID>'
例：
(mariadb)[mysql@nodem1 /]$ mysql -u root -p contrail123 nova MariaDB [nova]> update instances -> set node='nodem2.englab.juniper.net', host='nodem2' -> where uuid='b7178be6-d4da-4074-9124-d246fa3a2105' -> ; -
次のコマンドを実行して VM を起動します
openstack server start <vm-uuid>
-
-
Contrail リリース 3.x の場合は、次の手順でノードから Contrail を削除します。
-
vrouter-agentサービスを停止します。
-
vhost0インターフェイスを取り外します。 -
物理インターフェイスをスイッチダウンしてからアップにします。
-
カーネルから vrouter.ko モジュールを削除します。
-
-
Contrail リリース 4.x 以降では、次の手順でノードから Contrail を削除します。
-
エージェントコンテナを停止します。
-
物理インターフェイスを復元します。
-
-
必要なノードを追加して、ロール
vrouterとopenstack_legacy_computeでinstances.ymlします。 -
Contrail Ansible Deployer を実行して、新しい vrouter を展開し、古いコンピューティング サービスを設定します。
-
すべての新しいコンピューティング ノードには、次のものが含まれます。
-
コレクター設定は、新しい Contrail クラスタを指していました
-
Control/DNS ノードは、新しい Contrail クラスタを指しています
-
vnc_api_lib.ini の config-api 設定は、新しい Contrail クラスタを指していました
-
-
(オプション)転送されたノードでテスト ワークロードを実行して、新しい vrouter-agent が正しく動作することを確認します。
必要に応じて、次の手順に従って、コンピューティング ノードをロールバックします。
-
コンピューティング ノードからワークロードを移動します。
-
新しい Contrail コンテナを停止します。
-
ネットワーク構成が正常に復元されたことを確認します。
-
以前のバージョンの Contrail を、そのバージョンの導入方法を使用して導入します。
計算ノードを新しいクラスターに転送するための詳細な手順は次のとおりです。
選択したコンピューティングノードからワークロードを移動した後は、以前のバージョンの contrail-agent を削除する必要があります。たとえば、Ubuntu 16.04 とホストに直接インストールされている vrouter-agent の場合、以前の contrail-agent を削除する手順は次のとおりです。
# stop services systemctl stop contrail-vrouter-nodemgr systemctl stop contrail-vrouter-agent # remove packages apt-get purge -y contrail* # restore original interfaces definition cd /etc/network/interfaces.d/ cp 50-cloud-init.cfg.save 50-cloud-init.cfg rm vrouter.cfg # restart networking systemctl restart networking.service # remove old kernel module rmmod vrouter # maybe you need to restore default route ip route add 0.0.0.0/0 via 10.0.10.1 dev ens3
他の種類の展開の場合は、vrouter-agentコンテナとvrouter-agent-nodemgrコンテナを削除し、vhost0インターフェイスを無効にします。
-
新しいインスタンスは、vrouter と openstack_compute_legacy の 2 つのロールで instances.yaml に追加する必要があります。コンピュートノードの再プロビジョニングを回避するには、メンテナンスモードを
TRUEに設定します。例えば：instances: server10: ip: compute 10 ip provider: bms roles: vrouter: MAINTENANCE_MODE: TRUE VROUTER_ENCRYPTION: FALSE openstack_compute_legacy: nullinstances.yaml ノード定義に、アップグレードするコンピューティングノードのみが含まれていることを確認します。他のすべてのノードはコメントアウトする必要があります。
-
ansible Playbook を実行します。
ansible-playbook -v -e orchestrator=none -e config_file=/root/contrail-ansible-deployer/instances.yaml playbooks/configure_instances.yml ansible-playbook -v -e orchestrator=openstack -e config_file=/root/contrail-ansible-deployer/instances.yaml playbooks/install_contrail.yml
-
コンピューティングノードの contrail-status は次のように表示されます。
vrouter kernel module is PRESENT == Contrail vrouter == nodemgr: active agent: initializing (No Configuration for self)
- アップグレードの完了後、すべての新しいコントローラノードで contrail-control を再起動します。
docker restart control_control_1
-
コンピューティングノードをアップグレードした後、SSLハンドシェイクの問題によりXMPPがダウンします。例：
vrouter kernel module is PRESENT == Contrail vrouter == nodemgr: active agent: initializing (XMPP:control-node:10.10.10.1, XMPP:dns-server:10.10.10.1 connection down, No Configuration for self)
XMPP を起動する手順は次のとおりです。
- 次の 2 つのファイルを、新しい制御ノードからアップグレードされたコンピューティング ノードにコピーします。
/etc/contrail/ssl/private/server-privkey.pem /etc/contrail/ssl/certs/server.pem
-
アップグレードした計算ノードの VRouter エージェントを再起動します。
docker restart vrouter_vrouter-agent_1
- 次の 2 つのファイルを、新しい制御ノードからアップグレードされたコンピューティング ノードにコピーします。
-
新しいコンピューティング ノードで
contrail-statusを実行して、それらのノードの状態を確認します。これで、すべてのコンポーネントがアクティブになります。また、新しいコンピューティングノードで AZ/aggregates を作成して新しいインスタンスのステータスを確認し、いくつかのテストワークロードを実行して、正しく動作することを確認することもできます。
Contrail Ansible Deployer ISSU プロセスの最終処理
Contrail Ansible Deployer ISSU を次のようにファイナライズします。
-
issu-run-sync コンテナを停止します。
docker rm -f issu-run-sync
-
同期後のコマンドを実行します。
docker run --rm -it --network host -v $(pwd)/contrail-issu.conf:/etc/contrail/contrail-issu.conf --entrypoint /bin/bash -v /root/.ssh:/root/.ssh --name issu-run-sync $image_id -c "/usr/bin/contrail-issu-post-sync -c /etc/contrail/contrail-issu.conf" docker run --rm -it --network host -v $(pwd)/contrail-issu.conf:/etc/contrail/contrail-issu.conf --entrypoint /bin/bash -v /root/.ssh:/root/.ssh --name issu-run-sync $image_id -c "/usr/bin/contrail-issu-zk-sync -c /etc/contrail/contrail-issu.conf"
-
すべての新しいコントローラーノードで以下のコマンドを実行します。
docker-compose -f /etc/contrail/config/docker-compose.yaml restart api docker-compose -f /etc/contrail/config/docker-compose.yaml up -d
-
コンテナーを再起動します。
docker restart config_api_1
-
メンテナンスモードを解除し、以前に停止したすべてのコンテナを起動します。これを行うには、instances.yaml のエントリ
MAINTENANCE_MODEを FALSE に設定し、デプロイノードから次のコマンドを実行します。ansible-playbook -v -e orchestrator=openstack -i inventory/ playbooks/install_contrail.yml
この手順では、コンピューティング ノードのみを instances.yaml に含め、他のノードをコメント アウトする必要があります。
-
古い Contrail コントローラをクリーンアップして取り外します。config-apiコンテナから呼び出される provision-issu.py スクリプトをconfigissu.confで使用します。認証情報変数と API サーバー IP を、示されているように適切な値に置き換えます。
[DEFAULTS] db_host_info={"ip-address": "node-ip-address or hostname", "ip-address": "node-ip-address or hostname", "ip-address": "node-ip-address or hostname"} config_host_info={"ip-address": "node-ip-address or hostname", "ip-address": "node-ip-address or hostname", "ip-address": "node-ip-address or hostname"} analytics_host_info={"ip-address": "node-ip-address or hostname", "ip-address": "node-ip-address or hostname", "ip-address": "node-ip-address or hostname"} control_host_info={"ip-address": "node-ip-address or hostname", "ip-address": "node-ip-address or hostname", "ip-address": "node-ip-address or hostname"} admin_password = <admin password> admin_tenant_name = <admin tenant> admin_user = <admin username> api_server_ip= <any IP of new config-api controller> api_server_port=8082手記：現在、前のステップはホスト名でのみ機能し、IP アドレスでは機能しません。
-
任意のコントローラーノードから以下のコマンドを実行します。
手記：すべての *host_info パラメータには、新しいホストのリストが含まれている必要があります。
docker cp issu.conf config_api_1:issu.conf docker exec -it config_api_1 python /opt/contrail/utils/provision_issu.py -c issu.conf
-
他のサービスが存在しない場合は、サーバーをクリーンアップできます。
- 古いコントローラで次のパスに移動します。
[root@nodem1 ~]# cd /etc/kolla/neutron-server/ [root@nodem1 neutron-server]# pwd /etc/kolla/neutron-server [root@nodem1 neutron-server]# cat ContrailPlugin.ini [APISERVER] api_server_port = 8082 api_server_ip = <old_controller_ip> multi_tenancy = True contrail_extensions = ipam:neutron_plugin_contrail.plugins.opencontrail.contrail_plugin_ipam.NeutronPluginContrailIpa m,policy:neutron_plugin_contrail.plugins.opencontrail.contrail_plugin_policy.NeutronPluginContr ailPolicy,routetable:neutron_plugin_contrail.plugins.opencontrail.contrail_plugin_vpc.NeutronPluginContrailVpc ,contrail:None,service-interface:None,vf-binding:None [COLLECTOR] analytics_api_ip = <old_controller_ip> analytics_api_port = 8081 [keystone_authtoken] auth_host = <old_controller_ip> auth_port = 5000 auth_protocol = http admin_user = admin admin_password = password admin_tenant_name = admin insecure = True region_name = RegionOne
-
api_server_ip アドレスと analytics_api_ip アドレスを新しいコントローラの IP アドレスに変更します。
[root@nodem1 neutron-server]# pwd /etc/kolla/neutron-server [root@nodem1 neutron-server]# cat ContrailPlugin.ini [APISERVER] api_server_port = 8082 api_server_ip = <new_controller_ip> multi_tenancy = True contrail_extensions = ipam:neutron_plugin_contrail.plugins.opencontrail.contrail_plugin_ipam.NeutronPluginContrailIpa m,policy:neutron_plugin_contrail.plugins.opencontrail.contrail_plugin_policy.NeutronPluginContr ailPolicy,routetable:neutron_plugin_contrail.plugins.opencontrail.contrail_plugin_vpc.NeutronPluginContrailVpc ,contrail:None,service-interface:None,vf-binding:None [COLLECTOR] analytics_api_ip = <new_controller_ip> analytics_api_port = 8081 [keystone_authtoken] auth_host = <keystone_ip_addr> auth_port = 5000 auth_protocol = http admin_user = admin admin_password = password admin_tenant_name = admin insecure = True region_name = RegionOne
-
古いコントローラーで neutron-server コンテナを再起動します。
[root@nodem1]# docker restart neutron_server
-
古い制御ノードneutron_serverコンテナに移動します。ContrailPlugin.ini ファイルに新しいコントローラ IP が含まれているかどうかを確認します。新しいコントローラ IP が含まれている必要があります。
[root@nodem1 ~]# docker exec -it neutron_server bash (neutron-server)[neutron@nodem1 /]$ cd /etc/neutron/plugins/opencontrail (neutron-server)[neutron@nodem1 /etc/neutron/plugins/opencontrail]$ cat ContrailPlugin.ini [APISERVER] api_server_port = 8082 api_server_ip = <new_controller_ip> multi_tenancy = True contrail_extensions = ipam:neutron_plugin_contrail.plugins.opencontrail.contrail_plugin_ipam.NeutronPluginContrailIpa m,policy:neutron_plugin_contrail.plugins.opencontrail.contrail_plugin_policy.NeutronPluginContr ailPolicy,routetable:neutron_plugin_contrail.plugins.opencontrail.contrail_plugin_vpc.NeutronPluginContrailVpc ,contrail:None,service-interface:None,vf-binding:None [COLLECTOR] analytics_api_ip = <new_controller_ip> analytics_api_port = 8081 [keystone_authtoken] auth_host = <keystone_ip_addr> auth_port = 5000 auth_protocol = http admin_user = admin admin_password = password admin_tenant_name = admin insecure = True region_name = RegionOne
-
熱構成も同じ変更が必要です。パラメータ
[clients_contrail]/api_serverを見つけて、新しい config-api IP アドレスのリストを指すように変更します。
リリース21.4.L2でのトラブルシューティングリンクループ
Contrail Networking リリース 21.4.L2 の Ansible Deployer では、contrail 設定ノードにある /var/log/contrail ディレクトリにリンクループが導入されています。これは、Contrail Networking リリース 21.4.L2 Ansible Deployer が起動されるたびに発生します。前述の再帰により、ansible deployer プレイブックの再実行が失敗します。この問題は、Contrail Networking リリース 21.4.L3 で解決されています。ただし、Contrail Networking リリース 21.4.L2 では、特定の回避策に従うために手動による介入が必要です。
回避策:すべての Contrail Config ノードから誤ったシンボリックリンクを手動で削除します。
sudo unlink /var/log/contrail/config-database-rabbitmq/config-database-rabbitmq