仮想化エンジニア奮闘記

Citrix や VMware をはじめ、仮想化に関する最新技術や設計情報の検証結果を共有します。自分が面白いと思ったものを記事にするので一貫性はあまりありません。なお本ブログは個人のものであり、所属する会社とは関係ありません。内容については自己責任の上、ご参照をお願い致します。

vSANやるぞー!(7)-vSAN障害時の挙動(Capacity Disk障害時)①

皆さまお疲れ様です。

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

 

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

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

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

※本記事はvSphere 6.5、vSAN 6.6.1 で検証を行っています

 

今回もNested ESXi環境を利用し、親のESXi上でNested ESXiの仮想ディスクを削除して疑似障害を発生させます。

 

 

①Step 1 FTT=1の仮想マシンが属するCapacity Disk障害

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

 

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

f:id:kenta53682:20171121205534p:plain

 

結論:仮想マシンは稼働し続ける。Cache Diskと異なり、Disk Group自体がエラーになるわけではないので、別Capacity Diskに対してコンポーネントの再同期が行われる。

 

 

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

f:id:kenta53682:20171119105102p:plain

 

2) ここで、ESXi #2の仮想マシン設定を編集し、C0:T4:L0 の Capacity Disk を削除します。

f:id:kenta53682:20171119105458p:plain

 

3) vSANのステータスが「再構築なしで低下した可用」というステータスになりました。(コンポーネントの再同期開始前)

f:id:kenta53682:20171119110531p:plain

 

4) Cache Diskと異なり、Disk Group自体は見えています。

f:id:kenta53682:20171119110842p:plain

 

5) 仮想マシンはもちろん稼働しています。

f:id:kenta53682:20171119110608p:plain

 

6) そうこうしている間に、コンポーネントの再同期が行われています。予想では同一ESXi(ESXi #2)の別Capacity Diskに対して優先的に再同期がかけられると思っていましたが、そういうわけではないようです。別ESXi(ESXi#1)のCapacity Diskに対して再同期がかけられています。

f:id:kenta53682:20171119111035p:plain

 

「障害前の状況」と「障害発生し、コンポーネントの再同期が行われた後の状況」を比べてみます。赤字が変わった部分です。

f:id:kenta53682:20171119111851p:plain

 

7) コンポーネントの再同期画面を確認し、ETAが7分であることと、ESXi #1に再同期がかけられていることを確認しました。

f:id:kenta53682:20171119111954p:plain

 

8) 再同期が完了した後の画面です。かつ仮想マシンストレージポリシーのコンプライアンスチェックも行っています。vSANオブジェクトはすべて健全となり、コンプライアンスステータスも準拠となりました。

f:id:kenta53682:20171119112347p:plain

 

Capacity Disk障害時は、Disk Groupが無効になるわけではないので、ESXi 3台の環境でもコンポーネントの再同期が行われます。ですので、復旧についてもゆっくり対応することが可能です。

 

勿論、本環境では仮想マシンは既にストレージポリシーのコンプライアンスに準拠しているため、Capacity Diskが復旧してもコンポーネントの再同期等は行われません。

 

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

ありがとうございました。