皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。
本日はNutanixの障害シナリオについてお話したいと思います。
Nutanixはハードウェアおよびソフトウェアで構成されておりますが、ホストなどのハードウェアが障害があるケース、CVMなどのソフトウェアの障害またはネットワークなどの障害により挙動が違ってきます。今回はその想定される障害シナリオについていろいろとお話したいと思います。
障害シナリオについては、上記の記載した内容があります。
この中で、高密度型で導入していないお客様については、ブロックに関する障害はあまり関係ありませんが、どのようなケースなのかを覚えて頂くことも良いかもしれません。
ノード障害についてお話したいと思います。
物理障害であるため、ホスト・CVMの両コンポーネントがアクセスできなくなります。そのため、正常な物理ホストのみでクラスタを構成できるようになります。
こちらのスライドはその障害判断プロセスを記載しています。
実際に障害あった場合、ユーザはどのようにして気が付くのでしょうか？それを以下に記載します。
ユーザーには何が通知されるのでしょうか？
切り替え処理中に障害が発生したコントローラVMを持つホストは、共有ストレージが使用できないと報告 することがあります。このホスト上のゲストVMは、ストレージパスが復元されるまで「ハング」 しているように見えます。ゲストVMデータのプライマリコピーは、障害が発生したコントローラVMにマップされたディスクに格納されているため使用できませんが、そのデータのレプリカにはまだアクセス できます。リダイレクトが行われるとすぐに、VMは読み取りと書き込みを再開できます。
IOが内部ネットワークを経由するのではなく、ネットワークを介して移動しているため、パフォーマンスがわずかに低下する可能性があります。すべてのトラフィックが10GbEネットワークを通過するため、 ほとんどのワークロードはユーザーに認識されるようには減少しません。
別のノードが障害になった場合はどうなりますか？
2番目のコントローラVMの障害は他のホストのVMにも同じ影響を与えます。つまり、2つのホストがネットワークを介してIO要求を送信します。しかし、さらに重要なことは、ゲストVMデータに追加のリスクがあることです。2つのコントローラVMを使用できないため、アクセス不能な2つの物理ディスクセットが存在するようになりました。RF2を持つクラスタでは少なくとも1つのコントローラVMが動作を再開するまで、一部のVMデータエクステントが完全に欠落する可能性があります。
ホスト障害時の挙動についてはこちらをご覧ください。
ノード障害が発生すると、他のノードでVMが再起動しますが他のノードにデータが存在していれば、問題なくデータにアクセスすることができます。ただし、3ノードで構成した場合は、障害時は正常なクラスタではありませんので、早急に復旧が必要になります。
ユーザーには何が通知されるのでしょうか？
HA保護されたVMにアクセスしているユーザーは、新しいホストでVMを再起動している間はそのVMを 使用できないことに気付きます。HAなしでは、VMを手動で再起動する必要があります。
別のノードが障害になった場合はどうなりますか？
2番目のホストの障害により、残りのホストの処理能力が不十分になり、2番目のホストからVMを再起動 する可能性があります。ただし、負荷の軽いクラスタであってもゲストVMデータに対する追加のリスクが懸念されます。
アクセス不能な2組の物理ディスクを使用すると、一部のVMデータエクステントが完全に失われる可能性があります。
次にドライブ障害について説明します。
ドライブには起動用の領域のブートドライブ、階層化データやOplog（書き込みデータ）がSSDおよびHDDなどのデバイスに格納されています。
それそれに対しての説明については、私の文章で記載することはなく、スライドの内容を参照して頂ければと思います。
ブートドライブについては、Lenovoの場合、2枚のM.2のSSDを利用してRAID1構成について冗長化していることから、1回の障害は保護できるような構成になっています。
ユーザーには何が通知されるのでしょうか？
スイッチング処理中に障害が発生したSSDのホストは、共有ストレージが使用できないと報告することがあります。このホスト上のゲストVMは、ストレージパスが復元されるまで「ハング」するように見えます。
リダイレクトが行われるとすぐにVMは読み取りと書き込みを再開できます。IOが内部ネットワークを経由するのではなく、ネットワークを介して移動しているため、パフォーマンスがわずかに低下する可能性があります。すべてのトラフィックが10 GbEネットワークを経由するため、ほとんどのワークロードはユーザーに認識されるようには減少しません。
別のノードが障害になった場合はどうなりますか？
2番目のメタデータドライブの障害は、他のホスト上のVMにも同じ影響を与えます。つまり、2つのホストがネットワークを介してIO要求を送信します。Cassandra Ringの回復機能は、第2の障害が回復プロセスが完了する前に起こらない限り、第2のノードを失うことに伴うリスクを軽減する。
メタデータドライブ（SSD）とデータドライブ（HDD・オールフラッシュ構成はSSD）については、クラスタ全体で複製されているため、単一障害では特に影響できることはありません。
ネットワークの障害については、冗長化構成であれば、単一障害は問題ありません。1GbEのリンクにフェイルオーバーする場合とありますが、10GbEで組む構成が多いと思いますので、現状は気にすることはないと考えられます。
ブロックフォールトトレランスについては、ブロック（2U4Nのケースではあります）の時に関連する内容です。メタデータについてもBlockAwarenessも意識した構成が必要になりますので、十分注意が必要です。また、バージョンによってはEraser Codingのサポートにも影響があります
ブロックフォールトトレランスについてはデータ配置も構成も含めて図で示したほうがわかりやすいので、以下はイメージもつけて説明しております。
次にRedundancy Factorの話をしたいと思います。
こちらはRedundancy Factor3の内容になりますが、2ノードおよび異なるブロックの障害に耐えうる構成が必要になるオプションです。
デフォルトでは、Redundancy Factor2になるわけですが、クラスタのノードが増えれば増えるほど複数ノードの障害を考える必要があるので、こちらの設定が必要となります。詳細は以下のスライドをご参照下さい。
最後に劣化（Degrade）ノードについてお話したいと思います。
劣化したノードについてはパフォーマンスに悪影響を及ぼします。劣化ノードについては早期に検出して、リスクの軽減するための対策を立てる必要があります。詳細についてはスライドをご参照下さい。
ブログ内での説明よりもスライドの記載内容が多いため、コメントは少なめになってしまっておりますが、参考にして頂ければと思います。
よろしくお願いします。
