VxRail ディスク障害試験について

さっそくのご回答ありがとうございます。

コマンド経由で実績をお持ちということで、弊社もそのようにさせていただこうと思います！

ちなみにですが、（Dell公式の）VxRail PoC Guide 内の Disk Failure の項目では物理抜去でテストする想定となっていました。

kaneda さんの説明にもありますが vsanDiskFaultInjection.pyc を実施すると「疑似ディスク障害から疑似交換スクリプトを流そうとすると、VxRailの場合は交換前のDisk SNを記憶しているため、同じディスクで交換しなおす、ということはできません」となる、≒ 疑似障害だけど対象ドライブは(そのままでは)再度組み込めない、ということになり、結構面倒です。

以前検証環境でこのあたりを試した際は、
予めキャパシティドライブを数本抜いた状態で RASR で初期化してからセットアップ、その後、 vsanDiskFaultInjection.pyc で疑似障害を発生させて、その後は抜いておいたドライブを交換用ドライブとして交換操作を実施、という流れで行いました。

個人的には「稼働中にディスクを抜くようなリスクのある行為」はそれほど vSAN においてはリスクはなく、Absent (一時的な不明状態) とマークされ、IO メンバーから外されますが、
ドライブを戻せば即再認識されます(既定では一時間以上放置するとデータの再構成が始まってしまうので、障害状態を確認する想定であれば長くとも45分前後で戻すのが良いかと)。
※ vsanDiskFaultInjection.pyc を実施した際は Degraded としてマークされ即時データの再構成が開始されたはず

想定する障害と、検証したい復旧方法にも依存し、手間は異なりますが検証環境であればどちらのパターンでも問題はないです。

追加情報ありがとうございます。

vsanDiskFaultInjection.pycを使用する場合はご指摘いただいたテクニックを参考にしたいと思います。

稼働中にディスクを抜く行為もそれほどリスクがないということについても承知いたしました。

どちらの方法をとるかは社内で検討させていただきます。

とても参考になりました。ありがとうございます。

だいぶ遅れての追加回答となりますが、今日案件ミーティングで kaneda さんと話している中で、

>※ vsanDiskFaultInjection.pyc を実施した際は Degraded としてマークされ即時データの再構成が開始されたはず

と記した以前の私のコメント、vSAN としての挙動と VxRail Manager 管理下の Disk 状態の挙動でちょっとごっちゃになっておりましたので以下に整理します。

----

vsanDiskFaultInjection.pyc の実施時のオプションで、-u などで hot unplug 状態 (ディスク抜いた想定) にするのみであれば vSAN 上の Absent で、VxRail  Manager 上でも Disk に故障がマークされることは無いようです。

検証後は -c オプションで対象ドライブの状態をもとに戻せば問題がないです。

以前私が実施した際は即時リビルドを試すため -p で permanent error 状態で即 Degraded を発生させ、このときは VxRail Manager 上でも管理下の Disk に対して故障がマークされ、戻すのが手間だった、という事を思い出しました。