仮想化エンジニア奮闘記

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

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

皆さまお疲れ様です。

 

今回はvSAN Cache Disk障害時のStep3として、ESXi 4台の環境で、FTT=1の時の挙動を確認します。

 

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

次:Capacity Disk障害時の挙動①(ESXi 3台、FTT=0) 準備中

 

③Step 3 ESXi 4台構成の時にFTT=1の仮想マシンが属するCache Disk障害

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


ESXi 3台構成の前回に対して、今回はコンポーネントの再同期が行われるはずです。

 

f:id:kenta53682:20171112104212p: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:20171112113316p:plain

 

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

f:id:kenta53682:20171112113510p:plain

 

3) 予想と異なり「再構築なしで低下した可用」と表示され、コンポーネントの再同期が行われません、、、と思ったらコンポーネントの再同期が行われ始めました。「低下した可用性」という表示に変わりました。

f:id:kenta53682:20171112114248p:plain

f:id:kenta53682:20171112115915p:plain

 

4) コンポーネント再同期画面です。Hard Disk1(=vmdk)が再同期されています。ETAというのはポリシーに準拠した状態に戻るまでの予想残り時間です

f:id:kenta53682:20171112120037p:plain

 

5) コンポーネントの再同期が完了すると、「コンポーネントの再同期」画面に何も表示がされなくなり、「仮想オブジェクト」画面でCentOS7.3が「健全」状態に戻ります。コンプライアンスに非準拠」は、前回と同じくCentOS7.3で「仮想マシンストレージポリシーのコンプライアンスのチェック」を行えば「準拠」状態となります

f:id:kenta53682:20171112120532p:plain

f:id:kenta53682:20171112120520p:plain

 

6) CentOS7.3はもちろん稼働しています。

f:id:kenta53682:20171112120346p:plain

 

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

f:id:kenta53682:20171112121439p:plain

 

8) ディスクグループは見えないので、ストレージデバイスの再スキャンを行います。スキャン後、Cache Diskが復旧し、ディスクグループが復旧します。

f:id:kenta53682:20171112121716p:plain

f:id:kenta53682:20171112121950p:plain

 

9) vmdkはESXi #4へコピーされており、ポリシーに準拠しているのでESXi #1への再コピーは行われません。

f:id:kenta53682:20171112122216p:plain

f:id:kenta53682:20171112122305p:plain

 

それでは本日は以上となります。

次回はCapacity Diskの障害時の挙動について検証してゆきます。