コンピュートインスタンスの高可用性

Red Hat OpenStack Platform 16.2

コンピュートインスタンスの高可用性の設定

概要

本ガイドでは、インスタンスの高可用性 (インスタンス HA) を管理する方法について説明します。インスタンス HA が設定された Red Hat OpenStack Platform (RHOSP) では、コンピュートノードに障害が発生した場合に、インスタンスを自動的に退避させ別のコンピュートノードに作成し直すことができます。

前書き

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

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、弊社 の CTO、Chris Wright のメッセージ を参照してください。

Red Hat ドキュメントへのフィードバック (英語のみ)

弊社ドキュメントに対するご意見をお聞かせください。ドキュメントの改善点があればお知らせください。

ドキュメントへのダイレクトフィードバック (DDF) 機能の使用 (英語版のみ)

特定の文章、段落、またはコードブロックに対して直接コメントを送付するには、DDF の Add Feedback 機能を使用してください。なお、この機能は英語版のドキュメントでのみご利用いただけます。

  1. Multi-page HTML 形式でドキュメントを表示します。
  2. ドキュメントの右上隅に Feedback ボタンが表示されていることを確認してください。
  3. コメントするテキスト部分をハイライト表示します。
  4. Add Feedback をクリックします。
  5. Add Feedback フィールドにコメントを入力します。
  6. (オプション) ドキュメントチームが連絡を取り問題についてお伺いできるように、ご自分のメールアドレスを追加します。
  7. Submit をクリックします。

第1章 インスタンス HA デプロイメントの導入および計画

コンピュートインスタンスの高可用性 (インスタンス HA) は、障害が発生したコンピュートノードからインスタンスを退避して、別のコンピュートノードにインスタンスを再作成するのに使用できるツールです。

インスタンス HAは、共有ストレージまたはローカルストレージ環境で機能します。したがって、退避させたインスタンスは同じネットワーク設定 (静的 IP アドレス、Floating IP アドレス等) を維持します。再作成されたインスタンスも、新しいコンピュートノード内で同じ特性を維持します。

1.1. インスタンス HA の仕組み

コンピュートノードに障害が発生すると、オーバークラウドのフェンシングエージェントはノードをフェンシングします。続いてインスタンス HA エージェントは、障害が発生したコンピュートノードから別のコンピュートノードにインスタンスを退避させます。

コンピュートノードに障害が発生しインスタンス HA がトリガーされると、以下のイベントが発生します。

  1. 障害が発生すると、IPMI エージェントは最初のレイヤーのフェンシングを実行します。これには、ノードがシャットダウンされるように物理的にリセットする操作や、データの破損やオーバークラウド上に複数の同一インスタンスが存在するのを回避する操作が含まれます。ノードがオフラインである場合、フェンシング済みとみなされます。
  2. IPMI による物理的なフェンシングの後に以下のコマンドを実行すると、fence-nova エージェントが第二レイヤーのフェンシングを自動的に実施し、フェンシング済みのノードを属性 "evacuate=yes" でマーキングします (この属性は、ノードごとに設定する必要があります)。

    $ attrd_updater -n evacuate -A name="evacuate" host="FAILEDHOST" value="yes"

    FAILEDHOST は障害が発生したコンピュートノードの名前です。

  3. nova-evacuate エージェントは常にバックグラウンドで動作し、クラスターに “evacuate=yes” 属性のノードがないか定期的に確認します。この属性がフェンシング済みノードに含まれることを nova-evacuate が検出すると、エージェントはノードからの全インスタンスの退避を開始します。退避プロセスは、いつでも実行できる手動インスタンス退避プロセスと似ています。
  4. IPMI によるリセット後に障害が発生したノードが再起動すると、そのノードの nova-compute プロセスも自動的に開始されます。ノードはそれまでフェンシングされていたので、Pacemaker がノードのフェンシングを解除するまで、新しいインスタンスを実行しません。
  5. コンピュートノードがオンライン状態にあることを Pacemaker が検出すると、ノードで compute-unfence-trigger リソースエージェントが起動します。これにより、ノードが解放され、インスタンスが再び実行できるようになります。

1.2. インスタンス HA デプロイメントのプランニング

インスタンス HA をデプロイする前に、適合性のためにリソース名を確認し、環境に応じてストレージおよびネットワークを設定します。

  • コンピュートノードのホスト名および Pacemaker リモートリソース名は、W3C 命名規則に従う必要があります。詳細は、W3C ドキュメントの Declaring Namespaces および Names and Tokens を参照してください。
  • 一般的に、インスタンス HA ではインスタンスのディスクイメージ用に共有ストレージを設定する必要があります。したがって、no-shared-storage オプションの使用を試みると、退避中に InvalidSharedStorage エラーが表示され、インスタンスが別のコンピュートノードで起動しない場合があります。

    ただし、すべてのインスタンスが OpenStack Block Storage (cinder) ボリュームから起動するように設定されている場合には、インスタンスのディスクイメージ用に共有ストレージを設定する必要はないので、no-shared-storage オプションを使用してすべてのインスタンスを退避させることができます。

    インスタンスが Block Storage ボリュームから起動するように設定されている場合には、退避させたインスタンスは別のコンピュートノード上の同じボリュームからブートします。したがって、OS イメージおよびアプリケーションデータが OpenStack Block Storage ボリュームに保管されているので、退避させたインスタンスは直ちにジョブを再開します。

  • インスタンス HA をスパイン/リーフ環境でデプロイする場合には、コントローラーノードおよびコンピュートノードに単一の internal_api ネットワークを定義する必要があります。その後、各リーフのサブネットを定義できます。スパイン/リーフ型ネットワークの設定についての詳しい情報は、『Spine Leaf Networking』「Creating a roles data file」を参照してください。
  • Red Hat OpenStack Platform 13 以降では、オーバークラウドのアップグレードの一環として、director を使用してインスタンス HA をアップグレードします。オーバークラウドのアップグレードに関する詳しい情報は、『Keeping Red Hat OpenStack Platform Updated』を参照してください。
  • インストール後の director でのインスタンス HA の無効化はサポートされていません。デプロイメントからインスタンス HA コンポーネントを手動で削除する回避策は、「How can I remove Instance HA components from the controller nodes?」のアーティクルを参照してください。.

    重要

    この回避策は、実稼働環境用には検証されていません。実稼働環境で実装する前に、テスト環境で手順を検証する必要があります。

1.3. インスタンス HA リソースエージェント

インスタンス HA は fence_computeNovaEvacuate、および comput-unfence-trigger リソースエージェントを使用して、コンピュートノードに障害が発生した場合にインスタンスの退避および再作成を行います。

エージェント名クラスター内での名前ロール

fence_compute

fence-nova

コンピュートノードが使用不能になった場合に、退避のためにそのノードをマーキングする。

NovaEvacuate

nova-evacuate

障害が発生したノードからインスタンスを退避させる。このエージェントは、コントローラーノードのいずれかで動作します。

Dummy

compute-unfence-trigger

フェンシングされたノードを解放し、再びインスタンスを実行できるようにする。

第2章 インスタンス HA のインストールと設定

Red Hat OpenStack Platform (RHOSP) director は、インスタンスの高可用性 (HA) をデプロイします。ただし、新規オーバークラウドで新たなインスタンス HA デプロイメントを設定するには、追加のステップを実施する必要があります。ステップを完了すると、インスタンス HA はカスタムロールを持つコンピュートノードのサブセット上で実行されます。

重要

標準のロールまたはカスタムロールを使用する既存のオーバークラウド等、別の環境でインスタンス HA を有効にするには、デプロイメントに該当する手順のみを実施し、テンプレートを適切に変更します。

2.1. インスタンス HA ロール、フレーバー、およびプロファイルの設定

インスタンス HA をデプロイする前に、インスタンス HA ロールを roles-data.yaml ファイルに追加し、インスタンス HA フレーバーを作成し、Instanc HA で管理するコンピュートノードをインスタンス HA プロファイルでタグ付けし、インスタンス HA ロールをインスタンス HA フレーバーにマッピングします。

注記

お使いの環境に応じて、以下の手順のサンプルファイルおよびロール名を変更できます。

手順

  1. roles-data.yaml ファイルに ComputeInstanceHA ロールを追加し、ファイルを再生成します。

    $ openstack overcloud roles generate -o ~/my_roles_data.yaml Controller Compute ComputeInstanceHA

    ComputeInstanceHA ロールには、デフォルトの Compute ロールの全サービス、ComputeInstanceHA サービス、および PacemakerRemote サービスが含まれます。

  2. compute-instance-ha フレーバーを作成し、インスタンス HA で管理するコンピュートノードをタグ付けします。

    $ source ~/stackrc
    $ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 compute-instance-ha
    $ openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="compute-instance-ha" compute-instance-ha
    $ openstack flavor set --property resources:VCPU=0 --property resources:MEMORY_MB=0 --property resources:DISK_GB=0 --property resources:CUSTOM_BAREMETAL=1 compute-instance-ha
  3. インスタンス HA で管理する各コンピュートノードを compute-instance-ha プロファイルにタグ付けします。ここで、<NODE UUID> を実際の UUID に置き換えます。

    $ openstack baremetal node set --property capabilities='profile:compute-instance-ha,boot_option:local' <NODE UUID>
  4. 以下のパラメーターで環境ファイルを作成して、ComputeInstanceHA ロールを compute-instance-ha フレーバーにマッピングします。

    parameter_defaults:
      OvercloudComputeInstanceHAFlavor: compute-instance-ha

関連情報

2.2. インスタンス HA が設定されたオーバークラウドでのフェンシングの有効化

フェンシング情報を定義した環境ファイルを作成して、オーバークラウドの全コントローラーノードおよびコンピュートノードのフェンシングを有効にします。

手順

  1. ~/templates などのアクセス可能な場所に環境ファイルを作成し、以下の内容を追加します。

    parameter_defaults:
      EnableFencing: true
      FencingConfig:
        devices:
        - agent: fence_ipmilan
          host_mac: 00:ec:ad:cb:3c:c7
          params:
            login: admin
            ipaddr: 192.168.24.1
            ipport: 6230
            passwd: password
            lanplus: 1
        - agent: fence_ipmilan
          host_mac: 00:ec:ad:cb:3c:cb
          params:
            login: admin
            ipaddr: 192.168.24.1
            ipport: 6231
            passwd: password
            lanplus: 1
        - agent: fence_ipmilan
          host_mac: 00:ec:ad:cb:3c:cf
          params:
            login: admin
            ipaddr: 192.168.24.1
            ipport: 6232
            passwd: password
            lanplus: 1
        - agent: fence_ipmilan
          host_mac: 00:ec:ad:cb:3c:d3
          params:
            login: admin
            ipaddr: 192.168.24.1
            ipport: 6233
            passwd: password
            lanplus: 1
        - agent: fence_ipmilan
          host_mac: 00:ec:ad:cb:3c:d7
          params:
            login: admin
            ipaddr: 192.168.24.1
            ipport: 6234
            passwd: password
            lanplus: 1
  2. コンピュートインスタンスに共有ストレージを使用しない場合は、作成した環境ファイルに以下のパラメーターを追加します。

    parameter_defaults:
      ExtraConfig:
        tripleo::instanceha::no_shared_storage: true

2.3. インスタンス HA が設定されたオーバークラウドのデプロイ

オーバークラウドをすでにデプロイしている場合は、作成した追加のインスタンス HA ファイルで openstack overcloud deploy コマンドを再実行します。アンダーグラウンドの作成後は、いつでもオーバークラウドにインスタンス HA を設定することができます。

前提条件

  • インスタンス HA ロール、フレーバー、およびプロファイルが設定されている。
  • オーバークラウドでフェンシングが有効化されている。

手順

  • 作成したすべての環境ファイルのほか、compute-instanceha.yaml 環境ファイル用に、-e オプションを指定して openstack overcloud deploy コマンドを実行します。<FLAVOR_ENV_FILE> および <FENCING_ENV_FILE> を、実際の環境の適切なファイル名に置き換えてください。

    $ openstack overcloud deploy --templates \
      -e <FLAVOR_ENV_FILE> \
      -e <FENCING_ENV_FILE> \
      -e /usr/share/openstack-tripleo-heat-templates/environments/compute-instanceha.yaml
    注記
    • compute-instanceha.yaml 環境ファイルは変更しないでください。
    • オーバークラウドデプロイメントに追加する各環境ファイルへのフルパスを含めます。

デプロイメントが完了すると、それぞれのコンピュートノードには STONITH デバイスおよび GuestNode サービスが含まれます。

2.4. インスタンス HA による退避のテスト

インスタンス HA がインスタンスを正常に退避することをテストするには、コンピュートノードで退避をトリガーし、インスタンス HA エージェントが正常にインスタンスを退避して別のコンピュートノードに再作成することを確認します。

警告

以下の手順では、コンピュートノードを故意にクラッシュさせます。これにより、インスタンス HA によるインスタンスの自動退避がトリガーされます。

前提条件

  • インスタンス HA がコンピュートノードにデプロイされている。

手順

  1. オーバークラウドで 1 つまたは複数のインスタンスを起動します。

    stack@director $ . overcloudrc
    stack@director $ openstack server create --image cirros --flavor 2 test-failover
    stack@director $ openstack server list -c Name -c Status
  2. インスタンスをホストするコンピュートノードにログインし、root ユーザーに変更します。compute-n をコンピュートノードの名前に置き換えます。

    stack@director $ . stackrc
    stack@director $ ssh -l heat-admin compute-n
    heat-admin@compute-n $ su -
  3. コンピュートノードをクラッシュさせます。

    root@compute-n $ echo c > /proc/sysrq-trigger
  4. ノードが再起動するまで数分待ってから、クラッシュしたコンピュートノードのインスタンスが別のコンピュートノードで再作成されていることを確認します。

    stack@director $ openstack server list -c Name -c Status
    stack@director $ openstack compute service list

2.5. インスタンス HA で退避させるインスタンスの指定

デフォルトでは、インスタンス HA は障害が発生しているノードからすべてのインスタンスを退避させます。インスタンス HA を設定して、特定のイメージまたはフレーバーを持つインスタンスのみを退避させることができます。

前提条件

  • インスタンス HA がオーバークラウドにデプロイされている。

手順

  1. アンダークラウドに stack ユーザーとしてログインします。
  2. source コマンドで overcloudrc ファイルを読み込みます。

    $ source ~/overcloudrc
  3. 以下のいずれかのオプションを使用します。

    • イメージをタグ付けする。

      (overcloud) $ openstack image set --tag evacuable <image_id>

      <image_id> を退避させるイメージの ID に置き換えます。

    • フレーバーをタグ付けする。

      (overcloud) $ openstack flavor set --property evacuable=true <flavor_id>

      <flavor_id> を退避させるフレーバーの ID に置き換えてください。

2.6. 関連情報

第3章 インスタンス HA が設定されたアンダークラウドおよびオーバークラウドでのメンテナンスの実行

アンダークラウドおよびオーバークラウドでメンテナンスを実施するには、オーバークラウド起動時の問題を最小限に抑えるために、アンダークラウドおよびオーバークラウドノードを特定の順序でシャットダウンして起動する必要があります。また、ノードを停止しノード上の Pacemaker リソースを無効にして、特定のコンピュートノードまたはコントローラーノードでメンテナンスを実行することもできます。

3.1. 前提条件

  • インスタンス HA が有効な動作中のアンダークラウドおよびオーバークラウド

3.2. アンダークラウドおよびオーバークラウドのシャットダウン順序

Red Hat OpenStack Platform 環境をシャットダウンするには、オーバークラウドおよびアンダークラウドを以下の順序でシャットダウンする必要があります。

  1. オーバークラウドコンピュートノード上のインスタンスをシャットダウンする
  2. コンピュートノードをシャットダウンする
  3. コントローラーノードの高可用性サービスおよび OpenStack Platform のサービスをすべて停止する
  4. Ceph Storage ノードをシャットダウンする
  5. コントローラーノードをシャットダウンする
  6. アンダークラウドをシャットダウンする

3.2.1. オーバークラウドコンピュートノード上のインスタンスのシャットダウン

Red Hat OpenStack Platform 環境のシャットダウンのサブタスクとして、コンピュートノードをシャットダウンする前にコンピュートノード上のインスタンスをすべてシャットダウンします。

前提条件

  • Compute サービスがアクティブなオーバークラウド

手順

  1. アンダークラウドに stack ユーザーとしてログインします。
  2. source コマンドでオーバークラウドの認証情報ファイルを読み込みます。

    $ source ~/overcloudrc
  3. オーバークラウドで実行中のインスタンスを表示します。

    $ openstack server list --all-projects
  4. オーバークラウドのそれぞれのインスタンスを停止します。

    $ openstack server stop <INSTANCE>

    オーバークラウド内のすべてのインスタンスを停止するまで、それぞれのインスタンスでこのステップを繰り返します。

3.2.2. オーバークラウドコンピュートノードのインスタンス HA サービスの停止

Red Hat OpenStack Platform 環境のシャットダウンのサブタスクとして、インスタンスを停止してコンピュートノードをシャットダウンする前に、コンピュートノードのインスタンス HA サービスをすべてシャットダウンする必要があります。

前提条件

  • Compute サービスがアクティブなオーバークラウド
  • コンピュートノードでインスタンス HA が有効化されている

手順

  1. Pacemaker を実行するオーバークラウドノードに root ユーザーとしてログインします。
  2. それぞれのコンピュートノードの Pacemaker リモートリソースを無効にします。

    1. コンピュートノードの Pacemaker リモートリソースを特定します。

      # pcs resource status

      これらのリソースは ocf::pacemaker:remote エージェントを使用し、通常コンピュートノードのホストの形式に基づいて名前が付けられます (例: overcloud-novacomputeiha-0)。

    2. それぞれの Pacemaker リモートリソースを無効にします。overcloud-novacomputeiha-0 のリソースを無効にする方法を、以下の例に示します。

      # pcs resource disable overcloud-novacomputeiha-0
  3. コンピュートノードの STONITH デバイスを無効にします。

    1. コンピュートノードの STONITH デバイスを特定します。

      # pcs stonith status
    2. それぞれのコンピュートノードの STONITH デバイスを無効にします。

      # pcs stonith disable <STONITH_DEVICE>

3.2.3. コンピュートノードのシャットダウン

Red Hat OpenStack Platform 環境のシャットダウンのサブタスクとして、それぞれのコンピュートノードにログインしてシャットダウンします。

前提条件

  • コンピュートノード上のすべてのインスタンスがシャットダウンされている

手順

  1. コンピュートノードに root ユーザーとしてログインします。
  2. ノードをシャットダウンします。

    # shutdown -h now
  3. すべてのコンピュートノードをシャットダウンするまで、それぞれのコンピュートノードでこの手順を実施します。

3.2.4. コントローラーノードのサービスの停止

Red Hat OpenStack Platform 環境のシャットダウンのサブタスクとして、コントローラーノードをシャットダウンする前にノードのサービスを停止します。これには Pacemaker サービスおよび systemd サービスが含まれます。

前提条件

  • Pacemaker サービスがアクティブなオーバークラウド

手順

  1. コントローラーノードに root ユーザーとしてログインします。
  2. Pacemaker クラスターを停止します。

    # pcs cluster stop --all

    このコマンドにより、すべてのノード上のクラスターが停止します。

  3. Pacemaker サービスが停止するまで待ち、サービスが停止したことを確認します。

    1. Pacemaker のステータスを確認します。

      # pcs status
    2. Pacemaker サービスが実行されていないことを Podman で確認します。

      # podman ps --filter "name=.*-bundle.*"
  4. Red Hat OpenStack Platform のサービスを停止します。

    # systemctl stop 'tripleo_*'
  5. サービスが停止するまで待ち、サービスが実行されなくなったことを Podman で確認します。

    # podman ps

3.2.5. Ceph Storage ノードのシャットダウン

Red Hat OpenStack Platform 環境のシャットダウンのサブタスクとして、Ceph Storage サービスを無効にし、続いてそれぞれの Ceph Storage ノードにログインしてシャットダウンします。

前提条件

  • 正常な Ceph Storage クラスター
  • Ceph MON サービスがスタンドアロンの Ceph MON ノードまたはコントローラーノードで動作している

手順

  1. Ceph MON サービスを実行するノード (例: コントローラーノードまたはスタンドアロンの Ceph MON ノード) に root ユーザーとしてログインします。
  2. クラスターが正常であることを確認します。以下の例の podman コマンドにより、コントローラーノード上の Ceph MON コンテナー内でステータス確認が実施されます。

    # sudo podman exec -it ceph-mon-controller-0 ceph status

    ステータスが HEALTH_OK であることを確認します。

  3. クラスターの nooutnorecovernorebalancenobackfillnodown、および pause フラグを設定します。以下の例の podman コマンドにより、コントローラーノード上の Ceph MON コンテナーを通じてこれらのフラグが設定されます。

    # sudo podman exec -it ceph-mon-controller-0 ceph osd set noout
    # sudo podman exec -it ceph-mon-controller-0 ceph osd set norecover
    # sudo podman exec -it ceph-mon-controller-0 ceph osd set norebalance
    # sudo podman exec -it ceph-mon-controller-0 ceph osd set nobackfill
    # sudo podman exec -it ceph-mon-controller-0 ceph osd set nodown
    # sudo podman exec -it ceph-mon-controller-0 ceph osd set pause
  4. それぞれの Ceph Storage ノードをシャットダウンします。

    1. Ceph Storage ノードに root ユーザーとしてログインします。
    2. ノードをシャットダウンします。

      # shutdown -h now
    3. すべての Ceph Storage ノードをシャットダウンするまで、それぞれの Ceph Storage ノードでこの手順を実施します。
  5. スタンドアロンの Ceph MON ノードをすべてシャットダウンします。

    1. スタンドアロンの Ceph MON ノードに root ユーザーとしてログインします。
    2. ノードをシャットダウンします。

      # shutdown -h now
    3. スタンドアロンの Ceph MON ノードをすべてシャットダウンするまで、それぞれのスタンドアロンの Ceph MON ノードでこの手順を実施します。

3.2.6. コントローラーノードのシャットダウン

Red Hat OpenStack Platform 環境のシャットダウンのサブタスクとして、それぞれのコントローラーノードにログインしてシャットダウンします。

前提条件

  • Pacemaker クラスターが停止している
  • コントローラーノードのすべての Red Hat OpenStack Platform サービスが停止している

手順

  1. コントローラーノードに root ユーザーとしてログインします。
  2. ノードをシャットダウンします。

    # shutdown -h now
  3. すべてのコントローラーノードをシャットダウンするまで、それぞれのコントローラーノードでこの手順を実施します。

3.2.7. アンダークラウドのシャットダウン

Red Hat OpenStack Platform 環境のシャットダウンのサブタスクとして、アンダークラウドノードにログインしてアンダーグラウンドをシャットダウンします。

前提条件

  • 動作中のアンダークラウド

手順

  1. アンダークラウドに stack ユーザーとしてログインします。
  2. アンダークラウドをシャットダウンします。

    $ sudo shutdown -h now

3.3. システムメンテナンスの実施

アンダークラウドおよびオーバークラウドを完全にシャットダウンしたら、環境内のシステムに対するメンテナンスを実施し、続いてアンダークラウドおよびオーバークラウドを起動します。

3.4. アンダークラウドおよびオーバークラウドの起動順序

Red Hat OpenStack Platform 環境を起動するには、アンダークラウドおよびオーバークラウドを以下の順序で起動する必要があります。

  1. アンダークラウドを起動する
  2. コントローラーノードを起動する
  3. Ceph Storage ノードを起動する
  4. コントローラーノードの高可用性サービスを起動する
  5. コンピュートノードを起動する
  6. オーバークラウドコンピュートノード上のインスタンスを起動する

3.4.1. アンダークラウドの起動

Red Hat OpenStack Platform 環境の起動のサブタスクとして、アンダークラウドノードの電源をオンにし、アンダークラウドにログインし、アンダークラウドのサービスを確認します。

前提条件

  • 電源がオフのアンダークラウド

手順

  1. アンダークラウドの電源をオンにし、アンダークラウドがブートするまで待ちます。

検証

  1. アンダークラウドに stack ユーザーとしてログインします。
  2. アンダークラウドのサービスを確認します。

    $ systemctl list-units 'tripleo_*'
  3. source コマンドでアンダークラウドの認証情報ファイルを読み込み、検証コマンドを実行して、すべてのサービスおよびコンテナーがアクティブで正常であることを確認します。

    $ source stackrc
    $ openstack tripleo validator run --validation service-status --limit undercloud

3.4.2. コントローラーノードの起動

Red Hat OpenStack Platform 環境の起動のサブタスクとして、それぞれのコントローラーノードの電源をオンにし、そのノードの Pacemaker 以外のサービスを確認します。

前提条件

  • 電源がオフのコントローラーノード

手順

  1. それぞれのコントローラーノードの電源をオンにします。

検証

  1. 各コントローラーに root ユーザーとしてログインします。
  2. コントローラーノードのサービスを確認します。

    $ systemctl -t service

    Pacemaker ベース以外のサービスだけが動作中です。

3.4.3. Ceph Storage ノードの起動

Red Hat OpenStack Platform 環境の起動のサブタスクとして、Ceph MON ノードおよび Ceph Storage ノードの電源をオンにし、Ceph Storage サービスを有効にします。

前提条件

  • 電源がオフの Ceph Storage クラスター
  • 電源がオフのスタンドアロンの Ceph MON ノードまたは電源がオンのコントローラーノードで、Ceph MON サービスが有効である

手順

  1. お使いの環境にスタンドアロンの Ceph MON ノードがある場合、それぞれの Ceph MON ノードの電源をオンにします。
  2. それぞれの Ceph Storage ノードの電源をオンにします。
  3. Ceph MON サービスを実行するノード (例: コントローラーノードまたはスタンドアロンの Ceph MON ノード) に root ユーザーとしてログインします。
  4. クラスターノードのステータスを確認します。以下の例の podman コマンドにより、コントローラーノード上の Ceph MON コンテナー内でステータス確認が実施されます。

    # sudo podman exec -it ceph-mon-controller-0 ceph status

    それぞれのノードの電源がオンで、接続された状態であることを確認します。

  5. クラスターの nooutnorecovernorebalancenobackfillnodown、および pause フラグの設定を解除します。以下の例の podman コマンドにより、コントローラーノード上の Ceph MON コンテナーを通じてこれらのフラグの設定が解除されます。

    # sudo podman exec -it ceph-mon-controller-0 ceph osd unset noout
    # sudo podman exec -it ceph-mon-controller-0 ceph osd unset norecover
    # sudo podman exec -it ceph-mon-controller-0 ceph osd unset norebalance
    # sudo podman exec -it ceph-mon-controller-0 ceph osd unset nobackfill
    # sudo podman exec -it ceph-mon-controller-0 ceph osd unset nodown
    # sudo podman exec -it ceph-mon-controller-0 ceph osd unset pause

検証

  1. クラスターが正常であることを確認します。以下の例の podman コマンドにより、コントローラーノード上の Ceph MON コンテナー内でステータス確認が実施されます。

    # sudo podman exec -it ceph-mon-controller-0 ceph status

    ステータスが HEALTH_OK であることを確認します。

3.4.4. コントローラーノードの Pacemaker クラスターの起動

Red Hat OpenStack Platform 環境の起動のサブタスクとして、コントローラーノードの Pacemaker クラスターを起動します。このプロセスにより、データベース、メッセージング、負荷分散、仮想 IP アドレス割り当て等の高可用性サービスが有効化されます。

前提条件

  • コントローラーノードが動作中のオーバークラウド

手順

  1. コントローラーノードに root ユーザーとしてログインします。
  2. Pacemaker クラスターを起動します。

    # pcs cluster start --all

    このコマンドにより、すべてのノードのクラスターが起動されます。

  3. Pacemaker サービスが起動するまで待ち、サービスが起動したことを確認します。

    1. Pacemaker のステータスを確認します。

      # pcs status
    2. Pacemaker サービスが実行されていることを Podman で確認します。

      # podman ps --filter "name=.*-bundle.*"

3.4.5. コンピュートノードの起動

Red Hat OpenStack Platform 環境の起動のサブタスクとして、それぞれのコンピュートノードの電源をオンにし、そのノードのサービスを確認します。

前提条件

  • 電源がオフのコンピュートノード

手順

  1. それぞれのコンピュートノードの電源をオンにします。

検証

  1. 各コンピュートに root ユーザーとしてログインします。
  2. コンピュートノードのサービスを確認します。

    $ systemctl -t service

3.4.6. オーバークラウドコンピュートノードのインスタンス HA サービスの起動

Red Hat OpenStack Platform 環境の起動のサブタスクとして、コンピュートノードのインスタンス HA サービスをすべて起動します。

前提条件

  • コンピュートノードが動作中のオーバークラウド
  • コンピュートノードでインスタンス HA が有効化されている

手順

  1. Pacemaker を実行するオーバークラウドノードに root ユーザーとしてログインします。
  2. コンピュートノードの STONITH デバイスを有効にします。

    1. コンピュートノードの STONITH デバイスを特定します。

      # pcs stonith status
    2. コンピュートノードの STONITH エラーをすべて消去します。

      # pcs stonith confirm <COMPUTE_NODE>

      このコマンドにより、ノードがクリーンな STONITH の状態に戻ります。

    3. コンピュートノードの STONITH デバイスを有効にします。

      # pcs stonith enable <STONITH_DEVICE>
    4. STONITH を使用するそれぞれのコンピュートノードで、この手順を実施します。
  3. それぞれのコンピュートノードの Pacemaker リモートリソースを有効にします。

    1. コンピュートノードの Pacemaker リモートリソースを特定します。

      # pcs resource status

      これらのリソースは ocf::pacemaker:remote エージェントを使用し、通常コンピュートノードのホストの形式に基づいて名前が付けられます (例: overcloud-novacomputeiha-0)。

    2. それぞれの Pacemaker リモートリソースを有効にします。overcloud-novacomputeiha-0 のリソースを有効にする方法を、以下の例に示します。

      # pcs resource enable overcloud-novacomputeiha-0
    3. Pacemaker リモート管理を行うそれぞれのコンピュートノードで、この手順を実施します。

3.4.7. オーバークラウドコンピュートノード上のインスタンスの起動

Red Hat OpenStack Platform 環境の起動のサブタスクとして、コンピュートノード上のインスタンスを起動します。

前提条件

  • アクティブなノードを持つアクティブなオーバークラウド

手順

  1. アンダークラウドに stack ユーザーとしてログインします。
  2. source コマンドでオーバークラウドの認証情報ファイルを読み込みます。

    $ source ~/overcloudrc
  3. オーバークラウドで実行中のインスタンスを表示します。

    $ openstack server list --all-projects
  4. オーバークラウド内のインスタンスを起動します。

    $ openstack server start <INSTANCE>

3.5. インスタンス HA が設定されたコンピュートノードおよびコントローラーノードでのメンテナンスの実行

インスタンス HA が設定されたコンピュートノードまたはコントローラーノードでメンテナンスを実行するには、そのノードを standby モードに設定し、ノード上の Pacemaker リソースを無効にしてノードを停止します。メンテナンス作業が完了したら、ノードを起動して、Pacemaker リソースが正常であることを確認します。

前提条件

  • インスタンス HA が有効な動作中のオーバークラウド

手順

  1. コントローラーノードにログインし、コンピュートノードまたはコントローラーノードを停止します。

    # pcs node standby <node UUID>
    重要

    停止するノードとは異なるノードにログインする必要があります。

  2. ノード上の Pacemaker リソースを無効にします。

    # pcs resource disable <ocf::pacemaker:remote on the node>
  3. ノード上でメンテナンス作業を実行します。
  4. IPMI の接続を復旧し、ノードを起動します。ノードの準備ができてから手順を進めます。
  5. ノードで Pacemaker リソースを有効にし、ノードを起動します。

    # pcs resource enable <ocf::pacemaker:remote on the node>
    # pcs node unstandby <node UUID>
  6. ノードをメンテナンスモードに設定した場合は、source コマンドでオーバークラウドの認証情報ファイルを読み込んで、ノードをメンテナンスモードから復帰させます。

    # source stackrc
    # openstack baremetal node maintenance unset <baremetal node UUID>

検証

  1. Pacemaker リソースがアクティブで正常なことを確認します。

    # pcs status
  2. 起動プロセス中に Pacemaker リソースが起動できない場合は、pcs resource cleanup コマンドを実行して、リソースのステータスと異常回数をリセットします。
  3. ノードを停止する前にコンピュートノードからインスタンスを退避させた場合は、インスタンスが別のノードに移行されていることを確認します。

    # openstack server list --long
    # nova migration-list