新年早々、ストレージサーバのディスクが一時的に行方不明になって、いろいろ止まった。
我が家の構成は、こんな感じ。
zfsストレージサーバのハードが適当すぎる関係で、時々ディスクを見失ったりする。
- FreeBSD zfsストレージサーバ
- VMware ESXi (NFSでストレージサーバに接続)
- FreeBSDサーバ群 (VM)
さくっとdetached判定してくれればいいものの、コマンドを発行してタイムアウトを待つので、ESXiが待たされ、VMが待たされる。
VMもどうでもいい処理なら適当にコケるだけですむところが、swapアクセスが(mptタイムアウトで)コケると止まってしまう。
対策として以下を考えた。
- (VMの)mptのタイムアウトを伸ばす。
死ななくなるけど固まる。
ZFSはunderlying diskを永遠に待つので、関係するプロセスは固まる。
UFSは(VMの場合はmptなので)数回のリトライの後コケるので、いろいろよろしくない。 - (VMの)daのタイムアウトを伸ばす。
mptドライバはdaを作るので、da 側のタイムアウトを伸ばしてやる方法。これも死ななくなるけど、やっぱり固まる。
kern.cam.da.retry_countやkern.cam.da.default_timeoutあたりを変えてやればいい。 - (ストレージの)daのタイムアウトを縮める。
固まるのが気になるなら早くあきらめさせればいいので、ストレージサーバから実ディスクへの書き込みでさっさとエラーにしてしまえばいい。
というわけで、ストレージサーバのdaタイムアウトを縮めてみる。
[alraune:/] root# sysctl kern.cam.da.default_timeout=10 kern.cam.da.default_timeout: 60 -> 10 [alraune:/] root# sysctl kern.cam.da.retry_count=1 kern.cam.da.retry_count: 4 -> 1
ちなみにデフォルトは上で見えているとおり60と4だそうですよ。
man da より引用:
kern.cam.da.retry_count This variable determines how many times the da driver will retry a READ or WRITE command. This does not affect the number of retries used during probe time or for the da driver dump routine. This value currently defaults to 4. kern.cam.da.default_timeout This variable determines how long the da driver will wait before tim- ing out an outstanding command. The units for this value are sec- onds, and the default is currently 60 seconds.
さて、これで期待通りの動きになるか、それともタイムアウト多発でRAIDが維持できなくなるか。数日観察。