本記事は2021年2月4日にJosh Odgers氏が投稿した記事の翻訳版です。
このシリーズでは、Nutanix AOSがメンテナンスモード、再起動、障害シナリオにおいて、仮想マシンの完全な可用性とデータの整合性を維持することを学びました。
また、Nutanix AOSとvSAN 7 Update 1を比較したところ、vSANは、より高い(SCSI)I/Oタイムアウト設定と完全データ退避モードを使用しているにもかかわらず、再起動とパワーサイクルの両方の(障害)シナリオでI/O整合性エラーが発生するという事実に着目しました。
この、第5回では"vSANオブジェクト修復タイマーを60分から0分に減らすと、I/O整合性の課題に対して何か良い影響がありますか？"という質問にお答えします。
オブジェクト修復タイマーに馴染みのない方のために説明します。vSANオブジェクトは一部の障害シナリオに対して、(オブジェクト修復タイマーの)デフォルト設定である60分の間、修復が開始されません。その間、一部のデータは保護されず、設定されたポリシー（例：FTT1またはFTT2）に準拠した書き込みI/Oなどの機能を実行する能力を欠いた状態となります。
これこそが、X-Ray のPlatform Availability, Resiliency and Integrity(プラットフォームの可用性、回復性、整合性)テストにおいて、vSANがI/O整合性の問題に見舞われた原因であると考えられます。
では、この(オブジェクト修復タイマーの)値をより生産性の高い0分(の遅延)に変更する方法を見てみましょう。
vSAN 7 Update 1：オブジェクトの再同期(Resyncing Objects)のデフォルト表示
vSAN 7 Update 1：オブジェクト修復タイマーの値を0に変更する
この変更により、ノードがオフラインになった場合、vSANは回復力を維持するために必要なオブジェクトの復元プロセスを直ちに開始します。
これによりvSANは、vSAN 7 Update 1で変更されたメンテナンスモード時にデータの整合性を維持することが理論的には可能となり、再起動や障害の後にもデータの整合性を維持できる状態に一歩近づいたはずです。
その後、「カスタム」テストオプションを使用し、PVSCSIのデフォルトタイムアウトに合わせてI/Oタイムアウトを180秒に設定し、Full Platform resiliency testを実行しました。
メンテナンスモードのフェーズ:
vSAN 7U1は、メンテナンスモードのフェーズは、VMの可用性を維持し（PASS）、I/Oエラーも発生しませんでした（PASS）。
ローリングリブートのフェーズ:
vSAN 7U1は、ローリングリブートのフェーズにおいて、VMの可用性を維持しましたが（PASS）、オブジェクト修復タイマーが0に設定されていたにもかかわらず、69回のI/Oエラーが発生しました（FAIL）。
vSAN 7U1は、電源オフの段階でもVMの可用性を維持しましたが（PASS）、26回のI/Oエラーが発生しました（FAIL）。
オブジェクト修復タイマーを0に設定した場合のこの結果を、さまざまなI/Oタイムアウト設定をテストしたパート3（下記）の結果と比較すると、デフォルトのオブジェクト修復タイマーではパワーサイクルフェーズで63回のI/Oエラーが発生し、オブジェクト修復タイマーを0に設定するとエラーは26回に減少しました。
このように、より高性能なNVMe + SSDのDell PowerEdge r740xd-24ハードウェアであっても、最新のvSAN 7 Update 1と即時リビルドを組み合わせても、vSANはI/O整合性の問題を抱えていることがわかりした。
リビルドを無効にした場合、Nutanix AOSの挙動はどうなりますか？
これはサポートされているものではありませんし、現実の世界で私が行うこともありません。というのも、インフラストラクチャソリューションの優先順位は、可用性とデータの整合性を維持することが第一だからです。しかし、実験のために、ポストプロセスのディスクバランシング、イレイジャーコーディング、リビルド処理など、多くのバックグラウンドタスクを担当する「キュレーター」(Curator)サービス全体を停止してみました。
これは、テスト中にAOSがデータを再構築しないようにするための、強引な手段です。
その結果がこちら。
メンテナンスモードのフェーズ:
AOSは何のエラーもなく可用性を維持しています。
ローリングリブートのフェーズ
AOSは何のエラーもなく可用性を維持しています。
パワーサイクルのフェーズ
Nutanix AOSは、リビルドが発生することなく、また(vSANよりも(はるかに低い))30秒のI/Oタイムアウト設定でも、エラーが発生することなく可用性を維持しました。
驚くようなことではありませんが、Nutanix AOSは可用性やI/Oのエラーが発生することもなく、テストのすべてのフェーズに合格しました。
データのリビルドもせずに、どうしてこのようなことが可能なのでしょうか？
その理由は簡単で、すべての新規書き込みは、設定されたレジリエンス・ファクター（別名：ポリシー）のRF2（またはRF3）に準じて書き込まれます。
これにより、（RF2によって）1つの障害または(RF3によって )2つの障害から常に自動的に保護され、最大限の回復力が得られます。
読み取りについては、リビルドが行われていないため、このテストでは既存のデータの中には利用可能なコピーが1つしかない場合があります。Stargateサービスは、読み取りI/Oをローカル優先的を処理しますが、ローカルでない場合はネットワーク経由で処理されます。
このテストでは、一度に1つのノードがオフラインになるだけで、その後の障害は発生しなかったため、データの可用性が保たれ、テストに無事を合格することができました。
私は長年にわたり、VMware社のvSANに関するいくつかの設計上の選択について批判してきました。(オブジェクト)修復タイマーの遅延がデフォルトで60分に設定されていることは、顧客にとって最善の利益にならず、顧客を必要以上に危険にさらすことになると強く信じています。
まとめ
オブジェクトの再構築タイマーをデフォルトの60（分）から0（即時再構築）に設定した後、エラー率が減少することを期待していましたが、実際にはそのようになりませんでした。
しかし、まだ続きがあります。パート6では、テストをスケールアップし、より大きなクラスターがプラットフォームの可用性、回復力、整合性にどのような影響を与えるかを確認します。