コンピュートインスタンスの高可用性
コンピュートインスタンスの高可用性の設定
OpenStack Documentation Team
rhos-docs@redhat.com
概要
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。
Red Hat ドキュメントへのフィードバック (英語のみ)
Red Hat ドキュメントに対するご意見をお聞かせください。ドキュメントの改善点があればお知らせください。
ドキュメントへのダイレクトフィードバック (DDF) 機能の使用 (英語版のみ)
特定の文章、段落、またはコードブロックに対して直接コメントを送付するには、DDF の Add Feedback 機能を使用してください。なお、この機能は英語版のドキュメントでのみご利用いただけます。
- Multi-page HTML 形式でドキュメントを表示します。
- ドキュメントの右上隅に Feedback ボタンが表示されていることを確認してください。
- コメントするテキスト部分をハイライト表示します。
- Add Feedback をクリックします。
- Add Feedback フィールドにコメントを入力します。
- オプション: ドキュメントチームが問題の詳細を確認する際に使用できるメールアドレスを記入してください。
- Submit をクリックします。
第1章 インスタンス HA デプロイメントの導入および計画
コンピュートインスタンスの高可用性 (インスタンス HA) は、障害が発生したコンピュートノードからインスタンスを退避して、別のコンピュートノードにインスタンスを再作成するために使用できるツールです。
インスタンス HA は、共有ストレージまたはローカルストレージ環境で機能します。したがって、退避させたインスタンスは同じネットワーク設定 (静的 IP アドレス、Floating IP アドレス等) を維持します。再作成されたインスタンスも、新しいコンピュートノード内で同じ特性を維持します。
1.1. インスタンス HA の仕組み
コンピュートノードに障害が発生すると、オーバークラウドのフェンシングエージェントはノードをフェンシングします。続いてインスタンス HA エージェントは、障害が発生したコンピュートノードから別のコンピュートノードにインスタンスを退避させます。
コンピュートノードに障害が発生しインスタンス HA がトリガーされると、以下のイベントが発生します。
-
障害が発生すると、
IPMI
エージェントは最初のレイヤーのフェンシングを実行します。これには、ノードがシャットダウンされるように物理的にリセットする操作や、データの破損やオーバークラウド上に複数の同一インスタンスが存在するのを回避する操作が含まれます。ノードがオフラインである場合、フェンシング済みとみなされます。 IPMI による物理的なフェンシングの後に以下のコマンドを実行すると、
fence-nova
エージェントが第二レイヤーのフェンシングを自動的に実施し、フェンシング済みのノードを属性"evacuate=yes"
でマーキングします (この属性は、ノードごとに設定する必要があります)。$ attrd_updater -n evacuate -A name="evacuate" host="FAILEDHOST" value="yes"
FAILEDHOST
は障害が発生したコンピュートノードの名前です。-
nova-evacuate
エージェントは常にバックグラウンドで動作し、クラスターに“evacuate=yes"
属性のノードがないか定期的に確認します。この属性がフェンシング済みノードに含まれることをnova-evacuate
が検出すると、エージェントはノードからの全インスタンスの退避を開始します。退避プロセスは、いつでも実行できる手動インスタンス退避プロセスと似ています。 -
IPMI によるリセット後に障害が発生したノードが再起動すると、そのノードの
nova-compute
プロセスも自動的に開始されます。ノードはそれまでフェンシングされていたので、Pacemaker がノードのフェンシングを解除するまで、新しいインスタンスを実行しません。 -
コンピュートノードがオンライン状態にあることを Pacemaker が検出すると、ノードで
compute-unfence-trigger
リソースエージェントが起動します。これにより、ノードが解放され、インスタンスが再び実行できるようになります。
関連情報
1.2. インスタンス HA デプロイメントのプランニング
インスタンス HA をデプロイする前に、適合性のためにリソース名を確認し、環境に応じてストレージおよびネットワークを設定します。
- コンピュートノードのホスト名および Pacemaker リモートリソース名は、W3C 命名規則に従う必要があります。詳細は、W3C ドキュメントの namespace の宣言 および 名前とトークン を参照してください。
一般的に、インスタンス 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_compute
、NovaEvacuate
、および comput-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 フレーバーにマッピングします。
お使いの環境に応じて、以下の手順のサンプルファイルおよびロール名を変更できます。
手順
roles-data.yaml
ファイルにComputeInstanceHA
ロールを追加し、ファイルを再生成します。$ openstack overcloud roles generate -o ~/my_roles_data.yaml Controller Compute ComputeInstanceHA
ComputeInstanceHA
ロールには、デフォルトのCompute
ロールの全サービス、ComputeInstanceHA
サービス、およびPacemakerRemote
サービスが含まれます。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
インスタンス HA で管理する各コンピュートノードを
compute-instance-ha
プロファイルにタグ付けします。ここで、<NODE UUID>
を実際の UUID に置き換えます。$ openstack baremetal node set --property capabilities='profile:compute-instance-ha,boot_option:local' <NODE UUID>
以下のパラメーターで環境ファイルを作成して、
ComputeInstanceHA
ロールをcompute-instance-ha
フレーバーにマッピングします。parameter_defaults: OvercloudComputeInstanceHAFlavor: compute-instance-ha
関連情報
2.2. インスタンス HA が設定されたオーバークラウドでのフェンシングの有効化
フェンシング情報を定義した環境ファイルを作成して、オーバークラウドの全コントローラーノードおよびコンピュートノードのフェンシングを有効にします。
手順
~/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
コンピュートインスタンスに共有ストレージを使用しない場合は、作成した環境ファイルに以下のパラメーターを追加します。
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> \ -r my_roles_data.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/compute-instanceha.yaml
注記-
compute-instanceha.yaml
環境ファイルは変更しないでください。 - オーバークラウドデプロイメントに追加する各環境ファイルへのフルパスを含めます。
-
デプロイメントが完了すると、それぞれのコンピュートノードには STONITH
デバイスおよび GuestNode
サービスが含まれます。
2.4. インスタンス HA による退避のテスト
インスタンス HA がインスタンスを正常に退避することをテストするには、コンピュートノードで退避をトリガーし、インスタンス HA エージェントが正常にインスタンスを退避して別のコンピュートノードに再作成することを確認します。
以下の手順では、コンピュートノードを故意にクラッシュさせます。これにより、インスタンス HA によるインスタンスの自動退避がトリガーされます。
前提条件
- インスタンス HA がコンピュートノードにデプロイされている。
手順
オーバークラウドで 1 つ以上のインスタンスを起動します。
stack@director $ . overcloudrc stack@director $ openstack server create --image cirros --flavor 2 test-failover stack@director $ openstack server list -c Name -c Status
インスタンスをホストするコンピュートノードにログインし、
root
ユーザーに変更します。compute-n
をコンピュートノードの名前に置き換えます。stack@director $ . stackrc stack@director $ ssh -l heat-admin compute-n heat-admin@compute-n $ su -
コンピュートノードをクラッシュさせます。
root@compute-n $ echo c > /proc/sysrq-trigger
ノードが再起動するまで数分待ってから、クラッシュしたコンピュートノードのインスタンスが別のコンピュートノードで再作成されていることを確認します。
stack@director $ openstack server list -c Name -c Status stack@director $ openstack compute service list
2.5. インスタンス HA で退避させるインスタンスの指定
デフォルトでは、インスタンス HA は障害が発生しているノードからすべてのインスタンスを退避させます。インスタンス HA を設定して、特定のイメージまたはフレーバーを持つインスタンスのみを退避させることができます。
前提条件
- インスタンス HA がオーバークラウドにデプロイされている。
手順
-
アンダークラウドに
stack
ユーザーとしてログインします。 source コマンドで
overcloudrc
ファイルを読み込みます。$ source ~/overcloudrc
以下のオプションのいずれかを使用します。
イメージをタグ付けする。
(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 環境をシャットダウンするには、オーバークラウドおよびアンダークラウドを以下の順序でシャットダウンする必要があります。
- オーバークラウドコンピュートノード上のインスタンスをシャットダウンします。
- コンピュートノードをシャットダウンします。
- コントローラーノードの高可用性サービスおよび OpenStack Platform のサービスをすべて停止します。
- Ceph Storage ノードをシャットダウンします。
- コントローラーノードをシャットダウンします。
- アンダークラウドをシャットダウンします。
3.2.1. オーバークラウドコンピュートノード上のインスタンスのシャットダウン
Red Hat OpenStack Platform 環境のシャットダウンのサブタスクとして、コンピュートノードをシャットダウンする前にコンピュートノード上のインスタンスをすべてシャットダウンします。
前提条件
- Compute サービスがアクティブなオーバークラウド
手順
-
アンダークラウドに
stack
ユーザーとしてログインします。 source コマンドでオーバークラウドの認証情報ファイルを読み込みます。
$ source ~/overcloudrc
オーバークラウドで実行中のインスタンスを表示します。
$ openstack server list --all-projects
オーバークラウドのそれぞれのインスタンスを停止します。
$ openstack server stop <INSTANCE>
オーバークラウド内のすべてのインスタンスを停止するまで、それぞれのインスタンスでこのステップを繰り返します。
3.2.2. オーバークラウドコンピュートノードのインスタンス HA サービスの停止
Red Hat OpenStack Platform 環境のシャットダウンのサブタスクとして、インスタンスを停止してコンピュートノードをシャットダウンする前に、コンピュートノードのインスタンス HA サービスをすべてシャットダウンする必要があります。
前提条件
- Compute サービスがアクティブなオーバークラウド
- コンピュートノードで有効化されているインスタンス HA
手順
-
Pacemaker を実行するオーバークラウドノードに
root
ユーザーとしてログインします。 それぞれのコンピュートノードの Pacemaker リモートリソースを無効にします。
コンピュートノードの Pacemaker リモートリソースを特定します。
# pcs resource status
これらのリソースは
ocf::pacemaker:remote
エージェントを使用し、通常はコンピュートノードのホストの形式に基づく名前が付けられます (例:overcloud-novacomputeiha-0
)。それぞれの Pacemaker リモートリソースを無効にします。
overcloud-novacomputeiha-0
のリソースを無効にする方法を、以下の例に示します。# pcs resource disable overcloud-novacomputeiha-0
コンピュートノードの STONITH デバイスを無効にします。
コンピュートノードの STONITH デバイスを特定します。
# pcs stonith status
それぞれのコンピュートノードの STONITH デバイスを無効にします。
# pcs stonith disable <STONITH_DEVICE>
3.2.3. コンピュートノードのシャットダウン
Red Hat OpenStack Platform 環境をシャットダウンする際のサブタスクとして、それぞれのコンピュートノードにログインしてシャットダウンします。
前提条件
- コンピュートノード上のすべてのインスタンスがシャットダウンされている。
手順
-
コンピュートノードに
root
ユーザーとしてログインします。 ノードをシャットダウンします。
# shutdown -h now
- すべてのコンピュートノードをシャットダウンするまで、それぞれのコンピュートノードでこの手順を実施します。
3.2.4. コントローラーノードのサービスの停止
Red Hat OpenStack Platform 環境のシャットダウンする際のサブタスクとして、コントローラーノードをシャットダウンする前にノードのサービスを停止します。これには Pacemaker サービスおよび systemd サービスが含まれます。
前提条件
- Pacemaker サービスがアクティブなオーバークラウド
手順
-
コントローラーノードに
root
ユーザーとしてログインします。 Pacemaker クラスターを停止します。
# pcs cluster stop --all
このコマンドにより、すべてのノード上のクラスターが停止します。
Pacemaker サービスが停止するまで待ち、サービスが停止したことを確認します。
Pacemaker のステータスを確認します。
# pcs status
Pacemaker サービスが実行されていないことを Podman で確認します。
# podman ps --filter "name=.*-bundle.*"
Red Hat OpenStack Platform のサービスを停止します。
# systemctl stop 'tripleo_*'
サービスが停止するまで待ち、サービスが実行されなくなったことを Podman で確認します。
# podman ps
3.2.5. Ceph Storage ノードのシャットダウン
Red Hat OpenStack Platform 環境のシャットダウンのサブタスクとして、Ceph Storage サービスを無効にし、続いてそれぞれの Ceph Storage ノードにログインしてシャットダウンします。
前提条件
- 正常な Ceph Storage クラスター。
- Ceph MON サービスがスタンドアロンの Ceph MON ノードまたはコントローラーノードで動作している。
手順
-
Ceph MON サービスを実行するノード (例: コントローラーノードまたはスタンドアロンの Ceph MON ノード) に
root
ユーザーとしてログインします。 クラスターが正常であることを確認します。以下の例の
podman
コマンドにより、コントローラーノード上の Ceph MON コンテナー内でステータス確認が実施されます。# sudo podman exec -it ceph-mon-controller-0 ceph status
ステータスが
HEALTH_OK
であることを確認します。クラスターの
noout
、norecover
、norebalance
、nobackfill
、nodown
、および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
それぞれの Ceph Storage ノードをシャットダウンします。
-
Ceph Storage ノードに
root
ユーザーとしてログインします。 ノードをシャットダウンします。
# shutdown -h now
- すべての Ceph Storage ノードをシャットダウンするまで、それぞれの Ceph Storage ノードでこの手順を実施します。
-
Ceph Storage ノードに
スタンドアロンの Ceph MON ノードをすべてシャットダウンします。
-
スタンドアロンの Ceph MON ノードに
root
ユーザーとしてログインします。 ノードをシャットダウンします。
# shutdown -h now
- スタンドアロンの Ceph MON ノードをすべてシャットダウンするまで、それぞれのスタンドアロンの Ceph MON ノードでこの手順を実施します。
-
スタンドアロンの Ceph MON ノードに
3.2.6. コントローラーノードのシャットダウン
Red Hat OpenStack Platform 環境のシャットダウンのサブタスクとして、それぞれのコントローラーノードにログインしてシャットダウンします。
前提条件
- Pacemaker クラスターが停止している。
- コントローラーノードのすべての Red Hat OpenStack Platform サービスが停止している。
手順
-
コントローラーノードに
root
ユーザーとしてログインします。 ノードをシャットダウンします。
# shutdown -h now
- すべてのコントローラーノードをシャットダウンするまで、それぞれのコントローラーノードでこの手順を実施します。
3.2.7. アンダークラウドのシャットダウン
Red Hat OpenStack Platform 環境のシャットダウンのサブタスクとして、アンダークラウドノードにログインしてアンダーグラウンドをシャットダウンします。
前提条件
- 動作中のアンダークラウド
手順
-
アンダークラウドに
stack
ユーザーとしてログインします。 アンダークラウドをシャットダウンします。
$ sudo shutdown -h now
3.3. システムメンテナンスの実施
アンダークラウドおよびオーバークラウドを完全にシャットダウンしたら、環境内のシステムに対するメンテナンスを実施し、続いてアンダークラウドおよびオーバークラウドを起動します。
3.4. アンダークラウドおよびオーバークラウドの起動順序
Red Hat OpenStack Platform 環境を起動するには、アンダークラウドおよびオーバークラウドを以下の順序で起動する必要があります。
- アンダークラウドを起動する
- コントローラーノードを起動する
- Ceph Storage ノードを起動する
- コンピュートノードを起動する
- オーバークラウドコンピュートノード上のインスタンスを起動する
3.4.1. アンダークラウドの起動
Red Hat OpenStack Platform 環境の起動のサブタスクとして、アンダークラウドノードの電源をオンにし、アンダークラウドにログインし、アンダークラウドのサービスを確認します。
前提条件
- 電源がオフのアンダークラウド
手順
- アンダークラウドの電源をオンにし、アンダークラウドがブートするまで待ちます。
検証
-
アンダークラウドに
stack
ユーザーとしてログインします。 アンダークラウドのサービスを確認します。
$ systemctl list-units 'tripleo_*'
source コマンドでアンダークラウドの認証情報ファイルを読み込み、検証コマンドを実行して、すべてのサービスおよびコンテナーがアクティブで正常であることを確認します。
$ source stackrc $ openstack tripleo validator run --validation service-status --limit undercloud
関連情報
3.4.2. コントローラーノードの起動
Red Hat OpenStack Platform 環境の起動のサブタスクとして、それぞれのコントローラーノードの電源をオンにし、そのノードの Pacemaker 以外のサービスを確認します。
前提条件
- 電源がオフのコントローラーノード
手順
- それぞれのコントローラーノードの電源をオンにします。
検証
-
root
ユーザーとして各コントローラーノードにログインします。 コントローラーノードのサービスを確認します。
$ systemctl -t service
Pacemaker ベース以外のサービスだけが動作中です。
Pacemaker サービスが起動するまで待ち、サービスが起動したことを確認します。
$ pcs status
注記環境でインスタンス HA を使用している場合、Pacemaker リソースは、コンピュートノードを起動するか、
pcs stonith confirm <compute_node>
コマンドを使用して手動でフェンスを解除する操作を実行するまで起動しません。このコマンドは、インスタンス HA を使用する各コンピュートノードで実行する必要があります。
3.4.3. Ceph Storage ノードの起動
Red Hat OpenStack Platform 環境の起動のサブタスクとして、Ceph MON ノードおよび Ceph Storage ノードの電源をオンにし、Ceph Storage サービスを有効にします。
前提条件
- 電源がオフの Ceph Storage クラスター。
- 電源がオフのスタンドアロンの Ceph MON ノードまたは電源がオンのコントローラーノードで、Ceph MON サービスが有効になっている。
手順
- 使用している環境にスタンドアロンの Ceph MON ノードがある場合、それぞれの Ceph MON ノードの電源をオンにします。
- それぞれの Ceph Storage ノードの電源をオンにします。
-
Ceph MON サービスを実行するノード (例: コントローラーノードまたはスタンドアロンの Ceph MON ノード) に
root
ユーザーとしてログインします。 クラスターノードのステータスを確認します。以下の例の
podman
コマンドにより、コントローラーノード上の Ceph MON コンテナー内でステータス確認が実施されます。# sudo podman exec -it ceph-mon-controller-0 ceph status
それぞれのノードの電源がオンで、接続された状態であることを確認します。
クラスターの
noout
、norecover
、norebalance
、nobackfill
、nodown
、および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
検証
クラスターが正常であることを確認します。以下の例の
podman
コマンドにより、コントローラーノード上の Ceph MON コンテナー内でステータス確認が実施されます。# sudo podman exec -it ceph-mon-controller-0 ceph status
ステータスが
HEALTH_OK
であることを確認します。
3.4.4. コンピュートノードの起動
Red Hat OpenStack Platform 環境の起動のサブタスクとして、それぞれのコンピュートノードの電源をオンにし、そのノードのサービスを確認します。
前提条件
- 電源がオフのコンピュートノード
手順
- それぞれのコンピュートノードの電源をオンにします。
検証
-
各コンピュートに
root
ユーザーとしてログインします。 コンピュートノードのサービスを確認します。
$ systemctl -t service
3.4.5. オーバークラウドコンピュートノードのインスタンス HA サービスの起動
Red Hat OpenStack Platform 環境の起動のサブタスクとして、コンピュートノードのインスタンス HA サービスをすべて起動します。
前提条件
- コンピュートノードが動作中のオーバークラウド
- コンピュートノードで有効化されているインスタンス HA
手順
-
Pacemaker を実行するオーバークラウドノードに
root
ユーザーとしてログインします。 コンピュートノードの STONITH デバイスを有効にします。
コンピュートノードの STONITH デバイスを特定します。
# pcs stonith status
コンピュートノードの STONITH エラーをすべて消去します。
# pcs stonith confirm <COMPUTE_NODE>
このコマンドにより、ノードがクリーンな STONITH の状態に戻ります。
コンピュートノードの STONITH デバイスを有効にします。
# pcs stonith enable <STONITH_DEVICE>
- STONITH を使用するそれぞれのコンピュートノードで、この手順を実施します。
それぞれのコンピュートノードの Pacemaker リモートリソースを有効にします。
コンピュートノードの Pacemaker リモートリソースを特定します。
# pcs resource status
これらのリソースは
ocf::pacemaker:remote
エージェントを使用し、通常はコンピュートノードのホストの形式に基づく名前が付けられます (例:overcloud-novacomputeiha-0
)。それぞれの Pacemaker リモートリソースを有効にします。
overcloud-novacomputeiha-0
のリソースを有効にする方法を、以下の例に示します。# pcs resource enable overcloud-novacomputeiha-0
- Pacemaker リモート管理を行うそれぞれのコンピュートノードで、この手順を実施します。
Pacemaker サービスが起動するまで待ち、サービスが起動したことを確認します。
# pcs status
起動プロセス中に Pacemaker リソースの起動に失敗した場合は、リソースのステータスと失敗回数をリセットします。
# pcs resource cleanup
注記fence_compute
やfence_kdump
など、一部のサービスは開始に時間がかかる場合があります。
3.4.6. オーバークラウドコンピュートノード上のインスタンスの起動
Red Hat OpenStack Platform 環境の起動のサブタスクとして、コンピュートノード上のインスタンスを起動します。
前提条件
- アクティブなノードを持つアクティブなオーバークラウド
手順
-
アンダークラウドに
stack
ユーザーとしてログインします。 source コマンドでオーバークラウドの認証情報ファイルを読み込みます。
$ source ~/overcloudrc
オーバークラウドで実行中のインスタンスを表示します。
$ openstack server list --all-projects
オーバークラウド内のインスタンスを起動します。
$ openstack server start <INSTANCE>
第4章 インスタンス HA が設定されたコンピュートノードおよびコントローラーノードでのメンテナンスの実行
インスタンス HA が設定されたコンピュートノードまたはコントローラーノードでメンテナンスを実行するには、そのノードを standby
モードに設定し、ノード上の Pacemaker リソースを無効にしてノードを停止します。メンテナンス作業が完了したら、ノードを起動して、Pacemaker リソースが正常であることを確認します。
前提条件
- インスタンス HA が有効な動作中のオーバークラウド
手順
コントローラーノードにログインし、コンピュートノードまたはコントローラーノードを停止します。
# pcs node standby <node UUID>
重要停止するノードとは異なるノードにログインする必要があります。
ノード上の Pacemaker リソースを無効にします。
# pcs resource disable <ocf::pacemaker:remote on the node>
- ノード上でメンテナンス作業を実行します。
- IPMI の接続を復旧し、ノードを起動します。ノードの準備ができてから手順を進めます。
ノードで Pacemaker リソースを有効にし、ノードを起動します。
# pcs resource enable <ocf::pacemaker:remote on the node> # pcs node unstandby <node UUID>
ノードをメンテナンスモードに設定した場合は、source コマンドでオーバークラウドの認証情報ファイルを読み込んで、ノードをメンテナンスモードから復帰させます。
# source stackrc # openstack baremetal node maintenance unset <baremetal node UUID>
検証
Pacemaker リソースがアクティブで正常なことを確認します。
# pcs status
-
起動プロセス中に Pacemaker リソースが起動できない場合は、
pcs resource cleanup
コマンドを実行して、リソースのステータスと異常回数をリセットします。 ノードを停止する前にコンピュートノードからインスタンスを退避させた場合は、インスタンスが別のノードに移行されていることを確認します。
# openstack server list --long # nova migration-list