本記事はJosh Odgers氏が2020年8月19日に投稿した記事の翻訳版です。
パート1では、パブリッククラウドで環境の価値を高めるために、使用可能なネットワーク帯域幅を効率よく利用することがどれだけ重要なのかについて紹介しました。また、使用可能な帯域幅を最大限に確保すると、フラッシュデバイス（NVMe/SSD）の障害の場合にMean Time To Recover（MTTR：平均修復時間）が短くなり、回復力がどれほど向上するかについても紹介しました。
ベアメタルインスタンス（サーバーとノード）の障害の場合にも同じ概念が当てはまります。ただしこの場合は、完全なデータ整合性を回復するためには、単一の1.9TB NVMeデバイス（i3.metalの場合）ではなく8つの1.9TB NVMeデバイスのデータを再保護する必要があります。
そのため、リビルドをタイムリーに実行して影響を最小限に抑えるためには、効率的でスケーラブルなアーキテクチャーであることが重要です。
まずVMware VMCについて、リビルドの基盤となるアーキテクチャーについて紹介します。
VMC（vSANがベース）では、オブジェクト（最大255GB）がリストされるのは、オブジェクトがホストされているソースノード上のキャパシティドライブから、クラスター内の他のノード上のキャッシュドライブ（ディスクグループ当たり1つ）に対してだけです。
AWSで、よく使用されているi3.metalインスタンス（8 x 1.9NVMeデバイス）を使用する場合、VMCのリビルド操作では主に2つのNVMeデバイス（2つの「キャッシュ」ドライブ）しか使用されず、キャッシュドライブが一杯になると、残りの3つのNVMeデバイス（ディスクグループ当たり）にリビルドデータが排出されます。
つまり、VMwareのVMCを使用する場合、重要なリビルドトラフィックではリビルド用にNVMeドライブの20%しか使用されません。
そのため、パート2とパート3で紹介したように、VMCでは使用可能な容量が少なくなるだけでなく、回復力とパフォーマンスの観点でハードウェアが効率よく使用されないため、明らかにVMCプラットフォームの価値が下がります。
VMC/vSANでは、クラスター内の使用可能なハードウェアが最大限に利用されないため、結果的に以下のようになります。
- 回復力（データ整合性）を元の状態に戻すのに長い時間がかかる。
- データがリスクにさらされる時間が長くなる（構成されているFTTに適合していない）。
- VMC/vSANでは、限られた800GBの書き込みキャッシュドライブ経由で大量のデータが送信されるため、パフォーマンス上の影響が大きくなる。
- VMCでは最大75%の容量利用が推奨されているため、フラグメンテーション（使用不可能な容量）が発生する可能性が高くなる。
- リビルド操作時に新しい書き込みI/Oがストレージポリシーに従っていない可能性があり、さらに多くのデータがリスクにさらされる。
VMC/vSANのリビルドアーキテクチャーは効率性が低く、2つのキャッシュドライブ（i3.metalインスタンス内）がキャパシティデバイスよりも過度に酷使されます（従来のRAID「ホットスペア」と似た状態となります）。
そのため、リビルド操作中に障害が引き続き発生するリスクが高くなり（従来のRAIDスタイルのリビルドの場合と同様）、データが使用不可能になったりデータ損失が発生したりする可能性があります。
キャッシュドライブ障害の影響が極めて大きい（ディスクグループ全体がオフラインになる）ことを考えると、VMCのリビルドアーキテクチャーは不要な危険を伴うと言えます。
VMwareが6ノード以上のクラスターにはデュアルパリティのRAID6を推奨しているのは、このように大幅にリスクが高いためです。ただし、この推奨に基づいてVMC/vSANの回復力の問題を軽減するには、使用可能な容量やパフォーマンスがすべてのワークロードでさらに低くなるという大きな犠牲が伴います。
AWS上で同じi3.metalインスタンスを使用する場合、Nutanix Clustersのリビルド操作では、クラスター内のすべてのノードのすべてのNVMeデバイスが使用され、Nutanixの効率的な書き込みパスやインラインディスクバランシングのおかげで、キャッシュ層のデータをキャパシティ層に排出する必要性が抑えられます。このような排出はレガシーな概念であり、Nutanixではハイブリッド（フラッシュ + HDD）環境でのみ使用されています。
つまり、Nutanix Clustersでは使用可能なNVMeドライブ8つすべてがリビルドに使用されるため、ホットスポットやドライブの摩耗が最小限に抑えられ、リビルド操作中に障害が引き続き発生するリスク（データが使用不可能になったり損失したりするリスク）がさらに小さくなり、MTTRが可能な限り短くなります。
これが可能なのは、Nutanixはディスクグループの概念の制約を受けず、クラスター内のすべてのドライブを使用して単一のストレージプールが構成されるためです。
Nutanix Clustersでは、クラスター内の使用可能な容量がフラグメント化しないように、また、プロセス全体でパフォーマンスを最適にするように、リビルドデータがクラスター全体に動的に分散されます（すべてのフロンドエンドで書き込みIOで実行しているのと同様です）。
そのため、Nutanix Clustersでは、キャッシュのリビルドデータをキャパシティ層に排出するという後処理は必要ありません。このような後処理は不要で面倒なタスクであり、高度な分散ストレージソリューションを使用すれば不要です。
この高度な分散ストレージアーキテクチャーによって、顧客は対価を支払っているハードウェアを最適に活用することができ、ROIを最大限に高めつつ、TCOを最小限に抑えることができます。
以下の図は、ベアメタルインスタンスの障害発生後、完全な分散操作の結果として、Nutanixにおいていかに短時間でリビルドできるかを示す良い例です。
ベアメタルインスタンスに障害が発生した場合、書き込みI/Oの整合性は維持されるのか
VMC/vSANでは、Failures to Tolerate（FTT）ポリシーを構成しても、リビルド操作が完了するまで、新しい書き込みI/Oが保護されるとは限りません。
簡単に言うと、VMC/vSANでは、ベアメタルインスタンスやドライブに障害が発生した場合、データの整合性が得られません。
ストレージでは、「データの整合性がない」ということは「本番環境への実用に適していない」ことを意味します。
Nutanix Clustersでは、ベアメタルインスタンス/ホストやドライブに障害が発生した場合、データ整合性は常に維持され、構成されている回復ファクタ（RF2またはRF3）に完全に適合するまで新しい書き込みはゲストに認識されません。
これは、実用最小限のストレージ製品での重要な機能であり、書き込みは冗長状態の永続メディアにコミットされるまで認識されてはなりません。VMCは（vSANをベースにしているため）、この本番クラスストレージに不可欠である要件に対応していません。
詳しくは、Nutanixの回復力について触れたシリーズの投稿の一つであるパート6の、保守時または障害時の書き込みI/Oに関する投稿をご覧ください。
まとめ
この投稿では、Nutanix Clusterのアーキテクチャーについて以下のことを紹介しました。
- クラスター内の使用可能なすべてのNVMeデバイスとベアメタルインスタンスが最適にリビルドに使用されます。
- Nutanix Clustersは、望ましい回復ファクタ（RF）を短時間で回復させます。
- データがリスクにさらされる時間が短くなり、Mean Time To Recover（MTTR：平均修復時間）が向上します。
- 次の理由から、パフォーマンスへの影響が小さくなります。
- 操作がすべてのドライブに分散されて実行されます。
- キャッシュからキャパシティドライブにデータが排出されないように処理されます。
- リビルドでは、処理後のディスクバランシングを実行せずに済むように、リビルド時にデータが最適な場所に配置されるため、ディスクバランシングの問題が最小限に抑えられます。
- Nutanixのリビルド操作は、障害に関係なく即座（1分未満）に開始されます。
- リビルド操作では、「キャッシュ」ドライブのサブセットではなく、基盤となるすべての物理フラッシュ（NVMe）デバイスが使用されます。
- Nutanixでは、リビルドデータの書き込みは「キャッシュ」ドライブで強制的に実行されないため、後続のバックエンドIOが回避されます。
- Nutanixでは、すべてのノード障害やホスト障害のシナリオにおいて、書き込みI/Oの整合性が常に維持されます
- Nutanixでは、構成されている回復ファクタに対してノードが不足し、クラスターが機能低下状態になっている場合でも、引き続きデータがリビルドされます。
次に、VMCとNutanix ClustersのI/Oパスを比較し、それぞれの製品アーキテクチャーの回復性への影響を比較します。