ホーム
製品
Red Hat Enterprise Linux OpenStack Platform
7
director のインストールと使用方法
8.4. コントローラーノードの置き換え

8.4. コントローラーノードの置き換え

特定の状況では、高可用性クラスター内のコントローラーノードに障害が発生することがあり、その場合は、そのコントローラーノードをクラスターから削除して新しいコントローラーノードに置き換える必要があります。このステップには、クラスター内の他のノードとの接続を確認する作業も含まれます。

本項では、コントローラーノードの置き換えの手順について説明します。このプロセスでは openstack overcloud deploy コマンドを実行して、コントローラーノードを置き換えるための要求でオーバークラウドを更新します。このプロセスは、自動的には完了しない点に注意してください。オーバークラウドスタックの更新処理中のどの時点かで、openstack overcloud deploy コマンドによりエラーが報告されて、オーバークラウドスタックの更新が停止します。この時点で、プロセスに手動での介入が必要となります。この後に openstack overcloud deploy はプロセスを続行することができます。

重要

以下の手順は、高可用性環境のみに適用します。コントローラーノード 1 台の場合には、この手順は使用しないでください。

8.4.1. 事前のチェック

オーバークラウドコントローラーノードの置き換えを試みる前に、Red Hat OpenStack Platform 環境の現在の状態をチェックしておくことが重要です。このチェックしておくと、コントローラーの置き換えプロセス中に複雑な事態が発生するのを防ぐことができます。以下の事前チェックリストを使用して、コントローラーノードの置き換えを実行しても安全かどうかを確認してください。チェックのためのコマンドはすべてアンダークラウドで実行します。

アンダークラウドで、overcloud スタックの現在の状態をチェックします。
```
source stackrc
heat stack-list --show-nested
```
```
$ source stackrc
$ heat stack-list --show-nested
```
Copy to Clipboard
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-discoverd.service openstack-ironic-discoverd-dnsmasq.service
sudo cp /var/lib/ironic-discoverd/inspector.sqlite /home/stack/backup
sudo systemctl start openstack-ironic-api.service openstack-ironic-conductor.service openstack-ironic-discoverd.service openstack-ironic-discoverd-dnsmasq.service

$ 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-discoverd.service openstack-ironic-discoverd-dnsmasq.service
$ sudo cp /var/lib/ironic-discoverd/inspector.sqlite /home/stack/backup
$ sudo systemctl start openstack-ironic-api.service openstack-ironic-conductor.service openstack-ironic-discoverd.service openstack-ironic-discoverd-dnsmasq.service

Copy to Clipboard

アンダークラウドで、新規ノードのプロビジョニング時にイメージのキャッシュと変換に対応できる 10 GB の空きストレージ領域があるかどうかをチェックします。
コントローラーノードで実行中の Pacemaker の状態をチェックします。たとえば、実行中のコントローラーノードの IP アドレスが 192.168.0.47 の場合には、以下のコマンドで Pacemaker のステータス情報を取得します。
```
ssh heat-admin@192.168.0.47 'sudo pcs status'
```
```
$ ssh heat-admin@192.168.0.47 'sudo pcs status'
```
Copy to Clipboard
出力には、既存のノードで実行中のサービスと、障害が発生しているノードで停止中のサービスがすべて表示されるはずです。

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

wsrep_local_state_comment: Synced
wsrep_cluster_size: 2

実行中のコントローラーノードで以下のコマンドを使用して、パラメーターをチェックします (IP アドレスにはそれぞれ 192.168.0.47 と 192.168.0.46 を使用します)。

for i in 192.168.0.47 192.168.0.46 ; do echo "*** $i ***" ; ssh heat-admin@$i "sudo mysql --exec=\"SHOW STATUS LIKE 'wsrep_local_state_comment'\" ; sudo mysql --exec=\"SHOW STATUS LIKE 'wsrep_cluster_size'\""; done

$ for i in 192.168.0.47 192.168.0.46 ; do echo "*** $i ***" ; ssh heat-admin@$i "sudo mysql --exec=\"SHOW STATUS LIKE 'wsrep_local_state_comment'\" ; sudo mysql --exec=\"SHOW STATUS LIKE 'wsrep_cluster_size'\""; done

Copy to Clipboard

RabbitMQ のステータスをチェックします。たとえば、実行中のコントローラーノードの IP アドレスが 192.168.0.47 の場合には、以下のコマンドを実行してステータスを取得します。
```
ssh heat-admin@192.168.0.47 "sudo rabbitmqctl cluster_status"
```
```
$ ssh heat-admin@192.168.0.47 "sudo rabbitmqctl cluster_status"
```
Copy to Clipboard
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 set stonith-enabled=false"
```
Copy to Clipboard
以下のコマンドを実行してフェンシングのステータスを確認します。
```
ssh heat-admin@192.168.0.47 "sudo pcs property show stonith-enabled"
```
```
$ ssh heat-admin@192.168.0.47 "sudo pcs property show stonith-enabled"
```
Copy to Clipboard
director ノードで nova-compute サービスをチェックします。
```
sudo systemctl status openstack-nova-compute
nova hypervisor-list
```
```
$ sudo systemctl status openstack-nova-compute
$ nova hypervisor-list
```
Copy to Clipboard
出力では、メンテナンスモードに入っていないすべてのノードが up のステータスで表示されるはずです。
アンダークラウドサービスがすべて実行中であることを確認します。
```
sudo systemctl -t service
```
```
$ sudo systemctl -t service
```
Copy to Clipboard

8.4.2. ノードの置き換え

削除するノードのインデックスを特定します。ノードのインデックスは、nova list の出力に表示されるインスタンス名のサフィックスです。

nova list

[stack@director ~]$ nova list
+--------------------------------------+------------------------+
| ID                                   | Name                   |
+--------------------------------------+------------------------+
| 861408be-4027-4f53-87a6-cd3cf206ba7a | overcloud-compute-0    |
| 0966e9ae-f553-447a-9929-c4232432f718 | overcloud-compute-1    |
| 9c08fa65-b38c-4b2e-bd47-33870bff06c7 | overcloud-compute-2    |
| a7f0f5e1-e7ce-4513-ad2b-81146bc8c5af | overcloud-controller-0 |
| cfefaf60-8311-4bc3-9416-6a824a40a9ae | overcloud-controller-1 |
| 97a055d4-aefd-481c-82b7-4a5f384036d2 | overcloud-controller-2 |
+--------------------------------------+------------------------+

Copy to Clipboard

この例では、overcloud-controller-1 ノードを削除して、overcloud-controller-3 に置き換えます。初めにノードをメンテナンスモードに切り替えて、director がエラーの発生したノードを再プロビジョニングしないようにします。nova list で表示されるインスタンスの ID を、ironic node-list で表示されるノード ID と相関させます。

ironic node-list

[stack@director ~]$ ironic node-list
+--------------------------------------+------+--------------------------------------+
| UUID                                 | Name | Instance UUID                        |
+--------------------------------------+------+--------------------------------------+
| 36404147-7c8a-41e6-8c72-a6e90afc7584 | None | 7bee57cf-4a58-4eaf-b851-2a8bf6620e48 |
| 91eb9ac5-7d52-453c-a017-c0e3d823efd0 | None | None                                 |
| 75b25e9a-948d-424a-9b3b-f0ef70a6eacf | None | None                                 |
| 038727da-6a5c-425f-bd45-fda2f4bd145b | None | 763bfec2-9354-466a-ae65-2401c13e07e5 |
| dc2292e6-4056-46e0-8848-d6e96df1f55d | None | 2017b481-706f-44e1-852a-2ee857c303c4 |
| c7eadcea-e377-4392-9fc3-cf2b02b7ec29 | None | 5f73c7d7-4826-49a5-b6be-8bfd558f3b41 |
| da3a8d19-8a59-4e9d-923a-6a336fe10284 | None | cfefaf60-8311-4bc3-9416-6a824a40a9ae |
| 807cb6ce-6b94-4cd1-9969-5c47560c2eee | None | c07c13e6-a845-4791-9628-260110829c3a |
+--------------------------------------+------+--------------------------------------+

Copy to Clipboard

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

ironic node-set-maintenance da3a8d19-8a59-4e9d-923a-6a336fe10284 true

[stack@director ~]$ ironic node-set-maintenance da3a8d19-8a59-4e9d-923a-6a336fe10284 true

Copy to Clipboard

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

ironic node-update 75b25e9a-948d-424a-9b3b-f0ef70a6eacf add properties/capabilities='profile:control,boot_option:local'

[stack@director ~]$ ironic node-update 75b25e9a-948d-424a-9b3b-f0ef70a6eacf add properties/capabilities='profile:control,boot_option:local'

Copy to Clipboard

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

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

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

Copy to Clipboard

重要

インデックス 0 のノードを置き換える場合には、ノードの置き換えを開始する前に、Heat テンプレートを編集してブートストラップのノードインデックスとノード検証インデックスを変更します。director の Heat テンプレートコレクションのコピーを作成して (「10章カスタム設定の作成を参照」)、以下のコマンドを overcloud-without-mergepy.yaml ファイルに対して実行します。

sudo sed -i "s/resource\.0/resource.1/g" ~/templates/my-overcloud/overcloud-without-mergepy.yaml

$ sudo sed -i "s/resource\.0/resource.1/g" ~/templates/my-overcloud/overcloud-without-mergepy.yaml

Copy to Clipboard

これにより、以下のリソースのノードインデックスが変更されます。

ControllerBootstrapNodeConfig:
  type: OS::TripleO::BootstrapNode::SoftwareConfig
    properties:
      bootstrap_nodeid: {get_attr: [Controller, resource.0.hostname]}
      bootstrap_nodeid_ip: {get_attr: [Controller, resource.0.ip_address]}

ControllerBootstrapNodeConfig:
  type: OS::TripleO::BootstrapNode::SoftwareConfig
    properties:
      bootstrap_nodeid: {get_attr: [Controller, resource.0.hostname]}
      bootstrap_nodeid_ip: {get_attr: [Controller, resource.0.ip_address]}

Copy to Clipboard

および

AllNodesValidationConfig:
  type: OS::TripleO::AllNodes::Validation
  properties:
    PingTestIps:
      list_join:
      - ' '
      - - {get_attr: [Controller, resource.0.external_ip_address]}
        - {get_attr: [Controller, resource.0.internal_api_ip_address]}
        - {get_attr: [Controller, resource.0.storage_ip_address]}
        - {get_attr: [Controller, resource.0.storage_mgmt_ip_address]}
        - {get_attr: [Controller, resource.0.tenant_ip_address]}

AllNodesValidationConfig:
  type: OS::TripleO::AllNodes::Validation
  properties:
    PingTestIps:
      list_join:
      - ' '
      - - {get_attr: [Controller, resource.0.external_ip_address]}
        - {get_attr: [Controller, resource.0.internal_api_ip_address]}
        - {get_attr: [Controller, resource.0.storage_ip_address]}
        - {get_attr: [Controller, resource.0.storage_mgmt_ip_address]}
        - {get_attr: [Controller, resource.0.tenant_ip_address]}

Copy to Clipboard

ノードインデックスを特定した後には、オーバークラウドを再デプロイして、remove-controller.yaml 環境ファイルを追加します。

openstack overcloud deploy --templates --control-scale 3 -e ~/templates/remove-controller.yaml [OTHER OPTIONS]

[stack@director ~]$ openstack overcloud deploy --templates --control-scale 3 -e ~/templates/remove-controller.yaml [OTHER OPTIONS]

Copy to Clipboard

重要

オーバークラウドの作成時に追加の環境ファイルまたはオプションを渡した場合には、予定外の変更がオーバークラウドに加えられないように、その環境ファイルまたはオプションをここで再度渡してください。

ただし、-e ~/templates/remove-controller.yaml が必要なのは、この場合には 1 回のみである点に注意してください。

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

heat stack-list --show-nested

[stack@director ~]$ heat stack-list --show-nested

Copy to Clipboard

8.4.3. 手動での介入

ControllerNodesPostDeployment の段階中には、オーバークラウドスタックの更新が ControllerLoadBalancerDeployment_Step1 で UPDATE_FAILED エラーにより停止します。これは、一部の Puppet モジュールがノードの置き換えをサポートしてないためです。処理のこの時点で手動による介入が必要です。以下に記載する設定ステップに従ってください。

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

nova list

[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   |
... +------------------------+ ... +-------------------------+

Copy to Clipboard

既存のノードの /etc/corosync/corosync.conf ファイルで、削除されたノードの nodeid の値を確認します。たとえば、既存のノードが 192.168.0.47 の overcloud-controller-0 の場合には、以下のコマンドを実行します。
```
ssh heat-admin@192.168.0.47 "sudo cat /etc/corosync/corosync.conf"
```
```
[stack@director ~]$ ssh heat-admin@192.168.0.47 "sudo cat /etc/corosync/corosync.conf"
```
Copy to Clipboard
このコマンドにより、削除されたノードの 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
  }
}
```
```
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
  }
}
```
Copy to Clipboard
削除された nodeid の値は、後で使用するときのために書き留めておいてください。上記の例では、2 がその値です。

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

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

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

Copy to Clipboard

残りのノードの中の 1 台にログインして、crm_node コマンドで対象のノードをクラスターから削除します。
```
sudo crm_node -R overcloud-controller-1 --force
```
```
[stack@director] ssh heat-admin@192.168.201.47
[heat-admin@overcloud-controller-0 ~]$ sudo crm_node -R overcloud-controller-1 --force
```
Copy to Clipboard
このノードにログインした状態を維持します。

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

sudo rabbitmqctl forget_cluster_node rabbit@overcloud-controller-1

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

Copy to Clipboard

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

sudo netstat -tulnp | grep 27017

[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

Copy to Clipboard

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

echo "db.isMaster()" | mongo --host 192.168.0.47:27017

[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

Copy to Clipboard

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

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

mongo --host 192.168.0.47

[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>

Copy to Clipboard

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

tripleo:PRIMARY> rs.status()

tripleo:PRIMARY> rs.status()

Copy to Clipboard

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

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

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

Copy to Clipboard

重要

PRIMARY レプリカセットに対してコマンドを実行する必要があります。

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

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

Copy to Clipboard

上記のメッセージが表示された場合には、PRIMARY に指定されているノード上の MongoDB に再ログインします。

注記

障害の発生したノードのレプリカセットを削除する際には、通常以下のような出力が表示されます。

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

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

Copy to Clipboard

MongoDB を終了します。

tripleo:PRIMARY> exit

tripleo:PRIMARY> exit

Copy to Clipboard

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

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 resource update galera wsrep_cluster_address=gcomm://overcloud-controller-0,overcloud-controller-3,overcloud-controller-2

Copy to Clipboard

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

sudo pcs cluster node add overcloud-controller-3

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

Copy to Clipboard

各ノードで /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
  }
}
```
```
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
  }
}
```
Copy to Clipboard
上記の例では、新規ノードが削除されたノードと同じ nodeid を使用している点に注意してください。この値を、使用していないノードの ID 値に更新します。以下に例を示します。
```
node {
  ring0_addr: overcloud-controller-3
  nodeid: 4
}
```
```
node {
  ring0_addr: overcloud-controller-3
  nodeid: 4
}
```
Copy to Clipboard
新規ノードを含む各コントローラーノードの /etc/corosync/corosync.conf ファイルで nodeid の値を更新します。
既存のノードのみで Corosync サービスを再起動します。たとえば、overcloud-controller-0 で以下のコマンドを実行します。
```
sudo pcs cluster reload corosync
```
```
[heat-admin@overcloud-controller-0 ~]$ sudo pcs cluster reload corosync
```
Copy to Clipboard
overcloud-controller-2 で以下のコマンドを実行します。
```
sudo pcs cluster reload corosync
```
```
[heat-admin@overcloud-controller-2 ~]$ sudo pcs cluster reload corosync
```
Copy to Clipboard
このコマンドは、新規ノードでは実行しないでください。

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

sudo pcs cluster start overcloud-controller-3

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

Copy to Clipboard

新規ノード上で Keystone サービスを有効にします。残りのノードから director ホストに /etc/keystone をコピーします。
```
sudo -i
scp -r /etc/keystone stack@192.168.0.1:~/.
```
```
[heat-admin@overcloud-controller-0 ~]$ sudo -i
[root@overcloud-controller-0 ~]$ scp -r /etc/keystone stack@192.168.0.1:~/.
```
Copy to Clipboard
新規コントローラーノードにログインします。新規コントローラーノードから /etc/keystone ディレクトリーを削除して、director ホストから keystone ファイルをコピーします。
```
sudo -i
rm -rf /etc/keystone
scp -r stack@192.168.0.1:~/keystone /etc/.
chown -R keystone: /etc/keystone
chown root /etc/keystone/logging.conf /etc/keystone/default_catalog.templates
```
```
[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
```
Copy to Clipboard
/etc/keystone/keystone.conf を編集して admin_bind_host および public_bind_host のパラメーターを新規コントローラーノードの IP アドレスに設定します。これらの IP アドレスを確認するには、 ip addr コマンドを使用して、以下のネットワーク内の IP アドレスを見つけます。
- admin_bind_host: プロビジョニングネットワーク
- public_bind_host: 内部 API ネットワーク
注記
カスタムの ServiceNetMap パラメーターを使用してオーバークラウドをデプロイした場合には、これらのネットワークは異なる場合があります。
たとえば、プロビジョニングネットワークが 192.168.0.0/24 サブネットを使用して、内部 API が 172.17.0.0/24 サブネットを使用している場合には、以下のコマンドを使用して、それらのネットワーク上のノードの IP アドレスを特定します。
```
ip addr | grep "192\.168\.0\..*/24"
ip addr | grep "172\.17\.0\..*/24"
```
```
[root@overcloud-controller-3 ~]$ ip addr | grep "192\.168\.0\..*/24"
[root@overcloud-controller-3 ~]$ ip addr | grep "172\.17\.0\..*/24"
```
Copy to Clipboard
Pacemaker を使用して、いくつかのサービスを有効化して再起動します。クラスターは現在メンテナンスモードに設定されていますが、サービスを有効化するには、このモードを一時的に無効にする必要があります。以下に例を示します。
```
sudo pcs property set maintenance-mode=false --wait
```
```
[heat-admin@overcloud-controller-3 ~]$ sudo pcs property set maintenance-mode=false --wait
```
Copy to Clipboard

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

sudo pcs status | grep galera -A1

[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 ]

Copy to Clipboard

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

sudo pcs resource cleanup galera overcloud-controller-3

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

Copy to Clipboard

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

sudo pcs status | grep keystone -A1

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

Copy to Clipboard

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

sudo pcs resource cleanup openstack-keystone-clone overcloud-controller-3

          [heat-admin@overcloud-controller-3 ~]$ sudo pcs resource cleanup openstack-keystone-clone overcloud-controller-3

Copy to Clipboard

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

sudo pcs property set maintenance-mode=true --wait

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

Copy to Clipboard

手動の設定が完了しました。オーバークラウドのコマンドを再度実行して、スタックの更新を継続します。

openstack overcloud deploy --templates --control-scale 3 [OTHER OPTIONS]

[stack@director ~]$ openstack overcloud deploy --templates --control-scale 3 [OTHER OPTIONS]

Copy to Clipboard

重要

ただし、remove-controller.yaml ファイルは必要ない点に注意してください。

8.4.4. オーバークラウドサービスの最終処理

オーバークラウドのスタックの更新が完了したら、最終の設定が必要です。コントローラーノードの 1 つにログインして、Pacemaker で停止されているサービスを更新します。

for i in `sudo pcs status|grep -B2 Stop |grep -v "Stop\|Start"|awk -F"[" '/\[/ {print substr($NF,0,length($NF)-1)}'`; do echo $i; sudo pcs resource cleanup $i; done

[heat-admin@overcloud-controller-0 ~]$ for i in `sudo pcs status|grep -B2 Stop |grep -v "Stop\|Start"|awk -F"[" '/\[/ {print substr($NF,0,length($NF)-1)}'`; do echo $i; sudo pcs resource cleanup $i; done

Copy to Clipboard

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

sudo pcs status

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

Copy to Clipboard

注記

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

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

sudo pcs property set stonith-enabled=true

[heat-admin@overcloud-controller-0 ~]$ sudo pcs property set stonith-enabled=true

Copy to Clipboard

director を終了します。

exit

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

Copy to Clipboard

8.4.5. オーバークラウドのネットワークエージェントの最終処理

オーバークラウドと対話できるようにするために、source コマンドで overcloudrc ファイルを読み込みます。ルーターをチェックして、L3 エージェントがオーバークラウド環境内のルーターを適切にホストしていることを確認します。以下の例では、r1 という名前のルーターを使用します。

source ~/overcloudrc
neutron l3-agent-list-hosting-router r1

[stack@director ~]$ source ~/overcloudrc
[stack@director ~]$ neutron l3-agent-list-hosting-router r1

Copy to Clipboard

このリストには、新しいノードの代わりに、依然として古いノードが表示される場合があります。これを置き換えるには、環境内の L3 ネットワークエージェントを一覧表示します。

neutron agent-list | grep "neutron-l3-agent"

[stack@director ~]$ neutron agent-list | grep "neutron-l3-agent"

Copy to Clipboard

新しいノードと古いノード上でエージェントの UUID を特定します。新しいノードのエージェントにルーターを追加し、古いノードからそのルーターを削除します。以下に例を示します。

neutron l3-agent-router-add fd6b3d6e-7d8c-4e1a-831a-4ec1c9ebb965 r1
neutron l3-agent-router-remove b40020af-c6dd-4f7a-b426-eba7bac9dbc2 r1

[stack@director ~]$ neutron l3-agent-router-add fd6b3d6e-7d8c-4e1a-831a-4ec1c9ebb965 r1
[stack@director ~]$ neutron l3-agent-router-remove b40020af-c6dd-4f7a-b426-eba7bac9dbc2 r1

Copy to Clipboard

ルーターに対して最終チェックを実行し、すべてがアクティブであることを確認します。

neutron l3-agent-list-hosting-router r1

[stack@director ~]$ neutron l3-agent-list-hosting-router r1

Copy to Clipboard

古いコントローラーノードをポイントしている既存の Neutron エージェントを削除します。以下に例を示します。

neutron agent-list -F id -F host | grep overcloud-controller-1
neutron agent-delete ddae8e46-3e8e-4a1b-a8b3-c87f13c294eb

[stack@director ~]$ neutron agent-list -F id -F host | grep overcloud-controller-1
| ddae8e46-3e8e-4a1b-a8b3-c87f13c294eb | overcloud-controller-1.localdomain |
[stack@director ~]$ neutron agent-delete ddae8e46-3e8e-4a1b-a8b3-c87f13c294eb

Copy to Clipboard

8.4.6. Compute サービスの最終処理

削除されたノードの Compute サービスはオーバークラウドにまだ存在しているので、削除する必要があります。source コマンドで overcloudrc ファイルを読み込み、オーバークラウドと対話できるようにします。削除したノードの Compute サービスをチェックします。

source ~/overcloudrc
nova service-list | grep "overcloud-controller-1.localdomain"

[stack@director ~]$ source ~/overcloudrc
[stack@director ~]$ nova service-list | grep "overcloud-controller-1.localdomain"

Copy to Clipboard

ノードの Compute サービスを削除します。たとえば、overcloud-controller-1.localdomain の nova-scheduler サービスの ID が 5 の場合には、以下のコマンドを実行します。

nova service-delete 5

[stack@director ~]$ nova service-delete 5

Copy to Clipboard

削除したノードの各サービスでこのタスクを実行します。

新しいノードで openstack-nova-consoleauth サービスをチェックします。

nova service-list | grep consoleauth

[stack@director ~]$ nova service-list | grep consoleauth

Copy to Clipboard

サービスが実行していない場合には、コントローラーノードにログインしてサービスを再起動します。

pcs resource restart openstack-nova-consoleauth

[stack@director] ssh heat-admin@192.168.201.47
[heat-admin@overcloud-controller-0 ~]$ pcs resource restart openstack-nova-consoleauth

Copy to Clipboard

8.4.7. 結果

障害が発生したコントローラーノードと、関連サービスが新しいノードに置き換えられました。

トップに戻る

8.4. コントローラーノードの置き換え

8.4.1. 事前のチェック

8.4.2. ノードの置き換え

8.4.3. 手動での介入

8.4.4. オーバークラウドサービスの最終処理

8.4.5. オーバークラウドのネットワークエージェントの最終処理

8.4.6. Compute サービスの最終処理

8.4.7. 結果

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links