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 リソースの起動を試み、force-down API の呼び出しを取り消してノードを再び有効な状態に設定します。

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

1. ComputeInstanceHA ロールをロールデータのファイルに追加し、ファイルを再生成します。以下に例を示します。

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

   ComputeInstanceHA ロールには、デフォルトの Compute ロールの全サービスに加えて、ComputeInstanceHA および PacemakerRemote サービスが含まれます。カスタムロールおよび roles-data.yaml に関する一般的な情報は、『オーバークラウドの高度なカスタマイズ』の「ロール」セクションを参照してください。

2. インスタンス 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

3. インスタンス HA に指定する各コンピュートノードに compute-instance-ha プロファイルをタグ付けします。

   $ 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

フェンシングの有効化

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

   フェンシングおよび STONITH の設定に関する詳細は、『高可用性デプロイメントと使用方法』の「STONITH を使用したコントローラノードのフェンシング」を参照してください。

2. デフォルトでは、インスタンス HA は共有ストレージを使用します。共有ストレージがコンピュートインスタンス用に設定されていない場合には、前の手順で作成した環境ファイルに以下のパラメーターを追加します。

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

   インスタンスのディスクイメージ用に共有ストレージを設定するのではなく、OpenStack Block Storage (cinder) ボリュームから起動する方法は、「共有ストレージに関する注意事項」を参照してください。

1. テスト用インスタンスをホストするコンピュートノードをクラッシュさせる前に、オーバークラウド上でインスタンスを 1 つ以上起動します。

   stack@director $ . overcloudrc
   stack@director $ nova boot --image cirros --flavor 2 test-failover
   stack@director $ nova list --fields name,status,host

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 $ nova list --fields name,status,host
   stack@director $ nova service-list