仮想化エンジニア奮闘記

Citrix や VMware といったサーバー・デスクトップ仮想化の最新技術や設計情報の検証結果を共有します。(本ブログは個人のものであり、所属する会社とは関係ありません。)

vSANやるぞー!(9)-vSAN障害時の挙動(ホスト障害時)①

皆さまお疲れ様です。

今回からホスト障害時の挙動を確認してゆきます。

 

ポータルへ戻る場合はこちら

次:ホスト障害時の挙動②(ESXi4台、FTT=1)

 

今回もNested ESXi環境を利用し、親のESXi上でNested ESXiをパワーオフして疑似障害を発生させます。

 

 

ESXiホスト障害では、障害発生後すぐにコンポーネントの再同期は行われず、

既定では障害発生後60分後に再同期が行われる仕様となっています。

60分の設定は下記KBに従って変更することが可能です。

https://kb.vmware.com/s/article/2075456

 

※システムの詳細設定⇒VSAN.ClomRepairDelay より変更可能です。(本環境では5分)

f:id:kenta53682:20171125110549p:plain

 

 

①Step 1 FTT=1の仮想マシンのvmdkが保存されたホスト障害

※FTT=0は実際の環境で構成しないと思うので、割愛します。

 

ESXi 3台(すべて仮想マシン)、ESXi #1上にあるFTT=1の仮想マシンが稼働している状態で、ESXi #3をパワーオフします。(あえてvSANの動きだけを見るため、ESXi #1をパワーオフしてHAはさせません。)

f:id:kenta53682:20171125135943p:plain

 

結論:仮想マシンは稼働し続ける。ホスト障害に伴いDisk Groupが無効となり、ESXiが4台ないため、コンポーネントの再同期は行われない。

 

1) 障害発生前の状態。CentOS7.3はESXi #1(10.17.101.71)上にいます。FTT=1のため、vmdkは ESXi #1(10.17.101.71) と ESXi #3(10.17.101.73) に保管されています。

f:id:kenta53682:20171125141203p:plain

 

2) ここで、ESXi #3をパワーオフします。

 

3) ESXi #3が(not responding)状態となり、ディスクグループが見えなくなりました。

f:id:kenta53682:20171125141345p:plain

 

4) 仮想オブジェクトを見ると、「再構築なしで低下した可用性」と表示されています。

f:id:kenta53682:20171125141939p:plain

 

5) CentOS7.3は稼働し続けています。

f:id:kenta53682:20171125142101p:plain

 

6) ESXi 3台なので、コンポーネントの再同期は5分経っても行われません。

f:id:kenta53682:20171125142305p:plain

 

7) 復旧のため、ESXi #3をパワーオンします。

 

8) 仮想オブジェクトは特に問題なく「健全」状態となりました。ESXi #3復旧前後でvmdkに差分がなかったためか、コンポーネントの再同期の画面は6)と同じ状態でした。

f:id:kenta53682:20171125143119p:plain

 

 

それでは、次回はESXi 4台でホスト障害時の挙動を確認します。

 

本日は以上となります。ありがとうございました。