Red Hat Training
A Red Hat training course is available for Red Hat OpenStack Platform
第9章 オーバークラウドのスケーリング
オーバークラウドからノードを削除する場合は、openstack server delete
を使用しないでください。本項で説明する手順をよく読み、適切にノードの削除/置き換えを行ってください。
オーバークラウドの作成後に、ノードを追加または削除する必要がある場合があります。たとえば、オーバークラウドのコンピュートノードを追加する場合などです。このような状況では、オーバークラウドの更新が必要です。
以下の表を使用して、各ノード種別のスケーリングに対するサポートを判断してください。
表9.1 各ノード種別のスケーリングサポート
ノード種別 | スケールアップ | スケールダウン | 説明 |
コントローラー | 非対応 | 非対応 | |
コンピュート | 対応 | 対応 | |
Ceph Storage ノード | 対応 | 非対応 | オーバークラウドを最初に作成する際に Ceph Storage ノードを 1 つ以上設定する必要があります。 |
ブロックストレージノード | 非対応 | 非対応 | |
オブジェクトストレージノード | 対応 | 対応 | 「オブジェクトストレージノードの置き換え」で説明するように、手動でリングを管理する必要があります。 |
オーバークラウドをスケーリングする前には、少なくとも 10 GB の空き領域を確保するようにしてください。この空き領域は、イメージの変換やノードのプロビジョニングプロセスのキャッシュに使用されます。
9.1. 新たなノードの追加
director のノードプールにさらにノードを追加するには、登録する新規ノードの詳細を記載した新しい JSON ファイル (例: newnodes.json
) を作成します。
{ "nodes":[ { "mac":[ "dd:dd:dd:dd:dd:dd" ], "cpu":"4", "memory":"6144", "disk":"40", "arch":"x86_64", "pm_type":"pxe_ipmitool", "pm_user":"admin", "pm_password":"p@55w0rd!", "pm_addr":"192.0.2.207" }, { "mac":[ "ee:ee:ee:ee:ee:ee" ], "cpu":"4", "memory":"6144", "disk":"40", "arch":"x86_64", "pm_type":"pxe_ipmitool", "pm_user":"admin", "pm_password":"p@55w0rd!", "pm_addr":"192.0.2.208" } ] }
これらのパラメーターについての説明は、「オーバークラウドノードの登録」を参照してください。
以下のコマンドを実行して、これらのノードを登録します。
$ openstack baremetal import --json newnodes.json
新規ノードを登録したら、これらのノードのイントロスペクションプロセスを起動します。それぞれの新規ノードに対して、以下のコマンドを使用します。
$ openstack baremetal node manage [NODE UUID] $ openstack overcloud node introspect [NODE UUID] --provide
これにより、ノードのハードウェアプロパティーの検出とベンチマークが実行されます。
イントロスペクションプロセスが完了したら、各新規ノードを目的のロールにタグ付けします。たとえば、コンピュートノードの場合は、以下のコマンドを使用します。
$ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' [NODE UUID]
オーバークラウドをスケーリングするには、ロールに必要なノード数を指定して openstack overcloud deploy
を再度実行する必要があります。たとえば、コンピュートノードを 5 台にスケーリングするには、以下のコマンドを実行します。
$ openstack overcloud deploy --templates --compute-scale 5 [OTHER_OPTIONS]
これにより、オーバークラウドのスタック全体が更新されます。これにより更新されるのはスタックだけである点に注意してください。オーバークラウドの削除や、スタックの置き換えは行われません。
最初に作成したオーバークラウドからの環境ファイルおよびオプションをすべて追加するようにしてください。これには、コンピュート以外のノードに対する同様のスケジューリングパラメーターが含まれます。
9.2. コンピュートノードの削除
オーバークラウドからコンピュートノードを削除する必要がある状況が出てくる可能性があります。たとえば、問題のあるコンピュートノードを置き換える必要がある場合などです。
オーバークラウドからコンピュートノードを削除する前に、負荷をそのノードから別のコンピュートノードに移行してください。詳しくは、「8章コンピュートノード間の仮想マシンの移行」を参照してください。
次に、オーバークラウド上でノードの Compute サービスを無効にします。これにより、ノードで新規インスタンスがスケジューリングされないようになります。
$ source ~/overcloudrc $ openstack compute service list $ openstack compute service set [hostname] nova-compute --disable $ source ~/stackrc
オーバークラウドノードを削除するには、ローカルのテンプレートファイルを使用して、director の overcloud
スタックへの更新が必要です。最初にオーバークラウドスタックの UUID を特定します。
$ openstack stack list
削除するノードの UUID を特定します。
$ openstack server list
以下のコマンドを実行して、オーバークラウドのプランを更新し、スタックからノードを削除します。
$ openstack overcloud deploy --update-plan-only \ --templates \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e /home/stack/templates/network-environment.yaml \ -e /home/stack/templates/storage-environment.yaml \ -e /home/stack/templates/rhel-registration/environment-rhel-registration.yaml \ [-e |...] $ openstack overcloud node delete --stack [STACK_UUID] --templates -e [ENVIRONMENT_FILE] [NODE1_UUID] [NODE2_UUID] [NODE3_UUID]
オーバークラウドの作成時に追加の環境ファイルを渡した場合には、予定外の手動変更がオーバークラウドに加えられないように、ここで -e
または --environment-file
オプションを使用して環境ファイルを再度渡します。
操作を続行する前に、openstack overcloud node delete
コマンドが完全に終了したことを確認します。openstack stack list
コマンドを使用して、overcloud
スタックが UPDATE_COMPLETE
のステータスに切り替わっていることを確認してください。
最後に、ノードの Compute サービスを削除します。
$ source ~/overcloudrc $ openstack compute service list $ openstack compute service delete [service-id] $ source ~/stackrc
さらに、ノードの Open vSwitch エージェントを削除します。
$ source ~/overcloudrc $ openstack network agent list $ openstack network agent delete [openvswitch-agent-id] $ source ~/stackrc
オーバークラウドから自由にノードを削除して、別の目的でそのノードを再プロビジョニングできるようになりました。
9.3. コンピュートノードの置き換え
コンピュートノードに障害が発生した場合に、そのノードを機能しているノードに置き換えることができます。コンピュートノードを置き換えるには、以下のプロセスを使用します。
- 既存のコンピュートノードから負荷を移行して、ノードをシャットダウンする。このプロセスについては、「8章コンピュートノード間の仮想マシンの移行」を参照してください。
- オーバークラウドからコンピュートノードを削除する。このプロセスについては、「コンピュートノードの削除」を参照してください。
- 新しいコンピュートノードでオーバークラウドをスケールアウトする。このプロセスについては、「新たなノードの追加」を参照してください。
このプロセスにより、インスタンスの可用性に影響を与えずにノードを置き換えることができます。
9.4. コントローラーノードの置き換え
特定の状況では、高可用性クラスター内のコントローラーノードに障害が発生することがあります。その場合は、そのコントローラーノードをクラスターから削除して新しいコントローラーノードに置き換える必要があります。この操作には、ノードがクラスター内の他のノードに接続できるようにする手順も含まれます。
本項では、コントローラーノードを置き換える手順について説明します。このプロセスでは、openstack overcloud deploy
コマンドを実行し、コントローラーノードを置き換えるリクエストでオーバークラウドを更新します。このプロセスは完全には自動的に行われないことに注意してください。オーバークラウドスタックの更新プロセス中、ある時点で openstack overcloud deploy
コマンドが異常を報告し、オーバークラウドスタックの更新が停止します。この時点で、プロセスに手動で介入する必要あります。その後、openstack overcloud deploy
プロセスを続行することができます。
以下の手順は、高可用性環境にのみ適用されます。コントローラーノードを 1 台しか使用していない場合は、この手順を使用しないでください。
9.4.1. 事前確認
オーバークラウドコントローラーノードの置き換えを試みる前に、Red Hat OpenStack Platform 環境の現在の状態をチェックしておくことが重要です。このチェックしておくと、コントローラーの置き換えプロセス中に複雑な事態が発生するのを防ぐことができます。以下の事前チェックリストを使用して、コントローラーノードの置き換えを実行しても安全かどうかを確認してください。チェックのためのコマンドはすべてアンダークラウドで実行します。
アンダークラウドで、
overcloud
スタックの現在の状態をチェックします。$ source stackrc $ openstack stack list --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
- アンダークラウドに、新規ノードプロビジョニング時のイメージのキャッシュと変換に対応できる 10 GB の空きストレージ領域があることを確認します。
コントローラーノードで実行中の Pacemaker の状態をチェックします。たとえば、実行中のコントローラーノードの IP アドレスが 192.168.0.47 の場合には、以下のコマンドで Pacemaker のステータス情報を取得します。
$ 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 を使用します) で以下のコマンドを使用して、これらのパラメーターを確認します。
$ 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
-
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 $ openstack hypervisor list
出力では、メンテナンスモードに入っていないすべてのノードが
up
のステータスで表示されるはずです。アンダークラウドサービスがすべて実行中であることを確認します。
$ sudo systemctl -t service
9.4.2. Ceph monitor デーモンの削除
本手順では、ストレージクラスターから ceph-mon
デーモンを削除します。コントローラーノードが Ceph monitor サービスを実行している場合には、以下のステップを完了して、ceph-mon デーモンを削除してください。この手順は、コントローラーが到達可能であることを前提としています。
新しい Ceph monitor デーモンは、クラスターに新しいコントローラーが追加された後に追加されます。
置き換えるコントローラーに接続して、root になります。
# ssh heat-admin@192.168.0.47 # sudo su -
注記コントローラーが到達不可能な場合には、ステップ 1 と 2 をスキップして、稼働している任意のコントローラーノードでステップ 3 から手順を続行してください。
root として monitor を停止します。
# systemctl stop ceph-mon@<monitor_hostname>
以下に例を示します。
# systemctl stop ceph-mon@overcloud-controller-2
クラスターから monitor を削除します。
# ceph mon remove <mon_id>
Ceph monitor ノード上で、
/etc/ceph/ceph.conf
から monitor のエントリーを削除します。たとえば、controller-2 を削除した場合には、controller-2 の 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-1,overcloud-controller-0
オーバークラウドノードの
/etc/ceph/ceph.conf
に同じ変更を適用します。注記置き換え用のコントローラーノードが追加されると、director によって該当するオーバークラウドノード上の
ceph.conf
ファイルが更新されます。通常、この設定ファイルは director によってのみ管理され、手動で編集する必要はありませんが、このステップでは、新規ノードが追加される前に他のノードが再起動してしまった場合に一貫性を保つために、ファイルを編集しています。オプションとして、monitor データをアーカイブして、別のサーバーに保存します。
# mv /var/lib/ceph/mon/<cluster>-<daemon_id> /var/lib/ceph/mon/removed-<cluster>-<daemon_id>
9.4.3. ノードの置き換え
削除するノードのインデックスを特定します。ノードのインデックスは、nova list
の出力に表示されるインスタンス名のサフィックスです。
[stack@director ~]$ openstack server 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 を openstack baremetal node list
で表示されるノード ID に関連付けます。
[stack@director ~]$ openstack baremetal 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 ~]$ openstack baremetal node maintenance set da3a8d19-8a59-4e9d-923a-6a336fe10284
新規ノードを control
プロファイルにタグ付けします。
[stack@director ~]$ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 75b25e9a-948d-424a-9b3b-f0ef70a6eacf
オーバークラウドのデータベースは、置き換え手順の実行中に稼働し続ける必要があります。この手順の実行中に Pacemaker が Galera を停止しないようにするには、実行中のコントローラーノードを選択して、そのコントローラーノードの IP アドレスを使用して、アンダークラウドで以下のコマンドを実行します。
[stack@director ~]$ ssh heat-admin@192.168.0.47 "sudo pcs resource unmanage galera"
削除するノードのインデックスを定義する YAML ファイルを作成します (~/templates/remove-controller.yaml
)。
parameters: ControllerRemovalPolicies: [{'resource_list': ['1']}]
Corosync での処理の試行回数を減らすことによって、置き換えプロセスを迅速化することができます。~/templates/remove-controller.yaml
環境ファイルに CorosyncSettleTries
パラメーターを追加します。
parameter_defaults: CorosyncSettleTries: 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 回だけである点に注意してください。
director は古いノードを削除して、新しいノードを作成してから、オーバークラウドスタックを更新します。以下のコマンドを使用すると、オーバークラウドスタックのステータスをチェックすることができます。
[stack@director ~]$ openstack stack list --nested
9.4.4. 手動による介入
ControllerNodesPostDeployment
段階の ControllerDeployment_Step1
で、オーバークラウドスタックの更新が UPDATE_FAILED
エラーにより停止します。これは、一部の Puppet モジュールがノードの置き換えをサポートしていないためです。プロセスのこの時点で手動による介入が必要です。以下の設定手順に従ってください。
コントローラーノードの IP アドレスの一覧を取得します。以下に例を示します。
[stack@director ~]$ openstack server 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"
このコマンドにより、削除されたノード (
overcloud-controller-1
) の ID が含まれるnodelist
が表示されます。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')
重要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
Galera クラスターのノード一覧を更新します。
[heat-admin@overcloud-controller-0 ~]$ sudo pcs resource update galera wsrep_cluster_address=gcomm://overcloud-controller-0,overcloud-controller-3,overcloud-controller-2
-
新規ノードで Galera クラスターの確認を設定します。既存のノードから新規ノード上の同じ場所に
/etc/sysconfig/clustercheck
をコピーします。 -
root
ユーザーが新規ノードの Gelera にアクセスできるように設定します。既存のノードから新規ノード上の同じ場所に/root/.my.cnf
をコピーします。 新規ノードをクラスターに追加します。
[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
Galera クラスターを再起動して Pacemaker の管理に戻します。
[heat-admin@overcloud-controller-0 ~]$ sudo pcs resource cleanup galera [heat-admin@overcloud-controller-0 ~]$ sudo pcs resource manage galera
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
クラスターをメンテナンスモードに戻します。
[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.5. オーバークラウドサービスの最終処理
オーバークラウドスタックの更新が完了したら、最終の設定が必要です。コントローラーノードのいずれかにログインして、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 stonith show [heat-admin@overcloud-controller-0 ~]$ sudo pcs stonish delete my-ipmilan-for-controller-1 [heat-admin@overcloud-controller-0 ~]$ sudo pcs stonith create my-ipmilan-for-controller-3 fence_ipmilan pcmk_host_list=overcloud-controller-3 ipaddr=192.0.2.208 login=admin passwd=p@55w0rd! lanplus=1 cipher=1 op monitor interval=60s [heat-admin@overcloud-controller-0 ~]$ sudo pcs constraint location my-ipmilan-for-controller-3 avoids overcloud-controller-3
フェンシングの再有効化
[heat-admin@overcloud-controller-0 ~]$ sudo pcs property set stonith-enabled=true
フェンシングの設定に関する詳しい情報は、「コントローラーノードのフェンシング」を参照してください。
director に戻ります。
[heat-admin@overcloud-controller-0 ~]$ exit
9.4.6. L3 エージェントのルーターホスティングの最終処理
オーバークラウドと対話できるようにするために、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.7. 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.0.47 [heat-admin@overcloud-controller-0 ~]$ pcs resource restart openstack-nova-consoleauth
9.4.8. 結果
これで、障害が発生したコントローラーノードと関連サービスが、新規ノードに置き換えられました。
「オブジェクトストレージノードの置き換え」に示すように、オブジェクトストレージの自動リング構築を無効にしている場合は、新規ノード用にオブジェクトストレージのリングファイルを手動で構築する必要があります。リングファイルを手動で構築する方法は、「オブジェクトストレージノードの置き換え」を参照してください。
9.5. Ceph Storage ノードの置き換え
director を使用して、director で作成したクラスター内の Ceph Storage ノードを置き換えることができます。その手順は、『オーバークラウド向けの Red Hat Ceph Storage』を参照してください。
9.6. オブジェクトストレージノードの置き換え
本項では、クラスターの整合性を保ちながらオブジェクトストレージノードを置き換える方法を説明します。以下の例では、2 台のノードで構成されるオブジェクトストレージクラスターで、ノード overcloud-objectstorage-1
を置き換える必要があります。目的は、ノードをあと 1 台追加して、overcloud-objectstorage-1
を削除することです (結果的に、置き換えることになります)。
以下の内容で、~/templates/swift-upscale.yaml という名前の環境ファイルを作成します。
parameter_defaults: ObjectStorageCount: 3
ObjectStorageCount
は、環境内のオブジェクトストレージノード数を定義します。今回の例では、ノードを 2 つから 3 つにスケーリングします。openstack overcloud deploy
の一部として、オーバークラウドの残りの環境ファイル (ENVIRONMENT_FILES) と共にswift-upscale.yaml
ファイルを追加します。$ openstack overcloud deploy --templates ENVIRONMENT_FILES -e swift-upscale.yaml
注記swift-upscale.yaml
ファイルのパラメーターがそれより前の環境ファイルのパラメーターよりも優先されるように、このファイルを環境ファイルの一覧の最後に追加します。再デプロイメントが完了したら、オーバークラウドには新たなオブジェクトストレージノードが含まれます。
ここで、データを新しいノードに複製する必要があります。ノードを削除する前に (この場合は
overcloud-objectstorage-1
)、複製のパス が新規ノードで完了するのを待つ必要があります。/var/log/swift/swift.log
で複製パスの進捗を確認することができます。パスが完了すると、Object Storage サービスは以下のようなエントリーをログに残します。Mar 29 08:49:05 localhost object-server: Object replication complete. Mar 29 08:49:11 localhost container-server: Replication run OVER Mar 29 08:49:13 localhost account-server: Replication run OVER
リングから不要になったノードを削除するには、
swift-upscale.yaml
のObjectStorageCount
の数を減らして不要になったリングを削除します。今回は 2 に減らします。parameter_defaults: ObjectStorageCount: 2
新規環境ファイル (
remove-object-node.yaml
) を作成します。このファイルは、指定したオブジェクトストレージノードを特定し、削除します。以下の内容ではovercloud-objectstorage-1
の削除を指定します。parameter_defaults: ObjectStorageRemovalPolicies: [{'resource_list': ['1']}]
デプロイメントコマンドに両方の環境ファイルを含めます。
$ openstack overcloud deploy --templates ENVIRONMENT_FILES -e swift-upscale.yaml -e remove-object-node.yaml ...
director は、オーバークラウドからオブジェクトストレージノードを削除して、オーバークラウド上の残りのノードを更新し、ノードの削除に対応します。