VMwareな日々

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

vSphere Data Protectionの基本と今後について

<著者からのお願い>

本記事の改訂版として以下のリンク内に更新記事を掲載しております。最新の情報をご確認頂くため、こちらのリンクをご覧ください。

lab8010.com

なお、はてなブログ上の本記事については今後更新は行いませんので、ブックマークなどをされている読者様は、恐れ入りますが新ブログを改めてブックマーク頂くようお願い致します。

 

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であることが確認出来ます。

 

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

この点については、最新の情報が欲しいという方は、VMwareよりリリースをされている”vSphere のインストールとセットアップ”という名称のユーザーズガイドを参照ください。

ブログにて内容を纏めても良いのですが、今後の製品アップデートなどで考慮事項が変化する場合、記事が最新でない可能性を回避するためです。

例えば、"vSphere 6.5 Update1"のガイドの場合は、以下のように制限事項が283ページに有ることが分かります。

vSphere 6.5 Update 1 vSphereのインストールとセットアップ PDF版

(リンクが切れておりましたら、お手数ですが検索エンジンにて検索頂けますと幸いです)

f:id:instructor8010:20171213125537p:plain

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

f:id:instructor8010:20170725073914p:plain

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

例えば、vCenter Serverで管理している”分散スイッチ”は、上記バックアップには含まれますが、バックアップ取得後に変更を行った場合は、その変更差分を分散スイッチ側のエクスポート機能で取得をするように、と紹介がなされています。

f:id:instructor8010:20171213130017p:plain

vSphere 6.5 Update1 vSphereのインストールとセットアップPDF版 P284より抜粋

本手順については、以下のKBを参照ください。

vSphere Web Client を使用した Distributed Switch 構成のエクスポート/インポート/リストア (2096643)

以上のように、本機能はあくまでも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に含まれています。

https://kb.vmware.com/s/article/2147929?lang=ja

簡単に言えば、”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

 

以上です。

 

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

 

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クラスター上で保護されているオブジェクトとコンポーネントの状態を表示するコマンドである

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

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

もう間もなく、このRVCのvsan.support_infoシリーズも終わりを迎えます。

回を重ねるごとに、新しい発見もあるので、なかなか楽しくブログを書くことが出来ました。

 

さて、今回のコマンドは"vsan.resync_dashboard"ですが、vSAN 5.5ユーザーの方はお世話にならざるを得なかったコマンドだと言えます。

そして、vSAN 6.0以降はこのコマンドに相当する機能が、vSphere Web Clientに登場しました。

 

 

このコマンドでは、コンポーネントの再同期の様子、進捗をモニタリングすることが出来ます。

従来のRAIDで言えば、リビルドの進捗を見る、ストレージ管理ツール、とでも言えます。

 

さて、まずコマンド出力の様子を確認してみましょう。

f:id:instructor8010:20170708131427p:plain

非常に見た目はシンプルですね。項目としては次の2つが閲覧出来るようです。

  • 同期中のオブジェクト数
  • 残る同期のデータ量

続いてGUIでの同じ画面を見てみましょう。

f:id:instructor8010:20170708132051p:plain

このような画面です。項目としては次の内容が確認可能です。

  • 同期中のオブジェクト数
  • 残る同期のデータ量
  • 同期の完了目安時間

これらの図では、同期が走っていませんでしたので、強制的に再同期が走るケースを作り出したいと思います。

 

■シナリオ

VMを1台作成し、RAID1, FTT=1で保護する。コンポーネントを保護するホストをメンテナンスモードにし、同期を誘発させる。

 

★補足★

vSANではホストレベルの障害は、即時障害扱いとはなりません。障害の種類が2タイプあり、”不完全(Absent)”と呼ばれる症状として認定され、デフォルトでは60分間の障害検知タイマーがタイムアウトしてから、再同期動作が走ります。

 

ですので、まずこの値を変更しておきます。デフォルト値の60が入っています。

f:id:instructor8010:20170708140243p:plain

ここを1に変更すれば、メンテナンスモード投入後、1分で再同期が走ると言えます。

f:id:instructor8010:20170708140359p:plain

f:id:instructor8010:20170708140428p:plain

この後CLOMDサービスを再起動します。詳細はこちらをご確認ください。

kb.vmware.com

 

準備が整いました。

f:id:instructor8010:20170708143337p:plain

現在"Test-VM"のコンポーネントは1号機、3号機、4号機によって保護されています。

今回は3号機をメンテナンスモードに設定します。メンテナンスモード設定後1分以内はコンポーネントはAbsentとなると予想されます。

 

まず想定通りの動作です。コンポーネントアクセスができなくなり、Absent表示に変化

これに呼応し、ポリシー準拠ステータスもNoncompliantに変化します。

f:id:instructor8010:20170708143510p:plain

 

1分後、再同期が開始されました。

Absentのステータスはそのまま残り、新たに再同期のコンポーネントが登場しました。

f:id:instructor8010:20170708143607p:plain

この後、GUICLIでの同期ステータスチェックを行います。

※残念ながら、仮想環境上でデプロイが出来るVMDKサイズが小さく、一瞬で同期が終わってしまいました。

※何度も何度もメンテナンスモード投入などを行ったので、以下2枚の図では同期対象のホストが異なりますが、上記の理由によるものです。

 

まずGUIでの同期ステータス状況です。開いた瞬間残り時間0秒でしたので、ギリギリアクセスが出来たような状態です。

f:id:instructor8010:20170708143946p:plain

 

次にCLIでの同期ステータス状況です。コマンドを実行したタイミングの情報を取ってくる動きのため、リアルタイムな画面更新はありません。

何度かコマンドを連続で実行していたのですが、一瞬だけ同期の様子を確認することが出来ました。

f:id:instructor8010:20170708145042p:plain

 

以上です。

 

結論:コンポーネントの同期は、GUI/CLIいずれでも確認は可能である。

参照出来る情報には差があり、いずれもリアルタイムでの情報更新はありません。

(なお、検証動作環境はVMware Hands on LAB HOL-1708 vSAN 6.2 from A to Zより)