Red Hat OpenStack Platform の最新状態の維持
Red Hat OpenStack Platform のマイナー更新の実施
OpenStack Documentation Team
rhos-docs@redhat.com
概要
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ を参照してください。
Red Hat ドキュメントへのフィードバック (英語のみ)
Red Hat ドキュメントに対するご意見をお聞かせください。ドキュメントの改善点があればお知らせください。
ドキュメントへのダイレクトフィードバック (DDF) 機能の使用 (英語版のみ)
特定の文章、段落、またはコードブロックに対して直接コメントを送付するには、DDF の Add Feedback 機能を使用してください。なお、この機能は英語版のドキュメントでのみご利用いただけます。
- Multi-page HTML 形式でドキュメントを表示します。
- ドキュメントの右上隅に Feedback ボタンが表示されていることを確認してください。
- コメントするテキスト部分をハイライト表示します。
- Add Feedback をクリックします。
- Add Feedback フィールドにコメントを入力します。
- オプション: ドキュメントチームが問題の詳細を確認する際に使用できるメールアドレスを記入してください。
- Submit をクリックします。
第1章 はじめに
本書で説明するワークフローは、お使いの Red Hat OpenStack Platform 16.1 環境が最新のパッケージおよびコンテナーで更新された状態を維持するのに役立ちます。
本ガイドは、以下のバージョンのアップグレードパスを提供します。
現在の OpenStack バージョン | 新しい OpenStack バージョン |
---|---|
Red Hat OpenStack Platform 16.0 | Red Hat OpenStack Platform 16.1.z |
Red Hat OpenStack Platform 16.1 | Red Hat OpenStack Platform 16.1.z |
1.1. ワークフローの概要
以下の表には、アップグレードのプロセスに必要なステップの概要をまとめています。
ステップ | 説明 |
---|---|
アンダークラウドの更新 | アンダークラウドを最新の OpenStack Platform 16.1.z バージョンに更新します。 |
オーバークラウドの更新 | オーバークラウドを最新の OpenStack Platform 16.1.z バージョンに更新します。 |
Ceph Storage ノードの更新 | すべての Ceph Storage サービスをアップグレードします。 |
アップグレードの最終段階 | コンバージェンスのコマンドを実行して、オーバークラウドスタックをリフレッシュします。 |
インフラストラクチャーがマルチスタックの場合は、各オーバークラウドスタックを一度に 1 つずつ完全に更新します。分散コンピュートノード (DCN) インフラストラクチャーがある場合は、中央のロケーションでオーバークラウドを完全に更新してから、各エッジサイトでオーバークラウドを一度に 1 つずつ更新します。
RHOSP 環境を更新する前の考慮事項
更新プロセス中のガイドとして、次の情報を考慮してください。
- Red Hat は、アンダークラウドおよびオーバークラウドの制御プレーンをバックアップすることを推奨しています。ノードのバックアップについて詳しくは、アンダークラウドおよびコントロールプレーンノードのバックアップと復元 を参照してください。
- 更新を妨げる可能性のある既知の問題を把握してください。
-
現在のメンテナンスリリースを確認するには、
$ cat /etc/rhosp-release
を実行してください。環境を更新した後にこのコマンドを実行して、更新を検証することもできます。
1.2. 更新を妨げる可能性のある既知の問題
マイナーバージョンの更新の正常な完了に影響を及ぼす可能性のある、以下の既知の問題を確認してください。
ノードのクラスターをシャットダウンする際に生じる競合状態により、Pacemaker バージョン 2.0.3-5.el8_2.4
を実行するオーバークラウドノードで更新に失敗する場合があります。
現在オーバークラウドノードのいずれかに Pacemaker バージョン 2.0.3-5.el8_2.4
がインストールされている場合、BZ#1973660 を避けるためにオーバークラウドノードを更新する前に Pacemaker をアップグレードする必要があります。詳細は、以下の Red Hat ナレッジベースのソリューション Update from OSP16.1 to OSP16.2 might fail to update certain HA containers を参照してください。
+RHEL 8.2 を実行し、コンポーザブルロールをベースとするノードの場合は、他のロールを更新する前に最初に Database
ロールを更新する必要があります。
既知の問題により、リリース 16.1.6 以前から 16.1.7 以降に更新した後、LDAP 接続が失敗します。RHOSP 16.1.7 では、Identity サービス (keystone) コンテナーがホストファイルシステムに /etc/openldap
をマウントします。以前に RHOSP 13 から更新したことがある場合、古い設定ファイルが /etc/openldap
ディレクトリーに存在し、Identity サービスの LDAP 接続が失敗する原因となる可能性があります。
回避策として、各コントローラーで次のコマンドを実行します。
$ sudo cp /etc/openldap/ldap.conf.rpmnew /etc/openldap/ldap.conf $ sudo podman restart keystone
次の条件を満たしている場合、ovn-controller の再起動中に、プロバイダーネットワークからトラバースするネットワークトラフィックが中断されます。
- お使いの環境には、フローティング IP またはプロバイダーネットワーク上の直接ポートによって接続されたプロバイダーネットワークがあります。
- 任意の 16.1 リリースに更新する
ダウンタイムは、既存のワークロードの数によって異なります。ダウンタイムを回避するには、Red Hat Knowledgebase の解決策を適用します。16.2.2 より古い OSP (すべての 16.1 バージョンを含む) からの更新/アップグレード時にデータプレーンが中断される。
第2章 マイナー更新の準備
Red Hat OpenStack Platform 16.1 を最新のマイナーリリースに更新するプロセスを開始する前に、アンダークラウドおよびオーバークラウドで準備手順を実施する必要があります。
2.1. 環境の Red Hat Enterprise Linux リリースへのロック
Red Hat OpenStack Platform 16.1 は Red Hat Enterprise Linux 8.2 でサポートされています。更新を実施する前に、オペレーティングシステムをより新しいマイナーリリースにアップグレードしないように、アンダークラウドおよびオーバークラウドのリポジトリーを Red Hat Enterprise Linux 8.2 リリースにロックします。
手順
-
アンダークラウドに
stack
ユーザーとしてログインします。 stackrc
ファイルを取得します。$ source ~/stackrc
-
RhsmVars
パラメーターが含まれるオーバークラウドのサブスクリプション管理用環境ファイルを編集します。通常、このファイルのデフォルト名はrhsm.yml
です。 サブスクリプション管理の設定で
rhsm_release
パラメーターを確認します。このパラメーターが設定されていない場合は、このパラメーターを追加してパラメーターを 8.2 に設定します。parameter_defaults: RhsmVars: … rhsm_username: "myusername" rhsm_password: "p@55w0rd!" rhsm_org_id: "1234567" rhsm_pool_ids: "1a85f9223e3d5e43013e3d6e8ff506fd" rhsm_method: "portal" rhsm_release: "8.2"
- オーバークラウドのサブスクリプション管理用環境ファイルを保存します。
オーバークラウドの静的なインベントリーファイルを作成します。
$ tripleo-ansible-inventory --ansible_ssh_user heat-admin --static-yaml-inventory ~/inventory.yaml
デフォルトのオーバークラウド名
overcloud
以外のオーバークラウド名を使用する場合は、--plan
オプションを使用して実際のオーバークラウドの名前を設定します。すべてのノードで、オペレーティングシステムのバージョンを Red Hat Enterprise Linux 8.2 にロックするタスクが含まれる Playbook を作成します。
$ cat > ~/set_release.yaml <<'EOF' - hosts: all gather_facts: false tasks: - name: set release to 8.2 command: subscription-manager release --set=8.2 become: true EOF
set_release.yaml
Playbook を実行します。$ ansible-playbook -i ~/inventory.yaml -f 25 ~/set_release.yaml --limit <undercloud>,<Controller>,<Compute>
-
--limit
オプションを使用して、コンテンツをすべての RHOSP ノードに適用します。<undercloud>
、<Controller>
、<Compute>
を、それらのノードを含む環境内の Ansible グループに置き換えます。 - これらのノードに別のサブスクリプションを使用している場合は、Ceph Storage ノードに対してこの Playbook を実行することはできません。
-
手動でノードを特定のバージョンにロックするには、ノードにログインして subscription-manager release
コマンドを実行します。
$ sudo subscription-manager release --set=8.2
2.2. EUS リポジトリーから TUS リポジトリーへの変更
Red Hat OpenStack Platform サブスクリプションには、Red Hat Enterprise Linux 8.2 Extended Update Support (EUS) のリポジトリーが含まれます。2022 年 4 月 30 日以降、メンテナンスサポートを受けるには、RHEL 8.2 Telecommunications Update Service (TUS) リポジトリーを有効化する必要があります。TUS リポジトリーには、Red Hat Enterprise Linux 8.2 の最新のセキュリティーパッチとバグ修正が含まれています。更新を実行する前に、以下のリポジトリーに切り替えます。
EUS リポジトリー | TUS リポジトリー |
---|---|
rhel-8-for-x86_64-baseos-eus-rpms | rhel-8-for-x86_64-baseos-tus-rpms |
rhel-8-for-x86_64-appstream-eus-rpms | rhel-8-for-x86_64-appstream-tus-rpms |
rhel-8-for-x86_64-highavailability-eus-rpms | rhel-8-for-x86_64-highavailability-tus-rpms |
特定バージョンの Podman との互換性を維持するには、TUS リポジトリーを使用する必要があります。より新しいバージョンの Podman は、Red Hat Open Stack Platform 16.1 のリリースに対してテストされておらず、予期せぬ結果を招く可能性があります。
前提条件
- RHOSP 16.1 EUS サブスクリプション
手順
-
アンダークラウドに
stack
ユーザーとしてログインします。 stackrc
ファイルを取得します。$ source ~/stackrc
-
RhsmVars
パラメーターが含まれるオーバークラウドのサブスクリプション管理用環境ファイルを編集します。通常、このファイルのデフォルト名はrhsm.yml
です。 サブスクリプション管理の設定で
rhsm_repos
パラメーターを確認します。このパラメーターに TUS リポジトリーが含まれていない場合、該当するリポジトリーを TUS バージョンに変更します。parameter_defaults: RhsmVars: rhsm_repos: - rhel-8-for-x86_64-baseos-tus-rpms - rhel-8-for-x86_64-appstream-tus-rpms - rhel-8-for-x86_64-highavailability-tus-rpms - ansible-2.9-for-rhel-8-x86_64-rpms - advanced-virt-for-rhel-8-x86_64-rpms - openstack-16.1-for-rhel-8-x86_64-rpms - rhceph-4-tools-for-rhel-8-x86_64-rpms - fast-datapath-for-rhel-8-x86_64-rpms
- オーバークラウドのサブスクリプション管理用環境ファイルを保存します。
オーバークラウドの静的なインベントリーファイルを作成します。
$ tripleo-ansible-inventory --ansible_ssh_user heat-admin --static-yaml-inventory ~/inventory.yaml
デフォルトのオーバークラウド名
overcloud
以外のオーバークラウド名を使用する場合は、--plan
オプションを使用して実際のオーバークラウドの名前を設定します。すべてのノードで、リポジトリーを Red Hat Enterprise Linux 8.2 TUS に設定するタスクが含まれる Playbook を作成します。
$ cat > ~/change_tus.yaml <<'EOF' - hosts: all gather_facts: false tasks: - name: change to tus repos command: subscription-manager repos --disable=rhel-8-for-x86_64-baseos-eus-rpms --disable=rhel-8-for-x86_64-appstream-eus-rpms --disable=rhel-8-for-x86_64-highavailability-eus-rpms --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 become: true EOF
change_tus.yaml
Playbook を実行します。$ ansible-playbook -i ~/inventory.yaml -f 25 ~/change_tus.yaml --limit <undercloud>,<Controller>,<Compute>
-
--limit
オプションを使用して、コンテンツをすべての RHOSP ノードに適用します。<undercloud>
、<Controller>
、<Compute>
を、それらのノードを含む環境内の Ansible グループに置き換えます。 - これらのノードに別のサブスクリプションを使用している場合は、Ceph Storage ノードに対してこの Playbook を実行することはできません。
-
2.3. Red Hat Openstack Platform および Ansible リポジトリーの更新
Red Hat OpenStack Platform 16.1 パッケージおよび Ansible 2.9 パッケージを使用するようにリポジトリーを更新します。
手順
-
アンダークラウドに
stack
ユーザーとしてログインします。 stackrc
ファイルを取得します。$ source ~/stackrc
-
RhsmVars
パラメーターが含まれるオーバークラウドのサブスクリプション管理用環境ファイルを編集します。通常、このファイルのデフォルト名はrhsm.yml
です。 サブスクリプション管理の設定で
rhsm_repos
パラメーターを確認します。rhsm_repos
パラメーターで Red Hat OpenStack Platform 16.0 リポジトリーおよび Ansible 2.8 リポジトリーが使用されている場合は、リポジトリーを正しいバージョンに変更します。parameter_defaults: RhsmVars: rhsm_repos: - rhel-8-for-x86_64-baseos-tus-rpms - rhel-8-for-x86_64-appstream-tus-rpms - rhel-8-for-x86_64-highavailability-tus-rpms - ansible-2.9-for-rhel-8-x86_64-rpms - advanced-virt-for-rhel-8-x86_64-rpms - openstack-16.1-for-rhel-8-x86_64-rpms - fast-datapath-for-rhel-8-x86_64-rpms
- オーバークラウドのサブスクリプション管理用環境ファイルを保存します。
オーバークラウドの静的なインベントリーファイルを作成します。
$ tripleo-ansible-inventory --ansible_ssh_user heat-admin --static-yaml-inventory ~/inventory.yaml
デフォルトのオーバークラウド名
overcloud
以外のオーバークラウド名を使用する場合は、--plan
オプションを使用して実際のオーバークラウドの名前を設定します。すべてのノードで、リポジトリーを Red Hat OpenStack Platform 16.1 に設定するタスクが含まれる Playbook を作成します。
$ cat > ~/update_rhosp_repos.yaml <<'EOF' - hosts: all gather_facts: false tasks: - name: change osp repos command: subscription-manager repos --disable=openstack-16-for-rhel-8-x86_64-rpms --enable=openstack-16.1-for-rhel-8-x86_64-rpms --disable=ansible-2.8-for-rhel-8-x86_64-rpms --enable=ansible-2.9-for-rhel-8-x86_64-rpms become: true EOF
update_rhosp_repos.yaml
Playbook を実行します。$ ansible-playbook -i ~/inventory.yaml -f 25 ~/update_rhosp_repos.yaml --limit <undercloud>,<Controller>,<Compute>
-
--limit
オプションを使用して、コンテンツをすべての RHOSP ノードに適用します。<undercloud>
、<Controller>
、<Compute>
を、それらのノードを含む環境内の Ansible グループに置き換えます。 - これらのノードに別のサブスクリプションを使用している場合は、Ceph Storage ノードに対してこの Playbook を実行することはできません。
-
すべてのノードで、リポジトリーを Red Hat OpenStack Platform 16.1 に設定するタスクが含まれる Playbook を作成します。
$ cat > ~/update_ceph_repos.yaml <<'EOF' - hosts: all gather_facts: false tasks: - name: change ceph repos command: subscription-manager repos --disable=openstack-16-deployment-tools-for-rhel-8-x86_64-rpms --enable=openstack-16.1-deployment-tools-for-rhel-8-x86_64-rpms --disable=ansible-2.8-for-rhel-8-x86_64-rpms --enable=ansible-2.9-for-rhel-8-x86_64-rpms become: true EOF
update_ceph_repos.yaml
Playbook を実行します。$ ansible-playbook -i ~/inventory.yaml -f 25 ~/update_ceph_repos.yaml --limit CephStorage
--limit
オプションを使用して、コンテンツを Ceph Storage ノードに適用します。
2.4. container-tools のバージョンの設定
container-tools
モジュールをバージョン2.0
に設定して、すべてのノードで正しいパッケージバージョンを使用するようにします。
手順
-
アンダークラウドに
stack
ユーザーとしてログインします。 stackrc
ファイルを取得します。$ source ~/stackrc
オーバークラウドの静的なインベントリーファイルを作成します。
$ tripleo-ansible-inventory --ansible_ssh_user heat-admin --static-yaml-inventory ~/inventory.yaml
デフォルトのオーバークラウド名
overcloud
以外のオーバークラウド名を使用する場合は、--plan
オプションを使用して実際のオーバークラウドの名前を設定します。すべてのノードで
container-tools
モジュールをバージョン2.0
に設定するタスクが含まれる Playbook を作成します。$ cat > ~/container-tools.yaml <<'EOF' - hosts: all gather_facts: false tasks: - name: disable default dnf module for container-tools command: dnf module reset -y container-tools become: true - name: set dnf module for container-tools:2.0 command: dnf module enable -y container-tools:2.0 become: true EOF
すべてのノードに対して
container-tools.yaml
Playbook を実行します。$ ansible-playbook -i ~/inventory.yaml -f 25 ~/container-tools.yaml
2.5. コンテナーイメージ準備ファイルの更新
コンテナー準備ファイルは、ContainerImagePrepare
パラメーターが含まれるファイルです。このファイルを使用して、アンダークラウドおよびオーバークラウドのコンテナーイメージを取得する際のルールを定義します。環境を更新する前に、ファイルを確認して正しいイメージバージョンを取得するようにしてください。
手順
-
コンテナー準備ファイルを編集します。通常、このファイルのデフォルト名は
containers-prepare-parameter.yaml
です。 それぞれのルールセットについて、
tag
パラメーターが16.1
に設定されていることを確認します。parameter_defaults: ContainerImagePrepare: - push_destination: true set: … tag: '16.1' tag_from_label: '{version}-{release}'
更新に特定のタグ (16.1
や 16.1.2
等) を使用しない場合は、tag
キーと値のペアを削除し、tag_from_label
のみを指定します。これにより、更新プロセスの一部として使用するタグの値を決定する際に、インストールされた Red Hat OpenStack Platform バージョンが使用されます。
- このファイルを保存します。
2.6. SSL/TLS 設定の更新
resource_registry
から NodeTLSData
リソースを削除して、SSL/TLS 設定を更新します。
手順
-
アンダークラウドに
stack
ユーザーとしてログインします。 stackrc
ファイルを取得します。$ source ~/stackrc
-
カスタムのオーバークラウド SSL/TLS パブリックエンドポイントファイルを編集します。通常、このファイルの名前は
~/templates/enable-tls.yaml
です。 '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
セクションをすべて削除します。- SSL/TLS パブリックエンドポイントファイルを保存します。
2.7. オーバークラウドでのフェンシングの無効化
オーバークラウドを更新する前に、フェンシングが無効になっていることを確認します。
コントローラーノードの更新プロセス中にフェンシングが環境にデプロイされると、オーバークラウドは特定ノードが無効であることを検出し、フェンシング操作を試みる場合があります。これにより、意図しない結果が生じる可能性があります。
オーバークラウドでフェンシングを有効にしている場合には、意図しない結果を防ぐために、更新期間中フェンシングを一時的に無効にする必要があります。
手順
-
アンダークラウドに
stack
ユーザーとしてログインします。 source コマンドで
stackrc
ファイルを読み込みます。$ source ~/stackrc
コントローラーノードにログインし、Pacemaker コマンドを実行してフェンシングを無効にします。
$ ssh heat-admin@CONTROLLER_IP "sudo pcs property set stonith-enabled=false"
-
fencing.yaml
環境ファイルで、EnableFencing
パラメーターをfalse
に設定し、更新プロセス中にフェンシングが無効のままとなるようにします。
第3章 アンダークラウドの更新
以下の手順では、アンダークラウドおよびそのオーバークラウドイメージを最新の Red Hat OpenStack Platform 16.1 バージョンに更新します。
3.1. コンテナー化されたアンダークラウドのマイナー更新の実施
director では、アンダークラウドノード上の主要なパッケージを更新するためのコマンドが提供されています。これにより、OpenStack Platform 環境の現行バージョン内のマイナー更新を実行することができます。
手順
-
director に
stack
ユーザーとしてログインします。 dnf
コマンドを実行して、director の主要なパッケージをアップグレードします。$ sudo dnf update -y python3-tripleoclient* tripleo-ansible ansible
director は
openstack undercloud upgrade
コマンドを使用して、アンダークラウドの環境を更新します。以下のコマンドを実行します。$ openstack undercloud upgrade
- アンダークラウドのアップグレードプロセスが完了するまで待ちます。
アンダークラウドをリブートして、オペレーティングシステムのカーネルとその他のシステムパッケージを更新します。
$ sudo reboot
- ノードがブートするまで待ちます。
3.2. オーバークラウドイメージの更新
現在のオーバークラウドイメージを新しいバージョンに置き換える必要があります。新しいイメージにより、director は最新バージョンの OpenStack Platform ソフトウェアを使用してノードのイントロスペクションとプロビジョニングを行うことができるようになります。
前提条件
- アンダークラウドが最新バージョンに更新されていること
手順
stackrc
ファイルを取得します。$ source ~/stackrc
stack
ユーザーのホーム下のimages
ディレクトリー (/home/stack/images
) から既存のイメージを削除します。$ rm -rf ~/images/*
アーカイブをデプロイメントします。
$ cd ~/images $ for i in /usr/share/rhosp-director-images/overcloud-full-latest-16.1.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-16.1.tar; do tar -xvf $i; done $ cd ~
director に最新のイメージをインポートします。
$ openstack overcloud image upload --update-existing --image-path /home/stack/images/
ノードが新しいイメージを使用するように設定します。
$ openstack overcloud node configure $(openstack baremetal node list -c UUID -f value)
新規イメージが存在することを確認します。
$ openstack image list $ ls -l /var/lib/ironic/httpboot
- オーバークラウドノードをデプロイする際には、オーバークラウドイメージのバージョンが該当する heat テンプレートバージョンに対応している状態にします。たとえば、RHOSP 16.1 heat テンプレートでは RHOSP 16.1 イメージのみを使用します。
-
Red Hat カスタマーポータルまたは Red Hat Satellite Server を使用する接続環境をデプロイした場合、オーバークラウドのイメージとパッケージリポジトリーのバージョンが同期していない可能性があります。オーバークラウドのイメージとパッケージリポジトリーのバージョンが一致していることを確認するには、
virt-customize
ツールを使用できます。詳細は、Red Hat ナレッジベースで Modifying the Red Hat Linux OpenStack Platform Overcloud Image with virt-customize のソリューションを参照してください。 -
新しい
overcloud-full
イメージは、古いovercloud-full
イメージを置き換えます。古いイメージに変更を加えた場合、特に今後新規ノードをデプロイする場合は、新しいイメージで変更を繰り返す必要があります。
3.3. アンダークラウドアップグレード後の注意事項
-
stack
ユーザーのホームディレクトリーでコアテンプレートのローカルセットを使用している場合には、Advanced Overcloud Customizationの Using Customized Core Heat Templates に記載の推奨ワークフローを使用して、テンプレートを更新するようにしてください。オーバークラウドをアップグレードする前に、ローカルコピーを更新する必要があります。
第4章 オーバークラウドの更新
アンダークラウドを更新した後、オーバークラウドとコンテナーイメージの準備コマンドを実行し、ノードを更新し、オーバークラウドの更新収束
コマンドを実行してオーバークラウドを更新できます。コントロールプレーン API は、マイナー更新中もすべて利用できます。
前提条件
- アンダークラウドが最新バージョンに更新されていること
4.1. オーバークラウドの更新準備タスクの実施
更新プロセスに向けてオーバークラウドを準備するには、openstack overcloud update prepare
のコマンドを実行して、以下のタスクを実施します。
- オーバークラウドのプランを OpenStack Platform 16.1 に更新する。
- 更新に向けてノードを準備する
前提条件
-
Ceph のサブスクリプションを使用し、Ceph ストレージノード用に
overcloud-minimal
イメージを使用するように director を設定している場合、roles_data.yaml
ロール定義ファイルでrhsm_enforce
パラメーターがFalse
に設定されていることを確認する。 -
カスタム NIC テンプレートをレンダリングした場合は、オーバークラウドのバージョンとの非互換性を回避するために、
openstack-tripleo-heat-templates
コレクションの更新バージョンでテンプレートを再生成する必要があります。カスタム NIC テンプレートの詳細は、オーバークラウドの高度なカスタマイズ ガイドの カスタマイズのためのデフォルトのネットワークインターフェイステンプレートのレンダリング を参照してください。
手順
stackrc
ファイルを取得します。$ source ~/stackrc
更新準備コマンドを実行します。
$ openstack overcloud update prepare \ --templates \ --stack <stack_name> \ -r <roles_data_file> \ -n <network_data_file> \ -e <environment_file> \ -e <environment_file> \ …
以下のオプションの中で、お使いの環境に適切なオプションを追加します。
-
オーバークラウドスタックの名前がデフォルトの名前
overcloud
とは異なる場合は、更新の準備コマンドに--stack
オプションを追加し、<stack_name>
を実際のスタック名に置き換えます。 -
専用のカスタムロールを使用する場合は、カスタムロール (
<roles_data>) ファイル
を追加します (-r
)。 -
カスタムネットワークを使用する場合は、コンポーザブルネットワーク (
_<network_data>) ファイル _
を追加します (-n
)。 -
高可用性クラスターをデプロイする場合は、更新の準備コマンドに
--ntp-server
オプションを追加するか、環境ファイルにNtpServer
パラメーターおよび値を追加します。 -
すべてのカスタム設定環境ファイル (
-e
)
-
オーバークラウドスタックの名前がデフォルトの名前
- 更新の準備が完了するまで待ちます。
4.2. コンテナーイメージ準備タスクの実行
オーバークラウドの更新を実行するには、最新の OpenStack Platform 16.1 のコンテナーイメージが必要です。そのためには、container_image_prepare
外部更新プロセスを実行します。このプロセスを実行するには、container_image_prepare
にタグ付けされたタスクに対して openstack overcloud external-update run
コマンドを実行します。これらのタスクにより以下のアクションが実施されます。
- お使いの環境に該当するすべてのコンテナーイメージ設定を自動的に準備する。
- 事前にこのオプションを無効にしていない限り、該当するコンテナーイメージをアンダークラウドにプルする。
デフォルトのスタック名 (overcloud
) を使用していない場合は、--stack <stack_name>
オプションでスタック名を設定します。<stack_name>
は実際のスタック名に置き換えます。
手順
stackrc
ファイルを取得します。$ source ~/stackrc
container_image_prepare
にタグ付けされたタスクに対してopenstack overcloud external-update run
コマンドを実行します。$ openstack overcloud external-update run --stack <stack_name> --tags container_image_prepare
4.3. オプション: すべてのオーバークラウドサーバーでの ovn-controller コンテナーの更新
Modular Layer 2 Open Virtual Network メカニズムドライバー (ML2/OVN) を使用してオーバークラウドをデプロイした場合は、ovn-controller コンテナーを最新の RHOSP 16.1 バージョンに更新します。更新は、ovn-controller コンテナーを実行するすべてのオーバークラウドサーバーで行われます。
デフォルトのスタック名 (overcloud
) を使用していない場合は、--stack <stack_name>
オプションでスタック名を設定します。<stack_name>
は実際のスタック名に置き換えます。
手順
-
アンダークラウドに
stack
ユーザーとしてログインします。 stackrc
ファイルを取得します。$ source ~/stackrc
ovn タグを持つタスクに対して openstack overcloud external-update run コマンドを実行します。
$ openstack overcloud external-update run --stack <stack_name> --tags ovn
- ovn-controller コンテナーの更新が完了するまで待ちます。
4.4. すべてのコントローラーノードの更新
以下の手順では、すべてのコントローラーノードを最新バージョンの OpenStack Platform 16.1 に更新します。このプロセスでは、--limit Controllerer
オプションを指定して openstack overcloud update run
コマンドを実行し、操作をコントローラーノードだけに制限します。コントロールプレーン API は、マイナー更新中もすべて利用できます。
BZ#1872404 が解決されるまで、コンポーザブルロールに基づくノードについては、先ず Database
ロールを更新してから、Controller
、Messaging
、Compute
、Ceph
、およびその他のロールを更新する必要があります。
デフォルトのスタック名 (overcloud
) を使用していない場合は、--stack <stack_name>
オプションでスタック名を設定します。<stack_name>
は実際のスタック名に置き換えます。
手順
stackrc
ファイルを取得します。$ source ~/stackrc
更新コマンドを実行します。
$ openstack overcloud update run --stack <stack_name> --limit Controller
- コントローラーノードの更新が完了するまで待ちます。
4.5. すべてのコンピュートノードの更新
以下の手順では、すべてのコンピュートノードを最新バージョンの OpenStack Platform 16.1 に更新します。このプロセスは、openstack overcloud update run
コマンドに --limit Compute
オプションを指定して、操作をコンピュートノードのみに制限して実行する必要があります。
- 並列処理に関する考慮事項
多数のコンピュートノードをアップグレードする場合は、パフォーマンスを向上させるために、
--limit Compute
オプションを指定してopenstack overcloud upgrade run
コマンドを実行し、20 ノードのバッチを並行して処理することができます。たとえば、デプロイメントに 80 のコンピュートノードがある場合、次のコマンドを実行して、コンピュートノードを並行して更新できます。$ openstack overcloud update run -y --limit 'Compute[0:19]' > update-compute-0-19.log 2>&1 & $ openstack overcloud update run -y --limit 'Compute[20:39]' > update-compute-20-39.log 2>&1 & $ openstack overcloud update run -y --limit 'Compute[40:59]' > update-compute-40-59.log 2>&1 & $ openstack overcloud update run -y --limit 'Compute[60:79]' > update-compute-60-79.log 2>&1 &
'Compute[0:19]'
、'Compute[20:39]'
、'Compute[40:59]'
、および'Compute[60:79]'
のノード領域分割方法はランダムで、更新されるノードを制御することはできません。特定のコンピュートノードを更新するには、バッチで更新するノードをコンマ区切りリストで指定します。
$ openstack overcloud update run --limit <Compute0>,<Compute1>,<Compute2>,<Compute3>
デフォルトのスタック名 (overcloud
) を使用していない場合は、--stack <stack_name>
オプションでスタック名を設定します。<stack_name>
は実際のスタック名に置き換えます。
手順
stackrc
ファイルを取得します。$ source ~/stackrc
更新コマンドを実行します。
$ openstack overcloud update run --stack <stack_name> --limit Compute
- コンピュートノードの更新が完了するまで待ちます。
4.6. 全 HCI コンピュートノードの更新
以下の手順では、ハイパーコンバージドインフラストラクチャー (HCI) コンピュートノードを更新します。このプロセスでは、以下の操作を行います。
-
openstack overcloud update run
コマンドに--limit ComputeHCI
オプションを指定して、操作を HCI ノードのみに制限して実行する -
openstack overcloud external-update run --tags ceph
コマンドを実行し、コンテナー化された Red Hat Ceph Storage 4 クラスターへの更新を実施する
デフォルトのスタック名 (overcloud
) を使用していない場合は、--stack <stack_name>
オプションでスタック名を設定します。<stack_name>
は実際のスタック名に置き換えます。
前提条件
ceph-mon
サービスを実行している Ceph Monitor または Controller ノードで、Red Hat Ceph Storage クラスターのステータスが正常であり、pg ステータスがactive+clean
であることを確認する。$ sudo podman exec -it ceph-mon-controller-0 ceph -s
Ceph クラスターが正常な場合、
HEALTH_OK
のステータスが返されます。Ceph クラスターのステータスが異常な場合、
HEALTH_WARN
またはHEALTH_ERR
のステータスを返す。トラブルシューティングのガイダンスについては、Red Hat Ceph Storage 4 トラブルシューティングガイドを 参照してください。
手順
stackrc
ファイルを取得します。$ source ~/stackrc
更新コマンドを実行します。
$ openstack overcloud update run --stack <stack_name> --limit ComputeHCI
- ノードの更新が完了するまで待ちます。
Ceph Storage の更新コマンドを実行します。以下に例を示します。
$ openstack overcloud external-update run --stack <stack_name> --tags ceph
- コンピュート HCI ノードの更新が完了するまで待ちます。
4.7. すべての Ceph Storage ノードの更新
以下の手順では、Ceph Storage ノードを更新します。このプロセスでは、以下の操作を行います。
-
openstack overcloud update run
コマンドに--limit CephStorage
オプションを指定して、操作を Ceph Storage ノードのみに制限して実行する -
openstack overcloud external-update run
コマンドを実行して外部プロセスとしてceph-ansible
を実行し、Red Hat Ceph Storage 3 コンテナーを更新する。
RHOSP 16.1 は RHEL 8.2 でサポートされています。ただし、Ceph Storage ロールにマップされているホストは、最新のメジャー RHEL リリースに更新されます。詳細は、Red Hat Ceph Storage: サポートされる設定 を参照してください。
デフォルトのスタック名 (overcloud
) を使用していない場合は、--stack <stack_name>
オプションでスタック名を設定します。<stack_name>
は実際のスタック名に置き換えます。
前提条件
ceph-mon
サービスを実行している Ceph Monitor または Controller ノードで、Red Hat Ceph Storage クラスターのステータスが正常であり、pg ステータスがactive+clean
であることを確認する。$ sudo podman exec -it ceph-mon-controller-0 ceph -s
Ceph クラスターが正常な場合、
HEALTH_OK
のステータスが返されます。Ceph クラスターのステータスが異常な場合、
HEALTH_WARN
またはHEALTH_ERR
のステータスを返す。トラブルシューティングのガイダンスについては、Red Hat Ceph Storage 4 トラブルシューティングガイドを 参照してください。
手順
stackrc
ファイルを取得します。$ source ~/stackrc
グループノードを更新します。
グループ内のすべてのノードを更新するには、以下のコマンドを実行します。
$ openstack overcloud update run --limit <GROUP_NAME>
グループ内の単一ノードを更新するには、以下のコマンドを実行します。
$ openstack overcloud update run --limit <GROUP_NAME> [NODE_INDEX]
注記ノードを個別に更新する場合は、必ずすべてのノードを更新してください。
グループ内の最初のノードのインデックスはゼロ (0) です。たとえば、
CephStorage
という名前のグループの最初のノードを更新するには、以下のコマンドを実行します。openstack overcloud update run --limit CephStorage[0]
- ノードの更新が完了するまで待ちます。
Ceph Storage コンテナーの更新コマンドを実行します。
$ openstack overcloud external-update run --tags ceph
- Ceph Storage コンテナーの更新が完了するまで待ちます。
4.8. データベースのオンライン更新の実施
一部のオーバークラウドコンポーネントでは、データベーステーブルのオンラインアップグレード (または移行) が必要です。そのためには、online_upgrade
外部更新プロセスを実行します。このプロセスを実行するには、online_upgrade
にタグ付けされたタスクに対して openstack overcloud external-update run
コマンドを実行します。これにより、以下のコンポーネントに対してデータベースのオンライン更新が実行されます。
- OpenStack Block Storage (cinder)
- OpenStack Compute (nova)
手順
stackrc
ファイルを取得します。$ source ~/stackrc
online_upgrade
のタグを使用するタスクに対してopenstack overcloud external-update run
コマンドを実行します。$ openstack overcloud external-update run --tags online_upgrade
4.9. 更新の最終処理
更新には、オーバークラウドスタックを更新する最終ステップが必要です。これにより、スタックのリソース構造が OpenStackPlatform 16.1 の標準のデプロイメントと一致し、今後、通常の openstack overcloud deploy
の機能を実行できるようになります。
手順
stackrc
ファイルを取得します。$ source ~/stackrc
-
オーバークラウドでフェンシングを再度有効にするには、
fencing.yaml
環境ファイルで、EnableFencing
パラメーターをtrue
に設定します。 更新の最終処理のコマンドを実行します。
$ openstack overcloud update converge \ --templates \ --stack <stack_name> \ -r <roles_data_file> \ -n <network_data_file> \ -e <environment_file> \ -e <environment_file> \ ... ...
以下のオプションの中で、お使いの環境に適切なオプションを追加します。
-
EnableFencing
パラメーターがtrue
に設定されたfencing.yaml
環境ファイル。 -
オーバークラウドスタックの名前がデフォルトの名前
overcloud
とは異なる場合は、更新の準備コマンドに--stack
オプションを追加し、<stack_name>
を実際のスタック名に置き換えます。 -
専用のカスタムロールを使用する場合は、カスタムロール (
<roles_data>
) のファイルを追加します (-r
) -
カスタムネットワークを使用する場合は、コンポーザブルネットワーク (
<network_data>
) のファイルを追加します (-n
) -
すべてのカスタム設定環境ファイル (
-e
)
-
- 更新の最終処理が完了するまで待ちます。
第5章 オーバークラウドのリブート
Red Hat OpenStack バージョンのマイナー更新後に、オーバークラウドをリブートします。リブートにより、関連付けられたカーネル、システムレベル、およびコンテナーコンポーネントの更新と共にノードがリフレッシュされます。これらの更新により、パフォーマンスとセキュリティー上のメリットが得られます。
ダウンタイムを計画して、以下のリブート手順を実施します。
5.1. コントローラーノードおよびコンポーザブルノードのリブート
コントローラーノードおよびコンポーザブルロールに基づくスタンドアロンのノードをリブートするには、以下の手順を実施します。ただし、これにはコンピュートノードおよび Ceph Storage ノードは含まれません。
手順
- リブートするノードにログインします。
オプション: ノードが Pacemaker リソースを使用している場合は、クラスターを停止します。
[heat-admin@overcloud-controller-0 ~]$ sudo pcs cluster stop
ノードをリブートします。
[heat-admin@overcloud-controller-0 ~]$ sudo reboot
- ノードがブートするまで待ちます。
サービスを確認します。以下に例を示します。
ノードが Pacemaker サービスを使用している場合には、ノードがクラスターに再度加わったかどうかを確認します。
[heat-admin@overcloud-controller-0 ~]$ sudo pcs status
ノードが Systemd サービスを使用している場合は、すべてのサービスが有効化されていることを確認します。
[heat-admin@overcloud-controller-0 ~]$ sudo systemctl status
ノードがコンテナー化されたサービスを使用している場合は、ノード上の全コンテナーがアクティブであることを確認します。
[heat-admin@overcloud-controller-0 ~]$ sudo podman ps
5.2. Ceph Storage (OSD) クラスターの再起動
Ceph Storage (OSD) ノードのクラスターを再起動するには、以下の手順を実施します。
前提条件
ceph-mon
サービスを実行している Ceph Monitor または Controller ノードで、Red Hat Ceph Storage クラスターのステータスが正常であり、pg ステータスがactive+clean
であることを確認する。$ sudo podman exec -it ceph-mon-controller-0 ceph -s
Ceph クラスターが正常な場合、
HEALTH_OK
のステータスが返されます。Ceph クラスターのステータスが異常な場合、
HEALTH_WARN
またはHEALTH_ERR
のステータスを返す。トラブルシューティングのガイダンスについては、Red Hat Ceph Storage 4 トラブルシューティングガイドを 参照してください。
手順
ceph-mon
サービスを実行している Ceph Monitor または Controller ノードにログインし、Ceph Storage クラスターのリバランスを一時的に無効にします。$ sudo podman exec -it ceph-mon-controller-0 ceph osd set noout $ sudo podman exec -it ceph-mon-controller-0 ceph osd set norebalance
注記マルチスタックまたは分散コンピュートノード (DCN) アーキテクチャーを使用している場合は、
noout
フラグとnorebalance
フラグの設定時にクラスター名を指定する必要があります。例:sudo podman exec -it ceph-mon-controller-0 ceph osd set noout --cluster <cluster_name>
- 再起動する最初の Ceph Storage ノードを選択し、そのノードにログインします。
ノードを再起動します。
$ sudo reboot
- ノードがブートするまで待ちます。
ノードにログインして、クラスターのステータスを確認します。
$ sudo podman exec -it ceph-mon-controller-0 ceph status
pgmap
により、すべてのpgs
が正常な状態 (active+clean
) として報告されることを確認します。- ノードからログアウトして、次のノードをリブートし、ステータスを確認します。全 Ceph Storage ノードがリブートされるまで、このプロセスを繰り返します。
完了したら、
ceph-mon
サービスを実行している Ceph Monitor または Controller ノードにログインし、クラスターの再調整を再度有効にします。$ sudo podman exec -it ceph-mon-controller-0 ceph osd unset noout $ sudo podman exec -it ceph-mon-controller-0 ceph osd unset norebalance
注記マルチスタックまたは分散コンピュートノード (DCN) アーキテクチャーを使用している場合は、
noout
フラグとnorebalance
フラグの設定解除時にクラスター名を指定する必要があります。例:sudo podman exec -it ceph-mon-controller-0 ceph osd set noout --cluster <cluster_name>
最終のステータスチェックを実行して、クラスターが
HEALTH_OK
を報告していることを確認します。$ sudo podman exec -it ceph-mon-controller-0 ceph status
5.3. コンピュートノードの再起動
コンピュートノードをリブートするには、以下の手順を実施します。Red Hat OpenStack Platform 環境内のインスタンスのダウンタイムを最小限に抑えるために、この手順には、リブートするコンピュートノードからインスタンスを移行するステップも含まれています。これは、以下のワークフローを伴います。
- コンピュートノードをリブートする前に、インスタンスを別のノードに移行するかどうかを決定する。
- リブートするコンピュートノードを選択して無効にし、新規インスタンスをプロビジョニングしないようにする。
- インスタンスを別のコンピュートノードに移行する。
- 空のコンピュートノードを再起動します。
- 空のコンピュートノードを有効にします。
前提条件
コンピュートノードをリブートする前に、ノードをリブートする間インスタンスを別のコンピュートノードに移行するかどうかを決定する必要があります。
コンピュートノード間で仮想マシンインスタンスを移行する際に受ける可能性のある移行の制約のリストを確認してください。詳細は、Configuring the Compute Service for Instance Creation の Migration constraints を参照してください。
インスタンスを移行できない場合は、以下のコアテンプレートパラメーターを設定して、コンピュートノード再起動後のインスタンスの状態を制御する。
NovaResumeGuestsStateOnHostBoot
-
リブート後のコンピュートノードで、インスタンスを同じ状態に戻すか定義します。
False
に設定すると、インスタンスは停止した状態を維持し、手動で起動する必要があります。デフォルト値はFalse
です。 NovaResumeGuestsShutdownTimeout
-
再起動する前に、インスタンスのシャットダウンを待つ秒数。この値を
0
に設定することは推奨されません。デフォルト値は 300 です。
オーバークラウドパラメーターおよびその使用方法についての詳細は、オーバークラウドのパラメーター を参照してください。
手順
-
アンダークラウドに
stack
ユーザーとしてログインします。 全コンピュートノードとその UUID をリスト表示します。
$ source ~/stackrc (undercloud) $ openstack server list --name compute
リブートするコンピュートノードの UUID を特定します。
アンダークラウドから、コンピュートノードを選択します。そのノードを無効にします。
$ source ~/overcloudrc (overcloud) $ openstack compute service list (overcloud) $ openstack compute service set <hostname> nova-compute --disable
コンピュートノード上の全インスタンスをリスト表示します。
(overcloud) $ openstack server list --host <hostname> --all-projects
- インスタンスを移行しない場合は、このステップ に進みます。
インスタンスを別のコンピュートノードに移行する場合には、以下のコマンドのいずれかを使用します。
インスタンスを別のホストに移行する。
(overcloud) $ openstack server migrate <instance_id> --live <target_host> --wait
nova-scheduler
がターゲットホストを自動的に選択できるようにします。(overcloud) $ nova live-migration <instance_id>
すべてのインスタンスを一度にライブマイグレーションします。
$ nova host-evacuate-live <hostname>
注記nova
コマンドで非推奨の警告が表示される可能性がありますが、無視しても問題ありません。
- 移行が完了するまで待ちます。
移行が正常に完了したことを確認します。
(overcloud) $ openstack server list --host <hostname> --all-projects
- 選択したコンピュートノードのインスタンスがなくなるまで、移行を続けます。
コンピュートノードにログインして、ノードをリブートします。
[heat-admin@overcloud-compute-0 ~]$ sudo reboot
- ノードが起動するまで待ちます。
コンピュートノードを再度有効にします。
$ source ~/overcloudrc (overcloud) $ openstack compute service set <hostname> nova-compute --enable
コンピュートノードが有効であることを確認します。
(overcloud) $ openstack compute service list