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

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

このシリーズでは、重複排除と圧縮、およびイレイジャーコーディングを使用する際に、Nutanixがより多くの使用可能容量を提供し、容量効率性、柔軟性、回復力、およびパフォーマンスを向上させることを学んできました。

また、Nutanixははるかに簡単かつ優れたストレージのスケーラビリティを提供し、ドライブやノードの障害による影響を大幅に軽減していることもわかりました。

このパートでは、NutanixのAOS（Acropolis Operating System）とVMwareのvSAN（Virtual SAN）における、ストレージ層のアップグレードなど、Day 2 オペレーションで重要となるトピックを取り上げます。

双方のプラットフォームでどのようにアップグレードが実行され、これらのアップグレードが環境にどのような影響を与えるかを議論していきます。

まずは単純な「チェックボックスの比較」から始めてみましょう。

以前の記事でも強調しましたが、「チェックボックス」スタイルのスライドは、製品の能力に関するミスリーディング引き起こしがちです。この問題は、アップグレードなどのDay 2 オペレーションについても大いに当てはまります。

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

例1：AOSやvSANの新バージョンへのアップグレード

チェックボックスの比較を見ると、両製品とも"停止を伴わないストレージのアップグレード"ができることがわかります。この議論のために、以下のシンプルな定義を使用します。

「停止を伴わないストレージのアップグレード」とは、仮想マシンが停止することなく、ソフトウェア定義ストレージ層のアップグレードを実行できることです。

NutanixとvSANの双方において、仮想マシンが停止することなくアップグレードを実行できるのは事実ですが、仮想マシンとクラスタの可用性/パフォーマンスとデータの整合性にはどのような影響があるのでしょうか？

Nutanix のクラウド時代のハイパーバイザーであるAHVを用いて比較を行ってしまうと、vSphere スタックをアップグレードするような複雑さがNutanix のソリューションにはないため、全く異なった議論になってしまいます。

しかし、今回の比較ではこのシリーズの流れに沿って、より公平な比較を行うために、ストレージ層だけに焦点を当てます。この点から、NutanixとvSANは双方とも(訳注:ハイパーバイザーには)VMwareスイートを使用するものと仮定します。

まずはvSANから見ていきましょう：

VMwareのドキュメントによると

vSAN クラスタのメンバーであるホストは、シャットダウン、再起動または切断する前にメンテナンス モードにする必要があります。ホストをメンテナンス モードにする場合、�アクセシビリティの確保] や :全データの移行] などのデータ退避モードを選択する必要があります。
引用元: https://docs.vmware.com/jp/VMware-vSphere/6.7/com.vmware.vsphere.virtualsan.doc/GUID-521EA4BC-E411-47D4-899A-5E0264469866.html

また、「データの移行なし」という選択肢もあります。

それぞれのオプションを確認してみましょう。

アクセシビリティの確保 (デフォルト)

デフォルトのオプションです。 クラスタでホストをパワーオフまたは削除すると、vSAN によってこのホストのすべてのアクセス可能な仮想マシンはアクセス可能なままになります。アップグレードをインストールするときのようにホストを一時的にクラスタから外して後で戻す場合に、このオプションを選択します。 このオプションは、クラスタからホストを恒久的に削除する場合には適切ではありません。

通常、部分的なデータ退避だけが必要です。 ただし、退避中は、仮想マシンが仮想マシン ストレージ ポリシーに対して完全準拠ではなくなる可能性があります。 つまり、一部のレプリカにアクセスできなくなることがあります。 ホストがメンテナンス モードになっており、 �許容されるプライマリ レベルの障害数] が 1 に設定されている場合に障害が発生すると、クラスタでデータが損失する可能性があります。

注： 3 台のホスト クラスタ、または 3 つのフォールト ドメインが構成されている vSAN クラスタを使用している場合、これは使用できる唯一の退避モードです。

全データの移行:

vSAN は、すべてのデータをクラスタ内の別のホストに退避させ、影響を受けるコンポーネントの可用性のコンプライアンスを維持または修正し、クラスタ内に十分なリソースがある場合にデータを保護します。このオプションはホストを恒久的に移行する場合に選択します。 クラスタの最後のホストからデータを退避させたら、必ず仮想マシンを別のデータストアに移行してホストをメンテナンス モードにします。

この退避モードにすると、大量のデータが転送され、時間とリソースの消費が最も多くなります。選択したホストのローカル ストレージ上のすべてのコンポーネントは、クラスタの別の場所に移行されます。ホストがメンテナンス モードになっている場合、すべての仮想マシンはそのストレージ コンポーネントにアクセスでき、これに割り当てられたストレージ ポリシーに引き続き準拠します。

 

データの移行なし:

vSAN はこのホストからデータを退避させません。クラスタからホストをパワーオフまたは削除した場合、仮想マシンによってはアクセス不能になる可能性があります。

 

vSAN オンディスクフォーマットのアップグレード:

VMwareのドキュメントによると

ディスク グループは一度に 1 つずつアップグレードされるため、ディスク グループのサイズによってはディスク フォーマットのアップグレードに時間がかかる場合があります。 各ディスク グループのアップグレードでは、各デバイスにあるすべてのデータが退避し、vSAN クラスタからディスク グループが削除されます。その後、新しいオンディスク フォーマットの vSAN に、ディスク グループが再び追加されます。

引用元:

https://docs.vmware.com/jp/VMware-vSphere/6.7/com.vmware.vsphere.virtualsan.doc/GUID-08728A9E-88E0-4CEB-9764-E828719DA927.html
(※訳注:著者が引用しているページが引用元サイトのリニューアルによって削除されているため、同等の内容が記述されている製品ドキュメントページの引用に差し替えています)

この仕組みには大きな問題点があります。例として、環境への影響を考えてみます。ディスクグループ内のデータセット全体(10TB以上となることも珍しくありません)をクラスタ内の別の場所に格納することで退避させる必要が生じてしまいます。

これこそが、vSANが25～30%という大きなスラックスペースを必要としている理由の一つです。このデータ退避処理の間、Write I/O の比較で学んだようにvSANでは、オブジェクトが移動されるVMのデータの整合性が、新規書き込みと既存データのどちらにおいても維持されていません。つまり、vSAN環境でFTT1 (Nutanixで言うところのRF2)を使用している場合、一定期間、既存データは1つのコピーしか保持されていない可能性があるということです。

ある程度の回復力を維持するために確実な方法は、vSAN Failure to tolerate (FTT)を1から2に増やすことです。 これにはかなりの容量オーバーヘッドがありますし、言うまでもなく性能低下も生じます（気にするほどではない場合もありますが）。

さらに、上位レベルのデータ保護を行うための「コスト」には、vSANホストのCPUオーバーヘッドや、特にvSANがデータローカリティ機能を持たないが故のネットワークトラフィックの増加も含まれます。なお、vSAN においてFTT1と比較してFTT2のために追加されるCPUオーバーヘッドは不合理なものではありません。実際、Nutanix ADSFもRF2と比較してRF3でより多くのCPUを利用します。

これらのオーバーヘッドが生じるにも関わらず、vSANをFTT2に設定したところで、vSANでは新規の書き込み（アップグレード中や、以前に説明したような障害発生中）に対しては障害を許容可能な状態が維持されません。

vSANやディスクフォーマットのアップグレード中（または障害発生中）に、ストレージポリシーの書き込みI/Oの整合性/コンプライアンスを、設定どおりに維持し続ける唯一の方法は、「全データの移行」オプションを使用することです。

ここでの重要なポイントは、Write IOとノード障害の比較で学んだように、vSANは必ずしも常に書き込みI/Oの整合性を維持しているわけではなく、この問題は「全データの移行」をしないままディスクフォーマットを変更した場合にも当てはまる、ということです。

vSANでは、5・10・20TBのホストのデータセットを完全に退避させるには、一般的に数分単位ではなく数時間単位の時間を要します。これは、3ノードクラスタでの「リソース枯渇」問題、クラスタ内のノードやディスクの不足、そしてお客様がホストをメンテナンスモードにした際の遅延が発生した、といった形でお客様から課題が報告されています。

これらはすべて、vSAN アーキテクチャの複雑さについての単純な例にすぎません。

アップグレードに時間がかかればかかるほど、メンテナンスウィンドウとコスト(OPEX)の枠内で作業をスケジューリングし完了できるかという問題は言うまでもなく、障害と性能への悪影響というリスクに長い間さらされることになります。

次にNutanix AOSのアップグレードがどのように動作するのかを説明します：

AOSのアップグレードは輪番で、一度に1つのController VM (CVM)で実行されます。CVMがオフラインになる前に、ホスト/ノードのストレージ接続はクラスタ内の他のノードに自動的にリダイレクトされます。

重要なポイント： ストレージのアップグレードはハイパーバイザーから独立しているため、ハードウェアの再起動やホストの退避は必要ありません。

CVMがアップグレードされている間、仮想マシンはそのままのホスト/ノード上で動作し続けます。CVMのアップグレードが完了すると、ストレージはローカルのCVMへ戻る形でリダイレクトされます。

Nutanixでは、AOSのアップグレード中は、vMotionは一度も必要ありません！なぜ vMotion を使わないことが重要なのでしょう？

なぜなら、vMotionを実行するために移行元と移行先の両方でCPU/RAMやネットワークなどのホストリソースを必要とするからです。また、vMotionには時間がかかり、メンテナンスウィンドウが長くなります。

ノードあたり100～200個のVDI VMがあるVDI環境を考えてみましょう。この場合、ホストをアップグレードする準備として100～200回のvMotionを行い、アップグレードされたノードにVMを戻すためにも100～200回のvMotionを行うことになります。

もう1つの例として、各ノードでは、そのノードのCPU/RAMの大部分を使用するようなミッションクリティカルなアプリケーションを数個（あるいは1つ）しか実行していないとします。この場合、大規模なVM、特にメモリ内の変化率が高いVMは、vMotion中にパフォーマンスへのペナルティを受ける可能性があることを念頭に置く必要があります。

ノードが適切にサイジングされ、適切な利用率となっている場合であれば、はじめにワークロードをノードから退避させ、後で元のノードに戻すためには、256GB、512GB、あるいは1TB以上のメモリをネットワーク経由で転送する必要があります。

vMotion の際には、VM/アプリケーションのパフォーマンスに対する影響は僅かであることが多いものの、VMが静止状態となる影響も存在します。

NutanixのVMに対する唯一の影響は、アップグレード中には読み書きI/Oが100%リモート(Nutanix特有のデータローカリティの利点が失われる)になることですが、この状態はそもそもデータローカリティの概念が存在しないvSANにおける正常動作と同じようなものです。

vSANでは、VMがvSANオブジェクトのホストされているノードで稼働しており正常動作している場合でも、読み取りI/Oの少なくとも50%がネットワークを介して送信されます。VMがディスクオブジェクトのないノードでホストされている場合、読み取りI/Oの100% がネットワークを横断しています。

Nutanixは今まで/今後も、ドライブやファイルシステムのフォーマットを変更/改善することがありますが、ドライブ、ディスクグループ、またはノードからの退避のような、データの一括移動を必要とすることはありません。

Nutanixは、長年にわたってメタデータ構造に多くの変更/改善を行ってきました。これらの変更を効率的に行うための仕組みを支える主要な仕組みは、当社のMapReduceフレームワークです。このフレームワークはメタデータを効率的にスキャンし、メタデータとデータの両方において、1MBのエクステントまたは4MBのエクステントグループの単位ですべての変換を実行します。

Autonomous Extent Store (AES)は、AOS 5.10で導入されたもので、ディスクのメタデータの保存方法を根本的に変えたものです。このコードは、1つのNutanix vdiskが両方のフォーマットのメタデータを扱えるように書かれています。このため、新しいデータは新しいフォーマットで書き込まれますが、古いデータは以前と同じように動作します。後続のリリースでは、MapReduceエンジンは、Nutanix Cassandraから各ノードのローカルなAES DBへのメタデータの移行を、ディスク上のデータへの変更や移行なしに処理します。

現時点でGA済みの製品では、個々のvDisksまたはVM全体を手動でAESに移行することができますが、これはデータの一括移動やノードまたはクラスタ内の利用可能な容量の損失なしに実行されます。この設定が考慮点として重大になるのは、継続的ランダム書き込み性能の最大化を必要とする上位5%のワークロードのみであり、大多数のワークロードはAESなしでも非常に良好なパフォーマンスを発揮します。

現在のGA済みリリースでは、すべての新しいコンテナとクラスタは自動的にAESが有効化されています。

例：4MBのエクステントグループとそのメタデータはAES形式に変換されます。容量オーバーヘッドは、vSANのディスクグループの場合のようにVM全体と同じサイズにはならず、4MBとなります。そして、この変換はNutanixのキュレータサービスによって優先度の低いバックグラウンドタスクとして行われます。

Nutanix ADSFのもう一つの大きな利点は、変換をクラスタ全体に分散したやりかたで処理できることです。メタデータやディスク上のデータの変換は分散処理され、vSANのように単一ディスクグループの速度/可用性によって制限を受けることはありません。

また、Nutanixは、AOSソフトウェアがVM内で実行され、ハイパーバイザーから抽象化されているため、(※訳注:AOSソフトウェアの更新と同時に)ハイパーバイザーをアップグレードする必要が無いことから、互換性、セキュリティ、信頼性の問題が少ないと言えます。

運用の複雑さとリスクを最小限に抑えるためには、ハイパーバイザーとストレージ層の間の抽象化を確実に行うことが重要です。

vSANとNutanixは、どちらの製品も「停止を伴わないアップグレード」ができると主張しているにもかかわらず、より詳細に比較してみると、アップグレードがどのように実行されるかという点では、大きく隔たっていることがわかりました。

まとめ

1. vSANでは、お客様が「全データの移行」オプションを使用しない限り、アップグレード中に書き込みI/Oの整合性が維持されません。このオプションは、環境内の空き容量（スラックスペース）を増大させ、アップグレードに時間がかかり、影響が大きくなる原因となります。
2. Nutanix ADSFでは常に書き込みI/Oの整合性を維持し、アップグレード中もデータを(vSANの「全データの移行」オプションのように)一括移動する必要がありません。
3. vSANでは、ストレージのアップグレードを実行するためにVMをホストから退避させる必要があります。
4. Nutanixでは、ストレージのアップグレードを実行するためにVMを退避させる必要はありません。
5. Nutanixでは、メタデータ/データフォーマットを変更するために、大量のデータを移動させたり、あるいは空き容量を大量に失った状態になったりする必要はありません。
6. vSANでは、一部のディスクフォーマット変更のためにデータを一括して移動する必要があります。
7. Nutanix AOSのアップグレードでは、ハイパーバイザーからの抽象化によりvMotionを行う必要がないため、より迅速に実行でき、メンテナンスウィンドウとリスクを削減できます。
8. Nutanix ADSFでは、いずれのノードがオフラインになってもvDiskやVMにアクセス不可にはならないことを常に保証します。したがってvSANで要求される「アクセシビリティの確保」オプションは必要ありません。