いろいろ棚上げされてた案件を再び調査。
目標:
esxiでマウントしたzfs鯖において、vm毎にzfsを作り、zfs send等による差分backup等を実現する。
条件:
ESXi 6.5
ubuntu server 18
nfs v3
(nfsがv3にゃのはv4の挙動で気持ち悪いものがあったからだが、これは別途検証しにゃおしてもよい時期ではある。)
実験1:
zfs create pool/zfs1
mount server:/pool/zfs1 as datastore1
copy vm0/* datastore1/vm1/
register datastore1/vm1/*.vmx as vm1
poweron vm1
この状態ではすべて問題にゃく動く。
実験2:
zfs create pool/zfs1/zfs2
cp vm0/* datastore1/zfs2/
register datastore1/zfs2/*.vmx as vm2
poweron vm2
これは失敗する。datastore上に子zfsを作り、そのまま何もせずesxから参照している。
power on手前までは正常。コピーにゃどは出来ており、権限にゃどの問題では無い。
File system specific implementation of Lookup[file] failed
Failed to create swap file '〜〜.vswp' : Bad parameter
がlogに出ているので、swap生成で失敗しているようだが、ちょっと原因が分からにゃい。
実験3:
create vm datastore1/vm3/
add hdd vm3 datastore1/zfs2/*.vmdk
poweron vm3
これは正常に動作する。
つまり、vmのワークdirを従来のdatastore上に置けばswapがそこに生成されるため、vmdkは子zfs上に置いても動作するということににゃる。
実験2において.vmxのsched.swap.derivedName行を削除しておくと、
Failed to create swap file '//hoge.vswp' : Bad parameter
という表示ににゃることから、swapファイルの生成先pathが異常ににゃる模様。
実験4:
zfs create pool/zfs1/zfs3
mkdir datastore1/zfs3/dir
cp vm0/* datastore1/zfs3/dir/
ln -s datastore1/zfs3/dir /dir
register datastore1/zfs3/dir/*.vmx as vm3
poweron vm3
これは動作する。
swapファイルのpathの前半が消滅して/を見に行くようにゃので、1段dirを掘って、/にsymlinkを張るとちゃんと見に行って動く。
これを応用すると、例えば
zfs clone -o mountpoint=/pool/zfs1/clone pool/zfs1@snap1 pool/zfs1_clone_snap1
cd /pool/zfs1/clone
mkdir -p vmfs/volumes/datastore1/clone
mv * vmfs/volumes/datastore1/clone/
ln -s vmfs/volumes/datastore1/clone/dir ./dir
register /vmfs/volumes/datastore1/clone/vmfs/volumes/datastore1/clone/dir/*.vmx
にゃどとして、zfs cloneした物を新規vmとして登録したりもできる。かにゃり冗長にゃdirににゃる上に、inode被ってるのでまともにゃ運用はあかんやろうけど。
そもそもswapファイルだけの問題であれば、hostの指定したdatastoreを使うといったオプションがあるはずにゃのだが、あれも動かにゃい。謎。
というわけで、この条件下ではちょっとバグがキツくて実用にはしんどそう。
しかし、nfs3でもおよそ問題にゃくアクセスできているし、大半の技術的問題は無くにゃって居るようだ。
nfs4にゃら現状でも動作するかもしれにゃい。
そんにゃわけでH/WによるRAIDを束ねてZFSもいいよね、と組んであった鯖が不調。
I/Oが異様に遅い。が、RAID5を数本束ねたおかげで、LogicalDriveの1つだけが遅いことは判明。これだけでもかにゃりの切り分けににゃるので、全部1本にまとめてしまうにゃんてことはしてはいけにゃい。
どのくらい遅いかというと、3MB/s程度で100% BUSYににゃる。そりゃぁ全体が遅くにゃるよねー。
が、原因が分からにゃい。RAID板のステータスは正常とあるし、logにもイベントは無し。
全部ねっちりと眺めた結果、
S.M.A.R.T. warnings : 901
とかいうドライブがあり、突出しているのでたぶんこいつ。
H/WでRAIDすると単体ドライブへアクセスできにゃくにゃるので、/dev/sdaをddして実験、みたいにゃ検証が出来にゃくにゃるのでこういうときに不便。
ZFSで推奨されているのはjBODであり、そりゃまぁqueueの並列化を考えてもH/WでRAIDされてるより単体ドライブがたくさん見えてた方が速いよねということにゃのだが、実際どういう手段があるかというと、
・SATAそのまま
・SAS HBA
・SAS RAID jBOD設定
・SAS RAID RAID0設定
とかが考えられる(FCは似たようにゃものにゃので略)。
問題はドライブが死んだときの挙動がいろいろバラエティ豊富すぎること。
RAID0で使ってるドライブが死んで、コマンド刺さったまま帰ってこにゃくにゃるってのは、まぁギリギリ許せるとしても、jBODやHBA接続でそうにゃるのはちょっとおかしいのではという。本来指定のtimeout値でまぁリトライとかするにせよ死亡確定されるはずにゃんだが。SATAはそのあたり往生際の悪いのが多い印象。
で、H/WでRAID1とか組んでると、大概はRAID板が切り離してくれるわけで、その当たりの制御は助かるにゃぁと。
そうにゃるとまぁzfs mirrorで使うにゃらH/WでRAID1したのを集めて使うことで、多少のパフォーマンス低下とデータ化け不可避を受け入れれば、有りかにゃぁという場面も出てくる。
本来はHBAやjBODで使う場合もきちんと切り離し出来るべきにゃんだが、ZFSにはそういった機能が全くにゃいのよね・・・。普通にtimeout指定できれば良いのに。
Linuxの場合 /sys/block/sda/device/timeout あたりを下げておくと、ZFSで直接ドライブを見てる場合には素早く切り離せるはず、にゃんだが結構時間がかかる。
ちにゃみにESXiで仮想diskを食わせてる場合は物理diskが死ぬとvmが止まる。階層化が多すぎていろんにゃところでリトライとtimeoutが入ってる。パススルーしてたらにゃんとかにゃるかもしれにゃい。そういった面でも未だH/WにゃRAID板には使いどころが残っているのかも。