MATSUzakI Motoaki
matsu****@desig*****
2014年 7月 1日 (火) 15:40:39 JST
松島様 松崎です。 早速お返事ありがとうございます。 (2014/06/28 5:18), Takehiro Matsushima wrote: > 松崎さん > > はじめまして、松島と申します。 > > 実際に検証したわけではありませんが、 > http://www.drbd.org/users-guide-8.3/re-drbdconf.html > の内容がマッチしていると思います。 > DRBDやKernelの動作をよくわかっていないので、正しいかどうかわかりませんが... > >> DRBDのデフォルトのタイムアウトは6秒だと思いますが、3.1ではそれ以上待たさ >> れているため、DRBDの無応答検出とは別のところで止まっていたのでは思いま >> す。DRBDの無応答検出は、connect要求からACKが返るまでの時間ではないかと思 >> いますので、ESTABLISHEDな状態になってからS機が返事を返さなかったのではな >> いかと思っています。 > > DRBDのタイムアウト(timeout)ですが、 > * timeoutはデフォルト6秒 > * timeoutはconnect-intとping-intより小さくあるべし > * connect-intは接続リトライ間隔でデフォルト10秒 > * ping-intは字面どおりで、デフォルト10秒 > * ping-timeoutはデフォルト500ミリ秒 > となっていました。 > timeout自身は > If the partner node fails to send an expected response packet within > time tenths of a second, > the partner node is considered dead and therefore the TCP/IP > connection is abandoned. > だそうですので、確立された接続そのものも対象になっているのではないでしょうか。 > ただ、TCP/IPのタイムアウトというよりは、DRBDとしてのタイムアウトかもしれません。 > TCP/IPとしての接続を維持した状態であっても、書き込み要求を投げてもその結果が > 時間切れになればタイムアウトとして扱われる、というように読めます。 > (が、TCP/IP接続が切断されるので縮退しそうなものですが) いろいろなパラメータがいろいろな効果をもたらしているようですね。pingとソ ケット自体のタイムアウトがあると思いますが、ネットワークに関わる部分が原 因だとすると、今回焦点になっているのはソケット自体のほうだと思います。 >> ・このときDRBD的に何が起こっていたのでしょうか？ > > DRBDのプロセスは生きており、TCP/IPの接続は維持されたままとなっていたかもしれません。 > Pacemakerとしても問題がある状態にはなっていないはずです。 > セカンダリノードではメモリに溜め込んだ書き込み予定のブロックをフラッシングしようとしているのに > Diskが返答をよこさないため(OSは)SCSIなりATAなりのタイムアウトを待ちます。 > OSは一旦タイムアウトを迎えてもリトライをするかもしれません。 > ここは次のURLの内容が該当するでしょうか。 > https://access.redhat.com/site/documentation/ja-JP/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/task_controlling-scsi-command-timer-onlining-devices.html これは納得できます。RAIDコントローラではありませんが、壊れたディスクの不 良箇所を踏んだ場合、ディスクに対して何度も読み書きを挑戦するような音が聞 こえ、一定回数挑戦して成功しなかったらついには諦めてエラーが返るという現 象と同じように思います。 > ここで完全にタイムアウトになってしまうまえにプライマリのほうでFilesystem RAが > monitor timeoutを迎えフェイルオーバーしようとしても、今度はセカンダリの方で > リソースの昇格やマウントに失敗(ROになっているなど)しフェイルオーバーに失敗する、 > という状況かもしれません。 ここはちょっとややこしいので一度整理します。 2. S機のOSが反応しなくなるのは、3. P機のmonitorが走る前でした。正確に は、S機でログファイルが行の途中で途切れていたときの、そのログの時刻から 類推しています。もしかすると、この時点でSCSIエラーが発生していたのかもし れませんし、P機のmonitorが走っている時点でもデバイスへのリトライの真っ最 中だったかもしれません。 S機ではDRBDのログなど何も出力されていませんでしたが、ただ単に書けていな いだけだったという考え方もできるかもしれません。そうしますと、確かにおっ しゃることもうなずけるのですが、Pacemakerのログを見る限りはS機への通信断 を検知しているようですので、フェイルオーバを試みた時点で対向ノードが死ん でいることから、P機は再度自ノードでサービスの起動を試みたのではないかと 思います。 とすると、ちょっと戻るのですが、S機ではSCSIデバイスが応答しない状態であ りつつ、あるタイミングからkernel、少なくともネットワークインタフェースは 応答しない状態が同時発生していたようにも見受けられます。恐らくネットワー クの方はSCSIよりは後で死んだとすると、今回の現象を引き起こす原因というの は、次のどれかになりそうです。 1. S機のSCSIエラーに引きずられた 2. S機のネットワーク無応答により引き起こされた 3. 実は合わせ技 1だとすると、ネットワークが生きている限りDRBD自体のハートビートかキープ アライブか何かで接続が確立しており、しかし応答が遅かった、と考えられます （しかしprotocol BがSCSIに引きずられるかどうかは疑問ですが）。 2だとすると、タイムアウトの基点はどこ？という疑問が解決すれば原因は見え てきそうな気がします。 >> ・この状態に陥ったときでも適当な時間でタイムアウトするような設定はあるの >> でしょうか？もちろん、protocol Cにすればこのような状態にならないことは理 >> 解できます。 > > DRBD8.4にはdisk-timeoutというパラメタがあるようです。 > DRBD8.3でしたらko-countが効くのかもしれません。 > セカンダリノードが書き込みリクエストの処理に指定回数失敗した(timeoutで指定した時間に達した)場合、 > クラスタからセカンダリノードが排除され、プライマリはStandAloneに遷移する、という内容ですが、 > デフォルトは0になっており、機能が無効化されているようです。 > In case the secondary node fails to complete a single write request > for count times the timeout, > it is expelled from the cluster. (I.e. the primary node goes into > StandAlone mode.) > The default value is 0, which disables this feature. なるほど、ko-countは効きそうな感じですね。「 fails to complete a single write request」がどのポイントの事を指しているかにもよると思いますが・・・ -- ------------------------------ MATSUzakI Motoaki DesigNET Inc. e-mail: matsu****@Desig***** Phone: +81-52-709-7121 (voice) +81-52-709-7122 (FAX) URL: http://www.DesigNET.co.jp/ ------------------------------
Fork