ESXiバージョン別の vSAN 性能を比較してみると?

CJです。

vSANは基本 ESXi バージョンアップに合わせて、様々な改善が行われます。

今年2月にも ESXi 6.0U3がリリースされ、以下のような vSAN性能改善が行われたことが知られています。

Virtual SAN のパフォーマンス:VMware ESXi 6.0 Update 3 リリースでは、I/O パスの最適化を実現するため、複数の修正が加えられています。これにより、オール フラッシュ構成およびハイブリッド構成の Virtual SAN のパフォーマンスが向上します。

リリースノートのこの文面だけでは、実際どれくらい性能が向上されたかがわかり難かったため、性能測定を行い、その結果を共有したいと思います。

テスト環境

いつもの大好きな RAID-6 (Erasure Coding) の vSAN環境となります。

性能測定方法

fio を利用して性能測定 (IOPS)

#同一条件で行ったため、細かいパラメータはスキップします。

テスト結果

1プロセッサーの場合 (1P)  / 4プロセッサーの場合 (4P)

いかがでしょうか。

リリースノートに書いてあったパフォーマンス向上の話は本当であり、かつ1行の説明で終わっているような感もしますが、実は測定結果の通りに大きな改善がありました。念のため、現時点の最新バージョンである ESXi 6.5U1 と比較してもそれほど変わらないこともわかります。これから vSANの使用をご検討の方、ESXi 6.0U3 より前のバージョンを使っている方はぜひ ESXi 6.0U3 以上の使用をご検討いただいたらいかがでしょうか。

 

vSAN 仮想マシンの容量が増えるにつれ、ObjectとComponentに起きる変化とは?

CJです。

先日、vSAN環境における RAID-6 にて “VM、Object、Components” の全体的な概要について共有しました。 今日は、その延長となる内容で実際仮想マシンのデータが増えるにつれ、VMの構成要素でもある Object と Component がどのように動作していくのかについて共有したいと思います。

では、早速確認していきましょう。

まず、検証環境はいつもの大好きな RAID-6 構成 (vSAN 6.2) となります。

 

VM作成前

vsan.obj_status_report /localhost/DCNAME/computers/CLUSTERNAME

RVC上で、こちらのコマンドを実行し、まず VM作成前の Object 数を確認してみました。

本環境には、現在 1 Object が存在し、その Object に 6 Components が存在しているのがわかります。 まだ本環境には VMが1台も存在していないのに、なぜか 1 Objectがすでに存在する状態です。 この 1 Object は vSAN 健全性とパフォーマンスオプションが有効になっていると vsanDatastore上で vsan.statsフォルダができますが、これの Object となります。

次は、1TBのディスク容量を持つ VMを作成してみました。

VM作成 (1TB / Thin)

すると、GUI (vSphere Web Client) 上からは、以下の通りに表示されていることがわかります。

#Object : VM ホーム

#Object : ハードディスク (VMDK)

CUI (RVC) からは、以下の通りに表示されます。

vsan.vm_object_info localhost/DCNAME/vms/VMNAME/

GUI上で表示されていた “VM ホーム” と “ハードディスク” のコンポーネント詳細が表示されます。また、こちらで各コンポーネントの容量も確認できます。

vsan.obj_status_report /localhost/DCNAME/computers/CLUSTERNAME

Object Status Report からも、VMDKや VMホームのコンポーネントが表示されたことがわかります。ところが、RAID-6なのになぜか 1 Object に対して 3 Components になっているものが存在しています。これは、VMを起動すると現れる SWAP object となります。 SWAP object は特別扱いで RAID-6 構成であっても、RAID-1の動き (1 コピー + 1 Witness) をするみたいです。

ここまでの整理

ここまでの状況を簡単に整理すると、以下の通りとなります。

VMを作成すると、

・3つの Object (VMDK、VMホーム、SWAP) ができ、

・各 Object はさらに Component に分割され、

・Componentは VMDKが12個、HOMEが6個、SWAPが3個

であることがわかりました。

VMDKの Component 数は、なぜ 12個?

vSAN仕様上、1つの Object は Component で構成されており、1 Component の最大サイズは 255GB となっています。

今回、1TBディスク (データ) を持つ、VMを作成しましたことを思い出してください。

1TB = 1024GB ですね。

255GB x 4 (Component : データ) = 1020GB となります。

この 1020GBをオーバーするため、不足している分 (1021~1024GB) の Component が増加 (6つ)する動きとなっています。

これを簡単な図で表したのが、次です。

仮想マシンの容量が増えるにつれ、Component のサイズはどうなるの?

仮想マシンの容量が増える (Guest OS 内のデータが増える)と、VMDK Object を構成している各 Component のサイズも均等に増加します。実際、Guest OS内のデータを増やして行く際の Component サイズの変化を表したのが、次です。

各 Component の容量が 127.5GB で均等に分散されているのがわかります。

また、vSANのRAID-6を使う場合に、ディスク使用量が 1.5倍になりますが、きちんと仕様通りの動きになっていることもわかります。#1530GB

Tip: 2TB のVMを作成すると?

Componentの数と容量が増えていることがわかります。

まとめ

いかがでしょうか。

VMの構成要素 (Object & Component) とそれらの増加タイミング、数、容量などの変化が起きる仕組みがお分かりになりました?vSAN ならではの仕様でもあるため、なんとなくわかっても綺麗に整理できなかった方々に本記事が少しでも役に立てればと思います。

 

[参考情報]

SWAP Object について

http://www.yellow-bricks.com/category/storage/page/2/

vSAN Objects and Component Placement

Understanding vSAN Rebuilds and Repairs