VMwareな日々

VMware環境関連の管理者/導入/トラブルシュートなどに役立ちそうな情報を備忘録として掲載とその他を少々投稿していくブログ

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つのステータスは連動して変化すると言えます。