本記事は2020年6月22日にJosh Odgers氏が投稿した記事の翻訳版です。
このシリーズの前半では、Nutanix AOSの読み取りパスおよび書き込みパスの利点と、Nutanix独自のデータローカリティの実装が、どのような恩恵をもたらすかについて説明しました。
また、データローカリティに関する新たな比較シリーズを開始し、データローカリティが究極のストレージ性能だけではなく、基盤となるクラスタとすべての仮想マシンの性能と機能についてもハイライトしています。
それでは、I/Oパスのしなやかさについて詳しく見ていきましょう。
先日、VMware社は「How to handle lost of stuck I/O on a host in vSAN Cluster（vSAN Clusterにおけるホスト上でのI/Oの喪失時の対応について）」というタイトルでKB71207を公開しました。
この記事では、ストレージコントローラや物理ドライブなど、I/OパスのどこかでI/Oが「スタック」または「ロスト」した場合のvSANの対応について説明しています。
この症状について、VMware社は次のように説明しています：
ストレージコントローラやストレージディスクでI/Oがスタックしたり失われたりすると、ESXiストレージコンポーネントは、タスク管理要求を通じて、これらI/Oを中止しようとし、以下のコンソールメッセージを表示します。
If I/O is stuck or lost on the storage controller or the storage disk, the ESXi storage stack will try to abort them using the task management request displaying these console messages:
記事はこう続けています：
このようなロストI/Oがホスト上で見つかった場合、vSANはホストを強制的にPSODさせ、クラスタ上の他のホストに影響を与えないようにします。
If such a lost I/O is found on a host, vSAN will force the host to PSOD to ensure that it doesn’t affect other hosts on the cluster.
この記事では、その影響とリスクについても紹介しています：
「Lost or wedged I/O」とは、ESXiの外部（デバイスコントローラ/ファームウェア）で動かなくなったI/Oのことで、（I/Oが）完了せず、アボート（異常終了）要求にも反応せず、または完了できません。このようなI/Oは、ディスクやディスクグループが応答しなくなる原因となり、その結果、hostdがハングアップしたり、応答しなくなったり、vCenter Serverから切断されたりします。
Lost or wedged I/O is an I/O which is stuck outside of ESXi (device controller/firmware) that does not complete and doesn’t respond to abort and/or abort never completes. Such I/Os can cause a disk or disk-group to be unresponsive which in-turn can cause hostd to hang or become unresponsive and disconnecting from vCenter Server.
I/OはESXiの外で止まっているため、ESXiが唯一できることは、アボート（異常終了）を送信することだけです。デバイス/コントローラが120秒（デフォルトのタイムアウト値）以内にアボートに応答しない場合、vSANはホストをクラッシュさせてvSANクラスタ全体に影響を与えないように、ホストをサービスから外します。
Since the I/O is stuck outside of ESXi, the only option ESXi has is to send an abort. If the device/controller doesn’t respond to the abort within 120 seconds (default tiemout) vSAN will take the host out of service to avoid affecting the entire vSAN cluster by crashing the host.
要約すると、VMware社は、「スタック」または「ロスト」したI/Oに対して、結果としてPSOD（Purple Screen of Death：ESXサーバのVMkernelで重大なエラーが発生し機能が完全に停止した状態）が発生するとアドバイスしています。これは最終的に、ホスト上の仮想マシンがHAイベントによって、クラスタ内の生き残ったノード上で再起動される（仮想マシンが生きたままvMotionされない）ことを意味します。
VMwareはPSODの処理を「クラスタ上の他のホストに影響を与えないようにするため」と正当化しており、ある意味で納得です。
それでは、Nutanix AOSが同じ状況に陥った場合にどのように対処するかを見ていきましょう。
最初の大きな違いは、Nutanix AOSが仮想マシン（「コントローラVM」）内で実行されることで、ハイパーバイザーから抽象化されていることです。
これは、ハイパーバイザーに影響を与えることなく、CVMがハングアップしたI/Oなどのシナリオを処理できるという点で、「インカーネル」であることに比べて大きな利点となります。
それでは、手順をもう少し詳しくご紹介しましょう。
- ディスクにIO要求が発行されると、CVMのカーネルはデバイスに関連したscsiタイムアウトを持ち、それ以降はscsi abort task managementコマンドを使ってIOを中止しようとします。
- 先のカーネルでの処理に加えて、Stargate（データI/Oマネージャー、全てのデータ管理とI/O処理を行い、ハイパーバイザーからの主なI/Oインターフェイス）では、ディスクにI/Oが発行されるたびにタイマーを開始します。これは基本的に2重の保護となります。
- カーネルが1.のアボートの結果、I/Oエラーやショートリードを返し、そのI/Oがegroup（Nutanixのストレージにおけるデータ管理の単位のグループ1つ）ファイルに関連付けられている場合、Nutanixは単にメタデータでegroupの破損をマークし、別の健全なレプリカからその4MB単位で再複製する修繕オペレーションを起動します。このように、デバイス上の不良ブロックは、そのブロックにマッピングされていた1つのegroupファイルにのみ影響を与え、それ以外はすべて正常に機能し続けます。
- 場合によっては、ディスク上のエラーがより深刻で、そのディスクがもはや稼働していないケースもあります。このようなディスクからの応答がない場合でも、2.で開始したタイマーが作動します。このイベントでは、その特定のディスクをオフラインにします。このようにして、そのホスト上の他のすべてのディスクは問題なく機能し続けます。さらに、Curator（MapReduceクラスタの管理とクリーンアップを行うサービスで、Curatorは、クラスタ全体のディスクのバランシング、事前スクラブといった多くのタスクの管理と分散を行う）は、オフラインのディスクにコピーを持っていたすべてのegroupのレプリカに対して、再レプリケーション要求の起動を行います。 このように、1台の不良ディスクがCVMやホストに影響を与えることはありません。一方vSANでディスク障害が発生した場合、重複排除と圧縮を使用している場合や、キャッシュドライブが故障している場合は、ディスクグループ全体が失われます。
- 稀なケースですが、カーネルやドライバーの問題でCVMがダウンしてしまった場合、クラスタ上のHAモニターは、そのCVMが動作するノードにリダイレクトルールを追加します。これにより仮想マシンのI/Oは、単純に別の健全なCVMにリダイレクトされ、ホスト上の仮想マシンはvMotionやHAイベントを必要とせずに通常通り稼働し続けます。この機能は、計画的なCVMのアップグレードの際にも使用されます。ローリングアップグレードとCVMの再起動を実行するだけで、ホストと関連する仮想マシンは、Nutanixクラスタによる基本的なHA再ルーティング処理によって移行することなく実行され続けます。
このようなことができるのは、ストレージコントローラ全体をCVMにPCIパススルーしているからです。
そのため、I/Oコントローラに深刻なエラーやハングアップが発生しても、CVMを再起動するだけで済み、最悪の場合はCVMを停止させておくと言う選択も可能です。
ホストはストレージコントローラを管理しておらず、I/Oリクエストを発行していないため、このようなイベントの影響を受けることはありません。メンテナンス（例：CVMリソース設定のローリング変更）やアップグレードなど、CVMがオフラインになった場合、AOSはすべての仮想マシンIOをクラスタ内の残りのCVMにリダイレクトします。
一方、VSANがホストをPSODする必要があるのは、ホストプロセスが下位のデバイスにI/Oを発行しているからです。したがって、実際にはESXカーネル/ホストのスレッドが中断できないスリープに陥っており、ホストのリセットが唯一の手段になり、すべての仮想マシンをHAでリカバリする必要があるということになります。
まとめ
この単純な例において、vSAN/VxRAIL環境では、最低でも（I/Oパス障害に伴う）ホスト障害によって仮想マシンがHAイベントに直面するのに対して、Nutanix上の仮想マシンは、引き続き動作し続け、最悪のケースでもI/Oがクラスタ内の別CVMにリダイレクトされる間、データのローカリティが一時的に失われるのみで済みます。
Nutanix AOSの優位点は次のとおり：
- I/Oのハングアップやスタックが生じても仮想マシンのHAイベントは必要ありません
- ストレージコントローラ関連の問題が生じてもハイパーバイザーへの影響はありません
- ドライブが故障してもホスト全体がオンライン状態を維持し、（クラスタ全体における）分散型の自己修復機能の動作に参加し続けます
- データの破損が原因でI/Oのハングアップやスタックが発生した場合、AOSはそのレプリカを破損としてマークし、残りのレプリカから読み込みを行う一方で、破損したレプリカの自己修復機能が自動起動されます
- 最悪のシナリオでも、I/Oがクラスタ全体にリダイレクトされるのみで、これはアップグレードのための通常の動作と同様であり、仮想マシンは引き続き動作し続けます
- 問題を解決するためにCVMを再起動する必要がある場合でも、ホストと仮想マシンには影響がなく、AOSは仮想マシンとして動作するため、再起動は非常に迅速に行われ、クラスタは通常の状態/回復力のある状態に戻ります
- プラットフォームが自己復旧して回復力のある状態に戻るのに管理者の介入は最小限または不要です
- AOSソフトウェアは、仮想マシン内で実行されることにより、ハイパーバイザーから抽象化されています!!
この記事に貢献してくれた、Nutanixの多くの素晴らしいプリンシパルエンジニアの一人であり、StargateチームのリーダーであるTabrez Memon氏に多大な感謝を捧げます。