コンピュートインスタンスの高可用性
コンピュートインスタンスの高可用性の設定
概要
第1章 概要
本ガイドでは、インスタンスの高可用性 (インスタンス HA) を管理する方法について説明します。インスタンス HA が設定された Red Hat OpenStack Platform では、ホストコンピュートノードに障害が発生した場合に、インスタンスを自動的に退避させ別のコンピュートノードに作成し直すことができます。
インスタンス HA がトリガーとなる退避プロセスは、ユーザーが手動で実施できる操作(詳細は『インスタンス &イメージガイド』の「インスタンスの退避 」を参照)と類似しています。
インスタンス HAは、共有ストレージまたはローカルストレージ環境で機能します。したがって、インスタンスを新たに作成した場合でも、退避したインスタンスは新しいホスト内で同じネットワーク設定 (静的 IP、Floating IP 等) および同じ特性を維持します。
インスタンス HA は以下のリソースエージェントにより管理されます。
エージェント名 | クラスター内での名前 | ロール |
---|---|---|
|
| コンピュートノードが使用不能になった場合に、退避のためにそのノードをマーキングする。 |
|
| 障害が発生したノードからインスタンスを退避させる。このエージェントは、コントローラーノードのいずれかで動作します。 |
|
| フェンシングされたノードを解放し、再びインスタンスを実行できるようにする。 |
第2章 インスタンス HA の仕組み
OpenStack では、インスタンス 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
リソースの起動を試み、force-down API の呼び出しを取り消してノードを再び有効な状態に設定します。
2.1. 退避させる特定インスタンスの指定
デフォルトでは、すべてのインスタンスを退避させますが、退避用のイメージまたはフレーバーをタグ付けすることもできます。
イメージをタグ付けするには、以下のコマンドを実行します。
$ openstack image set --tag evacuable ID-OF-THE-IMAGE
フレーバーをタグ付けするには、以下のコマンドを実行します。
$ nova flavor-key ID-OF-THE-FLAVOR set evacuable=true
第3章 インスタンス HA のインストールと設定
インスタンス HA は director でデプロイおよび設定されます。ただし、デプロイメントの準備のために、いくつかの追加ステップを実施する必要があります。
本項では、カスタムロールを使用してコンピュートノードのサブセットでインスタンス HA を有効化することを目的に、新しいオーバークラウドで新しいインスタンス HA デプロイメントを設定するために必要なすべての手順について説明します。
- コンピュートノードのホスト名および Pacemaker リモートリソース名は、W3C 命名規則に従う必要があります。詳細は、W3C ドキュメントの Declaring Namespaces および Names and Tokens を参照してください。
-
インスタンス HA をスパイン/リーフ環境でデプロイする場合には、コントローラーノードおよびコンピュートノードに単一の
internal_api
ネットワークを定義する必要があります。その後、各リーフのサブネットを定義できます。スパイン/リーフ型ネットワーク の設定についての詳しい情報は、『スパイン/リーフ 型ネットワーク』の「ロールデータファイル の作成」を参照し てください。 - 標準のロールまたはカスタムロールを使用する既存のオーバークラウド等、別の環境でインスタンス HA を有効化する場合には、デプロイメントに関連する手順のみに従い、テンプレートを適切に変更します。
- インストール後の director でのインスタンス HA の無効化はサポートされていません。デプロイメントからインスタンス HA コンポーネントを手動で削除する回避策は、 「How can I remove Instance HA components from the controller nodes?」の記事を参照してください。.この回避策は、そのまま提供されます。実稼働環境で実装する前に、テスト環境で手順を検証する必要があります。
オーバークラウドのデプロイに関する一般的な情報は、『 director のインストールと使用方法』 を参照してください。カスタムロールの詳細は、『オーバークラウドの高度なカスタマイズ』の「 コンポーザブルサービスとカスタムロール」を参照 してください。
インスタンス HA ロール、フレーバー、およびプロファイルの設定
ロールデータファイルに
ComputeInstanceHA
ロールを追加し、ファイルを再生成します。以下に例を示します。$ openstack overcloud roles generate -o ~/my_roles_data.yaml Controller Compute ComputeInstanceHA
ComputeInstanceHA
ロールには、デフォルトのCompute
ロールの全サービスに加えて、ComputeInstanceHA
およびPacemakerRemote
サービスが含まれます。カスタムロールおよび roles-data.yaml に関する一般的な情報は、『オーバークラウドの 高度なカスタマイズ』 の「ロール」セクションを参照してください。https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/16.0/html-single/advanced_overcloud_customization/#rolesインスタンス HA に指定するコンピュートノードにタグ付けする
compute-instance-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
インスタンス HA に指定する各コンピュートノードに
compute-instance-ha
プロファイルをタグ付けします。$ 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
フェンシングの有効化
フェンシング情報を定義した環境ファイルを作成して、オーバークラウドの全コントローラーノードおよびコンピュートノードのフェンシングを有効にします。必ずアクセス可能な場所に環境ファイルを作成してください (~/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
フェンシングおよび STONITH の設定に関する詳細は、『 High Availability Deployment and Usage 』の「 Fencing Controller Nodes with STONITH 」セクションを参照してください。
デフォルトでは、インスタンス HA は共有ストレージを使用します。共有ストレージがコンピュートインスタンス用に設定されていない場合には、前の手順で作成した環境ファイルに以下のパラメーターを追加します。
parameter_defaults: ExtraConfig: tripleo::instanceha::no_shared_storage: true
インスタンスのディスクイメージ用に共有ストレージを設定するのではなく、OpenStack Block Storage(cinder)ボリュームから起動する方法は、??? を参照してください。
オーバークラウドのデプロイ
作成したすべての環境ファイルのほか、compute-instanceha.yaml 環境ファイル用に、-e
オプションを指定して openstack overcloud deploy
コマンドを実行します。以下に例を示します。
$ 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 環境ファイルは変更しないでください。
- オーバークラウドデプロイメントに追加する各環境ファイルへのパスを含めるようにしてください。
-
アンダーグラウンドの作成後は、いつでもオーバークラウドにインスタンス HA を設定することができます。オーバークラウドをすでにデプロイしている場合は、新しいインスタンス HA ファイルで
overcloud deploy
コマンドを再実行する必要があります。
デプロイメントが完了すると、それぞれのコンピュートノードには STONITH
デバイスおよび GuestNode
サービスが含まれます。
3.1. 共有ストレージに関する注意事項
一般的に、インスタンス HA ではインスタンスのディスクイメージ用に共有ストレージを設定する必要があります。したがって、no-shared-storage
オプションの使用を試みると、退避中に InvalidSharedStorage
エラーが表示され、インスタンスが別のコンピュートノードで起動しなくなります。
ただし、すべてのインスタンスが OpenStack Block Storage (cinder
) ボリュームから起動するように設定されている場合には、インスタンスのディスクイメージ用に共有ストレージを設定する必要はないので、no-shared-storage
オプションを使用してすべてのインスタンスを退避させることができます。
インスタンスが Block Storage ボリュームから起動するように設定されている場合には、退避したインスタンスは別のコンピュートノード上の同じボリュームから起動するはずです。したがって、OS イメージおよびアプリケーションデータが OpenStack Block Storage ボリュームに保管されているので、退避したインスタンスは直ちにジョブを再開します。
第4章 インスタンス HA による退避のテスト
以下の手順では、コンピュートノードを故意にクラッシュさせます。これにより、意図的にインスタンス HA によるインスタンスの自動退避を実行させます。
テスト用インスタンスをホストするコンピュートノードをクラッシュさせる前に、オーバークラウド上でインスタンスを 1 つ以上起動します。
stack@director $ . overcloudrc stack@director $ nova boot --image cirros --flavor 2 test-failover stack@director $ nova list --fields name,status,host
compute-n
フォーマットを使用して、インスタンスをホストするコンピュートノードにログインします。stack@director $ . stackrc stack@director $ ssh -l heat-admin compute-n heat-admin@compute-n $
コンピュートノードをクラッシュさせます。
heat-admin@compute-n $ echo c > /proc/sysrq-trigger
数分待ってから、これらのインスタンスが別のコンピュートノード上で作成し直されていることを確認します。
stack@director $ nova list --fields name,status,host stack@director $ nova service-list