今回は、
「vSAN環境でのDisk障害対応について」
というタイトルでお送りします。
vSANを利用している環境でローカルのストレージに障害が起こった場合、
従来の様にメーカと調整して、フィールドエンジニア（CE）の方に現地に来てもらってディスクを交換してもらうだけでは復旧しません。
そういう意味では、vSAN環境では障害時の復旧作業（運用作業）の難易度は高くなってしまっていると言えますかね。
某ハードウェアメーカの派遣したフィールドエンジニアの言うことを、確認せずに信じてしまったせいで、復旧するのにすごく、、、大変だった＆時間が掛かった。。。というのもありますが・・・笑
そんなわけで、今回は公開されている情報でもありますが、
自分が今後対応しやすくするための備忘録的なことも含めて...な投稿です。
まず、、、どんなことを言われても、『交換対象のディスクをホストするvSANホスト』は、オフラインにしましょう。
（ここまで、ディスク、、、と書いてましたが、SSDだったらディスクじゃなくドライブですね。。笑）
状況によっては、ハードウェアとしてはオンラインのまま交換出来て、
IPMI系のツールだったりでは認識できたりするのですが、、、
ハイパーバイザーで交換したドライブを認識しないことが多々あります。
そうしたら、どうなるか、、、
一度ハイパーバイザーを再起動しなければいけないわけです。
で、、、あれば、最初から「再起動必要です。」というのと、vSANでの話なので
「クラスタの中の他のハイパーバイザーにゲストOSは逃がしますから。」と、
言って、ユーザとの調整を図るべきかと思いますね。
（↑の話をするには、こういう時に使えなくて何のために
「冗長性を持った構成で可用性を担保しているのか、、？」
という話をユーザにも啓蒙活動しておいて、理解しておいてもらう必要はあるとは
思いますが、、、。）
まぁ、ハードウェア故障の予兆検知だったりした場合には、
ドライブを手動でオフラインにしないといけないですから、、
安全性を考えたらこの意味でもハイパーバイザー的にもvSANとしての意味でも
ホストはメンテナンスモードにしてオフライン化しておくべきですね。。
そんなこんなで、グダグダ書かせて頂き、くどいですが結論は、
vSAN環境のハードウェア障害は当然のことながら、
サービス停止は無く（ゲストOSの停止は無く）行えます。
ユーザ様へは、最初からホストだけは停止します、というのは伝えておくべきでしょうね。
ちなみに、実際に交換時にやることは、
○ Capacity Tierの場合
- 交換前に故障したドライブをvSAN管理画面から削除する
- 交換する
- （ホストの再起動も含めて）交換したドライブを認識したら
Diskグループに組み込む
○ Cache Tierの場合
- 交換前に故障したドライブが担当（？）していたディスクグループを削除する
- 交換する
- （ホストの再起動も含めて）交換したドライブを認識したらDiskグループを作り直して、CacheとCapacityを登録する
です。
ちなみに、多分、この作業は、、1時間で物理的な交換までやるには厳しいと思いますので、
VSAN.ClomRepairDelayの値を事前に変えておくことをお勧めします。
KBはこちらですね。
ご参考まで。
