Unmapの必要性
vSANのサポートをしていると時々「容量が足りない！容量を空ける方法を教えてほしい」といった問い合わせを受けることがあります。
Storageのサポートをしていた時からたびたびこういう問い合わせを受けますが、ベンダーだけが知る秘密の方法、みたいなものはないので基本的にはお客様のデータを削除していただくか、Diskを追加して容量を拡張していただく、という形になります。
※お客様の使い方を効率化することで空き容量を捻出できる場合もあると思いますが、基本的にはサポートでなく有償のコンサルタントサービスになるのが一般的と思います。コンサルに金を出すくらいならその金でDiskを買うか、自分で勉強したほうがいい、というのは私の個人的な意見です。
もちろん多くのお客様は上記のようなことはご承知なので、データの削除をしてくれます。ただしVMwareやStorageをよくご存じでないお客様の場合、
「GuestOSでデータを削除したのにvSANの空き容量が増えない」
というお問い合わせを受けることがあります。
vSANの場合は基本的にはThin Provisioningとなりますので、vSAN上の仮想マシンが仮想ディスクを消費するたびに領域が少しずつ割り当てられていく、という仕組みになっています。
一度割り当てられた領域は割り当て済みとなるため、たとえその領域が使用されていなかったとしてもあとから回収することはできません。（※vSAN 6.7U1以前）
vSANにはThinではなくLazy zero-ed Thickのようにすることはできますが、デフォルトはThinなので特に指定しない限り上記のような動作になります。
具体的には以下のような感じになります。
最初に100GBの仮想ディスクを持つ仮想マシンをvSANデータストア上にThinで作成し、その上にOSをInstallしたとします。
Install直後は10GBほどしか使われてないとすると、対象の仮想ディスクのvSANデータストア上での容量も10GBほどになります。
その後、GuestOSにて50GBの書き込みを実施したとします。そうするとvSANデータストアで対象の仮想ディスクに追加で50GB分の容量が割り当てられるので、合計で60GBとなります。
その後、あとから書き込んだ50GBのデータを、GuestOS上で削除した場合、GuestOS上でのDisk使用率は低下しますが、vSANデータストアにおいてはすでに60GB分が割り当て済みなので、対象の仮想ディスクのvSANデータストア上のサイズは60GBのままです。（GuestOS上では10GB分のサイズしか使用してない）
この場合、対象の仮想ディスクに割り当て済みだが、実際には使用されていない容量が50GBあることになります。
この50GBはvSANデータストア上のほかの仮想ディスクですることもできず、かといって対象の仮想ディスクを使用するGuestOSからも使用されてないので完全に無駄な領域となってしまいます。
つまり、vSANデータストア上に作成した仮想マシンにて、上記のような作業を繰り返してしまった場合、実際に使っている量よりも明らかにvSANの使用容量が多いぞ？ということになってしまうわけです。
この問題を解決するためには、GuestOSで使用されなくなった領域をvSANデータストアに返却する仕組みが必要です。
その機能のことをUnmapといいます。
この機能はvSAN 6.7U1からサポートされました。（デフォルトでは無効）
この機能を利用することで、上記のような容量管理上無駄となってしまう領域を再利用することが可能になります。
Unmapの利用方法
Unmapは前述のとおりvSAN 6.7U1からの機能となりますので前提条件として、ESXi/vCenterがともにvSphere 6.7U1以降であり、vsan disk formatも7以上である必要があります。
https://kb.vmware.com/s/article/2145267
https://kb.vmware.com/s/article/2150753
またUnmap機能はデフォルトで無効になっていますが、使用方法はVMware Docから確認できます。
Reclaiming Space with SCSI Unmap
UNMAP/TRIM Space Reclamation on vSAN | vSAN Space Efficiency Technologies | VMware
細かい使用方法や前提条件（仮想ハードウェアのVersionなど）は上記の公式ドキュメントに譲りますが、大体の流れとしては以下のようになります。
- 前提条件を満たしていることを確認
- RVCにて機能を有効化する。
- 各GuestOSごとの設定
GuestOS側での対応について
UnmapのオペレーションはvSAN側から開始するものではなく、GuestOS側から開始するものです。
というとも、vSANデータストア側からは、GuestOS内でどの領域を使用しているのかが不明なため、GuestOSがストレージ側（vSAN）にどの領域を解放してよいのかを教えてあげる必要があるためです。
Widowsサーバの場合、2012以降であればこのUnmapを開始する作業（Trim）がデフォルトで有効になっているため、特に問題はないと思いますが、Linux環境ではちょっとOSや環境に応じて個別の対応が必要になるかもしれません。
※あくまでも私の認識ではありますが、TrimとUnmapは同じ意味であり、OSの文脈ではTrimが使われ、Storageの文脈ではUnmapが使われることが多い印象です。
厳密には異なるかもしれませんが、少なくともこの記事ではTrim＝Unmapとして記載してます。
※※WindowsサーバにおけるTrim設定の確認や動作検証などは以下のブログが参考になると思います。
https://www.idaten.ne.jp/portal/page/out/secolumn/vmware/column52.html
CentOS7 + LVM 利用の場合
私の環境ではLVMを利用したCentOS7でした。
その場合は以下の対応が必要となりました。
lvm.confの編集
LVMの場合は実際にDiskを管理しているのLVMサービスになりますので、LVMにてTrim/Unmapを有効化する必要があります。
具体的には、/etc/lvm/lvm.conf ファイルの
issue_discards = 0
の部分を
issue_discards = 1
にしてあげる必要があります。
fstabの編集
ファイルシステムでもTrim/Unmapを有効化してあげる必要があります。
具体的には、/etc/fstab を編集して対象のファイルシステムにdiscardオプションをつけてあげる必要があります。
私の環境の場合はLVMで作成した/dev/mapper/centos-home をXFSファイルシステムでフォーマットして、/homeとしてマウントしていましたので、fstabには以下のように設定されてました。
/dev/mapper/centos-home /home xfs defaults
この部分に手を加え、
/dev/mapper/centos-home /home xfs defaults,discard
として、discardオプションを足しました。
trimの実行
設定が終わったらTrimを実行してあげる必要があります。
VMware Docによるとfstrimコマンドで実施することが推奨とありました。
/homeのファイルシステムに対して実行したい場合は、以下のような形式で実行します。
※不要なファイルはあらかじめGuestOSレベルで削除しておいてください。
※※設定直後はコマンドが成功しないことがありました。その場合はいったんRebootしてあげてください。
（コマンド）# fstrim -v /home
（出力）/home: 1.7 TiB (1838816620544 bytes) trimmed
※ -v オプションはつけなくてもいいのですが、つけないと何も出力が返ってこないので、私はつけるようにしてます。（なんとなくの安心感があるので。）
Unmapの結果や進捗を確認する
fstrimコマンドを実行した場合、出力は比較的すぐに返ってきます。
もちろん、そんな短時間にUnmap処理自体が完了したわけではありません。
私の理解ではOSはUnmapの処理をStorageに指示するのみで実際の処理はStorage側で実施されているはずです。
vSANの場合もOS側から進捗や結果を確認することはできず、vSANの統計情報や、vSphereの消費容量から確認することになります。
Unmap IOを確認する
vSANのパフォーマンス情報にはUnmap IO情報が個別の項目として存在するのでそこから確認可能です。
Unmap IOは対象の仮想マシンが稼働するホスト上で記録されます。
つまり、Unmapを実行した仮想マシンAが、ESXi Bで稼働していた場合は、ESXi BのvSAN統計情報を確認する必要があります。
vSphere Client（HTML5）にログインし、ホストとクラスタのViewから、ESXi Bを選択し、監視→vSAN → パフォーマンスから確認できます。
Unmap前の情報
以下がUnmap前の統計情報です。UnmapのIOPSがずっとゼロであることがわかります。
Unmap後の情報
以下がUnmap後の情報です。Unmap IOPSが増えており、同じタイミングでTrim/Unmap スループットが記録されています。
Unmap IOがあるうちはUnmap進行中、Unmap IOがなくなったら完了、と言えそうです。
Unmap結果について
Unmapの結果については、vSphere Client(HTML5)から、vSANの空き容量が増えていることを確認したり、対象の仮想マシンがデータストア上で消費する容量が減っていることで確認できます。
今回はキャプチャをとり忘れてしまったのですが、実際にやってみる際は事前と事後の容量を比較してみるといいと思います。
Unmapされない？
きちんと設定したはずなのに、想定通りにUnmapが走ってくれない場合もあると思います。
対象の仮想マシンでSnapshotがある場合は、Unmapしたい領域をSnapshotが使っていて解放されないことがあるようです。
Snapshotがない場合でも、Replicationなどのソリューションが介在している場合、うまく動作しないことが考えられます。
私のラボ環境ではDell EMCのRP4VMでReplicationを行っている仮想マシンに関してはUnmapが動作しませんでした。
詳細なロジックや追加検証にて確認すべき余地はあるため、確定情報ではないですが、Unmapがうまくいかない場合は、SnapshotやReplicationなどの機能をOffにしたり削除したりといった切り分けが有効化と思います。
いかがでしたでしょうか。vSANは70％程度の容量使用率が推奨されている関係もあって、いきなり容量が足りなくなる、ということはほとんどないとは思いますが、空き容量が少なくなってくると、vSANの動作に影響が出たり、パフォーマンスが出なかったり、障害時に可用性が維持できないなどの問題が生じます。
現在空き容量でお困りではないユーザであっても、使用していない領域を再利用できるに越したことはないと思います。
Unmapは地味に大事な機能だと思いますので、vSAN 6.7U1以前のVersionをお使いの場合は、ぜひともUpgradeをご検討ください。
このブログの内容が運用や管理の助けになれば幸いです。
