本記事はJosh Odgers氏が2020年8月20日に投稿した記事の翻訳版です。
パート6では、ベアメタルインスタンスに障害が発生した後で、VMware VMCとNutanix Clustersの各アーキテクチャーではリビルドがどのように実行されるのかについて、および回復力とパフォーマンスにおいてNutanixで得られる主な利点について紹介しました。
この投稿では、I/OパスにおいてI/Oが「スタック」または「ハング」するというシナリオに両方の製品がどのように対処するのかについて、および、これらの状況が及ぼす影響について紹介します。
説明に入る前に、概念レベルで、インフラストラクチャーの目的は最大限の可用性とデータ整合性を確保することです。そのため、インフラストラクチャーと業務に対するリスクや影響を最小限に抑えるように、あらゆる障害に対処する必要があります。
それを前提に、パブリッククラウドでVMware VMCとNutanix Clustersを使用する場合に、I/Oが「スタック」または「ハング」すると、どのようなことが発生するかを紹介します。
VMwareはKB「How to handle lost or stuck I/O on a host in vSAN cluster (71207)」を公開しており、このKBの中で、I/Oパス内のいずれかの場所（ストレージコントローラーや物理ドライブ自体など）でI/Oの「スタック」または「損失」が発生した場合に、vSANがどのように対処するかを紹介しています。
VMwareでは、この症状を以下のように説明しています。
ストレージコントローラー上やストレージディスク上でI/Oのスタックまたは損失が発生した場合、ESXiストレージスタックはタスク管理リクエストを使用してI/Oを中止するように試み、以下のコンソールメッセージが表示されます。
続けて、以下のように説明しています。
ホスト上でこのような損失I/Oが見つかった場合、vSANはこのホストで強制的にPSODを実行し、このホストがクラスター内の他のホストに影響を及ぼさないようにします。
また、影響やリスクについては、以下のように説明しています。
損失I/Oまたは無反応のI/Oは、ESXi（デバイスコントローラー/ファームウェア）の外部でスタックしているI/Oです。このようなI/Oは完了せず、中止に応答せず、中止は完了されません。このようなI/Oが発生すると、ディスクやディスクグループが応答しなくなり、ホストがハングするか応答しなくなって、vCenter Serverから切断されます。
I/OがESXiの外部でスタックしているため、ESXiでは中止を送信するしか選択肢はありません。デバイス/コントローラーが120秒以内（デフォルトのタイムアウト値）に中止に応答しない場合、vSANはそのホストのサービスを休止し、ホストがクラッシュしてもvSANクラスター全体に影響が及ばないようにします。
まとめると、VMwareは、「スタック」または「損失」が発生したI/Oには、Purple Screen of Death（PSOD）が発生すると忠告しています。つまり、ホスト上のVMにHAイベントが発生し、このホストは（vMotionによって移行されるのではなく）クラスター内の残りのノード上で再起動されます。
VMwareはPSOD処理の理由を「クラスター内の他のホストに影響が及ばないようにするため」としており、これが重要なのは私も同意します。
このシナリオでVMC/vSANの処理で生じる影響は、結局のところ、パート6で紹介したベアメタルインスタンスの障害と同じです。
つまり、ベアメタルインスタンスで実行されているすべての仮想マシンが停止し（HAイベント）、いずれかの段階でサーバーが再起動されてクラスターに再参加します。
それまでの間、VMのストレージオブジェクトはオフラインのノードにホストされ、VMの新しい書き込みI/Oは、構成されているストレージポリシーに適合しなくなります。
何らかの理由（再起動が失敗するなど）でベアメタルインスタンスがクラスターに再参加しない場合は、VMCがノード障害全体を処理します。
次に、Nutanix Clustersはこの同じ状況にどのように対処するのか紹介します。
主な違いとして、まず、Nutanix Clusters（AOS）は仮想マシン（コントローラーVM（CVM））内で実行される点があります。つまり、ハイパーバイザーやハードウェアから抽象化されます。
これは、VMC/vSANに対する大きな利点です。VMC/vSANは、カーネル内であり、ハイパーバイザーに不必要に関連付けられるため、その制約を受けます。Nutanix Clustersでは、この状況に固有の利点として、ハイパーバイザーに影響を及ぼさずに、もしくはベアメタルサーバーを再起動（すべての仮想マシンでHAイベントが発生）することなく、ハングI/OなどのシナリオをCVMが処理できます。
以下で、段階的に詳しく説明します。
- ディスクに対してI/Oが実行されると、CVMカーネルはデバイスのscsiタイムアウトに関連付けられ、このタイムアウトが過ぎると、scsi中止タスク管理コマンドを使用してI/Oを中止するように試みます。
- カーネルの処理に加えて、Stargateで、ディスクに対してI/Oが実行されるとタイマーが起動されます。これは本質的に保護が二層になっていることを意味します。
- 1での中止の結果としてカーネルがI/Oエラーを返すか読み取り時間切れになった場合や、そのI/Oがegroupファイルに関連付けられている場合、メタデータにegroup破損とマークされ、その4MBを別の正常なレプリカから再レプリケートするようにフィクサーが起動されます。そのため、デバイス上の問題のあるブロックは、そのブロックにマップされている単一のegroupファイルにしか影響を及ぼさず、それ以外のすべてが引き続き正常に機能します。
- ディスク上のエラーがさらに重大な場合があります。ディスクが機能しなくなるという場合です。このようなイベントで、ディスクからの応答が受信されない場合は、2）で起動されたタイマーが開始されます。このイベントでは、その特定のディスクがオフラインとマークされます。この方法で、そのホスト上の他のすべてのディスクは、問題なく引き続き機能します。また、Curatorが、オフラインのディスクにコピーが格納されているすべてegroupレプリカに対して、再レプリケーションを起動します。そのため、単一ディスク障害はCVMやホストにまったく影響しません。vSANで単一ディスク障害が発生すると、重複排除と圧縮を使用している場合、および/もしくはキャッシュドライブに障害が発生した場合は、ディスクグループ全体が失われます。
- まれにですが、CVMの停止を引き起こすカーネル/ドライバーの問題が発生した場合は、クラスターのHAモニターが、そのCVMをホストしていたノード上にリダイレクトルールを追加します。つまり、VMのI/Oは別の正常なCVMにリダイレクトされ、ホスト上のVMは引き続き正常に動作します。vMotionやHAイベントは必要ありません。この機能は、CVMの計画アップグレード時にも使用されます。その場合、CVMのローリングアップグレードと再起動を実行するだけで、ホストおよび関連付けられたVMが引き続き動作します。これはそれを支える高可用性構造をNutanixクラスターがリルートするためです。
上記が可能なのは、PCIがストレージコントローラー全体をCVMにパススルーするためです。
その結果、IOコントローラーでもっとも重大なエラーやハングが発生した場合は、CVMを再起動するだけで済みます。再起動しないと、最悪の場合はCVMが停止したままになります。
ホストはストレージコントローラーを管理しておらず、また、ストレージコントローラーに対してのI/Oもリクエストしないため、ホストはこのようなイベントの影響を受けません。保守（CVMリソース変更のローリングなど）やアップグレードを含め、CVMがオフラインになるシナリオでは、Nutanix Clusters（AOS）がすべてのVM I/Oをクラスター内の残りのすべてのCVMにリダイレクトします。
それに対してvSANでは、ホストのプロセスで基盤となるデバイスにI/Oが実行されるため、ホストにPSODが発生します。そのため、割り込みが不可能なスリープ状態になりESXカーネル/ホストのスレッドが実際にスタックした場合、解決するにはホストをリセットするしか方法がなく、HAを使用してすべてのVMをリカバリしなくてはなりません。
まとめ
ここで示した簡単な例では、VMC/vSAN環境は最低でもホスト障害シナリオの影響を受け、VMでHAイベントが発生します。Nutanix Clustersでは、VMは引き続き機能し、HAイベントも発生しません。最悪のシナリオでは、I/Oはクラスター全体へリダイレクトされますが、データローカリティが失われるためパフォーマンスが低下します。CVMが（物理サーバーの再起動よりも大幅に短時間で）再起動されると、Nutanix固有のデータローカリティのメリットが再び得られます。
Nutanix Clusters（AOS）の利点：
- I/Oがハングまたはスタックした場合、VMにHAイベントは発生しません。
- ストレージコントローラー関連の問題が発生した場合、ハイパーバイザーに影響は及びません。
- ドライブ障害が発生した場合、ホスト全体がオンラインのまま分散型の自己修復操作に参加します。
- データ破損の結果としてI/Oがハングまたはスタックした場合、Nutanix Clusters（AOS）がそのレプリカを破損とマークします。破損したレプリカをマークしてデータを再保護するフィクサー操作を開始している間、残りのレプリカから読み取りを行います。
- 最悪の場合は、I/Oがクラスター全体へリダイレクトされます。これはアップグレード時にも行なわれる通常の処理であり、VMは引き続き機能します。
- 問題解決のためにCVMの再起動が必要な場合でも、ホストとVMは影響を受けません。Nutanix Clusters（AOS）ソフトウェアはVM内で実行されるため、再起動はすばやく実行されて、クラスターが回復力を備えた通常の状態に戻ります。
- 回復力を備えた状態にプラットフォームを自己修復する上で、管理者の介入はまったく不要、もしくは最小限しか必要ありません。
- 仮想マシン内で実行することで、Nutanix Clusters（AOS）ソフトウェアがハイパーバイザーから抽象化されます。
次に、パート8で、AWSでのストレージスケーラビリティと回復力について紹介します。
Nutanixの主席エンジニアでありStargateチームのリーダーであるTabrez Memonのこの記事への貢献に対して、深く感謝の意を表します。