私のXenサーバーはopenSUSE11.1で、iSCSIへのopen-iscsi SANクラスターです。SANモジュールは、イニシエーターが仮想IPの背後にあるIPフェイルオーバーグループにありますに接続します。
プライマリSANサーバーがダウンした場合、セカンダリはターゲットとして機能する役割を引き受けます。これはすべて、LeftHand SAN/iQソフトウェアによって処理され、ほとんどの状況で適切に機能します。
私が抱えている問題は、Xen DomUの一部で、IPフェイルオーバー後にルートファイルシステムが読み取り専用になることがあるということです。これは一貫性がなく、フェイルオーバーが発生するたびに異なるサブセットに発生します。それらはすべて同じopenSUSE 11.1ソフトウェアイメージを実行しています。
各DomUのルートファイルシステムは、Dom0のopen-iscsiによってマウントされ、Xenは標準のブロックデバイスドライバーを使用してDomUに公開します。
正確な症状は、ルートとしてtouch /test
を実行すると、「読み取り専用ファイルシステム」というエラーが返されることです。ただし、mount
の出力は、読み取り/書き込みでマウントされていることを示しています。もちろん、domU上の他のすべてのI/Oもこの時点で失敗しているため、マシンは完全にダウンします。 iSCSIセッションを再接続することなくDom0からxm
を使用して再起動するだけで、すべてが再び機能します。
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スタックに送信するまでの時間を決定する設定です。
また、フェイルオーバーに実際にかかる時間も調べます。予想よりも時間がかかる場合があります。もしそうなら、おそらくVIPフェイルオーバーは、ARP関連の問題のために時間がかかりすぎています。
フェイルオーバー時の読み取り/書き込みエラーまたはscsiエラーを示すメッセージがdom0にありますか?もしそうなら、それはこの書き込みエラーがdomUに渡されているように見えます。 domUは、iSCSIデバイスであることを「認識」していないため、基盤となるディスクが削除され、ファイルシステムを読み取り専用で再マウントしたかのように動作しています(mount(1)のマンページを参照してください-errors=continue / errors=remount-ro / errors=panic
)
Dom0の観点からは、読み取り専用に変更されることはありません-この読み取り専用の動作は、ファイルシステムセマンティックであり、ブロックデバイスセマンティックではありません。
この時点で「他のすべてのI/Oが失敗している」とのことですが、domUかdom0ですか?
通常、HA iSCSIソリューションをセットアップするときは、仮想IPテイクオーバーではなくマルチパスを使用します。これにより、ホストの可視性が高まり、iSCSIセッションが突然消えて再起動する必要がなくなります。常に存在し、そのうちの2つだけです。 。これはこの環境でのオプションですか?