iSCSI仮想IPフェイルオーバーでXen DomUルートファイルシステムが読み取り専用になる

私のXenサーバーはopenSUSE 11.1で、iSCSI SANクラスターに対してopen-iscsiを使用しています。SANモジュールは、イニシエーターが接続する仮想IPの背後にあるIPフェイルオーバーグループにあります。

プライマリSANサーバーがダウンした場合、セカンダリはターゲットとして機能する役割を引き受けます。これはすべてLeftHand SAN / iQソフトウェアによって処理され、ほとんどの状況でうまく機能します。

私が抱えている問題は、Xen DomUの一部で、IPフェイルオーバー後にルートファイルシステムが読み取り専用になることがあるということです。これは一貫性がなく、フェイルオーバーが発生するたびに異なるサブセットに発生します。それらはすべて同じopenSUSE 11.1ソフトウェアイメージを実行しています。

各DomUのルートファイルシステムは、Dom0のopen-iscsiによってマウントされ、Xenは標準のブロックデバイスドライバーを使用してDomUに公開します。

正確な症状は、実行中のrootとしてtouch /test「読み取り専用ファイルシステム」エラーを返すことです。ただし、の出力は、mount読み取り/書き込みでマウントされていることを示しています。もちろん、domU上の他のすべてのI / Oもこの時点で失敗しているため、マシンは完全にダウンします。xmiSCSIセッションを再接続することなくDom0から再起動するだけで、すべてが再び機能します。

Dom0側では、フェイルオーバー中のsyslogメッセージは次のようなものです。

kernel: connection1:0: iscsi: detected conn error (1011)
iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
iscsid: connection1:0 is operational after recovery (1 attempts) 

この問題をデバッグするためにどのレイヤーを見つけるのに苦労しています、それはDomUカーネルの何かですか？またはDom0またはXenレベルで？何らかのタイムアウトを増やすために微調整が必​​要なパラメータがどこかにあると思いますが、どこを見ればよいかわかりません。

接続されたブロックデバイスがDom0から読み取りおよび書き込み可能であるという理由だけで、open-iscsiの問題であるとは本当に思いません。

私は最終的に、open-iscsiドキュメントの次のアドバイスと設定を使用してこれを解決しました。

8.2 iSCSI settings for iSCSI root
---------------------------------

When accessing the root parition directly through a iSCSI disk, the
iSCSI timers should be set so that iSCSI layer has several chances to try to
re-establish a session and so that commands are not quickly requeued to
the SCSI layer. Basically you want the opposite of when using dm-multipath.

For this setup, you can turn off iSCSI pings by setting:

node.conn[0].timeo.noop_out_interval = 0
node.conn[0].timeo.noop_out_timeout = 0

And you can turn the replacement_timer to a very long value:

node.session.timeo.replacement_timeout = 86400

上記のように各LUNへの接続をセットアップした後、フェイルオーバーは、数分かかる場合でも魅力的に機能します。

これは、dom0で実行されているiSCSIイニシエーターの問題のようです。イニシエーターは、SCSI障害をスタックに迅速に送信しないでください。iscsi.confでConnFailTimeoutを設定することをお勧めします。これは、接続の失敗をエラーと見なし、そのエラーをSCSIスタックに送信するまでの時間を決定する設定です。

また、フェイルオーバーに実際にかかる時間も調べます。予想よりも時間がかかる場合があります。その場合、ARP関連の問題が原因でVIPフェイルオーバーに時間がかかりすぎる可能性があります。

フェイルオーバー時の読み取り/書き込みエラーまたはscsiエラーを示すdom0のメッセージはありますか？もしそうなら、それはこの書き込みエラーがdomUに渡されているように見えます。domUは、iSCSIデバイスであることを「認識」していないため、基盤となるディスクがなくなってファイルシステムを読み取り専用で再マウントしたかのように動作しています（mount（1）のマンページ-を参照errors=continue / errors=remount-ro / errors=panic）。

dom0の観点からは、読み取り専用に変更されることはありません。この読み取り専用の動作は、ファイルシステムセマンティックであり、ブロックデバイスセマンティックではありません。

この時点で「他のすべてのI / Oが失敗している」とおっしゃっていますが、domUかdom0ですか？

通常、HA iSCSIソリューションを設定するときは、仮想IPテイクオーバーではなくマルチパスを使用します。これにより、ホストの可視性が向上し、iSCSIセッションが突然消えて再起動する必要がなくなります-常にそこにあり、2つしかありません。 。これはこの環境でのオプションですか？

ええと...問題の一部は、ROとして実行していないことでもあります。ベストプラクティスは、 "/"でroをマウントし、rwを必要とするすべてのファイルシステムを個別にマウントする必要がある（つまり、/ varと/ tmp）。/ etcの下に書き込みが必要なディレクトリがある場合は、/ var / etc / pathに移動し、/ etcにシンボリックリンクする必要があります。

「/」は、シングルユーザーモードでのみRWをマウントする必要があります。

この方法で設定すると、他の提案と組み合わせると、上記の状況でのセグメンテーション違反を防ぐことができます。