VMwareな日々

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

VMware vSANまとめ(2017/07/18更新)

【2017/07/18更新】追加情報を掲載致しました。(追加記事2つ)

【2017/07/07更新】追加情報を掲載致しました。(追加記事3つ)

【2017/07/06更新】追加情報を掲載致しました。(追加記事3つ)

【2017/06/30更新】追加情報を掲載致しました。リンク切れなどがありましたので、修正致しました。

 

<vSAN ドキュメント>

<Ruby vSphere Console>

RVCの基本操作(起動、ログイン、コマンド操作)

vsan.support_information まとめ

<検証レポート>

 

vSphere 6.5の新機能(vCenter Server Applianceのネイティブバックアップ機能)

さて今週から、vSphere 6.5 Install, Configure, Manageをはじめました。

今まで6.0の提供だけでしたので、色々と変更点も多く楽しくトレーニング初日を迎えました。

 

さて、本題です。今回は受講生からの質問ではなく想定問答対策です。

お題:vCenter Serverのバックアップが6.5では、ネイティブな機能で提供されるようになったが、これによって取得されるデータの範囲はどこまでか?

 

バックアップ、IT管理者の永遠の課題ですね。

特にバックアップアプリケーションはサードパーティーでの販売もあれば、ご本家からのネイティブな機能の提供などもある場合、どれを使えばいいか、など管理者の方の悩みは尽きません。

 

今回は、トレーニングコースには、"vCenter Server 6.5のネイティブバックアップ機能"の紹介が含まれるため、その性質について紹介をしたいと思います。

 

まずこの機能はアプライアンス版vCenter Server限定です。

つまり、Windows版のvCenter Serverには無い機能です。

 

次に、この機能で取得出来るバックアップですが、バックアップ対象は”vCenter Server”と"Platform Service Controller(以降PSC)"です。

vCenter Server 6.0以降は、vCenter Serverのアーキテクチャとして、PSCが登場しました。ライセンスの管理やVMwareディレクトリなどを保存、管理してくれるサービスの集合体です。

 

これらの2つのデプロイモデルは、2パターンです。

  • 単一のVMに、vCenter ServerとPSCを組み込むパターン
  • それぞれを別々のVMに分けてデプロイする(2つのVMが登場する)

もし、単一のVMに対し2つの機能をデプロイする場合、1回のバックアップでOKです。

もし2つのVMに対しこれらの機能をデプロイする場合、それぞれで1回ずつバックアップを取得する必要があります。

 

今回紹介するバックアップ機能は、次のURLからアクセスしたページ上で行います。

(赤=単体VMへのデプロイ時のURL、青=別々にデプロイした際のそれぞれのURL)

f:id:instructor8010:20170725072944p:plain

こちらの画面が、上記URLでアクセスをした際のログイン画面です。

f:id:instructor8010:20170725072432p:plain

ログイン時には、vCenter Server Appliance及びPSCのローカルユーザー認証情報を入力します。(Administrator@vsphere.localではありません)

 

ログインを終えると、次のような画面が表示されます。後は赤枠で囲ったバックアップボタンから、バックアップを行います。

f:id:instructor8010:20170725073319p:plain

この画面はvCenter Server ApplianceもPSCも共通です。どちらにログインをしているかを確認したい場合は、以下の箇所で判別が可能です。

f:id:instructor8010:20170725073605p:plain

左がvCenter Server Applianceであり、右がPSCであることが確認出来ます。

 

最後に本バックアップを行う上での考慮事項です。

以降マニュアル"vSphereのインストールとセットアップ ESXi 6.5"から抜粋です。

 

バックアップによって保護されるデータは次の通りです。

f:id:instructor8010:20170725073914p:plain

本手順以外にバックアップ取得が必要なものはあるか?

幾つかの項目は、個別にバックアップが必要となります。

例えば分散スイッチはそのうちの1つです。

f:id:instructor8010:20170725074342p:plain

vSANやVirtual Volumesでお馴染みのストレージポリシーも個別にバックアップが必要と言えます。

f:id:instructor8010:20170725074532p:plain

 

以上のように、本機能はあくまでもvCenter ServerとPSCのための機能と言えますので、ユーザーの構成や環境によっては、この機能以外での追加バックアップも検討をする必要があります。

 

最後にこの機能のコンセプトですが、やはりVMwareネイティブという所がポイントです。サードパーティのバックアップアプリケーションなどもありますが、トラブル時に問い合わせ先が増えるのは管理者としては負担が増える一方です。

またサードパーティアプリケーションの場合は、別途ライセンス購買費用などがかかるケースもあります。

 

コストエフェクティブ、シンプル、このキーワードがぴったりな機能だと言えます。

vSANでの障害処理(vSphere HAとの連携とコンポーネント総数50%未満でのVMの動作状況について)

vSANトレーニング5週連続終えました。来週からはvSphere 6.5 Install Configure Manageです。

そして、VMware NSXとHorizonも要望が高まってきていますので、そのうち主要製品はコンプリートしそうです。

 

さて、前回のvSANトレーニングで、vSAN環境に於ける"HA(High Availability)"の動作について質問があったので、動作検証を持って正確な情報を得たいと思います。

 

質問:vSAN上のVMがFTT=1のRAID1ポリシーで保護されている場合、3つのコンポーネントが分断された場合は、オブジェクトは利用不可とはなるが、VMは再起動されるのかされないのか

 

ということで毎度お馴染みのHOLで環境を構成します。

まず4ノードvSANクラスターを構成します。Test-VMは現在"esx-03a.corp.local"上で起動しています。

f:id:instructor8010:20170723094142p:plain

続いてコンポーネントの配置を見てみましょう。

VMDKオブジェクトはホスト番号02, 03, 04号機上に保存されていることがわかります。

f:id:instructor8010:20170723094434p:plain

■シナリオ1:4ノードクラスターで、1ノードが停止するケース

まず一旦、4ノードクラスター内の1台をシャットダウンし、vSANクラスターを3ノードまで減らします。せっかくですので、Test-VMが動作している"esxi03a.corp.local"をシャットダウンしてみます。

 

 

ホスト”esx-03a.corp.local”をシャットダウンし、VMも接続性を失いました。

f:id:instructor8010:20170723094905p:plain

ホストがHAによりリスタート完了しました。

f:id:instructor8010:20170723095805p:plain

Test-VMは、4号機上でリスタートされたようです。

f:id:instructor8010:20170723095959p:plain

コンポーネントのステータスはAbsentですね。

(ホスト障害やネットワーク疎通不可はデフォルトで60分のタイマー切れ後に再同期動作が始まる)

f:id:instructor8010:20170723100252p:plain

■シナリオ2:オブジェクトに対する一部のコンポーネントが欠損した状態で、更に障害を発生させる。

さて、いよいよ本題です。現在のコンポーネント配置は次の状態です。

f:id:instructor8010:20170723102950p:plain

今度はホスト2号機をダウンさせます。1号機でも良いのですが、せっかくなら、VMDKの完全なミラーをもつコンポーネントは残しておきます。

理論上、オブジェクトは3つ中2つがアクセス不可となるため、オブジェクトは動作が出来ない状態になると言えます。

VMDKオブジェクトが残っていればI/Oは出来る環境は残るので、ひょっとしてVMは継続して動くのでは?と、興味を持たれる方もいるかもしれませんので、1号機を残します。

シャットダウン後がこちらです。

f:id:instructor8010:20170723103822p:plain

vSphere Web Clientの更新もしっかり行いましたが、VMは起動状態のままです。

HOLは残念ながらクライアントOSのデプロイが出来ないので、IOを発生させるなどの検証は出来ませんでした。

入念なチェックのため、vSphere Clientからも確認しましたが、やはり起動状態ではあるようですね。

f:id:instructor8010:20170723104023p:plain

データストアブラウザからも、各構成ファイルを確認することが出来ないようです。

f:id:instructor8010:20170723104506p:plain

ちなみに今回は、Test-VMは04ホストで動作をしていましたので、HAによるリスタートは起きませんでした。(後々、そこまで想定してvMotionしとけばよかったと思いました)

せっかくなんで、手動でTest-VMを再起動してみます。HAでは無いですが、HAによるリスタートと同じ結果が得られると言えます。

 

再起動、ポチッとな。

f:id:instructor8010:20170723104812p:plain

1~2秒後に、こんな感じでした。そりゃそうですよね。

f:id:instructor8010:20170723104854p:plain

その後、VMのステータスはパワーオフ状態となり、以降起動は失敗します。

f:id:instructor8010:20170723105018p:plain

以上です。

 

結論:いくらVMDKのレプリカコンポーネントがアクセス可能であっても、オブジェクトは50%以上のコンポーネント保有していない場合、VMは正常に動作は出来ない。

なお、VMは継続稼働状態にはあったものの、ディスクIOなどを受けた場合は、OSやアプリケーション側のタイムアウトなどにより、エラーが発生し停止することが予想される。

また、HAによるリスタート命令を受けるVMは、リスタートが失敗する。

データストアブラウザで見た場合、ファイルが消失しているように見える。

 

付録:vSANでの障害ステータスについて

以下の図のように、ご覧を頂くとたった1台のホスト障害で、2つのエラーが発生しているように見えます。

f:id:instructor8010:20170723101010p:plain

また、別の画面ではVMは障害の影響を受けておらず、正常であるかのようにも見えます。

f:id:instructor8010:20170723101725p:plain

管理者の方からすると、複数の障害が発生している、と見えてしまうかもしれませんが、そうではありません。

vSANでは、次の3つの視点からVMを評価しているといえます。

  1. ポリシーで既定したデータ配置がなされているか否か
    vSphere Web Client上の”コンプライアンスステータス”
    ポリシーで定義した数のコンポーネントが全て存在する場合は”準拠”と表示
    コンポーネントが1つでもアクセス不能になると”非準拠”と表示

  2. オブジェクトが動作出来ているか
    vSphere Web Client上の"動作状態"
    オブジェクトが動作出来る間(50%以上のコンポーネント保有)は”健全”と表示
    オブジェクトが動作出来ない間(50%未満のコンポーネント保有)は”非健全”と表示

  3. コンポーネント単体のステータス
    vSphere Web Client上の”コンポーネントの状態”
    コンポーネントを保持するデバイスの種別によって”低下しました”または”不完全”と表示される。

これらを纏めると、単一の障害で、これら3つのステータスは連動して変化すると言えます。

vSphere 6.5 の変更点(vSphere Client HTML5編)

vSANのRVCコマンドも一旦落ち着きまして、また来週からは、vSphere 6.5 Install Configure Manageの提供を行います。

今年は8月から9月にかけては、APJチームへのトレーニング提供も行う予定です。

 

さて、自分の予習も兼ねて、"vSphere 6.5って何が変わったの?"という点をまとめてみます。

まずは何と言ってもインターフェースのアップデートが一番わかり易い変更点と言えるのでは無いでしょうか:)

 

管理インターフェースは、やはり毎日の管理業務を行う上では大変重要ですね。

 

さて、6.5絡みでよく聞かれる質問で多いものがあるのですが、それは・・・

”vSphere Clientって無くなったんですよね?”

 

この質問に対する正しい回答、次のURLに含まれています。

kb.vmware.co

 

簡単に言えば、”vSphere ClientはC#版と呼ばれる、Windowsインストール版から、HTML5版に変更されました”

 

この変更によるメリットは次の通りです。

  • 管理端末がWindowsのみであったのに対し、対応ブラウザがインストールされていればOK
  • Adobe Flash Playerのようなプラグインが不要
  • vSphere Clientは、ホストのESXiの世代に応じて複数のバージョンを用意する必要があったが、管理機能がホストに組み込まれたため、その必要がなくなった

以下の画面はHTML5版のvSphere Clientログイン画面です。

f:id:instructor8010:20170719072012p:plain

ここではESXiホストのログイン情報を入力し、ログインします。

 

続いてログイン後の画面です。

フレームデザインとしては左側にツリー、右側がメイン画面なのは変わりませんね。

f:id:instructor8010:20170719072440p:plain

 

インターフェースと言えば、言語表示も重要です。

今までは、URLを編集することで切り替えを行っていたことを考えれば、言語切替も簡単に行うことが出来るようになりました。

f:id:instructor8010:20170719073032p:plain

ちなみにvSphere Web Clientの表示言語変更手順を知らなかったという方はこちらをご覧ください。

kb.vmware.com

 

まずはホスト関連の情報から見ていきましょう

管理:ハードウェアのパススルー設定やライセンス、インストール済みのVIB、サービスやポート開放などの設定に関する情報がこちらに集約されています。

f:id:instructor8010:20170720071144p:plain

 

監視:パフォーマンス統計(1時間分のみ)、ハードウェアセンサー、イベントなど現状の問題やトラブル対処などの考察に使う情報が閲覧出来ます。

f:id:instructor8010:20170720071316p:plain

仮想マシン仮想マシンの作成、起動、停止、スナップショット取得など、基本操作が可能です。

f:id:instructor8010:20170720065511p:plain

また、”コンソール”に関して言えば、2種類のコンソールが用意されています。

(ブラウザコンソールとVMRC)

f:id:instructor8010:20170720065618p:plain

ブラウザコンソールは、HTML5を利用したコンソールです。vSphere Clietn上の画面に展開されます。別タブや別ウィンドウでも開くことも可能です。

f:id:instructor8010:20170720070322p:plain

VMware Remote Consoleも利用可能です。

f:id:instructor8010:20170720070652p:plain

 

ストレージ:データストアのマウント状況や、ホストバスアダプターなどの情報が閲覧と設定変更可能です

f:id:instructor8010:20170719073219p:plain

ネットワーク:ポートグループや仮想スイッチなどの情報が閲覧と設定変更可能です

f:id:instructor8010:20170719073310p:plain

 

 以上です。ちなみに現時点では、このHTML版のvSphere Clientでは出来ない操作も幾つかあり、そのことも合わせてナレッジに記載があります。

<以下ナレッジより抜粋>

f:id:instructor8010:20170720072611p:plain

完全な機能を提供されるまでは、複数のインターフェースを使うケースも出てくるかもしれません。皆様のフィードバックを、HTML版vSphere Clientのフィードバックツールから伝えることで、少しでも速くフル機能を実装して頂けるかもしれませんね:)

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

さて、いよいよvsan.support_infoコマンドのサマライズ最終編です。

少々時間はかかりましたが、第1弾からお読み頂いた皆様、本当にありがとうございます。

 

ブログ開始は3月くらいからでしたが、中国出張などもありつつ、ブログの閲覧数も1000を超え、平日では約50アクセスくらいがコンスタントになってきつつあります。

 

今後も有用な情報をお届けしていきたいと思います。

では、早速本題に参りたいと思います。

 

今回のコマンドは"vsan.disk_object_info"です。

ディスク内に存在する、オブジェクトに関連するコンポーネントの情報を表示するコマンドです。

 

毎度お馴染みのHOLから今回もコマンド出力を拝借致します。

今回もオブジェクトとコンポーネント絡みですので、先んじてVMを作成し、コンポーネントの配置を確認します。

f:id:instructor8010:20170717143919p:plain

RAID1ポリシーのFTT=1ですので、単一のオブジェクトは3つのコンポーネントで保護されます。

今回は、ホスト01(esx-01a.corp.local)に接続された、ディスクID mpx.vmhba2:C0:T1:L0を、このコマンドで閲覧してみたいと思います。

 

それがこちら。

f:id:instructor8010:20170717144336p:plain

1本のディスクに、2つのオブジェクトのコンポーネントが保存されていることが分かります。こちらのコマンドでは、指定したディスク内に保存されているコンポーネントのオブジェクト情報が表示されます。

赤枠が"Test-VM"のネームスペースディレクトリオブジェクトです

緑枠が"Test-VM"のvmdkオブジェクトです

 

後は、よくよく見てみると、ポリシーとコンポーネントの各配置と現在のステータス情報が表示されています。

 

ちなみにコマンドを発行するに辺り、上図では、一旦hostsディレクトリまで移動し、ホスト番号を指定し、その後ろにNAA IDまたはランタイム名を入れることで、ディスクを指定しました。

f:id:instructor8010:20170717145142p:plain

上記のように、lsで文頭のインデックス番号1が、esx-01a.corp.localの番号であると確認出来たため、コマンドも次のように、"1"が入っており、"1"のホストの”vmhba2”の”チャネル0”の”ターゲットID 1”の”LUN番号0”の情報を表示をするように指示をしています。

f:id:instructor8010:20170717145303p:plain

 

以上です。

 

結論:本コマンドは、ディスク単位でのコンポーネントの状況を把握するのに利用をします。ユースケースとしては、特定のディスクの障害や正常性確認などを行いたい際に活躍が出来るのではないでしょうか。

 

PowerEdge 14GとVMware (その1)

皆様、数日ぶりです。

3連休の最終日ということもあり、前2日は横浜界隈をウロウロしておりました。

 

さて、世間は3連休と猛暑日と、そろそろ夏休みムードが迫っているわけですが、弊社の場合は、新世代のPowerEdgeサーバーが登場したわけです。

cloud.watch.impress.co.jp

 

ベゼルデザインが、旧EMCライクで私は個人的には好きです。もう少しブルーなテイストが入ってくれればなお良かったかなとも思いますが、ある意味旧デルらしさということでグレーなテイストが残ったのかなと。

 

さて、世代の変更に際し、見た目だけではなく、VMwareに関連する点も、少しUpdateがあったので、何点かピックアップをしてみたいと思います。

 

まずは1点目です。それがこちら。

DellEMC factory install changes for VMware ESXi

 

工場初期出荷時点でプリインストールされるvSphere ESXiのパスワードですが、13世代まではパスワード無しでの設定でしたが、第14世代からはデフォルトで、”サービスタグ”がパスワードとして設定されているようです。

 

サービスタグは、Dell製品をご愛顧頂いている方からすればおなじみのあれですね。

製品単位で付帯される一意の識別子であり、保守や初期出荷構成、オーダー情報を含むものですね。

 

他にも第14世代関連では、”Boot Optimized Storage Solution(通称BOSS)”と呼ばれる新しいデバイスも登場し、ハイパーバイザー関連の製品となっておりますので、また次号でこちらは取り扱いたいと思います。

 

皆様も3連休、体調を壊さず過ごしてください~!

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

いつも帰宅後にHOLを起動し、動作テストを行うのですが、夏場になり、夏バテでしょうか。昨日はすぐに休んでしまい、今朝の更新となりました。

 

ということでおまたせしました、1日ぶりの更新です。

さて、今回は"vsan.obj_status_report"というコマンドです。

オブジェクトのステータスを表示する、と解釈出来る内容ですね。

それではコマンドの出力結果を複数用意しましたので、それぞれ確認して行きましょう。

 

VMが一つも存在しない状態

f:id:instructor8010:20170713064849p:plain

オブジェクトもコンポーネントも0ですので一覧には何も表示されません。

VMがいなければ、オブジェクトが存在しないのは至極当然と言えますね。

では、VMを1個作成してみましょう。

 

VMが1つvSANクラスター上に存在し、正常な状態

f:id:instructor8010:20170713065025p:plain

1台のVMを"vSAN Default Storage Policy(RAID1, FTT=1)"で保護しています。

ですので、ホームスペースとvmdkの2つのオブジェクトが存在しており、それぞれは3つのコンポーネントで保護されています。

これらの情報が上の表で示されています(3個中3個のコンポーネントが全て利用出来るオブジェクトが、2つ存在する、という意味合いですね)

 

VMホームスペースオブジェクトはホスト01、02、04にて保護されていますね。

f:id:instructor8010:20170713065641p:plain

 

VMDKオブジェクトはホスト02、03、04にて保護されていますね。

f:id:instructor8010:20170713065855p:plain

ここでホストをメンテナンスモードにして障害を起こします。

本環境は4ホストのvSANクラスターなので、1台をメンテナンスモード状態にします。

今回はホスト01号機(esx-01a.corp.local)で実施をしてみます。

予測される動作としては、VMホームスペースオブジェクトはこの01号機によりコンポーネントが保護されているので、このオブジェクトが影響を受けると考えられます。

 

結果はこちらです。

f:id:instructor8010:20170713070350p:plain

予想通りですが、2/3(Reduced)と書かれた行が登場しました。オブジェクトを保護するコンポーネントが1つ不在になってしまっており、残り2つであるという状態です。

 

vSphere Web Clientからも、以下のように状態が変化をしています。

f:id:instructor8010:20170713070459p:plain

 

以上です。

なお、コマンド内では2つの表が表示されていましたが、下の表は孤立状態のVMについての同様のけっかを表示します。

結論:このコマンドでは、vSANクラスター上で保護されているオブジェクトとコンポーネントの状態を表示するコマンドである

障害発生時の問題発生範囲を、オブジェクトとコンポーネントの視点で把握が出来る