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

$ source stackrc
$ heat stack-list --show-nested

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

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

$ mkdir /home/stack/backup
$ sudo mysqldump --all-databases --quick --single-transaction | gzip > /home/stack/backup/dump_db_undercloud.sql.gz
$ sudo systemctl stop openstack-ironic-api.service openstack-ironic-conductor.service openstack-ironic-inspector.service openstack-ironic-inspector-dnsmasq.service
$ sudo cp /var/lib/ironic-inspector/inspector.sqlite /home/stack/backup
$ sudo systemctl start openstack-ironic-api.service openstack-ironic-conductor.service openstack-ironic-inspector.service openstack-ironic-inspector-dnsmasq.service

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

$ ssh heat-admin@192.168.0.47 'sudo pcs status'

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

オーバークラウドの MariaDB クラスターの各ノードで以下のパラメーターをチェックします。

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

$ ssh heat-admin@192.168.0.47 "sudo rabbitmqctl cluster_status"

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

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

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

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

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

director ノードで nova-compute サービスをチェックします。

$ sudo systemctl status openstack-nova-compute
$ nova hypervisor-list

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

アンダークラウドサービスがすべて実行中であることを確認します。

$ sudo systemctl -t service

コントローラーノードの IP アドレスの一覧を取得します。以下に例を示します。

[stack@director ~]$ nova list
... +------------------------+ ... +-------------------------+
... | 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   |
... +------------------------+ ... +-------------------------+

既存のノードの /etc/corosync/corosync.conf ファイルで、削除されたノードの nodeid の値を確認します。たとえば、既存のノードが 192.168.0.47 の overcloud-controller-0 の場合には、以下のコマンドを実行します。

[stack@director ~]$ ssh heat-admin@192.168.0.47 "sudo cat /etc/corosync/corosync.conf"

このコマンドにより、削除されたノードの ID が含まれる nodelist が表示されます (overcloud-controller-1)。

nodelist {
  node {
    ring0_addr: overcloud-controller-0
    nodeid: 1
  }
  node {
    ring0_addr: overcloud-controller-1
    nodeid: 2
  }
  node {
    ring0_addr: overcloud-controller-2
    nodeid: 3
  }
}

削除された nodeid の値は、後で使用するときのために書き留めておいてください。上記の例では、2 がその値です。

各ノードの Corosync 設定から障害の発生したノードを削除して、Corosync を再起動します。この例では、overcloud-controller-0 と overcloud-controller-2 にログインして以下のコマンドを実行します。

[stack@director] ssh heat-admin@192.168.0.47 "sudo pcs cluster localnode remove overcloud-controller-1"
[stack@director] ssh heat-admin@192.168.0.47 "sudo pcs cluster reload corosync"
[stack@director] ssh heat-admin@192.168.0.46 "sudo pcs cluster localnode remove overcloud-controller-1"
[stack@director] ssh heat-admin@192.168.0.46 "sudo pcs cluster reload corosync"

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

[stack@director] ssh heat-admin@192.168.0.47
[heat-admin@overcloud-controller-0 ~]$ sudo crm_node -R overcloud-controller-1 --force

このノードにログインした状態を維持します。

障害が発生したノードを RabbitMQ クラスターから削除します。

[heat-admin@overcloud-controller-0 ~]$ sudo rabbitmqctl forget_cluster_node rabbit@overcloud-controller-1

障害が発生したノードを MongoDB から削除します。ノードの内部 API 接続のための IP アドレスを特定します。

[heat-admin@overcloud-controller-0 ~]$ sudo netstat -tulnp | grep 27017
tcp        0      0 192.168.0.47:27017    0.0.0.0:*               LISTEN      13415/mongod

ノードが primary レプリカセットであることを確認します。

[root@overcloud-controller-0 ~]# echo "db.isMaster()" | mongo --host 192.168.0.47:27017
MongoDB shell version: 2.6.11
connecting to: 192.168.0.47:27017/echo
{
  "setName" : "tripleo",
  "setVersion" : 1,
  "ismaster" : true,
  "secondary" : false,
  "hosts" : [
    "192.168.0.47:27017",
    "192.168.0.46:27017",
    "192.168.0.45:27017"
  ],
  "primary" : "192.168.0.47:27017",
  "me" : "192.168.0.47:27017",
  "electionId" : ObjectId("575919933ea8637676159d28"),
  "maxBsonObjectSize" : 16777216,
  "maxMessageSizeBytes" : 48000000,
  "maxWriteBatchSize" : 1000,
  "localTime" : ISODate("2016-06-09T09:02:43.340Z"),
  "maxWireVersion" : 2,
  "minWireVersion" : 0,
  "ok" : 1
}
bye

これで、現在のノードがプライマリーかどうかが表示されるはずです。そうでない場合には、primary キーに示されているノードの IP アドレスを使用します。

プライマリーノードで MongoDB に接続します。

[heat-admin@overcloud-controller-0 ~]$ mongo --host 192.168.0.47
MongoDB shell version: 2.6.9
connecting to: 192.168.0.47:27017/test
Welcome to the MongoDB shell.
For interactive help, type "help".
For more comprehensive documentation, see
http://docs.mongodb.org/
Questions? Try the support group
http://groups.google.com/group/mongodb-user
tripleo:PRIMARY>

MongoDB クラスターのステータスを確認します。

tripleo:PRIMARY> rs.status()

_id キーを使用してノードを特定し、name キーを使用して障害の発生したノードを削除します。この場合には name に 192.168.0.45:27017 を指定して Node 1 を削除します。

tripleo:PRIMARY> rs.remove('192.168.0.45:27017')

"replSetReconfig command must be sent to the current replica set primary."

2016-05-07T03:57:19.541+0000 DBClientCursor::init call() failed
2016-05-07T03:57:19.543+0000 Error: error doing query: failed at src/mongo/shell/query.js:81
2016-05-07T03:57:19.545+0000 trying reconnect to 192.168.0.47:27017 (192.168.0.47) failed
2016-05-07T03:57:19.547+0000 reconnect 192.168.0.47:27017 (192.168.0.47) ok

MongoDB を終了します。

tripleo:PRIMARY> exit

Galera クラスター内のノードの一覧を更新します。

[heat-admin@overcloud-controller-0 ~]$ sudo pcs resource update galera wsrep_cluster_address=gcomm://overcloud-controller-0,overcloud-controller-3,overcloud-controller-2

新規ノードをクラスターに追加します。

[heat-admin@overcloud-controller-0 ~]$ sudo pcs cluster node add overcloud-controller-3

各ノードで /etc/corosync/corosync.confファイルをチェックします。新規ノードの nodeid が削除したノードと同じ場合には、その値を nodeid 値に更新します。たとえば、/etc/corosync/corosync.conf ファイルに新規ノード (overcloud-controller-3) のエントリーが記載されています。

nodelist {
  node {
    ring0_addr: overcloud-controller-0
    nodeid: 1
  }
  node {
    ring0_addr: overcloud-controller-2
    nodeid: 3
  }
  node {
    ring0_addr: overcloud-controller-3
    nodeid: 2
  }
}

上記の例では、新規ノードが削除されたノードと同じ nodeid を使用している点に注意してください。この値を、使用していないノードの ID 値に更新します。以下に例を示します。

node {
  ring0_addr: overcloud-controller-3
  nodeid: 4
}

新規ノードを含む各コントローラーノードの /etc/corosync/corosync.conf ファイルで nodeid の値を更新します。

既存のノードのみで Corosync サービスを再起動します。たとえば、overcloud-controller-0 で以下のコマンドを実行します。

[heat-admin@overcloud-controller-0 ~]$ sudo pcs cluster reload corosync

overcloud-controller-2 で以下のコマンドを実行します。

[heat-admin@overcloud-controller-2 ~]$ sudo pcs cluster reload corosync

このコマンドは、新規ノードでは実行しないでください。

新規コントローラーノードを起動します。

[heat-admin@overcloud-controller-0 ~]$ sudo pcs cluster start overcloud-controller-3

新規ノード上で Keystone サービスを有効にします。残りのノードから director ホストに /etc/keystone ディレクトリーをコピーします。

[heat-admin@overcloud-controller-0 ~]$ sudo -i
[root@overcloud-controller-0 ~]$ scp -r /etc/keystone stack@192.168.0.1:~/.

新規コントローラーノードにログインします。新規コントローラーノードから /etc/keystone ディレクトリーを削除して、director ホストから keystone ファイルをコピーします。

[heat-admin@overcloud-controller-3 ~]$ sudo -i
[root@overcloud-controller-3 ~]$ rm -rf /etc/keystone
[root@overcloud-controller-3 ~]$ scp -r stack@192.168.0.1:~/keystone /etc/.
[root@overcloud-controller-3 ~]$ chown -R keystone: /etc/keystone
[root@overcloud-controller-3 ~]$ chown root /etc/keystone/logging.conf /etc/keystone/default_catalog.templates

/etc/keystone/keystone.conf を編集して admin_bind_host および public_bind_host のパラメーターを新規コントローラーノードの IP アドレスに設定します。これらの IP アドレスを確認するには、ip addr コマンドを使用して、以下のネットワーク内の IP アドレスを見つけます。

たとえば、プロビジョニングネットワークが 192.168.0.0/24 サブネットを使用して、内部 API が 172.17.0.0/24 サブネットを使用している場合には、以下のコマンドを使用して、それらのネットワーク上のノードの IP アドレスを特定します。

[root@overcloud-controller-3 ~]$ ip addr | grep "192\.168\.0\..*/24"
[root@overcloud-controller-3 ~]$ ip addr | grep "172\.17\.0\..*/24"

Pacemaker を使用して、いくつかのサービスを有効化および再起動します。クラスターは現在メンテナンスモードに設定されていますが、サービスを有効化するには、このモードを一時的に無効にする必要があります。以下に例を示します。

[heat-admin@overcloud-controller-3 ~]$ sudo pcs property set maintenance-mode=false --wait

全ノードで Galera サービスが起動するのを待ちます。

[heat-admin@overcloud-controller-3 ~]$ sudo pcs status | grep galera -A1
Master/Slave Set: galera-master [galera]
Masters: [ overcloud-controller-0 overcloud-controller-2 overcloud-controller-3 ]

必要な場合には、新規ノードで cleanup を実行します。

[heat-admin@overcloud-controller-3 ~]$ sudo pcs resource cleanup galera --node overcloud-controller-3

全ノードで httpd サービスが起動するまで待ちます。

[heat-admin@overcloud-controller-3 ~]$ sudo pcs status | grep httpd -A1
Clone Set: httpd-clone [httpd]
Started: [ overcloud-controller-0 overcloud-controller-2 overcloud-controller-3 ]

必要な場合には、新規ノードで cleanup を実行します。

[heat-admin@overcloud-controller-3 ~]$ sudo pcs resource cleanup httpd --node overcloud-controller-3

クラスターをメンテナンスモードに再度切り替えます。

[heat-admin@overcloud-controller-3 ~]$ sudo pcs property set maintenance-mode=true --wait