⑦vSAN Express Storage Architecture (vSAN ESA)に関するサイジングの考え方

元の記事は以下となります。

• vSAN データストアの容量サイジングの考え方 (vSAN 6.7 / vSAN 7.0 / vSAN 8.0)
  https://kwmtlog.blogspot.com/2022/12/vsan-capacity-consumption.html
  
  

 

サイジングツールのご紹介

上記の Blog 記事や vSphere / vSAN オンラインセミナー#55 VMware vSAN 8 Deep Dive !!! でも紹介していますが、vSAN Ready Node Sizer (以下 vSAN RN Sizer) が12月に vSAN ESA 対応版として刷新されました。

ざっくりサイジング、オーバーヘッドの確認は vSAN RN Sizer の Quick Sizer (Reverse Sizer) 機能で確認ができますので、まずは電卓代わりにこちらをご活用ください。

Quick Sizer の UI も以前と比べてだいぶ改善されて使いやすくなったと思います。

※ 宣伝

新しい vSAN RN Sizer の使い方について、2023年2月15日に Webinar を予定しています。
ご興味ある方は https://juku-jp.vmware.com/seminar/1387-online_230215/ からぜひご登録をお願いします。

ちなみに VxRail は VxRail 専用で VxRail Sizing Tool  がありますが、こちらも 2022年12月16日に vSAN ESA 対応したバージョンがリリースされており、構成作成途中でちゃんと選べる様になりました。

 

vSAN OSA / vSAN ESA のサイジング・オーバーヘッドの考え方

本題のサイジングに関して、こちら Blog にも記しましたが重要なポイントなのでこちらにもあらためて記します。

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

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

それが以下の 操作の予約 : (Operations Reserve : OR)  と ホスト再構築の予約 : (Host Rebuild Reserve : 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 は設定できますが実際は意味がないので通常は無効とする
  
  

現在のバージョンの vSAN (VxRail を含む) は、必須のオーバーヘッドは全体の 10% の容量の OR と、任意のホスト障害時を考慮した HRR が仮想マシンのデータ保存用とは別に確保しておく容量のオーバーヘッドとなります。
ESXi ホスト台数によって HRR の容量は変わってきますので 4 台 〜 6台 の vSAN クラスタでは HRR 含めて 25% 〜 30% の空き容量、10台以上であれば 20% 以下の空き容量でカバーできる、そのくらいのざっくりサイジングで OK です。

※ 詳細は上記の Blog または公式の VMware vSAN Design Guide https://core.vmware.com/resource/vmware-vsan-design-guide 参照。

 

ご利用のシステムによっては 2〜3 ESXi ホストが停止した際にも容量を確保しておきたい、といった場合があります。
HRR は 1 ESXi ホスト障害を前提としたサイジングになりまので、そうした場合は任意の閾値でアラートを設定できますのでホスト台数に応じた数値を設定して運用で調整してください。

※ この新しい考え方だと vSAN の利用率が 80% を超える事があります。「vSAN の利用率が 80% を超えると強制リバランスが起きて良くないと聞いたんだけど？」と言った質問も今コミュニティや VMTN で頻繁に質問が上がるので Blog 側に回答を用意しておりますので参照願います。

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

 

基本の容量オーバーヘッドの考え方は vSAN OAS / vSAN ESA ともに上記の OR と HRR を確保しておくことで同じですが、vSAN ESA  では若干の追加の考慮点があります。

ここで考慮する必要があるのが、各 NVMe ドライブに格納される vSAN ESA  のメタデータ・Performance-Leg・Capacity-Leg の領域の使われ方です。

詳細は VMware Core Tech Zone にて紹介されていますが、英語の記事なのでここではわかりやすい図でご説明します。

• Capacity Overheads for the ESA in vSAN 8
  https://core.vmware.com/blog/capacity-overheads-esa-vsan-8
  

 

先程の vSphere Client の UI で表示される OR・HRR の図で説明すると以下のようなオーバーヘッドの考慮が必要です。

 

上記図でお伝えしたい考慮ポイントはメタデータ = OR で 10% と HRR の 1/N ESXi ホスト分の容量の他、vSAN ESA のファイルシステム上のオーバーヘッド LFS オーバーヘッドが "書き込まれたデータ量の 13%" が必要となるということです。

"書き込まれたデータ量" なので圧縮後に NVMe ドライブに格納された容量がカウントされ、Performance-Leg のオーバーヘッドもこの中で考慮されています。

LFS オーバーヘッドの 13% が大きいようにも見えますが、全体としてはキャッシュ専用のドライブは不要であること、圧縮のアーキテクチャが大幅に改善されて圧縮率が上がっていることなど、全体としてのインパクトは薄まりますのでご安心を。

 

これら含めたサイジング時の考慮点、机上計算では考慮漏れが起きる可能性もありますので、 ぜひ最初にご紹介した vSAN / VxRail の Sizer を活用して、机上の計算をツールで確認する(その逆も)感じで適切なサイジングでリーズナブル & コストパフォーマンスの良い基盤導入につなげていただければと思います。