FTT1の場合のvSANオブジェクトの配置

引用: https://storagehub.vmware.com/t/vsan-6-7-update-1-technical-overview/vsan-objects-and-component-placement-3/

vSANの書き込みパスのサマリ:

ベストケースのシナリオは、VMが作成されたホスト上から移動していない、もしくは最初のホストへと移動して戻っている状態で、書き込みのうちの一方はローカルのオブジェクト、もう一方はリモートのオブジェクトになります。

シナリオ1: vSAN

vSANにとって最適な書き込みパス– VMが作成されたホスト上にある

もしも仮想マシンが手動、もしくはDRSでvMotionして偶然にノード2へと移動した場合、以下に示すように同じ最適な書き込みパスのまま。

シナリオ2: vSAN

vSANにとっての最適な書き込みパス– 仮想マシンがオブジェクトの配置されているホストへと移動する

もしも仮想マシンがオブジェクトがホストされていないホスト上にある場合(4ノードクラスタの場合50%の確率)、すべての書き込みは従来型のSAN環境でそうであったようにネットワーク越しにリモートで実行されます。

シナリオ3: vSAN

vSANにとって最適とは言えない書き込みパス– 仮想マシンがオブジェクトの配置されていないホスト上にある

これらのシナリオはもしも我々がvSANの「インカーネル」アーキテクチャがもっとも最適な(もしくは最短の)IOパスであるということを受け入れるとしても、取り上げておくべき内容です。IOがリモートで実施されるケースの場合、理論的な優位性は失われると言ってしまっても構わないでしょう。

もう少しだけ深く分け入って、仮想マシンがクラスタ内を動き回った(これはよく起こることです)際に何が起こるかを見てみましょう。

メンテナンスやDRSによるクラスタのバランシングによって動き回る2つの仮想マシンというシンプルな例を利用しましょう。これらの仮想マシンがそれぞれ最終的に自身のオブジェクトを一切ホストしていないノード上で起動されています。これらの仮想マシンのIOパスは一体どのようなものになるでしょうか?

以下の図はその問題を顕しています。2つの仮想マシンの書き込み I/Oは100%リモートへと向かうことになります。さらにノード1とノード3のネットワークトラフィックは書き込みを2つ送り出している上に、2つの書き込みを受け止める事になっており、問題をさらに悪化させています。

シナリオ 4: vSAN

vSANにとって最適とは言えない書き込みパス– 2つの仮想マシンはオブジェクトが配置されていないホスト上にある

以前にも言及したとおり、クラスタが拡張されていくに連れ、仮想マシンがそのオブジェクトが格納されているホスト上に存在する可能性は低下していくため、このシナリオでは環境上で不必要なリソースのオーバーヘッドが発生する可能性が高くなります。

もし環境が2重障害無害化(FTT2)で構成されている場合には、この仮想マシンのIOが100%リモートで行われるというオーバーヘッドは更に増加します。

シナリオ5: vSAN

vSANがメンテナンス状態で、仮想マシンがクラスタ全体に渡って移動されている場合には、仮想マシンは1つもしくはそれ以上の仮想マシンのオブジェクトをホストしているノード上に移動され、書き込み I/Oは最適になるかもしれませんが、すでにお伝えしたとおり、これはクラスタのサイズが大きくなるに連れてその可能性が下がっていきます。

これを私は「偶然のデータローカリティ」と呼んでいます。

vSANのIOパスのサマリ:

* 偶然に最適なシナリオになる確率はクラスタのサイズが大きくなるに連れて小さくなります。8ノードクラスタでは25%にまで低下し、32ノードのクラスタではたったの6.25%です。

結果としてメンテナンスの最中には大部分の書き込み I/Oはネットワーク越しに行われるという事態になり、以前にご説明したように他の仮想マシンとの競合を引き起こします。

注意: メンテナンス時にvSANの標準の「アクセシビリティを保証(”Ensure Accesibility”)」設定を利用している際には、以下のvSAN 6.7のドキュメント(vSANクラスタのメンバーをメンテナンスモードにするに記載)に説明されているとおり、データはVMストレージポリシーには完全には準拠していません:

大抵の場合、一部のデータのみの退避が必要になります。しかしながら、仮想マシンはこの退避中VMストレージポリシーに完全に準拠しなくなる場合があります。これはつまり、そのレプリカの全てにアクセスができなくなるかもしれないということを意味します。もしもホストがメンテナンスモードの最中に障害が発生し、プライマリレベルの対障害性が1にセットされていた場合、クラスタ内のデータ喪失が発生する可能性があります。

引用: HTTPS://DOCS.VMWARE.COM/EN/VMWARE-VSPHERE/6.7/COM.VMWARE.VSPHERE.VIRTUALSAN.DOC/GUID-521EA4BC-E411-47D4-899A-5E0264469866.HTML

VMwareのOffice of CTOのHCIビジネス部門のチーフテクノロジストのDuncan Epping氏はVSAN6.2 : なぜFTT=2を新しい標準として利用すべきなのかというタイトルの記事を書いています。

私はDuncan氏のvSANについての推奨事項に同意しますし、上のメンテナンスシナリオでのデータ喪失のリスクはvSANでFTT2を利用する必要性を強調するものです。

注意: Nutanix ADSFはRF2(FTT1)で当たり前のように常に書き込み I/Oの整合性を維持します。これはADSFにとって大きな容量、回復力、そして性能上の優位性です。

将来の記事でもっと重要な回復力についての考慮事項を取り上げます。

さぁ、Nutanix ADSFについて確認していきましょう:

ここではvSAN上での仮想マシンと同じ構成の仮想マシン、1つの600GBの仮想ディスクを保持しています。Nutanix ADSFには大規模で効率の良くないオブジェクトのコンセプトはありません。vDiskの数がいくつであるかに関係なくすべてのデータは1MBのエクステントもしくは4MBのエクステントグループに分割されています。

Nutanixの仮想マシンが新たなデータを書き込んでいます、1つのレプリカはローカル、そしてもう一つのレプリカはリモートへインテリジェントなレプリカ配置機構で書き込まれます。

すべてのケースで1つのレプリカは仮想マシンが動作しているホストへと書き込まれ、もう一方のレプリカはクラスタ全体へ分散して書き込まれます。

Nutanixはキャパシティの効率性とパフォーマンスを書き込みパス内で提供します。

続いて、仮想マシンをノード1からノード2へとvMotionしてみましょう。

vMotion後のNutanixの仮想マシンは新しいデータを書き込みます、1つのレプリカをローカルへ、もう一方のレプリカをインテリジェントなレプリカ配置機構を用いてリモートへ配置します。

この場合であっても1つのレプリカは仮想マシンが稼働しているホストへと書き込まれ、もう一方のレプリカはクラスタ全体に分散して書き込まれます。

NutanixはvMotionの後であっても引き続きキャパシティの効率性とパフォーマンスを提供します。

それでは今度は仮想マシンをノード3へとvMotionしてみましょう。

Nutanixの仮想マシンは2回目のvMotionのあと新しいデータを書き込みます、書き込み パスは引き続き一貫して1つのレプリカをローカルへ、もう一つのレプリカはインテリジェントなレプリカ配置機構を用います。

それでは仮想マシンをオリジナルのホストへvMotionで戻してみましょう。

結果として状況は7つのうち4つのデータがローカルに、そして3つのデータがリモートになり、もしもアクセスが必要になればローカライズされます。もしもアクセスされないのであればそのままリモートのまま維持され、仮想マシンの性能には影響を与えません。

ここで重要な点は仮想マシンがどこに動いたのかに関わらず、書き込みパスは常に 1つのレプリカをローカルに、もう1つをリモートに書き込み、一貫した書き込み性能を提供することです。

 書き込みパスではインテリジェントなレプリカ配置が使用されるので、クラスタは可能な限り均一になることが保証されます。このシンプルな例から、ノードが3つか4つのデータのかけらを保持しており、そしてすべてのノードが分散した作法で書き込み IOに参加するということを見ることができます。

vSANで取り上げた2つの仮想マシンがそれぞれ作成されたホストから移動されたというシナリオではどうでしょうか?

Nutanix ADSFのIOパスのサマリ:

以下ではクラスタ内のどこに仮想マシンがあるかに関わらず、書き込みパスは同じに維持されるということを確認できます。1つのレプリカは仮想マシンが稼働しているノードに書き込まれ、2つ目(RF3の場合は3つ目も)のレプリカはインテリジェントにクラスタ全体に分散されます。

一貫性が重要です、そしてこれは Nutanixのユニークなデータローカリティが書き込み IOにもたらしているもの、そのものです。

Nutanixの書き込み I/Oが1つはローカル、もう一つはリモート(RF3ではリモート2つ)では最適でないというシナリオはないのですか?

あります、3つのシナリオがあります:

1. ローカルのノードがフルの場合
2. ローカルノードのCVMが様々な理由で利用できない場合
3. 上書き(これは「その場で」実施されます)

最初の2つの場合、すべての書き込み(と読み込み)はリモートになります。

上書きについては、ランダムI/Oは引き続き、最適なパフォーマンスのためにローカルのoplogへと書き込まれます。IOがエクステントストアへとドレインされる際に、その状況に応じてローカルもしくはリモートで実際の上書き操作が完了されます。もしも上書きされたデータが読み込まれる場合には将来、適切に上書き操作(そして読み込み操作)を行うためにローカライズが実施されます。

短くまとめるとNutanix ADSFの最悪のケースのシナリオ(すべてのIOがリモート)はvSANにとってよくあるシナリオということになります。

CVMはAOSのアップグレードのような計画的なメンテナンスや利用できなくなります。CVMが予期せずにオフラインとなるような好ましくないイベントが発生した場合にも、仮想マシンは継続して稼働し続け、IOはリモートから提供され、重要なインテリジェントなレプリカ配置が引き続き適用されます。CVMがオンラインに復帰すれば最適な書き込みパスが再開されます。

次は、vSANとNutanix ADSFの読み込み I/Oパスについて取り上げます。

サマリ

1. vSANの書き込みパスは仮想マシンがクラスタ内のどこにいるのかによって劇的に移り変わります。
2. vSANの静的な、オブジェクトベースの書き込みパスではメンテナンスの最中に大規模なデータ移行(ホストの退避)を行わなければ、新たに書き込まれるI/Oを保護することができません。
3. Nutanix ADSFは常に構成されたストレージポリシー(RF - Resiliency factor)に基づいて書き込み I/Oの整合性を維持します。
4. Nutanix ADSFはクラスタ内のどこに仮想マシンがあっても、もしくはそれが移動しても関係なく書き込み パスの一貫性を提供します。
5. Nutanix ADSFの最悪のケースのシナリオは2つの書き込みのレプリカがリモートに送信される(メンテナンス時やCVMの障害)ですが、これはvSANにとっては当たり前のシナリオです。
6. Nutanix ADSFは設計レベルでデータローカリティを実現しており、偶然そうなるのではありません。