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

警告

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

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

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

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

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

ノード種別

スケールアップ

スケールダウン

備考

コントローラー

 

Compute

Y

Y

 

Ceph Storage ノード

Y

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

Block Storage ノード

 

Object Storage ノード

Y

Y

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

重要

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

8.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]

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

$ 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 を設定します。

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

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

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

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

重要

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

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

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

重要

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

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

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

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

$ openstack stack list

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

$ openstack server list

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

$ 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 ~/stack/overcloudrc
$ openstack compute service list
$ openstack compute service delete [service-id]
$ source ~/stack/stackrc

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

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

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

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

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

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

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

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

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

重要

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

8.4.1. 事前のチェック

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

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

    $ source stackrc
    $ openstack stack list --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
    $ openstack hypervisor list

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

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

    $ sudo systemctl -t service

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

8.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 内での settle の試行回数を減らすことによって、置き換えプロセスをスピードアップすることができます。~/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

8.4.4. 手動での介入

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

  1. コントローラーノードの 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   |
    ... +------------------------+ ... +-------------------------+
  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-0overcloud-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"
  4. 残りのノードの中の 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

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

  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 キーを使用して障害の発生したノードを削除します。この場合には name192.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. Galera クラスターを再起動して Pacemaker の管理に戻します。

    [heat-admin@overcloud-controller-0 ~]$ sudo pcs resource cleanup galera
    [heat-admin@overcloud-controller-0 ~]$ sudo pcs resource manage galera
  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. クラスターをメンテナンスモードに再度切り替えます。

    [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 ファイルは必要なくなった点に注意してください。

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

オーバークラウドのスタックの更新が完了したら、最終の設定が必要です。コントローラーノードの 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 コマンドを使用して、問題の解決後にそのサービスを再起動します。

director を終了します。

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

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

8.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.localdomainnova-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

8.4.8. 結果

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

重要

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

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

director では、director で作成したクラスター内の Ceph Storage ノードを置き換えることができます。手順については、『オーバークラウド向けの Red Hat Ceph Storage』を参照してください。

8.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 を追加します。

    $ 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. デプロイメントのコマンドで両環境ファイルを指定します。

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

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


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