VMwareな日々

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

Ruby vSphere Consoleを試してみた(vsan.support_information編)

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

さて、前回のRVCから続き、第2弾です。

RVCはその性質上、込み入ったトラブルシュートを行うためのツールという要素が強いです。

そこで今回は、テクニカルサポートや管理者の方にとって重要なサポート情報収集コマンドを試しに実行してみました。

まず最初にSSHでvCenter Serverアプライアンスへ接続し、既にRVCは起動済みです。
かつ、cdコマンドによりデータセンターディレクトリまで移動済みであり、直下にはクラスターオブジェクトが”0”として存在する状況です。

ここで次のコマンドを実行しました"vsan.support_information 0"

f:id:instructor8010:20170625232532p:plain

すると、2分ほどの時間で、多くのコマンドが自動実行されました。

Puttyを見てみると、次のコマンドが実行されていることがわかりました。

以上です。

各コマンドについての詳細は個別ページでまとめていきたいと思います。

(記事自体が長くなることを避け、今後の更新をしやすくするためです)

Ruby vSphere Consoleを試してみた(起動/ログイン/基本操作編)

今回はRVCというツールについて紹介をする記事を書いてみました。

RVCとは"Ruby vSphere Console"の略称であり、vSAN環境のサポートやトラブルシュートに使うハイレベルなサポートツールです。このツールはCLIであり、vSphere Web ClientなどのGUIでは出来ない操作が出来るという点が特徴と言えます。

ユースケースとしては、上記のようなケースであり、既に幾つかのKBなどでは、コンプレックスな症状に対して、RVCを利用するようにと記載されたものもあります。

 

コマンドラインファンレスも存在し、以下のようにPDFで提供があります。

VMware® Ruby vSphere Console Command Reference for Virtual SAN

 

さて、今回はまず肝心のツールの起動方法、ログイン方法の紹介です。

  • このツールは、vCenter Server上に存在する
  • Windows版vCenter Serverでも、アプライアンス版でも利用が可能
  • Windows版の場合は、既定ディレクトリ上にあるbatファイルを動作させ、RVCを起動します。bat動作後、vCenter ServerがインストールされたWindows Server上にてコマンドプロンプトを動作させ、vCenter Serverディレクトリへcdコマンドで移動します。
  • vSAN 6.x の場合: %PROGRAMFILES%\VMware\vCenter Server\rvc\rvc.bat
  • vSAN 5.5 の場合: %PROGRAMFILES%\VMware\Infrastructure\VirtualCenter Server\support\rvc\rvc.bat
  • アプライアンス版の場合は、SSHクライアントよりvCenter Serverにアクセスしツールを利用します。

今回は、アプライアンス版にて操作を行ってみます。以下の図では、既にPuttyにてvCenter Serverに対しSSH接続が確立している様子です。

f:id:instructor8010:20170625224317p:plain

SSHログイン後、次のコマンドを入力しています。

"rvc ユーザー名@ログイン先"

rvcによりツールを起動し、ログイン先のvCenter Serverの指定とそれに使うユーザーを引数として指定しています。その後、パスワードを入力し、rvcが利用出来るようになりました。

※上記ログインの手順の詳細については、コマンドラインリファレンスの6ページくらいにも記載があります。

f:id:instructor8010:20170625224540p:plain

一般的なCLIにあるような次の機能が利用可能です。

  • helpコマンドによるコマンド確認
  • Tabキーによるコマンド補完
  • Wildcardによる複数のVMやホストに対する命令
  • Markコマンドによる特定のVMやホストなどのエイリアス作成

さて、基本的には"ls"と"cd"を駆使し、階層構造となっているvSAN環境を確認する所がはじめのステップと言えます。

vSANコマンドを使う上では、コマンドを実行する対象のパスを指定するためには階層構造になっているこれらの単位の状況を、この2つのコマンドで確認する必要があります。

 

例えばこちらをご覧頂くと、”ls”で現在のディレクトリ内部を確認しています。

lsで確認した内容の先頭には番号がついており、これを用いて"cd"でより深い階層に移動しています。

f:id:instructor8010:20170625225243p:plain

ここでは、"RegionA01"というデータセンター内の”コンピュートリソース”を確認しており、4つのコンピュートリソースを確認出来ている状態です。(RegionA01-COMP01という名称のクラスタが1つ、それ以外はesx-から始まる名称の単体のホストが連番で3台あります)

vSphere Web ClientのGUIと対比するとわかりやすくなりますね:)

f:id:instructor8010:20170625225838p:plain

さて、現在はこの赤色の、データセンターレイヤーからコンピュートリソースを見下ろしているような状態です。

ここで、何か試しにホストの情報を取ってみたいと思います。

f:id:instructor8010:20170625230144p:plain

vsan.check_stateというコマンドを実施してみました。このコマンドではvSANクラスター上にあるオブジェクトの状況やVMの状態を表示させるという意味合いがあります。

赤はコマンドの失敗例です。
上記コマンドだけを入力しており、コマンド実行対象を入れていません。

緑はコマンドの成功例です。
上記コマンドに”0”を加えた事で、コマンド実行対象としてクラスターを指定しました。
しかし、残念ながら、このvSANクラスターにはVMを作成していなかったので、アクセスが出来ないオブジェクトは0であり、構成誤りのVMや同期が出来ていないVMなども見つからなかったという結果になっています。

 

最後に、VMを1台だけ作って、コマンドを実行してみました。

Test-VMという名称でテスト用VMを作成しました。

f:id:instructor8010:20170625230655p:plain

コマンドの性質上、vSAN環境上のVMのオブジェクトへのアクセスに問題が無いかの概要を確認するコマンドでしたので、正常なケースと障害ケースでコマンド出力を出してみました。

f:id:instructor8010:20170625231252p:plain

緑枠:正常なケース(VMはFTT=1で保護されており、オブジェクトのコンポーネントは全てアクセスが可能な状態)

赤枠:異常なケース(3ノードクラスターのうち、2ノードをメンテナンスモードにし、無理やりコンポーネントアクセスが出来ない状態を作成しました)

f:id:instructor8010:20170625231801p:plain

以上でした。今回はRVCの起動、ログイン、基本操作についての紹介でした。

今後は少しずついろいろなコマンドを試していきたいと思います。

vSAN環境に於いて、ドライブ交換時はメンテナンスモードを利用する必要があるか?

さて、土日を迎えたわけですが、来週はブレードサーバーと相も変わらずvSphere vSAN 6.2 Deploy & Manageのトレーニング提供です。

やるたびやるたび話したい内容が増えていきます。

 

さて、前回のトレーニング中に受けた質問にこんなものがありました。

■トレーニング受講生のGさん:すいません、資料には”ドライブ交換の際って、ESXiはメンテナンスモードにする必要がありますか?”

■私:いや、特に不要だと思われます。でもよく見ると確かにスライドにそういう記述がありますね。ホットプラグ非対応なサーバーをシャットダウンする時には設定が必要と言えるから載ってるようにも見えますね。

実際前に私が擬似障害を発生させた場合は、メンテナンスモードにしなくともオブジェクトの再同期はうまく行きました。この経験に基づけば、不要かな、とも言えます。

しかし、どうにもスライドで態々メンテナンスモードにすると書いてある記載がどうにも気になり調べてみました。

 

 

で、ここに行き着いたわけです。困ったときのコーマック・ホーガン先生です。

blogs.vmware.com

コーマック先生によると、VMwareはディスクグループまたはディスクの交換を安全に行うためのは、データをなるべく退避し交換作業を行うことを強く勧める、とのことです。

f:id:instructor8010:20170623213021p:plain

なるほど、まぁ安全性という意味では確かに、と頷けます。

また、ディスク交換に関連するページでも、次のように交換作業時のデータ欠損リスクを無くすために、データ退避を勧めていますね。

VMware vSphere 6.5 Documentation Library

f:id:instructor8010:20170623214902p:plain

しかし、ディスク交換のために正常稼働しているディスク上のデータの移行も発生するわけであります。またメンテナンスモードに投入したvSAN  クラスターノードはディスクグループ上のキャッシュとキャパシティの提供を行わなくなります。

VMware vSphere 6.5 Documentation Library

f:id:instructor8010:20170623214209p:plain

これらの点から言えるのは、vSAN クラスター内で、メンテナンスモードに設定されるホストが提供する空き容量が大きい場合、メンテナンスモード投入後に空き容量が不足する可能性が考えられるため、ノードごとの提供容量が均一化されている方が、単一ノードのメンテナンスモード設定による影響が低減出来ることを意味します。

(極端にノード間でディスク容量に差がある場合、高キャパシティを提供するノードの欠損はクラスターに対しいい影響があるとは言いづらいです)

また、それだけではなく、DRS(Distributed Resource Scheduler)を利用している環境では、メンテナンスモードに伴う、自動vMotionも誘発されるため、自ずとメンテナンスモードに設定されるコンピュートリソース(CPU, メモリ)も、一時的に減ることを意味します。

 

と、言うことはデータ退避が目的のはずのメンテナンスモードであるにも関わらず、コンピュートリソースまで減るのは少し影響があるように見えます。

ここでコーマック先生は続けて次のようにコメントしています。

f:id:instructor8010:20170623215529p:plain

 vSAN 6.0からはメンテナンスモードにしなくとも、ディスクグループ削除またはディスクの削除時にデータ移行のオペレーションが出来るようになった、と言っています。

確かに、6.0からは仕様が変更されており、メンテナンスモードでなくともこれらのオペレーションは出来ます。

そういう意味では、6.0以降であれば必ずしもメンテナンスモードでなくとも、データ退避は出来ますからこちらの手法でもいいかもしれませんね。

 

ということで、今回は次の結論に行き着いたと言えます。

結論:VMwareとしては、ディスク交換時には、関連ディスクグループ内のデータを移動することを推奨している。

但し、3ノードクラスターでのFTT=1構成など、構成規模によってはデータ移行が出来ない環境もあるため、そうした環境ではその次第ではないことも念頭においておく必要が有るといえます。

vSphereインターフェース上からのディスクの物理ロケーションIDを考える(2) RAID 0モード編

 さて、前回の続きです。

instructor8010.hatenablog.jp

 

前回の記事を投稿まもなくお読みいただいた方は、画像のキャプチャを少し見やすいものにしましたので、再度記事を確認いただけると幸いです。

さて、今回はコントローラーがディスクを取り扱うモードを”RAIDモード”へ変更します。

 

まず、以下の図は”パススルーモード”にて各ディスクが認識されている図です。

ランタイム名のvmhbaxx:Cxx:Txx:LxxのTxxにて物理ロケーションがわかるという話でした。

f:id:instructor8010:20170622133931p:plain

この後、コントローラーがディスクを取り扱うモードを、パススルーモードからRAIDモードに変更し、このランタイム名が変化するかを見るという検証です。

 

こちらの図は、Dell PowerEdgeのiDRAC(Integrated Dell Remote Access Controller)よりディスクを確認している状況です。モード変更前ですから、”非RAID”モードとなっています。

f:id:instructor8010:20170622134517p:plain

iDRACよりディスクモードを変更します。こちらのページよりプルダウンで変更操作を行っていきます。(物理ディスク→セットアップ)

f:id:instructor8010:20170622134942p:plain

RAIDに変換”をセットし、変更を適用するため再起動も行います。

f:id:instructor8010:20170622135126p:plain

 再起動を経て、iDRAC上のディスクのステータスが、”非RAID”から”準備完了”に変化しました。(これは想定どおりの動きです)

f:id:instructor8010:20170622140542p:plain

RAID0をまだ組んでいないので、次のようにディスクがvmkernelから見えない状況です。(これも想定どおりの動きです)

f:id:instructor8010:20170622140801p:plain

ひとまず先ほど擬似障害を起こしたID 0のディスクを、RAID 0に設定してみます。

RAID構成になったため、RAID参加後のステータスに変化しました)

f:id:instructor8010:20170622142338p:plain

RAID 0が構成された、ID 0のディスクは、"vmhba0:C2:T0:L0"であがってきました。

f:id:instructor8010:20170622142553p:plain

 

RAIDモード時のID 0のディスクのランタイム名:vmhba0:C2:T0:L0

パススルーモード時のID 0のディスクのランタイム名:vmhba0:C0:T0:L0

RAID構成になることで、チャネルIDだけが変わっているようです。

たまたまターゲットIDが同じだった可能性も考慮し、全部のディスクをRAID 0モードに設定してみます。

念のためRAID BIOSでも8本のRAID 0があることを確認します。

f:id:instructor8010:20170622164522p:plain

vSphere Clientから見てみた図がこちらです。やはり、ランタイム名で見た場合すべてがチャネル2であり、ターゲットIDは0~7です。

f:id:instructor8010:20170622165351p:plainランタイム名は、”ストレージLUNを、パス名で識別する”ことが目的のものとなりますので、例えばドライブの物理ロケーションが人為的な操作で入れ替えられると、実際それが元のデバイスかどうかはわかりません。

 

ですので、さらに念には念を入れて、”識別子”も使って本当にこのランタイム名が以前のパススルーモードのときと同じかを見てみます。

f:id:instructor8010:20170622170953p:plain

ここは残念ながら一致しておらず、RAIDを構成した段階でDellPERCにより制御される形となり、識別子が新規に生成されてしまっています。ですので、識別子を用いてのディスクが同一かどうかは確認ができませんでしたので、シャーシから0番と5番を抜いて見ます。(ディスクはランダムに選んでみました)

これまでの流れでいえば、次のランタイム名のIDがグレーアウトすると予想できます。

  • vmhba0:C2:T0:L0(ディスクID 0)
  • vmhba0:C2:T5:L0(ディスクID 5)

f:id:instructor8010:20170622171321p:plain予想通り、上記のランタイム名が2つともグレーアウトしました。

結論:ターゲットIDが物理的なロケーションと一致する

但し、VMwareでは以下にあるようにこの識別子は再起動ごとに変わるリスクがあることを説明しているため、今回のように実検証を予め行っておいたほうが、より確実だと言えます。

f:id:instructor8010:20170622172459p:plain

 

pubs.vmware.com

 

もちろん、vSphere Web Client上から、障害ドライブのLEDをブリンクさせることができれば、その方法が一番確実な障害ディスク確認手法としては適切であり、確実と言えます。

今回の手法は、あくまでも上記の手順が実施できない場合の対策として把握しておくとよいと言えます。

巨大なVMDKをvSAN環境上でデプロイする場合

以前にVirtual SAN 6.2 Deploy and Manageクラスを提供した時に、受講生からこんな質問を受けました。

mylearn.vmware.com

----------------------------------------------------------------------------------------------------------------------

受講生:vSANデータストア上でのVMDK(仮想ハードディスク)のサイズの上限はいくつですか?

私:62TBです、構成の上限を参照してみるとそれがわかります。

f:id:instructor8010:20170325205112p:plain

受講生:ありがとうございます。もう1つ質問ですが、vSANの教科書ではコンポーネントの単一のサイズは255GBと記載があります。そしてvSANポリシーのストライプ数は12が最大値だと思うので、矛盾してるように思います。62TBのVMDKはどのような形で保存されるのでしょうか?

----------------------------------------------------------------------------------------------------------------------

なるほど、そんなに大きなVMDKを作ることを、自分が行った検証では行ってはおらず、あまり気にしてはいませんでした。

そして手持ちの環境では数TBあるディスクが直ぐに用意ができませんでしたので、検証レポートを書いてるブログなどが無いかを調べてみました。

Cormac Hogan氏のブログで見つけちゃいました。英語なので日本語で読みたいという方向けに解説を入れたいと思います。

cormachogan.com

まず彼のブログでは8TBのVMDKをRAID5ポリシーで保護した場合の動作が紹介されていました。

RAID5の場合は、保護するVMDKの容量に対し133%の容量が必要となるため、
8TB*133%で、約10.6TBが必要となります。(最小必要ホスト数は4台)

ちなみにRAID1の場合は、保護するVMDKの容量に対し200%の容量が必要となるため、8TB*200%で、約16TBが必要となります。(最小必要ホスト数は3台)

 

そして、実際にRAID5で8TBのVMDKを保護してみた結果がこちらだったそうです。

f:id:instructor8010:20170325211002p:plain

結論から言えば、1ホスト当たり11個のコンポーネントが展開され、1クラスターに対し4ホストが存在するので、4*11で44個のコンポーネントが1クラスター上に展開されたようです。

10.6TB÷44=約240GBとなるので、これであれば単一コンポーネントの上限値である255GBにも収まっているのがわかります。

さて、次にストレージポリシーのストライプ数上限について再度ドキュメントで確認をしてみます。

説明の一行目に注目をしてみると・・・

f:id:instructor8010:20170325205504p:plain

仮想マシンオブジェクトの各レプリカがストライピングされるキャパシティディスクの最小数

と記載されています。つまりこの数字は単一のオブジェクトをコンポーネントに分割するときの最大値ではないということです。最低でも、この数に分割するというものです。

pubs.vmware.com

 

ということで、上記が質問に対する回答となりました。

もちろんですが、62TBほど大きくなくとも、例えば10GBのVMDKにストライプ数12のポリシーを適用すると、ハードディスクドライブ12本でRAID0を組み、そこに対し10GBのファイルが保存されるイメージとなります。スピンドルが増えると、IOPSが向上するためパフォーマンスが良くなりますが、1台のドライブの障害でデータがロストされてしまうので、この点は注意が必要です。

以上、皆様のvSANライフがより良いものになれば幸いです。

vSphereインターフェース上からのディスクの物理ロケーションIDを考える(1) パススルーモード編

本日もvSAN 6.2 Deploy & Manageのトレーニング提供でした。

そういえばvSAN 6.6 Deploy & Manageが新たにリリースされましたね。

mylearn.vmware.com

 

実はVCI(VMware認定トレーナー)はいち早く教科書がもらえますので早速もらっちゃいました。早く6.6を展開したいですね。

 

さて、ディスク交換についてですが、キャパシティディスク編を書いていましたが、1つ気になったことがありました。それが今回のお題です。

 

お題:vSphereインターフェース上から見る情報で、物理サーバーのディスクロケーションはわかるのか?

 

さて、弊社の場合はPowerEdgeサーバーなわけですが、次のようにサーバーは前面からホットプラグで物理ドライブ交換が出来る標準的なメンテナンス機能を持っているわけです。

f:id:instructor8010:20170621205758p:plain

ここで注目したいのはハードウェア交換のメンテナンスのために、物理ドライブの識別子が番号が振られているわけです。

 

これが今回のテーマとどう関係が有るかというと、"VMware vSAN環境の場合、障害が発生したドライブを交換する場合、vSphereのインターフェース上ではこの識別子が使えるのか?"と言うものです。

トレーニング中に質問があったわけじゃないのですが、私自身が前回の検証中に少しきになったわけです。

さて、そこで次の検証を行いました。(まずはこの検証のために資材の準備の手伝いをしてくれた、社内の先輩Mさん、ありがとうございました)

検証:PowerEdgeサーバーにESXiをインストールし、vSphereの管理インターフェースからディスク識別子を確認し、物理的なロケーションとの相関関係を見る。

上記検証であれば、最新式のサーバーでなくてもよかったので、Mさんの席近くにあったサーバーを拝借。私がトレーニング中にESXiのデプロイをして頂きました。

 

Mさん:RAIDコントローラーもパススルー設定かRAID-0モードかでカーネルが得る情報が違うと思うよ

というアドバイスがあり、パススルーモードで一旦確認しました。 

さて、これがデプロイが終わった後のESXiをvSphere Clientの”構成”タブ→”ストレージ”から見た図です。何本のディスクがあるでしょうか?またランタイム名で、それぞれの違いは何でしょうか?

f:id:instructor8010:20170622132258p:plain

 正解は、ディスクは8本でバックプレーン構成です。

コントローラーであるvmhbaが認識しているデバイスは全部で9つです。(ディスク8本、バックプレーン1つ)これは上図右側の”タイプ”からわかります。

さて、そして”ランタイム名”ですが、ここではターゲット番号が全デバイスで一意です。

実際の製品の前面にあるドライブロケーションの番号と一致していました。

ですので、vmhba0:C0:T0:L0であれば、前面の0の番号が割り振ってあるディスクでした。

これが本当に前面のID0のディスクかどうかを確かめるために、ID0のディスクを抜いてみました。

結果、次のようにID0のディスクは以下のようにステータスが変化しました。

f:id:instructor8010:20170622132746p:plain

これにより、ランタイム名のターゲット番号は前面の識別子と一致すると言える状況が生まれました。

ちなみに”ランタイム名”とは、vmvkernelが命名する識別子であり、”デバイスのパス情報を含む、SCSIバイスの識別子”です。

ですから、今回のvSAN時の障害点確認にはもってこいの識別子です。詳細はこちらをご確認ください。

kb.vmware.com

pubs.vmware.com

ですので、保守作業を行う観点で、遠隔管理者とデータセンター管理者とがいる環境の場合は、このランタイム名を駆使すれば正確なコミュニケーションができそうです。

 

なお、vSAN環境ではコントローラーの性質によっては”パススルーモード”ではなく”RAID-0モード”でないと行けない場合もあるので、これはこれで要検証です。

ということで、第2弾にてこの検証を行ってみましたので、気になる方はこちらをご覧ください。

 

instructor8010.hatenablog.jp

 

vSAN障害シナリオ:キャパシティディスク編(その1)

現在vSAN 6.2のコース提供を絶賛行っております。

基本的な障害に関する情報はコース内で紹介するものの、具体的な交換手順やその際の諸注意は資料以上の内容が知りたいという声も多いです。

基本的にStorage HUBの情報をベースに、HOL上での動作検証も踏まえ上記に対する考察を記載していこうと思います。

Disk Failures - Storagehub.vmware.com

続きを読む