RHEL でアクティブなノードがストレージ方式でフェンスされた後、クラスタ化された IP リソースが回復に失敗する

Issue

• 弊社クラスタサービスが稼働しているノードがストレージへのアクセス不能に伴い退避・フェンスされ、ストレージフェンス方式（fence_brocade, fence_scsi, etc ）で構成されている場合、サービス内のIPリソースがIP衝突により他のノードで回復できないことがあります。

Aug 27 11:40:49 node1 clurgmgrd: [5052]: <info> Adding IPv4 address 192.168.143.8/24 to bond2
Aug 27 11:40:49 node1 clurgmgrd: [5052]: <debug> Pinging addr 192.168.143.8 from dev bond2
Aug 27 11:40:49 node1 clurgmgrd: [5052]: <err> IPv4 アドレス衝突 192.168.143.8
Aug 27 11:40:49 node1 clurgmgrd[5052]: <notice> start on ip "192.168.143.8" returned 1 (一般的なエラー)
Aug 27 11:40:49 node1 clurgmgrd[5052]: <warning> #68:service:test の起動に失敗しました。

Nov 11 18:19:27 node1 rgmanager[8429]: [ip] IPv4アドレス 192.168.2.88/24 を bond0 に追加
Nov 11 18:19:27 node1 rgmanager[8475]: [ip] IPv4アドレス衝突 192.168.2.88
Nov 11 18:19:27 node1 rgmanager[6412]: start on ip "192.168.2.88" returned 1 (generic error)
11月11日 18:19:27 node1 rgmanager[6412]:#68:service:myserviceの起動に失敗しました; 返り値: 1

• クラスタリソースの操作（開始、停止、ステータス）は、リソースエージェントで何らかの操作（I/Oやネットワーク操作など）の完了を待ってブロックされる場合があります。 この間にノードが立ち退き、クラスタから削除された場合、そのスタック操作が完了するまでそのサービスの緊急停止は行いませんが、フェンシングが成功するとすぐにクラスタの他のノードがそのサービスを回復しようとします。 そのサービスにIPが含まれている場合、最初のノードではまだそのIPが立ち上がっているため、起動に失敗します。
• ノード2はノード1との接続を失い、fence_ILOを使用してフェンスを試みたが、成功しなかったと思われる。 ノード1はまだ起動していた。 Node2はサービスをオンラインにしようとしましたが、失敗しました。