NetApp(NFS)+VMware環境での話。
同一ボリューム内に複数の仮想マシンを作成した場合、
仮想マシンの削除には注意が必要です。
具体的には
「削除するVMの容量分、ボリュームに空き容量を持っておく必要がある」
という事に注意ください。
※NetApp上でSnapshotを取得していないボリュームであれば対象外ですが少数かと思います。
例えばNetApp上に300GBのボリュームがあるとします。
※Snapshotを取得した状態のボリュームとします。
NetAppのステータスを確認してみます。
NetApp > df -h
Filesystem total used avail capacity Mounted on
/vol/pikkoro/ 300GB 200GB 100GB 66% /vol/pikkoro/
/vol/pikkoro/.snapshot 10GB 1GB 99GB 10% /vol/pikkoro/.snapshot
このボリュームはESXiにマウントされおり、usedの200GBは以下のVMにより消費されています。
「pikkoro1-VM」(100GB)
「pikkoro2-VM」(100GB)
この状態で「pikkoro1-VM」を削除してみます。
しばらく時間を置いてNetAppのステータスを確認してみます。
NetApp > df -h
Filesystem total used avail capacity Mounted on
/vol/pikkoro/ 300GB 200GB 100GB 66% /vol/pikkoro/
/vol/pikkoro/.snapshot 10GB 101GB 0GB 1001% /vol/pikkoro/.snapshot
削除したVMの容量分スナップショット領域に増えています。(←わかる)
しかし、usedが減っていません。(←???)
snapshot領域から溢れている容量は実領域を侵食してしまいます。
しかもステータス上は確認できません。
先ほどの「df -h」で見える「/vol/pikkoro/」のステータス、実際は以下のようになっています。
Filesystem total used avail capacity Mounted on
/vol/pikkoro/ 300GB 291GB 9GB 97% /vol/pikkoro/
.snapshot領域から溢れた91GBが消費されているので、実際は残り9GBしか無い事になります。
気がついたらVMが止まっているといった状況が想定されます。
対処法ですが、事前にSnapshot(SnapMirror用のSnapshotも含む)を全て削除すれば回避することができます。
…が、バックアップで利用しているケースがほとんどかと思いますのでバックアップを飛ばす事になります。
SnapMirrorを構成している場合は初期転送が必要となってしまいさらに現実的ではありません。
※VM削除後にSnapMirrorのUpdateを実行すれば初期転送は必要ありません。
なので最初に申し上げた通り
「削除するVMの容量分、ボリュームに空き容量を持っておく必要がある」
という結論に至りました。
これ、結構痛い目見た人もいるんじゃないでしょうか。。。
0 件のコメント:
コメントを投稿