エスカレーションについて

topologyがある場合には、１つのレベルのフェンシングが失敗すると次のレベルへ。１つのレベルのみの場合は、一旦失敗しリトライのフェンシングが実行される。
topologyが無い場合は、他のフェンシング可能なノードが有れば、そのノードからのフェンシング（エスカレーション)へ。他にフェンシング可能なノードが無い場合には、一旦失敗しリトライのフェンシングが実行される。

stonith-max-attemptsの回数を制御しているのは、フェンシングを依頼するcontrold側。
pcmk_xxxx_retriesをstonith-timetou内で回数管理して制御しているのはfenced側。

topologyが無い場合、disable-timeoutが有効(デフォルトは有効)になっている場合は、ETIMEに落ちてしまう為、エスカレーションしない。
※フェンスエージェントによっては、まだ、disable-timeoutが有効でも、ETIMEに落ちないものもあるかも。。。

priority-fencing-delayについて

設定値の待ち時間は、フェンシングのタイムアウトの伸長には含まれていない。
base_delay/base_delay_maxは含まれている
topologyがある場合でも、無い場合でも、priority-fencing-delayの待ちが有効になるのは最初のフェンシング動作のみ(LEVEL1)で、以降のエスカレーションのフェンシングには有効にならない。
2ノードのみで有効で、3ノード以上は、no-quorum-policyの制御に従う。

pcmk_host_checkパラメータ指定について

dynamic-list,static-list,statusが指定可能で、フェンシング時の指定ノードを決定する方法を指定する。
指定されていない場合は、他のパラメータやフェンスエージェントのサポートするアクションによって、以下の判断で自動的に設定される。

pcmk_host_listパラメータが指定されている場合は、"static-list"として処理される
pcmk_host_mapパラメータが指定されている場合も、"static-list"として処理される
上記が指定されておらず、フェンスエージェントがlistアクションをサポートしている場合は、"dynamic-list"として処理される。
上記が指定されておらず、フェンスエージェントがstatusアクションをサポートしている場合は、"status"として処理される。
上記全てに当てはまらない場合は、指定無し(PCMK__VALUE_NONE)として処理される。

pcmk_host_list/pcmk_host_map指定について

pcmk_host_listは固定で、フェンシング対象とマッチングして、マッチングすればフェンシング可能なデバイスとして判断される。
pcmk_host_mapは、KVM/vSphereなどのVM上用のマッチングで、KVM/vSphere上のホスト名とフェンシング対象をマッチングさせる。マッチング時にlistコマンドも実行させて、マッチングさせる為に、pcmk_host_checkにdymanic-listも指定して、KVM/vSphere上の情報も含めてマッチングさせる方が良い。
pcmk_host_listは、pcmk_host_checkに指定なしか、static-listを指定した場合にしか有効にならない。

DCノード故障からのフェンシングの移譲について

topologyがある場合で、DCをフェンシングする他ノードが存在する場合には、他ノードへフェンシングを移譲する。
この時、DCノードの故障からのフェンシングは移譲されたノードを起点として開始される
toplogyが無い場合は、常にDCノードが起点となって開始される。
DCノード故障ではない場合は、topologyの有無に関わらず、全てDCノードが起点となって開始される。
他ノードが複数存在する場合には、クラスタに参加した（クラスタがメンバーとして認識した）順が早いノードから選択される。
※topologyが無い場合のDCをフェンシングする場合も、今後のリリースでは、他ノードへフェンシングを移譲する動作に変更となる予定です。よって、topologyの有無に関わらず、DCをフェンシングする場合は、全て移譲となります。

fece-agentsへのパラメータの引き渡し

fencedからfork後に標準入力より引き渡している
resource-agentとは異なる。

fence_scsi/fence_mpath

unfencing(on)動作が可能なのは、対象ノードのみ。
unfencing動作は、probeよりも先に実行される。
他のSTONITHデバイスは、通常はreboot/offなどの動作は、対象ノード以外で実行できる所が異なる。
unfencing動作であっても、topologyが有る場合には、topologyに従って制御される

Query処理

フェンシング実行前にクラスタを構成するノードのフェンシング可能なデバイス情報を取得する為に、フェンシングの基点となるノード(通常、DCノード、移譲される場合は、移譲先のノード)かQueryメッセージにより、他ノードへの探索依頼(Query)が送信される。
自ノードも含めて、Queryを受信したノードは、対象ノードがフェンシング可能なデバイスが自ノードに登録されているどうか確認し、フェンシング可能なデバイスを全てQueryの要求元に返す。
起点となるノードは、この情報を元にして、どのノードにフェンシングを依頼するか決定する。
複数からフェンシング可能な同じデバイスなどが選出される場合には、優先的に、より多くのデバイスを登録しているノードにフェンシングを依頼する。
全く同じデバイス数を登録している場合には、Query応答が早いノードから優先的にフェンシングを依頼する。
デバイスの選出は、VERIFY(monitor/list/status)が優先、その次に登録済(配置可能)のデバイスとなる。

topology

Level(index)で複数の段階的なフェンシングを設定可能。
devicesにカンマ区切りで複数のデバイスを指定すると、１レベルでand実行(必ず実行)する。

    <fencing-topology>
      <fencing-level devices="fence-xxxx1" index="1" target="rh85-01" id="fl-rh85-01-1"/>
      <fencing-level devices="fence-xxxx5" index="2" target="rh85-01" id="fl-rh85-01-2"/>
      <fencing-level devices="fence-xxxx2" index="1" target="rh85-02" id="fl-rh85-02-1"/>
      <fencing-level devices="fence-xxxx3,fence-xxxx4" index="1" target="rh85-03" id="fl-rh85-03-1"/>
    </fencing-topology>