TGIF!!ということで、先週末金曜日ということで、横浜にて諸先輩方とワインとコース料理を堪能しました:)
さて、本題です。
RVCのコマンドである”vsan.check_state”の内容ですが、これはvSAN環境に於けるVMとオブジェクトのステータス確認コマンドです。
こちらの図は正常時と障害時の比較です。
このコマンドでは、Step1, 2, 3と3つの検査を行っています。
緑の方が正常であり、Step1では”Detected 0 objects to be inaccessible”(つまり、アクセス不可のオブジェクトを0個検出しました)とあり、Step2では何も表示されていません。Step3では”Did not find VMs for which VC/hostd/vmx are out of sync”(つまり、同期されていないものは無い)
赤の方は障害状態であり、Step1にて2つのオブジェクトへのアクセスができない旨が表示されています。
Step2では”Test-VM”という名称のVMがアクセス不可になっています。
(コンポーネントが50%以上保持できず、起動不可な状態と言えます)
Step3は同じ状態です。今回の疑似障害シナリオでは、同期問題は発生させていません。
ちなみに今回は、4ノードvSANクラスター内のうち、2ノードをメンテナンスモードで強制的に利用不可にしています。これにより、VMを形成するオブジェクトが利用不可なわけです。
上記で上げている2つのオブジェクトですが、これは”VMネームスペース オブジェクト”と”VMDKオブジェクト”です。
この事は、vsan.object_infoと付け合わせればそのことが分かります。
以下の2つの図は、上記写真とは別日で検証を行ったので、オブジェクトIDが異なっています。
まずこちらの図では、vsan.object_infoコマンドにより、”Test-VM“というVMの、構成ファイル群を保持するディレクトリである”ネームスペース ディレクトリ オブジェクト(赤)”と、”VMDKオブジェクト(青)”の2つオブジェクトの2つが表示されています。
それぞれのオブジェクトのオブジェクトIDは、各枠内に、太線内に見えます。
一方、vsan.check_stateコマンドでは次のように上記のオブジェクトIDが閲覧可能です。このアクセス不可の結果、”Test-VM“アクセス不可、となっていると言えます。
結論：このコマンド結果は、vSANにおけるオブジェクトへのアクセス問題を表示し、それに伴い影響を受けるVMが表示される
何も出力がなければ、VMへの影響は起きていないと言える
大規模な環境に於いて、影響を受けているVMの範囲やその特定を行うのに向いているコマンドだと言える
＜おまけ＞
検証中に、次のような状況に当たりました。どこかがおかしいです。
あれ、オブジェクトが2つ見えていないと言いつつ、影響を受けているVMは存在しない(つまり全VMは正常である)という状況になっています。明らかな矛盾です。
これは、vSANに於ける、ストレージポリシーのステータスチェックが、このコマンド実行時になされていなかったことが要因で、このような状況に陥りました。
GUIでは、こちらにストレージポリシーの再チェックを促すボタンがありますので、こちらを押下後、正常に障害を検知することが出来ました。
コメント