TAKATSUKA Haruka
haruk****@sra*****
2014年 1月 22日 (水) 18:08:14 JST
高塚です。 ・crm_mon 出力を見ますとノードが全て Online ですし、DC は一貫して host1 ですし、ご認識の通り、これはスプリットブレインではないですね。 ・片ノードで v_ipリソースに紐づくNIC に障害を起こすテストをしていて、 障害をうけて、別ノードでリソースが起動したあと、リソースを元のノードに crm コマンドで戻すのにうまくいかないケースがある、ということですね。 そのうまくいかない場合の諸情報を提示いただければ、だれか何か分かる かもしれません。 ・スプリットブレインを疑似的に作り出すなら、iptables でノード間通信で 使用しているポートを遮断してしまうのが簡単です。 On Wed, 22 Jan 2014 13:07:58 +0900 mlus <mlus****@39596*****> wrote: > コヤマです。 > > 高塚さん、ご返答ありがとうございます。 > 長文にて失礼します。 > > > クラスタ管理部が corosync の場合については詳しく把握していませんが、 > > heartbeat の場合についていえば、 > > 双方が DC を名乗っている状態になった後で相互通信が復旧したとして、 > > 少なくとも片方の heartbeat プロセスを再起動をしないと、スプリット > > ブレインを解消できないと思います。 > > テストとして、NICをホストから挿抜して行いましたが、 > スプリットブレインを擬似的に作り出せてないので、 > 想定していたテストが出来ていないのが現状です。 > 2つのノードとも、HAデーモン(pacemaker corosync)を起動させた > ままのテストになりました。 > 片方(この場合active側）のHAデーモンを再起動してしまうケースだと、 > 私の知識では、standby側のHAデーモンを再起動なしに稼動したままでの > crmコマンドを使って元に戻す事ができていません。 > 質問が上手くできていませんでしたが、この方法も知りたかったのです。 > > 再起動なしバージョンでは、テストと経過が以下のようになりまして、 > 一応元に戻すことができています。 (後略）
Fork