ZFSの中でも一度オンにしてしまうと生涯呪われてしまい成仏できなくなる機能、それが重複排除（Deduplication）です。
ZFSで dedup=on と設定した状態では、書き込み時に重複排除に使用する DDT という情報をメモリ上およびメディア上に保持するようになります。普通に読み書きしている範囲ではそれほど困らなかったりもするのですが、曲者なのはDDTが付いてるデータを削除するとき。削除対象データのDDTをメモリにロードしきれないとZFSが沈黙してしまったりするので、システムメモリ8GBの環境で1GBのファイルを削除するのもドキドキです。
DDTが読み込めずにシステムが沈黙してしまっても、システムを再起動してプールをインポートしなおせば数時間の末に何とかトランザクション完了してオンラインになってくれますし、そんなことを過去に何十回やっててもデータロストしたことがないZFSは偉いです。
しかし、今回は...
「zfs destroy array2/backup」
→メモリ不足で沈黙
→再起動
→インポート中にメモリ不足で沈黙
→再起動
→インポート中にメモリ不足で沈黙
アッー！今回こそダメかも！ と思いながら復旧することにしました。
■ 効くかどうかわからないけど、とりあえずシステムのアップデートを
これまで運用してきたカーネルは OpenIndiana 151a7 でした。たぶんこのカーネルに、メモリ不足になるとZFSが無限ループに墜ちるバグがあるわけなので、直っていることを期待してアップデートしておきます。
■ ESXi の機能でメモリ容量を全力オーバーコミット！
この OpenIndiana の ZFS 環境は当初はXen上の仮想マシン→物理（DRAM 4GB）→ESXi（仮想RAM 3GBから現在は16GBに増量）と、当初より相当のメモリ量を割り当てているのですが、たかが4GBほど容量を消費していた ZFS ファイルシステムすら削除できないようです。
ESXi側からメモリ消費のグラフをみてみると、たしかにメモリは大量に消費しているものの、一度書き込んだメモリは殆ど触っていないように見えるので、思い切って全力でオーバーコミットしてみることにしました。
32GB。そう、 ESXi 5 の無償ライセンス 1ホスト分で利用できる最大メモリ量です。 VMware ではメモリのオーバーコミットができるので、実装 8GB でも 16GB でも、仮想マシンに対してもっと多くのメモリがあるように見せかけられます。なお、該当ゲストのページングファイルは ioDrive2 上に置きました。
32GB で足りない場合は VMware 以外でオーバーコミットするか VMware 様にお布施するか、もしくは VMware ESXi を適当な USB メモリにインストールして評価モードでオーバーコミットしましょう。
■ インポートできた
メモリ容量さえなんとかしてあげればインポートできるという確信は持っていたのですが、数時間のインポート処理の末ついにインポートが完了しました。 ESXi 側の仮想マシン情報を見るかぎり、今回は19GBほどメモリがあればインポートできたようです。
4GBの ZFS ファイルシステムを destroy しただけなのに……。
4GBの ZFS ファイルシステムを destroy しただけなのに……。
4GBの ZFS ファイルシステムを destroy しただけなのに……。
まあ、とはいえ、一度インポートが成功した＝残留トランザクションは完了したので、もう今後は（また同じような状態に陥らなければ）オーバーコミットをしなくても起動できます。
再起動してみたら、インポート完了時点でのメモリ消費量は1.9GBにまで落ちていました。 ZFSェ...
■ というわけで
ZFSの重複排除は怖いので使わないようにしましょう。使ってしまったら迂闊にデータを消さないようにしましょう。
けっこう大変な思いを度々しているので、 dedup=off な新天地へのマイグレーションを検討中
0 件のコメント:
コメントを投稿