1. Red Hat OpenStack Platform デプロイメントをバージョン 13 からバージョン 16.2 にアップグレードする前に、Red Hat Ceph Storage クラスターをバージョン 3 からバージョン 4 にアップグレードする必要があります。詳細は、Red Hat Ceph Storage 4 インストールガイドの Red Hat Ceph Storage クラスターのアップグレード を参照してください。
2. Red Hat Ceph Storage クラスターをバージョン 3 からバージョン 4 にアップグレードした後も、Red Hat OpenStack Platform 13 では引き続き RHCSv3 クライアントコンポーネントが実行されている可能性がありますが、これらは RHCSv4 クラスターに対して互換性があります。
3. 13 から 16.2 へのアップグレードフレームワークに記載のアップグレードパスに従うことができます。該当する場合は、この特定のシナリオをサポートする条件ステップを実行する必要があります。条件ステップは、外部の Ceph デプロイメントと共にアップグレードする場合はで始まる箇所です。
4. 外部の Ceph デプロイメントと共にアップグレードする場合は、オーバークラウドのアップグレードプロセスの一部として RHCSv4 ceph-ansible をインストールします。director を使用してデプロイされた Ceph クラスターをアップグレードする場合は、オーバークラウドのアップグレードプロセスの完了後に RHCSv4 ceph-ansible をインストールします。

手順

1. 環境ファイルの parameter_defaults セクションで、DeleteOnRHELUnregistration パラメーターが true に設定されている場合は、パラメーターを false に設定します。
2. openstack overcloud update prepare コマンドを実行します。
3. openstack undercloud upgrade コマンドを実行します。

手順

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

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

   $ source ~/stackrc

3. 以下の内容で、pre-upgrade-validations.sh という名前の bash スクリプトを作成します。

   #!/bin/bash
   for VALIDATION in $(openstack action execution run tripleo.validations.list_validations '{"groups": ["pre-upgrade"]}' | jq ".result[] | .id")
   do
     echo "=== Running validation: $VALIDATION ==="
     STACK_NAME=$(openstack stack list -f value -c 'Stack Name')
     ID=$(openstack workflow execution create -f value -c ID tripleo.validations.v1.run_validation "{\"validation_name\": $VALIDATION, \"plan\": \"$STACK_NAME\"}")
     while [ $(openstack workflow execution show $ID -f value -c State) == "RUNNING" ]
     do
       sleep 1
     done
     echo ""
     openstack workflow execution output show $ID | jq -r ".stdout"
     echo ""
   done

4. スクリプトを実行する権限を追加します。

   $ chmod +x pre-upgrade-validations.sh

5. スクリプトを実行します。

   $ ./pre-upgrade-validations.sh

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

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

手順

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

2. playbook-nics.yaml という名前の Ansible Playbook を作成し、以下のコンテンツを Playbook にコピーします。

   ---
   - name: Rename eth devices
     hosts: all
     become: yes
     vars:
       prefix: "em"
       undercloud_conf: "/home/stack/undercloud.conf"
       osnet_conf: "/etc/os-net-config/config.json"
     tasks:
       - set_fact:
           eth_interfaces: "{{ ansible_interfaces | select('match','eth.*') | list }}"
       - debug:
           msg: "{{ eth_interfaces }}"
       - name: Update udev rules
         lineinfile:
           line: "SUBSYSTEM==\"net\", ACTION==\"add\", DRIVERS==\"?*\", ATTR{address}==\"{{ ansible_facts[item]['perm_macaddress'] | default(ansible_facts[item]['macaddress']) }}\", NAME=\"{{ item|replace('eth',prefix) }}\""
           path: /etc/udev/rules.d/70-rhosp-persistent-net.rules
           create: True
         with_items: "{{ eth_interfaces }}"
       - name: Rename eth files
         block:
           - name: Check that eth files exists
             stat:
               path: /etc/sysconfig/network-scripts/ifcfg-{{ item }}
             register: nic_result
             with_items: "{{ eth_interfaces }}"
           - name: Copy nic files using the new prefix
             copy:
               remote_src: True
               src: "{{ item.stat.path }}"
               dest: "{{ item.stat.path|replace('eth',prefix) }}"
             with_items: "{{ nic_result.results }}"
             when: item.stat.exists
           - name: Edit NAME in new network-script files
             lineinfile:
               regexp: "^NAME=.*"
               line: "NAME={{ item.item|replace('eth',prefix) }}"
               path: "{{ item.stat.path|replace('eth',prefix) }}"
             with_items: "{{ nic_result.results }}"
             when: item.stat.exists
           - name: Edit DEVICE in new network-script files
             lineinfile:
               regexp: "^DEVICE=.*"
               line: "DEVICE={{ item.item|replace('eth',prefix) }}"
               path: "{{ item.stat.path|replace('eth',prefix) }}"
             with_items: "{{ nic_result.results }}"
             when: item.stat.exists
           - name: Backup old eth network-script files
             copy:
               remote_src: True
               src: "{{ item.stat.path }}"
               dest: "{{ item.stat.path }}.bak"
             with_items: "{{ nic_result.results }}"
             when: item.stat.exists
           - name: Remove old eth network-script files
             file:
               path: "{{ item.stat.path }}"
               state: absent
             with_items: "{{ nic_result.results }}"
             when: item.stat.exists
       - name: Rename route files
         block:
           - name: Check that route files exists
             stat:
               path: /etc/sysconfig/network-scripts/route-{{ item }}
             register: route_result
             with_items: "{{ eth_interfaces }}"
           - name: Copy route files using the new prefix
             copy:
               remote_src: True
               src: "{{ item.stat.path }}"
               dest: "{{ item.stat.path|replace('eth',prefix) }}"
             with_items: "{{ route_result.results }}"
             when: item.stat.exists
           - name: Update prefix in route files that use IP command arguments format
             replace:
               regexp: "eth"
               replace: "{{ prefix }}"
               path: "{{ item.stat.path|replace('eth',prefix) }}"
             with_items: "{{ route_result.results }}"
             when: item.stat.exists
           - name: Backup old route files
             copy:
               remote_src: True
               src: "{{ item.stat.path }}"
               dest: "{{ item.stat.path }}.bak"
             with_items: "{{ route_result.results }}"
             when: item.stat.exists
           - name: Remove old route files
             file:
               path: "{{ item.stat.path }}"
               state: absent
             with_items: "{{ route_result.results }}"
             when: item.stat.exists
       - name: Perform a final regex for any remaining eth prefixes in ifcfg files
         block:
           - name: Get a list of all ifcfg files
             find:
               paths: /etc/sysconfig/network-scripts/
               patterns: 'ifcfg-*'
               excludes: '*.bak'
             register: ifcfg_files
           - name: Perform final regex on ifcfg files
             replace:
               path: "{{ item[0].path }}"
               regexp: "{{ item[1] }}"
               replace: "{{ item[1]|replace('eth',prefix) }}"
             with_nested:
               - "{{ ifcfg_files.files }}"
               - "{{ eth_interfaces }}"
       - name: Replace interface name in files referencing old eth interface
         block:
           - name: Check if undercloud.conf exists
             stat:
               path: "{{ undercloud_conf }}"
             register: undercloud_conf_stat
           - name: Replace interface name in undercloud.conf
             replace:
               path: "{{ undercloud_conf }}"
               regexp: 'eth(\d+)'
               replace: "{{ prefix }}\\1"
             when: undercloud_conf_stat.stat.exists
           - name: Check if os-net-config's config.json exists
             stat:
               path: "{{ osnet_conf }}"
             register: osnet_conf_stat
           - name: Replace interface name in config.json
             replace:
               path: "{{ osnet_conf }}"
               regexp: 'eth(\d+)'
               replace: "{{ prefix }}\\1"
             when: osnet_conf_stat.stat.exists
       - name: Patch vlan devices
         block:
           - name: Check that vlan files exists
             stat:
               path: /etc/sysconfig/network-scripts/ifcfg-{{ item }}
             register: nic_result
             when: item.startswith("vlan")
             with_items: "{{ ansible_interfaces }}"
           - name: Backup old vlan network-script files
             copy:
               remote_src: True
               src: "{{ item.stat.path }}"
               dest: "{{ item.stat.path }}.bak"
             when: item.item.startswith("vlan") and item.stat.exists
             with_items: "{{ nic_result.results }}"
           - name: Edit PHYSDEV in new network-script files
             replace:
               path: "{{ item.stat.path }}"
               regexp: "^PHYSDEV=eth"
               replace: "PHYSDEV={{ prefix }}"
             when: item.item.startswith("vlan") and item.stat.exists
             with_items: "{{ nic_result.results }}"

   注記

   この Playbook を使用して、アップグレードプロセスの後半でオーバークラウドの NIC の名前を変更します。

3. アンダークラウドで playbook-nics.yaml Playbook を実行します。

   $ ansible-playbook -c local -i localhost, playbook-nics.yaml

   この Playbook により、新しい NIC の接頭辞が em に設定されます。別の NIC 接頭辞を設定するには、Playbook の実行時に prefix 変数を設定します。

   $ ansible-playbook -c local -i localhost, -e prefix="mynic" ~/playbook-nics.yaml

   NIC の変更は、Leapp によるアップグレードプロセスが完了し、ノードがリブートされた後にのみ適用されます。

手順

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. 有効なハードウェアタイプの最新のリストを確認します。

   $ source ~/stackrc
   $ openstack baremetal driver list --type dynamic

2. 有効ではないハードウェアタイプのドライバーを使用する場合には、undercloud.conf ファイルの enabled_hardware_types パラメーターを使用してそのドライバーを有効にします。

   enabled_hardware_types = ipmi,redfish,idrac

3. ファイルを保存し、アンダークラウドをリフレッシュします。

   $ openstack undercloud install

4. 以下のコマンドを実行します。OLDDRIVER および NEWDRIVER 変数を、実際の電源管理タイプに置き換えてください。

   $ source ~/stackrc
   $ OLDDRIVER="pxe_ipmitool"
   $ NEWDRIVER="ipmi"
   $ for NODE in $(openstack baremetal node list --driver $OLDDRIVER -c UUID -f value) ; do openstack baremetal node set $NODE --driver $NEWDRIVER; done

手順

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

2. アンダークラウド上の主要 OpenStack サービスを無効にします。

   $ sudo systemctl stop 'openstack-*' httpd haproxy mariadb 'rabbitmq*' docker xinetd

3. OpenvSwitch およびアップグレードに必要な特定の Python 2 パッケージは除き、アンダークラウドから主要 OpenStack サービスを削除します。

   $ sudo yum -y remove '*el7ost*' 'galera*' 'haproxy*' \
       httpd 'mysql*' 'pacemaker*' xinetd python-jsonpointer \
       qemu-kvm-common-rhev qemu-img-rhev 'rabbit*' \
       'redis*' \
       -- \
       -'*openvswitch*' -python-docker -python-PyMySQL \
       -python-pysocks -python2-asn1crypto -python2-babel \
       -python2-cffi -python2-cryptography -python2-dateutil \
       -python2-idna -python2-ipaddress -python2-jinja2 \
       -python2-jsonpatch -python2-markupsafe -python2-pyOpenSSL \
       -python2-requests -python2-six -python2-urllib3 \
       -python-httplib2 -python-passlib -python2-netaddr -ceph-ansible

4. /etc/httpd および /var/lib/docker ディレクトリーからコンテンツを削除します。

   $ sudo rm -rf /etc/httpd /var/lib/docker

手順

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

2. Leapp ユーティリティーと jq をインストールします。

   $ sudo yum install leapp
   $ sudo yum install jq

3. ナレッジベースのアーティクル RHEL 7 から RHEL 8 へのインプレースアップグレード時に Leapp ユーティリティーで必要なデータ に添付されている追加の必須データファイル (RPM パッケージの変更および RPM リポジトリーマッピング) をダウンロードし、それらのファイルを /etc/leapp/files/ ディレクトリーに置きます。

4. Red Hat サブスクリプションを更新します。

   • アンダークラウドの登録に Red Hat カスタマーポータルを使用している場合、現在のサブスクリプションをリフレッシュし、Red Hat Enterprise Linux 8.4 コンテンツへのアクセス権限を取得します。

     $ sudo subscription-manager refresh

   • アンダークラウドの登録に Red Hat Satellite Server を使用している場合は、アンダークラウドを Red Hat OpenStack Platform (RHOSP) 16.2 のアクティベーションキーに関連付けられたコンテンツビューに再登録します。

     $ sudo subscription-manager register --force --org ORG --activationkey ACTIVATION_KEY

     注記

     Red Hat OpenStack Platform 16.2 用に作成するコンテンツビューには、Red Hat Enterprise Linux 8.4 のコンテンツが含まれている必要があります。

5. Red Hat OpenStack Platform 16.2 では、新しいバージョンの Open vSwitch が使用されます。to_remove および to_install トランザクションファイルにより、Open vSwitch のバージョンを置き換えます。

   $ echo 'openvswitch2.11' | sudo tee -a /etc/leapp/transaction/to_remove
   $ echo 'openvswitch2.15' | sudo tee -a /etc/leapp/transaction/to_install

6. to_keep トランザクションファイルを使用して、アップグレードプロセス中に Red Hat Ceph Storage 3 バージョンの ceph-ansible を維持します。

   $ echo 'ceph-ansible' | sudo tee -a /etc/leapp/transaction/to_keep

7. RHEL 8 ではサポートされなくなったカーネルモジュールを調整します。

   $ if [ -f /usr/share/leapp-repository/repositories/system_upgrade/el7toel8/actors/kernel/checkkerneldrivers/files/removed_drivers.txt ]; then
       for module in pata_acpi floppy; do
           sudo sed -i "/^${module}$/d" /usr/share/leapp-repository/repositories/system_upgrade/el7toel8/actors/kernel/checkkerneldrivers/files/removed_drivers.txt
       done
   else
       for module in pata_acpi floppy; do
           jq ". | del(.data[] | select(.driver_name == \"${module}\"))" /etc/leapp/files/device_driver_deprecation_data.json | sudo tee /etc/leapp/files/device_driver_deprecation_data.json_modified
           mv /etc/leapp/files/device_driver_deprecation_data.json_modified /etc/leapp/files/device_driver_deprecation_data.json
       done
   fi

8. pam_pkcs11 モジュールを削除します。

   $ sudo leapp answer --add --section remove_pam_pkcs11_module_check.confirm=True

9. (オプション) TLS-Everywhere アーキテクチャーで環境がデプロイされ、システムでの認証を設定するのに非推奨の authconfig ユーティリティーが使用される場合は、authselect ユーティリティーを使用して RHEL 8 システムを設定します。

   $ sudo leapp answer --add --section authselect_check.confirm=True

   Leapp によるアップグレードプロセス時の認証設定の詳細は、Upgrading from RHEL 7 to RHEL 8の Known issues を参照してください。

10. LEAPP_DEVEL_TARGET_RELEASE および LEAPP_UNSUPPORTED 環境変数を設定して、アップグレードする RHEL 8 マイナーバージョンを指定します。RHOSP 16.2 では、RHEL 8 マイナーバージョンを 8.4 に設定する必要があります。

    $ export LEAPP_UNSUPPORTED=1
    $ export LEAPP_DEVEL_TARGET_RELEASE=8.4

    LEAPP_DEVEL 接頭辞を付けて環境変数を使用する場合は、LEAPP_UNSUPPORTED 環境変数を使用する必要があります。

11. Leapp プロセスから、永続的なネットワーク名のアクターを削除します。

    注記

    Leapp によるアップグレードプロセスを実行する前にネットワークインターフェイス名を変更しない場合、RHEL 8.2 へのアップグレードの完了後にインターフェイス名が変わる可能性があります。ネットワークインターフェイス名の名前変更の詳細については、「予測可能なアンダークラウドノード NIC 名の使用」 を参照してください。

    $ sudo rm -f /usr/share/leapp-repository/repositories/system_upgrade/el7toel8/actors/persistentnetnamesdisable/actor.py

12. Leapp によるアップグレードプロセスを開始します。

    $ sudo -E leapp upgrade --debug --enablerepo rhel-8-for-x86_64-baseos-eus-rpms --enablerepo rhel-8-for-x86_64-appstream-eus-rpms --enablerepo fast-datapath-for-rhel-8-x86_64-rpms --enablerepo ansible-2.9-for-rhel-8-x86_64-rpms

    --enablerepo オプションを使用して、Leapp によるアップグレードプロセス中に有効にするリポジトリーを設定します。特に新しいバージョンの Open vSwitch を使用する場合は、Red Hat OpenStack Platform 16.2 への移行を円滑に行うために、これらのリポジトリーを追加する必要があります。

13. leapp upgrade コマンドが正常に完了するのを待ちます。

14. ルートディレクトリーに空の .autorelabel ファイルを作成します。

    $ sudo touch /.autorelabel

    リブート後、SELinux はこのファイルを検出し、自動的にファイルシステムのラベルを変更します。

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

    $ sudo reboot

16. DNF の設定で定義されているトランザクションの除外対象から、Leapp のパッケージを削除します。

    $ sudo dnf config-manager --save --setopt exclude=''

手順

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

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

   $ source ~/stackrc

3. カスタムテンプレートで BaseTripleoPackages 変数を追加して、デプロイメントに追加のパッケージを含めます。以下に例を示します。

   BaseTripleoPackages:
   - jq
   - lvm2
   - net-snmp
   - openstack-selinux
   - os-net-config
   - puppet-tripleo
   - python3-heat-agent*
   - python3-openstackclient

手順

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

2. subscription-manager release コマンドを使用して、アンダークラウドを特定のバージョンにロックします。

   $ sudo subscription-manager release --set=8.4

手順

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

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

   [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=ansible-2.9-for-rhel-8-x86_64-rpms \
   --enable=openstack-16.2-for-rhel-8-x86_64-rpms \
   --enable=fast-datapath-for-rhel-8-x86_64-rpms

   これらのリポジトリーには、director のインストールに必要なパッケージが含まれます。

3. container-tools リポジトリーモジュールをバージョン 3.0 に設定します。

   [stack@director ~]$ sudo dnf module reset container-tools
   [stack@director ~]$ sudo dnf module enable -y container-tools:3.0

4. オペレーティングシステムを同期し、システムパッケージがオペレーティングシステムのバージョンと一致するようにします。

   [stack@director ~]$ sudo dnf distro-sync -y
   [stack@director ~]$ sudo reboot

手順

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

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

手順

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

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

   $ sudo 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 ファイルを使用することができます。

3. 要件に合わせて containers-prepare-parameter.yaml を変更します。

手順

1. アンダークラウドホストに stack ユーザーとしてログインします。
2. containers-prepare-parameter.yaml ファイルを編集します。

3. 遷移コンテナーパラメーターを ContainerImagePrepare パラメーターに 設定します。デプロイメントの種別に応じて、以下のいずれかの方法でパラメーターを設定します。

   • director を使用してデプロイされた Red Hat Ceph Storage クラスターがデプロイメントで使用される場合は、以下のパラメーターを追加します。

     parameter_defaults:
       ContainerImagePrepare:
       - push_destination: true
         set:
           ...
           name_prefix_stein: openstack-
           name_suffix_stein: ''
           namespace_stein: registry.redhat.io/rhosp15-rhel8
           tag_stein: 15.0
           ceph3_namespace: registry.redhat.io/rhceph
           ceph3_tag: latest
           ceph3_image: rhceph-3-rhel7
           ...

     • *_stein パラメーターで定義する Red Hat OpenStack Platform 15 用のコンテナーイメージが、アップグレードプロセスでデータベースの移行に使用されます。
     • ceph3_* パラメーターは、オーバークラウドが使用する現在の Red Hat Ceph Storage コンテナーイメージを定義します。Red Hat Ceph Storage 3 から 4 への移行には、オーバークラウドに ceph3_* および ceph_* 両方のパラメーターが必要です。
     • コンテナーイメージのストレージに Red Hat Satellite Server を使用している場合は、名前空間をご自分の Red Hat Satellite Server 上のイメージの場所に設定します。

   • 外部の Ceph Storage クラスターがデプロイメントで使用される場合は、以下のパラメーターを追加します。

     parameter_defaults:
       ContainerImagePrepare:
       - push_destination: true
         set:
           ...
           name_prefix_stein: openstack-
           name_suffix_stein: ''
           namespace_stein: registry.redhat.io/rhosp15-rhel8
           tag_stein: 15.0
           ceph_namespace: registry.redhat.io/rhceph
           ceph_tag: latest
           ceph_image: rhceph-4-rhel8
           ...

     • *_stein パラメーターで定義する Red Hat OpenStack Platform 15 用のコンテナーイメージが、アップグレードプロセスでデータベースの移行に使用されます。
     • ceph_* パラメーターは、オーバークラウドが使用する現在の Red Hat Ceph Storage 4 コンテナーイメージを定義します。
     • コンテナーイメージのストレージに Red Hat Satellite Server を使用している場合は、名前空間をご自分の Red Hat Satellite Server 上のイメージの場所に設定します。

4. neutron_driver パラメーターを openvswitch に変更します。

   parameter_defaults:
     ContainerImagePrepare:
     - push_destination: true
       set:
         ...
         neutron_driver: openvswitch
         ...

   アップグレードプロセスの全期間中、Open vSwitch との互換性が維持されます。Red Hat OpenStack Platform 16.2 へのアップグレードが完了したら、オーバークラウドを Open vSwitch から Open Virtual Network (OVN) に移行します。

5. containers-prepare-parameter.yaml ファイルを保存します。

手順

1. アンダークラウドホストに stack ユーザーとしてログインします。
2. undercloud.conf ファイルを編集します。

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

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

   director が正しい場所からアンダークラウドのコンテナーイメージをプルできるように、このパラメーターで containers-prepare-parameter.yaml 環境ファイルの場所を定義します。

4. generate_service_certificate パラメーターを確認します。このパラメーターのデフォルト設定は、false から true に変更されます。これにより、アップグレード中にアンダークラウドで SSL/TLS が有効になります。
5. 予測可能な NIC 命名規則に移行している場合は、local_interface パラメーターを確認してください。
6. Red Hat OpenStack Platform 13 で masquerade_network パラメーターを設定した場合には、このパラメーターを削除して、サブネットごとに masquerade = true を設定します。
7. ファイル内の他のすべてのパラメーターが変更されていないか確認します。
8. ファイルを保存します。

手順

1. 以下のコマンドを実行して、アンダークラウド上の director をアップグレードします。

   $ openstack undercloud upgrade

   このコマンドにより、director の設定スクリプトが起動します。director によりパッケージがアップグレードされ、undercloud.conf の設定に合わせてサービスが設定されます。このスクリプトは、完了までに数分かかります。

   注記

   director の設定スクリプトでは、次の設定に進む前に確認が求められます。この確認を省略するには、-y オプションを使用します。

   $ openstack undercloud upgrade -y

2. このスクリプトにより、アンダークラウド上の OpenStack Platform サービスのコンテナーも、すべて自動的に起動されます。systemd リソースでそれぞれのサービスを管理します。systemd リソースを確認します。

   $ sudo systemctl list-units "tripleo_*"

   各 systemd サービスでコンテナーを制御します。以下のコマンドを使用して、有効化されたコンテナーを確認してください。

   $ sudo podman ps

3. スクリプトにより stack ユーザーが docker グループに追加され、stack ユーザーがコンテナー管理コマンドを使用できるようになります。以下のコマンドで stack ユーザーのアクセス権限をリフレッシュします。

   $ exec su -l stack

   このコマンドを実行すると、再度ログインが求められます。stack ユーザーのパスワードを入力します。

4. stack ユーザーを初期化してコマンドラインツールを使用するには、以下のコマンドを実行します。

   $ source ~/stackrc

   プロンプトには、OpenStack コマンドがアンダークラウドに対して認証および実行されることが表示されるようになります。

   (undercloud) $

手順

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

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

   $ source ~/stackrc

3. 全ノードの静的なインベントリーファイルを作成します。

   $ tripleo-ansible-inventory --static-yaml-inventory ~/inventory.yaml --stack <STACK_NAME>
    --ansible_ssh_user heat-admin

   デフォルトの overcloud スタック名を使用していない場合は、<STACK NAME> をスタックの名前に置き換えます。

4. お使いの環境で Ansible のPlaybookを実行するには、ansible-playbook コマンドを実行し、-i オプションを使用して動的インベントリーツールの完全パスを追加します。以下に例を示します。

   (undercloud) $ ansible-playbook -i ~/inventory.yaml <PLAYBOOK>

手順

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

   $ source ~/stackrc

2. --group pre-upgrade オプションを指定して openstack tripleo validator run コマンドを実行し、/usr/libexec/platform-python python ランタイム環境を追加します。

   $ openstack tripleo validator run --group pre-upgrade --python-interpreter /usr/libexec/platform-python -i inventory.yaml

   注記

   確認するパッケージのリストが含まれていることを確認してください。コマンドで --extra-vars または --extra-vars-file を使用すると、CLI からリストを提供できます。詳細は、tripleo validator run のコマンド引数 を参照してください。

3. 検証レポートの結果を確認します。特定の検証からの詳細出力を表示するには、レポートからの特定検証の UUID を指定して openstack tripleo validator show run --full コマンドを実行します。

   $ openstack tripleo validator show run  --full <UUID>

手順

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

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

   $ source ~/stackrc

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

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

   <controller_ip> を、コントローラーノードの IP アドレスに置き換えます。コントローラーノードの IP アドレスは、openstack server 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. アンダークラウドに stack ユーザーとしてログインします。

2. templates ディレクトリーに upgrades-environment.yaml という名前の環境ファイルを作成します。

   $ touch templates/upgrades-environment.yaml

3. ファイルを編集し、以下の必須コンテンツを追加します。

   parameter_defaults:
     UpgradeLeappCommandOptions: " --enablerepo rhel-8-for-x86_64-baseos-eus-rpms --enablerepo rhel-8-for-x86_64-appstream-eus-rpms --enablerepo rhel-8-for-x86_64-highavailability-eus-rpms --enablerepo ansible-2.9-for-rhel-8-x86_64-rpms --enablerepo fast-datapath-for-rhel-8-x86_64-rpms "

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

4. upgrades-environment.yaml ファイルを保存します。

手順

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

2. すべてのオーバークラウドノードで playbook-nics.yaml Playbook を実行します。

   $ ansible-playbook -i ~/inventory.yaml playbook-nics.yaml

   この Playbook により、新しい NIC の接頭辞が em に設定されます。別の NIC 接頭辞を設定するには、Playbook の実行時に prefix 変数を設定します。

   $ ansible-playbook -i ~/inventory.yaml -e prefix="mynic" playbook-nics.yaml

   NIC の変更は、Leapp によるアップグレードプロセスが完了し、ノードがリブートされた後にのみ適用されます。

手順

1. コンポーザブルサービスを使用するカスタム環境ファイルを検索します。通常、カスタム環境ファイルは /home/stack/templates ディレクトリーに保存されます。

   $ cd ~/templates/
   $ grep "OS::TripleO::Services" *

   このシナリオでは、ファイルの 1 つに古くなったマッピングがあるとします。

     OS::TripleO::Services::CephMgr: /usr/share/openstack-tripleo-heat-templates/docker/services/ceph-ansible/ceph-mgr.yaml

2. /usr/share/openstack-tripleo-heat-templates/ の新しい ceph-mgr.yaml の場所を特定します。このファイルは、`deployment/ceph-ansible' ディレクトリーに置かれています。

   $ find /usr/share/openstack-tripleo-heat-templates/ -name ceph-mgr.yaml
   /usr/share/openstack-tripleo-heat-templates/deployment/ceph-ansible/ceph-mgr.yaml

3. カスタム環境ファイルでサービスを編集します。

   resource_registry:
     OS::TripleO::Services::CephMgr: /usr/share/openstack-tripleo-heat-templates/deployment/ceph-ansible/ceph-mgr.yaml

   ファイルを保存します。

手順

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

2. アンダークラウドのコントロールプレーンのホスト名を取得します。

   $ sudo hiera container_image_prepare_node_names
   ["undercloud.ctlplane.localdomain"]

3. containers-prepare-parameter.yaml ファイルを編集し、DockerInsecureRegistryAddress パラメーターを追加して、アンダークラウドのコントロールプレーンのホスト名およびプロビジョニングネットワーク上のアンダークラウドの IP アドレスが含まれる YAML のリストを指定します。

   parameter_defaults:
     DockerInsecureRegistryAddress:
     - undercloud.ctlplane.localdomain:8787
     - 192.168.24.1:8787
     ...

   ホスト名および IP アドレスの値に、オーバークラウドレジストリーのポート番号も追加する必要があります。ポート番号は 8787 です。

手順

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

2. Compute の命名形式を設定します。

   • カスタムの roles_data ファイルを使用する場合には、カスタムの roles_data ファイルを編集し、Compute ロールの HostnameFormatDefault パラメーターを設定します。

     - name: Compute
       …​
       HostnameFormatDefault: '%stackname%-compute-%index%'
       …​

     カスタム roles_data ファイルを編集します。

   • openstack-tripleo-heat-templates でデフォルトの roles_data ファイルを使用する場合には、環境ファイルで命名形式を設定します。実際のノード数およびフレーバーに合わせて環境ファイルを編集します。このファイルは、通常 node-info.yaml という名前です。parameter_defaults セクションに ComputeHostnameFormat パラメーターを追加します。

     parameter_defaults:
       …​
       ComputeHostnameFormat: '%stackname%-compute-%index%'
       …​

     node-info.yaml ファイルを保存します。

手順

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

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

   [stack@director ~]$ source ~/stackrc

3. 環境ファイルを開きます。

4. 次の設定を環境ファイルに追加して、インスタンスのシリアル番号がホストのシリアル番号に基づくように指定します。

   parameter_defaults:
     <Role>ExtraConfig:
       nova::compute::libvirt::sysinfo_serial: auto

5. 更新を環境ファイルに保存します。
6. このファイルをオーバークラウドのアップグレードおよびデプロイメントコマンドに追加します。

手順

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

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

   $ source ~/stackrc

3. カスタムのオーバークラウド SSL/TLS パブリックエンドポイントファイルを編集します。通常、このファイルの名前は ~/templates/enable-tls.yaml です。

4. resource_registry から NodeTLSData リソースを削除します。

   resource_registry:
     OS::TripleO::NodeTLSData: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/tls/tls-cert-inject.yaml
     ...

   オーバークラウドデプロイメントは、HAProxy の新しいサービスを使用して SSL/TLS が有効かどうかを判断します。

   注記

   これがenable-tls.yaml ファイルの resource_registry セクションにある唯一のリソースである場合、resource_registry セクションをすべて削除します。

5. SSL/TLS パブリックエンドポイントファイルを保存します。

手順

1. 設定後テンプレートを編集します。

2. parameters セクションに、EndpointMap パラメーターとそのサブパラメーターを追加します。

   parameters:
     servers:
       type: json
     nameserver_ip:
       type: string
     DeployIdentifier:
       type: string
     EndpointMap:
       default: {}
       type: json

3. テンプレートを保存します。

手順

1. rhel-registration 環境ファイルは、今後のデプロイメント操作から除外します。通常は、以下のファイルを除外します。

   • rhel-registration/environment-rhel-registration.yaml
   • rhel-registration/rhel-registration-resource-registry.yaml

2. カスタムの roles_data ファイルを使用する場合には、roles_data ファイルの各ロールに必ず OS::TripleO::Services::Rhsm コンポーザブルサービスを含めてください。以下に例を示します。

   - name: Controller
     description: |
       Controller role that has all the controller services loaded and handles
       Database, Messaging and Network functions.
     CountDefault: 1
     ...
     ServicesDefault:
       ...
       - OS::TripleO::Services::Rhsm
       ...

3. rhsm コンポーザブルサービスのパラメーター用の環境ファイルを今後のデプロイメント操作に追加します。

手順

1. 設定を保存するための環境ファイル (templates/rhsm.yml) を作成します。

2. 環境ファイルに設定を追加します。以下に例を示します。

   resource_registry:
     OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml
   parameter_defaults:
     RhsmVars:
       rhsm_repos:
         - rhel-8-for-x86_64-baseos-eus-rpms
         - rhel-8-for-x86_64-appstream-eus-rpms
         - rhel-8-for-x86_64-highavailability-eus-rpms
         …​
       rhsm_username: "myusername"
       rhsm_password: "p@55w0rd!"
       rhsm_org_id: "1234567"
       rhsm_pool_ids: "1a85f9223e3d5e43013e3d6e8ff506fd"
       rhsm_method: "portal"
       rhsm_release: 8.4

   • resource_registry セクションは、各ロールで利用可能な OS::TripleO::Services::Rhsm リソースに rhsm コンポーザブルサービスを関連付けます。
   • RhsmVars の変数は、Red Hat の登録を設定するためにパラメーターを Ansible に渡します。
3. 環境ファイルを保存します。

手順

1. 設定を保存するための環境ファイル (templates/rhsm.yml) を作成します。

2. 環境ファイルに設定を追加します。以下に例を示します。

   resource_registry:
     OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml
   parameter_defaults:
     ControllerParameters:
       RhsmVars:
         rhsm_repos:
           - rhel-8-for-x86_64-baseos-eus-rpms
           - rhel-8-for-x86_64-appstream-eus-rpms
           - rhel-8-for-x86_64-highavailability-eus-rpms
           - ansible-2.9-for-rhel-8-x86_64-rpms
           - openstack-16.2-for-rhel-8-x86_64-rpms
           - fast-datapath-for-rhel-8-x86_64-rpms
         rhsm_username: "myusername"
         rhsm_password: "p@55w0rd!"
         rhsm_org_id: "1234567"
         rhsm_pool_ids: "55d251f1490556f3e75aa37e89e10ce5"
         rhsm_method: "portal"
         rhsm_release: 8.4
     ComputeParameters:
       RhsmVars:
         rhsm_repos:
           - rhel-8-for-x86_64-baseos-eus-rpms
           - rhel-8-for-x86_64-appstream-eus-rpms
           - rhel-8-for-x86_64-highavailability-eus-rpms
           - ansible-2.9-for-rhel-8-x86_64-rpms
           - openstack-16.2-for-rhel-8-x86_64-rpms
           - fast-datapath-for-rhel-8-x86_64-rpms
         rhsm_username: "myusername"
         rhsm_password: "p@55w0rd!"
         rhsm_org_id: "1234567"
         rhsm_pool_ids: "55d251f1490556f3e75aa37e89e10ce5"
         rhsm_method: "portal"
         rhsm_release: 8.4
     CephStorageParameters:
       RhsmVars:
         rhsm_repos:
           - rhel-8-for-x86_64-baseos-rpms
           - rhel-8-for-x86_64-appstream-rpms
           - rhel-8-for-x86_64-highavailability-rpms
           - ansible-2.9-for-rhel-8-x86_64-rpms
           - openstack-16.2-deployment-tools-for-rhel-8-x86_64-rpms
         rhsm_username: "myusername"
         rhsm_password: "p@55w0rd!"
         rhsm_org_id: "1234567"
         rhsm_pool_ids: "68790a7aa2dc9dc50a9bc39fabc55e0d"
         rhsm_method: "portal"
         rhsm_release: 8.4

   resource_registry は、各ロールで利用可能な OS::TripleO::Services::Rhsm リソースに rhsm コンポーザブルサービスを関連付けます。

   ControllerParameters、ComputeParameters、および CephStorageParameters パラメーターはいずれも、個別の RhsmVars パラメーターを使用してサブスクリプションの情報をそれぞれのロールに渡します。

   注記

   Red Hat Ceph Storage のサブスクリプションおよび Ceph Storage 固有のリポジトリーを使用するように、CephStorageParameters パラメーター内の RhsmVars パラメーターを設定します。rhsm_repos パラメーターに、コントローラーノードおよび Compute ノードに必要な Extended Update Support (EUS) リポジトリーではなく、標準の Red Hat Enterprise Linux リポジトリーが含まれるようにします。

3. 環境ファイルを保存します。

手順

1. rhel-registration 環境ファイルは、今後のデプロイメント操作から除外します。通常は、以下のファイルを除外します。

   • rhel-registration/environment-rhel-registration.yaml
   • rhel-registration/rhel-registration-resource-registry.yaml

2. カスタムの roles_data ファイルを使用する場合には、roles_data ファイルの各ロールに必ず OS::TripleO::Services::Rhsm コンポーザブルサービスを含めてください。以下に例を示します。

   - name: Controller
     description: |
       Controller role that has all the controller services loaded and handles
       Database, Messaging and Network functions.
     CountDefault: 1
     ...
     ServicesDefault:
       ...
       - OS::TripleO::Services::Rhsm
       ...

3. rhsm コンポーザブルサービスのパラメーター用の環境ファイルを今後のデプロイメント操作に追加します。

手順

1. 設定を保存するための環境ファイル (templates/rhsm.yml) を作成します。

2. 環境ファイルに設定を追加します。以下に例を示します。

   resource_registry:
     OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml
   parameter_defaults:
     RhsmVars:
       rhsm_activation_key: "myactivationkey"
       rhsm_method: "satellite"
       rhsm_org_id: "ACME"
       rhsm_server_hostname: "satellite.example.com"
       rhsm_baseurl: "https://satellite.example.com/pulp/repos"
       rhsm_release: 8.4

   resource_registry は、各ロールで利用可能な OS::TripleO::Services::Rhsm リソースに rhsm コンポーザブルサービスを関連付けます。

   RhsmVars の変数は、Red Hat の登録を設定するためにパラメーターを Ansible に渡します。

3. 環境ファイルを保存します。

手順

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

2. playbook-satellite.yaml という名前のファイルを作成し、以下のコンテンツをファイルに貼り付けます。

   - name: Pre-install leapp
     hosts: overcloud
     become: yes
     tasks:
       - name: Pre-install leapp
         yum:
           name:
             - leapp
             - leapp-repository
           state: installed
       - name: Remove katello-host-tools-fact-plugin
         yum:
           name:
             - katello-host-tools-fact-plugin
           state: removed
       - name: Register system
         redhat_subscription:
           activationkey: "osp16-key"
           org_id: "ACME"
           server_hostname: "satellite.example.com"
           rhsm_baseurl: "https://satellite.example.com/pulp/repos"
           force_register: True

   お使いの Satellite Server に合わせて redhat_subscription 変数を変更します。

3. Playbook を実行します。

   $ ansible-playbook -i ~/inventory.yaml playbook-satellite.yaml

1. アンダークラウドをアップグレードしますが、バージョン 3 の ceph-ansible を維持します。
2. オーバークラウドのアップグレードを開始します。

3. Ceph Storage のコンテナー化されたサービスをホストするノードごとに、以下のタスクを実行します。

   1. Ceph Storage のコンテナー化されたサービスを Podman に移行する。
   2. オペレーティングシステムをアップグレードする。
   3. OpenStack Platform サービスをアップグレードする。これにより、Ceph Storage バージョン 3 のコンテナー化されたサービスが再起動されます。
4. オーバークラウドのアップグレードを完了します。
5. アンダークラウドの ceph-ansible をバージョン 4 にアップグレードします。
6. オーバークラウドで Red Hat Ceph Storage 4 にアップグレードします。

手順

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

2. dnf コマンドを実行して、ceph-ansible パッケージのバージョンを確認します。

   $ sudo dnf info ceph-ansible

   コマンド出力には、ceph-ansible パッケージのバージョン 3 が表示されます。

   Installed Packages
   Name         : ceph-ansible
   Version      : 3.xx.xx.xx
   ...

手順

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

2. オーバークラウドの Ceph Storage 設定が含まれる環境ファイルを編集します。このファイルは、通常 ceph-config.yaml という名前で、templates ディレクトリーにあります。

   $ vi /home/stack/templates/ceph-config.yaml

3. parameter_defaults セクションに CephAnsibleRepo パラメーターを追加します。

   parameter_defaults:
     ...
     CephAnsibleRepo: rhceph-4-tools-for-rhel-8-x86_64-rpms
     ...

   CephAnsibleRepo は、ceph-ansible が含まれるリポジトリーを設定します。検証フレームワークでは、このパラメーターを使用して、アンダークラウドに ceph-ansible がインストールされていることを確認します。

4. ceph-config.yaml ファイルを保存します。

手順

1. ceph-mon サービスを実行しているノードにログインします。このノードは、通常コントローラーノードまたはスタンドアロンの Ceph Monitor ノードです。

2. 以下のコマンドを入力して、Ceph クラスターのステータスを表示します。

   $ docker exec ceph-mon-$HOSTNAME ceph -s

3. クラスターの健全性ステータスが HEALTH_OK であること、およびすべての OSD が up の状態にあることを確認します。

手順

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

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

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

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

手順

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

2. オーバークラウドの Ceph Storage 設定が含まれる環境ファイルを編集します。このファイルは、通常 ceph-config.yaml という名前で、templates ディレクトリーにあります。

   $ vi /home/stack/templates/ceph-config.yaml

3. parameter_defaults セクションに CephAnsibleRepo パラメーターを追加します。

   parameter_defaults:
     ...
     CephAnsibleRepo: rhceph-4-tools-for-rhel-8-x86_64-rpms
     ...

   CephAnsibleRepo は、ceph-ansible が含まれるリポジトリーを設定します。検証フレームワークでは、このパラメーターを使用して、アンダークラウドに ceph-ansible がインストールされていることを確認します。

4. ceph-config.yaml ファイルを保存します。

手順

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

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

   $ source ~/stackrc

3. アンダークラウドにおいて、update-nic-templates.sh という名前のファイルを作成し、以下の内容を追加します。

   #!/bin/bash
   STACK_NAME="overcloud"
   ROLES_DATA="/usr/share/openstack-tripleo-heat-templates/roles_data.yaml"
   NETWORK_DATA="/usr/share/openstack-tripleo-heat-templates/network_data.yaml"
   NIC_CONFIG_LINES=$(openstack stack environment show $STACK_NAME | grep "::Net::SoftwareConfig" | sed -E 's/ *OS::TripleO::// ; s/::Net::SoftwareConfig:// ; s/ http.*user-files/ /')
   echo "$NIC_CONFIG_LINES" | while read LINE; do
       ROLE=$(echo "$LINE" | awk '{print $1;}')
       NIC_CONFIG=$(echo "$LINE" | awk '{print $2;}')
   
       if [ -f "$NIC_CONFIG" ]; then
           echo "Updating template for $ROLE role."
           python3 /usr/share/openstack-tripleo-heat-templates/tools/merge-new-params-nic-config-script.py \
               --tht-dir /usr/share/openstack-tripleo-heat-templates \
               --roles-data $ROLES_DATA \
               --network-data $NETWORK_DATA \
               --role-name "$ROLE" \
               --discard-comments yes \
               --template "$NIC_CONFIG"
       else
           echo "No NIC template detected for $ROLE role. Skipping $ROLE role."
       fi
   done

   • カスタムのオーバークラウド名を使用している場合には、STACK_NAME 変数をそのオーバークラウドの名前に設定します。オーバークラウドスタックのデフォルト名は overcloud です。
   • カスタムの roles_data ファイルを使用する場合は、ROLES_DATA 変数をカスタムファイルの場所に設定します。デフォルトの roles_data ファイルを使用する場合には、変数を /usr/share/openstack-tripleo-heat-templates/roles_data.yaml のままにします。
   • カスタムの network_data ファイルを使用する場合は、NETWORK_DATA 変数をカスタムファイルの場所に設定します。デフォルトの network_data ファイルを使用する場合には、変数を /usr/share/openstack-tripleo-heat-templates/network_data.yaml のままにします。
   • /usr/share/openstack-tripleo-heat-templates/tools/merge-new-params-nic-config-script.py -h を実行して、スクリプトに追加するオプションのリストを確認します。

4. スクリプトに実行権限を追加します。

   $ chmod +x update-nic-templates.sh

5. (オプション) RHOSP 環境にスパイン/リーフ型ネットワークトポロジーを使用する場合には、roles_data.yaml ファイルをチェックして、デプロイメントの NIC テンプレートに正しいロール名が使用されていることを確認します。このスクリプトは、roles_data.yaml ファイルの deprecated_nic_config_name パラメーターの値を使用します。

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

   $ ./update-nic-templates.sh

   スクリプトにより各カスタム NIC テンプレートのコピーが保存され、不足しているパラメーターで各テンプレートが更新されます。このスクリプトは、カスタムテンプレートを持たないロールもスキップします。

   No NIC template detected for BlockStorage role. Skipping BlockStorage role.
   Updating template for CephStorage role.
   The original template was saved as: /home/stack/templates/custom-nics/ceph-storage.yaml.20200903144835
   The update template was saved as: /home/stack/templates/custom-nics/ceph-storage.yaml
   Updating template for Compute role.
   The original template was saved as: /home/stack/templates/custom-nics/compute.yaml.20200903144838
   The update template was saved as: /home/stack/templates/custom-nics/compute.yaml
   Updating template for Controller role.
   The original template was saved as: /home/stack/templates/custom-nics/controller.yaml.20200903144841
   The update template was saved as: /home/stack/templates/custom-nics/controller.yaml
   No NIC template detected for ObjectStorage role. Skipping ObjectStorage role.

手順

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

   $ source ~/stackrc

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

   $ openstack overcloud upgrade prepare \
       --stack STACK NAME \
       --templates \
       -e ENVIRONMENT FILE
       …​
       -e /home/stack/templates/upgrades-environment.yaml \
       -e /home/stack/templates/rhsm.yaml \
       -e /home/stack/containers-prepare-parameter.yaml \
       -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs.yaml \
       …​

   以下のオプションの中で、お使いの環境に適切なオプションを追加します。

   • アップグレード固有のパラメーターが含まれる環境ファイル (upgrades-environment.yaml) (-e)
   • 登録およびサブスクリプションに関するパラメーターが含まれる環境ファイル (rhsm.yaml) (-e)
   • 新しいコンテナーイメージの場所を定義した環境ファイル (containers-prepare-parameter.yaml) (-e)。多くの場合、アンダークラウドが使用する環境ファイルと同じファイルです。
   • OVS との互換性を維持するための環境ファイル (neutron-ovs.yaml)
   • デプロイメントに関連するカスタム設定環境ファイル (-e)
   • 該当する場合は、--roles-file でカスタムロール (roles_data) ファイルを指定します。
   • 該当する場合は、--networks-file でコンポーザブルネットワーク (network_data) ファイルを指定します。
   • カスタムのスタック名を使用する場合は、--stack オプションでその名前を渡します。
3. アップグレードの準備が完了するまで待ちます。

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

   $ openstack overcloud external-upgrade run --stack STACK NAME --tags container_image_prepare

手順

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

   $ source ~/stackrc

2. アンダークラウドノードで、ブートストラップコントローラーノードを特定します。

   $ tripleo-ansible-inventory --list [--stack <stack_name>] |jq .overcloud_Controller.hosts[0]

   • <stack_name> は、実際のスタック名に置き換えます。

3. ブートストラップ Controller ノードをアップグレードします。

   1. ブートストラップ Controller ノードでオペレーティングシステムの Leapp アップグレードを実行します。

      $ openstack overcloud upgrade run [--stack <stack>] --tags system_upgrade --limit <bootstrap_controller_node>

      • <bootstrap_controller_node> を環境内のブートストラップ Controller ノードのホスト名 (例: overcloud-controller-0) に置き換えます。

      • デフォルトのオーバークラウドスタック名である overcloud を使用していない場合は、--stack オプションの引数を含め、<stack> をオーバークラウドスタックの名前に置き換えます。

        ブートストラップ Controller ノードは、Leapp アップグレードの一部として再起動されます。

   2. データベースの最新バージョンを既存のノードからブートストラップノードにコピーします。

      $ openstack overcloud external-upgrade run [--stack <stack>] --tags system_upgrade_transfer_data

      重要

      このコマンドにより、コントロールプレーンが停止します。RHOSP のアップグレードが完了し、コントロールプレーンが再びアクティブになるまで、オーバークラウドで標準的な操作を実行することはできません。

   3. Compute ノード上の一時的な 16.2 コンテナーが起動します。これにより、後のステップで Compute ノードをアップグレードする際に、ワークロードの移行が円滑に行われます。

      $ openstack overcloud upgrade run --stack <stack> --playbook upgrade_steps_playbook.yaml --tags nova_hybrid_state --limit all

   4. タグなしでオーバークラウドをアップグレードします。

      $ openstack overcloud upgrade run --stack <stack> --limit <bootstrap_controller_node>

   5. アップグレード後に新しい Pacemaker クラスターが起動していること、および galera、rabbit、haproxy、redis 等のコントロールプレーンサービスが実行中であることを確認します。

      $ sudo pcs status

4. 次のコントローラーノードをアップグレードします。

   1. 古いクラスターが実行されなくなったことを確認します。

      $ sudo pcs status

      クラスターが実行されていない場合、以下のようなエラーが表示されます。

      Error: cluster is not currently running on this node

   2. Controller ノードでオペレーティングシステムの Leapp アップグレードを実行します。

      $ openstack overcloud upgrade run --stack <stack> --tags system_upgrade --limit <controller_node>

      • <controller_node> をアップグレードするコントローラーノードのホスト名 (例: overcloud-controller-1) に置き換えます。

        Leapp アップグレードの一環として、コントローラーノードが再起動されます。

   3. コントローラーノードをアップグレードし、新しい Pacemaker クラスター内の以前にアップグレードしたノードに追加します。

      $ openstack overcloud upgrade run --stack <stack> --limit <bootstrap_controller_node,controller_node_1,controller_node_n>

      • <bootstrap_controller_node,controller_node_1,controller_node_n> を、これまでにアップグレードしたコントローラーノードのコンマ区切りのリストと、Pacemaker クラスターに追加する追加のコントローラーノード (例: overcloud-controller-0,overcloud-controller-1, overcloud-controller-2 に置き換えます)。

手順

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

   $ source ~/stackrc

2. アンダークラウドノードで以下のコマンドを実行し、ブートストラップコントローラーノードを特定します。

   $ tripleo-ansible-inventory --list [--stack <stack_name>] |jq .overcloud_Controller.hosts[0]

   • オプション: <stack_name> をスタックの名前に置き換えます。指定しない場合、デフォルトは overcloud です。

3. ブートストラップ Controller ノードをアップグレードします。

   1. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run [--stack <stack_name>] --tags ceph_systemd -e ceph_ansible_limit=overcloud-controller-0

      <stack_name> は、実際のスタック名に置き換えます。

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したコントローラーノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

   2. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run [--stack <stack_name>] --tags system_upgrade --limit overcloud-controller-0

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。

      • Leapp によるアップグレードの一部としてリブートを実施する。

        重要

        次のコマンドにより、コントロールプレーンで機能停止が生じます。これ以降の数ステップを実施している間は、標準的なオーバークラウド操作を行うことはできません。

   3. system_upgrade_transfer_data タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run [--stack <stack_name>] --tags system_upgrade_transfer_data

      このコマンドにより、最新バージョンのデータベースが既存のノードからブートストラップノードにコピーされます。

   4. nova_hybrid_state タグを指定してアップグレードコマンドを実行し、upgrade_steps_playbook.yaml Playbook だけを実行します。

      $ openstack overcloud upgrade run [--stack <stack_name>] --playbook upgrade_steps_playbook.yaml --tags nova_hybrid_state --limit all

      このコマンドにより、Compute ノード上の一時的な 16.2 コンテナーが起動します。これにより、後のステップで Compute ノードをアップグレードする際に、ワークロードの移行が円滑に行われます。

   5. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run [--stack <stack_name>] --limit overcloud-controller-0

      このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。

      重要

      このコマンドの処理が完了すると、コントロールプレーンがアクティブになります。再び標準的なオーバークラウド操作を実施することができます。

   6. アップグレード後に新しい Pacemaker クラスターが起動していること、および galera、rabbit、haproxy、redis 等のコントロールプレーンサービスが実行中であることを確認します。

      $ sudo pcs status

4. 次のコントローラーノードをアップグレードします。

   1. 古いクラスターが実行されなくなったことを確認します。

      $ sudo pcs status

      クラスターが実行されていない場合、以下のようなエラーが表示されます。

      Error: cluster is not currently running on this node

   2. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run [--stack <stack_name>] --tags ceph_systemd -e ceph_ansible_limit=overcloud-controller-1

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したコントローラーノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

   3. 次のコントローラーノードで、system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run [--stack <stack_name>] --tags system_upgrade --limit overcloud-controller-1

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。

   4. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run [--stack <stack_name>] --limit overcloud-controller-0,overcloud-controller-1

      このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。このノードに加えて、前のステップでアップグレードしたブートストラップノードを --limit オプションに含めます。

5. 最後のコントローラーノードをアップグレードします。

   1. 古いクラスターが実行されなくなったことを確認します。

      $ sudo pcs status

      クラスターが実行されていない場合、以下のようなエラーが表示されます。

      Error: cluster is not currently running on this node

   2. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run [--stack <stack_name>] --tags ceph_systemd -e ceph_ansible_limit=overcloud-controller-2

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したコントローラーノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

   3. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run [--stack <stack_name>] --tags system_upgrade --limit overcloud-controller-2

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。

   4. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run [--stack <stack_name>] --limit overcloud-controller-0,overcloud-controller-1,overcloud-controller-2

      このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。--limit オプションにすべてのコントローラーノードを含めます。

手順

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

   $ source ~/stackrc

2. Ceph Storage ノードを選択し、オペレーティングシステムをアップグレードします。

   1. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph_systemd -e ceph_ansible_limit=overcloud-cephstorage-0

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

   2. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-cephstorage-0

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。

   3. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-cephstorage-0

      このコマンドにより config-download Playbook が実行され、Ceph Storage ノードでコンポーザブルサービスが設定されます。このステップでは、Ceph Storage ノードは Red Hat Ceph Storage 4 にアップグレードされません。Red Hat Ceph Storage 4 へのアップグレードは、後の手順で実施されます。

3. 次の Ceph Storage ノードを選択し、オペレーティングシステムをアップグレードします。

   1. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph_systemd -e ceph_ansible_limit=overcloud-cephstorage-1

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

   2. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-cephstorage-1

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。

   3. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-cephstorage-1

      このコマンドにより config-download Playbook が実行され、Ceph Storage ノードでコンポーザブルサービスが設定されます。このステップでは、Ceph Storage ノードは Red Hat Ceph Storage 4 にアップグレードされません。Red Hat Ceph Storage 4 へのアップグレードは、後の手順で実施されます。

4. 最後の Ceph Storage ノードを選択し、オペレーティングシステムをアップグレードします。

   1. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph_systemd -e ceph_ansible_limit=overcloud-cephstorage-2

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

   2. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-cephstorage-2

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。

   3. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-cephstorage-2

      このコマンドにより config-download Playbook が実行され、Ceph Storage ノードでコンポーザブルサービスが設定されます。このステップでは、Ceph Storage ノードは Red Hat Ceph Storage 4 にアップグレードされません。Red Hat Ceph Storage 4 へのアップグレードは、後の手順で実施されます。

手順

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

   $ source ~/stackrc

2. インスタンスを移行します。移行計画についての詳細は、Migrating virtual machines between Compute nodes を参照してください。

3. system_upgrade タグを指定してアップグレードコマンドを実行します。

   $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-compute-0

   このコマンドにより、以下のアクションが行われます。

   • Leapp によるオペレーティングシステムのアップグレードを実施する。
   • Leapp によるアップグレードの一部としてリブートを実施する。

4. タグを指定せずにアップグレードコマンドを実行します。

   $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-compute-0

   このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。

5. 複数の Compute ノードを並行してアップグレードするには、--limit オプションをアップグレードするノードのコンマ区切りリストに設定します。まず system_upgrade タスクを実行します。

   $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-compute-0,overcloud-compute-1,overcloud-compute-2

   続いて、標準の OpenStack サービスのアップグレードを実施します。

   $ openstack overcloud upgrade run --stack STACK NAME  --limit overcloud-compute-0,overcloud-compute-1,overcloud-compute-2

手順

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

   $ source ~/stackrc

2. containers-prepare-parameter.yaml ファイルを編集し、以下のパラメーターおよびその値を削除します。

   • ceph3_namespace
   • ceph3_tag
   • ceph3_image
   • name_prefix_stein
   • name_suffix_stein
   • namespace_stein
   • tag_stein
3. オーバークラウドでフェンシングを再度有効にするには、fencing.yaml 環境ファイルで EnableFencing パラメーターを true に設定します。

4. アップグレードの最終処理コマンドを実行します。

   $ openstack overcloud upgrade converge \
       --stack STACK NAME \
       --templates \
       -e ENVIRONMENT FILE
       …​
       -e /home/stack/templates/upgrades-environment.yaml \
       -e /home/stack/templates/rhsm.yaml \
       -e /home/stack/containers-prepare-parameter.yaml \
       -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs.yaml \
       …​

   以下のオプションの中で、お使いの環境に適切なオプションを追加します。

   • アップグレード固有のパラメーターが含まれる環境ファイル (upgrades-environment.yaml) (-e)
   • EnableFencing パラメーターが true に設定された環境ファイル (fencing.yaml)。
   • 登録およびサブスクリプションに関するパラメーターが含まれる環境ファイル (rhsm.yaml) (-e)
   • 新しいコンテナーイメージの場所を定義した環境ファイル (containers-prepare-parameter.yaml) (-e)。多くの場合、アンダークラウドが使用する環境ファイルと同じファイルです。
   • OVS との互換性を維持するための環境ファイル (neutron-ovs.yaml)
   • デプロイメントに関連するカスタム設定環境ファイル (-e)
   • 該当する場合は、--roles-file でカスタムロール (roles_data) ファイルを指定します。
   • 該当する場合は、--networks-file でコンポーザブルネットワーク (network_data) ファイルを指定します。
   • カスタムのスタック名を使用する場合は、--stack オプションでその名前を渡します。
5. スタックの同期が完了するまで待ちます。

手順

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

   $ source ~/stackrc

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

   $ openstack overcloud upgrade prepare \
       --stack STACK NAME \
       --templates \
       -e ENVIRONMENT FILE
       …​
       -e /home/stack/templates/upgrades-environment.yaml \
       -e /home/stack/templates/rhsm.yaml \
       -e /home/stack/containers-prepare-parameter.yaml \
       -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs.yaml \
       …​

   以下のオプションの中で、お使いの環境に適切なオプションを追加します。

   • アップグレード固有のパラメーターが含まれる環境ファイル (upgrades-environment.yaml) (-e)
   • 登録およびサブスクリプションに関するパラメーターが含まれる環境ファイル (rhsm.yaml) (-e)
   • 新しいコンテナーイメージの場所を定義した環境ファイル (containers-prepare-parameter.yaml) (-e)。多くの場合、アンダークラウドが使用する環境ファイルと同じファイルです。
   • OVS との互換性を維持するための環境ファイル (neutron-ovs.yaml)
   • デプロイメントに関連するカスタム設定環境ファイル (-e)
   • 該当する場合は、--roles-file でカスタムロール (roles_data) ファイルを指定します。
   • 該当する場合は、--networks-file でコンポーザブルネットワーク (network_data) ファイルを指定します。
   • カスタムのスタック名を使用する場合は、--stack オプションでその名前を渡します。
3. アップグレードの準備が完了するまで待ちます。

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

   $ openstack overcloud external-upgrade run --stack STACK NAME --tags container_image_prepare

手順

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

   $ source ~/stackrc

2. アンダークラウドノードで以下のコマンドを実行し、ブートストラップコントローラーノードを特定します。

   $ tripleo-ansible-inventory --list [--stack <stack_name>] |jq .overcloud_Controller.hosts[0]

   • オプション: <stack_name> をスタックの名前に置き換えます。指定しない場合、デフォルトは overcloud です。

3. ブートストラップ Controller ノードをアップグレードします。

   1. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run [--stack <stack_name>] --tags system_upgrade --limit overcloud-controller-0

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。

      • Leapp によるアップグレードの一部としてリブートを実施する。

        重要

        次のコマンドにより、コントロールプレーンで機能停止が生じます。これ以降の数ステップを実施している間は、標準的なオーバークラウド操作を行うことはできません。

   2. system_upgrade_transfer_data タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run [--stack <stack_name>] --tags system_upgrade_transfer_data

      このコマンドにより、最新バージョンのデータベースが既存のノードからブートストラップノードにコピーされます。

   3. nova_hybrid_state タグを指定してアップグレードコマンドを実行し、upgrade_steps_playbook.yaml Playbook だけを実行します。

      $ openstack overcloud upgrade run [--stack <stack_name>] --playbook upgrade_steps_playbook.yaml --tags nova_hybrid_state --limit all

      このコマンドにより、Compute ノード上の一時的な 16.2 コンテナーが起動します。これにより、後のステップで Compute ノードをアップグレードする際に、ワークロードの移行が円滑に行われます。

   4. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run [--stack <stack_name>] --limit overcloud-controller-0

      このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。

      重要

      このコマンドの処理が完了すると、コントロールプレーンがアクティブになります。再び標準的なオーバークラウド操作を実施することができます。

   5. アップグレード後に新しい Pacemaker クラスターが起動していること、および galera、rabbit、haproxy、redis 等のコントロールプレーンサービスが実行中であることを確認します。

      $ sudo pcs status

4. 次のコントローラーノードをアップグレードします。

   1. 古いクラスターが実行されなくなったことを確認します。

      $ sudo pcs status

      クラスターが実行されていない場合、以下のようなエラーが表示されます。

      Error: cluster is not currently running on this node

   2. 次のコントローラーノードで、system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run [--stack <stack_name>] --tags system_upgrade --limit overcloud-controller-1

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。

   3. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run [--stack <stack_name>] --limit overcloud-controller-0,overcloud-controller-1

      このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。このノードに加えて、前のステップでアップグレードしたブートストラップノードを --limit オプションに含めます。

5. 最後のコントローラーノードをアップグレードします。

   1. 古いクラスターが実行されなくなったことを確認します。

      $ sudo pcs status

      クラスターが実行されていない場合、以下のようなエラーが表示されます。

      Error: cluster is not currently running on this node

   2. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run [--stack <stack_name>] --tags system_upgrade --limit overcloud-controller-2

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。

   3. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run [--stack <stack_name>] --limit overcloud-controller-0,overcloud-controller-1,overcloud-controller-2

      このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。--limit オプションにすべてのコントローラーノードを含めます。

手順

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

   $ source ~/stackrc

2. インスタンスを移行します。移行計画についての詳細は、Migrating virtual machines between Compute nodes を参照してください。

3. system_upgrade タグを指定してアップグレードコマンドを実行します。

   $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-compute-0

   このコマンドにより、以下のアクションが行われます。

   • Leapp によるオペレーティングシステムのアップグレードを実施する。
   • Leapp によるアップグレードの一部としてリブートを実施する。

4. タグを指定せずにアップグレードコマンドを実行します。

   $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-compute-0

   このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。

5. 複数の Compute ノードを並行してアップグレードするには、--limit オプションをアップグレードするノードのコンマ区切りリストに設定します。まず system_upgrade タスクを実行します。

   $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-compute-0,overcloud-compute-1,overcloud-compute-2

   続いて、標準の OpenStack サービスのアップグレードを実施します。

   $ openstack overcloud upgrade run --stack STACK NAME  --limit overcloud-compute-0,overcloud-compute-1,overcloud-compute-2

手順

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

   $ source ~/stackrc

2. containers-prepare-parameter.yaml ファイルを編集し、以下のパラメーターおよびその値を削除します。

   • ceph3_namespace
   • ceph3_tag
   • ceph3_image
   • name_prefix_stein
   • name_suffix_stein
   • namespace_stein
   • tag_stein
3. オーバークラウドでフェンシングを再度有効にするには、fencing.yaml 環境ファイルで EnableFencing パラメーターを true に設定します。

4. アップグレードの最終処理コマンドを実行します。

   $ openstack overcloud upgrade converge \
       --stack STACK NAME \
       --templates \
       -e ENVIRONMENT FILE
       …​
       -e /home/stack/templates/upgrades-environment.yaml \
       -e /home/stack/templates/rhsm.yaml \
       -e /home/stack/containers-prepare-parameter.yaml \
       -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs.yaml \
       …​

   以下のオプションの中で、お使いの環境に適切なオプションを追加します。

   • アップグレード固有のパラメーターが含まれる環境ファイル (upgrades-environment.yaml) (-e)
   • EnableFencing パラメーターが true に設定された環境ファイル (fencing.yaml)。
   • 登録およびサブスクリプションに関するパラメーターが含まれる環境ファイル (rhsm.yaml) (-e)
   • 新しいコンテナーイメージの場所を定義した環境ファイル (containers-prepare-parameter.yaml) (-e)。多くの場合、アンダークラウドが使用する環境ファイルと同じファイルです。
   • OVS との互換性を維持するための環境ファイル (neutron-ovs.yaml)
   • デプロイメントに関連するカスタム設定環境ファイル (-e)
   • 該当する場合は、--roles-file でカスタムロール (roles_data) ファイルを指定します。
   • 該当する場合は、--networks-file でコンポーザブルネットワーク (network_data) ファイルを指定します。
   • カスタムのスタック名を使用する場合は、--stack オプションでその名前を渡します。
5. スタックの同期が完了するまで待ちます。

手順

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

   $ source ~/stackrc

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

   $ openstack overcloud upgrade prepare \
       --stack STACK NAME \
       --templates \
       -e ENVIRONMENT FILE
       …​
       -e /home/stack/templates/upgrades-environment.yaml \
       -e /home/stack/templates/rhsm.yaml \
       -e /home/stack/containers-prepare-parameter.yaml \
       -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs.yaml \
       …​

   以下のオプションの中で、お使いの環境に適切なオプションを追加します。

   • アップグレード固有のパラメーターが含まれる環境ファイル (upgrades-environment.yaml) (-e)
   • 登録およびサブスクリプションに関するパラメーターが含まれる環境ファイル (rhsm.yaml) (-e)
   • 新しいコンテナーイメージの場所を定義した環境ファイル (containers-prepare-parameter.yaml) (-e)。多くの場合、アンダークラウドが使用する環境ファイルと同じファイルです。
   • OVS との互換性を維持するための環境ファイル (neutron-ovs.yaml)
   • デプロイメントに関連するカスタム設定環境ファイル (-e)
   • 該当する場合は、--roles-file でカスタムロール (roles_data) ファイルを指定します。
   • 該当する場合は、--networks-file でコンポーザブルネットワーク (network_data) ファイルを指定します。
   • カスタムのスタック名を使用する場合は、--stack オプションでその名前を渡します。
3. アップグレードの準備が完了するまで待ちます。

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

   $ openstack overcloud external-upgrade run --stack STACK NAME --tags container_image_prepare

手順

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

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

   $ source ~/stackrc

3. アンダークラウドノードで、ブートストラップコントローラーノードを特定します。

   $ tripleo-ansible-inventory --list [--stack <stack_name>] |jq .overcloud_Controller.hosts[0]

   • オプション: <stack_name> をスタックの名前に置き換えます。指定しない場合、デフォルトは overcloud です。

4. overcloud-controller-0、overcloud-database-0、overcloud-networker-0、および overcloud-ceph-0 コントロールプレーンノードをアップグレードします。

   1. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack <stack_name> --tags ceph_systemd -e ceph_ansible_limit=overcloud-controller-0,overcloud-database-0,overcloud-networker-0,overcloud-ceph-0

      このコマンドにより、以下のアクションが行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したノードに制限する。

      このステップは、Leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

   2. 各コントロールプレーンノードでオペレーティングシステムの Leapp アップグレードを実行します。

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

      コントロールプレーンノードは、Leapp アップグレードの一部として再起動します。

      重要

      Ceph ノードのアップグレードが失敗した場合は、残りのアップグレードに進む前に、controller-0 のアップグレードが完了していることを確認してください。

   3. データベースの最新バージョンを既存のノードからブートストラップノードにコピーします。

      $ openstack overcloud external-upgrade run --stack <stack_name> --tags system_upgrade_transfer_data

      重要

      このコマンドにより、コントロールプレーンが停止します。これ以降の数ステップを実施している間は、標準的なオーバークラウド操作を行うことはできません。

   4. nova_hybrid_state タグを指定してアップグレードコマンドを実行し、upgrade_steps_playbook.yaml Playbook だけを実行します。

      $ openstack overcloud upgrade run --stack <stack_name> \
       --playbook upgrade_steps_playbook.yaml \
       --tags nova_hybrid_state --limit all

      このコマンドにより、Compute ノード上の一時的な 16.2 コンテナーが起動します。これにより、後のステップで Compute ノードをアップグレードする際に、ワークロードの移行が円滑に行われます。

   5. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack <stack_name> --limit overcloud-controller-0,overcloud-database-0,overcloud-networker-0,overcloud-ceph-0 --playbook all

      このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。

      重要

      このコマンドの処理が完了すると、コントロールプレーンがアクティブになります。再び標準的なオーバークラウド操作を実施することができます。

   6. (オプション) ブートストラップコントローラーノードにおいて、アップグレード後に新しい Pacemaker クラスターが起動していること、および galera、rabbit、haproxy、redis 等のコントロールプレーンサービスが実行中であることを確認します。

      $ sudo pcs status

5. overcloud-controller-1、overcloud-database-1、overcloud-networker-1、および overcloud-ceph-1 コントロールプレーンノードをアップグレードします。

   1. overcloud-controller-1 ノードにログインし、古いクラスターが実行されなくなったことを確認します。

      $ sudo pcs status

      クラスターが実行されていない場合、以下のようなエラーが表示されます。

      Error: cluster is not currently running on this node

   2. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack <stack_name> --tags ceph_systemd -e ceph_ansible_limit=overcloud-controller-1,overcloud-database-1,overcloud-networker-1,overcloud-ceph-1

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したノードに制限する。

      このステップは、Leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

   3. system_upgrade タグを指定してアップグレードコマンドを実行します。

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

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。

   4. タグを指定せずにアップグレードコマンドを実行します。

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

      このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。このノードに加えて、前のステップでアップグレードしたブートストラップノードを --limit オプションに含めます。

6. overcloud-controller-2、overcloud-database-2、overcloud-networker-2、および overcloud-ceph-2 コントロールプレーンノードをアップグレードします。

   1. overcloud-controller-2 ノードにログインし、古いクラスターが実行されなくなったことを確認します。

      $ sudo pcs status

      クラスターが実行されていない場合、以下のようなエラーが表示されます。

      Error: cluster is not currently running on this node

   2. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack <stack_name> --tags ceph_systemd -e ceph_ansible_limit=overcloud-controller-2,overcloud-database-2,overcloud-networker-2,overcloud-ceph-2

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したノードに制限する。

      このステップは、Leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

   3. system_upgrade タグを指定してアップグレードコマンドを実行します。

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

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。

   4. タグを指定せずにアップグレードコマンドを実行します。

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

      このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。--limit オプションにすべてのコントロールプレーンノードを含めます。

手順

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

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

   $ source ~/stackrc

3. インスタンスを移行します。移行計画についての詳細は、Migrating virtual machines between Compute nodes を参照してください。

4. system_upgrade タグを指定してアップグレードコマンドを実行します。

   $ openstack overcloud upgrade run -y --stack STACK NAME --tags system_upgrade --limit 'Compute[0:19]' > upgrade-compute-00-19.log 2>&1 &
   $ openstack overcloud upgrade run -y --stack STACK NAME --tags system_upgrade --limit 'Compute[20:29]' > upgrade-compute-20-29.log 2>&1 &
   $ openstack overcloud upgrade run -y --stack STACK NAME --tags system_upgrade --limit 'Compute[40:59]' > update-compute-40-59.log 2>&1 &
   $ openstack overcloud upgrade run -y --stack STACK NAME --tags system_upgrade --limit 'Compute[60:79]' > update-compute-60-79.log 2>&1 &

   このコマンドにより、以下のアクションが行われます。

   • Leapp によるオペレーティングシステムのアップグレードを実施する。
   • Leapp によるアップグレードの一部としてリブートを実施する。

5. タグを指定せずにアップグレードコマンドを実行します。

   $ openstack overcloud upgrade run -y --stack STACK NAME --limit 'Compute[0:19]' > upgrade-compute-00-19.log 2>&1 &
   $ openstack overcloud upgrade run -y --stack STACK NAME --limit 'Compute[20:29]' > upgrade-compute-20-29.log 2>&1 &
   $ openstack overcloud upgrade run -y --stack STACK NAME --limit 'Compute[40:59]' > update-compute-40-59.log 2>&1 &
   $ openstack overcloud upgrade run -y --stack STACK NAME --limit 'Compute[60:79]' > update-compute-60-79.log 2>&1 &

   このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。

6. (オプション) 選択した Compute ノードをアップグレードするには、アップグレードするノードのコンマ区切りリストと共に --limit オプションを使用します。以下の例では、overcloud-compute-0、overcloud-compute-1、overcloud-compute-2 ノードを並行してアップグレードします。

   1. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-compute-0,overcloud-compute-1,overcloud-compute-2

   2. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME  --limit overcloud-compute-0,overcloud-compute-1,overcloud-compute-2

手順

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

   $ source ~/stackrc

2. containers-prepare-parameter.yaml ファイルを編集し、以下のパラメーターおよびその値を削除します。

   • ceph3_namespace
   • ceph3_tag
   • ceph3_image
   • name_prefix_stein
   • name_suffix_stein
   • namespace_stein
   • tag_stein
3. オーバークラウドでフェンシングを再度有効にするには、fencing.yaml 環境ファイルで EnableFencing パラメーターを true に設定します。

4. アップグレードの最終処理コマンドを実行します。

   $ openstack overcloud upgrade converge \
       --stack STACK NAME \
       --templates \
       -e ENVIRONMENT FILE
       …​
       -e /home/stack/templates/upgrades-environment.yaml \
       -e /home/stack/templates/rhsm.yaml \
       -e /home/stack/containers-prepare-parameter.yaml \
       -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs.yaml \
       …​

   以下のオプションの中で、お使いの環境に適切なオプションを追加します。

   • アップグレード固有のパラメーターが含まれる環境ファイル (upgrades-environment.yaml) (-e)
   • EnableFencing パラメーターが true に設定された環境ファイル (fencing.yaml)。
   • 登録およびサブスクリプションに関するパラメーターが含まれる環境ファイル (rhsm.yaml) (-e)
   • 新しいコンテナーイメージの場所を定義した環境ファイル (containers-prepare-parameter.yaml) (-e)。多くの場合、アンダークラウドが使用する環境ファイルと同じファイルです。
   • OVS との互換性を維持するための環境ファイル (neutron-ovs.yaml)
   • デプロイメントに関連するカスタム設定環境ファイル (-e)
   • 該当する場合は、--roles-file でカスタムロール (roles_data) ファイルを指定します。
   • 該当する場合は、--networks-file でコンポーザブルネットワーク (network_data) ファイルを指定します。
   • カスタムのスタック名を使用する場合は、--stack オプションでその名前を渡します。
5. スタックの同期が完了するまで待ちます。

手順

1. ワークロードをシャットダウンします。

2. director に統合された Ceph をデプロイした場合は、Ceph の systemd ファイルを podman に切り替えます。

   $ openstack overcloud external-upgrade run --stack overcloud --tags ceph_systemd -e ceph_ansible_limit=controller-0,controller-1,controller-2,ceph-0,ceph-1,ceph-2,networker-0,networker-1

   • controller-0、controller-1、controller-2、ceph-0、ceph-1、ceph-2、networker-0、networker-1 を、環境内のロールのサーバー名に置き換えます。

   • Ceph を含む Compute ノードをアップグレードするには、Compute ノードのホスト名を openstack overcloud external-upgrade run コマンドに含めます。以下に例を示します。

     $ openstack overcloud upgrade run --stack overcloud --tags ceph_systemd -e ceph_ansible_limit=overcloud-compute-0,overcloud-compute-1

     さらに、手順 4 と 5 のコマンドに Compute ノードのホスト名を含めます。

3. ノード上のすべての RHOSP サービスを停止します。

   $ openstack overcloud external-upgrade run --stack overcloud --tags system_upgrade_stop_services

4. すべてのノードでシステムアップグレードを実行します。director に統合された Ceph をデプロイした場合は、すべての Ceph ノードを同じ --limit コマンドに含めます。

   $ openstack overcloud upgrade run --stack overcloud --tags system_upgrade --limit controller-0,controller-1,controller-2,ceph-0,ceph-1,ceph-2,networker-0,networker-1

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

   $ openstack overcloud upgrade run --stack overcloud --limit controller-0,controller-1,controller-2,ceph-0,ceph-1,ceph-2,networker-0,networker-1

手順

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

   $ source ~/stackrc

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

   $ openstack overcloud upgrade prepare \
       --stack STACK NAME \
       --templates \
       -e ENVIRONMENT FILE
       …​
       -e /home/stack/templates/upgrades-environment.yaml \
       -e /home/stack/templates/rhsm.yaml \
       -e /home/stack/containers-prepare-parameter.yaml \
       -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs.yaml \
       …​

   以下のオプションの中で、お使いの環境に適切なオプションを追加します。

   • アップグレード固有のパラメーターが含まれる環境ファイル (upgrades-environment.yaml) (-e)
   • 登録およびサブスクリプションに関するパラメーターが含まれる環境ファイル (rhsm.yaml) (-e)
   • 新しいコンテナーイメージの場所を定義した環境ファイル (containers-prepare-parameter.yaml) (-e)。多くの場合、アンダークラウドが使用する環境ファイルと同じファイルです。
   • OVS との互換性を維持するための環境ファイル (neutron-ovs.yaml)
   • デプロイメントに関連するカスタム設定環境ファイル (-e)
   • 該当する場合は、--roles-file でカスタムロール (roles_data) ファイルを指定します。
   • 該当する場合は、--networks-file でコンポーザブルネットワーク (network_data) ファイルを指定します。
   • カスタムのスタック名を使用する場合は、--stack オプションでその名前を渡します。
3. アップグレードの準備が完了するまで待ちます。

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

   $ openstack overcloud external-upgrade run --stack STACK NAME --tags container_image_prepare

手順

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

   $ source ~/stackrc

2. アンダークラウドノードで以下のコマンドを実行し、ブートストラップノードを特定します。

   $ tripleo-ansible-inventory --list [--stack <stack_name>] |jq .overcloud_Controller.hosts[0]

   • オプション: <stack_name> をスタックの名前に置き換えます。指定しない場合、デフォルトは overcloud です。

3. ブートストラップノードをアップグレードします。

   1. ノードに Ceph Storage コンテナーが含まれていれば、ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run [--stack <stack_name>] --tags ceph_systemd -e ceph_ansible_limit=overcloud-controller-0

      <stack_name> は、実際のスタック名に置き換えます。

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

   2. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run [--stack <stack_name>] --tags system_upgrade --limit overcloud-controller-0

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。

   3. system_upgrade_transfer_data タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run [--stack <stack_name>] --tags system_upgrade_transfer_data

      このコマンドにより、最新バージョンのデータベースが既存のノードからブートストラップノードにコピーされます。

   4. nova_hybrid_state タグを指定してアップグレードコマンドを実行し、upgrade_steps_playbook.yaml Playbook だけを実行します。

      $ openstack overcloud upgrade run [--stack <stack_name>] --playbook upgrade_steps_playbook.yaml --tags nova_hybrid_state --limit all

      このコマンドにより、Compute ノード上の一時的な 16.2 コンテナーが起動します。これにより、後のステップで Compute ノードをアップグレードする際に、ワークロードの移行が円滑に行われます。

   5. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run [--stack <stack_name>] --limit overcloud-controller-0

      このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。

4. Pacemaker ベースの各ノードをアップグレードします。

   1. ノードに Ceph Storage コンテナーが含まれていれば、ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run [--stack <stack_name>] --tags ceph_systemd -e ceph_ansible_limit=overcloud-database-0

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

   2. 次のノードで、system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run [--stack <stack_name>] --tags system_upgrade --limit overcloud-database-0

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。

   3. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run [--stack <stack_name>] --limit overcloud-controller-0,overcloud-database-0

      このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。このノードに加えて、前のステップでアップグレードしたすべてのノードを --limit オプションに含めます。

5. 各 Pacemaker ベースのノードでアップグレードプロセスを繰り返し、すべての Pacemaker ベースのノードをアップグレードします。

手順

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

   $ source ~/stackrc

2. system_upgrade タグを指定してアップグレードコマンドを実行します。

   $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-networker-0

   このコマンドにより、以下のアクションが行われます。

   • Leapp によるオペレーティングシステムのアップグレードを実施する。
   • Leapp によるアップグレードの一部としてリブートを実施する。

3. タグを指定せずにアップグレードコマンドを実行します。

   $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-networker-0

   このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。

4. 各ノードでアップグレードプロセスを繰り返し、すべてのコントローラーベースのノードをアップグレードします。

手順

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

   $ source ~/stackrc

2. Ceph MON ノードを選択し、オペレーティングシステムをアップグレードします。

   1. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph_systemd -e ceph_ansible_limit=overcloud-cephmon-0

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

   2. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-cephmon-0

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。

   3. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-cephmon-0

      このコマンドにより config-download Playbook が実行され、Ceph MON ノードでコンポーザブルサービスが設定されます。以下の手順では、Ceph MON ノードは Red Hat Ceph Storage 4 にアップグレードされません。Red Hat Ceph Storage 4 へのアップグレードは、後の手順で実施されます。

3. 次の Ceph MON ノードを選択し、オペレーティングシステムをアップグレードします。

   1. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph_systemd -e ceph_ansible_limit=overcloud-cephmon-1

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

   2. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-cephmon-1

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。

   3. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-cephmon-1

      このコマンドにより config-download Playbook が実行され、Ceph MON ノードでコンポーザブルサービスが設定されます。以下の手順では、Ceph MON ノードは Red Hat Ceph Storage 4 にアップグレードされません。Red Hat Ceph Storage 4 へのアップグレードは、後の手順で実施されます。

4. 最後の Ceph MON ノードを選択し、オペレーティングシステムをアップグレードします。

   1. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph_systemd -e ceph_ansible_limit=overcloud-cephmon-2

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

   2. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-cephmon-2

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。

   3. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-cephmon-2

      このコマンドにより config-download Playbook が実行され、Ceph MON ノードでコンポーザブルサービスが設定されます。以下の手順では、Ceph MON ノードは Red Hat Ceph Storage 4 にアップグレードされません。Red Hat Ceph Storage 4 へのアップグレードは、後の手順で実施されます。

手順

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

   $ source ~/stackrc

2. Ceph Storage ノードを選択し、オペレーティングシステムをアップグレードします。

   1. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph_systemd -e ceph_ansible_limit=overcloud-cephstorage-0

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

   2. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-cephstorage-0

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。

   3. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-cephstorage-0

      このコマンドにより config-download Playbook が実行され、Ceph Storage ノードでコンポーザブルサービスが設定されます。このステップでは、Ceph Storage ノードは Red Hat Ceph Storage 4 にアップグレードされません。Red Hat Ceph Storage 4 へのアップグレードは、後の手順で実施されます。

3. 次の Ceph Storage ノードを選択し、オペレーティングシステムをアップグレードします。

   1. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph_systemd -e ceph_ansible_limit=overcloud-cephstorage-1

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

   2. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-cephstorage-1

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。

   3. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-cephstorage-1

      このコマンドにより config-download Playbook が実行され、Ceph Storage ノードでコンポーザブルサービスが設定されます。このステップでは、Ceph Storage ノードは Red Hat Ceph Storage 4 にアップグレードされません。Red Hat Ceph Storage 4 へのアップグレードは、後の手順で実施されます。

4. 最後の Ceph Storage ノードを選択し、オペレーティングシステムをアップグレードします。

   1. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph_systemd -e ceph_ansible_limit=overcloud-cephstorage-2

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

   2. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-cephstorage-2

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。

   3. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-cephstorage-2

      このコマンドにより config-download Playbook が実行され、Ceph Storage ノードでコンポーザブルサービスが設定されます。このステップでは、Ceph Storage ノードは Red Hat Ceph Storage 4 にアップグレードされません。Red Hat Ceph Storage 4 へのアップグレードは、後の手順で実施されます。

手順

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

   $ source ~/stackrc

2. インスタンスを移行します。移行計画についての詳細は、Migrating virtual machines between Compute nodes を参照してください。

3. system_upgrade タグを指定してアップグレードコマンドを実行します。

   $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-compute-0

   このコマンドにより、以下のアクションが行われます。

   • Leapp によるオペレーティングシステムのアップグレードを実施する。
   • Leapp によるアップグレードの一部としてリブートを実施する。

4. タグを指定せずにアップグレードコマンドを実行します。

   $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-compute-0

   このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。

5. 複数の Compute ノードを並行してアップグレードするには、--limit オプションをアップグレードするノードのコンマ区切りリストに設定します。まず system_upgrade タスクを実行します。

   $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-compute-0,overcloud-compute-1,overcloud-compute-2

   続いて、標準の OpenStack サービスのアップグレードを実施します。

   $ openstack overcloud upgrade run --stack STACK NAME  --limit overcloud-compute-0,overcloud-compute-1,overcloud-compute-2

手順

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

   $ source ~/stackrc

2. containers-prepare-parameter.yaml ファイルを編集し、以下のパラメーターおよびその値を削除します。

   • ceph3_namespace
   • ceph3_tag
   • ceph3_image
   • name_prefix_stein
   • name_suffix_stein
   • namespace_stein
   • tag_stein
3. オーバークラウドでフェンシングを再度有効にするには、fencing.yaml 環境ファイルで EnableFencing パラメーターを true に設定します。

4. アップグレードの最終処理コマンドを実行します。

   $ openstack overcloud upgrade converge \
       --stack STACK NAME \
       --templates \
       -e ENVIRONMENT FILE
       …​
       -e /home/stack/templates/upgrades-environment.yaml \
       -e /home/stack/templates/rhsm.yaml \
       -e /home/stack/containers-prepare-parameter.yaml \
       -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs.yaml \
       …​

   以下のオプションの中で、お使いの環境に適切なオプションを追加します。

   • アップグレード固有のパラメーターが含まれる環境ファイル (upgrades-environment.yaml) (-e)
   • EnableFencing パラメーターが true に設定された環境ファイル (fencing.yaml)。
   • 登録およびサブスクリプションに関するパラメーターが含まれる環境ファイル (rhsm.yaml) (-e)
   • 新しいコンテナーイメージの場所を定義した環境ファイル (containers-prepare-parameter.yaml) (-e)。多くの場合、アンダークラウドが使用する環境ファイルと同じファイルです。
   • OVS との互換性を維持するための環境ファイル (neutron-ovs.yaml)
   • デプロイメントに関連するカスタム設定環境ファイル (-e)
   • 該当する場合は、--roles-file でカスタムロール (roles_data) ファイルを指定します。
   • 該当する場合は、--networks-file でコンポーザブルネットワーク (network_data) ファイルを指定します。
   • カスタムのスタック名を使用する場合は、--stack オプションでその名前を渡します。
5. スタックの同期が完了するまで待ちます。

手順

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

   $ source ~/stackrc

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

   $ openstack overcloud upgrade prepare \
       --stack STACK NAME \
       --templates \
       -e ENVIRONMENT FILE
       …​
       -e /home/stack/templates/upgrades-environment.yaml \
       -e /home/stack/templates/rhsm.yaml \
       -e /home/stack/containers-prepare-parameter.yaml \
       -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs.yaml \
       …​

   以下のオプションの中で、お使いの環境に適切なオプションを追加します。

   • アップグレード固有のパラメーターが含まれる環境ファイル (upgrades-environment.yaml) (-e)
   • 登録およびサブスクリプションに関するパラメーターが含まれる環境ファイル (rhsm.yaml) (-e)
   • 新しいコンテナーイメージの場所を定義した環境ファイル (containers-prepare-parameter.yaml) (-e)。多くの場合、アンダークラウドが使用する環境ファイルと同じファイルです。
   • OVS との互換性を維持するための環境ファイル (neutron-ovs.yaml)
   • デプロイメントに関連するカスタム設定環境ファイル (-e)
   • 該当する場合は、--roles-file でカスタムロール (roles_data) ファイルを指定します。
   • 該当する場合は、--networks-file でコンポーザブルネットワーク (network_data) ファイルを指定します。
   • カスタムのスタック名を使用する場合は、--stack オプションでその名前を渡します。
3. アップグレードの準備が完了するまで待ちます。

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

   $ openstack overcloud external-upgrade run --stack STACK NAME --tags container_image_prepare

手順

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

   $ source ~/stackrc

2. アンダークラウドノードで以下のコマンドを実行し、ブートストラップコントローラーノードを特定します。

   $ tripleo-ansible-inventory --list [--stack <stack_name>] |jq .overcloud_Controller.hosts[0]

   • オプション: <stack_name> をスタックの名前に置き換えます。指定しない場合、デフォルトは overcloud です。

3. ブートストラップ Controller ノードをアップグレードします。

   1. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run [--stack <stack_name>] --tags ceph_systemd -e ceph_ansible_limit=overcloud-controller-0

      <stack_name> は、実際のスタック名に置き換えます。

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したコントローラーノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

   2. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run [--stack <stack_name>] --tags system_upgrade --limit overcloud-controller-0

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。

      • Leapp によるアップグレードの一部としてリブートを実施する。

        重要

        次のコマンドにより、コントロールプレーンで機能停止が生じます。これ以降の数ステップを実施している間は、標準的なオーバークラウド操作を行うことはできません。

   3. system_upgrade_transfer_data タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run [--stack <stack_name>] --tags system_upgrade_transfer_data

      このコマンドにより、最新バージョンのデータベースが既存のノードからブートストラップノードにコピーされます。

   4. nova_hybrid_state タグを指定してアップグレードコマンドを実行し、upgrade_steps_playbook.yaml Playbook だけを実行します。

      $ openstack overcloud upgrade run [--stack <stack_name>] --playbook upgrade_steps_playbook.yaml --tags nova_hybrid_state --limit all

      このコマンドにより、Compute ノード上の一時的な 16.2 コンテナーが起動します。これにより、後のステップで Compute ノードをアップグレードする際に、ワークロードの移行が円滑に行われます。

   5. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run [--stack <stack_name>] --limit overcloud-controller-0

      このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。

      重要

      このコマンドの処理が完了すると、コントロールプレーンがアクティブになります。再び標準的なオーバークラウド操作を実施することができます。

   6. アップグレード後に新しい Pacemaker クラスターが起動していること、および galera、rabbit、haproxy、redis 等のコントロールプレーンサービスが実行中であることを確認します。

      $ sudo pcs status

4. 次のコントローラーノードをアップグレードします。

   1. 古いクラスターが実行されなくなったことを確認します。

      $ sudo pcs status

      クラスターが実行されていない場合、以下のようなエラーが表示されます。

      Error: cluster is not currently running on this node

   2. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run [--stack <stack_name>] --tags ceph_systemd -e ceph_ansible_limit=overcloud-controller-1

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したコントローラーノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

   3. 次のコントローラーノードで、system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run [--stack <stack_name>] --tags system_upgrade --limit overcloud-controller-1

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。

   4. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run [--stack <stack_name>] --limit overcloud-controller-0,overcloud-controller-1

      このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。このノードに加えて、前のステップでアップグレードしたブートストラップノードを --limit オプションに含めます。

5. 最後のコントローラーノードをアップグレードします。

   1. 古いクラスターが実行されなくなったことを確認します。

      $ sudo pcs status

      クラスターが実行されていない場合、以下のようなエラーが表示されます。

      Error: cluster is not currently running on this node

   2. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

      $ openstack overcloud external-upgrade run [--stack <stack_name>] --tags ceph_systemd -e ceph_ansible_limit=overcloud-controller-2

      このコマンドにより、以下の操作が行われます。

      • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
      • ceph_ansible_limit 変数を使用して、アクションを選択したコントローラーノードに制限する。

      このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

   3. system_upgrade タグを指定してアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run [--stack <stack_name>] --tags system_upgrade --limit overcloud-controller-2

      このコマンドにより、以下のアクションが行われます。

      • Leapp によるオペレーティングシステムのアップグレードを実施する。
      • Leapp によるアップグレードの一部としてリブートを実施する。

   4. タグを指定せずにアップグレードコマンドを実行します。

      $ openstack overcloud upgrade run [--stack <stack_name>] --limit overcloud-controller-0,overcloud-controller-1,overcloud-controller-2

      このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。--limit オプションにすべてのコントローラーノードを含めます。

手順

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

   $ source ~/stackrc

2. インスタンスを移行します。移行計画についての詳細は、Migrating virtual machines between Compute nodes を参照してください。

3. ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

   $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph_systemd -e ceph_ansible_limit=overcloud-computehci-0

   このコマンドにより、以下の操作が行われます。

   • Podman 管理を使用するために、Ceph Storage コンテナーを制御する systemd ユニットを変更する。
   • ceph_ansible_limit 変数を使用して、アクションを選択した Ceph Storage ノードに制限する。

   このステップは、leapp によるアップグレードに向けて Ceph Storage サービスを準備するための予備的な処置です。

4. system_upgrade タグを指定してアップグレードコマンドを実行します。

   $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-computehci-0

   このコマンドにより、以下のアクションが行われます。

   • Leapp によるオペレーティングシステムのアップグレードを実施する。
   • Leapp によるアップグレードの一部としてリブートを実施する。

5. タグを指定せずにアップグレードコマンドを実行します。

   $ openstack overcloud upgrade run --stack STACK NAME --limit overcloud-computehci-0

   このコマンドにより、Red Hat OpenStack Platform のアップグレードが実施されます。

6. 複数の Compute ノードを並行してアップグレードするには、--limit オプションをアップグレードするノードのコンマ区切りリストに設定します。まず、ceph_systemd タグを指定して外部アップグレードコマンドを実行します。

   $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph_systemd -e ceph_ansible_limit=overcloud-computehci-0,overcloud-computehci-1,overcloud-computehci-2

   次に、system_upgrade タスクを実行します。

   $ openstack overcloud upgrade run --stack STACK NAME --tags system_upgrade --limit overcloud-computehci-0,overcloud-computehci-1,overcloud-computehci-2

   続いて、標準の OpenStack サービスのアップグレードを実施します。

   $ openstack overcloud upgrade run --stack STACK NAME  --limit overcloud-computehci-0,overcloud-computehci-1,overcloud-computehci-2

手順

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

   $ source ~/stackrc

2. containers-prepare-parameter.yaml ファイルを編集し、以下のパラメーターおよびその値を削除します。

   • ceph3_namespace
   • ceph3_tag
   • ceph3_image
   • name_prefix_stein
   • name_suffix_stein
   • namespace_stein
   • tag_stein
3. オーバークラウドでフェンシングを再度有効にするには、fencing.yaml 環境ファイルで EnableFencing パラメーターを true に設定します。

4. アップグレードの最終処理コマンドを実行します。

   $ openstack overcloud upgrade converge \
       --stack STACK NAME \
       --templates \
       -e ENVIRONMENT FILE
       …​
       -e /home/stack/templates/upgrades-environment.yaml \
       -e /home/stack/templates/rhsm.yaml \
       -e /home/stack/containers-prepare-parameter.yaml \
       -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs.yaml \
       …​

   以下のオプションの中で、お使いの環境に適切なオプションを追加します。

   • アップグレード固有のパラメーターが含まれる環境ファイル (upgrades-environment.yaml) (-e)
   • EnableFencing パラメーターが true に設定された環境ファイル (fencing.yaml)。
   • 登録およびサブスクリプションに関するパラメーターが含まれる環境ファイル (rhsm.yaml) (-e)
   • 新しいコンテナーイメージの場所を定義した環境ファイル (containers-prepare-parameter.yaml) (-e)。多くの場合、アンダークラウドが使用する環境ファイルと同じファイルです。
   • OVS との互換性を維持するための環境ファイル (neutron-ovs.yaml)
   • デプロイメントに関連するカスタム設定環境ファイル (-e)
   • 該当する場合は、--roles-file でカスタムロール (roles_data) ファイルを指定します。
   • 該当する場合は、--networks-file でコンポーザブルネットワーク (network_data) ファイルを指定します。
   • カスタムのスタック名を使用する場合は、--stack オプションでその名前を渡します。
5. スタックの同期が完了するまで待ちます。

手順

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

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

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

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

手順

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

   $ source ~/stackrc

2. ceph タグを指定して、Ceph Storage の外部アップグレードプロセスを実行します。

   $ openstack overcloud external-upgrade run --stack STACK NAME --tags ceph

3. Ceph Storage のアップグレードが完了するまで待ちます。

手順

1. コントローラーノードやスタンドアロンの Ceph MON ノードなど、Ceph MON コンテナーを持つノードに heat-admin ユーザーとしてログインします。たとえば、標準のオーバークラウドデプロイメントでは、overcloud -controller-1 は Ceph MON コンテナーを使用します。

2. OSD が使用しているドライバーを確認するために、Ceph クラスターに対してクエリーを行います。

   [heat-admin@overcloud-controller-1 ~]$ sudo -i
   [root@overcloud-controller-1 ~]# podman exec -it ceph-mon-overcloud-controller-1 sh -c "ceph -f json osd metadata" | jq -c 'sort_by(.hostname) | .[] | ["host", .hostname, "osd_id", .id, "objectstore", .osd_objectstore]'
   [root@overcloud-controller-1 ~]#

3. いずれかの行が "objectstore": "filestore" を返す場合、そのノードには OSD の移行が必要です。

手順

1. CephAnsibleDisksConfig パラメーターの osd_objectstore が filestore にデフォルト設定されないようにします。いずれかのカスタム heat 環境ファイルに osd_objectstore パラメーターが存在する場合は、bluestore の値を明示的に定義する必要があります。

   parameter_defaults:
     CephAnsibleDisksConfig:
       devices:
         - /dev/sdb
         - /dev/sdc
         - /dev/sdd
       osd_scenario: lvm
      osd_objectstore: bluestore

   注記

   ジャーナル等に対する特定の FileStore 設定がある場合は、適切に設定を更新するようにしてください。高度な設定についての詳しい情報は、Deploying an overcloud with containerized Red Hat Cephの Mapping the Ceph Storage Node Disk Layout を参照してください。

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

3. ceph_fstobs タグを指定して openstack overcloud external-upgrade run コマンドを入力します。<NODE_NAME> は、アップグレードする Ceph OSD ノードの名前に置き換えてください。openstack server list コマンドを使用してノード名を探すことができます。

   [stack@undercloud ~] $ openstack overcloud external-upgrade run --tags ceph_fstobs -e ceph_ansible_limit=<NODE_NAME> | tee oc-fstobs.log

4. Ceph MON サービスが実行されているノードにログインし、Ceph クラスターにクエリーを行いアップグレードしたノードの OSD のステータスを確認します。次の OSD ノードの移行を開始する前に、アップグレードしたノードが正常に移行されていることを確認する必要があります。

   [heat-admin@overcloud-controller-1 ~]$ sudo -i
   [root@overcloud-controller-1 ~]# podman exec -it ceph-mon-overcloud-controller-1 sh -c "ceph -f json osd metadata" | jq -c '.[] | select(.hostname == "<NODE_NAME>") | ["host", .hostname, "osd_id", .id, "objectstore", .osd_objectstore]'
   [root@overcloud-controller-1 ~]# exit

   <NODE_NAME> を移行したノードの名前に置き換えます。出力結果を確認し、OSD が BlueStore を使用することが示されていれば、移行は正常に完了しています。

5. (オプション) 特定の OSD に関する追加情報を表示するには、以下のコマンドを入力します。

   [root@overcloud-controller-1 ~]# podman exec -it ceph-mon-overcloud-controller-1 sh -c "ceph osd metadata <ID>"

   <ID> はクエリーを行う OSD の ID に置き換えてください。

6. 次のノードで移行プロセスを開始する前に、クラスターが同期するのを待つ必要があります。

   [root@overcloud-controller-1 ~]# podman exec -it ceph-mon-overcloud-controller-1 sh -c  "ceph  -s"

   Review the command output and ensure that the health of the cluster is `HEALTH_OK` and the PGs are in the `active+clean` state.

7. 次のノードで移行プロセスを開始する前に、クラスターのリバランスプロセスが完了するまで待つ必要があります。ステータスを確認するには、以下のコマンドを実行します。

   [heat-admin@overcloud-controller-0 ~]$ sudo podman exec ceph-mon-<NODE_NAME> ceph -w

   <NODE_NAME> を移行したノードの名前に置き換えます。

8. ストレージクラスター内の各ノードに対して移行プロセスを繰り返します。

手順

1. いずれかのコントローラーノードがホストする ceph-mon コンテナーに heat-admin ユーザーとしてログインします。

2. Ceph クラスターに対してクエリーを行います。

   [heat-admin@overcloud-controller-1 ~]$ sudo -i
   [root@overcloud-controller-1 ~]# podman exec -it ceph-mon-overcloud-controller-1 sh -c "ceph -f json osd metadata" | jq -c 'sort_by(.hostname) | .[] | ["host", .hostname, "osd_id", .id, "objectstore", .osd_objectstore]'
   [root@overcloud-controller-1 ~]#