みなさん、こんにちは
本日投稿の内容について、以前別サイトで私が投稿したブログの内容です。
サイトの閉鎖に伴い、こちらで再度掲載いたします。
今回はNutanixの障害シナリオについてご紹介します。
Nutanixはハードウェアおよびソフトウェアで構成されておりますが、ホストなどのハードウェアが障害があるケース、CVMなどのソフトウェアの障害またはネットワークなどの障害により挙動が違ってきます。今回はその想定される障害シナリオについていろいろとお話したいと思います。
1. 障害シナリオについて
２. ノード障害について（コントローラVMの障害）
ノード障害は物理障害であるため、ホスト・CVMの両コンポーネントがアクセスできなくなります。そのため、正常な物理ホストのみでクラスタを構成できるようになります。
こちらのスライドはその障害判断プロセスを記載しています。
実際に障害あった場合、ユーザはどのようにして気が付くのでしょうか︖それを以下に記載します。
ユーザーには何が通知されるのでしょうか︖
切り替え処理中に障害が発⽣したコントローラVMを持つホストは、共有ストレージが使⽤できないと報告 することがあります。このホスト上のゲストVMは、ストレージパスが復元されるまで「ハング」しているように⾒えます。ゲストVMデータのプライマリコピーは、障害が発⽣したコントローラVMにマップされたディスクに格納されているため使⽤できませんが、そのデータのレプリカにはまだアクセス できます。リダイレクトが⾏われるとすぐに、VMは読み取りと書き込みを再開できます。
I/Oが内部ネットワークを経由するのではなく、ネットワークを介して移動しているため、パフォーマンスがわずかに低下する可能性があります。すべてのトラフィックが10GbEネットワークを通過するため、 ほとんどのワークロードはユーザーに認識されるようには減少しません。
別のノードが障害になった場合はどうなりますか︖
2番⽬のコントローラVMの障害は他のホストのVMにも同じ影響を与えます。つまり、2つのホストがネットワークを介してI/O要求を送信します。しかし、さらに重要なことは、ゲスト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などのデバイスに格納されています。
コールド層の永続データは、ノードのハードディスク・ドライブに格納されます。ストレージメタデータ、ホットプラグ、ホットティア永続データ、コントローラVMブートファイルは、ドライブベイ1のSATA-SSDに保存されます。2つのSATA-SSDを搭載したシステムでは、追加のホット層DSFデータストレージに2台目のドライブを使用します。
オールフラッシュノードでは、すべてのタイプのデータがSATA-SSDに格納されます。
ブートドライブの障害
各コントローラVMはSATA-SSDもしくは2枚のM.2 SSDを利用して起動します。かつてはブートドライブの冗長化はされていなかったのですが、最近はRAID1構成の冗長化になっていることから、1枚のM.”デバイスの障害に耐えられる構成になっています。
クラスタの運用中は、このドライブにもコンポーネントログと関連ファイルが保存されます。
クラスタの運用中は、このドライブにもコンポーネントログと関連ファイルが保存されます。
ブートドライブの故障により、最終的にはコントローラVMが異常終了します。ホストはブートドライブに直接アクセスしないため、他のゲストVMは引き続き実行できます。データパス冗長性は、ストレージパスを別のコントローラVMにリダイレクトします。
メタデータドライブの障害
メタデータドライブは多くの目的に役立ちます。各ホストのoplogを保持し、書き込み要求を送信するVMに高速応答を提供します。永続データ層として使用されます。また、Cassandraデータベースはクラスタメタデータに対する高速な読み書き応答を提供するためにも使用されます。これらのストレージ使用はすべて障害の可能性を考慮して設計されているため、クラスタ内の他のメタデータディスクに複製されます。
メタデータドライブ（SSD）とデータドライブ（HDD・オールフラッシュ構成はSSD）については、クラスタ全体で複製されているため、単⼀障害では特に影響できることはありません。
メタデータドライブに障害が発生した場合、問題を認識する最初のコンポーネントはCassandraです。
データベースのシェアにアクセスできなくなり、問題を解決するための再起動の継続的なサイクルが開始されます。
StargateはMedusaを通じてCassandraと依存関係にあるため、最終的にStargateは障害を起こしたことをクラスタによって検出され、パスはデータパスの冗長性に基づいて自動的にリダイレクトされます。 まもなく、障害があったメタデータドライブを持つホストは、ネットワーク経由で別のStargateに リダイレクトされます。
Cassandraプロセスがノードで5分以上ダウンした場合、残りのCassandraノードはCassandraデータベースからノードを切り離し、使用できないメタデータを他のノードに複製することができます。データベースを修復するプロセスは約30〜40分かかります。
Cassandraプロセスが再起動して5分間継続した場合、回復手順がまだ実行中の場合、ノードを切り離す手順はキャンセルされます。回復手順が完了してからプロセスが再開し安定した場合、nCLIコマンドを使用してノードを手動でデータベースに追加できます。
ncli> host enable-metadata-store id = cvm_id
スイッチング処理中に障害が発⽣したSSDのホストは、共有ストレージが使⽤できないと報告することがあります。このホスト上のゲストVMは、ストレージパスが復元されるまで「ハング」するように⾒えます。
リダイレクトが⾏われるとすぐにVMは読み取りと書き込みを再開できます。I/Oが内部ネットワークを経由するのではなく、ネットワークを介して移動しているため、パフォーマンスがわずかに低下する可能性があります。すべてのトラフィックが10 GbEネットワークを経由するため、ほとんどのワークロードはユーザーに認識されるようには減少しません。
別のノードが障害になった場合はどうなりますか︖
2番⽬のメタデータドライブの障害は、他のホスト上のVMにも同じ影響を与えます。つまり、2つのホストがネットワークを介してIO要求を送信します。
Cassandra Ringの回復機能は、第2の障害が回復プロセスが完了する前に起こらない限り、第2のノードを失うことに伴うリスクを軽減する。
データドライブの障害
各ノードはデータ・ドライブをクラスター・ストレージ・プールに提供します。
コールドデータはHDDに保存され、ホットデータはSSDに保存されて高速のパフォーマンスが得られます。
HDDには可動部品があり、他のハードウェアコンポーネントを上回っているため、故障が発生する可能性が最も高いコンポーネントです。データはクラスタ全体に複製されるため、単一のハードディスクドライブに障害が発生してもデータが失われることはありません。オールフラッシュノードでは、すべてのタイプのデータがSSDに格納されます。
クラスタソフトウェアは、ホストからデータドライブ（HDDまたはSSD）に障害が発生したハードウェアアラートを受信し、直ちに作業を開始して2回目の障害の影響を軽減します。Curatorはドライブに格納されているゲストVMデータの2番目のレプリカを作成するようにStargateに指示します。
５．ネットワークリンクの障害
各ホストの物理ネットワークアダプタは外部ネットワーク上でグループ化されています。両方の10GbEポートが顧客のネットワークに接続されている場合、ネットワークリンクの障害はユーザーに影響を与えずに許容されます。クラスタが1GbEリンクにフェイルオーバーする必要がある場合、書き込みパフォーマンスは低下します。
Nutanixを構成する際はほとんど10GbEの構成になると思いますので、現状気にする必要はないと考えられます。
６. ブロックフォールトトレランスについて
ブロックフォールトトレランスはNutanixクラスタが任意のデータの冗長コピーを作成し、同じブロックにないノードにデータを配置する機能です。また、メタデータはブロックフォールトトレラントでなければ ならない。
ブロックは、 1〜4個の2U4Nのノードを含むラックマウント型筐体です。電源装置、フロントコントロールパネル、バックプレーン、およびファンは、ブロック内のすべてのノードで共有されます。
ブロックフォールトトレランス機能を有効にすると、ゲストVMデータとメタデータの冗長コピーが他のブロックに存在するため、ゲストVMはブロック障害を発生したまま実行されます。
特定の条件が満たされると、Nutanixクラスタはブロックフォールトトレラントになります。ブロックフォールトトレランス機能は、クラスタ内の各ストレージ階層には、各ブロックに少なくとも1つのドライブが含まれています。
クラスタ内のすべてのストレージコンテナには、少なくとも2つのレプリケーションファクタがあります。
RF2の場合、クラスタには最低3つのブロックがあります。
クラスター内の少なくとも複製ファクター数のブロックには、すべての層に十分な空き領域があります。 例えば、クラスタ内のストレージコンテナのレプリケーションファクタが2である場合、少なくとも2つの ブロックに空き領域が必要です。
Eraser Codingは、どのストレージコンテナにおいても有効にしてはいけない。
（AOS5.8よりブロック環境においてもEraser Codingをサポート）
ブロックフォールトトレランスの状態は、Prism Web ConsoleおよびNutanix CLIで表示できます。
管理者はストレージ階層またはストレージコンテナを設定する必要がありますが、データの移行先は特定できません。AOSはデータの移行先を決定します。
ブロックフォールトトレランス条件が満たされると、クラスタは特定の数のブロック障害に耐えられます。
- 3つ以上のブロックを有するRF2またはRF3 クラスタは、1つのブロックの最大障害を許容することができる。
- 5つ以上のブロックを有するRF3クラスタは、2つのブロックの最大障害を許容することができる。
ブロックフォールトトレランスはResiliencyの一部です。インフラストラクチャのかなりの部分が利用できない状況では、ディスク領域とCPU /メモリリソースの可用性などの他の制約は取り除かれません。
ブロックのフォールトトレランスには、メタデータのブロック認識が必要です。RF2およびRF3に対してメタデータ ブロックのAwareness機能を有効にすることができます。メタデータブロックのフォールトトレランス機能を有効にするには、メタデータが上記のReplication Factorの要件を満たしている必要があります。
7. ブロックフォールトトレラントデータ配置
Stargateはブロック間でデータを配置する役割を果たし、CuratorはStargateにデータ配置要求を行いブロック耐障害性を維持します。
新しいクラスタと既存のクラスタは、ブロックフォールトトレラントな状態になります。新しいクラスタは構成がサポートしていれば、作成直後にフォールトトレラントにすることができます。以前はフォールトトレラントではなかった既存のクラスタは、ブロックフォールトトレランスをサポートする方法でクラスタを再構成することで耐性を持たせることができます。
ブロックフォールトトレラントクラスタ内の新しいデータは、ブロックフォールトトレランスを維持するために配置されます。ブロック耐障害状態にない既存のデータは、キュレーターによってブロックフォールトトレラント状態に移動およびスキャンされます。
再配置が必要なデータの量に応じて、ブロック間でデータを配信するために、キュレーターが数時間にわたって複数のスキャンを実行することがあります。
ブロックフォールトトレラントデータ配置はベストエフォートベースで行われますが保証はされません。ブロック間のディスク使用率が高いなどの条件により、クラスタがゲストVMの冗長コピーデータを他のブロックに配置できなくなる可能性があります。
以下にわかりやすいイメージを載せておきますので、参考にして頂ければ幸いです。
Nutanix MedusaコンポーネントはCassandraを使用してメタデータを格納します。Cassandraはリング内のピアにデータをコピーしてデータの一貫性と可用性を確保するリング型の構造を採用しています。クラスタはメタデータの少なくとも3つの冗長コピーを保持します。少なくとも半分は一貫性を確保するために利用可能でなければなりません。
ブロック・フォールト・トレランスでは、Cassandraのピアはブロック間に分散され、同じブロックに2つのピアが存在
しないようにします。ブロックに障害が発生した場合、少なくとも2つのメタデータのコピーがクラスタに存在します。
Nutanix Zeusコンポーネントは、Zookeeperを使用してクラスタの必須の構成データを格納します。Zookeeperの役割はブロックに障害が発生した場合の可用性を確保するためにブロック間で分散されます。
８. Redundancy Factor3
Redundancy Factor3はNutanixクラスタが2つのノードまたは異なるブロックのドライブの障害に耐えることを可能にする構成可能なオプションです。
デフォルトではNutanixクラスタはRedundancy Factor2を持ちます。つまり、単一のノードまたはドライブの障害を許容することができます。クラスタが大きいほど、複数の障害が発生する可能性が高くなります。Redundancy Factor3が
ないと複数の障害が発生すると、障害が修復されるまでクラスタが使用できなくなります。
Redundancy Factor3には次の要件があります。
- クラスタにはRedundancy Factor3を有効にするために、少なくとも5つのノードが必要
- ゲストVMが異なるブロック内の2つのノードまたはドライブの同時障害を許容するには、RF33のストレージコンテナにデータを格納する必要
- コントローラVMは少なくとも24GB以上のメモリで構成する必要があります。
Redundancy Factor3のイメージ
メタデータの冗長コピーの少なくとも半分は、一貫性を確保するために利用可能でなければなりません。 Redundancy Factor3がない場合、クラスタはメタデータの3つのコピーを保持します。 Redundancy Factor3の場合、クラスタは5つのメタデータを保持し2つのノードに障害が発生した場合、少なくとも3つのコピーが使用可能になります。
Nutanix Zeusコンポーネントは、Zookeeperを使用してクラスタの必須の構成データを格納します。 Redundancy Factor3がない場合、クラスタは構成データの3つのコピーを保持します。 Redundancy Factor3の場合、クラスタは構成データのコピーを5つ保持し2つのノードに障害が発生した場合、少なくとも3つのコピーを使用できるようにします。
９. 劣化ノード (Degrade Node)
劣化ノードには、完全に応答しない状態ではないCVMが含まれていますが、正常なクラスタ操作を確実に実行することはできません。劣化した（または部分的に利用可能な）ノードはクラスタ全体のパフォーマンスに悪影響を及ぼします。 劣化ノード検出は、劣化ノードの結果を軽減するために導入されています。劣化ノードを継続して実行するとクラスタ 全体とユーザーVMのパフォーマンスに影響を与える可能性があります。劣化したノード検出を有効にすることにより、ZooKeeperはノードをメンテナンスモードにします。メンテナンスモードではノードをリーダーシップの位置から移動し、タスクを自動的に配布します。
劣化したノードのアラートは、Webコンソールの[アラート]ページに表示されます。
以下のイベントは、ノードの劣化に寄与する可能性があります。
- ネットワーク帯域幅の削減
- ネットワークパケットドロップ
- ソフトロックアップ
- 部分的に不良なディスク
- ハードウェアの問題（ECCエラーのある信頼性の低いDIMMなど）
劣化ノード検出は、ピア正常性グローバルデータベースで構成されます。これらのサービスは、クラスタの各ノードで実行されます。各ノードは、他のノードで実行されているサービスに対してスコア発行。ピア・スコアは、次のようなメトリックを評価します。
リモートプロシージャコール（RPC）の待ち時間
RPCの失敗またはタイムアウト
ネットワーク待ち時間
1つのノードが約10分間低いスコアを一貫して受信した場合、ピアはそのノードを劣化ノードとしてマークします。
クラスタリングアルゴリズムは、異常値を識別するために使用されます。
劣化ノードの検出
ノードが不良ピアスコアを受信し始めたときに、Webコンソールはユーザーに警告します。数分のスコアが悪いとノードは劣化しているとマークされます。
劣化したノード検出ソフトウェアは、障害の影響を緩和しクラスタ全体への影響を軽減します。影響を軽減するために、このソフトウェアは次のいずれかの操作を実行できます。プロンプトが表示されたら、
次のいずれかを選択します。
- 劣化したノードのコンポーネントがリーダーシップの役割を獲得できないようにする
- 劣化ノードCVMを保守モードにしてCVMを再起動し、サービスを停止します
- ホストをシャットダウンする
劣化ノードの検出の有効化
Webコンソールで劣化したノード検出設定を有効にします。
- クラスタのWebコンソールにログインします。
- ページの隅にある歯車のアイコンをクリックします。
- Degraded Node Settingsをクリックします。劣化ノード設定ウィンドウが表示されます。
- 劣化ノードの検出ステータスを「縮退ノード検出を有効にする」に設定します。
チェックボックスをオンにすると、劣化ノードの検出が有効になります。
それ以外の場合は、劣化ノードの検出を無効にする場合は、ボックスをクリアしてください。 - [保存]をクリックして設定を確定します。劣化ノード設定ウィンドウが閉じて、Webコンソールには、ポップアップの 確認が表示されます。
- アラートポリシーを更新し、アラートを有効または無効にするには：
１．Webコンソールで、[アラート]をクリックします。
２．縮退ノードをクリックすると縮退ノードウィンドウが表示されます。
３．可能な劣化ノードのサイドバー、クリック可能な劣化のノードを。ノードは、数分間の不良ピア・スコアを受信した後、劣化とマークされます。
４．Update Policyポップアップが表示されます。
５．ポリシーを更新し、[保存]をクリックします。チェックボックスをオンにしてポリシーを有効にします。
６．チェックボックスをオフにしてポリシーを無効にします。
非常に長い文章になってしまいましたが、障害シナリオの紹介でした。
以上、よろしくお願い致します。
0 件のコメント:
コメントを投稿
注: コメントを投稿できるのは、このブログのメンバーだけです。