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

特定の状況では、高可用性クラスター内のコントローラーノードに障害が発生することがあり、その場合は、そのコントローラーノードをクラスターから削除して新しいコントローラーノードに置き換える必要があります。このステップには、クラスター内の他のノードとの接続を確認する作業も含まれます。
本項では、コントローラーノードの置き換えの手順について説明します。このプロセスでは openstack overcloud deploy コマンドを実行して、コントローラーノードを置き換えるための要求でオーバークラウドを更新します。このプロセスは、自動的には完了しない点に注意してください。オーバークラウドスタックの更新処理中のどの時点かで、openstack overcloud deploy コマンドによりエラーが報告されて、オーバークラウドスタックの更新が停止します。この時点で、プロセスに手動での介入が必要となります。この後に openstack overcloud deploy はプロセスを続行することができます。

重要

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

9.4.1. 事前のチェック

オーバークラウドコントローラーノードの置き換えを試みる前に、Red Hat OpenStack Platform 環境の現在の状態をチェックしておくことが重要です。このチェックしておくと、コントローラーの置き換えプロセス中に複雑な事態が発生するのを防ぐことができます。以下の事前チェックリストを使用して、コントローラーノードの置き換えを実行しても安全かどうかを確認してください。チェックのためのコマンドはすべてアンダークラウドで実行します。
  1. アンダークラウドで、overcloud スタックの現在の状態をチェックします。 
    $ source stackrc
$ heat stack-list --show-nested
    overcloud スタックと後続の子スタックは、CREATE_COMPLETE または UPDATE_COMPLETE のステータスである必要があります。
  2. アンダークラウドデータベースのバックアップを実行します。 
    $ 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
  3. アンダークラウドで、新規ノードのプロビジョニング時にイメージのキャッシュと変換に対応できる 10 GB の空きストレージ領域があるかどうかをチェックします。
  4. コントローラーノードで実行中の Pacemaker の状態をチェックします。たとえば、実行中のコントローラーノードの IP アドレスが 192.168.0.47 の場合には、以下のコマンドで Pacemaker のステータス情報を取得します。 
    $ ssh heat-admin@192.168.0.47 'sudo pcs status'
    出力には、既存のノードで実行中のサービスと、障害が発生しているノードで停止中のサービスがすべて表示されるはずです。
  5. オーバークラウドの 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
  6. RabbitMQ のステータスをチェックします。たとえば、実行中のコントローラーノードの IP アドレスが 192.168.0.47 の場合には、以下のコマンドを実行してステータスを取得します。 
    $ ssh heat-admin@192.168.0.47 "sudo rabbitmqctl cluster_status"
    running_nodes キーには、障害が発生しているノードは表示されず、稼働中のノード 2 台のみが表示されるはずです。
  7. フェンシングが有効化されている場合には無効にします。たとえば、実行中のコントローラーノードの 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"
  8. director ノードで nova-compute サービスをチェックします。 
    $ sudo systemctl status openstack-nova-compute
$ nova hypervisor-list
    出力では、メンテナンスモードに入っていないすべてのノードが up のステータスで表示されるはずです。
  9. アンダークラウドサービスがすべて実行中であることを確認します。 
    $ sudo systemctl list-units httpd\* mariadb\* neutron\* openstack\* openvswitch\* rabbitmq\*

9.4.2. ノードの置き換え

削除するノードのインデックスを特定します。ノードのインデックスは、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 |
+--------------------------------------+------------------------+
この例では、overcloud-controller-1 ノードを削除して、overcloud-controller-3 に置き換えます。初めにノードをメンテナンスモードに切り替えて、director がエラーの発生したノードを再プロビジョニングしないようにします。nova list で表示されるインスタンスの ID を、ironic node-list で表示されるノード ID と相関させます。 
[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 |
+--------------------------------------+------+--------------------------------------+
ノードをメンテナンスモードに切り替えます。 
[stack@director ~]$ ironic node-set-maintenance da3a8d19-8a59-4e9d-923a-6a336fe10284 true
新規ノードを control プロファイルでタグ付けします。 
[stack@director ~]$ ironic node-update 75b25e9a-948d-424a-9b3b-f0ef70a6eacf add properties/capabilities='profile:control,boot_option:local'
削除するノードインデックスを定義する YAML ファイルを作成します (~/templates/remove-controller.yaml)。 
parameters:
  ControllerRemovalPolicies:
    [{'resource_list': ['1']}]

重要

インデックス 0 のノードを置き換える場合には、ノードの置き換えを開始する前に、Heat テンプレートを編集してブートストラップのノードインデックスとノード検証インデックスを変更します。director の Heat テンプレートコレクションのコピーを作成して (「カスタムのコア Heat テンプレートの使用」 を参照)、以下のコマンドを overcloud.yaml ファイルに対して実行します。 
$ sed -i "s/resource\.0/resource.1/g" ~/templates/my-overcloud/overcloud.yaml
これにより、以下のリソースのノードインデックスが変更されます。 
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]}
および 
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]}

注記

Corosync での settle の試行回数を減らすことによって、置き換えのプロセスをスピードアップすることができます。 環境ファイルの「ExtraConfig」パラメーターに以下の hieradata を追加します。 
parameter_defaults:
  ExtraConfig:
    pacemaker::corosync::settle_tries: 5
ノードインデックスを特定した後には、オーバークラウドを再デプロイして、remove-controller.yaml 環境ファイルを追加します。 
[stack@director ~]$ openstack overcloud deploy --templates --control-scale 3 -e ~/templates/remove-controller.yaml [OTHER OPTIONS]

重要

オーバークラウドの作成時に追加の環境ファイルまたはオプションを渡した場合には、予定外の変更がオーバークラウドに加えられないように、その環境ファイルまたはオプションをここで再度渡してください。
ただし、この場合は、-e ~/templates/remove-controller.yaml が必要なのは 1 回のみである点に注意してください。これは、ノードの削除プロセスが 1 回のみで、それ以降の実行時には実行されてはならないためです。
director は古いノードを削除して、新しいノードを作成してから、オーバークラウドスタックを更新します。以下のコマンドを使用すると、オーバークラウドスタックのステータスをチェックすることができます。 
[stack@director ~]$ heat stack-list --show-nested

重要

削除のプロセスにより、削除されたコントローラーノードが利用不可となることが原因で、RHELUnregistrationDeployment リソースがハングする場合があります。このような状態が発生した場合には、以下のコマンドを使用してリソースに信号を送ります。 
# heat resource-list -n 5 -f name=RHELUnregistrationDeployment overcloud
# heat resource-signal [STACK_NAME] RHELUnregistrationDeployment
[STACK_NAME] はコントローラーのサブトラックに置き換えます。たとえば、コントローラーノード 1 の場合は、overcloud-Controller-yfbet6xh6oov-1-f5v5pmcfvv2k-NodeExtraConfig-zuiny44lei3w に置き換えます。
ControllerNodesPostDeployment の段階に、オーバークラウドスタックがタイムアウトになって、ControllerLoadBalancerDeployment_Step1 で UPDATE_FAILED エラーが発生して停止します。これは想定通りの動作で、次の項で説明する手動での介入が必要です。

9.4.3. 手動での介入

ControllerNodesPostDeployment の段階には、オーバークラウドスタックが ControllerLoadBalancerDeployment_Step1 で UPDATE_FAILED エラーによりタイムアウトになって停止するまで。これは、一部の Puppet モジュールがノードの置き換えをサポートしていないためです。処理のこの時点で、手動での介入が必要です。以下に記載する設定ステップに従ってください。
  1. コントローラーノードの 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   |
... +------------------------+ ... +-------------------------+
  2. 既存のノードの /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 がその値です。
  3. 各ノードの 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"
  4. 残りのノードの中の 1 台にログインして、crm_node コマンドで対象のノードをクラスターから削除します。 
    [stack@director] ssh heat-admin@192.168.201.47
[heat-admin@overcloud-controller-0 ~]$ sudo crm_node -R overcloud-controller-1 --force
    このノードにログインした状態を維持します。
  5. 障害が発生したノードを RabbitMQ クラスターから削除します。 
    [heat-admin@overcloud-controller-0 ~]$ sudo rabbitmqctl forget_cluster_node rabbit@overcloud-controller-1
  6. 障害が発生したノードを 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')

    重要

    PRIMARY レプリカセットに対してコマンドを実行する必要があります。 
    "replSetReconfig command must be sent to the current replica set primary."
    上記のメッセージが表示された場合には、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
    MongoDB を終了します。 
    tripleo:PRIMARY> exit
  7. Galera クラスター内のノードの一覧を更新します。 
    [heat-admin@overcloud-controller-0 ~]$ sudo pcs resource update galera wsrep_cluster_address=gcomm://overcloud-controller-0,overcloud-controller-3,overcloud-controller-2
  8. 新規ノードに対して Galera クラスターのチェックが行われるように設定します。既存のノードから新規ノードの同じ場所に /etc/sysconfig/clustercheck をコピーします。
  9. root ユーザーが新規ノードの Gelera にアクセスできるように設定します。既存のノードから新規ノードの同じ場所に /root/.my.cnf をコピーします。
  10. 新規ノードをクラスターに追加します。 
    [heat-admin@overcloud-controller-0 ~]$ sudo pcs cluster node add overcloud-controller-3
  11. 各ノードで /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 の値を更新します。
  12. 既存のノードのみで 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
    このコマンドは、新規ノードでは実行しないでください。
  13. 新規コントローラーノードを起動します。 
    [heat-admin@overcloud-controller-0 ~]$ sudo pcs cluster start overcloud-controller-3
  14. 新規ノード上で 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 アドレスを見つけます。
    • admin_bind_host: プロビジョニングネットワーク
    • public_bind_host: 内部 API ネットワーク

    注記

    カスタムの ServiceNetMap パラメーターを使用してオーバークラウドをデプロイした場合には、これらのネットワークは異なる場合があります。
    たとえば、プロビジョニングネットワークが 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"
  15. Pacemaker を使用して、いくつかのサービスを有効化して再起動します。クラスターは現在メンテナンスモードに設定されていますが、サービスを有効化するには、このモードを一時的に無効にする必要があります。以下に例を示します。 
    [heat-admin@overcloud-controller-3 ~]$ sudo pcs property set maintenance-mode=false --wait
  16. 全ノードで 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
  17. 全ノードで Keystone サービスが起動するのを待ちます。 
    [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 ]
    必要な場合には、新規ノードで「cleanup」を実行します。 
    [heat-admin@overcloud-controller-3 ~]$ sudo pcs resource cleanup openstack-keystone-clone --node overcloud-controller-3
  18. クラスターをメンテナンスモードに再度切り替えます。 
    [heat-admin@overcloud-controller-3 ~]$ sudo pcs property set maintenance-mode=true --wait
手動の設定が完了しました。オーバークラウドのコマンドを再度実行して、スタックの更新を継続します。 
[stack@director ~]$ openstack overcloud deploy --templates --control-scale 3 [OTHER OPTIONS]

重要

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

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

オーバークラウドのスタックの更新が完了したら、最終の設定が必要です。コントローラーノードの 1 つにログインして、Pacemaker で停止されているサービスを更新します。 
[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
最終のステータスチェックを実行して、サービスが正しく実行されていることを確認します。 
[heat-admin@overcloud-controller-0 ~]$ sudo pcs status

注記

エラーが発生したサービスがある場合には、pcs resource cleanup コマンドを使用して、問題の解決後にそのサービスを再起動します。
「コントローラーノードのフェンシング」に記載の手順を参考にして、新規ノードのフェンシングの情報を追加してから、フェンシングを再度有効化します。以下のコマンドを使用してフェンシングを有効化してください。 
[heat-admin@overcloud-controller-0 ~]$ sudo pcs property set stonith-enabled=true
director を終了します。 
[heat-admin@overcloud-controller-0 ~]$ exit

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

オーバークラウドと対話できるようにするために、source コマンドで overcloudrc ファイルを読み込みます。ルーターをチェックして、L3 エージェントがオーバークラウド環境内のルーターを適切にホストしていることを確認します。以下の例では、r1 という名前のルーターを使用します。 
[stack@director ~]$ source ~/overcloudrc
[stack@director ~]$ neutron l3-agent-list-hosting-router r1
このリストには、新しいノードの代わりに、依然として古いノードが表示される場合があります。これを置き換えるには、環境内の L3 ネットワークエージェントを一覧表示します。 
[stack@director ~]$ neutron agent-list | grep "neutron-l3-agent"
新しいノードと古いノード上でエージェントの UUID を特定します。新しいノードのエージェントにルーターを追加し、古いノードからそのルーターを削除します。以下に例を示します。 
[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
ルーターに対して最終チェックを実行し、すべてがアクティブであることを確認します。 
[stack@director ~]$ neutron l3-agent-list-hosting-router r1
古いコントローラーノードをポイントしている既存の Neutron エージェントを削除します。以下に例を示します。 
[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

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

削除されたノードの Compute サービスはオーバークラウドにまだ存在しているので、削除する必要があります。source コマンドで overcloudrc ファイルを読み込み、オーバークラウドと対話できるようにします。削除したノードの Compute サービスをチェックします。 
[stack@director ~]$ source ~/overcloudrc
[stack@director ~]$ nova service-list | grep "overcloud-controller-1.localdomain"
ノードの Compute サービスを削除します。たとえば、overcloud-controller-1.localdomain の nova-scheduler サービスの ID が 5 の場合には、以下のコマンドを実行します。 
[stack@director ~]$ nova service-delete 5
削除したノードの各サービスでこのタスクを実行します。
新しいノードで openstack-nova-consoleauth サービスをチェックします。 
[stack@director ~]$ nova service-list | grep consoleauth
サービスが実行していない場合には、コントローラーノードにログインしてサービスを再起動します。 
[stack@director] ssh heat-admin@192.168.201.47
[heat-admin@overcloud-controller-0 ~]$ pcs resource restart openstack-nova-consoleauth

9.4.7. 結果

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

重要

「Object Storage ノードの置き換え」 のように Object Storage でリングファイルの自動構築を無効にした場合には、新規ノード用に Object Storage リングファイルを手動で構築する必要があります。リングファイルの手動構築についての詳しい情報は、「Object Storage ノードの置き換え」を参照してください。