皆さまお疲れ様です。
今回から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を仮想マシンから削除します。
結論：仮想マシンは稼働し続ける。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) に保管されています。
2) ここで、ESXi #2の仮想マシン設定を編集し、C0:T4:L0 の Capacity Disk を削除します。
3) vSANのステータスが「再構築なしで低下した可用」というステータスになりました。(コンポーネントの再同期開始前)
4) Cache Diskと異なり、Disk Group自体は見えています。
5) 仮想マシンはもちろん稼働しています。
6) そうこうしている間に、コンポーネントの再同期が行われています。予想では同一ESXi(ESXi #2)の別Capacity Diskに対して優先的に再同期がかけられると思っていましたが、そういうわけではないようです。別ESXi(ESXi#1)のCapacity Diskに対して再同期がかけられています。
「障害前の状況」と「障害発生し、コンポーネントの再同期が行われた後の状況」を比べてみます。赤字が変わった部分です。
7) コンポーネントの再同期画面を確認し、ETAが7分であることと、ESXi #1に再同期がかけられていることを確認しました。
8) 再同期が完了した後の画面です。かつ仮想マシンストレージポリシーのコンプライアンスチェックも行っています。vSANオブジェクトはすべて健全となり、コンプライアンスステータスも準拠となりました。
Capacity Disk障害時は、Disk Groupが無効になるわけではないので、ESXi 3台の環境でもコンポーネントの再同期が行われます。ですので、復旧についてもゆっくり対応することが可能です。
勿論、本環境では仮想マシンは既にストレージポリシーのコンプライアンスに準拠しているため、Capacity Diskが復旧してもコンポーネントの再同期等は行われません。
それでは本日は以上となります。
ありがとうございました。