以前にも記載していたが、格安SSDでRAID-Z2を組んで動作させていたが、色々な動作が遅くなってしまって、実質使い物にならない状態に陥った。その時の調査方法や、対応方法について記録しておく。
そもそもDRAMレスSSDでのTruenasの使用は推奨されていない。MX500やEvo870などのDRAM付きの物が推奨されている。とはいえもう買って組んでしまったのでしょうがない。
2台、2.5インチSSDでTruenasを動作させていたが、1台はN54Lにて、Boot-poolをUSB-SSDにて動作させていたが、いろいろと調べると下記問題点が挙げられた。
①最近のTruenasは、Boot-poolにも起動中に読み書きが発生するのでSSDを使用することが
求められている(起動後にBoot-poolにUSB使用とのメッセージを無視しながら使っていた)
②ZFSのバージョンが2.3.4となっており、Boot-pool、SSDに負担がかかる状況となったらしい
③DRAMレスのSSDはそもそも推奨されていない
SSDへの負荷を軽くするなどチューニングを行ったが解決しないこととなり、思い切ってすべてのSSDをSecureEraseして、RAID-Z2を組みなおすこととした。この際、②のZFSのバージョンが古いものがよいが、①の事象も考慮するとTruenasで行くことが果たして正しいのか疑問となり、さらに思い切って、Xigmanasに切り替えることとした。
幸いにデータはバックアップを取っていたので、思い切ることができた。
2台目については、Boot-poolはSSDを用いているので、上記①、②の問題はないが、やはり③の問題が残っている。また④としてLSI8207-8iを使用しているが、こちらが熱暴走している可能性が否定できない。
④の問題を回避するために、ケースの蓋を取り扇風機を当てながらバックアップを取ろうとしたところ、はじめは順調だったのだが、だんだんと読み出し速度が数MBに落ちてしまい、実質バックアップができない状況になってしまった。
念のため、SATAのリンク速度を1.5Gbpsに制限させて動かしてみたが、状況に大きな変化はなかった。ちなみに1.5Gbpsへの制限は、lsiutilを使って13を選択して対応した。
バックアップを取っている状態で、iostat -x 3で状況を見てみると、特定のSSDだけ、r_awaitの時間が、数秒かかっている物があった。
シャットダウンして、SSDを引き抜きこちらもSecureEraseを行い、元に戻してResilver動作をさせることで何とか回避できている。
Resilver中に、再度速度が異様に遅くなる事象が発生した。iostat -x 3で確認したところ、もう1台異様にr_awaitの時間が数秒掛かっているものがあった。こちらも同様にSecureEraseをかけ、Resilverさせて対応した。
RAID-Z2は2台までの故障ならデータは壊れないが、もう1台NGとなるとデータが壊れてしまう。実際Resilver中にチェックサムエラーが発生し、いくつかのファイルがお亡くなりになってしまった。
色々調べてみると、DRAMレスではマッピングの量が増えると今回のような事象が発生するようだ。素直に、DRAM付きのSSDを使用するしか方法がない。
マッピングの量が増えないように、定期的にSecireEraseとResilverを走らせるしか対応方法はないものと思っている。
Resilver中にSSDの3台目がr_awaitの値が異常になってきて、打つ手がなくなったと思ったが、やけくそになって、zpool trim pool名でtrimの発行を行ったところ、r_awaitの値が嘘のように改善した。定期的にSecureEraseとResilverするしかないと思っていたが、Trimの発行で大きく改善することが分かった。もっと早く試すべきだった。
最終的にはもう1台のSSDにREAD/WRITEエラーが発生し、Resilverは失敗した結果となってしまった。こちらのサーバーも、すべてのSSDをSeureEraseして組みなおすこととした。
複数の問題が絡み合って、問題が発生していたと思われるが、反省点として以下の手順で、対応っすればよかったと思う。
1) lsiutilの20-12で、PHYのエラー状況を確認する。
2) iostat -x 3を実行して、%utilや、r_awaitの数値が異常でないかを確認
3) zpool trim プール名で、Trimを実行して、iostatの結果に反応がないか確認する
4) zpool scrub プルー名で、データの整合性を確認する
5) 別のディスクへバックアップを取る
6) SSDを定期的に、SecureEraseしてマッピングテーブルが複雑にならないようにする
結果的に、何があったとしても動作しているSSDをSecureEraseしてResilverを走らせるような手法は絶対やってはいけないことと思われ、少なくとも、5)までの実行を行い、データが保全されていることを前提でやるべきであった。
今回LSI9207-8iが熱暴走していることが否定できないため、40mm角の厚み20mmのFANを結束バンドで固定して様子を見ることとした。残念ながらLSI9207-8iの温度をコマンド上で読み取れないため、効果があるのかないのかは不明ではある。
コメント