1. 検証環境
今回は以下のバージョンで検証を実施します。
- ESXi 6.5 GA (Build-5310538)
- vCenter Server 6.5.0d (Build-5318154)
- vSAN 6.5 (vSAN ディスク フォーマット バージョン5)
2. 構成
vSAN クラスタを以下の設定で構成します。また、仮想マシンもテスト用に 3 台デプロイします (仮想マシン名: testvm01, testvm02, testvm03)。
| ノード数 |
3 台（ノード名: esxi-1, esxi-2, esxi-3） |
| ストレージタイプ |
ハイブリッド（磁気ディスクとSSD ディスクの組み合わせ） |
| デデュープおよび圧縮 |
無効 |
| 暗号化 |
無効 |
| ネットワーク モード |
ユニキャスト |
3. 前提
今回は 3 番目に停止させた ESXi ノード: esxi-3 に障害が発生し、シャットダウン後にパワーオンできず、残りの 2 台の ESXi ホストで仮想マシンを起動させるという想定で検証を行います。
4. 検証
上記検証機で実際に検証を行います。
4-1. 検証
ESXi ノードを 1 台ずつメンテナンスモードに移行し、シャットダウン処理を実施します。vSAN クラスタ シャットダウンを行う際、メンテナンスモード移行時に選択する退避モードは「
データの移行なし」を選択する決まりです。
1 台のノードをメンテナンスモードに移行したら、続いてそのノードのシャットダウン処理を行います。vSAN クラスタ内の複数のノードを同時にメンテナンスモードに移行しようとすると、メンテナンスモードに失敗する可能性があるため、注意が必要です。
残りの 2 ノード (esx-2, esx-3) に対しても同じ処理を繰り返します。
vSAN クラスタ内のすべてのノードを停止させると、Web Client のインベントリリストには下記図のようにすべてのノードが
“not responding” 状態になります。
4-2. ESXi ノードのパワーオンおよびメンテナンスモードの解除
2 台のノードのパワーオン処理よびメンテナンスモードを解除した後は、仮想マシンの “disconnected” 状態も解除されることが本来期待されます。しかしながら、下図のように今回の検証では仮想マシン testvm02 が
“orphaned” (親なし) 状態となります。
vSAN データストアのデータストアブラウザにも testvm02 のフォルダは表示されません。
vSAN クラスタ シャットダウンから起動後、仮想マシンにアクセスできない状況が発生しました。
vSAN 健全性アラームには多数の「失敗」項目が表示されています。
上記「失敗」項目は主にノード esxi-3 が停止状態であることに起因するものでしたが、1 つのオブジェクトが「
アクセス不可」状態となっています。
5. ログ採取
ここからは資料を採取し、資料から状況を確認します。本事象の調査を行う際、重要な資料はこちらです。
SAN クラスタ内のすべての ESXi ノードの vm-support ログバンドル資料
各 ESXi ノードの状況を確認するために必要です。vSAN データストア内のオブジェクトの状況を簡単に確認するのみであれば 1 台のみの情報でも確認は可能ですが、各 ESXi ホストの状況を確認するためには、基本的に vSAN クラスタ内すべての ESXi ホストの vm-support ログバンドルが必要です。
vCenter Server の vc-support ログバンドル資料
今回のケースでは確認しませんが、事象が発生した際の vCenter Server 側の状況を確認するために必要な資料です。
vCenter Server のイベントログ資料（システム、ユーザー）
vCenter Server および vCenter Server に登録されている ESXi ノード上で発生した事象の全体像を把握するために必要な資料です。
RVC コマンドによる support_information 資料
RVC は Ruby をベースに開発された vSAN の構成情報や特定の設定を行うための
コマンドです。support_information サブコマンドを実行することで、vSAN に関連する構成情報が一通り出力されます。
6. 状況の詳細確認
サポートチームでは上記資料をいただくことで、ESXi ノードのログから実施した作業内容の確認や、ログの確認等の調査を実施しますが、今回は Web Client の GUI やsupport_information 資料から問題が発生している仮想マシン testvm02 のオブジェクトの状況を確認します。
VM testvm02 ネームスペース オブジェクト:
仮想マシン testvm02 のネームスペース オブジェクトは FTT=1 が設定されており、2つのコンポーネントと 1 つの監視コンポーネントで構成されています。オブジェクトのコンポーネントは 2 つとも 「
なし」
状態 (英語表記では ABSENT で表示されます) であり、仮想マシンのネームスペースオブジェクトとして正しく認識することができない状態となっています。
オブジェクトを構成する 3 つのコンポーネントのうち 2 つのコンポーネントに異常が発生すると、クォーラムを維持することができず、そのオブジェクトは「
アクセス不可」の状態になります。Web Client で orphaned 状態になる症状や、データストアブラウザで仮想マシン testvm02 のフォルダが表示されない状態になる症状はオブジェクトが「アクセス不可」状態になったことが原因です。
次に、上記 3 つのコンポーネントについてもう少し詳しく説明します。
Witness コンポーネント
本コンポーネントは監視コンポーネントとも呼ばれる種類のコンポーネントであり、
ノード esxi-2 に配置されている
正常な状態 (アクティブ) のコンポーネントです。
「オブジェクトが見つかりません」と表示されているコンポーネント
本コンポーネントはオーナーのホストが不明な状態となっており、Web Client の画面からはどのノードに配置されているかを特定することができません。しかし vm-support 資料と組み合わせると、本コンポーネントは esxi-3 のディスクグループに配置されていることが確認できます。esxi-3 が停止状態であるため、本コンポーネントが見えない状態であることは
想定される状態です。
「esxi-1.gsslabs.org」上に配置されているコンポーネント」
このコンポーネントが本事象の中で
最もポイントとなるコンポーネントです。本コンポーネントが配置されているノード esxi-1 は正常に稼働しており、オブジェクト自体はアクセスできる状態のはずであり、本来 ACTIVE 状態になることが期待されていたコンポーネントです。しかし、本コンポーネントは support_information 資料を見ると
古いオブジェクト (STALE) と判断され、
ABSENT 状態とみなされています。
参考: support_information 資料より一部抜粋：
Component: a534385d-cb99-ce92-901b-005056034eb0
state: ABSENT (6), csn:
STALE (1!=2), host: esxi-1.gsslabs.org
本検証では esxi-1 を最初にメンテナンスモードに移行しましたが、esxi-1 のディスクグループに格納されているオブジェクトは、esxi-1 がメンテナンスモードに移行した段階でオブジェクトの更新処理がストップします。その後、esxi-2 と esxi-3 間でオブジェクトの更新が行われると、esxi-1 の持つオブジェクト情報は古いオブジェクト (
STALE) となります。
このケースでは、新しいコンポーネント情報を持つノード esxi-3 を復旧させることで、事象が解消されることが見込まれます。
7. 復旧
ノード esxi-3 を起動し、メンテナンスモードの解除処理を実施することで今回の事象は復旧します。仮想マシンのパワーオンも可能です。
8. 終わりに
今回はホスト障害を想定した検証を行いましたが、本事象はどのような障害が発生するかによって、vSAN データストア内のデータの影響の有無や、影響した場合の範囲等は大きく異なります。実環境では障害そのものの対応や、今回の検証環境よりも大規模であるケースが想定されるため、本検証のようにスムーズに復旧するかは不明であり、もう少し複雑な状況になることが想定されます。
KB#60424 ではノードのメンテナンスモードの移行処理を実施する前にノードの時刻を揃え、同時に vSAN ネットワークの無効化を行うことで、STALE コンポーネントの発生を抑止する回避策が紹介されています。
今回紹介した事象を回避するために、vSAN クラスタ全体の停止作業を実施する場合は必ず
KB#60424を実施いただくようお願いします。
またお使いの環境で万一今回ご紹介した vSAN クラスタ シャットダウンに伴う事象が発生した際は、速やかにサポートにお問い合わせください。その時々の状況に即した対応策を案内させていただきます。
