vSANのコンポーネント障害 <absent> を復旧してみた。
本記事では、たまたまvSAN検証環境で コンポーネント障害 <absent>が発生したので、
復旧までのアクションをまとめてみました。
似たような状況に遭遇した際、参考となれば幸いです。
きっかけ_vSANオブジェクトの健全性が"失敗"ステータスに
仮想マシンを作ろうとしたところ...タスクが失敗。
はて・・・? と思いつつ、vSAN健全性テストを見てみたところ、
[vSANオブジェクトの健全性]が失敗ステータスとなっていました。
具体的な失敗要因としては以下2つ。
再構築なしで低下した可用性 - 遅延タイマー
再構築なしで低下した可用性
困ったときのVMware KBだ！ということで KB 2148591を読むと...
再構築なしで低下した可用性 - 遅延タイマー >> 可用性低下（再構築なし） - 遅延タイマー：
オブジェクトでは障害が発生しましたが、vSAN で許容できる範囲でした。I/O のフローは継続し、オブジェクトにはアクセスできます。ただし vSAN は、再保護を発行する前に、60 分間（デフォルト）の遅延タイマーが切れるのを待機しているため、オブジェクトの再保護にまだ取り組んでいません。 障害が発生したエンティティが遅延期間中にリカバリできないことがわかっている場合は、明示的な要求を発行して遅延タイマーをスキップし、再保護をただちに開始することができます。 ただし、障害が発生したホストがアクティブに再起動しているとわかっている場合や、間違ったドライブが誤って引き抜かれた後に再挿入されたとわかっている場合は、オブジェクトを完全に再保護する最も早い方法であるため、これらのタスクが完了するまで待機することをお勧めします。
再構築なしで低下した可用性 >>可用性低下（再構築なし）：
オブジェクトでは障害が発生しましたが、VSAN で許容できる範囲でした。たとえば、I/O のフローは継続し、オブジェクトにはアクセスできます。ただし、VSAN はオブジェクトの再保護に取り組んでいません。これは遅延タイマー（可用性低下 - 再構築なし - 遅延タイマー）が原因ではなく、別の理由によるものです。考えられる原因としては、クラスタ内に十分なリソースがない、または過去に十分なリソースがなかった、過去に再保護すべき障害があったが VSAN がまだ再試行していない、などが考えられます。いずれかのリソースが枯渇している可能性がある場合は、最初の評価での制限健全性チェックを参照してください。後に続く障害から完全に保護された状態に戻すには、できるだけ早急に障害を解決するかリソースを追加する必要があります。
とりあえず再保護を待つのも面倒だったので、KB 2147736 を参考に遅延タイマーを 60分から 5分へ変更しましたが、再構築は走らず...
より状況を整理するため、調査をすることにしました。
調査_vSAN Architecture から現状を理解する
vSANでは、オブジェクトがストレージポリシーにより属性(パフォーマンス要件と可用性要件)を付与され、コンポーネントが配備されます。
「現在のコンポーネントステータスはどうなっているのか？」をチェックすべく、KB 2148709 を参考にvCSA上で以下コマンドを叩きました。
# python /usr/lib/vmware-vpx/vsan-health/vsan-vc-health-status.py
結果、Node#3に存在するコンポーネント全てがabsentステータスであることを確認しました。
*** command>vsan.vm_object_info
Disk backing: [Virtual-SAN-Datastore-xxx] 98fe815a-1a23-2d44-84ca-246e96ac1870/VMware vCenter Server Platform Services Controller_6.vmdk
DOM Object: 9afe815a-b663-0ae6-bcb9-246e96ac1870 (v5, owner: sds-03.sds.lab, proxy owner: None, policy: SCSN = 17, hostFailuresToTolerate = 1, spbmProfileGenerationNumber = 0, proportionalCapacity = 100, spbmProfileId = 86c3a1ef-bdb4-4439-a1ff-cb0075a6cd05, spbmProfileName = VXRAIL-SYSTEM-STORAGE-PROFILE, CSN = 16)
RAID_1
Component: 2770995a-3edf-285a-74a6-246e96ac1870 (state: ABSENT (6), csn: STALE (15!=16), host: sds-03.sds.lab, md: naa.5000cca02d9cbdb4, ssd: naa.58ce38ee2019570d,
votes: 1, usage: 0.0 GB, proxy component: false)
Component: 2770995a-d642-2b5a-31ee-246e96ac1870 (state: ACTIVE (5), host: sds-01.sds.lab, md: naa.5000cca02d9d2950, ssd: naa.58ce38ee20193f39,
votes: 1, usage: 0.0 GB, proxy component: false)
Witness: 3270995a-4420-5399-5fc4-246e96ac1870 (state: ACTIVE (5), host: sds-02.sds.lab, md: naa.5000cca02d9c4d80, ssd: naa.58ce38ee20190f11,
votes: 1, usage: 0.0 GB, proxy component: false)
Disk backing: [Virtual-SAN-Datastore-xxx] 98fe815a-1a23-2d44-84ca-246e96ac1870/VMware vCenter Server Platform Services Controller_3.vmdk
DOM Object: 99fe815a-6a81-8bb5-5b4f-246e96ac1870 (v5, owner: sds-03.sds.lab, proxy owner: None, policy: SCSN = 24, hostFailuresToTolerate = 1, spbmProfileGenerationNumber = 0, proportionalCapacity = 100, spbmProfileId = 86c3a1ef-bdb4-4439-a1ff-cb0075a6cd05, spbmProfileName = VXRAIL-SYSTEM-STORAGE-PROFILE, CSN = 24)
RAID_1
Component: 2770995a-e462-2232-7a55-246e96ac1870 (state: ABSENT (6), csn: STALE (23!=24), host: sds-03.sds.lab, md: naa.5000cca02d9cc354, ssd: naa.58ce38ee2019570d,
votes: 1, usage: 10.2 GB, proxy component: false)
Component: 2770995a-88f7-2432-87d4-246e96ac1870 (state: ACTIVE (5), host: sds-01.sds.lab, md: naa.5000cca02d9cc390, ssd: naa.58ce38ee20193f39,
votes: 1, usage: 10.2 GB, proxy component: false)
Witness: 4b70995a-2aaf-2578-f129-246e96ac1870 (state: ACTIVE (5), host: sds-02.sds.lab, md: naa.5000cca02d9c475c, ssd: naa.58ce38ee20190f11,
votes: 1, usage: 0.0 GB, proxy component: false)
Disk backing:[Virtual-SAN-Datastore-xxx] 98fe815a-1a23-2d44-84ca-246e96ac1870/VMware vCenter Server Platform Services Controller_10.vmdk
DOM Object: 9afe815a-1c79-b324-1285-246e96ac1870 (v5, owner: sds-03.sds.lab, proxy owner: None, policy: SCSN = 16, hostFailuresToTolerate = 1, spbmProfileGenerationNumber = 0, proportionalCapacity = 100, spbmProfileId = 86c3a1ef-bdb4-4439-a1ff-cb0075a6cd05, spbmProfileName = VXRAIL-SYSTEM-STORAGE-PROFILE, CSN = 16)
RAID_1
Component: 2770995a-e2f5-0b8e-9231-246e96ac1870 (state: ACTIVE (5), host: sds-02.sds.lab, md: naa.5000cca02d9cede4, ssd: naa.58ce38ee20190f11,
votes: 1, usage: 0.0 GB, proxy component: false)
Component: 2770995a-983e-0e8e-4e83-246e96ac1870 (state: ACTIVE (5), host: sds-01.sds.lab, md: naa.5000cca02d9cc380, ssd: naa.58ce38ee20193f39,
votes: 1, usage: 0.0 GB, proxy component: false)
Witness: 4170995a-4205-0882-0152-246e96ac1870 (state: ABSENT (6), csn: STALE (15!=16), host: sds-03.sds.lab, md: naa.5000cca02d9a7890, ssd: naa.58ce38ee2019570d,
votes: 1, usage: 0.0 GB, proxy component: false)
Node#3 ESXi自体は正常ステータスで、各種サービスも問題無い状態でした。
これ以上の調査となるとVMwareサポートさんの力を借りることになりそうです。。
ただ、こちらとしては仮想マシンの作成ができる様になればいいので、Google先生の力も借りて改善に向けたアクションをガツガツやってみることにしました。
解決_改善アクションの実行
vsish コマンドによるdom ownerのリフレッシュ
# vsish -e set /vmkModules/vsan/dom/ownerAbdicateAll
または
# vsish -e set /vmkModules/vsan/dom/ownerAbdicate <Inaccessible UUID>
これらのコマンドはココ とか ソコ とか、いろんなVMware Communityで情報が落ちていました。
vsishとは、通常のcommandでは採取,実行されない deepなVMkernel情報を閲覧,編集するためのshellコマンドです。
VMware社では、公式なサポートコマンドとしては明文化していません。
今回使用したコマンドで何をしているかというと、DOM Ownerのリフレッシュを行っていると思われます。
以下はVMware社が提供している、vSAN Architectureの図説です。
こちらの図から想像すると...
✅ vmdkファイルに紐つくOwnerは1つ決まっている
✅ そのI/Oを司っているのがまさしくDOM Ownerである
✅ 上述のコマンドを実行することでDOM Ownerをリフレッシュできる
このロジックで行くと、"データファイル自体が壊れていない"ということが前提の対処と言えますね。
Node#3のDG(Disk Group)を再作成
今回、Node#3に集中して事象が発生していました。
Disk容量にも空きがあったので、念のためDisk Groupの再作成も行いました。
メンテナンスモードに入るときは"アクセシビリティの確保"を選択。
Node#3の再起動
最後に、Node#3を再起動しました。
結果.. 改善！
改善しました。vSANの健全性欄 を見ていると、徐々に"低下した可用性" から "健全"ステータスへオブジェクトが移行していく様子が見えました。
改めてvsan-vc-health-status.pyを叩くと、やはりDOM OwnerがNode#3 から別 Nodeへ変更されていることが分かりました。併せて、<absent>であったコンポーネント自体の配置先はNode#3から変わっていません。
立てた予測もおおよそ合っていると言えそうです。
✅<absent>ステータスであったコンポーネント自体は壊れていなかった
✅何らかの要因で、<active>ステータスとして読み取れなくなっていた
✅Dom Ownerのリフレッシュ or ホストの再起動を実施したことで、改めてコンポーネントステータスが読み直された
*** command>vsan.vm_object_info
Disk backing:[Virtual-SAN-Datastore-xxx] ] 98fe815a-1a23-2d44-84ca-246e96ac1870/VMware vCenter Server Platform Services Controller_6.vmdk
DOM Object: 9afe815a-b663-0ae6-bcb9-246e96ac1870 (v5, owner: sds-04.sds.lab, proxy owner: None, policy: spbmProfileId = 86c3a1ef-bdb4-4439-a1ff-cb0075a6cd05, CSN = 29, SCSN = 26, hostFailuresToTolerate = 1, spbmProfileName = VXRAIL-SYSTEM-STORAGE-PROFILE, spbmProfileGenerationNumber = 0, proportionalCapacity = 100)
RAID_1
Component: e784b55a-aec7-86b8-30da-246e96ac1b10 (state: ACTIVE (5), host: sds-01.sds.lab, md: naa.5000cca02d9d2950, ssd: naa.58ce38ee20193f39,
votes: 1, usage: 0.0 GB, proxy component: false)
Component: 3678b55a-4a1b-f00a-65e5-246e96abf790 (state: ACTIVE (5), host: sds-02.sds.lab, md: naa.5000cca02d9c475c, ssd: naa.58ce38ee20190f11,
votes: 1, usage: 0.0 GB, proxy component: false)
Witness: e784b55a-2e1d-89b8-7699-246e96ac1b10 (state: ACTIVE (5), host: sds-03.sds.lab, md: naa.5000cca02d9cc354, ssd: naa.58ce38ee2019570d,
votes: 1, usage: 0.0 GB, proxy component: false)
Disk backing:[Virtual-SAN-Datastore-xxx] 98fe815a-1a23-2d44-84ca-246e96ac1870/VMware vCenter Server Platform Services Controller_3.vmdk
DOM Object: 99fe815a-6a81-8bb5-5b4f-246e96ac1870 (v5, owner: sds-04.sds.lab, proxy owner: None, policy: spbmProfileId = 86c3a1ef-bdb4-4439-a1ff-cb0075a6cd05, CSN = 39, SCSN = 36, hostFailuresToTolerate = 1, spbmProfileName = VXRAIL-SYSTEM-STORAGE-PROFILE, spbmProfileGenerationNumber = 0, proportionalCapacity = 100)
RAID_1
Component: df84b55a-6265-cdc3-c397-246e96ac1b10 (state: ACTIVE (5), host: sds-03.sds.lab, md: naa.5000cca02d9cbdb4, ssd: naa.58ce38ee2019570d,
votes: 1, usage: 10.2 GB, proxy component: false)
Component: 4078b55a-16d8-4c03-1b6a-246e96abf790 (state: ACTIVE (5), host: sds-02.sds.lab, md: naa.5000cca02d9c475c, ssd: naa.58ce38ee20190f11,
votes: 1, usage: 10.2 GB, proxy component: false)
Witness: df84b55a-3a2a-d0c3-3198-246e96ac1b10 (state: ACTIVE (5), host: sds-01.sds.lab, md: naa.5000cca02d9c4c78, ssd: naa.58ce38ee20193f39,
votes: 1, usage: 0.0 GB, proxy component: false)
Disk backing:[Virtual-SAN-Datastore-xxx] 98fe815a-1a23-2d44-84ca-246e96ac1870/VMware vCenter Server Platform Services Controller_10.vmdk
DOM Object:99fe815a-f023-3f71-3535-246e96ac1870 (v5, owner: sds-02.sds.lab, proxy owner: None, policy: spbmProfileId = 86c3a1ef-bdb4-4439-a1ff-cb0075a6cd05, CSN = 27, SCSN = 22, hostFailuresToTolerate = 1, spbmProfileName = VXRAIL-SYSTEM-STORAGE-PROFILE, spbmProfileGenerationNumber = 0, proportionalCapacity = 100)
RAID_1
Component: 2770995a-e2f5-0b8e-9231-246e96ac1870 (state: ACTIVE (5), host: sds-02.sds.lab, md: naa.5000cca02d9cede4, ssd: naa.58ce38ee20190f11,
votes: 1, usage: 0.0 GB, proxy component: false)
Component: d384b55a-b29b-51d5-5297-246e96ac1b10 (state: ACTIVE (5), host: sds-03.sds.lab, md: naa.5000cca02d9cbdb4, ssd: naa.58ce38ee2019570d,
votes: 1, usage: 0.0 GB, proxy component: false)
Witness: d384b55a-8446-54d5-780d-246e96ac1b10 (state: ACTIVE (5), host: sds-01.sds.lab, md: naa.5000cca02d9cc380, ssd: naa.58ce38ee20193f39,
votes: 1, usage: 0.0 GB, proxy component: false)
まとめ
無事、vSANのコンポーネント障害 <absent> を復旧できました。
vsish コマンドによるdom ownerのリフレッシュは、inaccecibleステータスに対するアクションとしてVMware Communityに紹介されていたので、コンポーネントステータスがおかしい時はとりあえず実行してみるのがいいかもしれません。
..と、散々トラブルシュートした後に気づいたのですが、新規で仮想マシンを作成する際に"Force Provisioning(強制的なプロビジョニング)"のポリシーを適用していれば、オペレーション自体は実行できていたかもしれません。
とりあえず、vSAN Architectureの実践的な理解が深まったので良しとします☺。
長文お読みいただきありがとうございました。
