NAKAHIRA Kazutomo
nakahira_kazutomo_b1****@lab*****
2013年 10月 25日 (金) 11:31:47 JST
TO：林さん おはようございます。中平と申します。 今回の不具合について、山内さんのご指摘のとおり Corosync2.0系を まずはご利用されることをお勧めしますが、その他の原因として、 ネットワーク周りに何か問題がないか合わせてチェックして頂ければ と思います。 以前、マルチキャスト通信が遮断され、その他の通信は疎通する 故障が起きたときに、今回のように FAILED TO RECEIVEが発生し corosyncプロセスが落ちる問題に当たったことがあります。 # このときは、RHEL6.1の bridgeインタフェースが実行する # IGMPスヌーピングの動作不良が原因でしたが、RHEL6.4では # この問題は解決されています。 マルチキャスト通信のみが突然落ちだすという故障はかなり レアケースなので、今回の原因とは関係がないかもしれませんが、 iptablesや NICの設定に問題がないか、スイッチ経由で結線して いる場合はスイッチ側で何か問題が起きていないかなどを、 念のため調べてみるとよいかと思います。 以上です。 よろしくお願い致します。 (2013/10/24 9:07), renay****@ybb***** wrote: > 林さん > > おはようございます。山内です。 > > > > --- On Wed, 2013/10/23, 林 宏河 <hayas****@progd*****> wrote: > >> 山内様 >> >> ご回答ありがとうございます。 >> 追加でいくつか質問がございます。 >> お分かりになる範囲で結構ですので、コメントお願い致します。 >> >>>> Oct 16 21:41:11 kvmco2 corosync[8071]: [TOTEM ] Retransmit List: fe ff >> >>> このログは、クラスタのノード間でメッセージの内容が一致しない（未到達のメッセージ）の >>> やり取り中に発生します。 >> >> Retransmitログは、「クラスタのノード間でメッセージの内容が一致しない >> （未到達のメッセージ）のやり取り中に発生」との事でしたが、 >> 未到達メッセージのログが出力される場合には、具体的にどのような場合があるのでしょうか？ > > 確か未到達のメッセージとして処理されるのは、corosyncスタック層を使って通信を行っているメッセージのみのはずです。 > よって、Pacemakerと組み合わせている場合は、Pacemakerによってノード間でやり取りされるメッセージなどが相当します。 > > ただし、今回の事象がPacemakerが安定状態ということであれば、通常、そのようなメッセージは流れないはずなので、何らかの不具合が発生しているのではないかと思っています。 > > >> >> 検証などしているとノード間の単純なネットワーク断では >> このような事態にはならないのかと思っています。 >> >> 突然Retransmitログが出力されだした為、その時何が起きていたのか、 >> 再発する可能性はあるのかどのような対策をすべきかが現在わからず、悩んでおります。 >> >> 具体的にどのような状況に陥った可能性があるかアドバイス頂けないでしょうか。 > > 上記の通りで、なぜ、安定状態から未到達が出てくるのかはちょっと現時点では判断しかねます。 > ＃詳細にソース・発生時のログなどを見る必要があると思います。 > >> >>>> ■1号機(Active側) >>>> >>>> Oct 16 21:48:42 kvmco1 corosync[12257]: [TOTEM ] FAILED TO RECEIVE >> >>> こちらのログは、確か、上記の未到達のメッセージ数が上限を超えたあたりで出力されるはずです。 >>> これが出るということは、クラスタを構成するノード間での未到達のメッセージの回復（一致）が出来なかったことを意味しますので、 >>> corosyncは再度、クラスタを再構成しようとします。 >> >> クラスタを再構成しようとするとの事ですが、 >> 具体的にはどのような状況になるべきなのでしょうか？ > > 以下のような動きになります。 > > ①一度、クラスタ上のノードは単一ノード（初期起動状態）になります。 > ②その後、クラスタ上の他ノードとクラスタを組む為の制御メッセージのやり取りを行います。 > ③再構成出来たら、再度クラスタを構成。出来ない場合は、それぞれのノードは単一のノードでクラスタを構成しますが、この後、単一のノードは他のクラスタ（ノード）の存在を検知してクラスタを統合する為に、制御メッセージを出します。この制御メッセージで再構成できれば、単一だったノードは他のクラスタ（ノード）とクラスタを構成します。 > ④よって、③を完了すれば、基本的にはきちんとクラスタは再構成できるということになります。 > >> >> 今回は、1号機(Active側)でcorosyncが停止したにも関わらず >> 2号機(Standby側)にも引継ぎが出来ない状況になり、 >> corosyncは停止したものの、サービスは1号機(Active側)が継続した形となりました。 > > ログや設定ファイルを見てみないとわかりませんが、本来はサービス停止になるはずですが、Pacemakerからの制御が行われずに、ノードが停止したと思われます。 > >> 2号機(Standby側)からの未到達メッセージがある事で、 >> 1号機(Active側)がダウンしてしまうと、サービスに影響が出ることを懸念しております。 >> >> それとも、未到達メッセージが出力され、クラスタノード間で不整合が出そうな場合は、 >> 全クラスタでサービスも停止となるのでしょうか？ > > すいません。 > 不整合～停止したことに関しては、私の方でもきちんと動作を把握していません。 > クラスタを再構成出来ない状態が続くと、このような状態になるのかも知れません。 > ＃個人的には、不具合からPacemakerかcorosyncに問題が出て停止したものと思っていますが・・・・ > ＃corosync2.0系の採用をやはりおすすめしますが・・・・ > > > 以上、宜しくお願いいたします。 > > > _______________________________________________ > Linux-ha-japan mailing list > Linux****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan > -- NTTデータ先端技術株式会社 中平 和友 TEL: 03-5860-5135 FAX: 03-5463-6490 Mail: nakahira_kazutomo_b1****@lab*****
Fork