Ruby vSphere Consoleの使い方(vsan.resync_dashboard編)
もう間もなく、このRVCのvsan.support_infoシリーズも終わりを迎えます。
回を重ねるごとに、新しい発見もあるので、なかなか楽しくブログを書くことが出来ました。
さて、今回のコマンドは"vsan.resync_dashboard"ですが、vSAN 5.5ユーザーの方はお世話にならざるを得なかったコマンドだと言えます。
そして、vSAN 6.0以降はこのコマンドに相当する機能が、vSphere Web Clientに登場しました。
このコマンドでは、コンポーネントの再同期の様子、進捗をモニタリングすることが出来ます。
従来のRAIDで言えば、リビルドの進捗を見る、ストレージ管理ツール、とでも言えます。
さて、まずコマンド出力の様子を確認してみましょう。
非常に見た目はシンプルですね。項目としては次の2つが閲覧出来るようです。
- 同期中のオブジェクト数
- 残る同期のデータ量
続いてGUIでの同じ画面を見てみましょう。
このような画面です。項目としては次の内容が確認可能です。
- 同期中のオブジェクト数
- 残る同期のデータ量
- 同期の完了目安時間
これらの図では、同期が走っていませんでしたので、強制的に再同期が走るケースを作り出したいと思います。
■シナリオ■
VMを1台作成し、RAID1, FTT=1で保護する。コンポーネントを保護するホストをメンテナンスモードにし、同期を誘発させる。
★補足★
vSANではホストレベルの障害は、即時障害扱いとはなりません。障害の種類が2タイプあり、”不完全(Absent)”と呼ばれる症状として認定され、デフォルトでは60分間の障害検知タイマーがタイムアウトしてから、再同期動作が走ります。
ですので、まずこの値を変更しておきます。デフォルト値の60が入っています。
ここを1に変更すれば、メンテナンスモード投入後、1分で再同期が走ると言えます。
↓
この後CLOMDサービスを再起動します。詳細はこちらをご確認ください。
準備が整いました。
現在"Test-VM"のコンポーネントは1号機、3号機、4号機によって保護されています。
今回は3号機をメンテナンスモードに設定します。メンテナンスモード設定後1分以内はコンポーネントはAbsentとなると予想されます。
まず想定通りの動作です。コンポーネントアクセスができなくなり、Absent表示に変化
これに呼応し、ポリシー準拠ステータスもNoncompliantに変化します。
1分後、再同期が開始されました。
Absentのステータスはそのまま残り、新たに再同期のコンポーネントが登場しました。
この後、GUIとCLIでの同期ステータスチェックを行います。
※残念ながら、仮想環境上でデプロイが出来るVMDKサイズが小さく、一瞬で同期が終わってしまいました。
※何度も何度もメンテナンスモード投入などを行ったので、以下2枚の図では同期対象のホストが異なりますが、上記の理由によるものです。
まずGUIでの同期ステータス状況です。開いた瞬間残り時間0秒でしたので、ギリギリアクセスが出来たような状態です。
次にCLIでの同期ステータス状況です。コマンドを実行したタイミングの情報を取ってくる動きのため、リアルタイムな画面更新はありません。
何度かコマンドを連続で実行していたのですが、一瞬だけ同期の様子を確認することが出来ました。
以上です。
結論：コンポーネントの同期は、GUI/CLIいずれでも確認は可能である。
参照出来る情報には差があり、いずれもリアルタイムでの情報更新はありません。
(なお、検証動作環境はVMware Hands on LAB HOL-1708 vSAN 6.2 from A to Zより)
Ruby vSphere Consoleの使い方(vsan.check_state編)
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では、こちらにストレージポリシーの再チェックを促すボタンがありますので、こちらを押下後、正常に障害を検知することが出来ました。
vSphere Update ManagerにDellのレポジトリを追加してみた
しばらくvSAN 6.2のトレーニング続きで、なかなかvSphere 6.5環境を触れず、久しぶりにvCenter Server 6.5をデプロイしてみました。
そういえば、vCenter Server 6.5からは、”vSphere Update Manager”がビルトインされたため、専用にWindows Serverをデプロイしなくてよくなったのを思い出しました。
これまで、大変便利な機能だと感じつつも、Windows Serverを用意しなくてはいけない点、またデータベースも規模によるがSQL Serverの準備など、なかなか準備までに時間に手間がかかりました。
今回は、せっかくですので、vCenter Server 6.5をデプロイしたので、簡単にGUIのウォークスルーと、Dellのレポジトリ追加を行ってみたいと思います。
※ちなみに元ネタはこちらです。私の同僚から教えていただきました。
まず、vSphere Web Clientにアクセスした直後の図です。
特にインストールしたわけでもないのに、Update Managerのアイコンが見えているのは個人的には感動です。ついにきたか！という感じです。
さて、メニュークリック後、パッチマネジメントのリポジトリ管理画面を表示しました。
※リポジトリとは、ファイルを提供してくれる保管庫みたいな役割を意味します。
※iPhoneならApp Store, AndroidならGoogle Playなんかもリポジトリと言えますね。
標準では、3つの、いずれもVMwareオフィシャルなリポジトリソースが登録されています。
ここに、Dellのリポジトリである、以下のURLを登録してみます。
http://vmwaredepot.dell.com/index.xml
こんな感じで入力しました。
”OK”押下後、即座にリポジトリと接続が確立されました。(ちなみに、vCenter ServerはWAN接続ありな状態です)
それでは、どのような更新情報が入手できるか、”今すぐダウンロード”を行ってみたいと思います。
Dell OpenManageとiDRAC Service Moduleの2つが複数バージョン提供されています。
単一のパッチをクリックすれば、アップデートに対する詳細情報も閲覧が出来ます。
以上です。この後の流れは、次の通りです。
- ベースラインの作成
- ベースラインの適用(ホストや仮想マシンに対し)
- ベースラインの準拠状態のスキャン
- ベースラインと現在の状況に差がある場合は、不足分のパッチ適用
- 必要に応じ、自動的にホストがメンテナンスモード、再起動が発生する
- 複数ノードがある場合は、この繰り返し
今回適用まで行なおうかと思いましたが、1ノードかつそのノード上にvCenter Serverが動いている状態でしたので、今回はvSphere Update Managerでの更新は行わず、後ほど手作業で行おうと思います。
vSANのパフォーマンス統計データはどのように保存されるか
今回も実際のトレーニングであった話です。
受講生Tさん：vSANのパフォーマンス統計データは保存先vSAN Datastore以外利用出来ますか？
良い着眼点ですね。ストレージ管理に於いて、パフォーマンスの監視は重要です。
まず基本的なパフォーマンス取得機能は以下をご覧頂ければ理解ができます。
vSphere Web Clientでは、これまでvSANのパフォーマンス情報(IOPS/スループット/遅延など)は閲覧が出来ませんでした。代わりとして、"vSAN Observer"という機能を利用する必要がありました。
vSAN 6.2からはvSphere Web Clientにてこの情報を閲覧が出来るようになりました。
この際、vSANのパフォーマンス情報は、vSANのデータストア上に保存されます。
つまり、この統計情報も”オブジェクト”であり、”ストレージポリシー”により保護されます。
ここで、こんな疑問が生まれます。
- パフォーマンス情報を取得し続けると、データが肥大化するのか
- パフォーマンス情報は、ローテートなど、古いデータのパージは行われるか
- パフォーマンス情報は、保存先をvSANデータストア以外を利用出来るか
- どれ位の期間のパフォーマンス情報を保存出来るのか
答えはここにありました。
一部抜粋しました。(KBのUpdateは2017/01/30のものです)
- データサイズの上限は255GBと既定されています。
- パフォーマンス統計の取得は約3ヶ月と記載があります。
- 古いデータはパージされます。
残念ながら、別のデータストアへの保存については言及がありませんが、vSANデータストアのみを前提としているようですね。
ディスク要求モードの変更について
vSAN環境では、SSD/HDDをデータストアに含める際に、”ディスク要求モード”と呼ばれるモードに基づいてそれらが組み込まれます。
概要はこちらをご覧ください。
さて、モードは2種類あり、”自動”と”手動”です。
自動の場合は、自動的にディスクグループが構成されます。
手動の場合は、ユーザーがどのSSDをキャッシュ層に含め、どのSSDまたはHDDをキャパシティ層に含めるかを選択する必要があります。
現在のユーザーのモード確認は、次の画面から確認が出来ます。
今回は次のような質問がありました。
”一度、自動モードを構成したvSANで、これを手動に変更した場合、ディスクグループは残るか？”
早速試しました。
結論は、”残る”です。(VMware ハンズオンラボ vSAN 6.2 A to Zにて確認済み)
ある意味当たり前かなとも言える結果ですし、”わざわざ自動から手動に変更するようなケースはあるのか？”とも言えます。
実は、ディスク交換時ですが、”手動モードでないと、ディスクの取り外しが出来ません”
操作を実施しようとした場合、次のようなエラーが表示されます。
ですので、メンテナンスによるディスク交換時には、モードを”手動”に変更する必要が出てきます。
以下の表記はvSAN 6.2の管理ガイドより抜粋です。
https://docs.vmware.com/en/VMware-vSphere/6.0/virtual-san-62-administration-guide.pdf
なお、vSAN 6.6のドキュメントでは・・・
https://docs.vmware.com/en/VMware-vSphere/6.5/virtual-san-66-administration-guide.pdf
表記が消えています。この点が解消されたのでしょうか。
いいえ、挙動は同じでした。
ドキュメントバージョンが、EN-002503-01ですので、これ以降のリビジョンにてこの点が修正されると思われます。
結論：ディスク交換時には、ディスク要求モードは”手動”でなければならない(2017/07時点)
Ruby vSphere Consoleの使い方(vsan.lldpnetmap編)
さて、だんだんこのシリーズも定着してきました。
今回はコマンド内にある用語に”LLDP”と入っていますので、内容が想像しやすいです。
”Link Layer Discovery Protocol”ですね。つまり、ホストが隣接するスイッチの情報が拾えるというやつです。
Windows Vista, 7の頃に、以下のようにネットワークトポロジーを可視化するための機能がありました。これはLLDPにより収集された情報をベースにしたものです。
似た動作をするプロトコルに”Cisco Discovery Protocol”がありますので、そちらを知っている方は、イメージがし易いと思います。
今回はこのコマンドを出力するのに、VMware Hands on LABを利用した所、次の状態に遭遇しました。
何も表示がありません。ある程度予測はしていました。
今回はVMwareのR&DのWilliam氏のブログです。LLDPコマンドの使い方を紹介しています。
彼によれば、次のように対向のスイッチがCiscoスイッチか、またはLLDP非対応のスイッチである場合情報取得が出来ないとある。
Hands on LABは仮想環境上にデプロイされたESXi環境なので、次のように”仮想ハードウェア上ではこのコマンドは利用不可”と言われてしまいました。
今回はブログ作成時に物理スイッチ環境かつLLDPサポート環境がなかったので、
RVCのコマンドリファンレスガイドから出力結果を参照してみました。
ここでは、ホスト”10.143.188.54”は、”vmnic5”と"vmnic7"が対向のネットワーク製品”w2r13~”から始まる製品につながっている状態を示しています。
結論としては、この機能はLLDP対応の機器が利用されている場合のみ利用が出来る、ネットワーク接続先の情報を取得するコマンドと言えます。
<補足>LLDPは仮想スイッチやホスト側でも設定が必要です。
次の図では、仮想スイッチ上で、Discovery Protocolが無効になっています。
設定から”Link Layer Discovery Protocol”を選択します。
この設定により、LLDPでの情報が拾えるようになります。
ちなみにプロトコルの動作モードは、3タイプあります。情報を拾うにはListenかBothである必要があります。
Listenは、仮想スイッチが対向の機器からLLDPプロトコルを利用し、デバイス情報を取得する、という設定です。
Advertiseは、仮想スイッチが対向の機器にLLDPプロトコルを通じて、自分自身がVMwareの仮想スイッチであることを通達する、という設定です。
Bothは、上記両方の動きです。
便利な機能ですが、デバイス情報の通知はセキュアでないと考えられるケースもあるため、管理者はセキュリティの強化のためにこの機能を利用しない、一部利用するなど選択肢が与えられていると理解出来ます。
Ruby vSphere Consoleの使い方(vsan.check_limits編)
(本検証実行時のvCenter Serverのバージョンは6.5.0、ビルドは4602587です)
vsan.check_limitsの出力情報についての紹介です。
今回は"limit"とあるので、何かの上限値が表示される、と予想が出来ます。
今回のコマンドは、クラスター単位での実行であり、クラスターに参加している全ノードの情報が次のように表示されました。
左から、ホスト名、RDTに関する情報、ディスクデバイスごとのコンポーネントの上限値と現在値についての記載のようです。
まず、”RDT”ですが、次のように説明があります。
Virtual SAN Diagnostics & Troubleshooting Reference Manual (52ページより引用)
Ruby vSphere Console Command Reference for Virtual SAN (20ページ引用)
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やメモリ、ディスクスペースなどの表面的なリソース以外にも、内的なコンポーネントの上限が原因で、サーバー停止に陥るようなことが無いよう、こうした項目の是非チェックをしていきましょう。
以上です。
