OVN メカニズムドライバーへの移行

手順

1. ML2/OVN ステージデプロイメントを作成し、ターゲット ML2/OVN デプロイメントのベースライン設定を取得し、ターゲットデプロイメントの実現可能性をテストします。

   計画された移行後の実稼働環境要デプロイメントと同じ基本的なロール、ルーティング、およびトポロジーを使用して、ステージデプロイメントを設計します。完全な openstack overcloud deploy コマンドをすべてのデプロイメント引数とともに overcloud-deploy.sh というファイルに保存します。環境ファイルなど、openstack overcloud deploy コマンドが参照するファイルもすべて保存します。この手順の後半で、移行のターゲット ML2/OVN 環境を設定するためにこれらのファイルが必要になります。

   注記

   これらのファイルは、ステージデプロイメントの作成および移行でのみ使用してください。移行後に再利用しないでください。

2. openstack-neutron-ovn-migration-tool をインストールします。

   sudo dnf install openstack-neutron-ovn-migration-tool

3. ステップ 1 で作成した overcloud-deploy.sh スクリプトをコピーし、コピーの名前を overcloud-migrate-ovn.sh に変更します。overcloud-migrate-ovn.sh 内の overcloud deploy コマンドのすべてのパスがまだ正しいことを確認します。後続の手順で、overcloud-migrate-ovn.sh スクリプトの引数をカスタマイズします。

4. 以下の一覧で移行シナリオを確認し、overcloud-migrate-ovn.sh の openstack deploy コマンドをカスタマイズするための適切な手順を実施します。

   警告

   デプロイメントコマンドでは、環境ファイルを追加する -e 引数の順序に注意してください。一般的なデフォルト設定を含む環境ファイル (neutron-ovn-dvr-ha.yaml など) は、ブリッジマッピングなどのカスタムネットワーク環境設定を含むファイルを指定する -e の引数の前に配置する必要があります。

   シナリオ 1: DVR から DVR への移行で、コンピュートノードが外部ネットワークに接続されている場合

   • overcloud-migrate-ovn.sh で、カスタム heat テンプレートファイル引数を openstack overcloud deploy コマンドに追加します。これらの引数はコアテンプレートファイルの引数の後に追加します。

     次のコマンド例では、デフォルトの neutron-ovn-dvr-ha.yaml heat テンプレートファイルを使用します。実際のデプロイメントでは、OVN 環境を定義するために複数の heat ファイルを使用する場合があります。それぞれを別々の -e 引数を使用して追加してください。

     openstack overcloud deploy \
     --templates /usr/share/openstack-tripleo-heat-templates \
     ...
     -e /usr/share/openstack-tripleo-heat-templates/environments/services/ \
     neutron-ovn-dvr-ha.yaml

   シナリオ 2: 集中ルーティングから集中ルーティングへ (DVR なし)

   • デプロイメントで SR-IOV およびその他の NFV 機能を使用する場合は、overcloud-migrate-ovn.sh で -e 引数を使用して SR-IOV 環境パラメーターを openstack overcloud deploy コマンドに追加します。SR-IOV 環境ファイルは、コアテンプレート環境ファイル引数およびその他のカスタム環境ファイル引数の後に追加します。SR-IOV 環境ファイルの例については、/usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovn-sriov.yaml を参照してください。
   • カスタムのネットワーク変更は、移行前と同じままにします。

   シナリオ 3: 集中ルーティングから DVR への移行で、コンピューティングノードが br-ex 経由で外部ネットワークに接続されている場合

   • コンピュートノードが br-ex ブリッジを介して外部ネットワークに接続されていることを確認します。たとえば、compute-dvr.yaml などの環境ファイルで、次のパラメーターを設定します。次に、-e を使用して、スクリプト overcloud-migrate-ovn.sh の openstack overcloud deploy コマンドに環境ファイルを追加します。

     type: ovs_bridge
         # Defaults to br-ex, anything else requires specific # bridge mapping entries for it to be used.
         name: bridge_name
         use_dhcp: false
         members:
          -
           type: interface
           name: nic3
           # force the MAC address of the bridge to this interface
           primary: true

5. overcloud-migrate-ovn.sh の overcloud deploy コマンドの最後に次の引数を追加します。

   -e /usr/share/openstack-tripleo-heat-templates/environments/disable-container-manage-clean-orphans.yaml \
   -e $HOME/ovn-extras.yaml

6. router が環境ファイルまたはテンプレートの NeutronServicePlugins または NeutronPluginExtensions の値として表示される場合は、その値 (router) を ovn-router に置き換えます。たとえば、Tripleo-heat-templates/environments/services/neutron-ovn-dvr-ha.yaml では次のようになります。

   parameter_defaults:
      NeutronServicePlugins: "ovn-router,trunk,qos,placement"

7. すべてのユーザーに overcloud-migrate-ovn.sh ファイルの実行権限があることを確認します。このスクリプトには、移行プロセス中に実行権限が必要です。

   $ chmod a+x ~/overcloud-migrate-ovn.sh

8. export コマンドを使用して、以下の移行関連の環境変数を設定します。以下に例を示します。

   $ export OVERCLOUDRC_FILE=~/myovercloudrc

   STACKRC_FILE

   アンダークラウドの stackrc ファイル。

   デフォルト: ~/stackrc

   OVERCLOUDRC_FILE

   アンダークラウドの overcloudrc ファイル

   デフォルト: ~/overcloudrc

   OVERCLOUD_OVN_DEPLOY_SCRIPT

   デプロイメントスクリプト。

   デフォルト: ~/overcloud-migrate-ovn.sh

   DHCP_RENEWAL_TIME

   DHCP エージェント設定ファイルで設定する DHCP 更新時間 (秒単位)。

   デフォルト: 30

   BACKUP_MIGRATION_IP

   バックアップが保存されているサーバーの IP アドレス。

   デフォルト: 192.168.24.1

   BACKUP_MIGRATION_CTL_PLANE_CIDRS

   バックアップされるすべてのノードのコントロールプレーンサブネットを CIDR 表記でコンマ区切りで表した文字列。

   デフォルト: 192.168.24.0/24

   /usr/bin/ovn_migraton.sh ファイルの先頭に、関連するすべての環境変数のリストが表示されます。

9. ovn-migration ディレクトリーにいることを確認して、ovn_migration.sh generate-inventory コマンドを実行し、インベントリーファイル hosts_for_migration および ansible.cfg ファイルを生成します。

   $ ovn_migration.sh generate-inventory   | sudo tee -a /var/log/ovn_migration_output.txt

10. hosts_for_migration ファイルで正確性を確認してください。

    1. リストがお使いの環境と一致していることを確認します。
    2. 各ノードに ovn コントローラーがあることを確認します。
    3. リスト見出し ([ovn-controllers] など) がリスト項目に含まれていないことを確認します。
    4. ovn 移行ディレクトリーから、ansible -i hosts_for_migration -m ping all コマンドをすべて ping します。

11. (オプション) 移行中に予期しない事態が発生した場合に備えて、移行を元に戻す準備をするためにデプロイメントをバックアップします。

    1. setup_rear_extra_vars.yaml ファイルに次の行が存在する場合は削除します。

       USER_INPUT_TIMEOUT: 5
       KERNEL_CMDLINE: unattended
       ISO_RECOVER_MODE: unattended

    2. コントロールプレーンのバックアップ選択したバックアップメカニズムを使用して、コントローラーノードをバックアップします。サポートされている選択肢は、ReaR バックアップツールを使用するデフォルトの ovn-migration.sh backup コマンドです。

       $ ovn_migration.sh backup

    3. オーバークラウドのデプロイに使用されたテンプレートと環境ファイルをバックアップします。ovn-migration.sh backup コマンドはオーバークラウドをバックアップしません。移行が部分的にまたは失敗した後にコントローラーノードを元に戻す必要がある場合は、OVS オーバークラウドを復元するためにこのバックアップが必要になります。
    4. 元の RHOSP 16.2 ML2/OVS デプロイメントをデプロイするのに使用したスクリプトをコピーします。たとえば、元のスクリプトの名前は overcloud_deploy.sh になります。コピーに overcloud-revert-ovs.sh という名前を付けます。

    5. 次の内容を含む /home/stack/ovs-extra.yml ファイルを作成します。

       parameter_defaults:
         ForceNeutronDriverUpdate: true

    6. overcloud-revert-ovs.sh の最終的な環境ファイル引数が次のようになっていることを確認します。

       -e /home/stack/ovs-extra.yml

    7. overcloud-revert-ovs.sh を安全に保存します。失敗した移行を元に戻す場合に必要になります。
12. 「OVS から OVN への ML2 メカニズムドライバーの移行用コンテナーイメージの準備」 に進みます。

手順

1. ML2/OVN への移行後に使用する新しいコンテナーイメージを準備します。

   1. ホームディレクトリーに containers-prepare-parameter.yaml ファイルがない場合は作成します。

      $ test -f $HOME/containers-prepare-parameter.yaml || sudo openstack tripleo container image prepare default \
      --output-env-file $HOME/containers-prepare-parameter.yaml

   2. containers-prepare-parameter.yaml が $HOME/overcloud-migrate-ovn.sh ファイルおよび $HOME/overcloud-deploy.sh ファイルの末尾にあることを確認します。

   3. containers-prepare-parameter.yaml ファイルの neutron_driver を ovn に変更します。

      $ sed -i -E 's/neutron_driver:([ ]\w+)/neutron_driver: ovn/' $HOME/containers-prepare-parameter.yaml

   4. neutron_driver への変更を確認します。

      $ grep neutron_driver $HOME/containers-prepare-parameter.yaml
      neutron_driver: ovn

   5. イメージを更新します。

      $ sudo openstack tripleo container image prepare \
      --environment-file /home/stack/containers-prepare-parameter.yaml

      注記

      containers-prepare-parameter.yaml ファイルへの完全パスを指定します。それ以外の場合、コマンドはイメージリストを更新したりエラーメッセージを表示したりすることなく、非常に迅速に完了します。

2. アンダークラウドにおいて、更新されたイメージを検証します。

   . Log in to the undercloud as the user `stack` and source the stackrc file.
   $ source ~/stackrc
   $ openstack tripleo container image list | grep  '\-ovn'

   リストは以下の例のようになります。これには、OVN データベース、OVN コントローラー、メタデータエージェント、および neutron サーバーエージェント用のコンテナーが含まれます。

   docker://undercloud-0.ctlplane.redhat.local:8787/rh-osbs/rhosp16-openstack-ovn-northd:16.2_20211110.2
   docker://undercloud-0.ctlplane.redhat.local:8787/rh-osbs/rhosp16-openstack-ovn-sb-db-server:16.2_20211110.2
   docker://undercloud-0.ctlplane.redhat.local:8787/rh-osbs/rhosp16-openstack-ovn-controller:16.2_20211110.2
   docker://undercloud-0.ctlplane.redhat.local:8787/rh-osbs/rhosp16-openstack-neutron-server-ovn:16.2_20211110.2
   docker://undercloud-0.ctlplane.redhat.local:8787/rh-osbs/rhosp16-openstack-ovn-nb-db-server:16.2_20211110.2
   docker://undercloud-0.ctlplane.redhat.local:8787/rh-osbs/rhosp16-openstack-neutron-metadata-agent-ovn:16.2_20211110.2

3. 元のデプロイメントで VXLAN を使用している場合は、最大伝送単位 (MTU) 値の調整が必要になる場合があります。「VXLAN OVS デプロイメントから移行するための MTU 削減」 に進みます。

   元のデプロイメントで VLAN ネットワークを使用している場合は、MTU 調整をスキップして 「ML2 メカニズムドライバーの OVS から OVN への移行」 の手順に進むことができます。

手順

1. ovn_migration.sh 'reduce-dhcp-t1 を実行します。これにより、DHCP エージェントが実行しているすべてのノードで、/var/lib/config-data/puppet-generated/neutron/etc/neutron/dhcp_agent.ini 内の dhcp_renewal_time を設定する内部 neutron DHCP サーバーの T1 パラメーターが短くなります。

   $ ovn_migration.sh reduce-dhcp-t1   | sudo tee -a /var/log/ovn_migration_output.txt

2. T1 パラメーターが既存の仮想マシンに伝播されていることを確認します。プロセスに最大 4 時間かかる場合があります。

   • コンピュートノードのいずれかにログインします。

   • プロジェクトネットワークに接続された仮想マシンタップのいずれかで tcpdump` を実行します。

     T1 の伝播が成功すると、リクエストは約 30 秒ごとに発生することが予想されます。

     [heat-admin@overcloud-novacompute-0 ~]$ sudo tcpdump -i tap52e872c2-e6 port 67 or port 68 -n
     tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
     listening on tap52e872c2-e6, link-type EN10MB (Ethernet), capture size 262144 bytes
     13:17:28.954675 IP 192.168.99.5.bootpc > 192.168.99.3.bootps: BOOTP/DHCP, Request from fa:16:3e:6b:41:3d, length 300
     13:17:28.961321 IP 192.168.99.3.bootps > 192.168.99.5.bootpc: BOOTP/DHCP, Reply, length 355
     13:17:56.241156 IP 192.168.99.5.bootpc > 192.168.99.3.bootps: BOOTP/DHCP, Request from fa:16:3e:6b:41:3d, length 30013:17:56.249899 IP 192.168.99.3.bootps > 192.168.99.5.bootpc: BOOTP/DHCP, Reply, length 355

     注記

     cirros 仮想マシンでは、この検証はできません。cirros udhcpc 実装は DHCP オプション 58 (T1) に応答しません。完全な Linux 仮想マシンに属するポートで、この検証を試みます。Red Hat では、Windows や Linux ディストリビューションのバリアントなど、ワークロードに含まれるさまざまなオペレーティングシステムをすべて確認することを推奨します。

3. DHCP の T1 パラメーターへの変更を反映するように仮想マシンインスタンスが更新されていない場合は、再起動します。

4. 移行前の VXLAN ネットワークの MTU を減らします。

   $ ovn_migration.sh reduce-mtu   | sudo tee -a /var/log/ovn_migration_output.txt

   このステップでは、ネットワークごとに MTU を減らし、adapted_mtu で完了したネットワークにタグを付けます。このツールは、VXLAN ネットワークでのみ動作します。デプロイメントに VLAN プロジェクトネットワークしかない場合、この手順では値は変更されません。

5. VXLAN プロジェクトネットワーク上に静的 IP が割り当てられているインスタンスがある場合は、インスタンスの MTU を手動で 8 バイト減らします。たとえば、VXLAN ベースの MTU が 1450 の場合は、これを 1442 に変更します。

   注記

   このステップは、VXLAN プロジェクトネットワークに静的 IP の割り当てと MTU 設定を手動で提供している場合にのみ行います。デフォルトでは、DHCP が IP 割り当てと MTU 設定を提供します。

6. 「ML2 メカニズムドライバーの OVS から OVN への移行」 に進みます。

手順

1. 新しいネットワーク、サブネット、ルーターまたはインスタンスの作成、コンピュートノード間のインスタンスの移行など、Networking Service (neutron) API と対話するすべての操作を停止します。

   移行中の Networking API とのやり取りにより、未定義の動作が発生する可能性があります。移行が完了したら、API 操作を再開できます。

2. ovn_migration.sh start-migration を実行して移行プロセスを開始します。tee コマンドは、トラブルシューティング目的のスクリプト出力のコピーを作成します。

   $ ovn_migration.sh start-migration  | sudo tee -a /var/log/ovn_migration_output.txt

手順

1. 新しいネットワーク、サブネット、ルーターの作成や、コンピュートノード間での仮想マシンインスタンスの移行など、コントロールプレーン API と対話するすべての操作を停止します。
2. 各コントロールプレーンノードの電源をオフにします。次のステップに進む前に、コントロールプレーンノードの電源が完全にオフになっていることを確認します。
3. 対応するバックアップの ISO イメージで各コントロールプレーンノードをブートします。

4. Relax-and-Recover ブートメニューが表示されたら、各コントロールプレーンノードで Recover <control_plane_node> を選択します。<control_plane_node> を対応するコントロールプレーンノードの名前に置き換えます。

   注記

   システムで UEFI を使用している場合は、Relax-and-Recover (no Secure Boot) オプションを選択します。

5. それぞれのコントロールプレーンノードで root ユーザーとしてログインし、ノードを復元します。

   以下のメッセージが表示されます。

   Welcome to Relax-and-Recover. Run "rear recover" to restore your system!
   RESCUE <control_plane_node>:~ # rear recover

   コントロールプレーンノードの復元プロセスが完了すると、コンソールに以下のメッセージが表示されます。

   Finished recovering your system
   Exiting rear recover
   Running exit tasks

6. ノードの電源を切ります。

   RESCUE <control_plane_node>:~ #  poweroff

7. ブートシーケンスを通常のブートデバイスに設定します。ノードをブートすると、以前の状態で再開されます。

8. サービスが正常に実行されていることを確認するには、pacemaker のステータスを確認します。root ユーザーとしてコントローラーノードにログインし、以下のコマンドを入力します。

   # pcs status

9. Ansible を使用して revert.yml ファイルを実行します。

   ansible-playbook -vv /usr/share/ansible/ \
   neutron-ovn-migration/playbooks/revert.yml \
   -i hosts_for_migration

10. ovn-router が環境ファイルまたはテンプレートの NeutronServicePlugins または NeutronPluginExtensions の値として表示される場合は、その値 (ovn-router) を router に置き換えます。パラメーターは複数のファイルに表示される場合があります。たとえば、そのようなファイルの 1 つは tripleo-heat templates/environments/services/neutron-ovn-dvr-ha.yaml です。

    parameter_defaults:
    NeutronServicePlugins: "router,trunk,qos,placement"

11. OVS テンプレートを使用するようにオーバークラウドを更新します。

    bash ~/overcloud-revert-ovs.sh

12. 元の ML2/OVS デプロイメントにトランクポートを使用するインスタンスが含まれていた場合は、次のコマンドを実行してそれらのインスタンスへの接続を復元します。

    ansible-playbook -vv /usr/share/ansible/neutron-ovn-migration/playbooks/revert-rewire.yml \
    -i hosts_for_migration