ad1

2022年12月2日金曜日

vSAN データストアの容量サイジングの考え方 (vSAN 6.7 / vSAN 7.0 / vSAN 8.0)

4年前の vExperts Advent Calendar で vSAN の各バージョンにおけるストレージ消費量を比べましたが、仮想マシンのデプロイ方法やストレージポリシーによってストレージがどの様に消費されるかは前回一通り確認しましたが、基本ルールは今のバージョンでも変わっていません。

今回は前回の続きのような感じで 過去に VMTN や Dell Community で vSAN のサイジングや容量監視に関連した質問と回答のポイントをまとめ、最新バージョンの vSAN における容量サイジングの考え方や推奨をご紹介します。

本記事は年末恒例の vExperts Advent Calendar 2022 の二日目を担当しております。

4年前の記事はこちら

本投稿の見出し

まずは vSAN Ready Node Sizer を電卓代わりに使おう

vSAN Ready Node Sizer <https://vsansizer.vmware.com/> は利用していますか？

2年前に vSAN 7.0 に対応した際にデザインが一新され、現在は vSAN 7.0u3 まで対応しています。細かい使い方などは 2年前に記事にまとめたのでそちらを参照して下さい。

この vSAN Ready Node Sizer、vSAN 8.0 の ESA への対応に合わせて大幅にデザインも進化します。

詳細は正式リリース後にあらためて使い方記事をまとめますが、ざっくりサイジングの強力なツールである vSAN Quick Sizer (Reverse Sizer) がかなり使いやすくなっています。


以前 VMTN に寄せられた質問と回答

vSAN Quick Sizer のもう一つ重要な使い方として現在はシステムメモリのオーバーヘッドを算出する唯一のツールでもあります。

従来 vSAN 環境のメモリサイジング(システム利用量)は KB : 2113954 で紹介されている複雑な計算式を利用して算出しましたが、バージョンや構成毎に複雑な計算が必要でした

2022年9月に KB が変更され、計算公式の公開はなくなり、今後は vSAN Quick Sizer (Reverse Sizer) を利用した確認へと内容が変わりました。

※ 2022年12月現在、KB の言語を日本語に変更すると従来の計算公式が参照可能ですが Quick Sizer を利用したほうが簡単で確実です。



本投稿の以降でご紹介するサイジングの考え方を抑えつつ、vSAN Ready Node Sizer を活用していただくことで、確実なサイジングが出来るはずです。

vSAN データストアの容量オーバーヘッドの考え方

vSAN をサイジングする際に以前は空き容量 20% 〜 30% を考慮するスラックスペース (Slack Space) という考え方でした。

一部の公式ドキュメントにはこの記載が残っていて紛らわしいのですが、現在 (正確には vSAN 7.0u1 以降) はスラックスペースという考え方・用語は利用しておらず、より明確な言葉で vSphere Client からも確認できる様になっています。

以前 VMTN に寄せられた質問と回答

それが上記の vSAN データストアの容量予約とアラートの UI にもある OR と HRR です。

  • 操作の予約 : (Operations Reserve : OR) - 必須
    vSAN のシステム用領域 (メタデータやポリシー変更などシステム処理で利用される領域) - 物理 (RAW) 容量の 10% が予約される
  • ホスト再構築の予約 : (Host Rebuild Reserve : HRR) - 任意
    ESXi ホストが1台停止した場合でも仮想マシンデータが再構築 (リビルド) 出来る様に1 ESXi 分の容量を予め予約 - N 台の ESXi で構成された vSAN クラスタの場合は全体の 1/N の容量が予約される
    ※ 最小構成台数の vSAN (3台構成や 2Node vSAN) では HRR は設定できますが実際は意味がないので通常は無効とする

"予約とアラート" で OR、HRR はそれぞれ予め予約しておくことが強く推奨されます。
※ OR の分も容量が食いつぶされるとシステム全体が止まるリスクが高まります。

重要な点は、OR は RAW の 10% が固定で確保され、HRR は ESXi 台数に応じて 1/N の容量が可変するということです。
4台のクラスタであれば 1/4 の容量が HRR としてのオーバーヘッド、16台のクラスタであれば 1/16 とオーバーヘッドのインパクトが薄まります。

vSAN OSA (従来型の Cache + Capacity の 2Tier vSAN) ではざっくり以下のオーバーヘッドサイジングになります。

ESXi ホスト台数毎の容量予約の考慮値 (VMware Core Tech Zone : vSAN Design Guide より)

  • 4ノードクラスター ：10％ OR + 25％ HRR = 合計予約容量 約 30％
  • 6ノードクラスター ：10％ OR + 17％ HRR = 合計予約容量 約 27％
  • 8ノードクラスター ：10％ OR + 13％ HRR = 合計予約容量 約 23％
  • 12ノードクラスター ：10％ OR + 8％ HRR = 合計予約容量 約 18％
  • 18ノードクラスター ：10％ OR + 6％ HRR = 合計予約容量 約 16％
  • 24ノードクラスター ：10％ OR + 4％ HRR = 合計予約容量 約 14％
  • 32ノードクラスター ：10％ OR + 3％ HRR = 合計予約容量 約 13％
  • 48ノードクラスター ：10％ OR + 2％ HRR = 合計予約容量 約 12％
  • 64ノードクラスター ：10％ OR + 2％ HRR = 合計予約容量 約 12％

※ 詳細は VMware vSAN Design Guide https://core.vmware.com/resource/vmware-vsan-design-guide 参照。

現在の vSAN データストア使用量の確認方法は？

実際に vSphere Client の "vSAN クラスタ > 監視 > vSAN > 容量" のビューで現在のストレージ使用量の確認でオーバーヘッドがどのくらいかが確認可能です。
OR と HRR が確保されていないな？と思ったらこの画面から "予約とアラート" の設定にとぶことも可能ですから有効化しておきましょう。

ホスト再構築の予約 (HRR) を確保しておかないとダメなの？

HRR は任意の設定ですが、1 ESXi 障害があった際に保存されたデータの可用性が低下したままになることは好ましくはないので最低でも N+1 の容量を確保しておくことが強く推奨されます。
システムの重要性や容量次第では N+2、N+3 の容量可用性も考慮する場合がありますが、システム上では N+1 以上の確保は出来ないので任意の使用率でアラートを設定しておくと良いです。

ちなみに容量予約無効時と有効時で同じストレージ使用量でもアラートが働いてちゃんと視認、通知してくれます。

予約無効時


予約有効時


なお、上にも書きましたが、最小構成台数の vSAN (3台構成や 2Node vSAN) では HRR は設定できますが実際はリビルド先が無いと意味がないので通常は無効としておきます。

vSAN の利用率が 80% を超えると強制リバランスが起きて良くないと聞いたんだけど？

vSAN における 「"80%" を超えると強制リバランス」というのは、個々のドライブの使用率で 「”80%" を超えるドライブがあると余裕のある他のドライブにリバランスする」という特定ドライブのみが容量フルで仮想マシンが停止する事故を防ぐための仕組みとなります。

そのため全部のドライブが均等に 80% 以上使用された場合はリバランスが発生することはありません。
それにより上記に記した 12 Node 以上の OR + HRR の容量予約値 18% 〜 12% という容量設計も可能となります。


以前 VMTN に寄せられた質問と回答


vSAN 7.0 以降では自動リバランスも閾値ベースで「個々のドライブの容量差」を % で指定して有効化する事が可能です。

容量がひっ迫してから強制リバランスが走るより、通常時から均等に容量を使うことで緊急時のリスクを減らすことができる非常に便利な機能です。


上記の例では、自動リバランスの閾値を 20% に設定していますが、個々のドライブの容量差が 20% を超えると容量差が設定値の 1/2 (この場合は 10%) になるまで vSAN コンポーネントがリバランスされます。


常に自動リバランスを有効にすることが一番ですが、本番稼働中にリバランス IO が発生する事は避けたいという場合には週末のみ自動リバランス有効化するなどで定期的にストレージ利用率を均等に慣らすことが推奨です。

※ 自動リバランスのスケジュールでの On/Off 設定は出来ないので PowerCLI などで外部からスケジュールタスクを組んで下さい。 

vSAN リバランス時の帯域制御って出来なくなったの？

vCenter 7.0u1 の vSphere Client から vSAN の再同期時の帯域制御のメニューが無くなりました。
これは vSAN 6.7u1 / 6.7u3 で実装された Adaptive Resync や Parallel Resync によってデータの再配置、再同期の時のスロットリングが適切に制御される様になったからです。

Adaptive Resync により、リバランス・再構築中は再同期 IO が仮想マシン IO やその他の IO と競合して帯域を食いつぶさないように、競合時には 20％ までが Resync に利用され、残り 80% が仮想マシンなどのその他の通信で利用できるように調整されます。

※ 以前の vSAN では手動で MBps 単位で再同期の帯域制御を設定しましたが、現在は Adaptive Resync がその役割を担っています。

但し、現在も PowerCLI など API に対して直接操作することで帯域制御の設定自体は可能で、以前に以下の記事にまとめました。Adaptive Resync で十分制御されますので本設定は推奨はされません。

Adaptive Resync については以下の Core TechZone の記事が詳細に書かれています。

Adaptive Resync が動作した際は5分間隔で IO をサンプリングして(vSAN 7.0u3 時点での確認)、フロントエンドの仮想マシン IO に影響が無いように内部的に IO 遅延と輻輳制御をして再同期 IO の帯域を全体の 20% 以下になるように自動で調整されます。

これらの挙動は vSphere Client の "vSAN クラスタ > 監視 > vSAN > パフォーマンス"、及び "vSAN クラスタ > 監視 > vSAN > サポート > サポートのパフォーマンス" からも確認できるので意図的にリバランスを発生させて試すことも可能です。


以前 VMTN に寄せられた質問と回答

vSAN 7.0 までと vSAN 7.0u1 以降で何が変わったの？

オーバーヘッドの考え方が変わった事により、内部的にもより効率よくオブジェクトを扱うようになりました。
ただし、これは大容量オブジェクトでは再構成が必要となり、vSAN 7.0 以前から vSAN 7.0u1 以降にバージョンアップした際に 255GB を超えるオブジェクト (VMDK) があると再構成が必要となります。

" クラスタを vSAN 7.0 以前のリリースから vSAN 7.0 U1 以降にアップグレードした後、以前のリリースで作成されたオブジェクトが 255 GB を超えている場合は、オブジェクトを新しい形式で作成しなおす必要があります。これにより、vSAN は、新しい空き容量要件のオブジェクトに対して操作を実行できます。アップグレードを行った後に、新しいオブジェクト フォーマットへの変換が必要なオブジェクトが存在すると、新しいオブジェクト フォーマットに関する健全性アラートが表示されます。レイアウト変更タスクを開始すると、この健全性の状態を修正できます。健全性アラートには、修正が必要なオブジェクトの数と、書き換えられるデータ量に関する情報が表示されます。レイアウト変更タスクの進行中に、クラスタのパフォーマンスが 20% ほど低下することがあります。この操作が完了するまでの所要時間について、正確な情報が再同期ダッシュボードに表示されます。 "

vSAN 7.0u1 以降に更新した際に 255GB 以上のオブジェクトが含まれていると vSAN 健全性の View にアラートが表示されます。


ここで "オブジェクトフォーマットの変更" をクリックすると変換が走ります。


変換中の途中経過は vSAN のリビルドと同じ "オブジェクト再同期" ビューで確認できます。


ちなみに、オブジェクトが変換される前(vSAN 7.0 以前)の 255GB 以上の VMDK は複数のオブジェクトに分割され複数の "RAID0" が "RAID1" で束ねられた表示 (所謂 RAID10) ですが、



オブジェクトが変換された後(vSAN 7.0u1 以降)の 255GB 以上の VMDK は複数のオブジェクトに分割されて複数の "RAID1" が "連結 (Concatenation)" と表示されます。


この辺りのコンポーネントの配置は ESXi に SSH などで接続して esxcli コマンドで確認することも可能です。

esxcli vsan debug object list

[root@tokyo-esxi02:~] esxcli vsan debug object list

Object UUID: 12136e63-0403-bffa-7e99-e4434b2dc97c
   Version: 15
   Health: healthy
   Owner: tokyo-esxi01.sddclab.jp
   Size: 300.00 GB
   Used: 600.02 GB
   Policy:
      stripeWidth: 1
      cacheReservation: 0
      proportionalCapacity: 0
      hostFailuresToTolerate: 1
      forceProvisioning: 0
      spbmProfileId: 9304e52e-bcc2-4638-9c2b-7796fad6bc3c
      spbmProfileGenerationNumber: 0
      replicaPreference: Performance
      iopsLimit: 0
      checksumDisabled: 0
      CSN: 159
      SCSN: 145
      spbmProfileName: 255GB_Over

   Configuration:

      Concatenation
         RAID_1
            Component: 11977163-aec0-5242-d462-e4434b2dcf1c
              Component State: ACTIVE,  Address Space(B): 273804165120 (255.00GB),  Disk UUID: 5277df35-cd07-d714-0686-cfedc5473c4a,  Disk Name: naa.5002538a4892e540:2
              Votes: 3,  Capacity Used(B): 276547239936 (257.55GB),  Physical Capacity Used(B): 273808359424 (255.00GB),  Host Name: tokyo-esxi02.sddclab.jp
            Component: 11977163-7401-5542-bf8c-e4434b2dcf1c
              Component State: ACTIVE,  Address Space(B): 273804165120 (255.00GB),  Disk UUID: 5239bf93-5203-f9be-c377-0f94ed1bdb8f,  Disk Name: naa.5002538a4892e6c0:2
              Votes: 1,  Capacity Used(B): 276547239936 (257.55GB),  Physical Capacity Used(B): 273808359424 (255.00GB),  Host Name: tokyo-esxi04.sddclab.jp
         RAID_1
            Component: 11977163-6001-5642-fd8e-e4434b2dcf1c
              Component State: ACTIVE,  Address Space(B): 48318382080 (45.00GB),  Disk UUID: 525dc0ca-1fc5-01dd-fede-3098d20a04ac,  Disk Name: naa.5002538a4892e690:2
              Votes: 1,  Capacity Used(B): 48809115648 (45.46GB),  Physical Capacity Used(B): 48322576384 (45.00GB),  Host Name: tokyo-esxi04.sddclab.jp
            Component: 11977163-30e6-5642-af91-e4434b2dcf1c
              Component State: ACTIVE,  Address Space(B): 48318382080 (45.00GB),  Disk UUID: 5288d3aa-ca1f-12cc-2ab1-769aed12e4fe,  Disk Name: naa.5002538a4892e6e0:2
              Votes: 2,  Capacity Used(B): 48809115648 (45.46GB),  Physical Capacity Used(B): 48322576384 (45.00GB),  Host Name: tokyo-esxi03.sddclab.jp

上記の仮想マシンは 300GB フルで利用している仮想ディスクですが、255GB と 45GB の2つの RAID1 オブジェクトが連結(コンカチ)しているのが確認できます。

vSAN OSA・ESA での大容量オブジェクト・コンポーネントの分割サイズ

従来の vSAN OSA (7.0 GA 以前)では vSAN 上に配置される VMDK サイズが大容量な場合は既定では 255GB で分割されて配置されていました。

この 255GB というサイズは vSAN が登場した 2014年頃にサポートされていた SSD・HDD の最小サイズが 300GB だったことがあり、大きな仮想マシンサイズを展開する際には それに収まる様に分割する必要があったからです。

※ コンポーネントサイズは各 ESXi ホストの詳細設定 [VSAN.ClomMaxComponentSizeGB] で変更可能

7.0u1 以降では一つ上のセクションで説明したようなオブジェクトフォーマットが変更され、255GB という基準とともに、8TB 以上の大容量 VMDK の場合は 255GB ではなく 765GB 単位で分割されるようになりました。

こちらは現在最低でも 1 TB 以上のキャパシティドライブを使う事が当たり前な時代になったので、8TB 大容量 VMDK を配置するためのホストであればキャパシティドライブ辺りの容量も大きく、765GB が一つのコンポーネントサイズでも問題が無く効率よく配置ができる様になったからという背景があります。


vSAN ESA ではこのオブジェクトサイズがどうなるか、それは「VMware vSAN Design Guide」 に説明されています。

For vSAN Express Storage Architecture (ESA) the maximum size of a performance leg is 255GB and the capacity leg is 765GB. The stripe policy is largely irrelevant to performance of vSAN ESA but the policy remains for backwards compatibility.

vSAN ESA では P-Leg のサイズで最大 255GB (後述しますが実際にはここまでは使われない)、実際の仮想マシンが格納される C-Leg のコンポーネントサイズで 765GB となります。

このサイズについて、vSAN ESA では認定されたドライブの容量が 1.6TB 以上の SSD のみになるので、大容量前提の 765GB でも問題がないということです。  

ESXi ホスト障害時の vSAN データストア使用可能量ってどのくらいあるの？

HRR の N+1 分の容量予約をしておけば、1 ESXi がダウンしてもデータリビルド後の使用可能量は変わりません。そのための N+1 の容量予約となります。

上記は 4 台の ESXi で構成された vSAN クラスタで HRR 予約を有効にした状態で 95% 近く vSAN を利用していますが、実際には薄灰色で示された "ホスト再構築の予約" で 1/4 大分の 25% が確保されているので、この状態で 1 ESXi が停止しても、保存された仮想マシンデータは停止した ESXi 上に配置されていた分は安全に他のホストに再配置されます。

また、vSAN 7.0u2 以降では、"持続性コンポーネント" と呼ばれる、ESXi ホスト停止時など片方の vSAN オブジェクトにアクセスできない間に発生した書き込み IO を
別のホストに差分として保存し、元のホストが復旧したタイミングで一時的に別のホストに記録していた書き込み差分を書き戻す機能強化が入っていますので、より復旧性とデータロスト耐性が向上しています。

ちなみに、この予約値含めて容量がフルになると新規の仮想マシンの作成や起動が不可になりますが、すでに作成済みの Thin Provisioning の仮想マシンはデータを書き込み続ける事が可能です。

場合によっては急速に増加するデータで予約していた以上のデータが消費される場合もあるため、予約値 +α の余裕をもたせたアラート監視で容量枯渇には注意を払って下さい。

以前 VMTN と Dell Community に寄せられた質問と回答


vSAN 8.0 ESA における容量オーバーヘッド

※ vSAN 8.0 ESA (Express Storage Architecture) については先日開催した VMware Explore 2022 Japan にて vSAN 8.0 Architecture Deep Dive のセッションを担当させていただきました。

2022年12月23日まではオンデマンド視聴と資料 DL が可能なので興味ある方は以下投稿でご紹介したイベントサイトからセッション資料を DL して下さい。

vSAN ESA では従来必要だったキャッシュドライブが不要になったので全てキャパシティドライブで組むことが出来るようになりました。

内部アーキテクチャも大きく変わり Performance-Leg と Capacity-Leg と Meta Data などが記されています。


じゃあこのメタデータなどのオーバーヘッドはどれくらいかというと、Core Tech Zone の公式 Blog Capacity Overheads for the ESA in vSAN 8 に詳細がまとまっているので紹介します(まだ私も実機で細かく検証出来ていません...)

vSAN ESA では上の図の紫の色で示しているメタデータ (Global Meta) で RAW 容量の 10% 確保の他にも書き込み済みのデータに対して 13% を必要とする LFS オーバーヘッドが必要となります。


vSAN ESA の容量オーバーヘッド

  • グローバルメタデータ : RAW 容量の 10% 
  • ホスト再構築の予約 (任意) : 1 ESXi 分
  • LFS オーバーヘッド : 書込済容量の約 13% ※ 圧縮後の容量に対して 13%
  • ※ vSAN ESA Performance Leg は容量サイジング上の考慮は不要 (理論的には最大 255GB 利用)

 仮想マシンのストレージポリシー別の容量オーバーヘッドの考え方

OR や HRR で予約した残りが仮想マシンで利用可能な容量となりますがストレージポリシーで設定する RAID のポリシーでオリジナルデータとレプリカデータの割合が大きく変わります。


上記の "仮想マシンが利用可能な容量" に対して、各ポリシーでどれくらいオーバーヘッドを見込むのかを図で説明します。

vSAN OSA でのストレージポリシー別仮想マシンの配置

vSAN OSA : Mirror

vSAN OSA ではミラー構成 (RAID1) ルールの場合は、FTT1 / FTT2 / FTT3 でそれぞれ Witness を含めた最小ホスト台数全体にコンポーネントが分散されます。

FTT1 / FTT2 / FTT3 でそれぞれ 2倍 / 3倍 / 4倍 のデータを消費するので、

  • FTT1 のときは実効容量は 1/2
  • FTT2 のときは実効容量は 1/3
  • FTT2 のときは実効容量は 1/4
と、データの多重度を上げる毎に消費は大きくなります。

vSAN OSA : Erasure Coding

また、イレイジャーコーディング構成 (RAID5/RAID6) では FTT1 : RAID5 のときは 3D + 1P の最小4台、FTT2 : RAID6 のときは 4D + 2P の最小6台に分散されます。



イレイジャーコーディングでは FTT1 / FTT2 でそれぞれ 3D + 1P、4D + 2P の容量を消費するので

  • RAID5 (3+1) のときは実効容量は 3/4
  • RADI6 (4+2) のときは実効容量は 4/6

と、ミラーに比べると容量増加を抑えることが可能です。

但し、vSAN OSA でのイレイジャーコーディングは書き込み時のパリティ計算のための Write Penalty が大きく影響するので高い書き込み IO で低遅延性が求められる環境での利用には注意が必要です。

vSAN ESA でのストレージポリシー別仮想マシンの配置

vSAN ESA : Mirror

vSAN ESA では Performance-Leg、Capacity-Leg が各 ESXi ホスト、各 NVMe ドライブに分散配置され、RAID1 構成時も Witness オブジェクトが配置されなくなるなどの変更があります。
※ 2Node vSAN や Stretch Cluster 時の vSAN Witness は必要


データの実際の消費は vSAN OSA と同じで
FTT1 / FTT2 / FTT3 でそれぞれ 2倍 / 3倍 / 4倍 のデータを消費します。

  • FTT1 のときは実効容量は 1/2
  • FTT2 のときは実効容量は 1/3
  • FTT2 のときは実効容量は 1/4

vSAN ESA : Erasure Coding

一方 vSAN ESA のイレイジャーコーディングでは FTT1 RAID5 構成時は ESXi ホスト台数によってデータとパリティの割合が可変します。


ESXi ホスト台数が 3台 〜 5台の時は 2D + 1P、6台以上の時は 4D + 1P となります。
RAID6 は 4D + 2P と変わりません。

  • RAID5 (2+1) のときは実効容量は 2/3
  • RAID5 (4+1) のときの実効容量は 4/5
  • RADI6 (4+2) のときは実効容量は 4/6

その他の vSAN 容量サイジングに関する FAQ・注意点

重複排除利用するときは必ず Thin Provisioning で！

vSAN データストア重複排除を有効にしたのに仮想マシンを Thick (容量 100% 予約)で作ってしまうと重複排除関係なく対象仮想マシンの 100% 容量が確保されてしまいます。

重複排除を利用する際は必ず Thin のポリシーで運用して下さい。

VM 暗号化と vSAN 重複排除を同時に利用しないで！

VM 暗号化を vSphere 側でかけてしまうとほぼ重複排除されません。

これは一般的な重複排除ストレージなどにも言えることですが、圧縮されたデータを更に圧縮するのが難しいのと同じで、暗号化で元のデータからバラバラに組み替えられたデータを重複排除しようにもデータの同一性が無いので重複排除の効果がほぼなくなります。

仮想マシンデータの暗号化要件がある場合は必ず vSAN 暗号化と vSAN 重複排除、または vSAN 圧縮機能の組み合わせで運用して下さい。

vSAN ESA では圧縮が標準で有効ですが、圧縮済みのデータに対して暗号化を掛けることで処理データ量を減らし全体の CPU・ネットワーク負荷を低減する効果があります。

異なるドライブサイズ、異なる性能の ESXi ホストでクラスタを組む際の注意点

vSphere クラスタ、vSAN データストアは異なる世代、異なる構成の ESXi を組み合わせることがサポートされており、vSAN データストアにおいてもドライブ容量や本数の異なる ESXi ホストを組み合わせることもサポートされます。

ただ、クラスタとしては全体をバランス良く使うことで性能が最大限発揮できますので可能な限り近い構成・性能で組むことが推奨され、3倍4倍と性能やリソース容量が異なる混在環境では仮想マシンの配置、データの配置が高い性能・大容量の ESXi ホストに偏る可能性があります。
※ 以下に紹介している過去の VMTN での回答 : 異なるディスク構成でvSANクラスタを組む際の懸念点 に図入りで説明しています

こうした状態では性能の高い ESXi ホストが停止した時のインパクトが大きくなるのでリスクを考慮した設計、運用が必要となります。

幾つか過去にまとめた記事と VMTN での回答がありますので以下を参照願います。

以前 VMTN に寄せられた質問と回答

想定していたより vSphere Client で表示される vSAN の容量が1割近く少ないのだけど？

恐らく物理ドライブに記載の RAW 容量 ( SI 接頭辞 = 10進換算 : x1000 で KB/MB/GB/TB の単位計算)と、
OS 上で認識される論理容量 (2進接頭辞 = 2進換算 : x1024 で KiB/MiB/GiB/TiB の単位計算) の計算の違いで少ない容量と見間違えてしまっている可能性があります。

同じ様に見えても SI 接頭辞での 1TB はフォーマットするとシステム上では 2進接頭辞 で 0.909 TiB として認識されるので 9% ほど容量が減ったように見えます。

容量がギリギリの環境で 10% 近いサイジングのズレは死活問題なので単位の計算には注意して下さい。



以前 VMTN に寄せられた質問と回答

時刻:
ラベル: , ,

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)

過去30日でアクセスの多い投稿