本記事は2020年2月3日にJosh Odgers氏が投稿した記事の翻訳版です。
最近の記事で、同じハードウェア上のNutanix ADSFとVMware vSANの実際の使用可能容量を比較したところ、Nutanixの方が約30~40%も多くの使用可能容量を提供していることがわかりました。
そうすると次の自然なステップは、使用可能容量にさらなるストレージ容量の効率性をもたらすデータ削減/効率化技術を比較することです。
前の記事では、使用可能容量の比較を単純化するために、2つの製品の機能差を「チャラ」にすると宣言しました。しかし、現実にはチャラにはなりません。Nutanixプラットフォームは、同じハードウェアであってもより多くの使用可能容量を提供する能力を保持しているからです。Acropolis Distributed Storage Fabric (ADSF)の優れたストレージ階層化に加え、データ削減技術を組み合わせたとしたら、vSANは銃撃戦にスプーンを持ってきたようなものです。
この記事では重複排除と圧縮について見ていきます。
圧縮、重複排除などのデータ削減技術は、データセットに応じて顧客にさまざまなレベルの価値を提供する実績のある技術です。
マーケティング資料などで、これらの機能が比較される際、多くの場合、ベンダーの営業担当者による"チェックボックス"スタイルのスライドが、利用されています。さらに悪いことに、こうしたスライドは殆どの場合、額面通りに(訳注:単に機能の有無しか表していないにも関わらず全く同等であるかの如く)受け取られてしまうため、容量、回復力、パフォーマンスなどの決定的なアーキテクチャ上/サイジング上の考慮事項について誤った想定をしてしまう可能性があります。
これは、私が2014年に書いた記事のことを思い出させます:Not all VAAI-NAS storage solutions are created equal(すべてのVAAI-NASストレージソリューションは同じように作成されていない)と題して、私は複数のベンダーがvSphere用のVAAI-NASのサポートを表明しているにも関わらず、必ずしもすべてのベンダーがVAAI-NASの提供する、付加価値となる機能、容量の効率性、そして不必要なIO処理を回避することで実現される性能の向上といった、すべてのプリミティブ(機能)をサポートしているわけではないということを述べました。
6年たった今でも、これらのチェックボックス型マーケティングの比較が業界を悩ませていることはほとんど変わっていません。
簡単な例を挙げてみましょう:
機能 | Nutanix | VMware vSAN |
重複排除 | ✅ | ✅ |
圧縮 | ✅ | ✅ |
上の表はデータ削減技術を示しており、NutanixとVMware vSANでは重複排除と圧縮の両方がサポートされていることを示しています。
この情報から、顧客/パートナー/VARは、両製品のデータ削減の能力は同等か、少なくとも購入やアーキテクチャの選定には影響しないほどの差異しかないと結論付けてしまいます。
しかし、これでは、以前と同様に多くの人が重大な勘違いをしてしまいます。
以下の表では、両製品で現在サポートされている構成ごとのデータ削減機能を示しています:
機能 | Nutanix | VMware vSAN | ||
オールフラッシュ | ハイブリッド | オールフラッシュ | ハイブリッド | |
重複排除 | ✅ | ✅ | ✅ | ❌ |
圧縮 | ✅ | ✅ | ✅ | ❌ |
ここでは、vSANがハイブリッド構成(フラッシュ+HDD)でのデータ削減技術をサポートしていないことがわかります。これにより、ハイブリッド・プラットフォームを選択している顧客は、Nutanixを使用することで、同じハードウェアでも、あるいはより少ないハードウェアでも、この優位性を利用してより多くのデータを保存できる可能性が高くなります。
VMwareからのメッセージは一貫して、ハイブリッド(HDD)層のデータ削減はパフォーマンス上の理由で行うべきではないので、意図的にハイブリッドでのデータ削減をサポートしていないというものでした。
この主張については本記事の後半で取り上げます。
引き続き比較を続けて、製品間に他にどのような違いがあるかを見ていきましょう。
一般的な重複排除と圧縮のコンセプト
データ削減技術には長所と短所があります。例えば重複排除はVDIデータセットでは10:1を超える効率性を提供しますが、他のデータセットでは、ほとんど、もしくはまったく削減効果を提供できません。
すでに圧縮されているデータ(例:アプリケーション層で圧縮されている)の場合も、ストレージ層の圧縮はあまり価値がないかもしれません。
どちらの技術もこれらの機能を実行するためにストレージコントローラ(物理、仮想、インカーネル、コントローラVM)のCPU/RAMを必要とします。このリソースと潜在的なパフォーマンスに対する「コスト」は、削減できる容量と比較する必要がありますし、結果は顧客によって大きく異なる可能性があります。
このように、ホスト(vSAN Kernel / Nutanix CVM)の不必要なオーバーヘッドを回避するためには、これらの技術をいつ/どこで使用するかを検討することが重要です。
圧縮と重複排除を「手当たり次第に」適用したところで、セールストークや、一般的に期待されるような結果になることはほとんどありません。対照的に、データ削減率が低い場合(例:1.2:1未満)は特にパフォーマンスに大きな影響を与える可能性が高いため、機能の柔軟性が鍵となります。
以下の表は、データ削減技術の設定を示しています:
データ削減機能の設定 | Nutanix | VMware vSAN |
圧縮のみ | ✅ | ❌ |
重複排除のみ | ✅ | ❌ |
圧縮と重複排除 | ✅ | ✅ |
vSANでは、圧縮と重複排除はすべて一緒に、そしてvSANクラスタ全体で有効にする必要があります。これは、顧客がデータセットに最適なテクノロジーを有効にするための柔軟性が失われることと、不必要に圧縮や重複排除を適用することによってオーバーヘッドが発生することを意味します。
以下はvSAN上で有効にする重複排除と圧縮の設定画面です:
これは大きな問題です。非効率性につながります。顧客は複数のサイロを作成することを余儀なくされ、効率性をさらに低下させ、信頼性確保のためのオーバーヘッドが増加する可能性があります(例:クラスタあたりN+1ノード)。
例) ある顧客は16ノードのクラスタを持っています。ワークロードの半分は2:1の圧縮と重複排除を利用しており、効果的に機能しています。残りの半分はビジネスクリティカルなアプリケーションで、パフォーマンスの問題に悩まされています。この問題を解決するには、vSANの顧客はクラスタ全体の重複排除と圧縮を無効にして2:1の容量節約を失うか(ノードの追加購入につながる可能性が高い)、あるいはクラスタを2つ以上のクラスタに分割して、重複排除と圧縮が効果的に機能するほうだけで継続して使用できるようにする必要があります。
質問) 16ノードのvSANクラスタを大幅なダウンタイムやハードウェアの追加なしに2つに分割するにはどうすればいいのでしょうか?(この手順の計画に関わる労力だけでも相当なものになるということは言うまでもありません)。
Nutanixならば、要求されたレベルのパフォーマンスを発揮していないワークロードに対してのみ、圧縮や重複排除、あるいはその両方をシンプルにオフに切り替えるだけです。これにより、データ削減技術の制約のためだけにvSANクラスタを分割するという、複雑でリスクが高く、時間のかかるプロジェクトの必要性はなくなります。
重複排除の境界:
重複排除をどこでどのように適用するかは、それがもたらす効率性に大きな影響を与える可能性があります。両製品の重複排除の「境界」を比較してみましょう。
重複排除の境界 | Nutanix | VMware vSAN |
グローバル | ✅ | ❌ |
ノード/ホストごと | N/A | ❌ |
ディスクグループごと | N/A | ✅ |
Nutanixの場合は簡単で、ストレージコンテナ内のあらゆるデータはクラスタ内のどこにいても他のデータと重複排除することができます。同じデータのコピーが16個ある16ノードクラスタの場合、重複排除を有効にすると、Nutanixはこれを1個のコピー(重複排除後もRF2またはRF3で保護されています)に減らし、そのデータの効率性は16:1になります。
同じ例であっても、vSANでは同等の効率性は得られないかもしれません。ディスクグループ内でしか重複排除を行わないからです。VMwareは最適なパフォーマンスを実現するために、1ノードあたり少なくとも2つのディスクグループを推奨しています。この重複排除の実装では、同一ホスト内であっても重複排除が機能せずに複数の同一データが存在する可能性があることを意味します(データの多重化はディスクグループをまたいで行われます)。
Nutanixが16:1の効率を達成した同じ16ノードクラスタの例では、vSANはNutanixの16倍のデータを保存することになるかもしれません。重複排除はディスクグループごとにしか実行されないという制約があるためです。
vSAN環境がノードごとに2つのディスクグループを使用しており、各ディスクグループに重複データがある場合、同じデータは最大で32個のコピー(16ノード×2ディスクグループ)が保持される可能性があります。重複排除の境界が(グローバルではなく)ディスクグループ層にあるためです。
結果は16~32倍になるかもしれませんと述べましたが、現実の世界では、もっと低くなる事が多いでしょう。混合ワークロードの場合は1.5〜2:0くらいでしょうか。ポイントは、vSANによるデータ削減機能の潜在的な効率は、基盤となるアーキテクチャに起因して人為的に低下してしまう一方で、Nutanixはこの問題に悩まされることはないということです。
VMwareの反論は、グローバルな重複排除はグローバルなメタデータを必要とするため、効率が悪い一方で、よりシンプルなvSANの実装に比べて高いリソース要件(CPU/RAM)を必要とする可能性があるというものです。VMwareのこの主張は間違っていません。しかしNutanix ADSFはそもそもストレージファブリックにグローバル・メタデータを利用した、完全な分散アーキテクチャであり、それを利用して2013年には重複排除がサポートされました。vSANは2016年にvSAN 6.2で重複排除と圧縮を「後付け」しただけです。
Nutanixのグローバル重複排除に対して考え得るもう一つの反論は、データローカリティが失われる可能性がある点です。しかし、VMwareは賢明にもこれについて言及することを避けているため、私はこの反論を耳にしたことはありません。なぜなら、この反論をするということは、Nutanixの独自の実装であるデータローカリティが価値あるものであることと、VM が作成されたホストから移動した後に インテリジェントにVM が存在する場所へ書き込みを行えないことがvSAN の大きなアーキテクチャ上の欠陥の 1 つであることを認めることになるからです。
使用可能容量の比較から学んだように、(グローバル・メタデータを使用する)分散ストレージファブリックは、vSANと比較した場合、物理容量に対してかなり多くの使用可能容量を提供します。これによって、見かけ上、または実際の追加のリソースのオーバーヘッドは正当化されるでしょう。グローバル・メタデータはまた、ストレージ・オンリー・ノードのような機能を利用して、ユーザーの介入なしに容量、回復力、パフォーマンスを追加することも可能にします。グローバル・メタデータにはコストがかかりますが、間違いなく相応の価値があります。
次は、いつ、どこで、どのようにしてデータ削減が行われるのかを深く見ていきます。
次の表は、両製品のデータ削減技術がどのストレージ階層でサポートされているかを示しています。
データが削減される層 | Nutanix | VMware vSAN |
書込みバッファ / キャッシュ | ✅ | ❌ |
キャパシティ層 | ✅ | ✅ |
vSANのデータ削減技術は高性能な「キャッシュ」層には適用されません。一方、Nutanixでは「キャッシュ」層に対しても書き込み用のインライン圧縮がデフォルトでオンになっており、重複排除がサポートされています。
vSANでは、重複排除と圧縮が適用されるのは、データがコールド(訳注:アクセス頻度が低い状態)になってキャパシティ層へ階層移動されてからです。前述した参考文献に戻ると、VMware は一貫して、パフォーマンス上の理由から意図的にハイブリッド構成でのデータ削減をサポートしないと言い続けてきました。特に書き込みキャッシュがディスクグループあたり 800GB に制限されていることを考えると、なぜこれらの優れた技術をなぜ「オールフラッシュ」構成のキャッシュ層に適用しないのかという疑問が湧いてきます。
Nutanixの書き込みバッファ(oplog)は、デフォルトで内部的に圧縮が有効になっており、PRISMのGUIから無効にすることはできません。検証において、この機能は最小限のオーバーヘッドで非常に効果的であることが示されていることから、ある種「強制的に」有効にされています。
例としてこちらをご一読ください。Nutanix上でのインライン圧縮によるパフォーマンスへの影響とオーバーヘッドはどの程度ですか?
Nutanixのフラッシュストレージ層がvSANの最大書き込みキャッシュサイズと同じ800GBだったとします。圧縮を有効にすると、効率比を保守的に1.5:1と仮定しても、有効なフラッシュ層は1.2TBに増加します。これは、SSD+HDD(ハイブリッド)か、あるいはNVMe+SSDであるかどうかにかかわらず、利用できる最速のストレージ層から提供されるデータが大幅に増加することを意味します。
では、ハイブリッド・プラットフォーム上ではデータ効率化を有効にしないというVMwareの主張をみていきましょう:
Nutanixの圧縮が50%の大きなレイテンシのペナルティを追加しているとしましょう(以前述べた通り、これは正しくありませんが、最後までお聞きください)。圧縮を行わない場合の読み書きの平均レイテンシは2msです。
これに50%を加えると平均レイテンシは3msになりますが、同時に、高速なストレージ層(例: NVMeやSSD)に、50%も多くのデータを保存できるようになります(保守的な1.5:1の圧縮率を想定しています)。対照的に、その50%のデータがSATA(ハイブリッドの場合)から読み書きされた場合、平均レイテンシは10ms以上になるでしょう。
これは単純な例ではありますが、ハイブリッドシステム上でのデータ削減が可能であり、そして多くの場面においてパフォーマンスの優位性にもつながっていることを示しています!
そうは言っても、顧客は多くの場合、大量のコールドデータを保持するユースケースでハイブリッドを選択します。そのような場合はアクセス頻度が低いため、たとえ潜在的なパフォーマンスのペナルティがあったとしても、1.5:1あるいは2:1という容量効率性を得る価値が十分にあると言えるでしょう。
2:1になると、同じデータを保存するのに必要なノード数は半分になります!Nutanixのお客様は圧縮を有効にすることで、節約したコストの一部を追加ノードに費やし、パフォーマンスを向上させることができます。そうすれば、コストの総額は削減しつつも、素晴らしいビジネス成果を得ることができるでしょう!
NVMeとSATA-SSDが混在したフラッシュ・システムの場合、たった1.5:1の比率だったとしても、NVMeが提供するデータが50%増加します。NVMeにはSATA-SSDに比べて低遅延かつ高速という利点があります。もちろん、フラッシュとHDDのプラットフォームと比較すると、その優位性は低くなるかもしれませんが。
レイテンシへの影響をある程度考慮したとしても、これはかなり堅実な結果です。
重要な注意: vSAN キャッシュは一般的に最もコストの高いフラッシュデバイス(例: NVMe やエンタープライズグレードの SSD)であるため、その層で削減できるデータが多ければ多いほど、ROI (とパフォーマンス) をより改善できたことでしょう。
しかしvSANでは、データ削減はコールドデータにのみ適用されます。キャッシュ層でデータ削減を使用しないということは、パフォーマンス上の理由からハイブリッド構成ではデータ削減をサポートしていない、というVMwareの主張とはまたもや矛盾しています。
「vSANは、キャッシュ層からキャパシティ層にデータを移動する際に重複排除を適用し、それから圧縮を行います。」
参照: HTTPS://DOCS.VMWARE.COM/EN/VMWARE-VSPHERE/6.5/COM.VMWARE.VSPHERE.VIRTUALSAN.DOC/GUID-3D2D80CC-444E-454E-9B8B-25C3F620EFED.HTML
Nutanixは、Oplog (永続的な書き込みバッファ)を含むすべてのデータにデータ削減機能を適用し、構成(ハイブリッドまたはオールフラッシュ)に関係なく、最大量のホットデータがフラッシュに保存されるように動作します。
データ削減機能を無効にするにはどんなオプションがありますか?
下の表は、お客様がデータ削減機能を一部、もしくは全部を無効にする際のオプションを示しています:
データ削減を無効にする際のオプション | Nutanix | VMware vSAN |
圧縮のみ | ✅ | ❌ |
重複排除のみ | ✅ | ❌ |
圧縮と重複排除 | ✅ | ✅ |
先に述べたように、vSAN の場合、圧縮と重複排除は「オール・オア・ナッシング」です。一方では良い圧縮率(>1.5:1など)が得られるかもしれませんが、他方ではレイテンシの影響が大きいか、重複排除率が低いかもしれません。vSAN の場合、選択の余地がないため、パフォーマンスと容量効率のどちらかで妥協をする必要があります。
これでは、グローバル・メタデータのオーバーヘッドと効率性に関するVMwareの反論は無意味なものになってしまうでしょう。
余談:vSANが圧縮と重複排除をサポートする前のことです。私はオーストラリアのシドニーで開催されたvChampionsのイベントに参加していました。そこでは「大容量のSATAドライブは低コストであるため、そのような機能は必要ない」主張されていたのを鮮明に覚えています。もちろん、私たちはバカではありません。VMwareが、Nutanixや従来のストレージアレイに対抗するために、データ効率を高める機能を実装するまでの時間を稼ぐための口実に過ぎなかったことは、誰もが知っています。
Nutanixでは、これらの設定をリアルタイムにオン/オフを切り替えることができます。また、容量効率とパフォーマンスの最適なバランスを確保するために、きめ細かい粒度で設定を行うことができます。
VMware はまた、グローバル重複排除はストレージコントローラ(CPU/RAM)リソースにコストがかかると主張しています。それ自体は公平に見て間違ってはいませんが、誤解を招きます。ベンダーに関係なく、すべてのデータ効率化には常にコストと利点があります。重要なのは、「コスト」からのリターンが何なのか、そのコストに見合う価値があるのかということです。
こちらがNutanix Controller VM (CVM)のコストとリターンについての記事です。
VMwareは重複排除にはオーバーヘッドがあることを正しく認めています。このためメリット(顧客によって異なる)とオーバーヘッドを比較して検討する必要があります。しかし、VMwareの実装では、重複排除は圧縮と同時に有効にしなければならず、さらに悪いことに、クラスタレベルで有効化しなければなりません。これが設計段階でゴールになっていたとは想像できませんが、vSAN の基盤となるアーキテクチャ上の制約を考えると、利用可能な最良の実装がこれだった可能性は高いと思います。
グローバルなメタデータが「コストがかかりすぎる」ということがVMwareがグローバルな重複排除を行わない本当の理由だとしたら、なぜノード単位ではなく「ディスクグループ」単位のソリューションを採用したのかという疑問が湧いてきます。ノード単位の重複排除にはグローバル・メタデータは不要ですし、ノード単位の重複排除のコンセプトには、現在のvSAN実装の欠点のすべてではないにせよ、帳消しにできるだけのいくらかの本当のメリットがあると思うからです。
VMwareがvSANの重複排除に制限をかけている本当の理由が「障害領域」のためでしたら、それなりのメリットがあるかもしれませんが、vSANアーキテクチャはすでにディスクグループの概念によって制約を受けています。vSANは、純粋なアーキテクチャ設計の目標とはうらはらに、ディスクグループごとの重複排除に制限されていると言う方が現実的です。私の意見では、これは意味をなしません。
vSANがNutanix ADSFのような完全な分散型ストレージソリューションではないという事実と合わせて考えると、グローバルな重複排除をサポートするためだけにvSANにグローバルなメタデータレイヤーを実装することは、リソースを大量に消費し、1つの機能だけでは到底正当化できない製品の複雑さをもたらす可能性が高いというのが本当の理由だと思います。
Nutanixは最初期からグローバルなメタデータを使用して設計されているため、既存のアーキテクチャをそのまま拡張してグローバル重複排除を実装することは当然の選択でした。
Nutanixを使えば、重複排除のコストがメリットに見合わないと感じた場合でも、圧縮とイレイジャーコーディング(EC-X)のメリットを享受することができ、重複排除をその場で無効化することができるので、すでに学んだようなデメリットはありません。
繰り返しになりますが、vSANでは重複排除だけをオフにすることはできません。ですから、重複排除(グローバルかどうかに関わらず)はコストがかかりすぎるという主張は少しばかげています。vSANではコストがかかる可能性のある2つの技術(圧縮と重複排除)を一緒に使うことを強制しているのです。多くの場合は、どちらか一方だけを使いたい、両方一度には使いたくないにも関わらずです。vSANで圧縮が適用されるのは、2:1 以上の比率で圧縮可能なデータセットの場合のみであることにもご注意ください。顧客が圧縮のためのコストを支払ったとしても、リソース投資に対するリターンを得られるのは、データセットが2:1以上の比率で圧縮可能な時だけです。
そうは言っても、重複排除はおそらくエンタープライズストレージの中で最も過大評価されている機能であり、一部のベンダーが主張しているような約束事が提供されることはほとんどありません。Nutanixは、メタデータのクローン(ESXiではVAAI-NASで、AHVではネイティブで)や書き込みパスのゼロサプレッションなどの技術を駆使して、大幅なレベルのスペース効率化を実現しています。結果として、見かけ上は重複排除の削減効果は、誤解を招くような数字を表現をする他のベンダーに比べると少なく見えるかもしれません。
こうした事実に基づいて、私は多くの場合顧客に重複排除を無効にしたままにすることをお勧めしています。圧縮とイレイジャーコーディング(EC-X)による削減とメタデータのクローン、サイロの撤廃、ゼロサプレッションを組み合わせることで、最小限のリソース使用で優れた技術的・ビジネス的成果が得られるからです。
顧客が重複排除による大きな節約が報告されているのを目にするとき、多くの場合それはミスリードされたレポートによるものです。例えば、スナップショットやメタデータコピーを、重複排除として報告するなどです。重複排除比率 - レポートされる比率には何を含めるべきでしょうか?
データ削減機能を無効にするとどのような影響がありますか?
VMwareは、ストレージベースのポリシー管理(SBPM)により、設定を変更するだけでデータ効率とデータ保護(FTT vs RAID5/6)の決定が容易になると、しばしば宣伝しています。設定を変更できるのは事実ですが、その変更はクラスタのパフォーマンスや回復力に大きな影響を与えるため、慎重に検討する必要があります。そのため、多くの顧客がメンテナンスウィンドウの間にだけこれらの変更を実行するようになりますし、ほとんどの場合、時間の長さと影響の大きさため、営業時間外に実行される事になります。
以下の表は、vSAN上で圧縮と重複排除を無効にした場合の4つの大きな影響を示しています。いずれもNutanixには適用されません。
影響 | Nutanix | VMware vSAN |
(1) ディスクグループからのデータの完全退避 | ||
(2) ディスクフォーマットの変更 |
| |
(3) ディスクグループのキャパシティはオペレーション中には使用できない |
| |
(4) 一時的な回復力の低下 |
|
以下はVMwareのドキュメントからの引用です。上記のチェックリストの内容が正しいことを確認できます。
vSANはデータは全て退避し、ディスクフォーマットを変更、キャパシティは使用不可になります(ディスクグループを削除):
重複排除と圧縮を無効にしている間、vSAN はクラスタの各ディスク グループのディスク フォーマットを変更します。ディスク グループからデータを退避させ、ディスク グループを削除し、重複排除と圧縮をサポートしないフォーマットで再作成します。
この操作に要する時間は、クラスタ内のホスト数とデータ量によって異なります。タスクとイベントタブで進行状況を監視することができます。
vSANでは一時的に信頼性が失われます:
その結果、重複排除と圧縮のためのフォーマット変更中に一時的に仮想マシンがデータ損失のリスクにさらされる可能性があります。vSANは、フォーマット変換が完了した後、完全なコンプライアンスと冗長性を復元します。
一方、Nutanixでは、動的な変更が可能なので、これらすべての欠点は当てはまりません。変更プロセスはキュレータによって優先度の低いタスクとしてハンドリングされて、時間をかけて処理されます。一方、新しい書き込みに対しては、設定が即座に反映されます。
データ削減技術を用いた際の信頼性の考慮点について議論しましょう
vSANでは、データ削減の技術を使用するため、大幅に障害の影響を増加させます。以下のデータの信頼性回復のシナリオは、これらの制約を受けないという、Nutanixの利点が際立っています。
データの信頼性 | Nutanix | VMware vSAN |
データ効率設定変更時にデータの信頼性に影響がない(OnのときもOffのときも) | ✅ | ❌ |
1台のドライブ(キャパシティ/キャッシュ)に障害が発生した場合、障害が発生した1台のドライブのデータのみが失われる | ✅ | ❌ |
ドライブを削除または追加しても、他のドライブには影響をあたえない | ✅ | ❌ |
ライトキャッシュ/バッファ用のドライブの障害により、複数のドライブが使用できなくなることはない* | ✅ * | ❌ |
キーポイント: Nutanixでは、データ効率の設定/変更の結果としてデータの信頼性が損なわれることはありません。
以下の引用文では、vSANの障害シナリオを明確にしています:
キャパシティ ディスクで障害が発生すると、ディスク グループ全体が使用できなくなります。この問題を解決するには、障害が発生しているコンポーネントをただちに識別して置き換えます。障害が発生したディスク グループを削除する際は、データの移行なし] オプションを使用します。.
最小の圧縮率
vSAN は、4kb ブロックが 2kb以下に圧縮される場合にのみデータを圧縮します。(重複排除の実施後に) つまり、データが2:1以上の比率で圧縮可能でない限り、vSANを利用するお客様は圧縮による容量の節約ができません。
Nutanixの最小圧縮率は現在30%です。ですから、Nutanixのお客様は、2:1以上圧縮だけではなく、1.3:1以上の圧縮を達成するデータセットでは、容量的に大きなアドバンテージを得ることができます。
30%が低すぎるというのは、あまり議論は必要ではないと思っています。私の個人的な意見では1.3~1.5:1がおそらくスイートスポットだと思います。vSAN の 2:1 が、顧客から大幅なデータ削減の機会を奪っていることについては、大いに議論すべきでしょう。
データ効率化の優位性の計算例
最後に、より多くの使用可能容量とより包括的なデータ削減技術を組み合わせたNutanixの利点が、顧客にとってどのように見えるか、簡単な計算をしてみましょう:
前回の記事では、Nutanix ADSFとVMware vSANの間の使用可能な容量の例として、16ノードのクラスタの例を紹介しました。Nutanixは、RF2/FTT1構成の場合、71TBの実効容量でした。vSANは41TBの実効容量でしたので、比較すると41.25%の優位性を持っていました。
Nutanix RF2 (FTT1) 利用可能な容量 | 71.34 |
1.5:1のデータ削減 | 107.01 |
2:1 のデータ削減 | 142.68 |
20%の追加データ削減効率 | 171.22 |
|
|
vSAN FTT1 (RF2) 用可能な容量 | 41.91 |
1.5:1のデータ削減* | 62.87 |
2:1 のデータ削減 | 83.83 |
|
|
Nutanixの実効容量(TB)の優位性 |
|
1.5:1* | 44.14** |
2.0:1 | 58.85** |
2.0:1 + 20%の追加データ削減効率 | 87.39 |
** 当初掲載時に計算ミスがあったので値を更新しました。
Nutanixは利用可能な容量の優位性が大きいため、vSAN と同じ比率でデータを削減した場合でも、実効容量の優位性が大幅に高くなることがわかります。
データ削減がグローバルに、永続的な書き込みバッファ (vSAN のキャッシュ層に相当) や圧縮率が2:1未満の場合適用されるNutanixの優れたデータ削減アーキテクチャによる優位性を、控えめに20%と仮定しましょう。その場合、Nutanixの実効容量の優位性は、vSANのデータ削減後の使用可能容量の合計と比較して、87.39TB多いことがわかります。(87.39TBは合計ではなくNutanixとvSANの実効容量の差分です)
この例では、Nutanixは171TBの使用可能な容量(RF2/FTT1)を提供していますが、vSANは83.83TBしか提供していません。使用可能な容量はNutanixよりも約50%も少なくなります。
顧客がvSANの信頼性の問題について認識している場合、信頼性を向上させるためにvSANのデータ削減技術の一部または全部を使用しないと決定する可能性があることを考えてみましょう。そうなるとNutanixの優位性はさらに大きくなります。
まとめ:
ここまでで、両方の製品で同じ機能がサポートされているように表現されたマーケティングのスライドや、営業資料が非常に誤解を招くことを解説してきました。
この記事では、データ削減技術の実装に関するさまざまな要素と、その基盤となるアーキテクチャが、これらの機能の実際の価値にどのように大きな影響を与えるかを取り上げてきました。
Nutanixが、データ削減を適用しない場合でも、vSANに対して20~40%以上の使用可能な容量の優位性を持つとしたら、データ削減機能によって達成された削減比率は(たとえそれが vSAN が達成したのと同じ比率であっても)、Nutanixの優位性を高めるだけです。さらに Nutanix はストレージのすべての層にデータ削減を適用しているので、差は広がるばかりです。
明らかな容量の利点はさておき、Nutanixはデータ削減技術を使用する際に信頼性を妥協することなく、再フォーマットや大きなバックエンドのオーバーヘッドなしに、これらの機能をきめ細かく有効化/無効化できるようにしています。
データ削減技術を使用した結果、データの回復力が損なわれることがあったのであれば、それは控えめにも有効な実装とはいえません
データ削減技術を最速かつ最も高価なストレージ層(例:NVMeやエンタープライズグレードのSSD(例:vSANのキャッシュ層))に適用できない場合、顧客は、非常に大きなパフォーマンスの向上とROIを失うことになります。高価なストレージにより多くのデータを保管できないからです
データ削減を有効にすると、vSANディスクグループ(1つのキャッシュと最大7つの容量のドライブ)で単一のドライブ障害が発生した場合でもディスクグループ全体がオフラインになり、再構築が必要になります。得られるメリットはリスクに見合うものではありません。
Nutanixは最初期より多額の投資を行い、完全な分散型ストレージファブリックを構築しました。vSANのような未発達の製品と比較して、物理容量と比較してより多くの実効容量を実現しただけでなく、Nutanixはデータ効率化技術を実装して効率性をさらに高め、顧客に柔軟性を与えることができるようになりました。
次の記事では、イレイジャーコーディングの比較 - Nutanix ADFS vs vSANを取り上げます。