[Linux-ha-jp] [TOTEM] FAILED TO RECEIVE 発生後に corosync 停止

Zurück zum Archiv-Index

renay****@ybb***** renay****@ybb*****
2013年 11月 5日 (火) 09:05:53 JST


林さん

おはようございます。山内です。

> ご回答ありがとうございます。
> 
> 頂いたアドバイスをもとに、以下の設定変更を実施しました。
> 
> (1) window_size: 300
> (2) マルチキャスト通信からユニキャスト通信への変更
> (3) fail_recv_const: 10,000
> 
> 現在、設定変更後の経過観察を続けております。
> 色々とアドバイスありがとうございました。
> 
> また、同時に障害の再現性の確認や両機のクラスタを再起動して
> クラスタ再構成を行いました。
> 
> その作業時に2点疑問に思う事がありましたので質問させて頂きます。
> 
> (1)障害の再現性を確認した所、今回の作業後、すぐに障害が発生しました。
>   前回の障害はcorosyncのプロセス再起動(サーバ再起動)後、
>   約2週間程度たってから発生しましたが、
>   この発生までの時間差異についてどのように思われますでしょうか?
> 
>   今回の作業としては以下です。
>   (上記した設定変更前に実施した内容です)
> 
>   ・2号機(Standby側)のcorosyncを停止(/etc/init.d/corosync stop)
>   ・1号機(Active側)のcorosyncを停止(/etc/init.d/corosync stop)
>    ・1号機(Active側)のcorosyncを起動(/etc/init.d/corosync start)
>    ・2号機(Standby側)のcorosyncを起動(/etc/init.d/corosync start)
>    ・2号機(Standby側)にて"pcs config"コマンド実行
>    ・2号機(Standby側)のログにRetransmit List:のログ発生
> 
>   #前回の障害のまでの間に"pcs config"コマンドは、1号機で6回、
>      2号機で1回実施していますが、その際は障害は発生しませんでした。

申し訳ありませんが、時間的な差異に関しては、現状、何とも判断しようがありません。
ただ、pcs config(pcsコマンド自体に私は詳しくありませんが)、crm configと同等の動作と考えると、configで構成を取得しただけで、障害が発生するとは考えずらいかと思っています。

> 
> (2)今回の作業で障害が再発した後、
>   DRBD領域(corosyncにて制御しているリソースの一つ)が、
>   前回の復旧作業でスプリットブレインになった事が原因で
>   DRBDの同期ができていない事に気付きました。
> 
>   その為、DRBDのスプリットブレインからの復旧として以下を実施しました。
> 
>    2号機(Standby側)
>   #drbdadm secondary <resource>
>    #drbdadm -- --discard-my-data connect <resource>
> 
>    1号機(Active側)
>    #drbdadm connect <resource>
> 
>    上記の結果、DRBDとしては同期可能となりました。
> 
>   その上で、corosyncのプロセス停止、起動を行い、
>   障害の再現性を確認した所、障害は発生しませんでした。
> 
>   以上から考えて、DRBDのデータ同期に問題があった状態で、
>   "pcs config"コマンドを実施した為障害が発生した可能性はありますでしょうか?

上記の通りなのですが、pcs configが影響したとは考えずらいと思っています。
もし、ご要望があれば、同一の環境で動作を確認してみることは可能と思います。
その場合、簡易に構成環境のソフトバージョン、支障のないレベルでのconfigファイル(PMのリソース構成、corosync.conf)などを開示して頂ければと思います。
#多少お時間は頂くかと思いますが・・・・

以上、ご連絡が遅れ、申し訳ありませんでした。

--- On Fri, 2013/11/1, Kouga Hayashi <kouga****@gmail*****> wrote:

> 山内様
> 
> ご回答ありがとうございます。
> 
> 頂いたアドバイスをもとに、以下の設定変更を実施しました。
> 
> (1) window_size: 300
> (2) マルチキャスト通信からユニキャスト通信への変更
> (3) fail_recv_const: 10,000
> 
> 現在、設定変更後の経過観察を続けております。
> 色々とアドバイスありがとうございました。
> 
> また、同時に障害の再現性の確認や両機のクラスタを再起動して
> クラスタ再構成を行いました。
> 
> その作業時に2点疑問に思う事がありましたので質問させて頂きます。
> 
> (1)障害の再現性を確認した所、今回の作業後、すぐに障害が発生しました。
>   前回の障害はcorosyncのプロセス再起動(サーバ再起動)後、
>   約2週間程度たってから発生しましたが、
>   この発生までの時間差異についてどのように思われますでしょうか?
> 
>   今回の作業としては以下です。
>   (上記した設定変更前に実施した内容です)
> 
>   ・2号機(Standby側)のcorosyncを停止(/etc/init.d/corosync stop)
>   ・1号機(Active側)のcorosyncを停止(/etc/init.d/corosync stop)
>    ・1号機(Active側)のcorosyncを起動(/etc/init.d/corosync start)
>    ・2号機(Standby側)のcorosyncを起動(/etc/init.d/corosync start)
>    ・2号機(Standby側)にて"pcs config"コマンド実行
>    ・2号機(Standby側)のログにRetransmit List:のログ発生
> 
>   #前回の障害のまでの間に"pcs config"コマンドは、1号機で6回、
>      2号機で1回実施していますが、その際は障害は発生しませんでした。
> 
> (2)今回の作業で障害が再発した後、
>   DRBD領域(corosyncにて制御しているリソースの一つ)が、
>   前回の復旧作業でスプリットブレインになった事が原因で
>   DRBDの同期ができていない事に気付きました。
> 
>   その為、DRBDのスプリットブレインからの復旧として以下を実施しました。
> 
>    2号機(Standby側)
>   #drbdadm secondary <resource>
>    #drbdadm -- --discard-my-data connect <resource>
> 
>    1号機(Active側)
>    #drbdadm connect <resource>
> 
>    上記の結果、DRBDとしては同期可能となりました。
> 
>   その上で、corosyncのプロセス停止、起動を行い、
>   障害の再現性を確認した所、障害は発生しませんでした。
> 
>   以上から考えて、DRBDのデータ同期に問題があった状態で、
>   "pcs config"コマンドを実施した為障害が発生した可能性はありますでしょうか?
> 
> 
> 以上、宜しくお願い致します。
> 
> 2013年10月28日 9:42  <renay****@ybb*****>:
> > 林さん
> >
> > おはようございます。山内です。
> >
> >> (1)window_sizeの値をあげる
> >>
> >> 参照ページの情報及び、/etc/corosync/corosync.confの説明から
> >> 詳細は分かりませんが、変更してみようと思います。
> >>
> >> 参照ページ:
> >> http://www.hastexo.com/resources/hints-and-kinks/whats-totem-retransmit-list-all-about-corosync

> >>
> >
> >> また、値は「300」にしようと考えています。
> >>
> >> この値を変更する事で、別の部分に影響する事はあるのでしょうか?
> >
> > こちらの影響はないと思います。
> >
> >>
> >> (2)マルチキャスト通信からユニキャスト通信への変更
> >>
> >> 中平様のご指摘や、今回の構成では、物理サーバ間でのクラスタであるものの、
> >> 物理サーバ内にはKVM仮想ゲストもあり、ブリッジ接続を利用している為、
> >> マルチキャスト通信をやめてユニキャスト通信にしようと思います。
> >>
> >
> > こちらも問題ないと思います。
> > もし、corosync層のインターフェースを2重化されているのであれば、rrp_modeもnoneなどに設定して、bondingを採用された方が良いかも知れません。
> > #確かcorosyncではいろいろと問題があって、推奨されるrrp_modeは、noneだったと記憶しています。
> >
> >> (3)fail_recv_constの値をあげる
> >>
> >> 山内様のご指摘の通りRetransmitログが2500回くらいでクラスタ障害が発生したように思います。
> >> 可能性は低いかもしれませんが、Retransmitログ(未到達のメッセージ)が終息する可能性を考えて、
> >> 5,000から10,000くらいの値にしようと考えています。
> >>
> >> この値を変更する事で、別の部分に影響する事はあるのでしょうか?
> >
> > 特にないと思います。
> >
> > また、こちらの検証環境で無理やり再現させた上で、
> >> 上記の数値を変えた場合以下結果となりました。
> >>
> >> ●検証条件
> >>  ・Corosync+Pacemakerのバージョンは障害発生時と同じ
> >>  ・1号機(Active側)のiptablesでノード間に流れるUDPパケットの量を制限した
> >>  ・"pcs config"コマンドを実行して、ノード間でやり取りされるメッセージがある状況にした
> >>  ・fail_recv_const: 10 としてFAILED TO RECEIVEが発生しやすいようにした
> >>
> >
> >> ●検証結果
> >>          | iptables                   | multi or uni  | window_size | FAILED TO RECEIVEの発生有無
> >>   ----------------------------------------------------------------------------------------
> >>       1  | パケット数100/s制限 | multi         |     50      | 発生
> >>
> >   ----------------------------------------------------------------------------------------
> >>       2  | パケット数100/s制限 | uni            |     50      | 発生
> >>   ----------------------------------------------------------------------------------------
> >>
> >       3  | パケット数100/s制限 | uni            |    300     | 発生しない
> >>   ----------------------------------------------------------------------------------------
> >>       4  | パケット数100/s制限 | multi         |     50      | 発生
> >>
> >
> >>
> >> ■クラスタ再構成について
> >>
> >> > ①一度、クラスタ上のノードは単一ノード(初期起動状態)になります。
> >> > ②その後、クラスタ上の他ノードとクラスタを組む為の制御メッセージのやり取りを行います。
> >> > ③再構成出来たら、再度クラスタを構成。出来ない場合は、それぞれのノードは単一のノードでクラスタを構成しますが、この後、単一のノードは他のクラスタ(ノード)の存在を検知してクラスタを統合する為に、制御メッセージを出します。この制御メッセージで再構成できれば、単一だったノードは他のクラスタ(ノード)とクラスタを構成します。
> >>
> >> ④よって、③を完了すれば、基本的にはきちんとクラスタは再構成できるということになります。
> >>
> >> 頂いた情報を元に、再度、FAILED TO RECEIVE発生時のログを1号機(Active側)で確認しました。
> >>
> >> 制御メッセージのやり取りをしているようには思えず、crmdとcibのコネクションがこわれてしまっているようです。
> >>
> >> Oct 16 21:48:42 kvmco1 crmd[12268]:    error: do_log: FSA: Input I_ERROR from crmd_cib_connection_destroy() received in state S_IDLE
> >>
> > Oct 16 21:48:42 kvmco1 crmd[12268]:   notice: do_state_transition: State transition S_IDLE -> S_RECOVERY [ input=I_ERROR cause=C_FSA_INTERNAL origin=crmd_cib_connection_destroy ]
> >> Oct 16 21:48:42 kvmco1 crmd[12268]:    error: do_recover: Action A_RECOVER (0000000001000000) not supported
> >>
> > Oct 16 21:48:42 kvmco1 crmd[12268]:  warning: do_election_vote: Not voting in election, we're in state S_RECOVERY
> >> Oct 16 21:48:42 kvmco1 crmd[12268]:    error: do_log: FSA: Input I_TERMINATE from do_recover() received in state S_RECOVERY
> >>
> >
> >> その後、制御している各リソースで以下メッセージが出ました。
> >> (以下はリソースの1つであるファイルシステムの件です。)
> >>
> >> Oct 16 21:48:42 kvmco1 crmd[12268]:    error: verify_stopped: Resource filesystem was active at shutdown.  You may ignore this error if it is unmanaged.
> >>
> >
> >> その後、crmdではリカバリーができず終わっております。
> >>
> >> Oct 16 21:48:42 kvmco1 crmd[12268]:   notice: terminate_cs_connection: Disconnecting from Corosync
> >> Oct 16 21:48:42 kvmco1 crmd[12268]:   error: do_exit: Could not recover from internal error
> >>
> >
> >> このような動作で、一応1号機(Active側)でリソースだけは生き残り、
> >> サービスが継続されました。
> >>
> >> 環境状況によるかと思いますが、もう一度再発しても、
> >> 1号機(Active側)でリソースは生き残るものでしょうか?
> >>
> >> 障害発生原因がわからない状況ですが、できれば障害が発生しても
> >> サービスだけは継続したく対策を考える上で、
> >> アドバイスを頂ければと思います。
> >
> > 今回の全く同じ状況じ(corosync/pacemakerが落ちる)であれば、1号機側のリソースに対しての制御は行われない状態となりますので、サービスは残る可能性が高いと思います。
> >
> > 障害発生時に、1号機・2号機どちらかでサービスを継続するという方針であれば、stonithを採用されることをお勧めします。
> > #ただし、stonithを採用した場合、今回の状況であれば、リソースを保持している1号機(サービスがまだ残っているノード)がstonithされますので、2号機へサービスがFOします。
> >
> > 以上、宜しくお願いいたします。
> >
> >
> >
> >
> >
> > _______________________________________________
> > Linux-ha-japan mailing list
> > Linux****@lists*****
> > http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan

> 





Linux-ha-japan メーリングリストの案内
Zurück zum Archiv-Index