本記事はJosh Odgers氏が2020年8月21日に投稿した記事の翻訳版です。
このシリーズのパート2とパート3では、Nutanix ClustersとVMware VMConAWSで同じAWSベアメタル（i3.metal）ハードウェアを基盤として使用した場合に、Nutanix Clustersのほうが使用可能な容量が多くなることを紹介しました。
次に、データ効率テクノロジーと回復力に関する考慮事項を比較し、容量効率、柔軟性、回復力、パフォーマンスに関してNutanix ClustersがvSANよりも明らかに優れていることを紹介しました。
パート5では、Nutanix Clustersがストレージデバイス（NVMe SSD）のデバイス障害をどのように処理するかについて、パート6ではベアメタルインスタンスの障害の場合について紹介しました。両方の場合とも、Nutanix ClustersはVMC/vSANよりも影響が小さく、Nutanixの基盤となる分散ストレージファブリック（AOS）のおかげでデータ整合性と回復力を短時間で回復できます。
パート7では、コントローラーVM（CVM）にNutanix Clusters（AOS）が実装されるため、ストレージI/Oパスでハードウェアやソフトウェアの問題が発生しても、VMCよりも回復力が高く、影響が小さいことを紹介しました。VMCでは不要なHAイベントがノードに発生し、大きな影響が生じます。
AWS EC2では、NutanixやVMwareなどのベンダーはハードウェア層を制御できないため、ストレージ容量を拡張するには、シンプルに、環境にベアメタルインスタンスを追加します。
どちらの製品の場合でも、ストレージ容量要件に対応するには、新しいベアメタルインスタンスを追加するだけで済むとも言えます。
本当にそれだけでしょうか。いいえ、そうではありません。
実は、どちらの製品においても、新しい容量を実際に使用するためには時間と労力が大幅にかかります。
VMC/vSANの問題1 – 新しいノードをVMCクラスターに追加しても、新しいノードのストレージリソースは既存の仮想マシンの使用可能な容量（またはパフォーマンス）に追加されません。
どういうことだろうか、とお思いになりますよね。
例えば、4ノードのVMC/vSANクラスターを使用しており、VMC環境に4つのノードを追加する場合、新しい仮想ディスクが作成される（データはその新しい仮想ディスクに手動で移動します）、もしくは管理者がクラスターリバランス操作を手動で実行してクラスター内のすべてのノードにラージオブジェクトを分散するまで、仮想マシンで新しい容量を使用することはできないのです。
VMwareはそのドキュメントで、この問題を認めています。
（vSAN）クラスターの容量を拡張してから、手動リバランスを実行してリソースをクラスター全体に均等に配分します。詳しくは、『vSAN Monitoring and Troubleshooting』の「Manual Rebalance」を参照してください。
このため、VMC/vSANでは、vSANクラスターのリバランスを使用するか、または自動リバランスを構成する必要があります。vSANクラスターのリバランスでは、クラスターが80%に到達するとクラスターのリバランス（リアクティブリバランス）が開始されます。VMwareによると、自動リバランスはパフォーマンスに影響するため、場合によっては自動リバランスをオフにする必要があります。
デフォルトでは、vSANはディスクグループのデータを自動的にリバランスします。自動リバランスの設定を構成できます。
デバイスのI/Oパターンが不均等になったり、ホストやキャパシティデバイスを追加したりすると、vSANクラスターがアンバランスになることがあります。クラスターがアンバランスになった場合、vSANは自動的にディスクのリバランスを実行します。この処理により、使用率の高いディスクのコンポーネントが使用率の低いディスクに移動されます。
自動リバランスは有効/無効の切り替えができ、自動リバランスがトリガされる偏差のしきい値も設定できます。クラスター内の任意の2台のディスク間でキャパシティの偏差がリバランスのしきい値を超えると、vSANはクラスターのリバランスを開始します。
ディスクのリバランスは、vSANクラスターのI/Oパフォーマンスに影響を与える可能性があります。このパフォーマンスへの影響を回避するために、ピークパフォーマンスが必要な場合は自動リバランスをオフにできます。
vSANのリバランスは、オブジェクト/コンポーネントレベルで自動または手動で実行される後処理（リアクティブ）操作であるため、それほどきめ細かくなく、大量のデータを移動する必要があります。VMwareによると、パフォーマンスが大幅に低下するため、場合によってはオフにする必要があります。
vSANで容量管理を実装する場合、容量とパフォーマンスのどちらを取るのか妥協する必要があります。重複排除と圧縮の両方をオンまたはオフにすることや、イレージャーコーディングを再度オンにしてすべてのデータにインラインで適用するか、またはオフにすることとよく似ています。
運用面において、vSANアーキテクチャーが基盤となっているということは、VMC環境の容量管理は人々が認識しているよりも大幅に複雑だということです。また、クラスターリバランスが意味することは、貴重な人的リソースの時間と労力が無駄に使われるということです。Nutanix Clustersでは、これらすべてが自動かつ動的に実行されます。
Nutanix Clustersでは、書き込みパス（別名「インライン」）にプロアクティブでインテリジェントなレプリカ配置を使用することで、個々のノード/ドライブの容量とパフォーマンス使用状況に基づいて新規データがリアルタイムに配置されます。
その結果、クラスター全体でバランスが均等になるように、新しいノードがただちに動的に利用されます。これにより、回復力とパフォーマンスが向上し、以前に紹介したようなフラグメンテーションや使用不可能な容量の発生を避けることができます。
また、クラスターのバランスが大幅に不均衡になった場合に適用される後処理のディスクリバランスの必要性は最低限になり、このディスクリバランスのワークロードも最小限に抑えられます。おもな違いは、Nutanixではオブジェクト（最大255GB）レベルではなくエクステントグループ（4MB）レベルでバランシングが実行される点です。そのため、移行が必要となるデータの量が少なくなり、非効率なフラグメンテーションがほぼゼロになります。
VMC/vSANの問題3 – VMC/vSANクラスターの規模の拡張につれて、空き容量のオーバーヘッドが25～30%で固定になるため（スラックスペース）、スケールメリットがありません。
4ノードクラスターの25%はN-1であり、Nutanix Clustersと同じです。ただし、5ノードクラスターで比較すると、VMC/vSANでは相変わらず25～30%必要ですが、NutanixではN-1、つまり20%しか必要ありません。Nutanix Clusterでは即座に5%のメリットが得られます。
クラスターの拡張につれて、Nutanixでは回復力のオーバーヘッドはN-1のままになります。つまり、減った分の容量パーセントを予約する必要があります（スケールメリット）。これに対してVMCでは、16ノード（VMCの現状最大値）の場合でも25%（最小値）のままで、これはN-4に相当します。
16ノード以上の場合、個人的にはNutanix環境にN-2を推奨します（引き続きRF2を使用）。つまり、Nutanix Clustersでは、VMC/vSANよりも高い回復力を維持しながら、クラスター操作にVMC/vSANの半分の容量しか必要ありません。
Nutanix Clustersにノードを追加すると、既存のVMのパフォーマンスがただちに向上します。Nutanixでは、データ送信に使用される物理ストレージデバイス（NVMe SSD）が増え、それに加えて、分散ストレージファブリックのワークロードを処理するコントローラーVM（CVM）が増えるためです。
それに対してVMC/vSANでは、新しいハードウェアを利用するためには、その前に大幅な保守操作が必要です。
ここまで紹介してきたことを以下にまとめます。
| 機能 | Nutanix | VMware vSAN |
| 容量のインライン（リアルタイム）バランシング |
|
|
| パフォーマンスに基づいたインライン（リアルタイム）バランシング |
|
|
| きめ細かいレベル（4MB）での完全自動の後処理バランシング |
|
|
* VMC/vSANでは、ストレージデバイスの使用率が80%以上の場合は自動的にバランシングが実行されますが、このバランシングはラージオブジェクトレベル（最大255GB）で実行されます。
両方のプラットフォームについて、ストレージ容量を拡張する機能について以下にまとめます。
| パブリッククラウドの機能 | Nutanix Clusters | VMware VMC/vSAN |
| 容量をリアルタイムで増やす |
|
|
| パフォーマンスをリアルタイムで高める |
|
|
| 効率をリアルタイムで高める |
|
|
| プロアクティブな（インラインの）ディスクバランシング |
|
|
| リアクティブな（後処理の）ディスクバランシング |
|
|
* VMC/vSANデータベースの容量は技術的には増えますが、リバランス操作が完了するか新しいVM/vDiskが作成されるまで、容量は使用されず、使用可能になりません。
** デフォルトでは、ストレージデバイスの使用率が80%を超えた場合にのみ適用されます。
パフォーマンスがリアルタイムで向上するというのは、2016年7月に行ったStorage Onlyノードを使用したスケールアウトパフォーマンステストで実証されています。このテストでは、4ノードクラスターで4つのワークロードを実行してから、4つのノードを追加しましたが、IOPSが2倍になり、読み取りレイテンシーと書き込みレイテンシーが短くなりました。ノードを追加する以外は、仮想マシンやクラスターに変更は加えていません。
ブラックフライデーや月末処理などのピーク期間を想像すると、すべてのNutanix顧客は、ビジネスクリティカルなワークロードのパフォーマンスを向上するには、環境にノードを追加するだけで済みます。データベース管理者（DBA）などのアプリケーションスペシャリストの手を煩わせる必要はありません。
まとめ
「チェックボックス」形式のマーケティングスライドや基本レベルで比較すると、どちらのプラットフォームも同じ機能を備えています。ただし、実際の機能はマーケティングスライドに記載されている機能とは大きく異なるため、隠れているものに目を向けることが重要である、ということを紹介しました。
Nutanix Clusters（AOS）では、手動で操作せずにノードを追加してストレージ機能を拡張できるため、顧客に真のパブリッククラウドエクスペリエンスと成果をもたらします。
さらに、Nutanixを使用する場合、環境の拡張に応じて、パフォーマンスと回復力が向上し、すべてのデータ効率テクノロジーを利用でき、これらの利点を妥協なしに享受できます。（重複排除、圧縮、イレージャーコーディングのページをご参照ください。）.
VMCはvSANをベースとしているため、効率性とパフォーマンスを維持しながら容量（または回復力）を拡張できるような基盤テクノロジーを備えていません。