VMwareな日々

VMware環境関連の管理者/導入/トラブルシュートなどに役立ちそうな情報を備忘録として掲載とその他を少々投稿していくブログ

vSAN障害シナリオ:キャパシティディスク編(その1)

現在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スクリプトで予め用意されている疑似障害スクリプトで動きを見てみます。

疑似障害の発生から収束までの手順はは次の通りで実施をしてみます。

  1. VMをvSANDatastore上にデプロイ
  2. VMのデータ配置がどのホストのどのディスクにされたかを確認
  3. データが配置されたディスクに対し、次のコマンドで障害ステータスをセットする
    python vsanDiskFaultInjection.pyc -p - d ”デバイスID”
  4. コンポーネントの再同期状態をGUIで確認する
  5. 3.で設定した疑似障害のステータスをクリアする

以下の図では既に1.と2.の工程を終えています。

(Failure-Testという名称のVMのデータが、FTT=1で保護されており、ホスト01と03上にデータコンポーネント、02ホストにスプリットブレイン回避用のウィットネスメタデータが保持されています)

f:id:instructor8010:20170620224115p:plain

ここではこの赤枠内の黄色の蛍光ペンでマークしているesx-01a~で始まるホストのディスクに障害をマークしたいと思います。

以下の情報は、VMwareのFailure Testドキュメントからの抜粋であり、naa識別子により障害発生ディスクを指定しています。

f:id:instructor8010:20170620225754p:plain

(naa.600508b1001cla7f310269ccd51a4e83=vmhba1:C0:T0:L4です)

f:id:instructor8010:20170620230047p:plain

HOLでは上図のように括弧内を見たところ、NAA識別子ではないMPX識別子でディスク識別子が与えられていたので、NAAを置き換えた結果、コマンドは次のようになると言えます。

python vsanDiskFaultInjection.pyc -p - d /vmfs/devices/disks/mpx.vmhba2:C0:T1:L0

上記でコマンドをSSH接続したESXiホストに実行した所、次の出力となりました。

f:id:instructor8010:20170620224430p:plain

コマンドは成功しているものの、Injecting permanent error on device Noneとなっており、障害フラグをデバイスに立てられませんでした。

この後も追加情報を調べましたが、HOL上ではネスト環境のESXiであり、SCSI INQUIRYによるNAA値が取得出来ないようで上記のコマンドは実施不可のようでした。

一旦、物理環境を後日用意するとして、現時点での考察は次の通りです。

  • ディスクの自然障害では、FTT=1以上であれば空きスペースに対してオブジェクトのコンポーネントの再同期が実施される
  • FTT=0のVMが、不運にも動作していた場合はバックアップからのリストアが必要
  • ディスクグループ内では”Degraded(低下しました)”ステータスで残っている状態となるため、これをディスクグループから削除→物理的に抜去→新規ディスクを挿入→ディスクグループへ追加の流れとなる。

上記の様子を擬似的に発生させるため、クラスタのディスクグループ管理画面より、

今回障害発生を想定していたディスクを強制的に外してみます。

f:id:instructor8010:20170620231955p:plain

今回は障害の挙動を想定しているので、ディスク抜去時のデータ移行は無しとしてオペレーションを続けます

f:id:instructor8010:20170620232123p:plain

この後再同期が完了し、コンポーネントはesx-01aに代わり、esx-04a内のディスクによりキープされている状態に変わりました。

f:id:instructor8010:20170620232538p:plain

なお、ディスクグループですが、HOL上の環境が1ディスクグループにキャッシュドライブ、キャパシティドライブが1本ずつのアサインの最小構成であったため、ディスクを1つ外した事でディスクグループそのものが無くなりました。(最小構成を満たさないため)

f:id:instructor8010:20170620232751p:plain

この点については、2本以上のキャパシティディスクがある場合はグループが保持される動きとなるため、後日この点は検証をしておきたいと思います。

 

以上、引き続き障害対応の流れをいろんな角度で見てみたいと思います。