本記事は2021年2月8日にJosh Odgers氏が投稿した記事の翻訳版です。
このシリーズではNutanix AOSが回復力ファクタ(RFつまり2つのデータコピー)を利用した場合に3ノードクラスタの場合も含め、メンテナンスモード、再起動、および障害シナリオにおいて完全な仮想マシンの可用性とデータの整合性を維持できるということを見てきました。
そして、パート2ではNutanix AOSとvSAN 7 Update 1とを比較し、vSANが再起動と電源サイクル(障害)シナリオの両方で、以下のようなあらゆるvSANにとって有利に働く状況を作ったとしてもI/O整合性のエラーに苦しんでいるという事実を確認しました:
- vSANが長い(SCSI)I/Oタイムアウト設定を利用している (180 秒 vs Nutanix 30 秒)
- vSANがデータの完全退避モードを利用している
- vSANのオブジェクトリビルドタイマーを60分の遅延から遅延なしに変更 (すなわち、これによってリビルドは即時開始される)
- より大きなクラスタ(8ノード)を利用し、その上で、テストはそのクラスタ内の最初の4ノードのみで実施する
それではvSAN 7 Update 1が対障害性(FTT)を2に設定した場合の動作について見ていきます、つまりvSANはデータのコピーを3つ書き込んでいくことになり、理論的には回復力を向上して、2つの同時ドライブもしくはノード障害に対応ができることになります。
この一連のテストは回復力にフォーカスを当てており、FTT2(もしくはNutanix AOSではRF3)を利用するということは同時に実効で利用可能なキャパシティを50%からファイルシステム、キャッシュドライブ、そして回復用のキャパシティ(N-1/N-2)をマイナスしたものから33%から同じオーバーヘッドをマイナスしたものへと減少させるというコストを伴うということを理解しておくことが重要です。
FTT2(NutanixではRF3)を利用する場合には、同じ仮想マシンのフロントエンドのパフォーマンスに対してもより多くのシステムリソース(例:CPU/ストレージIO)を消費します。例えば、デュアルパリティへの移行によってサイジングには劇的な影響があり、大抵の場合33%以上になりますし、もちろんプラットフォームの先行投資(ハードウェア & ソフトウェアライセンス)および運用コスト(電源、冷却、パッチなど)にも影響します。
今回のテストでは7ノードのクラスタを利用しています。
なぜ7なのか気になりますか? その答えはシンプルで、vSAN(もしくはAOS)では2つのノードの同時障害に対応するためには5ノードが必要だからです。
しかし、2つのノードの同時障害イベント時には、このクラスタは自己治癒を行ってデュアルパリティを維持するということができません。ですから、FTT2(もしくはRF3)の場合には私は最小サイズを7ノードにすることを推奨しています。
上記はつまり、必要とされるパリティが同時障害のあとも引き続き維持される、ということで、これがお客様が知っているか、知らないかはさておき最終的にお客様が実際の環境で期待することなのです。
さて、プラットフォームの可用性、回復力、整合性のシナリオの最初のリリースではN-1(FTT1/RF2)回復力の検証のみのシナリオしかサポートしていないため、一度には1ノードずつしかオフラインにすることはできません。ですから、FTT2/RF3のシステムは簡単にテストをパスすることができるはずです。
さて、結果を見てみましょう。
メンテナンスモードのフェーズ:
期待した通り、このフェーズ中にはエラーは観測されませんでした。
ローリングリブートのフェーズ:
62のエラー!!!!!!!!!!!
FTT2を利用している場合にもI/Oエラーが出たということに心底驚いています。理論的にはそれぞれのノードがローリングで再起動している最中であってもvSANはすべてのオブジェクトの(最低)2つのコピーを利用可能なはずで、これは起こるべきではないからです。
電源オフのフェーズ:
37のエラー!!!!!!!!!!!
この結果についても心底驚きましたし、もちろん、とても心配になりました。
2016年にさかのぼりますが、Duncan Epping氏はVSAN 6.2 : Why going forward FTT=2 should be your new default (VSAN 6.2 : なぜこの先ではFTT=2を新しい標準にすべきなのか?)というタイトルの記事を執筆しており、これは特に今回のシリーズで明らかになった結果をもとにするととても納得する内容でした。
根本的にvSANはデータ整合性の観点からは7ノードサイズのクラスタで対障害性2(FTT2)を利用している場合であっても最低限の要件を満たしていません。これは可用性、整合性もしくはその両方を単一ノード障害のシナリオであったとしても維持できていないからです。
以下はvSphereクライアントのMonitor > vSAN > Virtual Objectsで確認できる問題の一例です。
プラットフォームの回復力テスト全体で発生したVirtual Objectsのステータス | 7 ノード vSAN 7U1 | FTT2 クラスタ
サマリ:
vSANはX-Rayのテストが同時に1ノードずつしかアクションを実行していないにもかかわらず、適切なサイズのFTT2クラスタ(5+2)においても、可用性と回復力(I/Oエラー)に問題を抱えています。
一方でパート1で、我々はNutanix AOSがRF2(データを2つコピー)を利用して常にIOの整合性と仮想マシンの可用性を単一SSDの3ノードのプラットフォームでも維持できることを見てきています。
次の記事のパート8では、もしvSANがストレッチクラスタ構成を利用した場合にIOの整合性と仮想マシンの可用性を維持できるのかについて検証していきたいと思います。
パート1に戻る: