この投稿は5年以上前のものです
280 メッセージ
0
6720
Linux + iSCSI環境のタイムアウト値について
VNX for BlockのiSCSI環境で、以下のようにホストを接続しています。
・RHEL 6.0
・NMP
先日、VNXでSPのリブートを実施したところ、リブート後にSPへiSCSI sessionが復帰しませんでした。
サーバー側では、一度Sessionが切れた場合、自動復帰がされる設定になっているはずなのですが、
いつまで復帰を試みるか？というタイムアウト及びリトライ設定として、
node.conn[0].timeo.login_timeout = 15
node.session.initial_login_retry_max =8
あたりが関係するのではないか、またその場合は120秒がリトライの限界のように思われます。
ついては、
①上記設定についての推奨等ございますでしょうか？
（EMC Host Connectivity Guideにはこちらの項目は見当たりませんでした。）
②SPの再起動時にはどれくらいログインできない時間があるのでしょうか？
先日のリブートはOEアップグレードによるものだったため、片系のSPリブートで約40分程度かかっていました。
つまり、40分間Sessionにログインできないとすれば、上記設定ではリブート後にはタイムアウト値を超えているため、
自動で復帰はしないということになり、設定として妥当であるのか？と懸念しております。
以上、よろしくお願いいたします。
Anonymous
5 Practitioner
5 Practitioner
•
274.2K メッセージ
0
2013年4月22日 19:00
②の時間について、実際に日本で作業を行っている者や、上海のsupport teamに確認したところ、約1時間、最低でも45分かかるとのことでした。
ayanoさんが約40分とのことですので、この45分にも「約」が付く「幅」のあるものと考えるべきでしょうね。
また、①の設定についてもayanoさんが調べられた「Connectivity Guide」に書かれていることが多いのですが、Linux iSCSI 設定についてはおっしゃる通り、載っておらず、また、上海teamの見解では15秒を8回は一般的であるとのことなので、この設定は特に問題ないと考えられます。
しかし、ayanoさんのおっしゃるように15秒×8回の2分間では約40分から1時間の作業時間はカバーできませんね。この点についてもう少し調べ、何かありましたらupdateしますね。
JPCommunityMgr
Community Manager
Community Manager
•
3.1K メッセージ
0
2013年4月22日 20:00
スペース「日本語コミュニティ」からサブスペース「ストレージシステム」に移動しました。
Anonymous
5 Practitioner
5 Practitioner
•
274.2K メッセージ
0
2013年4月24日 00:00
サポートに確認したところ、（例えば、VNX OEのupgrade時の）SP リブート後、通常、iSCSIセッションは自動復活するとのことでした。
ただし、host側の要因によっては、SPリブート前に手動によるTrespassを行うことで安全性が高まるケースもあるそうです。
Uehara Y.
Community Manager
Community Manager
•
4.9K メッセージ
1
2013年4月24日 21:00
MultiPathソフトウェアがきちんと動作していれば、サポートの方が言っているように片方のSPリブート時にiSCSIセッションが切れるということはないと思うのですが、そもそものiSCSIのデバイス認識についてよくわからなかったので確認をしてみました。この情報が参考になると幸いです。
[利用環境]
ホストはCentOS 6.3
open-iscsiはデフォルト設定(iscsi-initiator-utils-6.2.0.873-2.el6.x86_64)＝インストール後/etc/iscsi/iscsid.confに変更は行わない
iSCSIのターゲットはVNXe3300（OE 2.3) 本当はVNX利用して確認をしたかったのですが、環境がなかったのでしょうがなくVNXeを利用して確認をしてみました。
わかったことは以下の通りです。
1) ホストからiSCSIデバイスへのコネクションが切れた後に、該当デバイスへアクセスを試みると、（おそらく2分のリトライの後）Read-Onlyと認識されてしまう。一度Read-Onlyと認識されてしまうと、iSCSIのコネクションが復活した後でも再マウントするまでは該当デバイスはRead-Onlyのまま。
1)' ホストからiSCSIデバイスへのコネクションが切れた後に、該当デバイスへのアクセスをせずに（ひっそりとして）いて、その後（こっそりと）コネクションが復活すると、何事もなかったかのように該当デバイスへのアクセスが可能。
2) ホストが起動する時に、iSCSIデバイスへのコネクションが切れていると、（おそらく2分のリトライの後）ホストはそのデバイスはもう無いものとして起動し、iSCSIデバイスへの明示的なログイン→マウントなどの処理をしない限り当該iSCSIデバイスを認識することはない。
iSCSIにそれほど明るくはないので正しいかは少し不安ですが、SPがダウンしているタイミングでホストのリブートを行ったりすると、上記2)に合致してしまい、該当パス（デバイス）がホストから認識されなくなってしまうということがありそうです。
Uehara Y.
Community Manager
Community Manager
•
4.9K メッセージ
0
2013年4月24日 21:00
※参考情報：確認パターンと結果の概要
【確認パターン1】
両SPへのEtherケーブルを抜線後、ホストからiSCSI接続されているディレクトリにアクセス。
すると該当領域はRead-only file systemとなり参照は出来るが変更や追加は不可能となる。
dmesgには以下のような記述（VNXeのiSCSI領域はsdb1として認識しています）。Read-onlyにしてから8×15＝120秒待っているのか120秒待ってからRead-onlyにしているのかまでは不明。
EXT3-fs (sdb1): error: remounting filesystem read-only
connection15:0: detected conn error (1020)
connection14:0: detected conn error (1020)
connection15:0: detected conn error (1020)
connection15:0: detected conn error (1020)
connection15:0: detected conn error (1020)
connection15:0: detected conn error (1020)
connection15:0: detected conn error (1020)
connection15:0: detected conn error (1020)
connection15:0: detected conn error (1020)
connection15:0: detected conn error (1020)
connection15:0: detected conn error (1020)
connection15:0: detected conn error (1020)
connection15:0: detected conn error (1020)
connection15:0: detected conn error (1020)
connection15:0: detected conn error (1020)
session15: session recovery timed out after 120 secs
/var/log/messagesには以下のエラーが多数
Apr 24 19:14:25 localhost kernel: connection15:0: detected conn error (1020)
Apr 24 19:14:25 localhost iscsid: conn 0 login rejected: initiator error - target not found (02/03)
Etherケーブルを再度SPに接続。自動でRead-only状態から元のRead-Writeに戻らなかったので、デバイスの再マウントを行い元に戻る。
【確認パターン1'】
両SPへのEtherケーブルを抜線後、ホストからiSCSI接続されているディレクトリにはアクセスせずに約15分間放置。
その後、SPへのEtherケーブルを接続し、ホストからiSCSI接続されているディレクトリにアクセス。
該当領域は全く問題なく利用可能。
【確認パターン2】
SPのEtherケーブルを全て抜いた状態でLinuxを再起動。
起動完了後、iSCSI領域がマウントされていないことを確認（マウントされてたら怖い。。）。
その後EtherケーブルをSPに接続し、15分ほど待機。
自動でiSCSI領域を見つけることはなかったので、マウントコマンドを打ってマウントしようとするも、以下エラーによりマウント不可能。起動時に見つけられなかったデバイスは二度と自動認識されない模様。
mount: special device /dev/sdb1 does not exist
しょうがないので、iscsiadm --loginコマンドを用いて再度iSCSIデバイスへログイン後、mount -aコマンドでマウントを行いアクセスが復活。
ayano
280 メッセージ
0
2013年5月26日 18:00
皆様、ご回答いただきありがとうございました。
返信が遅くなり、申し訳ございません。
前回SPリブート後にiSCSIセッションが自動復帰しなかったのは、
Ueharaさんのおっしゃる通り2)に合致していたからだと思われます。
# SPリブートの際に併せてホストのリブートも発生したので、デバイスはないと認識されてしまったのかと。
SPのリブートの時に、「リブートを実行する」などというクリックを押さないと実行されない、とかの
ステップがあると良いのですが・・・
VNX OEのアップグレードなどの時に、File部分のDMのリブート時はあるのですがBlock部分のSPリブートはないんですよね。
やはりNDU delayの時間を長めにしてInitiatorのログインを確認するというふうな手順が望ましいのでしょうか。
今後も起こり得る話ではありますので、いろいろと検証してみたいと思います。