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

(本検証実行時のvCenter Serverのバージョンは6.5.0、ビルドは4602587です)

vsan.check_limitsの出力情報についての紹介です。

今回は”limit”とあるので、何かの上限値が表示される、と予想が出来ます。

今回のコマンドは、クラスター単位での実行であり、クラスターに参加している全ノードの情報が次のように表示されました。

左から、ホスト名、RDTに関する情報、ディスクデバイスごとのコンポーネントの上限値と現在値についての記載のようです。

まず、”RDT”ですが、次のように説明があります。

RDTは、vSANを形成するコンポーネントの一種であり、ストレージとネットワークの上限値について管理をしているということが読み取れます。

AssocsとSocketsはネットワークの項目であり、その上限値と現在値のようです。

ClientsとOwnerはオブジェクトに対するDOM OwnerとDOM Clientに見えます。

esx-01a.corp.localだけが、owner値が2ですから、既存のオブジェクトの様子を確認してみたいと思います。

以前に学んだ”vsan.vm_object_info”より、”Test-VM2″というVMのホームディレクトリとVMDKオブジェクトがそれぞれ存在し、これらのオーナーがいずれもesx-01a.corp.localであることが確認出来ました。

ここで、念のためスナップショットをVMで取得してみ、それに合わせてDOM Ownerの値がクラスター内で増えるかを見てみます。

予想通りでした、これはDOM Ownerの値で問題ないようです。

続いて右側は単純に各ホストが保持出来るコンポーネントの数の上限と現在値です。
ここで一つ問題に当たります。

そもそもRVCコマンドラインリファレンスと出力が違うのは、恐らくvSANまたはvCenter Serverのバージョン違いだとしても、コンポーネントの上限数の9000ではない数字が表示されています。

色々情報を調べるも、上記数字の本来の意味合いには現状辿り着けておりません。

※困った時のコーマック・ホーガン氏とダンカン・エッピング氏のブログではこちらの情報を確認出来ませんでした。

※この後vSAN 6.2のHOLでもコマンド出力を確認するも↑と同じ結果でした。

※オールフラッシュ環境でしたので、ハイブリッド環境に変えてみましたが結果変わらず

一旦は構成の上限である9000が公式ソースかな、と理解している状況ですが、Updateがあればこちらの記事でここの数値に関する情報を追記したいと思います。

<2018/08/05追記>

本値は、vSANノード上に搭載されるシステムメモリ量に依存し、変動するとの情報を内的に得ましたことをご報告致します。

何GBの場合に上限値がいくつになる、というレベルの比較情報については現在調査中ですが、中の人からの情報です。

これまで紹介したコマンドと違い、若干要確認の内容が多い回となりましたが、ネットワークとストレージ周りの上限値を確認することが目的の出力だとわかりました。

vSphereの環境では、例えば、仮想スイッチのポート数にも上限があるため、上限値を超えた接続が要求されるとVMの起動が出来ないなど、上限値の把握が重要なシナリオがあります。

ですので、単純にCPUやメモリ、ディスクスペースなどの表面的なリソース以外にも、内的なコンポーネントの上限が原因で、サーバー停止に陥るようなことが無いよう、こうした項目の是非チェックをしていきましょう。

以上です。