現在vSAN 6.2のコース提供を絶賛行っております。
基本的な障害に関する情報はコース内で紹介するものの、具体的な交換手順やその際の諸注意は資料以上の内容が知りたいという声も多いです。
基本的にStorage HUBの情報をベースに、HOL上での動作検証も踏まえ上記に対する考察を記載していこうと思います。
Disk Failures － Storagehub.vmware.com
今回のお題：キャパシティディスクの自然障害
What Happens When a Disk Fails?
If a disk drive has an unrecoverable error, vSAN marks the disk as DEGRADED as the failure is permanent.（修復不能なディスク障害発生時、vSANは該当のディスクを永続的なDegraded（日本語ステータスでは低下しました）としてマークします）
Expected Behaviors（予期される動作）
- If the VM has a policy that includes NumberOfFailuresToTolerate=1 or greater, the VM’s objects will still be accessible.（FTT=1以上で保護されているオブジェクトは、障害発生時であってもアクセス可能である）
- The disk state is marked as DEGRADED and can be verified via vSphere web client UI.（ディスクステータスがDegradedである状態はvSphere Web Clientから確認が可能です）
- At this point, all in-flight I/O is halted while vSAN reevaluates the availability of the object without the failed component as part of the active set of components.
（障害発生時点で、全ての実行中のIOは停止され、vSANは障害発生したコンポーネント以外のアクティブなコンポーネントを再評価します） - If vSAN concludes that the object is still available (based on a full mirror copy and greater than 50% of components being available), all in-flight I/O is restarted.
（vSANはオブジェクトのコンポーネントが50％以上存在する場合は、そのオブジェクトが利用可能であり、実行中のIOを再開します） - The typical time from physical removal of the drive, vSAN processing this event, marking the component DEGRADED halting and restoring I/O flow is approximately 5-7 seconds.
（上述のIO停止から再開までの時間は約5~7秒の間で実行されます） - vSAN now looks for any hosts and disks that can satisfy the object requirements. This includes adequate free disk space and placement rules (e.g. 2 mirrors may not share the same host). If such resources are found, vSAN will create new components on there and start the recovery process immediately.
（上述のIO停止から再開までの時間は約5~7秒の間で実行されます） - If the VM Storage Policy has NumberOfFailuresToTolerate=0, the VMDK will be inaccessible if one of the VMDK components (think one component of a stripe) exists on the pulled disk. This will require a restore of the VM from a known good backup.
（もしストレージポリシーによる保護で、FTTが0に設定されているVMのデータが障害ディスクに保存されている場合は、VMDKへのアクセスはできなくなる。この場合はバックアップからのデータ復元を行う必要がある）
ここまではStoragehub.vmware.comの簡易翻訳にすぎないので、HOLで動作を見たいと思います。
今回はHOLということで、物理的な実機はないので、pythonスクリプトで予め用意されている疑似障害スクリプトで動きを見てみます。
疑似障害の発生から収束までの手順はは次の通りで実施をしてみます。
- VMをvSANDatastore上にデプロイ
- VMのデータ配置がどのホストのどのディスクにされたかを確認
- データが配置されたディスクに対し、次のコマンドで障害ステータスをセットする
python vsanDiskFaultInjection.pyc -p – d ”デバイスID” - コンポーネントの再同期状態をGUIで確認する
- 3.で設定した疑似障害のステータスをクリアする
以下の図では既に1.と2.の工程を終えています。
（Failure-Testという名称のVMのデータが、FTT=1で保護されており、ホスト01と03上にデータコンポーネント、02ホストにスプリットブレイン回避用のウィットネスメタデータが保持されています）
ここではこの赤枠内の黄色の蛍光ペンでマークしているesx-01a～で始まるホストのディスクに障害をマークしたいと思います。
以下の情報は、VMwareのFailure Testドキュメントからの抜粋であり、naa識別子により障害発生ディスクを指定しています。
（naa.600508b1001cla7f310269ccd51a4e83＝vmhba1:C0:T0:L4です）
HOLでは上図のように括弧内を見たところ、NAA識別子ではないMPX識別子でディスク識別子が与えられていたので、MPXから始まる値で次のコマンドを実行してみました。
python vsanDiskFaultInjection.pyc -p – d mpx.vmhba3:C0:T0:L0
上記でコマンドをSSH接続したESXiホストに実行した所、次の出力となりました。
この結果vSAN内で保護されている仮想マシンのコンポーネントの様子を見てみると次の通りです。
コメント