[Linux]”IP address seems to still exist somewhere else”のエラーでクラスターフェイルオーバーが失敗する

  • 更新
フォローする

■発生事象

クラスターフェイルオーバー発生時に、待機系にて以下のエラーとともにIPリソースが起動失敗し、最終的にフェイルオーバーが失敗する。

lcdmachfail[xxxxx]: ERROR:lcd.mes:::004217:Communication failure: destination system "CLUSTERNODE001" is out of service.
lcdmachfail[xxxxx]: INFO:lcd.lraci:restore:ip-xx.xx.xx.xx:004878:Machine failover, remote resource is ILLSTATE. Not attempting remote remove of resource "ip-XX.XX.XX.XX" on machine "CLUSTERNODE001"
restore[xxxxx]: NOTIFY:RKActionHandler:restore:ip-XX.XX.XX.XX:001044:BEGIN restore of "ip-XX.XX.XX.XX"
restore[xxxxx]: ERROR:ip:restore:ip-XX.XX.XX.XX:123024:IP address seems to still exist somewhere else.
restore[xxxxx]: NOTIFY:RKActionHandler:restore:ip-XX.XX.XX.XX:001046:END failed "restore" of "ip-XX.XX.XX.XX" with return value of 1
lcdmachfail[xxxxx]: ERROR:lcd.lraci:restore:ip-XX.XX.XX.XX:004300:restore of resource "ip-XX.XX.XX.XX" has failed

 

■原因

LifeKeeperの仕様上、ノードフェイルオーバー時は早期に待機系でリソースを起動させることを優先します。そのため、稼働系リソースの停止を待たずに待機系でリソースの起動を開始します。本事象では、稼働系でIPリソースが完全に停止するより前に待機系でIPリソースが起動することにより、待機系でIPリソースを起動する際にIPの重複を検知してリソースの起動に失敗しています。

 

■原因への合致条件

コミュニケーションパス全断によるクラスターのフェイルオーバーが発生した
コミュニケーションパスのネットワークと、IPリソースのネットワークが設計上分離されている
※上記は本事象の一例であり、本事象の発生条件を網羅するものではありません。
 

■対処方法

本事象については、以下の対処方法が考えられます。

【方法１：IPの重複チェックを無効にする】
/etc/default/LifeKeeper 設定ファイルで、NOIPUNIQUEパラメーターを 1 へ変更します。
本設定により、IPリソース起動処理においてIPアドレスの重複チェックを無効化できます。

#vi /etc/default/LifeKeeper
（略）
NOIPUNIQUE=1
（略）

本設定は即時LifeKeeperに反映されます。
LifeKeeper の再起動は不要ですが、両サーバで同じ設定としてください。

ご参考：IP Recovery Kit のチューニング
 
【方法２：IP リソースの配下に、起動処理を待ち合せるスリープリソースを作成する】
IPリソースより下位の階層に5～10秒程度のsleepリソース（Genericリソース）を作成し、起動時に5秒程度の遅延を意図的に発生させます。

IP リソース
└sleep リソース

※Genericリソースの作成および動作保証はすべてお客様側での責任となるため、事前に十分な検証を行ってください。
サンプルスクリプトはございません。スクリプト作成にあたりまして、以下の資料をご参考ください。

ご参考：[Linux] GenericARK開発ガイドとサンプルスクリプト
 
【方法３：IP リソースの起動順序をできるだけ後にする】
要件上可能な場合は、IP リソースをできるだけリソースツリーの上位に配置することで、リソース起動タイミングを意図的に遅くできるので、本事象の発生可能性を抑制できます。
※ただし、リソースが早く起動する場合など、必ずしも本事象を回避できるとは限りません。
 
【方法４：STONITHを利用する】
共有ストレージ(SCSI Reserve)を利用しない場合、STONITHの利用により強力な排他制御が可能です。

ご参考：STONITH
 
【方法５：SCSI Reserveを利用する】
コミュニケーションパス全断時確実にフェイルオーバーを行うには、共有ストレージ(SCSI Reserve)による排他制御が有効です。

ご参考：SCSI リザベーション 

改訂履歴

[公開日：2018年12月26日]
[更新日：2019年05月13日] リンクを最新の情報に修正
[更新日：2019年10月21日] リンクを最新の情報に修正

関連記事