vSANでの障害処理(vSphere HAとの連携とコンポーネント総数50%未満でのVMの動作状況について)

vSANトレーニング5週連続終えました。来週からはvSphere 6.5 Install Configure Manageです。

そして、VMware NSXとHorizonも要望が高まってきていますので、そのうち主要製品はコンプリートしそうです。

 

さて、前回のvSANトレーニングで、vSAN環境に於ける”HA(High Availability)”の動作について質問があったので、動作検証を持って正確な情報を得たいと思います。

 

質問:vSAN上のVMがFTT=1のRAID1ポリシーで保護されている場合、3つのコンポーネントが分断された場合は、オブジェクトは利用不可とはなるが、VMは再起動されるのかされないのか

 

ということで毎度お馴染みのHOLで環境を構成します。

まず4ノードvSANクラスターを構成します。Test-VMは現在”esx-03a.corp.local”上で起動しています。

f:id:instructor8010:20170723094142p:plain

続いてコンポーネントの配置を見てみましょう。

VMDKオブジェクトはホスト番号02, 03, 04号機上に保存されていることがわかります。

f:id:instructor8010:20170723094434p:plain

■シナリオ1:4ノードクラスターで、1ノードが停止するケース

まず一旦、4ノードクラスター内の1台をシャットダウンし、vSANクラスターを3ノードまで減らします。せっかくですので、Test-VMが動作している”esxi03a.corp.local”をシャットダウンしてみます。

 

 

ホスト”esx-03a.corp.local”をシャットダウンし、VMも接続性を失いました。

f:id:instructor8010:20170723094905p:plain

ホストがHAによりリスタート完了しました。

f:id:instructor8010:20170723095805p:plain

Test-VMは、4号機上でリスタートされたようです。

f:id:instructor8010:20170723095959p:plain

コンポーネントのステータスはAbsentですね。

(ホスト障害やネットワーク疎通不可はデフォルトで60分のタイマー切れ後に再同期動作が始まる)

f:id:instructor8010:20170723100252p:plain

■シナリオ2:オブジェクトに対する一部のコンポーネントが欠損した状態で、更に障害を発生させる。

さて、いよいよ本題です。現在のコンポーネント配置は次の状態です。

f:id:instructor8010:20170723102950p:plain

今度はホスト2号機をダウンさせます。1号機でも良いのですが、せっかくなら、VMDKの完全なミラーをもつコンポーネントは残しておきます。

理論上、オブジェクトは3つ中2つがアクセス不可となるため、オブジェクトは動作が出来ない状態になると言えます。

VMDKオブジェクトが残っていればI/Oは出来る環境は残るので、ひょっとしてVMは継続して動くのでは?と、興味を持たれる方もいるかもしれませんので、1号機を残します。

シャットダウン後がこちらです。

f:id:instructor8010:20170723103822p:plain

vSphere Web Clientの更新もしっかり行いましたが、VMは起動状態のままです。

HOLは残念ながらクライアントOSのデプロイが出来ないので、IOを発生させるなどの検証は出来ませんでした。

入念なチェックのため、vSphere Clientからも確認しましたが、やはり起動状態ではあるようですね。

f:id:instructor8010:20170723104023p:plain

データストアブラウザからも、各構成ファイルを確認することが出来ないようです。

f:id:instructor8010:20170723104506p:plain

ちなみに今回は、Test-VMは04ホストで動作をしていましたので、HAによるリスタートは起きませんでした。(後々、そこまで想定してvMotionしとけばよかったと思いました)

せっかくなんで、手動でTest-VMを再起動してみます。HAでは無いですが、HAによるリスタートと同じ結果が得られると言えます。

 

再起動、ポチッとな。

f:id:instructor8010:20170723104812p:plain

1~2秒後に、こんな感じでした。そりゃそうですよね。

f:id:instructor8010:20170723104854p:plain

その後、VMのステータスはパワーオフ状態となり、以降起動は失敗します。

f:id:instructor8010:20170723105018p:plain

以上です。

 

結論:いくらVMDKのレプリカコンポーネントがアクセス可能であっても、オブジェクトは50%以上のコンポーネント保有していない場合、VMは正常に動作は出来ない。

なお、VMは継続稼働状態にはあったものの、ディスクIOなどを受けた場合は、OSやアプリケーション側のタイムアウトなどにより、エラーが発生し停止することが予想される。

また、HAによるリスタート命令を受けるVMは、リスタートが失敗する。

データストアブラウザで見た場合、ファイルが消失しているように見える。

 

付録:vSANでの障害ステータスについて

以下の図のように、ご覧を頂くとたった1台のホスト障害で、2つのエラーが発生しているように見えます。

f:id:instructor8010:20170723101010p:plain

また、別の画面ではVMは障害の影響を受けておらず、正常であるかのようにも見えます。

f:id:instructor8010:20170723101725p:plain

管理者の方からすると、複数の障害が発生している、と見えてしまうかもしれませんが、そうではありません。

vSANでは、次の3つの視点からVMを評価しているといえます。

  1. ポリシーで既定したデータ配置がなされているか否か
    vSphere Web Client上の”コンプライアンスステータス”
    ポリシーで定義した数のコンポーネントが全て存在する場合は”準拠”と表示
    コンポーネントが1つでもアクセス不能になると”非準拠”と表示
  2. オブジェクトが動作出来ているか
    vSphere Web Client上の”動作状態”
    オブジェクトが動作出来る間(50%以上のコンポーネント保有)は”健全”と表示
    オブジェクトが動作出来ない間(50%未満のコンポーネント保有)は”非健全”と表示
  3. コンポーネント単体のステータス
    vSphere Web Client上の”コンポーネントの状態”
    コンポーネントを保持するデバイスの種別によって”低下しました”または”不完全”と表示される。

これらを纏めると、単一の障害で、これら3つのステータスは連動して変化すると言えます。

コメント