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

警告

コンピュートインスタンスの高可用性 (またはインスタンス HA。『コンピュートインスタンスの高可用性』で説明) を使用している場合は、アップグレードとスケールアップはできません。操作を試みても失敗します。

HA を有効化しているインスタンスがある場合には、アップグレードまたはスケールアップを実行する前に無効にしてください。そのためには、「ロールバック」に記載の ロールバック の操作を実行してください。

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

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

表10.1 各ノード種別のスケーリングサポート

ノード種別

スケールアップ

スケールダウン

備考

コントローラー

 

Compute

Y

Y

 

Ceph Storage ノード

Y

オーバークラウドを最初に作成する際に Ceph Storage ノードを 1 つ以上設定する必要があります。

Block Storage ノード

 

Object Storage ノード

Y

Y

リングを手動で管理する必要があります (「Object Storage ノードの置き換え」に説明を記載)。

重要

オーバークラウドをスケーリングする前には、空き領域が少なくとも 10 GB あることを確認してください。この空き領域は、イメージの変換やノードのプロビジョニングプロセスのキャッシュに使用されます。

10.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.168.24.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.168.24.208"
    }
  ]
}

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

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

$ source ~/stackrc
(undercloud) $ openstack overcloud node import newnodes.json

新規ノードを追加した後には、それらのイントロスペクションプロセスを起動します。各新規ノードに以下のコマンドを使用します。

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

このコマンドは、ノードのハードウェアプロパティーの検出とベンチマークを実行します。

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

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

デプロイメント中に使用するブートイメージを設定します。bm-deploy-kernel および bm-deploy-ramdisk イメージの UUID を確認します。

(undercloud) $ openstack image list
+--------------------------------------+------------------------+
| ID                                   | Name                   |
+--------------------------------------+------------------------+
| 09b40e3d-0382-4925-a356-3a4b4f36b514 | bm-deploy-kernel       |
| 765a46af-4417-4592-91e5-a300ead3faf6 | bm-deploy-ramdisk      |
| ef793cd0-e65c-456a-a675-63cd57610bd5 | overcloud-full         |
| 9a51a6cb-4670-40de-b64b-b70f4dd44152 | overcloud-full-initrd  |
| 4f7e33f4-d617-47c1-b36f-cbe90f132e5d | overcloud-full-vmlinuz |
+--------------------------------------+------------------------+

新規ノードの deploy_kernel および deploy_ramdisk 設定にこれらの UUID を設定します。

(undercloud) $ openstack baremetal node set --driver-info deploy_kernel='09b40e3d-0382-4925-a356-3a4b4f36b514' [NODE UUID]
(undercloud) $ openstack baremetal node set --driver-info deploy_ramdisk='765a46af-4417-4592-91e5-a300ead3faf6' [NODE UUID]

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

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

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

重要

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

10.2. コンピュートノードの削除

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

重要

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

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

$ source ~/stack/overcloudrc
(overcloud) $ openstack compute service list
(overcloud) $ openstack compute service set [hostname] nova-compute --disable

アンダークラウドに戻ります。

(overcloud) $ source ~/stack/stackrc

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

(undercloud) $ openstack stack list

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

(undercloud) $ openstack server list

以下のコマンドを実行してスタックからノードを削除し、それに応じてプランを更新します。

(undercloud) $ 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 サービスを削除します。

(undercloud) $ source ~/stack/overcloudrc
(overcloud) $ openstack compute service list
(overcloud) $ openstack compute service delete [service-id]

ノードの Open vSwitch エージェントも削除します。

(overcloud) $ openstack network agent list
(overcloud) $ openstack network agent delete [openvswitch-agent-id]

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

10.3. コンピュートノードの置き換え

コンピュートノードに障害が発生した場合に、機能しているノードに置き換えることができます。コンピュートノードを置き換えるには、以下の手順を使用します。

このプロセスでは、インスタンスの可用性に影響を与えることなく、ノードを置き換えることができるようにします。

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

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

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

重要

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

10.4.1. 事前のチェック

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

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

    $ source stackrc
    (undercloud) $ openstack stack list --nested

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

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

    (undercloud) $ mkdir /home/stack/backup
    (undercloud) $ sudo mysqldump --all-databases --quick --single-transaction | gzip > /home/stack/backup/dump_db_undercloud.sql.gz
  3. アンダークラウドで、新規ノードのプロビジョニング時にイメージのキャッシュと変換に対応できる 10 GB の空きストレージ領域があるかどうかをチェックします。
  4. コントローラーノードで実行中の Pacemaker の状態をチェックします。たとえば、実行中のコントローラーノードの IP アドレスが 192.168.0.47 の場合には、以下のコマンドで Pacemaker のステータス情報を取得します。

    (undercloud) $ 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 を使用します)。

      (undercloud) $ for i in 192.168.0.47 192.168.0.46 ; do echo "*** $i ***" ; ssh heat-admin@$i "sudo mysql -p\$(sudo hiera -c /etc/puppet/hiera.yaml mysql::server::root_password) --execute=\"SHOW STATUS LIKE 'wsrep_local_state_comment'; SHOW STATUS LIKE 'wsrep_cluster_size';\""; done
  6. RabbitMQ のステータスをチェックします。たとえば、実行中のコントローラーノードの IP アドレスが 192.168.0.47 の場合には、以下のコマンドを実行してステータスを取得します。

    (undercloud) $ ssh heat-admin@192.168.0.47 "sudo docker exec \$(sudo docker ps -f name=rabbitmq-bundle -q) rabbitmqctl cluster_status"

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

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

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

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

    (undercloud) $ ssh heat-admin@192.168.0.47 "sudo pcs property show stonith-enabled"
  8. director ノードで nova-compute サービスをチェックします。

    (undercloud) $ sudo systemctl status openstack-nova-compute
    (undercloud) $ openstack hypervisor list

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

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

    (undercloud) $ sudo systemctl -t service

10.4.2. Ceph monitor デーモンの削除

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

注記

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

  1. 置き換えるコントローラーに接続して、root になります。

    # ssh heat-admin@192.168.0.47
    # sudo su -
    注記

    コントローラーが到達不可能な場合には、ステップ 1 と 2 をスキップして、稼働している任意のコントローラーノードでステップ 3 から手順を続行してください。

  2. root として monitor を停止します。

    # systemctl stop ceph-mon@<monitor_hostname>

    例:

    # systemctl stop ceph-mon@overcloud-controller-2
  3. クラスターから monitor を削除します。

    # ceph mon remove <mon_id>
  4. 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
  5. オーバークラウドノードの /etc/ceph/ceph.conf に同じ変更を適用します。

    注記

    置き換え用のコントローラーノードが追加されると、director によって関連するノード上の ceph.conf ファイルが更新されます。通常、設定ファイルは director によってのみ管理され、手動で編集する必要はありませんが、 このステップでは、新規ノードが追加される前に他のノードが再起動してしまった場合に一貫性を保つために、ファイルを編集しています。

  6. オプションとして、monitor データをアーカイブして、別のサーバーに保存します。

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

10.4.3. ノードの置き換え

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

(undercloud) $ 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 と相関させます。

(undercloud) $ 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 |
+--------------------------------------+------+--------------------------------------+

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

(undercloud) $ openstack baremetal node maintenance set da3a8d19-8a59-4e9d-923a-6a336fe10284

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

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

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

(undercloud) $ ssh heat-admin@192.168.0.47 "sudo pcs resource unmanage galera"

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

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

Corosync 内での settle の試行回数を減らすことによって、置き換えプロセスをスピードアップすることができます。~/templates/remove-controller.yaml 環境ファイルで CorosyncSettleTries パラメーターを指定します。

parameter_defaults:
  CorosyncSettleTries: 5

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

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

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

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

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

(undercloud) $ openstack stack list --nested

10.4.4. 手動での介入

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

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

    (undercloud) $ openstack server list -c Name -c Networks
    +------------------------+-----------------------+
    | 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. 各ノードの Corosync 設定から障害の発生したノードを削除して、Corosync を再起動します。この例では、overcloud-controller-0overcloud-controller-2 にログインして以下のコマンドを実行します。

    (undercloud) $ for NAME in overcloud-controller-0 overcloud-controller-2; do IP=$(openstack server list -c Networks -f value --name $NAME | cut -d "=" -f 2) ; ssh heat-admin@$IP "sudo pcs cluster localnode remove overcloud-controller-1; sudo pcs cluster reload corosync"; done
  3. 残りのノードの中の 1 台にログインして、crm_node コマンドで対象のノードをクラスターから削除します。

    (undercloud) $ ssh heat-admin@192.168.0.47
    [heat-admin@overcloud-controller-0 ~]$ sudo crm_node -R overcloud-controller-1 --force

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

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

    [heat-admin@overcloud-controller-0 ~]$ sudo docker exec -it $(sudo docker ps -f name=rabbitmq-bundle -q) rabbitmqctl forget_cluster_node rabbit@overcloud-controller-1
  5. Galera クラスター内のノードの一覧を更新し、クラスターをリフレッシュします。

    [heat-admin@overcloud-controller-0 ~]$ sudo pcs resource update galera cluster_host_map="overcloud-controller-0:overcloud-controller-0.internalapi.localdomain;overcloud-controller-3:overcloud-controller-3.internalapi.localdomain;overcloud-controller-2:overcloud-controller-2.internalapi.localdomain" wsrep_cluster_address="gcomm://overcloud-controller-0.internalapi.localdomain,overcloud-controller-3.internalapi.localdomain,overcloud-controller-2.internalapi.localdomain"
    [heat-admin@overcloud-controller-0 ~]$ sudo pcs resource cleanup galera
    [heat-admin@overcloud-controller-0 ~]$ sudo pcs resource manage galera
  6. 新規ノードをクラスターに追加します。

    [heat-admin@overcloud-controller-0 ~]$ sudo pcs cluster node add overcloud-controller-3
  7. 新規コントローラーノードを起動します。

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

手動の設定が完了しました。コントローラーにログインした状態を維持します。

別のターミナルを開き、オーバークラウドのデプロイメントコマンドを再度実行して、スタックの更新を継続します。

$ source ~/stackrc
(undercloud) $ openstack overcloud deploy --templates --control-scale 3 [OTHER OPTIONS]
重要

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

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

オーバークラウドのスタックの更新が完了したら、新たに追加されたコントローラーノード上で Pacemaker がコントローラーサービスを実行できるように、適切なクラスターノードのプロパティーを設定します。既存のコントローラーノードのどれかで (たとえば、overcloud-controller-0)、以下のコマンドを実行します。

[heat-admin@overcloud-controller-0 ~]$ for i in $(sudo pcs property | grep overcloud-controller-0: | cut -d' ' -f 3- | tr  ' ' '\n' | grep role); do sudo pcs property set --node overcloud-controller-3 $i; done

これ以降、新たに追加されたコントローラーノードで、Pacemaker の管理するサービスが実行されます。

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

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

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

director を終了します。

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

10.4.6. L3 エージェントのルーターホスティングの最終処理

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

$ source ~/overcloudrc
(overcloud) $ neutron l3-agent-list-hosting-router r1

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

(overcloud) $ neutron agent-list | grep "neutron-l3-agent"

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

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

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

(overcloud) $ neutron l3-agent-list-hosting-router r1

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

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

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

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

[stack@director ~]$ source ~/overcloudrc
(overcloud) $ openstack compute service list --host overcloud-controller-1.localdomain

削除したノードのコンピュートサービスを削除します。

(overcloud) $ for SERVICE in $(openstack compute service list --host overcloud-controller-1.localdomain -f value -c ID) ; do openstack compute service delete $SERVICE ; done

10.4.8. 結果

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

重要

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

10.5. Ceph Storage ノードの置き換え

director では、director で作成したクラスター内の Ceph Storage ノードを置き換えることができます。手順については、『Deploying an Overcloud with Containerized Red Hat Ceph』ガイドを参照してください。

10.6. Object Storage ノードの置き換え

本項では、クラスターの整合性を保ちながら Object Storage ノードを置き換える方法を説明します。以下の例では、2 台のノードで構成される Object Storage クラスターで、overcloud-objectstorage-1 を置き換える必要があります。この手順は、ノードを 1 台追加して、overcloud-objectstorage-1 を削除することを目的とします (実際には置き換えます)。

  1. ~/templates/swift-upscale.yaml という名前の環境ファイルを作成して、以下の内容を記載します。

    parameter_defaults:
      ObjectStorageCount: 3

    ObjectStorageCount は、環境内で Object Storage ノードをいくつ指定するかを定義します。今回の例では、ノードを 2 つから 3 つにスケーリングします。

  2. openstack overcloud deploy の一部として、オーバークラウドの残りの環境ファイル (ENVIRONMENT_FILES) と合わせて swift-upscale.yaml を追加します。

    $ source ~/stackrc
    (undercloud) $ openstack overcloud deploy --templates ENVIRONMENT_FILES -e swift-upscale.yaml
    注記

    swift-upscale.yaml ファイルのパラメーターが以前の環境ファイルのパラメーターよりも優先されるように、このファイルを環境ファイルの一覧の最後に追加します。

    デプロイメントが完了したら、オーバークラウドには別の Object Storage ノードが追加されています。

  3. データは新しいノード用に複製する必要があります。ノードを削除する前に (この場合は overcloud-objectstorage-1)、replication pass が新規ノードで完了するのを待つ必要があります。/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
  4. リングから以前のノードを削除するには、swift-upscale.yamlObjectStorageCount の数を減らして以前のリングを省略します。今回は 3 から 2 に減らします。

    parameter_defaults:
      ObjectStorageCount: 2
  5. 新規環境ファイル (remove-object-node.yaml) を作成します。このファイルは、以前に指定した Object Storage ノードを特定し、削除します。以下の内容では overcloud-objectstorage-1 の削除を指定します。

    parameter_defaults:
      ObjectStorageRemovalPolicies:
        [{'resource_list': ['1']}]
  6. デプロイメントのコマンドで両環境ファイルを指定します。

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

director は、オーバークラウドから Object Storage ノードを削除して、オーバークラウド上の残りのノードを更新し、ノードの削除に対応します。

10.7. ノードのブラックリスト登録

オーバークラウドノードがデプロイメントの更新を受け取らないように除外することができます。これは、既存のノードがコア Heat テンプレートコレクションから更新されたパラメーターセットやリソースを受け取らないように除外した状態で、新規ノードをスケーリングする場合に役立ちます。つまり、ブラックリストに登録されているノードは、スタック操作の影響を受けなくなります。

ブラックリストを作成するには、環境ファイルの DeploymentServerBlacklist パラメーターを使います。

ブラックリストの設定

DeploymentServerBlacklist パラメーターは、サーバー名のリストです。新たな環境ファイルを作成するか、既存のカスタム環境ファイルにパラメーター値を追加して、ファイルをデプロイメントコマンドに渡します。

parameter_defaults:
  DeploymentServerBlacklist:
    - overcloud-compute-0
    - overcloud-compute-1
    - overcloud-compute-2
注記

パラメーター値のサーバー名には、実際のサーバーホスト名ではなく、OpenStack Orchestation (Heat) で定義されている名前を使用します。

openstack overcloud deploy コマンドで、この環境ファイルを指定します。以下に例を示します。

$ source ~/stackrc
(undercloud) $ openstack overcloud deploy --templates \
  -e server-blacklist.yaml \
  [OTHER OPTIONS]

Heat はリスト内のサーバーをすべてブラックリストし、Heat デプロイメントの更新を受け取らないようにします。スタック操作が完了した後には、ブラックリストに登録されたサーバーは以前の状態のままとなります。操作中に os-collect-config エージェントの電源をオフにしたり、停止したりすることもできます。

警告
  • ノードをブラックリストに登録する場合には、注意が必要です。ブラックリストを有効にした状態で要求された変更を適用する方法を十分に理解していない限り、ブラックリストは使用しないでください。ブラックリスト機能を使うと、スタックがハングしたり、オーバークラウドが誤って設定されたりする場合があります。たとえば、クラスター設定の変更が Pacemaker クラスターの全メンバーに適用される場合には、この変更の間に Pacemaker クラスターのメンバーをブラックリストに登録すると、クラスターが機能しなくなる場合があります。
  • 更新またはアップグレードの操作中にブラックリストを使わないでください。これらの操作には、特定のサーバーに対する変更を分離するための独自の方法があります。詳細は、『Upgrading Red Hat OpenStack Platform』のドキュメントを参照してください。
  • サーバーをブラックリストに追加すると、そのサーバーをブラックリストから削除するまでは、それらのノードにはさらなる変更は適用されません。これには、更新、アップグレード、スケールアップ、スケールダウン、およびノードの置き換えが含まれます。

ブラックリストのクリア

その後のスタック操作のためにブラックリストをクリアするには、DeploymentServerBlacklist を編集して空の配列を使用します。

parameter_defaults:
  DeploymentServerBlacklist: []
警告

DeploymentServerBlacklist パラメーターを単に削除しないでください。パラメーターを削除しただけの場合には、オーバークラウドデプロイメントには、前回保存された値が使用されます。


このページには機械翻訳が使用されている場合があります (詳細はこちら)。