11.11. オーバークラウドの再起動
最新の 17.1 バージョンへの Red Hat OpenStack Platform (RHOSP) のマイナー更新実行後、オーバークラウドを再起動します。リブートにより、関連付けられたカーネル、システムレベル、およびコンテナーコンポーネントの更新と共にノードがリフレッシュされます。これらの更新により、パフォーマンスとセキュリティー上のメリットが得られます。ダウンタイムを計画して、再起動手順を実施します。
以下のガイドを使用して、さまざまなノードのタイプを再起動する方法を説明します。
- 1 つのロールで全ノードを再起動する場合は、各ノードを個別に再起動します。ロールの全ノードを同時に再起動すると、その操作中サービスにダウンタイムが生じる場合があります。
次の順序でノードの再起動の手順を完了します。
11.11.1. コントローラーノードおよびコンポーザブルノードの再起動
設定可能なロールに基づいて Controller ノードとスタンドアロンノードを再起動し、Compute ノードと Ceph ストレージノードを除外します。
手順
- 再起動するノードにログインします。
オプション: ノードが Pacemaker リソースを使用している場合は、クラスターを停止します。
[tripleo-admin@overcloud-controller-0 ~]$ sudo pcs cluster stop
ノードをリブートします。
[tripleo-admin@overcloud-controller-0 ~]$ sudo reboot
- ノードがブートするまで待ちます。
検証
サービスが有効になっていることを確認します。
ノードが Pacemaker サービスを使用している場合は、ノードがクラスターに再度加わったか確認します。
[tripleo-admin@overcloud-controller-0 ~]$ sudo pcs status
ノードが Systemd サービスを使用している場合は、すべてのサービスが有効化されていることを確認します。
[tripleo-admin@overcloud-controller-0 ~]$ sudo systemctl status
ノードがコンテナー化されたサービスを使用している場合は、ノード上の全コンテナーがアクティブであることを確認します。
[tripleo-admin@overcloud-controller-0 ~]$ sudo podman ps
11.11.2. Ceph Storage (OSD) クラスターの再起動
Ceph Storage (OSD) ノードのクラスターを再起動するには、以下の手順を実施します。
前提条件
ceph-monサービスを実行している Ceph Monitor または Controller ノードで、Red Hat Ceph Storage クラスターのステータスが正常であり、pg ステータスがactive+cleanであることを確認する。$ sudo cephadm -- shell ceph status
Ceph クラスターが正常な場合、
HEALTH_OKのステータスが返されます。Ceph クラスターのステータスが異常な場合、
HEALTH_WARNまたはHEALTH_ERRのステータスが返されます。トラブルシューティングのガイダンスは、Red Hat Ceph Storage 5 トラブルシューティングガイド または Red Hat Ceph Storage 6 トラブルシューティングガイド を参照してください。
手順
ceph-monサービスを実行している Ceph Monitor または Controller ノードにログインし、Ceph Storage クラスターのリバランスを一時的に無効にします。$ sudo cephadm shell -- ceph osd set noout $ sudo cephadm shell -- ceph osd set norebalance
注記マルチスタックまたは分散コンピュートノード (DCN) アーキテクチャーを使用している場合は、
nooutフラグとnorebalanceフラグの設定時に Ceph クラスター名を指定する必要があります。例:sudo cephadm shell -c /etc/ceph/<cluster>.conf -k /etc/ceph/<cluster>.client.keyring。- 再起動する最初の Ceph Storage ノードを選択し、そのノードにログインします。
ノードをリブートします。
$ sudo reboot
- ノードがブートするまで待ちます。
ノードにログインし、Ceph クラスターのステータスを確認します。
$ sudo cephadm -- shell ceph status
pgmapにより、すべてのpgsが正常な状態 (active+clean) として報告されることを確認します。- ノードからログアウトして、次のノードを再起動し、ステータスを確認します。全 Ceph Storage ノードが再起動されるまで、このプロセスを繰り返します。
完了したら、
ceph-monサービスを実行している Ceph Monitor または Controller ノードにログインし、クラスターのリバランスを有効にします。$ sudo cephadm shell -- ceph osd unset noout $ sudo cephadm shell -- ceph osd unset norebalance
注記マルチスタックまたは分散コンピュートノード (DCN) アーキテクチャーを使用している場合は、
nooutフラグとnorebalanceフラグの設定解除時に Ceph クラスター名を指定する必要があります。例:sudo cephadm shell -c /etc/ceph/<cluster>.conf -k /etc/ceph/<cluster>.client.keyring。最終のステータスチェックを実行して、クラスターが
HEALTH_OKを報告していることを確認します。$ sudo cephadm shell ceph status
11.11.3. Compute ノードの再起動
Red Hat OpenStack Platform (RHOSP) 環境でのインスタンスのダウンタイムを最小限に抑えるために、インスタンスの移行ワークフローでは、再起動するコンピュートノードからインスタンスを移行する時に必要な手順を概説します。
インスタンスの移行ワークフロー
- Compute ノードを再起動する前に、インスタンスを別のノードに移行するか決定します。
- 再起動する Compute ノードを選択して無効にし、新規インスタンスをプロビジョニングしないようにします。
- インスタンスを別の Compute ノードに移行します。
- 空の Compute ノードを再起動します。
- 空の Compute ノードを有効にします。
前提条件
Compute ノードを再起動する前に、ノードの再起動中にインスタンスを別の Compute ノードに移行するか決定する。
Compute ノード間で仮想マシンインスタンスを移行する際に発生する可能性のある移行の制約リストを確認する。詳細は、インスタンス作成のための Compute サービスの設定 の 移行の制約 を参照してください。
注記Multi-RHEL 環境があり、RHEL 9.2 を実行しているコンピュートノードから RHEL 8.4 を実行しているコンピュートノードに仮想マシンを移行する場合は、コールドマイグレーションのみがサポートされます。コールドマイグレーションの詳細は、インスタンス作成のための Compute サービスの設定 の インスタンスのコールドマイグレーション を参照してください。
インスタンスを移行できない場合は、以下のコアテンプレートパラメーターを設定して、Compute ノード再起動後のインスタンスの状態を制御する。
NovaResumeGuestsStateOnHostBoot-
リブート後の Compute ノードで、インスタンスを同じ状態に戻すか定義します。
Falseに設定すると、インスタンスは停止した状態を維持し、手動で起動する必要があります。デフォルト値はFalseです。 NovaResumeGuestsShutdownTimeout再起動する前に、インスタンスのシャットダウンを待つ秒数。この値を
0に設定することは推奨されません。デフォルト値は300です。オーバークラウドパラメーターおよびその使用方法の詳細は、オーバークラウドのパラメーター を参照してください。
手順
-
アンダークラウドに
stackユーザーとしてログインします。 コンピュートノードのリストを取得して、再起動するノードのホスト名を特定します。
(undercloud)$ source ~/overcloudrc (overcloud)$ openstack compute service list
再起動するコンピュートノードのホスト名を特定します。
再起動するコンピュートノード上のコンピュートサービスを無効にします。
(overcloud)$ openstack compute service list (overcloud)$ openstack compute service set <hostname> nova-compute --disable
-
<hostname>は、コンピュートノードのホスト名に置き換えます。
-
Compute ノード上の全インスタンスをリスト表示します。
(overcloud)$ openstack server list --host <hostname> --all-projects
オプション: インスタンスを別のコンピュートノードに移行するには、次の手順を実行します。
インスタンスを別の Compute ノードに移行する場合は、以下のコマンドのいずれかを使用します。
インスタンスを別のホストに移行するには、次のコマンドを実行します。
(overcloud) $ openstack server migrate <instance_id> --live <target_host> --wait
-
<instance_id>は、インスタンス ID に置き換えます。 -
<target_host>は、インスタンスの移行先のホストに置き換えます。
-
nova-schedulerがターゲットホストを自動的に選択できるようにします。(overcloud) $ nova live-migration <instance_id>
すべてのインスタンスを一度にライブマイグレーションします。
$ nova host-evacuate-live <hostname>
注記novaコマンドで非推奨の警告が表示される可能性がありますが、無視しても問題ありません。
- 移行が完了するまで待ちます。
移行が正常に完了したことを確認します。
(overcloud) $ openstack server list --host <hostname> --all-projects
- Compute ノードのインスタンスがなくなるまで、移行を続けます。
コンピュートノードにログインして、ノードをリブートします。
[tripleo-admin@overcloud-compute-0 ~]$ sudo reboot
- ノードがブートするまで待ちます。
Compute ノードを再度有効にします。
$ source ~/overcloudrc (overcloud) $ openstack compute service set <hostname> nova-compute --enable
Compute ノードが有効であることを確認します。
(overcloud) $ openstack compute service list
11.11.4. オーバークラウドの更新後の RHOSP の検証
Red Hat OpenStack Platform (RHOSP) 環境を更新した後、tripleo-validations Playbook を使用してオーバークラウドを検証します。
検証の詳細は、director を使用した Red Hat OpenStack Platform のインストールと管理 の 検証フレームワークの使用 を参照してください。
手順
-
アンダークラウドホストに
stackユーザーとしてログインします。 stackrcアンダークラウド認証情報ファイルを入手します。$ source ~/stackrc
検証を実行します。
$ validation run -i ~/overcloud-deploy/<stack>/tripleo-ansible-inventory.yaml --group post-update
- <stack> をスタックの名前に置き換えます。
検証
- 検証レポートの結果を表示するには、director を使用した Red Hat OpenStack Platform のインストールと管理 の 検証履歴の表示 を参照してください。
検証の実行時にホストが見つからない場合、コマンドはステータスを SKIPPED と報告します。SKIPPED のステータスは、検証が実行されないことを意味しますが、これは想定内です。さらに、検証の合格基準が満たされていない場合、コマンドはステータスを FAILED と報告します。検証が FAILED であっても、更新された RHOSP 環境を使用できないことはありません。ただし、検証が FAILED の場合は、環境に問題があることを示している可能性があります。
