VMwareな日々

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

Ruby vSphere Consoleの使い方(vsan.check_state編)

TGIF!!ということで、先週末金曜日ということで、横浜にて諸先輩方とワインとコース料理を堪能しました:)

f:id:instructor8010:20170708100914p:plain

 

さて、本題です。

RVCのコマンドである”vsan.check_state”の内容ですが、これはvSAN環境に於けるVMとオブジェクトのステータス確認コマンドです。

こちらの図は正常時と障害時の比較です。f:id:instructor8010:20170625231252p:plain

このコマンドでは、Step1, 2, 3と3つの検査を行っています。

 

  • Step1ではオブジェクトへのアクセス可否を検査
  • Step2ではアクセス不可のVMの検査
  • Step3では同期が出来ていないVMの検査

 

 

緑の方が正常であり、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つが表示されています。

f:id:instructor8010:20170708105505p:plain

それぞれのオブジェクトのオブジェクトIDは、各枠内に、太線内に見えます。

 

一方、vsan.check_stateコマンドでは次のように上記のオブジェクトIDが閲覧可能です。このアクセス不可の結果、"Test-VM"アクセス不可、となっていると言えます。

f:id:instructor8010:20170708110212p:plain

結論:このコマンド結果は、vSANにおけるオブジェクトへのアクセス問題を表示し、それに伴い影響を受けるVMが表示される

何も出力がなければ、VMへの影響は起きていないと言える

大規模な環境に於いて、影響を受けているVMの範囲やその特定を行うのに向いているコマンドだと言える

 

<おまけ>

検証中に、次のような状況に当たりました。どこかがおかしいです。

f:id:instructor8010:20170708110417p:plain

 

 

 

 

 

 

 

 

 

あれ、オブジェクトが2つ見えていないと言いつつ、影響を受けているVMは存在しない(つまり全VMは正常である)という状況になっています。明らかな矛盾です。

f:id:instructor8010:20170708110444p:plain

 

これは、vSANに於ける、ストレージポリシーのステータスチェックが、このコマンド実行時になされていなかったことが要因で、このような状況に陥りました。

 

GUIでは、こちらにストレージポリシーの再チェックを促すボタンがありますので、こちらを押下後、正常に障害を検知することが出来ました。

f:id:instructor8010:20170708110820p:plain