調べたこと試したこと: vSAN Ready Node Sizer の効果的な利用方法

※ 2020/9/9 更新 : vSAN Sizer のデザインが新しくなったため本投稿は「Old vSAN Ready Node Sizer」に画面を切り替えた際の操作ガイドとなります。
新しい画面の操作ガイドは 新しい vSAN Ready Node Sizer の効果的な利用方法 を参照してください。

vSAN を導入する際に構成選定やサイジングに利用するツールがいくつかありますが、周りから聞こえてくる声で「使い方がイマイチわからない」「想定している構成・サイジングが出来ない」など悩みを良く聞くので、今回は vSAN Ready Node Sizer (以下 vSAN Sizer) の私なりの使い方をご紹介します。

vSAN のハードウェア構成を考える際の BestPractice 的なポイントは以前書いた以下にまとめているので、今回の vSAN Sizer で組むべき構成もこちらをベースにしています。

また、vSAN に限らずサイジングする際には現状のリソースの利用状況を把握する事は重要なので、アセスメントに関しても検討してください。

vSAN Sizer は LiveOptics や RVTools で取得したデータを取り込んでより現実的なサイジングが可能なのでアセスメントはなるべくするようにしてください。

今回の内容です。

vSAN Ready Node Sizer が上手く使えない時に気にするポイント

私がよく見掛ける（相談を受ける） vSAN Sizer を利用する際に失敗してしまう時のポイント（= してはいけない事）は以下3つ。

サーバーハードウェアの構成を考えずにサイジング
vSAN Sizer の既定値のままでサイジング
提示されたハードウェア構成をそのまま受け入れてしまう

それぞれなぜ NG かを説明します。

サーバーハードウェアの構成を考えずにサイジングは NG
→ 少なくとも必要となる VM数・CPU・メモリの利用率からリーズナブルな ESXi ホスト台数を算出してから、それに合わせてそのホスト数前後で適切な vSAN 構成をサイジングするのが重要。
また、1U サーバにするか 2U サーバにするかでも搭載可能なドライブ数が大きく異なるので前提としてある程度想定するのがポイント。
vSAN Sizer の既定値のままでサイジングは NG
→ 上記のハードウェアの前提を vSAN Sizer の「CLUSTER SETTINGS」「ADVANCED SETTINGS」に必ず反映させる事。既定値のままだとかなりザルなサイジングになるので要注意。
提示されたハードウェア構成をそのまま受け入れてしまうは NG
→ ハードウェア構成は一発でまともな構成が出てくる事は稀です。必ず何度か入力情報を調整してベストな数字を探るのが重要。

これらを考慮して、必要なインプットを Sizer に与えればかなりしっかりしたサイジングが可能となります。

vSAN Ready Node Sizer を利用する際のポイント

https://vsansizer.vmware.com/

「Cluster Configuration」の既定値の変更

CLUSTER SETTINGS : ハードウェア構成(CPU・ドライブ)の前提を設定するため必ず確認・修正する
vSAN Configuration And Features

Configuration Type :
All Flash / Hybrid から選択
vSAN Version :
2020/08/31 時点では vSAN 6.7 のみ選択可能
ROBO :
2Node ROBO vSAN 構成で検討する場合にチェックを入れる(ROBO は 25VM が上限)
Stretched Clusters( 2-site ) :
ストレッチクラスタを検討する場合にチェックを入れる

Additional Cluster Information

Slack Space :
デフォルト 25% で設定されるが、Sizer 自体でその他のオーバーヘッドも加味されるので基本は 25% でよい(vSAN 6.7u3 前提)
% Growth Factor :
成長率の前提、デフォルトで 10% で設定。サイジングがややこしくなるので 0% にした方がシンプル
N+x :
予備ホスト分のリソースを N+0 / N+1 / N+2 で指定
Account for Swap Space :
vSwap ファイル分のリソースを容量に含めるか否かのチェック

「CLUSTER SETTINGS」では既定値で設定されている CPU の前提、ドライブの前提がかなりズレているのでこれを必ず修正します。
まずは「Server Configuration」。

Server Configuration

Total Sockets : ESXi ホスト辺りの CPU 数の指定
Cores per Socket : CPU 辺りのコア数の指定
Clock Speed : CPU の動作周波数の指定
Max Drive Slots Available :
ESXi ホスト辺りの vSAN で利用可能なドライブスロット数を指定(1U サーバなら 8~10、2U サーバなら 16~24 など)
Cache Tier Media Rating ( DWPD ) :
キャッシュ層 SSD の耐久性レベルを 3 DWPD または 10 DWPDで指定 (DWPD 3 は MixUse、DWPD 10 は Write Intensive となる)
Max Capacity Drive Size :
キャパシティ層ドライブの1本あたりの容量を TB で指定。サーバーメーカーの構成ガイドや vSAN HCL を参照する
Disk Group Distribution Method :
Maximum / Minimum / User Defined DiskGroup から選択。
構成デザインが思い浮かぶ方は User Defined でディスクグループ数を 1~5 で決め打ち設定する事をお勧め

例えば CPU を "20Core / 1CPU" に変更し、1ホスト辺りのドライブ搭載数を 1U サーバを前提にして "10" に変更、キャッシュドライブの耐久性レベルも Write Intensive な "10" に変更、最後にディスクグループの数をここでは "2" に指定すると以下の様になります。
※ この設定を入力するかしないかで結果が全く異なるサイジングになってしまうので、サーバーメーカーが公開している構成ガイドなどを元に、どのくらいの構成にしようか予めポンチ絵を書いておくとサイジングの妥当性が理解しやすいと思います。
ディスクグループ数やキャッシュドライブの耐久性の考え方については以下参照ください。

つづいて「CPU Headroom 」（CPU の余裕値）。

CPU Headroom

Steady State

CPU Headroom :
通常時の ESXi ホストの CPU 利用率の上限を余剰利用率で設定。デフォルト 15% ですが個人的な推奨は 20% ~25%。

Host Failure Scenario

CPU Headroom :
障害時(HA 縮退時)の ESXi ホストの CPU 利用率の上限。通常時より高く設定する。

私の場合はホストの CPU 利用率は 80 % くらいで抑えたサイジングにしたいので「Steady State」を "15" → "20"、「Host Failure Scenario」を "5" → "10" にしています。

この辺りは各案件のサイジングの上限値の設計で調整してください。

続いて「Additional Cluster Information」、これも「Slack Space」を "25" → "30"、「Growth Factor」成長率を初期導入時のみで算出するために "10" → "0"、HA 時のリソースの余裕を "N+1" で設定します。

これらも案件毎のポリシーに応じて調整してください。

「Workload Profiles」の既定値の変更

「Workload Profiles」は手入力も可能ですが、LiveOptics のアセスメントデータから直接インポートしたり、RVTools で取得したインベントリ情報をインポートする事でより正確な前提を入力する事が可能です。

Workload

General Purpose :
汎用用途のサイジングで利用(Full Clone VDI や DataBases も同じロジックのサイジング基準)
VDI :
Linked Clone と Instant Clone は独自の計算ロジックがあるので VDI の場合は利用

Full Clone
Linked Clone
Instant Clone

DataBases :

Oracle
Microsoft SQL Server

VM Profile Details

Total Count of VMs : VM の台数
Storage Per VM (GB) : VM が利用するストレージ容量

Additional Info

ADVANCED SETTINGS :
VM の CPU 利用率を設定しますが、デフォルトだと全ての VM が 100% の利用率で設定されているので修正必須
vCPU / Core : 物理コア辺りの vCPU 数(オーバーコミット率)
vCPU / VM : VM 辺りの vCPU 数(平均)
vRAM / VM (GB) : VM 辺りの vRAM 量(平均)
IOPs / VM : VM 辺りの IOPS 値(平均)
Host failures to tolerate :
vSAN の冗長性ポリシー FTT 1 / 2 / 3 を指定( FTT 3 は Mirror のみ)
Fault Tolerance Method :
vSAN の保護ポリシー Mirror (RAID1) か Erasure Coding (RAID5 / RAID 6) で指定
Dedup : 重複排除期待値。重複排除無効でサイジングする場合は "1" で設定

IO Profile

IO Access Pattern : Random / Sequential で指定
IO Size (KB) :
Random IO の場合は 4KB / 8KB / 16KB
Sequential IO の場合は 32KB / 64KB / 256KB で指定
IO Ratio :
Random IO の場合は Read:Write 50:50 / 70:30 / 80:20 / 90:10
Sequential IO の場合は Read:Write 100:0 / 0:100 で指定
※ 全ての IO パターンを一括指定する事は出来ないので特に Sequential IO 特化の VM が含まれる場合はワークロードを分けて設定する事を推奨

ここで必ず設定変更が必要なのが各ワークロードパターンの「Advanced Settings」です。
既定値だと全ての VM の CPU 利用率が 100% 前提でサイジングされてしまいますので、必ず現状確認やアセスメント結果から実際の数値を反映させてください。
以下が既定値の設定です。

上記を以下の様に、 「90% の VM が 20% の CPU 利用率、残りが 80% の利用率」、といった実際に近い前提の数値に変更します。

※ これを忘れると CPU リソースを稼ぐためにホスト台数が大幅に増えてしまいます。

以上を設定し、一先ずは「Recommendation」を出力します。

恐らく一発では想定したホスト構成、台数にはならないので現実的な構成を設定値を変えながら探ります。

「Recommendation」の数値の確認と調整

まずは1回目の「Recommendation」を確認すると、16 ESXi で構成されるクラスタが提示されますが全体でメモリ利用率が高くなっているので、Memory の円グラフ脇の + ボタンで ESXi 辺りのメモリ量を調整します。

1 ESXi 辺り 384GB にすると CPU もメモリも余裕が出てきました。

ここでもやはり 16 ESXi となり、もう少しホストを集約掛けたいと思います。

「CPU」に余裕がある事、「Capacity」がぎりぎりの状況なので、1 ESXi 辺りのドライブ本数を増やして、CPU の利用率を上げる方向で調整します。

いったん「Cluster Configuration」に戻り、「Cluster Settings」の CPU コア数とドライブ本数を変更します。

当初 1U サーバを前提としていたのをより高集約に振って 2U 24本ドライブの ESXi で構成したいと思います。

変更を反映させると以下の様に、16 ESXi から 11 ESXi に集約され、

CPU、Memory、Capacity もいい塩梅に調整できました。

以上簡単ですが vSAN Sizer で想定している構成と大きく異なるサイジングが提示されるときに確認、修正するべきポイントをまとめてみました。

事前にこれから選定しようとするサーバーのハードウェア構成や搭載可能な CPU モデル、ドライブ本数などを調査、想定した上で vSAN Sizer の前提に入力するだけでより正確なサイジングをする事が可能となります。

ここで出力された vSAN ハードウェアのスペックはあくまで参考値となるので、
お客様要件に合わせて調整が可能です。詳細は vSAN Ready Node のハードウェア構成のカスタマイズの項を参照ください。

より正確なサイジングをするためにアセスメントツールを活用する

vSAN Sizer は LiveOptics や RVTools で取得したデータをインポートする事で、より正確なリソース利用率を反映したサイジングが可能です。

今回は LiveOptics からアセスメントデータをインポートした際の利点を紹介します。

LiveOptics で既存のインフラ環境のデータを取得すると、性能・キャパシティ・構成などかなり詳細にレポートを整理してくれます。

以下はサンプルレポートでの紹介となりますが全体の利用率のサマリデータのダッシュボードや、

個々のクラスタ・データストアなどの利用状況の分析、

稼働している VM の内訳、利用状況などを詳細に把握可能です。

割当メモリとゲスト OS 内のアクティブメモリの差異や、仮想ディスクの回収可能量の把握など、サイジングの無駄を洗い出すのに役立ちます。

LiveOptics から vSAN Sizer へのデータ連携

データの連携は非常に簡単で、LiveOptics のレポートダッシュボード上の「エクスポート」 > 「vSAN Ready Node Sizer (Beta)」を選択するだけで、自分自身のメールアドレスのアカウント間でデータを共有してくれます。

インポートされたデータは以下の様にかなり詳細な数字を平均値として自動で入力してくれます。

※ 現在のバージョンでは CPU 利用率の連携は未実装のため前述の「Advanced Settings」で CPU 利用率の調整は必ず行ってください。

vSAN Sizer は正しく入力値を設定し、アセスメントデータと連携する事で強力なサイジングツールとして活用できます。

vSAN Ready Node のハードウェア構成のカスタマイズ

※ 最後に、以前書いたストレージの性能を考慮した vSAN ハードウェア構成の組み方にも含めていた章ですが、改めてここにも貼付しておきます。

vSAN クラスタのハードウェアを選定する際、多くは各ハードウェアメーカーがリファレンスモデルとしての vSAN Ready Node を公開しているので、vSAN Ready Node をベースにする事が多いと思います。

以下の公式のガイド、リファレンスガイド、コンフィグツールでサーバーのベースモデルを要件・用途に応じて選択します。

上記の vSAN Ready Node リファレンスモデルのベースを選択した後に、実際の性能要件や容量要件に応じて、各メーカーの構成ガイドや見積もりツールを利用して CPU / Memory / SSD など各コンポーネントを必要な構成に調整・カスタマイズして見積もりを作成しますが、

ここでよく「vSAN Ready Node って構成変更できないよね？」と勘違いされる事が多いのです。

vSAN Ready Node は従来の ESXi のカスタムと同じく基本的に vSAN HCL でサポートされている（サーバーメーカーがサポートしている）コンポーネントであればかなり幅広くカスタムする事が可能で、多くのお客様の環境でもそのように導入されています。

この辺りは KB にもまとまっています。

vSAN ReadyNode™ で変更できるものとできないものについて (52084)
https://kb.vmware.com/s/article/52084

上記 KB にある様に、vSAN Ready Node のベース構成で基本的に変更できないのは「HBA・RAID カードなどの IO コントローラ」と「ドライブのプロトコル（SAS/SATA/NVMe）の入れ替え」です。それ以外は柔軟に調整できます。

以上、ご参考まで

調べたこと試したこと

ad1

2020年8月31日月曜日

vSAN Ready Node Sizer の効果的な利用方法