16.2 から 17.1 へのアップグレードフレームワーク

手順

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

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 のバージョンのイメージファイルの名前に置き換えます。

     • director でデプロイされた Red Hat Ceph Storage を使用する場合は、< ceph_image_file > を rhceph-5-rhel8 に置き換えます。
     • 外部の Red Hat Ceph Storage を使用する場合は、< ceph_image_file > を、Red Hat Ceph Storage 環境が使用するのと同じ Ceph イメージに置き換えます。たとえば、Red Hat Ceph Storage 6 イメージの場合は rhceph-6-rhel9 を使用します。

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

     • director でデプロイされた Red Hat Ceph Storage を使用する場合は、rhceph-5-dashboard-rhel8 に置き換え てください。
     • 外部の Red Hat Ceph Storage を使用する場合は、Red Hat Ceph Storage 環境が使用する Ceph イメージと同じ Ceph イメージに置き換え ます。たとえば、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 環境ファイルの場所を定義します。

     注記

     元の undercloud.conf ファイルの /home/stack/custom-kerberos-params.yaml ファイルに CertmongerKerberosRealm パラメーターが含まれている場合は、CertmongerKerberosRealm パラメーターを HAProxyCertificatePrincipal パラメーターに置き換える必要があります。CertmongerKerberosRealm パラメーターが原因で、アンダークラウドのアップグレードに失敗します。

4. ファイル内の他のすべてのパラメーターが変更されていないか確認します。
5. ファイルを保存します。

手順

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

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

   $ source ~/stackrc

3. 次のコマンドに environment/ceph-ansible/ceph-ansible-external.yaml ファイルを含めた場合は、そのファイルを environment/external-ceph.yaml ファイルに置き換える必要があります。

   • openstack overcloud upgrade prepare

   • openstack overcloud deploy

     たとえば、以下のように指定したとします。

     $ openstack overcloud deploy
     ...
     -e environments/ceph-ansible/ceph-ansible-external.yaml
     ...

     以下に置き換えます。

     $ openstack overcloud deploy
     ...
     -e environments/external-ceph.yaml
     ...

4. ceph_params.yaml というファイルを作成し、次の内容を含めます。

   parameter_defaults:
     CephClusterFSID: <fsid>
     CephClientKey: <key>
     CephExternalMonHost: <mon ip addresses>
     CephSpecFqdn: <true/false>
     CephConfigPath: "/etc/ceph"
     DeployedCeph: false
     GrafanaPlugins: []

   • <fsid> は、Red Hat Ceph Storage クラスターの UUID に置き換えます。
   • <key> は、Ceph クライアントキーに置き換えます。
   • <mon ip address> は、Ceph Mon Host IP のリストに置き換えます。

   • <true/false> は、環境に応じて適切な値に置き換えます。

     注記

     Red Hat Ceph Storage デプロイメントに短縮名が含まれている場合は、CephSpecFqdn パラメーターを false に設定する必要があります。true に設定すると、短縮名とドメイン名の両方を使用してインベントリーが生成されるため、Red Hat Ceph Storage のアップグレードが失敗します。

5. オーバークラウドのデプロイコマンドに ceph_params.yaml ファイルを含めます。

   $ openstack overcloud deploy \
   ...
   -e ~/environments/ceph_params.yaml \

   重要

   RHOSP のアップグレード完了後に ceph_params.yaml ファイルを削除しないでください。このファイルは外部 Red Hat Ceph Storage 環境に存在する必要があります。さらに、openstack overcloud deploy を実行するときは、-e ceph_params.yaml を指定するなどして、常に ceph_params.yaml ファイルを含める必要があります。

手順

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

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

   $ source ~/stackrc

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

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

   • <controller_ip> は、コントローラーノードの IP アドレスに置き換えます。コントローラーノードの IP アドレスは、/etc/hosts または /var/lib/mistral で確認できます。
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. すべてのノードが ACTIVE 状態にあることを確認します。

   $ openstack baremetal node list

2. いずれかのノードが MAINTENANCE 状態にある場合は、次のコマンドを実行して last_error フィールドを確認し、MAINTENANCE 状態にあるノードの根本原因を特定してトラブルシューティングします。

   $ openstack baremetal node show <node_uuid>

   • <node_uuid> をノードの UUID に置き換えます。

3. MAINTENANCE の状態の設定を解除します。

    $ openstack baremetal node maintenance unset <node_uuid>

   ノードが MAINTENANCE 状態に戻るかどうかを確認するために 3 - 5 分待ちます。

   重要

   いずれかのノードが MAINTENANCE 状態のままの場合、アップグレードを続行できません。ノードを MAINTENANCE から削除できない場合は、Red Hat サポートにお問い合わせください。

手順

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

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

   $ source ~/stackrc

3. アンダークラウドのアップグレード中にエクスポートされた以下のファイルに、オーバークラウドのアップグレードで想定される設定が含まれていることを確認します。~/overcloud-deploy ディレクトリーには以下のファイルがあります。

   • tripleo-<stack>-passwords.yaml
   • tripleo-<stack>-network-data.yaml
   • tripleo-<stack>-virtual-ips.yaml
   • tripleo-<stack>-overcloud-network-environment.yaml

   • tripleo-<stack>-baremetal-deployment.yaml

     • このファイルの HostnameMap の値が現在のオーバークラウドの HostnameMap 値と一致することを確認し、必要に応じて値を修正してください。

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

     注記

     ファイルがアンダークラウドのアップグレード後に生成されなかった場合は、Red Hat サポートにお問い合わせください。

     警告

     Jinja2 のコメントの問題に対応し、アンダークラウドのアップグレード中に convert_v1_net_data.py や convert_heat_nic_config_to_ansible_j2.py などの自動変換ツールで作成された各 nic-config テンプレートから、すべての Jinja2 コメントブロックを削除する必要があります。これらのコメントブロックを削除しないと、スケールアウトノードはプロビジョニングに失敗します。または、network_config_update が true に設定されている場合、コントロールプレーンネットワークが失われる可能性があります。

     {{# NOTE! Custom parameter {} was hard-coded in '
     'the converted template. To parameterize use the '
     '{{role.name}}ExtraGroupVars THT interface and update the '
     'template to use an ansible var. +#}}

   重要

   マルチセル環境をお使いの場合は、マルチセル環境でのオーバークラウドの導入 を参照し、ファイルを各セルスタックにコピーする例を確認してください。

4. メインスタックで、passwords.yaml ファイルを ~/overcloud-deploy/$(<stack>) ディレクトリーにコピーします。環境内の各スタックでこの手順を繰り返します。

   $ cp ~/overcloud-deploy/<stack>/tripleo-<stack>-passwords.yaml ~/overcloud-deploy/<stack>/<stack>-passwords.yaml

5. メインスタックで、network-data.yaml ファイルをスタックユーザーのホームディレクトリーにコピーし、ネットワークをデプロイします。環境内の各スタックでこの手順を繰り返します。

   $ cp ~/overcloud-deploy/<stack>/tripleo-<stack>-network-data.yaml ~/
   $ mkdir ~/overcloud_adopt
   $ openstack overcloud network provision --debug \
   --output /home/stack/overcloud_adopt/generated-networks-deployed.yaml tripleo-<stack>-network-data.yaml

   詳細は、director を使用した Red Hat OpenStack Platform のインストールと管理 の オーバークラウドのプロビジョニングとデプロイ を参照してください。

6. メインスタックで、virtual-ips.yaml ファイルをスタックユーザーのホームディレクトリーにコピーし、ネットワーク VIP をプロビジョニングします。環境内の各スタックでこの手順を繰り返します。

   $ cp ~/overcloud-deploy/<stack>/tripleo-<stack>-virtual-ips.yaml ~/
   $ openstack overcloud network vip provision --debug \
   --stack <stack> --output \
   /home/stack/overcloud_adopt/generated-vip-deployed.yaml tripleo-<stack>-virtual-ips.yaml

7. メインスタックで、overcloud-network-environment.yaml ファイルを stack ユーザーのホームディレクトリーにコピーします。環境内の各スタックでこの手順を繰り返します。

   $ cp ~/overcloud-deploy/<stack>/<stack>-network-environment.yaml ~/overcloud_adopt/<stack>-network-environment.yaml

   注記

   NetworkConfigTemplate パラメーターが生成された .j2 ファイルを指し、overcloud-network-environment.yaml ファイルの resource_registry マッピングを削除していることを確認します。詳細は、Red Hat OpenStack Platform デプロイメントのカスタマイズ の NIC テンプレートの Jinja2 Ansible 形式への手動変換 を 参照してください。

8. メインスタックで、baremetal-deployment.yaml ファイルをスタックユーザーのホームディレクトリーにコピーし、オーバークラウドノードをプロビジョニングします。環境内の各スタックでこの手順を繰り返します。

   $ cp ~/overcloud-deploy/<stack>/tripleo-<stack>-baremetal-deployment.yaml ~/
   $ openstack overcloud node provision --debug --stack <stack> \
   --output /home/stack/overcloud_adopt/baremetal-deployment.yaml \
   tripleo-<stack>-baremetal-deployment.yaml

   注記

   これはオーバークラウド導入の最終ステップです。オーバークラウドの導入が完了するまでに 10 分以上かかる場合は、Red Hat サポートにお問い合わせください。

9. コンテナーを準備するには、以下の手順を実行します。

   1. アンダークラウドのアップグレードに使用した containers-prepare-parameter.yaml ファイルをバックアップします。

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

   2. スクリプトを実行して containers-prepare-parameter.yaml ファイルを更新する前に、以下の環境変数を定義します。

      • NAMESPACE: UBI9 イメージの名前空間。たとえば、NAMESPACE='"namespace":"example.redhat.com:5002",' など。
      • EL8_NAMESPACE: UBI8 イメージの名前空間。
      • NEUTRON_DRIVER: 使用する OpenStack Networking (neutron) コンテナーを定義するために使用するドライバー。元のスタックのデプロイに使用したコンテナーのタイプに設定します。たとえば、OVN ベースのコンテナーを使用するには、NEUTRON_DRIVER='"neutron_driver":"ovn",' に設定します。

      • EL8_TAGS: UBI8 イメージのタグ (例: EL8_TAGS='"tag":"17.1",')。

        • "17.1", は、コンテンツビューで使用するタグに置き換えます。

      • EL9_TAGS: UBI9 イメージのタグ (例: EL9_TAGS='"tag":"17.1",')。

        • "17.1", は、コンテンツビューで使用するタグに置き換えます。

          tag パラメーターの詳細は、Red Hat OpenStack Platform デプロイメントのカスタマイズ の コンテナーイメージ準備のパラメーター を参照してください。

      • CONTROL_PLANE_ROLES: --role オプションを使用したコントロールプレーンロールのリスト (例: --role ControllerOpenstack, --role Database, --role Messaging, --role Networker, --role CephStorage)。環境内のコントロールプレーンのロールのリストを表示するには、以下のコマンドを実行します。

        $ export STACK=<stack> \
        $ sudo awk '/tripleo_role_name/ {print "--role " $2}' \
        /var/lib/mistral/${STACK}/tripleo-ansible-inventory.yaml \
        | grep -vi compute

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

      • COMPUTE_ROLES: --role オプションを使用したコンピュートロールのリスト (--Compute-1 など)。環境内のコンピュートロールのリストを表示するには、以下のコマンドを実行します。

        $ sudo awk '/tripleo_role_name/ {print "--role " $2}' \
        /var/lib/mistral/${STACK}/tripleo-ansible-inventory.yaml \
        | grep -i compute

      • CEPH_OVERRIDE: Red Hat Ceph Storage をデプロイした場合は、Red Hat Ceph Storage 5 コンテナーイメージを指定します。以下に例を示します。

        CEPH_OVERRIDE='"ceph_image":"rhceph-5-rhel8","ceph_tag":"<latest>",'

        • <latest> は、最新の ceph_tag バージョン (5-499 など) に置き換えます。

          以下は、containers-prepare-parameter.yaml ファイル設定の例です。

          NAMESPACE='"namespace":"registry.redhat.io/rhosp-rhel9",'
          EL8_NAMESPACE='"namespace":"registry.redhat.io/rhosp-rhel8",'
          NEUTRON_DRIVER='"neutron_driver":"ovn",'
          EL8_TAGS='"tag":"17.1",'
          EL9_TAGS='"tag":"17.1",'
          CONTROL_PLANE_ROLES="--role Controller"
          COMPUTE_ROLES="--role Compute1 --role Compute2"
          CEPH_TAGS='"ceph_tag":"5",'

   3. 以下のスクリプトを実行して、containers-prepare-parameter.yaml ファイルを更新します。

      警告

      Red Hat Ceph Storage をデプロイした場合は、次のコマンドを実行する前に、CEPH_OVERRIDE 環境変数が正しい値に設定されていることを確認してください。これを行わないと、Red Hat Ceph Storage のアップグレード時に問題が発生します。

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

      multi-rhel-container-image-prepare.py スクリプトは、次のパラメーターをサポートしています。

      --output-env-file

      デフォルトの ContainerImagePrepare 値を含む環境ファイルを書き込みます。

      --local-push-destination

      ローカルレジストリーへのアップロードをトリガーします。

      --enable-registry-login

      コンテナーをプルする前に、システムがリモートレジストリーへのログインを試行できるようにするフラグを有効にします。このフラグは、--local-push-destination が使用されておらず、ターゲットシステムにリモートレジストリーへのネットワーク接続がある場合に使用します。このフラグは、リモートレジストリーへのネットワーク接続がない可能性があるオーバークラウドには使用しないでください。

      --enable-multi-rhel

      multi-rhel を有効にします。

      --excludes

      除外するサービスをリストします。

      --major-override

      メジャーリリースのオーバーライドパラメーターをリストします。

      --minor-override

      マイナーリリースのオーバーライドパラメーターをリストします。

      --role

      ロールのリスト。

      --role-file

      role_data.yaml ファイル。

   4. Red Hat Ceph Storage をデプロイした場合は、containers-prepare-parameter.yaml ファイルを開いて、Red Hat Ceph Storage 5 コンテナーイメージが指定されていること、および Red Hat Ceph Storage 6 コンテナーイメージへの参照がないことを確認します。

10. director でデプロイされた Red Hat Ceph Storage デプロイメントがある場合は、ceph_params.yaml というファイルを作成し、次の内容を含めます。

    parameter_defaults:
      CephSpecFqdn: true
      CephConfigPath: "/etc/ceph"
      CephAnsibleRepo: "rhceph-5-tools-for-rhel-8-x86_64-rpms"
      DeployedCeph: true

    重要

    RHOSP のアップグレード完了後に ceph_params.yaml ファイルを削除しないでください。このファイルは、director でデプロイされた Red Hat Ceph Storage 環境に存在する必要があります。さらに、openstack overcloud deploy を実行するときは、-e ceph_params.yaml を指定するなどして、常に ceph_params.yaml ファイルを含める必要があります。

    注記

    Red Hat Ceph Storage デプロイメントに短縮名が含まれている場合は、CephSpecFqdn パラメーターを false に設定する必要があります。true に設定すると、短縮名とドメイン名の両方を使用してインベントリーが生成され、Red Hat Ceph Storage のアップグレードが失敗します。

11. テンプレートディレクトリーに upgrades-environment.yaml という環境ファイルを作成し、以下の内容を含めます。

    parameter_defaults:
      ExtraConfig:
        nova::workarounds::disable_compute_service_check_for_ffu: true
      DnsServers: ["<dns_servers>"]
      DockerInsecureRegistryAddress: <undercloud_FQDN>
      UpgradeInitCommand: |
        sudo subscription-manager repos --disable=*
          if $( grep -q  9.2  /etc/os-release )
          then
            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
            sudo podman ps | grep -q ceph && subscription-manager repos --enable=rhceph-5-tools-for-rhel-9-x86_64-rpms
            sudo subscription-manager release --set=9.2
          else
            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
            sudo podman ps | grep -q ceph && subscription-manager repos --enable=rhceph-5-tools-for-rhel-8-x86_64-rpms
            sudo subscription-manager release --set=8.4
          fi
    
          if $(sudo podman ps | grep -q ceph )
          then
            sudo dnf -y install cephadm
          fi

    • <dns_servers> を、DNS サーバーの IP アドレスのコンマ区切りのリスト (["10.0.0.36", "10.0.0.37"] など) に置き換えます。

    • <undercloud_FQDN> をアンダークラウドホストの完全修飾ドメイン名 (FQDN) に置き換えます (例: "undercloud-0.ctlplane.redhat.local:8787")。

      環境ファイルで設定できるアップグレードパラメーターに関する詳細は、アップグレードパラメーター を参照してください。

12. アンダークラウドで、テンプレートディレクトリーに overcloud_upgrade_prepare.sh というファイルを作成します。このファイルは、環境内のスタックごとに作成する必要があります。このファイルには、オーバークラウドのデプロイファイルの元の内容と、使用中の環境に関連する環境ファイルが含まれています。以下に例を示します。

    #!/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/services/neutron-ovs.yaml \
      -e /home/stack/templates/network/network-environment.yaml \
      -e /home/stack/templates/inject-trust-anchor.yaml \
      -e /home/stack/templates/hostnames.yml \
      -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
      -e /home/stack/templates/nodes_data.yaml \
      -e /home/stack/templates/debug.yaml \
      -e /home/stack/templates/firstboot.yaml \
      -e /home/stack/templates/upgrades-environment.yaml \
      -e /home/stack/overcloud-params.yaml \
      -e /home/stack/overcloud_adopt/overcloud-network-environment.yaml \
      -e /usr/share/openstack-tripleo-heat-templates/environments/nova-hw-machine-type-upgrade.yaml \
      -e /home/stack/skip_rhel_release.yaml \
      -e ~/containers-prepare-parameter.yaml \
      -e /home/stack/overcloud_adopt/baremetal-deployment.yaml \
      -e /home/stack/overcloud_adopt/generated-networks-deployed.yaml \
      -e /home/stack/overcloud_adopt/generated-vip-deployed.yaml

    注記

    マルチセル環境をお使いの場合は、マルチセル環境でのオーバークラウドの導入 を参照し、セルスタックごとに overcloud_upgrade_prepare.sh ファイルを作成する例を確認してください。

    1. 元の network-environment.yaml ファイル (/home/stack/templates/network/network-environment.yaml) で、OS::TripleO::*::Net::SoftwareConfig を指す resource_registry リソースをすべて削除します。

    2. overcloud_upgrade_prepare.sh ファイルに、環境に関連する以下のオプションを含めます。

       • アップグレード固有のパラメーターを持つ環境ファイル (upgrades-environment.yaml) (-e)
       • 新しいコンテナーイメージの場所を定義した環境ファイル (containers-prepare-parameter.yaml) (-e)。多くの場合、アンダークラウドが使用する環境ファイルと同じファイルです。
       • リリースパラメーター (-e) を持つ環境ファイル (skip_rhel_release.yaml)。
       • デプロイメントに関連するカスタム設定環境ファイル (-e)
       • 該当する場合は、--roles-file を使用してカスタムロール (roles_data) ファイルを指定します。
       • Ceph デプロイメントの場合、Ceph パラメーター (-e) を持つ環境ファイル (ceph_params.yaml)。
       • 該当する場合は、IPA サービス (-e) を持つ環境ファイル (ipa-environment.yaml)。
       • コンポーザブルネットワークを使用している場合は、--network-file を使用して (network_data) ファイルを指定します。

       • オーバークラウドの導入中に生成されたファイル (network-deployed.yaml、vip-deployed.yaml、baremetal-deployment.yaml) (-e)。これらのファイルは、オーバークラウドアップグレード準備スクリプトの最後に配置する必要があります。

         注記

         オーバークラウドのデプロイファイルや overcloud_upgrade_prepare.sh ファイルに network-isolation.yaml ファイルを含めないでください。ネットワークの分離は network_data.yaml ファイルで定義します。

       • カスタムのスタック名を使用する場合は、--stack オプションでその名前を渡します。

         注記

         環境内のすべての RHEL 8 コンピュートノードが RHEL 9 にアップグレードされるまで、テンプレートに nova-hw-machine-type-upgrade.yaml ファイルを含める必要があります。このファイルを除外すると、/var/log/containers/nova ディレクトリーの nova_compute.log にエラーが表示されます。すべての RHEL 8 コンピュートノードを RHEL 9 にアップグレードした後、このファイルを設定から削除してスタックを更新できます。

    3. director でデプロイされた Red Hat Ceph Storage のユースケースでは、アップグレードするデプロイメントで、CephFS NFS を使用する Shared File Systems サービス (manila) を有効にしていた場合、overcloud_upgrade_prepare.sh スクリプトファイルの最後に追加の環境ファイルを指定する必要があります。環境ファイルは、スクリプトの前の方で指定されている別の環境ファイルをオーバーライドするため、スクリプトの最後に追加する必要があります。

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

    4. 外部 Red Hat Ceph Storage のユースケースでは、アップグレードするデプロイメントで、CephFS NFS を使用する Shared File Systems サービス (manila) を有効にしていた場合、overcloud_upgrade_prepare.sh スクリプト内の関連する環境ファイルが tripleo ベースの ceph-nfs ロールを参照することを確認する必要があります。次の環境ファイルが存在する場合は、削除します。

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

       次の環境ファイルを追加します。

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

13. 環境内のスタックごとにアップグレード準備スクリプトを実行します。

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

    注記

    マルチセル環境をお使いの場合は、各セルスタック用に作成した overcloud_upgrade_prepare.sh ファイルごとにスクリプトを実行する必要があります。例については、マルチセル環境でのオーバークラウドの導入 を参照してください。

14. アップグレードの準備が完了するまで待ちます。

15. コンテナーイメージをダウンロードします。

    $ openstack overcloud external-upgrade run --stack <stack> --tags container_image_prepare

1. 各セルスタック用の overcloud_upgrade_prepare.sh ファイルを作成します。オーバークラウドスタックから始めます。
2. セルスタック用に作成して生成した出力ファイルを overcloud_upgrade_prepare.sh ファイルに含めます。各セルスタック固有の環境ファイルを overcloud_upgrade_prepare.sh ファイルに必ず含めてください。
3. 各セルスタック用の overcloud_upgrade_prepare.sh スクリプトを実行します。

手順

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 install -y ceph-ansible

手順

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

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

   $ source ~/stackrc

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

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

   • <stack> は、スタックの名前に置き換えます。
   • DCN がデプロイされたサイトでこのコマンドを実行する場合は、--skip-tags パラメーターに指定されたコンマ区切りの値リストに、skip-tag cleanup_cephansible の値を追加します。

4. ceph versions コマンドを実行して、すべての Red Hat Ceph Storage デーモンがバージョン 5 にアップグレードされたことを確認します。このコマンドは、コントローラーノードでデフォルトでホストされる ceph monitor コンテナーで使用できます。

   重要

   前の手順のコマンドは、ceph-ansible rolling_update.yaml Playbook を実行して、クラスターをバージョン 4 から 5 に更新します。この手順を続行する前に、すべてのデーモンが更新されていることを確認することが重要です。

   次の例は、このコマンドの使用方法と出力を示しています。例に示されているように、デプロイメント内のすべてのデーモンには、パッケージバージョン 16.2.* とキーワード pacific が表示されます。

   $ sudo podman exec ceph-mon-$(hostname -f) ceph versions
   {
       "mon": {
           "ceph version 16.2.10-248.el8cp (0edb63afd9bd3edb333364f2e0031b77e62f4896) pacific (stable)": 3
       },
       "mgr": {
           "ceph version 16.2.10-248.el8cp (0edb63afd9bd3edb333364f2e0031b77e62f4896) pacific (stable)": 3
       },
       "osd": {
           "ceph version 16.2.10-248.el8cp (0edb63afd9bd3edb333364f2e0031b77e62f4896) pacific (stable)": 180
       },
       "mds": {},
       "rgw": {
           "ceph version 16.2.10-248.el8cp (0edb63afd9bd3edb333364f2e0031b77e62f4896) pacific (stable)": 3
       },
       "overall": {
           "ceph version 16.2.10-248.el8cp (0edb63afd9bd3edb333364f2e0031b77e62f4896) pacific (stable)": 189
       }
   }

   注記

   Red Hat Ceph Storage をホストしている任意のサーバー上で sudo podman ps | grep ceph コマンドを実行すると、バージョン 5 のコンテナーが返されるはずです。

5. 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 Undercloud,ceph_mon,ceph_mgr,ceph_rgw,ceph_mds,ceph_nfs,ceph_grafana,ceph_osd

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

   $ openstack overcloud upgrade run \
       --stack <stack> \
       --skip-tags ceph_ansible_remote_tmp \
       --tags setup_packages --limit Undercloud,ceph_mon,ceph_mgr,ceph_rgw,ceph_mds,ceph_nfs,ceph_grafana,ceph_osd \
       --playbook /home/stack/overcloud-deploy/<stack>/config-download/<stack>/upgrade_steps_playbook.yaml 2>&1

   • DCN がデプロイされたサイトでこのコマンドを実行する場合は、--skip-tags パラメーターに指定されたコンマ区切りの値リストに、skip-tag cleanup_cephansible の値を追加します。

     注記

     デフォルトでは、コンポーザブルロール機能を使用して他の場所でホストしていない限り、Ceph Monitor サービス (CephMon) はコントローラーノード上で実行します。このコマンドには ceph_mon タグが含まれており、Ceph Monitor サービスをホストしているノード (デフォルトではコントローラーノード) 上のパッケージも更新されます。

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

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

   • DCN がデプロイされたサイトでこのコマンドを実行する場合は、--skip-tags パラメーターに指定されたコンマ区切りの値リストに、skip-tag cleanup_cephansible の値を追加します。

8. ceph -s コマンドを実行して、すべてのプロセスが Red Hat Ceph Storage オーケストレーターによって管理されていることを確認します。このコマンドは、コントローラーノードでデフォルトでホストされる ceph monitor コンテナーで使用できます。

   重要

   前の手順のコマンドは、ceph-ansible cephadm-adopt.yaml Playbook を実行して、クラスターの今後の管理を ceph-ansible から cephadm および Red Hat Ceph Storage オーケストレーターに移行します。この手順を続行する前に、すべてのプロセスがオーケストレータによって管理されていることを確認することが重要です。

   次の例は、このコマンドの使用方法と出力を示しています。この例で示されているように、cephadm によって管理されていないデーモンは 63 個あります。これは、ceph-ansible cephadm-adopt.yml Playbook の実行に問題があったことを示しています。アップグレードを続行する前に、Red Hat Ceph Storage サポートに連絡してこれらのエラーのトラブルシューティングを行ってください。導入プロセスが正常に完了すると、cephadm によって管理されていない迷子のデーモンに関する警告は表示されなくなります。

   $ sudo cephadm shell -- ceph -s
     cluster:
       id:     f5a40da5-6d88-4315-9bb3-6b16df51d765
       health: HEALTH_WARN
               63 stray daemon(s) not managed by cephadm

9. 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 を使用し、スタックの更新を実行します。

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

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

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

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

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

13. デプロイメントに 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

   重要

   the- limit オプションを変更しないでください。ワークロードが破損しないように、スタックのすべてのノードを一度にアップグレードする必要があります。サポートが必要な場合は、Red Hat サポート にお問い合わせください。

   • <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 /home/stack/overcloud-deploy/overcloud/ssh_private_key

   出力例:

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

2. SSH キーが 2048 ビット未満の場合は、次に進む前に、SSH キーをローテーションする必要があります。詳細は、Red Hat OpenStack Platform の強化 の OpenStack 環境での SSH キーの更新 を参照してください。

手順

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: |
       subscription-manager repos --disable=*
       subscription-manager release --unset
       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

   重要

   RHEL 8 の ruby-irb ディレクトリーと RHEL 9 のシンボリックリンクの間の競合を避けるために、ruby-irb パッケージを削除する必要があります。詳細は、Red Hat ナレッジベースのソリューション leapp upgrade RHEL8 to RHEL9 fails with error "rubygem-irb-1.3.5-160.el9_0.noarch conflicts with file from package ruby-irb-2.5.9-110.module+el8.6.0+15956+aa803fc1.noarch" を参照してください。

   注記

   以前に RHOSP 13.0 以前が実行されていた場合、システムのアップグレード中に、既知の問題により、RHEL 8 エントリーではなく、GRUB に RHEL 7 エントリーが含まれます。回避策を含む詳細は、Red Hat ナレッジベースのソリューション Openstack 16 to 17 FFU - During LEAPP upgrade UEFI systems do not boot due to invalid /boot/grub2/grub.cfg を参照してください。

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_OVERRIDE}${NEUTRON_DRIVER}\"no_tag\":\"not_used\"}" \
        --major-override \
        "{${EL9_TAGS}${NAMESPACE}${CEPH_OVERRIDE}${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 ~

3. イメージを director にインポートします。

   (undercloud) [stack@director images]$ openstack overcloud image upload --image-path /home/stack/images/ --update-existing

   このコマンドは次のタスクを完了します。

   • イメージフォーマットを QCOW から RAW に変換します。
   • イメージのアップロードに関するステータスの最新情報を提供します。

手順

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

2. Compute ノードが同時マルチスレッド (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 ポリシーを使用するすべての固定インスタンスに対して、このステップを繰り返します。

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

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

        $ source ~/overcloudrc

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

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

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

     6. Compute ノードを再度有効にします。

        (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 の値が設定されていない場合には、ノード上でホストするインスタンスの種別に応じて、すべての Compute ノードのコアを NovaComputeCpuDedicatedSet または NovaComputeCpuSharedSet のどちらかに割り当てる必要があります。

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

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

   設定をピニング設定に移行するには、NovaComputeCpuDedicatedSet パラメーターを設定し、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 のいずれかの設定を変更する、またはその両方を設定するには、設定を更新する前にピニング設定の Compute ノードが 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 に設定します。