本記事は2020年1月30日にJosh Odgers氏が投稿した記事の翻訳版です。

原文はこちら。本シリーズの索引はこちら。

ハイパーコンバージド（HCI）製品を検討する際には、ベンダー、パートナー、VAR(Value Added Resellers: 再販業社)、顧客が複数のソリューションを比較することがよくあります。

このような比較の際には、マーケティング資料や、多くの場合は「チェックボックス」スタイルのスライドが比較され、さらに悪いことには額面通りの価値で比較され、容量、回復力、パフォーマンスなどの重要なアーキテクチャ/サイズの考慮事項について誤った仮定をしてしまうことがあります。

簡単な例を挙げてみましょう:

顧客は、要件を満たすために16台のノードを選択/必要としており、密度、電力効率、高性能のために2ラックユニットあたり4ノード（4N2U）という最も一般的なフォームファクタを選択しています。

フラッシュストレージのコストがユースケースに見合ったものであるため、ノードには6台の1.92TBドライブ(All Flash)が搭載されています。

つまり、16台のホスト* 6台のドライブ=合計96台のドライブを使用しています。

1.92TBドライブがフォーマットされた時の容量を1.78TBとすると96本では170.88TBとなります。

次に、顧客は vSAN と Nutanix を比較します。どちらもデータ保護の主要な形態としてレプリケーションを使用しており(従来の RAID とは対照的)、2 つのコピー(Nutanix では RF2、vSAN では FTT1)と 3 つのコピー(RF3 または FTT2)のどちらかを使用しています。

彼らは簡単な計算をして、次のような結論を出しています。

170.88TB / 2 (RF2 または FTT1) = 85.44TB 使用可能

170.88TB / 3 (RF3 または FTT2) = 56.96TB 使用可能

顧客/パートナー/VARは、両製品の使用可能容量は同じであるか、少なくともその差は購入やアーキテクチャ上の決定には重要ではないと結論づけてしまっていないでしょうか？

もしそうだとしたら、彼らは2つの重大な理由から大きな勘違いをしたことになるでしょう。

理由1：ファイルシステム/オブジェクトストアのオーバーヘッド

vSANやNutanixを含む新旧のすべてのストレージ製品にはオーバーヘッドがあります。これはごく普通のことですが、オーバーヘッドについて理解しておく必要があります。

まずはNutanix ADSFについて。ディスクバランシングやガベージマネジメントなどの「Curator」によるバックグラウンド操作のためにある程度の容量が予約されて(そして隠されて)います)。「Oplog」と呼ばれる永続的な書き込みバッファのためにさらに容量が予約され(そしてこちらも隠されて)います。

vSAN はキャッシュとして「ディスクグループ」ごとに 1 つの SSD を使用します。SSD 全体の容量は使用可能な容量と一致しません。Nutanix の Oplog の容量が使用可能な容量として報告されないのと同様です。

VMware では、ノードごとに複数のディスクグループを使用することを推奨しているため、この例では 2 つのディスクグループと、キャッシュ用に予約された 2 つの SSD を想定しています。

重要な注意点: オールフラッシュの vSAN 構成では、キャッシュデバイスの 100% が書き込みバッファリング専用となりますが、vSAN 6.7 u1 では最大 800GB (以前は 600GB) までとなっています。

参照: Understanding vSAN Architecture: Disk Groups (2019年4月)

理由2：スラックスペースの必要性

「vSANの空き容量に関する推奨事項の再検討」と題した最近の記事の中で、VMwareは過去数年間一貫して、サイズに関係なく、すべてのvSANクラスタに対して25～30%の「スラックスペース」を推奨してきたと述べています。

経験則としては、もしNutanixの顧客このルールが適用されたとしても、実際には私は気にしないでしょう。Nutanixの顧客は非常に保守的なサイズの（おそらくかなりオーバーサイズの）環境を持っているでしょうから。しかし、欠点としては、コストが大幅に増加すること、多くの場合、そのコストは投資を実行できなくするかもしれない程であること、より重要なことに、そのソリューションは、望ましいビジネス成果を提供するための要件を大幅に超える可能性が高いということです。

傍注: (Nutanix) HCIの中心となる価値の1つは、スモールスタートして必要に応じてスケールする能力です。vSANのスラックスペースの要件では、この価値は多少制約を受けます。一方、Nutanixは、この投稿に示されているように、容量、性能（リニアに上昇します）、および回復力の面で非常によくスケールアウトしています。

Nutanixのストレージ・オンリーノードによる性能のスケールアウトのテスト

「vSANの空き容量に関する推奨事項の再検討」記事の中から、フリースペース/スラックスペースに関するものを抜粋してご紹介します。

Nutanix ADSFでは、一時的な活動（ディスクバランシングやガベージ管理など）のための容量があらかじめ差し引かれた上で、使用可能な容量が算出されます。一時的な活動のための容量が不用意に使用されてプラットフォームが不安定になるか、パフォーマンスの問題、そして最終的にはダウンタイムにつながることがないようにするためです。Nutanix ADSFは 1 MB / 4 MB の粒度でストレージを管理しているため、バックグラウンドでの活動に必要な容量は非常に低く抑えられています。

対照的に、vSANオブジェクトは最大255GBまで肥大するため、容量のフラグメンテーションによって、使用できない容量がでてきたり、そのフラグメントされて使用できない容量の一部を利用するために、手動で環境をデフラグすることを余儀なくされたりします。

上記の記事では、VMwareは、障害を許容するために25〜30%の容量を確保する必要があることを指摘しています。4ノードのクラスタではN+1であれば25%の推奨値が正当化されますが、非常に一般的な8ノードのクラスタにスケールすると、25%(推奨範囲の下限)はすでにN+2であり、多くの環境では不必要です。

これも非常に一般的な(少なくともNutanix環境では)16ノードクラスタにスケールすると、25%はN+4を確保することになります。この値は、顧客がブロック全体（2Uの筐体の4台のノードを搭載できるエンクロージャ）の損失から保護したい場合には正当化できますが、多くの環境では過剰になるでしょう。

32ノードのクラスター規模では、VMwareが推奨する最小値では、N+8に相当する値を確保することになります。VMwareに弁明の余地を与えるとすると、このレベルの予約は、クラスタ内のラック全体の障害から保護するためにラック・アウェアネスの機能を利用したいと考えている、かなり少ない割合の顧客には議論の余地があります。しかし私なら4つの独立したクラスタなどの他のオプションを提案します。それによってスラック/HA/障害のために予約されたノード数は半分(4ノード)になりますが、より高い回復力と可用性を達成することができます。

しかし、話を両製品の使用可能容量に戻して、実際の値と現場でよく見かける以下のようなざっくりした推論値を比較してみましょう:

フォーマット後の170.88TBの使用可能容量 (RF2 または FTT1) 170.88TB / 2  = 85.44TB

フォーマット後の170.88TBの使用可能容量 (RF3 または FTT2) 170.88TB / 3  = 56.96TB

16ノードのクラスタから始めてみましょう

注：すべての計算は、推奨範囲の上限である30%の値ではなく、VMwareが推奨する最低25%の値を使用しています。

では、vSANの使用可能な容量を見てみましょう:

以下は、まさにこの構成のvSANクラスタのスクリーンショットです。

次にNutanix ADSFの使用可能容量を比較してみましょう

こちらがNutanix環境のスクリーンショットです:

2つの製品の間で使用可能容量の差が大きいことは数学者でなくてもわかりますが、興味のある方のために、全く同じハードウェアとスラックスペースの予約(必要ないにもかかわらず)では、vSANはNutanixよりも31.45%も使用可能容量が少なくなります。

以下は、vSANホストの1つに搭載されているストレージデバイスを示しています:

以下は、1台のNutanixホストで、同じストレージの概要を示したものです。

Nutanix ADSFのスラックスペースを下げるとどうなりますか?

Nutanixのスラックスペースを16ノードクラスタに対して私が一般的に推奨しているもの(16ノードクラスタの場合はN+2または12.5%)に設定すると、以下の計算では、使用可能な容量が61TBから71TBに増加し、Nutanixにとって非常に有利な計算になります。

私がNutanixへの優位性を示すためにクラスタサイズをチェリーピックしたと思っている人のために、同じHWで4ノードと8ノードのクラスタをレビューしてみましょう。

8ノードクラスタ

vSAN 8ノードクラスタの概要:

Nutanix 8ノードクラスタの概要:

繰り返しになりますが、vSANはまだNutanixよりも使用可能な容量が少ないことがわかりますが、この場合は全く同じハードウェアで41.25% 少なくなっています。スラックスペースの予約が12.5% (N+1)に減少していることに注目してください。

次は4ノードクラスタの比較です:

それでは、vSANの使用可能な容量を見てみましょう:

注：vSAN、Nutanix双方とも、4ノードクラスタではRF3/FTT2をサポートしていません。

次はNutanix ADSFの使用可能な容量です:

このシナリオでは、両製品ともシングルノード障害（N+1）に耐えられるように、少なくともN+1を維持する必要があるため、「スラックスペース」は両製品とも25%となります。これはvSANのベストケースシナリオですが、それでもNutanixと比較してvSANの使用可能キャパシティは31.45%低くなっています。繰り返しになりますが、全く同じハードウェアと回復力レベルでの比較です。

しかし、より大きなドライブを使用する場合はどうでしょうか?:

3.84TBのSSDを使用した際のvSANの結果は:

3.84TBのSSDを使用した際のNutanix ADSFの結果は:

Nutanix ADSFはいまだに41.25%のアドバンテージを持っています。その理由は単純で、vSANの基礎となるアーキテクチャが大量のスラックスペースを必要とすることと、キャッシュドライブが使用可能な容量に貢献していないという事実にあります。

更新: パート2(日本語記事投稿時にリンク)では大規模な24台のドライブを持つシステムでの使用可能容量の比較をしました。チェックしてください。

vSANの使用可能なキャパシティを向上させる方法はありますか?

端的な答えは「はい」です。私は常に公平性を保ち、両方の側面を提供するよう努めています。以下のオプションはvSANの使用可能な容量を増やすのに役立ちます。

1) 単一のディスクグループのみを使用することで、キャッシュによって「失われる」容量をSSD 1枚分だけをとどめます

これはディスクグループ内の「キャパシティ」ドライブの数を増やし、使用可能な容量を増やすことになります。しかし、書き込み/読み取りキャッシュに使用されるのは 1 台のドライブのみであるため、パフォーマンスに影響を与えるという、大きな代償が必要になります。パフォーマンスが阻害要因にならないと仮定した場合でも、残念ながら回復力にも影響があります。単一のディスクグループだけが存在する場合、単一のキャッシュ SSD の障害はノードの障害にもつながるからです。

注意: Nutanixノード内のすべてのSSDは永続的書き込みバッファ(oplog)に使用されます。永続的書き込みバッファ(oplog)は、最適なパフォーマンスを実現するため、また少数のドライブがホットスポットになることを避けるためにデフォルトですべてのドライブに渡ってストライプ化されています。そしてADSFはフラッシュを純粋にキャッシュとして利用することで発生するキャパシティの問題を回避しています。

2) ディスクグループごとに、より多く本数のSSDを利用する/またはより大容量の SSD を使用します

この例では、VMware のパフォーマンスに関する推奨に従い、2 つのディスクグループにキャッシュドライブ 1 台とキャパシティドライブ 2 台を配置しました。ノードがより多くのドライブをサポートしている場合、ディスクグループごとに最大7台のキャパシティドライブを使用することができます。

この場合も、キャッシュとキャパシティの比率が小さくなるため、パフォーマンスは低下します。より重要な問題は、単一のキャッシュドライブに障害が発生した場合、ディスクグループ全体がオフラインになるため、回復力が再び影響を受けることです。非常に大規模なディスクグループは、回復力、障害時のパフォーマンスへの影響、および、大量のデータの再複製が必要なことによる冗長性の回復時間などのリスクを大幅に増加させます。

Nutanix ADSFでは、どのような単一のSSD障害でも、それはただの「単一のSSD障害」です。再複製が必要なのは単一のSSDドライブのデータのみです。ディスクグループ全体の再複製とは対照的ですね。例外は単一のSSDしか持たないノードで、この場合はSSDの障害の結果としてノード障害となります。これは、私がプラットフォームに関係なく単一のSSDシステムを推奨しない理由の一つであり、vSANのディスクグループアーキテクチャを好まない理由でもあります。

3) 圧縮/重複排除を使用します

これはストレージ効率の向上に役立つかもしれませんが、両製品がこれらの機能をサポートしているため、これを行ってもソリューション間の使用可能容量の差は大きくは変わりません。

しかし、vSANソリューションがHybridの場合、vSANは圧縮と重複排除をサポートしていないため、Nutanixは使用可能な容量でさらに大きなアドバンテージを持つことになります。

4) イレイジャーコーディング/RAID5または6を使用します

vSANのRAIDの実装を使用することで使用可能な容量が増加します。しかし、圧縮と重複排除の場合と同様に、Nutanixはイレイジャーコーディングをサポートしているので、これは2つの製品間の使用可能容量のギャップを埋めることはできないことを意味します。

Nutanixは、実際、（2015年に）HCI市場に最初にイレイジャーコーディングを提供しましたが、これは容量の節約が再度洗練されたことを意味します。vSAN RAIDはインラインでも動作しますが、実際にはフロントエンドのIOパフォーマンスに直接影響を与え、データセットがRAIDに適していない場合（上書きによるパフォーマンスの低下）であっても、ホストのリソースとフロントエンドのパフォーマンスに不必要なコストをかけてRAIDが適用されます。

注意: vSAN上のRAID構成はオールフラッシュ構成に限定されています。イレイジャーコーディング/RAIDは、WORM(Write Once Read Many)、スナップショット、バックアップ、アーカイブ、オブジェクトストアなどの、頻繁に変更されたりアクセスされたりしないデータに対してのみ非常に魅力的であるにも関わらずです。Nutanixではハイブリッド構成でもイレイジャーコーディングをサポートしており、これらのデータに対して非常によく機能します。

とはいえ、Nutanix - イレイジャーコーディング(EC-X) ディープダイブをご一読ください。そこでは、フロントエンドのIOへの影響を避けて、イレイジャーコーディングに適しているデータのみに適用するといったNutanixのイレイジャーコーディングの実装のユニークな利点を解説しています。vSANの実装のようなオールオアナッシングのアプローチとは対照的です。これは、Nutanixが書き込みパス上のフロントエンドのIOに直接影響を与えることなく、最大の容量効率を実現していることを意味します。これはまた、適切でないデータにイレイジャーコーディングを適用しないことで、ホストリソース(CVMのvCPU)の使用量を削減することを意味します。

クラスタのフラグメンテーションとそれによる使用可能な容量への影響

vSAN は最大 255GB までのオブジェクトを持つ Object Store を使用しているため、粒度が非常に低く、通常、書き込み/読み込みは、VM の配置に関係なくノードのサブセットに対して行われます。オブジェクトのサイズが肥大化し、クラスタ内のどの2つのノードの利用可能な容量よりも大きくなった際には、一部の容量が使用できなくなる可能性があります。

Nutanix ADSFでは、空き容量がどこにあるかに関係なく、次の1MBエクステントを書き込むのに十分な空き容量が2ノード以下になるまで、すべての容量を使用してローカルまたはリモートに書き込むことができます。(RF3/FTT2の場合は3ノード)。

これは、ストレージ容量とパフォーマンスに基づいて書き込みIO（ローカルノードがフルの場合を除き、通常はレプリカのみ）を配置するNutanixインテリジェントレプリカ配置によって達成されます。

この容量効率の優位性はワークロードの種類によって異なります。VDIの場合はその優位性は最小限になりますが、混合ワークロードの場合は、クラスタによってサポートされているVMのサイズが異なるため、ストレージが断片化が生じることがあります。

詳細についてはこちらを参照してください。Nutanixの信頼性 - パート6 - CVMのメンテナンスや障害時のI/O書き込みについて この概念と障害シナリオをより深くカバーしています。

まとめ:

Nutanixの使用可能な容量をvSANと比較する場合、経験則として、一般的には、どのvSAN構成でも20～45％の物理的な容量を確保する必要があります。この記事で議論したようにディスクグループの構成によってはオーバーヘッドも大きくなります。公正な使用可能な容量の比較のためには、データを削減する技術を考慮しなくても構いません。双方でサポートされている場合チャラ(イーブン)になるからです。

これが示すのは、Nutanix ADSF（Acropolis Distributed Storage Fabric）には、vSANよりも大きなパフォーマンス、スケーラビリティ、および回復力の利点があるということです。Nutanixのシンプルさは、顧客（とアーキテクト）がディスクグループの複雑さを理解する必要がないことを保証するのにも役立ちますし、バックグラウンド機能（curator/stargate）は「空きスペース/スラックスペース」を考慮する必要がありません。箱から取り出してすぐに使えるソリューションを提供しています。

Nutanix、vSAN、または他のHCIや従来のストレージ製品/ソリューションを選択するかどうかにかかわらず、常に回復力/可用性の要件を考慮し、それに応じて設計してください。使用可能な容量は考慮すべき（非常に重要な）要素の1つに過ぎません。

次回はNutanix ADFSとVMware vSANの重複排除と圧縮を比較してみましょう!

本記事の作成に助力いただいたGary Little (@garyjlittle)氏に感謝します。彼のブログ  https://www.n0derunner.com/ では、パフォーマンス、スケーラビリティ、エンタープライズアプリケーションに焦点を当てた記事が掲載されています。GaryはNutanixのパフォーマンスおよびエンジニアリングチームの非常に尊敬されるシニアメンバーです。彼をフォローすることを強くお勧めします。

以下のゲイリーの記事をチェックしてみてください:

1. SQL Server uses only one NUMA Node with HammerDB

2. SuperScalin’: How I learned to stop worrying and love SQL Server on Nutanix

3. How scalable is my Nutanix cluster really?