VMwareな日々

Blog移管しました 新URLはこちら https://lab8010.com/

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