第17章 コントローラーノードの置き換え
特定の状況では、高可用性クラスター内のコントローラーノードに障害が発生することがあります。その場合は、そのコントローラーノードをクラスターから削除して新しいコントローラーノードに置き換える必要があります。
以下のシナリオの手順を実施して、コントローラーノードを置き換えます。コントローラーノードを置き換えるプロセスでは、openstack overcloud deploy コマンドを実行し、コントローラーノードを置き換えるリクエストでオーバークラウドを更新します。
以下の手順は、高可用性環境にのみ適用されます。コントローラーノード 1 台の場合には、この手順は使用しないでください。
17.1. コントローラー置き換えの準備
オーバークラウドのコントローラーノードを置き換える前に、Red Hat OpenStack Platform 環境の現在の状態をチェックしておくことが重要です。このチェックをしておくと、コントローラーの置き換えプロセス中に複雑な事態が発生するのを防ぐことができます。以下の事前チェックリストを使用して、コントローラーノードの置き換えを実行しても安全かどうかを確認してください。チェックのためのコマンドはすべてアンダークラウドで実行します。
手順
アンダークラウドで、
overcloudスタックの現在の状態をチェックします。$ source stackrc (undercloud)$ openstack stack list --nested
overcloudスタックと後続の子スタックは、CREATE_COMPLETEまたはUPDATE_COMPLETEのステータスである必要があります。データベースクライアントツールをインストールします。
(undercloud)$ sudo dnf -y install mariadb
root ユーザーのデータベースへのアクセス権限を設定します。
(undercloud)$ sudo cp /var/lib/config-data/puppet-generated/mysql/root/.my.cnf /root/.
アンダークラウドデータベースのバックアップを実行します。
(undercloud)$ mkdir /home/stack/backup (undercloud)$ sudo mysqldump --all-databases --quick --single-transaction | gzip > /home/stack/backup/dump_db_undercloud.sql.gz
アンダークラウドに、新規ノードプロビジョニング時のイメージのキャッシュと変換に対応できる 10 GB の空きストレージ領域があることを確認します。
(undercloud)$ df -h
新規コントローラーノード用に IP アドレスを再利用する場合は、古いコントローラーが使用したポートを削除するようにしてください。
(undercloud)$ openstack port delete <port>
コントローラーノードで実行中の Pacemaker の状態をチェックします。たとえば、実行中のコントローラーノードの IP アドレスが 192.168.0.47 の場合には、以下のコマンドで Pacemaker のステータスを表示します。
(undercloud)$ ssh heat-admin@192.168.0.47 'sudo pcs status'
この出力には、既存のノードで動作中のサービスおよび障害の発生しているノードで停止しているサービスがすべて表示されます。
オーバークラウド MariaDB クラスターの各ノードで以下のパラメーターをチェックします。
-
wsrep_local_state_comment: Synced wsrep_cluster_size: 2実行中のコントローラーノードで以下のコマンドを使用して、パラメーターをチェックします。以下の例では、コントローラーノードの IP アドレスは、それぞれ 192.168.0.47 と 192.168.0.46 です。
(undercloud)$ for i in 192.168.0.46 192.168.0.47 ; do echo "*** $i ***" ; ssh heat-admin@$i "sudo podman exec \$(sudo podman ps --filter name=galera-bundle -q) mysql -e \"SHOW STATUS LIKE 'wsrep_local_state_comment'; SHOW STATUS LIKE 'wsrep_cluster_size';\""; done
-
RabbitMQ のステータスをチェックします。たとえば、実行中のコントローラーノードの IP アドレスが 192.168.0.47 の場合には、以下のコマンドで RabbitMQ のステータスを表示します。
(undercloud)$ ssh heat-admin@192.168.0.47 "sudo podman exec \$(sudo podman ps -f name=rabbitmq-bundle -q) rabbitmqctl cluster_status"
running_nodesキーには、障害が発生しているノードは表示されず、稼働中のノード 2 台のみが表示されるはずです。フェンシングが有効な場合は、無効にします。たとえば、実行中のコントローラーノードの IP アドレスが 192.168.0.47 の場合には、以下のコマンドを実行してフェンシングのステータスを確認します。
(undercloud)$ ssh heat-admin@192.168.0.47 "sudo pcs property show stonith-enabled"
フェンシングを無効にするには、以下のコマンドを実行します。
(undercloud)$ ssh heat-admin@192.168.0.47 "sudo pcs property set stonith-enabled=false"
director ノードで Compute サービスがアクティブであることを確認します。
(undercloud)$ openstack hypervisor list
出力では、メンテナンスモードに入っていないすべてのノードが
upのステータスで表示されるはずです。アンダークラウドコンテナーがすべて実行中であることを確認します。
(undercloud)$ sudo podman ps
障害が発生したコントローラーノードで実行されているすべての
nova_*コンテナーを停止します。[root@controller-0 ~]$ sudo systemctl stop tripleo_nova_api.service [root@controller-0 ~]$ sudo systemctl stop tripleo_nova_api_cron.service [root@controller-0 ~]$ sudo systemctl stop tripleo_nova_compute.service [root@controller-0 ~]$ sudo systemctl stop tripleo_nova_conductor.service [root@controller-0 ~]$ sudo systemctl stop tripleo_nova_metadata.service [root@controller-0 ~]$ sudo systemctl stop tripleo_nova_placement.service [root@controller-0 ~]$ sudo systemctl stop tripleo_nova_scheduler.service
オプション: virt ドライバーとして Bare Metal サービス (ironic) を使用している場合は、削除するコントローラーに
instances.hostが設定されているベアメタルインスタンスのセルデータベースのサービスエントリーを手動で更新する必要があります。レッドハットサポートにお問い合わせください。注記Bare Metal サービス (ironic) を virt ドライバーとして使用する場合のセルデータベースのこの手動更新は、BZ2017980 が完了するまで、ノードのリバランスを確保するための一時的な回避策です。
