第12章 コントローラーノードの置き換え

手順

1. アンダークラウドで、overcloud スタックの現在の状態をチェックします。

   $ source stackrc
   (undercloud) $ openstack stack list --nested

   overcloud スタックと後続の子スタックは、CREATE_COMPLETE または UPDATE_COMPLETE のステータスである必要があります。

2. データベースクライアントツールをインストールします。

   (undercloud) $ sudo yum -y install mariadb

3. root ユーザーのデータベースへのアクセス権限を設定します。

   (undercloud) $ sudo cp /var/lib/config-data/puppet-generated/mysql/root/.my.cnf /root/.

4. アンダークラウドデータベースのバックアップを実行します。

   (undercloud) $ mkdir /home/stack/backup
   (undercloud) $ sudo mysqldump --all-databases --quick --single-transaction | gzip > /home/stack/backup/dump_db_undercloud.sql.gz

5. アンダークラウドに、新規ノードプロビジョニング時のイメージのキャッシュと変換に対応できる 10 GB の空きストレージ領域があることを確認します。

6. コントローラーノードで実行中の Pacemaker の状態をチェックします。たとえば、実行中のコントローラーノードの IP アドレスが 192.168.0.47 の場合には、以下のコマンドで Pacemaker のステータス情報を取得します。

   (undercloud) $ ssh heat-admin@192.168.0.47 'sudo pcs status'

   出力には、既存のノードで実行中のサービスと、障害が発生しているノードで停止中のサービスがすべて表示されるはずです。

7. オーバークラウド 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.47 192.168.0.46 ; do echo "*** $i ***" ; ssh heat-admin@$i "sudo mysql -p\$(sudo hiera -c /etc/puppet/hiera.yaml mysql::server::root_password) --execute=\"SHOW STATUS LIKE 'wsrep_local_state_comment'; SHOW STATUS LIKE 'wsrep_cluster_size';\""; done

8. RabbitMQ のステータスをチェックします。たとえば、実行中のコントローラーノードの IP アドレスが 192.168.0.47 の場合には、以下のコマンドを実行してステータスを取得します。

   (undercloud) $ ssh heat-admin@192.168.0.47 "sudo docker exec \$(sudo docker ps -f name=rabbitmq-bundle -q) rabbitmqctl cluster_status"

   running_nodes キーには、障害が発生しているノードは表示されず、稼働中のノード 2 台のみが表示されるはずです。

9. フェンシングが有効化されている場合には無効にします。たとえば、実行中のコントローラーノードの IP アドレスが 192.168.0.47 の場合には、以下のコマンドを実行してフェンシングを無効にします。

   (undercloud) $ ssh heat-admin@192.168.0.47 "sudo pcs property set stonith-enabled=false"

   以下のコマンドを実行してフェンシングのステータスを確認します。

   (undercloud) $ ssh heat-admin@192.168.0.47 "sudo pcs property show stonith-enabled"

10. director ノードで Compute サービスがアクティブであることを確認します。

    (undercloud) $ openstack hypervisor list

    出力では、メンテナンスモードに入っていないすべてのノードが up のステータスで表示されるはずです。

11. アンダークラウドコンテナーがすべて実行中であることを確認します。

    (undercloud) $ sudo docker ps

手順

1. 置き換えるコントローラーに接続して、root になります。

   # ssh heat-admin@192.168.0.47
   # sudo su -

   注記

   コントローラーが到達不可能な場合には、ステップ 1 と 2 をスキップして、稼働している任意のコントローラーノードでステップ 3 から手順を続行してください。

2. root として monitor を停止します。

   # systemctl stop ceph-mon@<monitor_hostname>

   例:

   # systemctl stop ceph-mon@overcloud-controller-1

3. 置き換えるコントローラーとの接続を終了します。

4. 既存のコントローラーのいずれかに接続します。

   # ssh heat-admin@192.168.0.46
   # sudo su -

5. クラスターから monitor を削除します。

   # ceph mon remove <mon_id>

6. すべてのコントローラーノード上で、/etc/ceph/ceph.conf から monitor のエントリーを削除します。たとえば、controller-1 を削除する場合には、controller-1 の IP アドレスとホスト名を削除します。

   編集前:

   mon host = 172.18.0.21,172.18.0.22,172.18.0.24
   mon initial members = overcloud-controller-2,overcloud-controller-1,overcloud-controller-0

   編集後:

   mon host = 172.18.0.22,172.18.0.24
   mon initial members = overcloud-controller-2,overcloud-controller-0

   注記

   置き換え用のコントローラーノードが追加されると、director によって該当するオーバークラウドノード上の ceph.conf ファイルが更新されます。通常は、director がこの設定ファイルを管理するだけで、手動でファイルを編集する必要はありません。ただし、新規ノードが追加される前に他のノードが再起動してしまった場合には、一貫性を保つために手動でファイルを編集することができます。

7. オプションとして、monitor データをアーカイブし、アーカイブを別のサーバーに保存します。

   # mv /var/lib/ceph/mon/<cluster>-<daemon_id> /var/lib/ceph/mon/removed-<cluster>-<daemon_id>

手順

1. コントローラーノードの IP アドレスの一覧を取得します。

   (undercloud) $ openstack server list -c Name -c Networks
   +------------------------+-----------------------+
   | Name                   | Networks              |
   +------------------------+-----------------------+
   | overcloud-compute-0    | ctlplane=192.168.0.44 |
   | overcloud-controller-0 | ctlplane=192.168.0.47 |
   | overcloud-controller-1 | ctlplane=192.168.0.45 |
   | overcloud-controller-2 | ctlplane=192.168.0.46 |
   +------------------------+-----------------------+

2. まだ古いノードにアクセスできる場合は、残りのノードのいずれかにログインし、古いノード上の Pacemaker を停止します。以下の例では、overcloud-controller-1 上の Pacemaker を停止しています。

   (undercloud) $ ssh heat-admin@192.168.0.47 "sudo pcs status | grep -w Online | grep -w overcloud-controller-1"
   (undercloud) $ ssh heat-admin@192.168.0.47 "sudo pcs cluster stop overcloud-controller-1"

   注記

   古いノードが物理的に利用できない、または停止している場合には、そのノードでは Pacemaker はすでに停止しているので、この操作を実施する必要はありません。

3. 古いノード上の Pacemaker を停止したら、各ノードの Corosync 設定から古いノードを削除して、Corosync を再起動します。古いノード上の Pacemaker のステータスを確認するには、pcs status コマンドを実行し、ステータスが Stopped であることを確認します。

   以下のコマンドの例では、overcloud-controller-0 および overcloud-controller-2 にログインし、overcloud-controller-1 を削除しています。

   (undercloud) $ for NAME in overcloud-controller-0 overcloud-controller-2; do IP=$(openstack server list -c Networks -f value --name $NAME | cut -d "=" -f 2) ; ssh heat-admin@$IP "sudo pcs cluster localnode remove overcloud-controller-1; sudo pcs cluster reload corosync"; done

4. 残りのノードの中の 1 台にログインして、crm_node コマンドで対象のノードをクラスターから削除します。

   (undercloud) $ ssh heat-admin@192.168.0.47
   [heat-admin@overcloud-controller-0 ~]$ sudo crm_node -R overcloud-controller-1 --force

5. オーバークラウドデータベースは、置き換え手順の実行中に稼働し続ける必要があります。この手順の実行中に Pacemaker が Galera を停止しないようにするには、実行中のコントローラーノードを選択して、そのコントローラーノードの IP アドレスを使用して、アンダークラウドで以下のコマンドを実行します。

   (undercloud) $ ssh heat-admin@192.168.0.47 "sudo pcs resource unmanage galera-bundle"

手順

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

   $ source ~/stackrc

2. overcloud-controller-1 ノードのインデックスを特定します。

   $ INSTANCE=$(openstack server list --name overcloud-controller-1 -f value -c ID)

3. インスタンスに関連付けられたベアメタルノードを特定します。

   $ NODE=$(openstack baremetal node list -f csv --quote minimal | grep $INSTANCE | cut -f1 -d,)

4. ノードをメンテナンスモードに切り替えます。

   $ openstack baremetal node maintenance set $NODE

5. コントローラーノードが仮想ノードの場合には、コントローラーホストで以下のコマンドを実行し、障害の発生した仮想ディスクをバックアップからの仮想ディスクに置き換えます。

   $ cp <VIRTUAL_DISK_BACKUP> /var/lib/libvirt/images/<VIRTUAL_DISK>

   <VIRTUAL_DISK_BACKUP> を障害の発生した仮想ディスクのバックアップへのパスに、<VIRTUAL_DISK> を置き換える仮想ディスクの名前にそれぞれ置き換えます。

   削除するノードのバックアップがない場合には、新しい仮想ノードを使用する必要があります。

   コントローラーノードがベアメタルノードの場合には、以下の手順を実施してディスクを新しいベアメタルディスクに置き換えます。

   1. 物理ハードドライブまたはソリッドステートドライブを置き換えます。
   2. 障害が発生したノードと同じ設定のノードを準備します。

6. 関連付けられていないノードの一覧を表示し、新規ノードの ID を特定します。

   $ openstack baremetal node list --unassociated

7. 新規ノードを control プロファイルにタグ付けします。

   (undercloud) $ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 75b25e9a-948d-424a-9b3b-f0ef70a6eacf

手順

1. 削除するノードのインデックスを定義する環境ファイルを作成します (~/templates/remove-controller.yaml)。

   parameters:
     ControllerRemovalPolicies:
       [{'resource_list': ['1']}]

2. ご自分の環境に該当するその他の環境ファイルと共に remove-controller.yaml 環境ファイルを指定して、オーバークラウドデプロイメントコマンドを実行します。

   (undercloud) $ openstack overcloud deploy --templates \
       -e /home/stack/templates/remove-controller.yaml \
       -e /home/stack/templates/node-info.yaml \
       [OTHER OPTIONS]

   注記

   -e ~/templates/remove-controller.yaml は、デプロイメントコマンドのこのインスタンスに対してのみ指定します。これ以降のデプロイメント操作からは、この環境ファイルを削除してください。

3. director は古いノードを削除して、新しいノードを作成してから、オーバークラウドスタックを更新します。以下のコマンドを使用すると、オーバークラウドスタックのステータスをチェックすることができます。

   (undercloud) $ openstack stack list --nested

4. デプロイメントコマンドの実行が完了すると、director の出力には古いノードが新規ノードに置き換えられたことが表示されます。

   (undercloud) $ openstack server list -c Name -c Networks
   +------------------------+-----------------------+
   | Name                   | Networks              |
   +------------------------+-----------------------+
   | overcloud-compute-0    | ctlplane=192.168.0.44 |
   | overcloud-controller-0 | ctlplane=192.168.0.47 |
   | overcloud-controller-2 | ctlplane=192.168.0.46 |
   | overcloud-controller-3 | ctlplane=192.168.0.48 |
   +------------------------+-----------------------+

   これで、新規ノードが稼動状態のコントロールプレーンサービスをホストするようになります。

手順

1. コントローラーノードにログインします。

2. Galera クラスターの Pacemaker 管理を有効にし、新規ノード上で Galera を起動します。

   [heat-admin@overcloud-controller-0 ~]$ sudo pcs resource refresh galera-bundle
   [heat-admin@overcloud-controller-0 ~]$ sudo pcs resource manage galera-bundle

3. 最終のステータスチェックを実行して、サービスが正しく実行されていることを確認します。

   [heat-admin@overcloud-controller-0 ~]$ sudo pcs status

   注記

   エラーが発生したサービスがある場合には、pcs resource refresh コマンドを使用して問題を解決し、そのサービスを再起動します。

4. director を終了します。

   [heat-admin@overcloud-controller-0 ~]$ exit

5. オーバークラウドと対話できるようにするために、source コマンドで overcloudrc ファイルを読み込みます。

   $ source ~/overcloudrc

6. オーバークラウド環境のネットワークエージェントを確認します。

   (overcloud) $ openstack network agent list

7. 古いノードにエージェントが表示される場合には、そのエージェントを削除します。

   (overcloud) $ for AGENT in $(openstack network agent list --host overcloud-controller-1.localdomain -c ID -f value) ; do openstack network agent delete $AGENT ; done

8. 必要に応じて、新規ノード上の L3 エージェントホストにルーターを追加します。以下のコマンドは、UUID に 2d1c1dc1-d9d4-4fa9-b2c8-f29cd1a649d4 を使用して L3 エージェントに r1 という名称のルーターを追加する例です。

   (overcloud) $ openstack network agent add router --l3 2d1c1dc1-d9d4-4fa9-b2c8-f29cd1a649d4 r1

9. 削除したノードの Compute サービスがオーバークラウドにまだ存在しているので、削除する必要があります。削除したノードの Compute サービスを確認します。

   [stack@director ~]$ source ~/overcloudrc
   (overcloud) $ openstack compute service list --host overcloud-controller-1.localdomain

10. 削除したノードのコンピュートサービスを削除します。

    (overcloud) $ for SERVICE in $(openstack compute service list --host overcloud-controller-1.localdomain -c ID -f value ) ; do openstack compute service delete $SERVICE ; done