vSAN の Thick → Thin 変換による消費容量削減検証


概要

仮想マシンのストレージポリシーを Thick プロビジョニングから Thin プロビジョニングへ変更したとき、vSAN データストアの使用容量は本当に減るのか。vSphere Cluster 8.x の実機で、Snapshot が絡んだ場合の挙動まで含めて検証しました。

VMware vSAN では、仮想マシンのディスクを「Thick(領域を確保する)」で作るか「Thin(使った分だけ消費する)」で作るかを、ストレージポリシーの Object space reservation で切り替えられます。すでに Thick で運用している仮想マシンをあとから Thin に変えたい、というのは容量が逼迫してきた環境ではよくある要望です。

ただ「ポリシーを変えれば本当に空き容量が戻るのか」「Snapshot を取っているとどうなるのか」「変更後すぐに数字へ反映されるのか」といった点は、実際にやってみないと分かりにくい部分です。そこで vSANクラスタ上の VM を対象に、一連の操作と容量の変化を追いかけてみました。

先に結論

Thick → Thin へポリシー変更した結果、vSAN データストアの使用容量は 4.86TB → 4.41TB へ約 0.45TB 減少しました。仮想マシン単体の VM Used Space で見ると 620GB → 124GB(差分 約 496GB)。FTT1(ミラー)構成のため、物理消費ベースでは約 500GiB 相当の削減に相当します。ただし数値が反映されるまでには VM の PowerCycle と 1〜2 時間の待機が必要でした。

検証環境

今回はVxRail に標準で存在する VxRail Manager VM を検証対象にしています。特別な仕込みは行わず、既存の仮想マシンのストレージポリシーを切り替える、という運用でありがちなシナリオをそのまま再現しました。

  • プラットフォーム: vSphere/vSAN 8.x
  • ハードウェア: Intel Skyelake CPU サーバ 3 ノード構成
  • 耐障害性: FTT=1 / RAID-1(ミラーリング)
  • 対象 VM: 仮想マシンディスクサイズ 288GiB、GuestOS 実使用 約 39GiB

検証の流れ

「作業前の状態確認」→「Snapshot 取得と Thin へのポリシー変更」→「Snapshot 削除とポリシー再適用」という順に、各ステップで vSAN の使用量・VM の使用量・コンプライアンス状態を記録しました。

  1. 作業前の状態を記録
    仮想マシンと vSAN データストアの使用量を確認
  2. VM PowerCycle で挙動確認
    10 分ほど放置して観察。VM 側は微減するものの、vSAN データストア側は PowerCycle 前後で変化なしでした。
  3. Snapshot を取得し、Thin ポリシーを適用
    テスト用に Object space reservation を「Thin provisioning」に設定したポリシーを作成し、対象 VM へ適用します。
  4. Snapshot を削除
    変更が確定したのち Snapshot を削除します。
  5. ポリシーを再適用
    Snapshot 削除直後は一時的に Out of Compliance になるため、ポリシーの再適用を実施(放置していても周期チェックで解消されます)。
  6. PowerCycle 後に最終確認
    PowerCycle して 1〜2 時間経過後に、ストレージの数値がようやく反映されました。

結果:どれだけ減ったか

削減量は 2 つの視点から確認しました。ひとつは vSAN データストア全体の使用容量、もうひとつは対象 VM 単体の Used Space です。

0.45 TB
vSAN データストア使用量の削減
(4.86TB → 4.41TB)
496 GB
VM Used Space の削減
(620GB → 124GB)
~500 GiB
FTT1 ミラー換算の理論削減量
(249GiB × 2 相当)

図1: 作業前後の vSAN データストア使用量(TB)と VM Used Space(GB)の比較

削減量の裏取り

対象 VM の仮想ディスクサイズは 288GiB、GuestOS の実使用は約 39GiB です。Thick では 288GiB を確保していたものが、Thin にすることで実使用相当まで縮むと考えると、単純計算で 288 − 39 = 249GiB が解放される計算になります。各種オーバーヘッドを加味すると実際にはもう少し多くなります。

本環境は FTT1 のミラー構成なので、データは 2 重に保持されています。したがって物理消費ベースでは 249GiB × 2 ≒ 約 500GiB の削減となる計算で、これは実測の vSAN 使用量差分(0.45TB)や VM Used Space 差分(496GB)ともよく整合しました。

指標作業前作業後差分
vSAN データストア使用量4.86 TB4.41 TB-0.45 TB
VM Used Space620 GB124 GB-496 GB
プロビジョニング済みディスク288 GiB288 GiB変化なし
GuestOS 実使用量約 39 GiB約 39 GiB変化なし

運用上の注意点

数値の反映にはタイムラグがある

ポリシー変更やSnapshot 削除の直後は、vSAN・VM の使用量に変化が見えませんでした。VM を PowerCycle し、さらに 1〜2 時間経過してから確認したところ、はじめて数値(588GB → 124GB)が反映されました。「変更したのに減っていない」と焦らず、しばらく待って再確認するのが正解です。

VM PowerCycle 単体では vSAN データストアの値は変わりません。あくまで Thin 化した領域が実際に解放され、それがメトリクスへ反映されるまでに時間を要する、という挙動です。

Snapshot 削除後は一時的に Out of Compliance になる

Snapshot を削除した直後、対象 VM は一時的に Out of Compliance 状態になります。これに対してはポリシーの再適用操作を行えばすぐ解消できますが、放置していても vSAN が周期的にコンプライアンスをチェックするため、待っていれば問題なくコンプライアンス状態へ戻ります。

Snapshot が存在するタイミングでの変更

変更前後で Snapshot を作成した場合の影響も観察対象としています。Provisioned Space と Used Space の関係を追うことで、Thin 化の効果が Snapshot のチェーンにどう現れるかを確認しました。Snapshot が残っている間は差分ディスクが容量を保持するため、削減効果を正しく評価するには Snapshot を削除してから計測するのが確実です。
逆に言えば、Snapshotがある状態でThick->Thinの変更を実施してもデータストアの空き容量増加の効果は薄いです。

まとめ

VxRail(vSAN)環境で仮想マシンを Thick から Thin に変換する運用は、実際に有意な容量削減効果があることが実測で確認できました。今回のケースでは 1 台の VM で vSAN データストアベースで約 0.45TB、FTT1 ミラー換算で約 500GiB の解放につながっています。

一方で、効果がメトリクスに反映されるまでには VM の PowerCycle と数時間の待機が必要で、Snapshot 削除に伴う一時的な Out of Compliance も想定しておく必要があります。容量が逼迫した環境で Thin 化を検討する際は、こうした「反映までのタイムラグ」と「コンプライアンス状態の一時変化」を運用手順に織り込んでおくと安心です。

コメント

コメントを投稿

このブログの人気の投稿

vSwitchにSTPが不要な理由

イメージ
  ** 知っている人にとっては当たり前の内容です**     ESXiは多くの場合、冗長構成をとるために二つ以上のNICを利用し、それぞれ単一、もしくは別個の物理スイッチに接続されていると思います。 ESXiの物理NICはuplinkまたはvmnicとよばれ、ESXi内部にある仮想スイッチ（vSwitch）につながっています。 vSwitchはL2SWとしての役割をするため、物理スイッチをESXiの接続はスイッチ間接続となります。   図１：ネットワークトポロジ     vSwitchが物理スイッチと同等の動作をすると仮定した場合、この構成はループに相当します。 L2レベルでループがある場合は、ブロードキャストストームなどの問題が発生するためにSpanning Tree Protocol（STP）を設定する必要（最近では必ずしもそうとは言い切れないようですが。。。）があります。   ではvSwitchの場合でもSpanning Treeに参加する（ネットワークは専門外なので表現が間違っていたらすみません。。。）必要があるのでしょうか？ 表題からもわかるように答えはNoです。 L2ネットワークでBPDUと呼ばれるパケットをやり取りすることで Spanning Treeが構成されますが、実際に、vSwitchではこのBPDUをDropしますので、vSwitchのUplinkがBlockされることはありません。   ではなぜ、vSwitchではトポロジ的にLoopであるにもかかわらずSpanning Treeが不要なのでしょうか？Loopによる問題は発生しないのでしょうか？   実はvSwitchはFloodingが必要な通信に対して特殊な動作をします。 その特殊動作のため、トポロジ的にLoopであっても問題は発生せず、Spanning Treeに参加する必要がないのです。   たとえば、ARPなどの外部からのブロードキャストフレームをuplink経由でvSwitchが受け取った場合、vSwitchに接続されるVMに対してはフレームを転送しますが、ほかのUplinkに対してはフレームを転送しません。   下図ではUplink1からBroadcast Packetを...
続きを読む

vSAN OSA更改時の考慮事項

  この投稿は、 vExperts Advent Calendar 2025 の 8 日目です。 文字ばかりですがご容赦ください     この記事の概要 VCF9 のリリースによって vSAN OSA の一部の Hybrid 構成が Deprecate になった。 そのため、 OSA 環境の更改においては ESA へのトランジションの検討が盛んになっている。 一方で、 ESA へのトランジションにおいては、 HCI のメリットの一つであるシームレスな更改手法（玉突き方式）がつかえない、といった 考慮事項も存在する。 本記事では、 vSAN クラスタの更改時によくある考慮事項を紹介する。   想定既存環境 以下のようなサンプル環境の更改を想定する   vSAN OSA クラスタ（ vSAN Ready Node 、クラスタ内の全ノードが更改対象） ライセンスはリテール版を利用し、 HW と更改時期がずれているため、更改対象ではない。 外部ストレージは無し TOR スイッチの HW 更改の対象に含める   ※ OEM ライセンス利用時や、 vSAN Ready Node より上位となる専用アプライアンスを利用している場合、 ライセンスや保守サービスにかかわる考慮事項が追加され、より複雑となることがあるが、本記事では考慮しない。   更改パターン   移行方法とストレージアーキテクチャをベースに大別すると以下の 4 パターンが考えられる。   OSA 玉突き更改 OSA 新規クラスタ ESA 新規クラスタ 分離型新規クラスタ（ vSAN MAX or 外部ストレージ）   更改パターンを選択する際の考慮事項を次項に列挙する     考慮ポイント 実績と安定性 OSA と外部ストレージ構成は実績や安定性の観点で申し分ない ESA も 2022 年にリリースされて以来、大きな不具合もなく現在に至る印象があるが実績の面では OSA や外部ストレージが勝る トラブルシューティングに関しても OSA/ ...
続きを読む

ESXi に DNS サーバを何個まで登録できるか

イメージ
ESXi の DNS サーバの最大登録可能数を調べる vSphere 構築経験のある多くの方は2つまでとお答えになるかもしれない。 なぜならば、DCUI や vSphere Client から設定した場合、Primary DNS と Alternative DNS の2つまでしか設定できないからだ。 GUI から設定する場合、苦し紛れにカンマ区切りなどで3つ以上登録しようと試みても無駄である。GUI でエラーになってはじかれるだけだ。 ならば、CLI はどうか。 /etc/resolv.conf に手動で追記していくだけであればストレージの許す限り記載することはできるだろうが、 この方法は当然ながら標準的な手順ではない。 esxcli を利用して DNS を登録することも可能である。具体的には以下のコマンドを利用する esxcli network ip dns server add -s <ip_address> 上記のコマンドを利用してどこまで登録可能かを試してみた。 具体的には以下のコマンドを用いて255個のDNSサーバを追加してみた for i in `seq 1 255`; do esxcli network ip dns server add -s 192.0.2.$i ;done なお、本ブログで記載される IP Address は例示用に予約されたものであり、RFC5737 から拝借している。 結果として、少々時間はかかるが登録自体は問題なく成功した。 実環境においてこれほど多くの DNS の登録をすることはあり得ないので、事実上制限なしと考えられる。 なお、参考のために他ベンダーも含める形で DNS 登録数の最大数を調べたところ、2 か 3 にしているところが多いようだ。 DNS を大量に登録した際の動作を調べる DNS クエリのタイムアウト時間：5 秒則 ESXi の DNS Client は最近の systemd-resolved などではなく、レガシーなソフトウェアであるため、 resolv.conf の上から順番に問い合わせていき、問合せ先の DNS に到達できなかった場合に次の DNS サーバに問い合わせる動作になる。 次の DNS サーバに問い合わせる条件はあくまでも到達できなかった場合であり、到達できた...
続きを読む