仮想化エンジニア奮闘記

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

vSANやるぞー!(5)-vSAN障害時の挙動(Cache Disk障害時)②

皆さまお疲れ様です。

 

今回はvSAN Cache Disk障害時のStep2として、FTT=1の時の挙動を確認します。

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

次:Cache Disk障害時の挙動③(ESXi4台、FTT=1)

 

②Step 2 FTT=1の仮想マシンが属するCache Disk障害

ESXi 3台(すべて仮想マシン)、ESXi #1上にあるFTT=1の仮想マシンが稼働している状態で、ESXi #1のCache Diskを仮想マシンから削除します。 

f:id:kenta53682:20171111205737p:plain

 

予想:仮想マシンは稼働し続ける。ESXiが4台ないため、コンポーネントの再同期は行わなれない。

 

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

f:id:kenta53682:20171111210315p:plain

 

2) ここで、ESXi #1の仮想マシン設定を編集し、Cache Disk を削除します。

f:id:kenta53682:20171111210510p:plain

 

3) vSANのステータスが「再構築なしで低下した可用」というステータスになりました。今回はESXiが4台ないため、コンポーネントの再同期(4台目のESXiホストにESXi #2のvmdkがコピーされること)が行われません。従って、追加でESXi #2のCache Diskに障害が起きたらCentOS7.3は停止します。ESXi #1のCache Disk復旧まで可用性が低下した状態となります。

f:id:kenta53682:20171111210909p:plain

 

4) 「ディスクの管理」画面を見るとディスクグループは表示されず、有効でないことがわかります。

f:id:kenta53682:20171111213727p:plain

 

5) CentOS7.3は問題なく稼働しています。(他のマシンからCentOS7.3に対してPing疎通も可でした。)

f:id:kenta53682:20171111211212p:plain

 

6) ここからは復旧手順となります。今度はESXi #1のvmdkを元に戻します。

f:id:kenta53682:20171111211621p:plain

 

6) 「ディスクの管理」を見ると、ディスクを追加しただけでは復旧しないようです。

f:id:kenta53682:20171111213727p:plain

 

7) ESXi #1のストレージデバイスを見ても、認識されていなかったので再スキャンを行います。再スキャンしたら5GBのCache Diskが見えてきました。

f:id:kenta53682:20171111214453p:plain

f:id:kenta53682:20171111214816p:plain

 

8) スキャンが終わった後、ディスクグループが見えるようになりました。

f:id:kenta53682:20171111215059p:plain

 

9) コンポーネントの再同期が行われ、CentOS7.3が「健全」ステータスとなりました。その割に「コンプライアンスに非準拠」となっていますね。

f:id:kenta53682:20171111215419p:plain

 

10) CentOS7.3を選択し、「仮想マシンストレージポリシーのコンプライアンスのチェック」を行ってみます。

f:id:kenta53682:20171111215545p:plain

 

11) コンプライアンスが「準拠」状態となりました。これで復旧は終わりです。

f:id:kenta53682:20171111215748p:plain

 

さて、次回はESXi 4台の時のコンポーネントが自動的に再同期する環境で検証を行ってみたいと思います。

 

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