手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. デフォルトのリポジトリーをすべて無効にしてから、必要な Red Hat Enterprise Linux (RHEL) リポジトリーを有効にします。

   [stack@director ~]$ sudo subscription-manager repos --disable=*
   [stack@director ~]$ sudo subscription-manager repos \
   --enable=rhel-8-for-x86_64-baseos-tus-rpms \
   --enable=rhel-8-for-x86_64-appstream-tus-rpms \
   --enable=rhel-8-for-x86_64-highavailability-tus-rpms \
   --enable=openstack-17.1-for-rhel-8-x86_64-rpms \
   --enable=fast-datapath-for-rhel-8-x86_64-rpms

3. すべてのノードで container-tools モジュールのバージョンを RHEL 8 に切り替えます。

   [stack@director ~]$ sudo dnf -y module switch-to container-tools:rhel8

4. director のインストールと設定を行うためのコマンドラインツールをインストールします。

   [stack@director ~]$ sudo dnf install -y python3-tripleoclient

手順

1. アンダークラウドホストに stack ユーザーとしてログインします。

2. stackrc アンダークラウド認証情報ファイルを入手します。

   $ source ~/stackrc

3. /var/lib/mistral/.ssh ディレクトリーのパーミッションを調整します。

   $ sudo chmod +x /var/lib/mistral/.ssh/

4. 検証用にパッケージをインストールします。

   $ sudo dnf -y update openstack-tripleo-validations python3-validations-libs validations-common

5. mistral からインベントリーをコピーします。

   $ sudo chown stack:stack /var/lib/mistral/.ssh/tripleo-admin-rsa
   $ sudo cat /var/lib/mistral/<stack>/tripleo-ansible-inventory.yaml > inventory.yaml

   • <stack> をスタックの名前に置き換えます。

6. 検証を実行します。

   $ validation run -i inventory.yaml --group pre-upgrade

7. スクリプトの出力を確認し、成功した検証と失敗した検証を確認します。

   === Running validation: "check-ftype" ===
   
   Success! The validation passed for all hosts:
   * undercloud

手順

1. アンダークラウドホストに stack ユーザーとしてログインします。

2. オプション: 16.2 containers-prepare-parameter.yaml ファイルをバックアップします。

   $ cp containers-prepare-parameter.yaml \
     containers-prepare-parameter.yaml.orig

3. デフォルトのコンテナーイメージ準備ファイルを生成します。

   $ openstack tripleo container image prepare default \
     --local-push-destination \
     --output-env-file containers-prepare-parameter.yaml

   上記のコマンドでは、以下の追加オプションを使用しています。

   • --local-push-destination: コンテナーイメージの保管場所として、アンダークラウド上のレジストリーを設定します。つまり、director は必要なイメージを Red Hat Container Catalog からプルし、それをアンダークラウド上のレジストリーにプッシュします。director はこのレジストリーをコンテナーイメージのソースとして使用します。Red Hat Container Catalog から直接プルする場合には、このオプションを省略します。

   • --output-env-file: 環境ファイルの名前です。このファイルには、コンテナーイメージを準備するためのパラメーターが含まれます。ここでは、ファイル名は containers-prepare-parameter.yaml です。

     注記

     アンダークラウドとオーバークラウド両方のコンテナーイメージのソースを定義するのに、同じ containers-prepare-parameter.yaml ファイルを使用することができます。

4. 要件に合わせて containers-prepare-parameter.yaml を変更します。コンテナーイメージのパラメーターに関する詳細は、コンテナーイメージ準備のパラメーター を参照してください。

5. デプロイメントに Red Hat Ceph Storage が含まれている場合は、デプロイメントで使用する Red Hat Ceph Storage のバージョンに応じて containers-prepare-parameter.yaml ファイル内の Red Hat Ceph Storage コンテナーイメージパラメーターを更新します。

   ceph_namespace: registry.redhat.io/rhceph
   ceph_image: <ceph_image_file>
   ceph_tag: latest
   ceph_grafana_image: <grafana_image_file>
   ceph_grafana_namespace: registry.redhat.io/rhceph
   ceph_grafana_tag: latest

   • <ceph_image_file> は、デプロイメントで使用する Red Hat Ceph Storage のバージョンのイメージファイルの名前に置き換えます。

     • Red Hat Ceph Storage 5: rhceph-5-rhel8
     • Red Hat Ceph Storage 6: rhceph-6-rhel9

   • <grafana_image_file> をデプロイメントで使用する Red Hat Ceph Storage のバージョンのイメージファイルの名前に置き換えます。

     • Red Hat Ceph Storage 5: rhceph-5-dashboard-rhel8
     • Red Hat Ceph Storage 6: rhceph-6-dashboard-rhel9

手順

1. アンダークラウドホストに stack ユーザーとしてログインします。

2. skip_rhel_release.yaml というファイルを作成し、SkipRhelEnforcement パラメーターを true に設定します。

   parameter_defaults:
     SkipRhelEnforcement: true

3. undercloud.conf ファイルを開き、ファイルの DEFAULT セクションに、以下のパラメーターを追加します。

   container_images_file = /home/stack/containers-prepare-parameter.yaml
   custom_env_files = /home/stack/skip_rhel_release.yaml

   • 追加のカスタム環境ファイルを custom_env_files パラメーターに追加します。

     custom_env_files パラメーターは、アップグレードに必要な skip_rhel_release.yaml ファイルの場所を定義します。

   • container_images_file パラメーターは、director が正しい場所からアンダークラウドのコンテナーイメージをプルできるように、containers-prepare-parameter.yaml 環境ファイルの場所を定義します。
4. ファイル内の他のすべてのパラメーターが変更されていないか確認します。
5. ファイルを保存します。

手順

1. アンダークラウドホストに stack ユーザーとしてログインします。

2. stackrc アンダークラウド認証情報ファイルを入手します。

   $ source ~/stackrc

3. コントローラーノードにログインし、Pacemaker コマンドを実行してフェンシングを無効にします。

   $ ssh tripleo-admin@<controller_ip> "sudo pcs property set stonith-enabled=false"

   • <controller_ip> を、コントローラーノードの IP アドレスに置き換えます。コントローラーノードの IP アドレスは、metalsmith list コマンドで確認できます。
4. fencing.yaml環境ファイルで、EnableFencingパラメーターをfalseに設定し、アップグレードプロセス中にフェンシングが無効のままとなるようにします。

手順

1. 環境ファイルを選択して、ExtraConfig パラメーターが設定されているかどうかを確認します。

   $ grep ExtraConfig ~/templates/custom-config.yaml

2. このコマンドの結果に、選択したファイル内のいずれかのロールの ExtraConfig パラメーター (例: ControllerExtraConfig) が表示される場合には、そのファイルの完全なパラメーター構造を確認してください。

3. SECTION/parameter 構文で value が続くいずれかの Puppet hieradata がパラメーターに含まれている場合には、実際の Puppet クラスのパラメーターに置き換えられている可能性があります。以下に例を示します。

   parameter_defaults:
     ExtraConfig:
       neutron::config::dhcp_agent_config:
         'DEFAULT/dnsmasq_local_resolv':
           value: 'true'

4. director の Puppet モジュールを確認して、パラメーターが Puppet クラス内に存在しているかどうかを確認します。以下に例を示します。

   $ grep dnsmasq_local_resolv

   その場合には、新規インターフェイスに変更します。

5. 構文の変更の実例を以下に示します。

   • 例 1:

     parameter_defaults:
       ExtraConfig:
         neutron::config::dhcp_agent_config:
           'DEFAULT/dnsmasq_local_resolv':
             value: 'true'

     変更後

     parameter_defaults:
       ExtraConfig:
         neutron::agents::dhcp::dnsmasq_local_resolv: true

   • 例 2:

     parameter_defaults:
       ExtraConfig:
         ceilometer::config::ceilometer_config:
           'oslo_messaging_rabbit/rabbit_qos_prefetch_count':
             value: '32'

     変更後

     parameter_defaults:
       ExtraConfig:
         oslo::messaging::rabbit::rabbit_qos_prefetch_count: '32'

手順

1. Ceph 5 Tools リポジトリーを有効化します。

   [stack@director ~]$ sudo subscription-manager repos --enable=rhceph-5-tools-for-rhel-8-x86_64-rpms

2. ceph-ansible パッケージをインストールします。

   [stack@director ~]$ sudo dnf update -y ceph-ansible

手順

1. アンダークラウドホストに stack ユーザーとしてログインします。

2. stackrc アンダークラウド認証情報ファイルを入手します。

   $ source ~/stackrc

3. ceph タグを使用して、Red Hat Ceph Storage の外部アップグレードプロセスを実行します。

   $ openstack overcloud external-upgrade run \
      --skip-tags "ceph_health,opendev-validation, ceph_ansible_remote_tmp" \
      --stack <stack> \
      --tags ceph,facts 2>&1

   • <stack> をスタックの名前に置き換えます。

4. ceph-admin ユーザーを作成し、適切なキーリングを配布します。

   ANSIBLE_LOG_PATH=/home/stack/cephadm_enable_user_key.log \
   ANSIBLE_HOST_KEY_CHECKING=false \
   ansible-playbook -i /home/stack/overcloud-deploy/<stack>/config-download/<stack>/tripleo-ansible-inventory.yaml \
     -b -e ansible_python_interpreter=/usr/libexec/platform-python /usr/share/ansible/tripleo-playbooks/ceph-admin-user-playbook.yml \
    -e tripleo_admin_user=ceph-admin \
    -e distribute_private_key=true \
     --limit ceph_osd,ceph_mon,Undercloud

5. Red Hat Ceph Storage ノード上のパッケージを更新します。

   $ openstack overcloud upgrade run \
       --stack <stack> \
       --skip-tags ceph_health,opendev-validation,ceph_ansible_remote_tmp \
       --tags setup_packages --limit ceph_osd,ceph_mon,Undercloud \
       --playbook /home/stack/overcloud-deploy/<stack>/config-download/<stack>/upgrade_steps_playbook.yaml 2>&1

   注記

   Ceph Monitor サービス (CephMon) はコントローラーノード上で実行されます。このコマンドには ceph_mon タグが含まれており、これはコントローラーノード上のパッケージも更新します。

6. cephadm を使用するように Red Hat Ceph Storage ノードを設定します。

   $ openstack overcloud external-upgrade run \
       --skip-tags ceph_health,opendev-validation,ceph_ansible_remote_tmp \
       --stack <stack> \
       --tags cephadm_adopt  2>&1

7. overcloud_upgrade_prepare.sh ファイルを変更して、ceph-ansible ファイルを cephadm heat 環境ファイルに置き換えます。

   #!/bin/bash
   openstack overcloud upgrade prepare  --yes \
     --timeout 460 \
    --templates /usr/share/openstack-tripleo-heat-templates \
     --ntp-server 192.168.24.1 \
     --stack <stack> \
     -r /home/stack/roles_data.yaml \
     -e /home/stack/templates/internal.yaml \
     …
     -e /usr/share/openstack-tripleo-heat-templates/environments/cephadm/cephadm-rbd-only.yaml \
     -e ~/containers-prepare-parameter.yaml

   注記

   この例では、RGW がデプロイされていないため、environments/cephadm/cephadm-rbd-only.yaml ファイルを使用します。RGW のデプロイを計画している場合は、RHOSP 環境のアップグレードが完了した後に environments/cephadm/cephadm.yaml を使用し、スタックの更新を実行します。

8. オーバークラウドのアップグレード準備用のコマンドを実行した際に以下の環境ファイルを追加した場合は、overcloud_upgrade_prepare.sh ファイルを変更してこの環境ファイルを削除します。

   -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/manila-cephfsganesha-config.yaml

9. ファイルを保存します。

10. upgrade prepare コマンドを実行します。

    $ source stackrc
    $ chmod 755 /home/stack/overcloud_upgrade_prepare.sh
    sh /home/stack/overcloud_upgrade_prepare.sh

11. デプロイメントに HCI ノードが含まれている場合は、コントローラーノードの cephadm コンテナーに一時的な hci.conf ファイルを作成します。

    1. コントローラーノードにログインします。

       $ ssh cloud-admin@<controller_ip>

       • <controller_ip> をコントローラーノードの IP アドレスに置き換えます。

    2. コントローラーノードから cephadm シェルを取得します。

       例

       [cloud-admin@controller-0 ~]$ sudo cephadm shell

    3. cephadm シェルで、一時的な hci.conf ファイルを作成します。

       例

       [ceph: root@edpm-controller-0 /]# cat <<EOF > hci.conf
       [osd]
       osd_memory_target_autotune = true
       osd_numa_auto_affinity = true
       [mgr]
       mgr/cephadm/autotune_memory_target_ratio = 0.2
       EOF
       …​

    4. 設定を適用します。

       例

       [ceph: root@edpm-controller-0 /]# ceph config assimilate-conf -i hci.conf

       HCI デプロイメントの設定を調整する方法の詳細は、ハイパーコンバージドインフラストラクチャーのデプロイ の HCI の Ceph 設定オーバーライド を 参照してください。

手順

1. アンダークラウドホストに stack ユーザーとしてログインします。

2. stackrc アンダークラウド認証情報ファイルを入手します。

   $ source ~/stackrc

3. メインスタック内のすべてのノードで RHOSP をアップグレードします。

   $ openstack overcloud upgrade run --yes --stack <stack> --debug --limit allovercloud,undercloud --playbook all

   • <stack> をノードをアップグレードするオーバークラウドスタックの名前に置き換えます。

     RHOSP デプロイメント内のスタックごとにこの手順を繰り返します。

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. /etc/ssh/sshd_config ファイルに PermitRootLogin パラメーターがあるかどうかを確認します。

   $ sudo grep PermitRootLogin /etc/ssh/sshd_config

3. /etc/ssh/sshd_config ファイルにパラメーターがない場合は、ファイルを編集して PermitRootLogin パラメーターを設定します。

   PermitRootLogin no

4. ファイルを保存します。

手順

1. SSH キーのサイズを検証します。

   ssh-keygen -l -f ~/.ssh/id_rsa.pub

   出力例:

   1024 SHA256:Xqz0Xz0/aJua6B3qRD7VsLr6n/V3zhmnGSkcFR6FlJw stack@director.example.local (RSA)

2. SSH キーが 2048 ビット未満の場合は、続行する前に ssh_key_rotation.yaml Ansible Playbook を使用して SSH キーを置き換えます。

   ansible-playbook \
   -i ~/overcloud-deploy/<stack>/tripleo-ansible-inventory.yaml \
   /usr/share/ansible/tripleo-playbooks/ssh_key_rotation.yaml \
   --extra-vars "keep_old_key_authorized_keys=<true|false> \ backup_folder_path=</path/to/backup_folder>"

   • <stack> をオーバークラウドスタックの名前に置き換えます。
   • バックアップのニーズに基づいて <true|false> を置き換えます。この変数を含めない場合、デフォルト値は true になります。
   • </path/to/backup_folder> をバックアップパスに置き換えます。この変数を含めない場合、デフォルト値は /home/{{ ansible_user_id }}/backup_keys/{{ ansible_date_time.epoch }} になります。

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. テンプレートディレクトリーに system_upgrade.yaml という名前のファイルを作成し、以下の内容を含めます。

   parameter_defaults:
     UpgradeLeappDevelSkip: "LEAPP_UNSUPPORTED=1 LEAPP_DEVEL_SKIP_CHECK_OS_RELEASE=1 LEAPP_NO_NETWORK_RENAMING=1 LEAPP_DEVEL_TARGET_RELEASE=9.2"
     UpgradeLeappDebug: false
     UpgradeLeappEnabled: true
     LeappActorsToRemove: ['checkifcfg','persistentnetnamesdisable','checkinstalledkernels','biosdevname']
     LeappRepoInitCommand: |
        subscription-manager repos --disable=*
        subscription-manager repos --enable rhel-8-for-x86_64-baseos-tus-rpms --enable rhel-8-for-x86_64-appstream-tus-rpms --enable openstack-17.1-for-rhel-8-x86_64-rpms
        subscription-manager release --set=8.4
     UpgradeLeappCommandOptions: "--enablerepo=rhel-9-for-x86_64-baseos-eus-rpms --enablerepo=rhel-9-for-x86_64-appstream-eus-rpms --enablerepo=rhel-9-for-x86_64-highavailability-eus-rpms --enablerepo=openstack-17.1-for-rhel-9-x86_64-rpms --enablerepo=fast-datapath-for-rhel-9-x86_64-rpms"

   注記

   デプロイメントに Red Hat Ceph Storage ノードが含まれている場合は、CephLeappRepoInitCommand パラメーターを追加し、Red Hat Ceph Storage ノードのソース OS バージョンを指定する必要があります。以下に例を示します。

   CephLeappRepoInitCommand:
   ...
     subscription-manager release --set=8.6

3. LeappInitCommand パラメーターを system_upgrade.yaml ファイルに追加して、環境に適用される追加の要件を指定します。たとえば、ロールベースのオーバーライドを定義する必要がある場合は、以下のようになります。

     LeappInitCommand: |
       sudo subscription-manager repos --disable=*
       sudo subscription-manager repos
     --enable=rhel-9-for-x86_64-baseos-eus-rpms --enable=rhel-9-for-x86_64-appstream-eus-rpms --enable=rhel-9-for-x86_64-highavailability-eus-rpms --enable=openstack-17.1-for-rhel-9-x86_64-rpms --enable=fast-datapath-for-rhel-9-x86_64-rpms
   
       leapp answer --add --section check_vdo.confirm=True
   
       dnf -y remove irb

4. カーネルベースの NIC 名を使用する場合は、以下のパラメーターを system_upgrade.yaml ファイルに追加して、アップグレードプロセス全体にわたって NIC 名が保持されるようにします。

   parameter_defaults:
     NICsPrefixesToUdev: ['en']
   ...

5. Leapp アップグレードを実行します。

   $ openstack undercloud upgrade --yes --system-upgrade \
   /home/stack/system_upgrade.yaml

   注記

   Leapp アップグレードを再度実行する必要がある場合は、まずリポジトリーを RHEL 8 にリセットする必要があります。

6. アンダークラウドをリブートします。

   $ sudo reboot

手順

1. アンダークラウドホストに stack ユーザーとしてログインします。

2. stackrc アンダークラウド認証情報ファイルを入手します。

   $ source ~/stackrc

3. CONTROL_PLANE_ROLES パラメーターを指定せずに以下のスクリプトを実行します。オーバークラウドアップグレード準備の実行 でコンテナーを準備するために使用した変数を必ず含めてください。

   python3 \
   /usr/share/openstack-tripleo-heat-templates/tools/multi-rhel-container-image-prepare.py \
        ${COMPUTE_ROLES} \
        --enable-multi-rhel \
        --excludes collectd \
        --excludes nova-libvirt \
        --minor-override \
   "{${EL8_TAGS}${EL8_NAMESPACE}${CEPH_TAGS}${NEUTRON_DRIVER}\"no_tag\":\"not_used\"}" \
        --major-override \
        "{${EL9_TAGS}${NAMESPACE}${CEPH_TAGS}${NEUTRON_DRIVER}\"no_tag\":\"not_used\"}" \
        --output-env-file \
   /home/stack/containers-prepare-parameter.yaml

   注記

   CONTROL_PLANE_ROLES パラメーターは、コントロールプレーンロールのリストを定義します。このパラメーターをスクリプトから削除すると、RHEL 9.2 へのアップグレード用のコントロールプレーンロールが準備されます。CONTROL_PLANE_ROLES パラメーターがスクリプトに含まれている場合は、コントロールプレーンのロールは RHEL 8.4 に残ります。

4. skip_rhel_release.yaml ファイルで、SkipRhelEnforcement パラメーターを false に設定します。

   parameter_defaults:
     SkipRhelEnforcement: false

5. overcloud_upgrade_prepare.sh ファイルを更新します。

   $ openstack overcloud upgrade prepare --yes \
       ...
       -e /home/stack/system_upgrade.yaml \
       -e /home/stack/containers-prepare-parameter.yaml \
       -e /home/stack/skip_rhel_release.yaml \
       ...

   • アップグレード固有のパラメーターを持つ system_upgrade.yaml ファイルを含めます (-e)。
   • コントロールプレーンロールを削除した containers-prepare-parameter.yaml ファイルを含めます (-e)。
   • リリースパラメーターを持つ skip_rhel_release.yaml ファイルを含めます (-e)。

6. overcloud_upgrade_prepare.sh スクリプトを実行します。

   $ sh /home/stack/overcloud_upgrade_prepare.sh

7. システムのアップグレードに必要な新しいコンテナーまたは変更されたコンテナーを取得します。

   $ openstack overcloud external-upgrade run  \
        --stack <stack> \
        --tags container_image_prepare 2>&1

8. コントロールプレーンノードの最初の 3 分の 1 をアップグレードします。

   $ openstack overcloud upgrade run --yes \
        --stack <stack> \
        --tags system_upgrade \
        --limit <controller-0>,<database-0>,<messaging-0>,<networker-0>,<ceph-0>

   • <stack> をスタックの名前に置き換えます。
   • <controller-0>、<database-0>、<messaging-0>、<networker-0>、<ceph-0> を独自のノード名に置き換えます。

9. アップグレードされた各ノードにログインし、各ノードのクラスターが実行されていることを確認します。

   $ sudo pcs status

   コントロールプレーンノードの次の 3 分の 1 をアップグレードした後、そしてコントロールプレーンノードの最後の 3 分の 1 をアップグレードした後に、この検証手順を繰り返します。

10. コントロールプレーンノードの次の 3 分の 1 をアップグレードします。

    $ openstack overcloud upgrade run --yes \
         --stack <stack> \
         --tags system_upgrade \
         --limit <controller-1>,<database-1>,<messaging-1>,<networker-1>,<ceph-1>

    • <controller-1>、<database-1>、<messaging-1>、<networker-1>、<ceph-1> を独自のノード名に置き換えます。

11. コントロールプレーンノードの最後の 3 分の 1 をアップグレードします。

    $ openstack overcloud upgrade run --yes \
         --stack <stack> \
         --tags system_upgrade \
         --limit <controller-2>,<database-2>,<messaging-2>,<networker-2>,<ceph-2>

    • <controller-2>、<database-2>、<messaging-2>、<networker-2>、<ceph-2> を独自のノード名に置き換えます。

12. STF を有効にした場合は、タグを指定せずにアップグレードコマンドを実行します。オペレーティングシステムのアップグレード後にこのコマンドを実行して、すべてのノードで collectd コンテナーを更新します。

    $ openstack overcloud upgrade run --yes \
         --stack <stack> \
         --limit <controller-0>,<controller-1>,<controller-2>,<database-0>,<database-1>,<database-2>,<networker-0>,<networker-1>,<networker-2>,<ceph-0>,<ceph-1>,<ceph-2>

    • < controller-0 > , <controller-1 > , <controller-2 > , <database-0 > , <database-1 > , <database-2 > , <networker-0 > , <networker-1 > , <networker-2 > , <ceph-0 > , <ceph-1 > , <ceph-2 > を独自のノード名に置き換えます。

手順

1. アンダークラウドホストに stack ユーザーとしてログインします。

2. stackrc アンダークラウド認証情報ファイルを入手します。

   $ source ~/stackrc

3. container-image-prepare.yaml ファイルには、ContainerImagePrepare パラメーターで指定されたタグのみが含まれ、MultiRhelRoleContainerImagePrepare パラメーターが削除されていることを確認します。以下に例を示します。

   parameter_defaults:
     ContainerImagePrepare:
     - tag_from_label: "{version}-{release}"
       set:
         namespace:
         name_prefix:
         name_suffix:
         tag:
         rhel_containers: false
         neutron_driver: ovn
         ceph_namespace:
         ceph_image:
         ceph_tag:

4. role_data.yaml ファイルで、OS::TripleO::Services::NovaLibvirtLegacy サービスを、RHEL 9.2 に必要な OS::TripleO::Services::NovaLibvirt サービスに置き換えます。

5. 次の例に示すように、-e system_upgrade.yaml 引数と必要なその他の -e 環境ファイル引数を overcloud_upgrade_prepare.sh スクリプトに含めます。

   $ openstack overcloud upgrade prepare --yes
   …​
   -e /home/stack/system_upgrade.yaml
   …​

6. overcloud_upgrade_prepare.sh スクリプトを実行します。

7. コンピュートノード上のオペレーティングシステムを RHEL 9.2 にアップグレードします。アップグレードするノードのコンマ区切りリストを指定して、--limit オプションを使用します。以下の例では、compute-0、compute-1、および compute-2 ノードをアップグレードします。

   $ openstack overcloud upgrade run --yes --tags system_upgrade --stack <stack> --limit compute-0,compute-1,compute-2

   • <stack> をスタックの名前に置き換えます。

8. コンピュートノード上のコンテナーを RHEL 9.2 にアップグレードします。アップグレードするノードのコンマ区切りリストを指定して、--limit オプションを使用します。以下の例では、compute-0、compute-1、および compute-2 ノードをアップグレードします。

   $ openstack overcloud upgrade run --yes --stack <stack>  --limit compute-0,compute-1,compute-2

1. どのノードを RHEL 9.2 にアップグレードするか、そしてどのノードを RHEL 8.4 に残しておきたいかを計画します。ノードのバッチごとに作成する各ロールのロール名を選択します (例: ComputeRHEL-9.2 および ComputeRHEL-8.4)。

2. RHEL 9.2 にアップグレードするノード、または RHEL 8.4 に残しておきたいノードを保存するロールを作成します。これらのロールは、コンピュートノードを新しいロールに移動する準備ができるまで空のままにすることができます。必要な数のロールを作成し、任意の方法でロール間でノードを分割できます。以下に例を示します。

   • 環境で ComputeSRIOV というロールが使用されており、カナリアテストを実行して RHEL 9.2 にアップグレードする必要がある場合は、新しい ComputeSRIOVRHEL9 ロールを作成し、カナリアノードを新しいロールに移動できます。
   • 環境で ComputeOffload というロールを使用しており、そのロール内のほとんどのノードを RHEL 9.2 にアップグレードするが、いくつかのノードを RHEL 8.4 に残しておきたい場合は、新しい ComputeOffloadRHEL8 ロールを作成して RHEL 8.4 ノードを保存できます。その後、元の ComputeOffload ロール内のノードを選択して、RHEL 9.2 にアップグレードできます。
3. ノードを各コンピュートロールから新しいロールに移動します。

4. 特定のコンピュートノード上のオペレーティングシステムを RHEL 9.2 にアップグレードします。同じロールまたは複数のロールから、ノードをバッチでアップグレードできます。

   注記

   Multi-RHEL 環境では、デプロイメントでは引き続き pc-i440fx マシンタイプを使用する必要があります。デフォルトを Q35 に更新しないでください。Q35 マシンタイプへの移行は、すべてのコンピュートノードを RHEL 9.2 にアップグレードした後に実行する、別のアップグレード後の手順です。Q35 マシンタイプの移行に関する詳細は、RHOSP 17 へのアップグレード後のホストのデフォルトマシンタイプの更新 を参照してください。

   次の手順を使用して、コンピュートノードを Multi-RHEL 環境にアップグレードします。

   • Multi-RHEL コンピュートノードのロールの作成
   • コンピュートノードのオペレーティングシステムのアップグレード

手順

1. stack ユーザーのホーム下の images ディレクトリー (/home/stack/images) から既存のイメージを削除します。

   $ rm -rf ~/images/*

2. アーカイブをデプロイメントします。

   $ cd ~/images
   $ for i in /usr/share/rhosp-director-images/overcloud-full-latest-17.1.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-17.1.tar; do tar -xvf $i; done
   $ cd ~

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. コンピュートノードが同時マルチスレッド (SMT) をサポートするが hw:cpu_thread_policy=isolated ポリシーでインスタンスを作成している場合は、以下のオプションのいずれかを実施する必要があります。

   • hw:cpu_thread_policy スレッドポリシーを設定しない新しいフレーバーを作成し、そのフレーバーでインスタンスのサイズを変更します。

     1. source コマンドでオーバークラウドの認証ファイルを読み込みます。

        $ source ~/overcloudrc

     2. デフォルトのスレッドポリシー prefer を使用してフレーバーを作成します。

        (overcloud) $ openstack flavor create <flavor>

        注記

        インスタンスのサイズを変更する場合は、新しいフレーバーを使用する必要があります。現在のフレーバーを再利用することはできません。詳細は、インスタンスの作成と管理 ガイドの インスタンスのサイズ変更 を参照してください。

     3. 新しいフレーバーを使用するようにインスタンスを変換します。

        (overcloud) $ openstack server resize --flavor <flavor> <server>
        (overcloud) $ openstack server resize confirm <server>

     4. hw:cpu_thread_policy=isolated ポリシーを使用するすべての固定インスタンスに対して、このステップを繰り返します。

   • コンピュートノードからインスタンスを移行して、コンピュートノードの SMT を無効にする。

     1. source コマンドでオーバークラウドの認証ファイルを読み込みます。

        $ source ~/overcloudrc

     2. コンピュートノードが新しい仮想マシンを受け入れるのを無効にします。

        (overcloud) $ openstack compute service list
        (overcloud) $ openstack compute service set <hostname> nova-compute --disable

     3. コンピュートノードからすべてのインスタンスを移行します。インスタンスの移行に関する詳細は、コンピュートノード間の仮想マシンインスタンスの移行 を参照してください。
     4. コンピュートノードをリブートし、コンピュートノードの BIOS で SMT を無効にします。
     5. コンピュートノードをブートします。

     6. コンピュートノードを再度有効にします。

        (overcloud) $ openstack compute service set <hostname> nova-compute --enable

3. stackrc ファイルを取得します。

   $ source ~/stackrc

4. NovaVcpuPinSet パラメーターが含まれる環境ファイルを編集します。

5. CPU ピニングの設定を NovaVcpuPinSet パラメーターから NovaComputeCpuDedicatedSet と NovaComputeCpuSharedSet に移行します。

   • これまでピニングされたインスタンス用に使用されていたホストの場合には、NovaVcpuPinSet の値を NovaComputeCpuDedicatedSet に変更します。
   • これまでピニングされていないインスタンス用に使用されていたホストの場合には、NovaVcpuPinSet の値を NovaComputeCpuSharedSet に変更します。
   • NovaVcpuPinSet の値が設定されていない場合には、ノード上でホストするインスタンスの種別に応じて、すべてのコンピュートノードのコアを NovaComputeCpuDedicatedSet または NovaComputeCpuSharedSet のどちらかに割り当てる必要があります。

   たとえば、以前の環境ファイルに以下のピニング設定が定義されていたとします。

   parameter_defaults:
     ...
     NovaVcpuPinSet: 1,2,3,5,6,7
     ...

   設定をピニング設定に移行するには、NovaCompute CpuDedicatedSet パラメーターを設定し、NovaVcpuPinSet パラメーターの設定を解除します。

   parameter_defaults:
     ...
     NovaComputeCpuDedicatedSet: 1,2,3,5,6,7
     NovaVcpuPinSet: ""
     ...

   設定をピニングしない設定に移行するには、NovaComputeCpuSharedSet パラメーターを設定し、NovaVcpuPinSet パラメーターの設定を解除します。

   parameter_defaults:
     ...
     NovaComputeCpuSharedSet: 1,2,3,5,6,7
     NovaVcpuPinSet: ""
     ...

   重要

   NovaComputeCpuDedicatedSet または NovaComputeCpuSharedSet のいずれかが、NovaVcpuPinSet で定義した設定と一致するようにします。NovaComputeCpuDedicatedSet または NovaComputeCpuSharedSet のいずれかの設定を変更する、またはその両方を設定するには、設定を更新する前にピニング設定のコンピュートノードが 1 つのインスタンスも実行していないようにします。

6. ファイルを保存します。

7. デプロイメントコマンドを実行して、新しい CPU ピニングパラメーターでオーバークラウドを更新します。

   (undercloud) $ openstack overcloud deploy \
       --stack _STACK NAME_ \
       --templates \
       ...
       -e /home/stack/templates/<compute_environment_file>.yaml
       ...

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. source コマンドで stackrc ファイルを読み込みます。

   $ source ~/stackrc

3. コントローラーノードに heat-admin ユーザーとしてログインします。

   (undercloud)$ metalsmith list
   $ ssh heat-admin@<controller_ip>

   <controller_ip> をコントローラーノードの IP アドレスに置き換えます。

4. マシンタイプが設定されていないインスタンスのリストを取得します。

   [heat-admin@<controller_ip> ~]$ sudo podman exec -i -u root nova_api \
     nova-manage libvirt list_unset_machine_type

5. インスタンスホストのデフォルトのマシンタイプについては、nova-hw-machine-type-upgrade.yaml ファイルの NovaHWMachineType パラメーターを確認します。RHOSP 16.2 の NovaHWMachineType パラメーターのデフォルト値は次のとおりです。

   x86_64=pc-i440fx-rhel7.6.0,aarch64=virt-rhel7.6.0,ppc64=pseries-rhel7.6.0,ppc64le=pseries-rhel7.6.0

6. 各インスタンスのシステムメタデータをデフォルトのインスタンスマシンタイプで更新します。

   [heat-admin@<controller_ip> ~]$ sudo podman exec -i -u root nova_api \
     nova-manage libvirt update_machine_type <instance_uuid> <machine_type>

   • <instance_uuid> をインスタンスの UUID に置き換えます。
   • <machine_type> をインスタンスを記録するマシンタイプに置き換えます。

7. すべてのインスタンスのマシンタイプが記録されていることを確認します。

   [heat-admin@<controller_ip> ~]$ sudo podman exec -i -u root nova_api \
     nova-status upgrade check

   このコマンドは、マシンタイプのないインスタンスが見つかった場合に警告を返します。この警告が表示された場合は、手順 4 からこの手順を繰り返します。

8. コンピュート環境ファイルの NovaHWMachineType のデフォルト値を x86_64=q35 に変更し、オーバークラウドをデプロイします。

検証

1. デフォルトのマシンタイプを持つインスタンスを作成します。

   (overcloud)$ openstack server create --flavor <flavor> \
     --image <image> --network <network> \
     --wait defaultMachineTypeInstance

   • <flavor> をインスタンスのフレーバーの名前または ID に置き換えます。
   • <image> を hw_machine_type を設定しないイメージの名前または ID に置き換えます。
   • <network> をインスタンスの接続先となるネットワークの名前または ID に置き換えます。

2. インスタンスのマシンタイプがデフォルト値に設定されていることを確認します。

   [heat-admin@<controller_ip> ~]$ sudo podman exec -i -u root nova_api \
     nova-manage libvirt get_machine_type <instance_uuid>

   <instance_uuid> をインスタンスの UUID に置き換えます。

3. マシンタイプ x86_64=pc-i440fx のインスタンスをハードリブートします。

   (overcloud)$ openstack server reboot --hard <instance_uuid>

   <instance_uuid> をインスタンスの UUID に置き換えます。

4. インスタンスのマシンタイプが変更されていないことを確認します。

   [heat-admin@<controller_ip> ~]$ sudo podman exec -i -u root nova_api \
     nova-manage libvirt get_machine_type <instance_uuid>

   <instance_uuid> をインスタンスの UUID に置き換えます。

手順

1. アンダークラウドホストに stack ユーザーとしてログインします。

2. stackrc アンダークラウド認証情報ファイルを入手します。

   $ source ~/stackrc

3. コントローラーノードにログインし、Pacemaker コマンドを実行してフェンシングを再度有効にします。

   $ ssh tripleo-admin@<controller_ip> "sudo pcs property set stonith-enabled=true"

   • <controller_ip> を、コントローラーノードの IP アドレスに置き換えます。コントローラーノードの IP アドレスは、openstack server list コマンドで確認できます。
4. fencing.yaml 環境ファイルで、EnableFencing パラメーターを true に設定します。