第9章オーバークラウドのスケーリング

警告

オーバークラウドからノードを削除する場合は、openstack server delete を使用しないでください。本項で説明する手順をよく読み、適切にノードの削除/置き換えを行ってください。

オーバークラウドの作成後に、ノードを追加または削除する必要がある場合があります。たとえば、オーバークラウドのコンピュートノードを追加する場合などです。このような状況では、オーバークラウドの更新が必要です。

以下の表を使用して、各ノード種別のスケーリングに対するサポートを判断してください。

Expand

表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"
    }
  ]
}

{
  "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"
    }
  ]
}

Copy to Clipboard

Toggle word wrap

これらのパラメーターについての説明は、「オーバークラウドノードの登録」を参照してください。

以下のコマンドを実行して、これらのノードを登録します。

openstack baremetal import --json newnodes.json

$ openstack baremetal import --json newnodes.json

Copy to Clipboard

Toggle word wrap

新規ノードを登録したら、これらのノードのイントロスペクションプロセスを起動します。それぞれの新規ノードに対して、以下のコマンドを使用します。

openstack baremetal node manage [NODE UUID]
openstack overcloud node introspect [NODE UUID] --provide

$ openstack baremetal node manage [NODE UUID]
$ openstack overcloud node introspect [NODE UUID] --provide

Copy to Clipboard

Toggle word wrap

これにより、ノードのハードウェアプロパティーの検出とベンチマークが実行されます。

イントロスペクションプロセスが完了したら、各新規ノードを目的のロールにタグ付けします。たとえば、コンピュートノードの場合は、以下のコマンドを使用します。

openstack baremetal node set --property capabilities='profile:compute,boot_option:local' [NODE UUID]

$ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' [NODE UUID]

Copy to Clipboard

Toggle word wrap

オーバークラウドをスケーリングするには、ロールに必要なノード数を指定して openstack overcloud deploy を再度実行する必要があります。たとえば、コンピュートノードを 5 台にスケーリングするには、以下のコマンドを実行します。

openstack overcloud deploy --templates --compute-scale 5 [OTHER_OPTIONS]

$ openstack overcloud deploy --templates --compute-scale 5 [OTHER_OPTIONS]

Copy to Clipboard

Toggle word wrap

これにより、オーバークラウドのスタック全体が更新されます。これにより更新されるのはスタックだけである点に注意してください。オーバークラウドの削除や、スタックの置き換えは行われません。

重要

最初に作成したオーバークラウドからの環境ファイルおよびオプションをすべて追加するようにしてください。これには、コンピュート以外のノードに対する同様のスケジューリングパラメーターが含まれます。

9.2. コンピュートノードの削除
リンクのコピー

オーバークラウドからコンピュートノードを削除する必要がある状況が出てくる可能性があります。たとえば、問題のあるコンピュートノードを置き換える必要がある場合などです。

重要

オーバークラウドからコンピュートノードを削除する前に、負荷をそのノードから別のコンピュートノードに移行してください。詳しくは、「8章コンピュートノード間の仮想マシンの移行」を参照してください。

次に、オーバークラウド上でノードの Compute サービスを無効にします。これにより、ノードで新規インスタンスがスケジューリングされないようになります。

source ~/overcloudrc
openstack compute service list
openstack compute service set [hostname] nova-compute --disable
source ~/stackrc

$ source ~/overcloudrc
$ openstack compute service list
$ openstack compute service set [hostname] nova-compute --disable
$ source ~/stackrc

Copy to Clipboard

Toggle word wrap

オーバークラウドノードを削除するには、ローカルのテンプレートファイルを使用して、director の overcloud スタックへの更新が必要です。最初にオーバークラウドスタックの UUID を特定します。

openstack stack list

$ openstack stack list

Copy to Clipboard

Toggle word wrap

削除するノードの UUID を特定します。

openstack server list

$ openstack server list

Copy to Clipboard

Toggle word wrap

以下のコマンドを実行して、オーバークラウドのプランを更新し、スタックからノードを削除します。

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]

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

Copy to Clipboard

Toggle word wrap

重要

オーバークラウドの作成時に追加の環境ファイルを渡した場合には、予定外の手動変更がオーバークラウドに加えられないように、ここで -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

$ source ~/overcloudrc
$ openstack compute service list
$ openstack compute service delete [service-id]
$ source ~/stackrc

Copy to Clipboard

Toggle word wrap

さらに、ノードの Open vSwitch エージェントを削除します。

source ~/overcloudrc
openstack network agent list
openstack network agent delete [openvswitch-agent-id]
source ~/stackrc

$ source ~/overcloudrc
$ openstack network agent list
$ openstack network agent delete [openvswitch-agent-id]
$ source ~/stackrc

Copy to Clipboard

Toggle word wrap

オーバークラウドから自由にノードを削除して、別の目的でそのノードを再プロビジョニングできるようになりました。

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
```
```
$ source stackrc
$ openstack stack list --nested
```
Copy to Clipboard Toggle word wrap
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

$ 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

Copy to Clipboard

Toggle word wrap

アンダークラウドに、新規ノードプロビジョニング時のイメージのキャッシュと変換に対応できる 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 Toggle word wrap
出力には、既存のノードで実行中のサービスと、障害が発生しているノードで停止中のサービスがすべて表示されるはずです。
オーバークラウドの 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
  Copy to Clipboard Toggle word wrap
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 Toggle word wrap
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 Toggle word wrap
以下のコマンドを実行してフェンシングのステータスを確認します。
```
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 Toggle word wrap
director ノードで nova-compute サービスをチェックします。
```
sudo systemctl status openstack-nova-compute
openstack hypervisor list
```
```
$ sudo systemctl status openstack-nova-compute
$ openstack hypervisor list
```
Copy to Clipboard Toggle word wrap
出力では、メンテナンスモードに入っていないすべてのノードが up のステータスで表示されるはずです。
アンダークラウドサービスがすべて実行中であることを確認します。
```
sudo systemctl -t service
```
```
$ sudo systemctl -t service
```
Copy to Clipboard Toggle word wrap

9.4.2. Ceph monitor デーモンの削除
リンクのコピー

本手順では、ストレージクラスターから ceph-mon デーモンを削除します。コントローラーノードが Ceph monitor サービスを実行している場合には、以下のステップを完了して、ceph-mon デーモンを削除してください。この手順は、コントローラーが到達可能であることを前提としています。

注記

新しい Ceph monitor デーモンは、クラスターに新しいコントローラーが追加された後に追加されます。

置き換えるコントローラーに接続して、root になります。
```
ssh heat-admin@192.168.0.47
sudo su -
```
```
# ssh heat-admin@192.168.0.47
# sudo su -
```
Copy to Clipboard Toggle word wrap
注記
コントローラーが到達不可能な場合には、ステップ 1 と 2 をスキップして、稼働している任意のコントローラーノードでステップ 3 から手順を続行してください。
root として monitor を停止します。
```
systemctl stop ceph-mon@<monitor_hostname>
```
```
# systemctl stop ceph-mon@<monitor_hostname>
```
Copy to Clipboard Toggle word wrap
以下に例を示します。
```
systemctl stop ceph-mon@overcloud-controller-2
```
```
# systemctl stop ceph-mon@overcloud-controller-2
```
Copy to Clipboard Toggle word wrap
クラスターから monitor を削除します。
```
ceph mon remove <mon_id>
```
```
# ceph mon remove <mon_id>
```
Copy to Clipboard Toggle word wrap

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.21,172.18.0.22,172.18.0.24
mon initial members = overcloud-controller-2,overcloud-controller-1,overcloud-controller-0

Copy to Clipboard

Toggle word wrap

編集後:

mon host = 172.18.0.22,172.18.0.24
mon initial members = 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

Copy to Clipboard

Toggle word wrap

オーバークラウドノードの /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>

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

Copy to Clipboard

Toggle word wrap

9.4.3. ノードの置き換え
リンクのコピー

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

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

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

Copy to Clipboard

Toggle word wrap

以下の例では、overcloud-controller-1 ノードを削除し、それを overcloud-controller-3 に置き換えます。まず、ノードをメンテナンスモードに切り替えて、director が障害の発生したノードを再プロビジョニングしないようにします。nova list で表示されるインスタンスの ID を openstack baremetal node list で表示されるノード ID に関連付けます。

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

Toggle word wrap

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

openstack baremetal node maintenance set da3a8d19-8a59-4e9d-923a-6a336fe10284

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

Copy to Clipboard

Toggle word wrap

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

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

[stack@director ~]$ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 75b25e9a-948d-424a-9b3b-f0ef70a6eacf

Copy to Clipboard

Toggle word wrap

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

ssh heat-admin@192.168.0.47 "sudo pcs resource unmanage galera"

[stack@director ~]$ ssh heat-admin@192.168.0.47 "sudo pcs resource unmanage galera"

Copy to Clipboard

Toggle word wrap

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

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

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

Copy to Clipboard

Toggle word wrap

注記

Corosync での処理の試行回数を減らすことによって、置き換えプロセスを迅速化することができます。~/templates/remove-controller.yaml 環境ファイルに CorosyncSettleTries パラメーターを追加します。

parameter_defaults:
  CorosyncSettleTries: 5

parameter_defaults:
  CorosyncSettleTries: 5

Copy to Clipboard

Toggle word wrap

ノードのインデックスを特定したら、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

Toggle word wrap

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

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

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

openstack stack list --nested

[stack@director ~]$ openstack stack list --nested

Copy to Clipboard

Toggle word wrap

9.4.4. 手動による介入
リンクのコピー

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

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

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

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

Copy to Clipboard

Toggle word wrap

既存のノードの /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 Toggle word wrap
このコマンドにより、削除されたノード (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
  }
}
```
```
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 Toggle word wrap
後で使用するために、削除されたノードの 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"

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

Copy to Clipboard

Toggle word wrap

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

障害が発生したノードを 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

Toggle word wrap

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

sudo netstat -tulnp | grep 27017
tcp        0      0 192.168.0.47:27017    0.0.0.0:*               LISTEN      13415/mongod

[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

Toggle word wrap

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

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

[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

Toggle word wrap

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

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

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>

[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

Toggle word wrap

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

tripleo:PRIMARY> rs.status()

tripleo:PRIMARY> rs.status()

Copy to Clipboard

Toggle word wrap

_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

Toggle word wrap

重要

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

Toggle word wrap

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

Toggle word wrap

MongoDB を終了します。

tripleo:PRIMARY> exit

tripleo:PRIMARY> exit

Copy to Clipboard

Toggle word wrap

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

Toggle word wrap

新規ノードで Galera クラスターの確認を設定します。既存のノードから新規ノード上の同じ場所に /etc/sysconfig/clustercheck をコピーします。
root ユーザーが新規ノードの Gelera にアクセスできるように設定します。既存のノードから新規ノード上の同じ場所に /root/.my.cnf をコピーします。

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

sudo pcs cluster node add overcloud-controller-3

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

Copy to Clipboard

Toggle word wrap

各ノードの /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 Toggle word wrap
この例では、新規ノードは削除されたノードと同じ nodeid を使用していることに注意してください。この値を使用していないノードの ID 値に更新します。以下に例を示します。
```
node {
  ring0_addr: overcloud-controller-3
  nodeid: 4
}
```
```
node {
  ring0_addr: overcloud-controller-3
  nodeid: 4
}
```
Copy to Clipboard Toggle word wrap
新規ノードを含め、各コントローラーノードの /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 Toggle word wrap
また、overcloud-controller-2 で以下のコマンドを実行します。
```
sudo pcs cluster reload corosync
```
```
[heat-admin@overcloud-controller-2 ~]$ sudo pcs cluster reload corosync
```
Copy to Clipboard Toggle word wrap
新規ノードでこのコマンドを実行しないでください。

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

sudo pcs cluster start overcloud-controller-3

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

Copy to Clipboard

Toggle word wrap

Galera クラスターを再起動して Pacemaker の管理に戻します。

sudo pcs resource cleanup galera
sudo pcs resource manage galera

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

Copy to Clipboard

Toggle word wrap

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 Toggle word wrap

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

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

[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

Toggle word wrap

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

sudo pcs resource cleanup galera --node overcloud-controller-3

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

Copy to Clipboard

Toggle word wrap

クラスターをメンテナンスモードに戻します。

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

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

Copy to Clipboard

Toggle word wrap

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

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

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

Copy to Clipboard

Toggle word wrap

重要

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

9.4.5. オーバークラウドサービスの最終処理
リンクのコピー

オーバークラウドスタックの更新が完了したら、最終の設定が必要です。コントローラーノードのいずれかにログインして、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

Toggle word wrap

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

sudo pcs status

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

Copy to Clipboard

Toggle word wrap

注記

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

コントローラーノードでフェンシングが使用されている場合は、古いフェンシングレコードを削除して、新しいフェンシングレコードを作成します。

sudo pcs stonith show
sudo pcs stonish delete my-ipmilan-for-controller-1
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
sudo pcs constraint location my-ipmilan-for-controller-3 avoids overcloud-controller-3

[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

Copy to Clipboard

Toggle word wrap

フェンシングの再有効化

sudo pcs property set stonith-enabled=true

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

Copy to Clipboard

Toggle word wrap

注記

フェンシングの設定に関する詳しい情報は、「コントローラーノードのフェンシング」を参照してください。

director に戻ります。

exit

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

Copy to Clipboard

Toggle word wrap

9.4.6. L3 エージェントのルーターホスティングの最終処理
リンクのコピー

オーバークラウドと対話できるようにするために、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

Toggle word wrap

この一覧に、新規ノードではなく古いノードが引き続き表示される場合があります。これを置き換えるには、環境内の L3 ネットワークエージェントを一覧表示します。

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

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

Copy to Clipboard

Toggle word wrap

新規ノードおよび古いノード上のエージェントの 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

Toggle word wrap

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

neutron l3-agent-list-hosting-router r1

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

Copy to Clipboard

Toggle word wrap

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

neutron agent-list -F id -F host | grep overcloud-controller-1
| ddae8e46-3e8e-4a1b-a8b3-c87f13c294eb | overcloud-controller-1.localdomain |
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

Toggle word wrap

9.4.7. 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

Toggle word wrap

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

nova service-delete 5

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

Copy to Clipboard

Toggle word wrap

削除されたノードの各サービスについて、このタスクを実行します。

新規ノードで openstack-nova-consoleauth サービスを確認します。

nova service-list | grep consoleauth

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

Copy to Clipboard

Toggle word wrap

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

[stack@director] ssh heat-admin@192.168.0.47
pcs resource restart openstack-nova-consoleauth

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

Copy to Clipboard

Toggle word wrap

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
```
```
parameter_defaults:
  ObjectStorageCount: 3
```
Copy to Clipboard Toggle word wrap
ObjectStorageCount は、環境内のオブジェクトストレージノード数を定義します。今回の例では、ノードを 2 つから 3 つにスケーリングします。
openstack overcloud deploy の一部として、オーバークラウドの残りの環境ファイル (ENVIRONMENT_FILES) と共に swift-upscale.yaml ファイルを追加します。
```
openstack overcloud deploy --templates ENVIRONMENT_FILES -e swift-upscale.yaml
```
```
$ openstack overcloud deploy --templates ENVIRONMENT_FILES -e swift-upscale.yaml
```
Copy to Clipboard Toggle word wrap
注記
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
```
```
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
```
Copy to Clipboard Toggle word wrap
リングから不要になったノードを削除するには、swift-upscale.yaml の ObjectStorageCount の数を減らして不要になったリングを削除します。今回は 2 に減らします。
```
parameter_defaults:
  ObjectStorageCount: 2
```
```
parameter_defaults:
  ObjectStorageCount: 2
```
Copy to Clipboard Toggle word wrap
新規環境ファイル (remove-object-node.yaml) を作成します。このファイルは、指定したオブジェクトストレージノードを特定し、削除します。以下の内容では overcloud-objectstorage-1 の削除を指定します。
```
parameter_defaults:
  ObjectStorageRemovalPolicies:
    [{'resource_list': ['1']}]
```
```
parameter_defaults:
  ObjectStorageRemovalPolicies:
    [{'resource_list': ['1']}]
```
Copy to Clipboard Toggle word wrap

デプロイメントコマンドに両方の環境ファイルを含めます。

openstack overcloud deploy --templates ENVIRONMENT_FILES -e swift-upscale.yaml -e remove-object-node.yaml ...

$ openstack overcloud deploy --templates ENVIRONMENT_FILES -e swift-upscale.yaml -e remove-object-node.yaml ...

Copy to Clipboard

Toggle word wrap

director は、オーバークラウドからオブジェクトストレージノードを削除して、オーバークラウド上の残りのノードを更新し、ノードの削除に対応します。

トップに戻る

第9章オーバークラウドのスケーリング

9.1. 新たなノードの追加
リンクのコピー

9.2. コンピュートノードの削除
リンクのコピー

9.3. コンピュートノードの置き換え
リンクのコピー

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

9.4.1. 事前確認
リンクのコピー

9.4.2. Ceph monitor デーモンの削除
リンクのコピー

9.4.3. ノードの置き換え
リンクのコピー

9.4.4. 手動による介入
リンクのコピー

9.4.5. オーバークラウドサービスの最終処理
リンクのコピー

9.4.6. L3 エージェントのルーターホスティングの最終処理
リンクのコピー

9.4.7. Compute サービスの最終処理
リンクのコピー

9.4.8. 結果
リンクのコピー

9.5. Ceph Storage ノードの置き換え
リンクのコピー

9.6. オブジェクトストレージノードの置き換え
リンクのコピー

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

第9章 オーバークラウドのスケーリング

9.1. 新たなノードの追加リンクのコピーリンクがクリップボードにコピーされました!

9.2. コンピュートノードの削除リンクのコピーリンクがクリップボードにコピーされました!

9.3. コンピュートノードの置き換えリンクのコピーリンクがクリップボードにコピーされました!

9.4. コントローラーノードの置き換えリンクのコピーリンクがクリップボードにコピーされました!

9.4.1. 事前確認リンクのコピーリンクがクリップボードにコピーされました!

9.4.2. Ceph monitor デーモンの削除リンクのコピーリンクがクリップボードにコピーされました!

9.4.3. ノードの置き換えリンクのコピーリンクがクリップボードにコピーされました!

9.4.4. 手動による介入リンクのコピーリンクがクリップボードにコピーされました!

9.4.5. オーバークラウドサービスの最終処理リンクのコピーリンクがクリップボードにコピーされました!

9.4.6. L3 エージェントのルーターホスティングの最終処理リンクのコピーリンクがクリップボードにコピーされました!

9.4.7. Compute サービスの最終処理リンクのコピーリンクがクリップボードにコピーされました!

9.4.8. 結果リンクのコピーリンクがクリップボードにコピーされました!

9.5. Ceph Storage ノードの置き換えリンクのコピーリンクがクリップボードにコピーされました!

9.6. オブジェクトストレージノードの置き換えリンクのコピーリンクがクリップボードにコピーされました!

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

第9章オーバークラウドのスケーリング

9.1. 新たなノードの追加
リンクのコピー

9.2. コンピュートノードの削除
リンクのコピー

9.3. コンピュートノードの置き換え
リンクのコピー

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

9.4.1. 事前確認
リンクのコピー

9.4.2. Ceph monitor デーモンの削除
リンクのコピー

9.4.3. ノードの置き換え
リンクのコピー

9.4.4. 手動による介入
リンクのコピー

9.4.5. オーバークラウドサービスの最終処理
リンクのコピー

9.4.6. L3 エージェントのルーターホスティングの最終処理
リンクのコピー

9.4.7. Compute サービスの最終処理
リンクのコピー

9.4.8. 結果
リンクのコピー

9.5. Ceph Storage ノードの置き換え
リンクのコピー

9.6. オブジェクトストレージノードの置き換え
リンクのコピー