*VMware Feed

2017/12/10

最近vCloud Directorってどうなってるの?

vCloud Director とは?

vCloud Directorは2010年にvSphereの上位に配置することで、サーバ仮想基盤をセルフサービス化してマルチテナント対応のIaaS基盤にすることができるソフトウェアとしてリリースされました。2014年のVer 5.6以降はサービスプロバイダー向け製品として、サービスプロバイダー契約したパートナーにのみ提供される製品となっています。

そんなvCloud Directorも着実に5.6,8.x,9.0とアップデートしています。ちょうど9月に最新版である9.0がリリースされました。9.0の新機能を中心に現在のvCloud Directorを利用するとどんなIaaS基盤を構成することができるのかを見ていきましょう。

VMware NSXとの高度な連携

従来vCloud DirectorはvCloud Network and Security(vCNS)と連携して、IaaSに必要なVPNゲートウェイやロードバランサ、NATファイアウォールの機能を提供してきました。後継としてVMware NSXの利用をサポートしてきましたが互換性の問題もあり、vCloud Network and Security相当としてVMware NSXを利用するというせっかくのVMware NSXの豊富な機能を最大限に利用することができていませんでした。

 ところが最近のバージョンではVMware NSXを最大限に利用することができるような機能拡張が多くされています。いくつかの代表的な機能をここでは紹介したいと思います。

Edge GatewayのNSX Edge フル機能サポート

vCloud Network and SecurityからVMware NSXに変わったことにより、一番機能が追加されるのがEdge Gatewayの機能追加になります。Edge Gatewayは従来どおり仮想マシンとしてゲートウェイを展開されますが、機能が大幅に強化されています。Vcd1

またロードバランサのようにvCNSでも使えていた機能の中で、大幅に強化された機能もあります。NSX Edgeのロードバランサではオープンソースで広く使われているHAProxy互換のアプリケーションルールによる柔軟な振り分けルールの記述ができるようになりました。これにより多くの既存の環境を使い勝手を損なうことなく移行いただくことができます。

Vcd5

分散ファイアウォールを使ったファイアウォール ポリシーのセルフサービス化

vCloud Director利用時にVMware NSXの採用で恩恵を受けるのは、Edge Gatewayだけではありません。VMware NSX=マイクロセグメンテーションというくらい代表的なVMware NSXの機能になっている分散ファイアウォールの機能とも連携することができます。AWSにおけるSecurity Groupのように利用することができます。

Vcd6

vCloud Directorのポータルから、セルフサービスで分散ファイアウォールにルールを追加することができます。分散ファイアウォールは仮想スイッチのレイヤで動作しているため、同一L2セグメント内の通信であってもアクセス制御することができるため様々な用途でご利用いただくことが可能です。

このように現在のバージョンのvCloud DirectorはVMware NSXの豊富な機能を利用することにより、従来以上に柔軟な環境をIaaS基盤として提供することができます。

UIの刷新と機能追加

FlashベースからHTML5ベースのポータルに刷新

Adobe社はFlashのサポートが2020年末で終了することを既に発表しています。それを受けてHTML5ベースに移行しようということで、vCloud Director9.0では最初のリリースとして、組織利用者の管理ポータルがHTML5版の利用ができるようになりました。組織利用者の管理ポータルはFlash版を引き続き利用することも可能ですし、サービス提供者側の管理ポータルは従来通りFlash版を利用します。

vRealize Operations Manager経由で仮想マシンの利用状況の把握が可能に

 vCloud DirectorやvRealize Automationなどのセルフサービスを実現する製品で必ずお客様から頂く質問として、「利用者はどうやって仮想マシンのリソース状況を確認するか?」がありました。従来のvSphereの仮想基盤では、vCenterやvRealize Operationsを利用して様々なメトリックを確認することができました。vCloud Directorもサービス事業者側はvSphereの仮想基盤から同様のことができましたが、利用者はvSphereにアクセスすることはできません。従来の物理サーバのように、監視ソフトウェアを利用してリソースを確認するといった対応を行う必要がありました。

 vCloud Director 9.0からは利用者側から仮想マシンのリソース状況を確認する方式が2つ提供されます

 

  • vCloud Director 9.0 + Cassandraで実現する方式
  • vRealize Operations Tenant App for vCloud Directorで実現する方式

 

1の方式はvRealize Operationsも不要でコンポーネントが少なくて済むのですが、Cassandraを準備いただくのにハードルが高いこともあり、今回は2のvRealize Operations Tenant App for vCloud Directorの紹介をしていきたいと思います。

 

vRealize Operations Tenant App for vCloud Directorとは?

vRealize Operations Tenant App for vCloud Directorは、vRealize OperationsのvCloud Director拡張である「vRealize Operations Management Pack for vCloud Director」に含まれるオプション製品となります。ドキュメントやバイナリの提供は以下のURLでされています。利用するにはvRealize Operations Advanced Edition以上が必要になるため注意が必要です。

https://marketplace.vmware.com/vsx/solutions/management-pack-for-vcloud-director

 

 vRealize Operations Tenant App for vCloud Directorは、vCloud DirectorとvRealize Operationsと連携してリソースの利用状況を確認することが可能なポータルを提供します。しかもvCloud Director 9.0を利用している場合、HTML5版のポータルと統合することが可能です。vCloud Director 9.0のポータルの中で、仮想マシンのリソース状況を確認することができます。

Vcd8

まとめ

今回はvCloud Director 9.0と最近のアップデートでのVMware NSXとのインテグレーションがどこまでされているのか、そしてvRealize Operations Tenant App for vCloud Directorを使ったvCloud Directorの拡張について紹介しました。ほかにもオンプレミスとの統合を実現する「vCloud Extender」、オンプレミスのDR先として利用することを可能にする「vCloud Availability for vCloud Director」を使ってDR as a Serviceを提供することも可能です。vCloud Directorを中心としたVMware社のソフトウェア群を使って、独自のサービス展開を考えているサービスプロバイダ様をネットワールドは支援させていただいております。

 

 

2017/12/05

名物vExpert アケミ姉さんのインフラ骨盤矯正ブログ vSAN編 #2

HPE教育サービスの中川明美です。

1回目はvSAN 6.6で提供された新機能や強化された機能をご紹介しました。2回目以降はトラブルシューティング時に役立つツールや機能についてです。

 

#1: VMware vSAN 6.6 What’s New

#2: トラブルトラブルシューティング時に役立つツール 1

#3: トラブルトラブルシューティング時に役立つツール 2

 

vSANの監視やトラブルシューティング時に使用するツールは大きく分けると次の3つがあります。状況に応じて使い分けられますね。

  • GUIツール (vSphere Web Client / vShere Host Client
  • コマンドラインツール (esxcli / Ruby vSphere Console)
  • VMware vRealize Operations Manager / VMware vRealize Log Insight

今回は、vSANクラスタのリバランスに役立つツールと、vSAN 6.6で追加された「esxcli」コマンドについてご紹介します。

 

vSANディスクバランス

VMware製品に関心のある方は、vSANがESXiホストのローカルディスクを利用して、データストアを構成していることをご存知かと思います。

このアーキテクチャを前提にすると、仮想マシンを構成するコンポーネント (仮想ディスクファイル等) がどのような配分でディスクに置かれるのかは気になるところだと思います。あるディスクの使用率が高いから、すぐにディスクを追加しましょうとはならないですよね。コンポーネントはすべてのディスクにバランスよく配置されるのが望まれるところです。

コンポーネントの配置によっては、パフォーマンスの低下やトラブルを引き起こすかもしれません。それらを回避するには、バランスの監視や状況によって手動でのリバランスが必要になるかもしれません。これから紹介するツールはディスクバランスの監視に役立ちます。vSANコンポーネントのリバランスは通常自動で行われます。

 

自動リバランス

デフォルトでは、キャパシティ層のデバイスの使用率が 80% に達すると、自動的にvSANクラスタはリバランスされます。リバランスは、vSANを構成するESXiホストがメンテナンス モード時にも行われます。

ディスク容量の使用率がクラスタ内でバランスが取れているかどうかは、「制限_現在のクラスタの状態」を確認します。ディスク容量使用率が80%を超えると自動でリバランスされます。

A010

「制限_1件の追加ホスト障害後」では、1台のホスト障害があった場合に、再保護用の容量に不足はない(使用率)のか、クラスタコンポーネント/ディスク容量/キャッシュ予約に影響する可能性がある(健全性)のかを確認することができます。「現在のクラスタの状態」では全ディスク容量が449GBですが、「1件の追加ホスト障害後」では299GBで分析されています。

A011

手動リバランス

一部のディスクの負荷分散がしきい値30%を超えると、警告が表示されます。しきい値は、「クラスタ_vSANディスクバランス」の最大分散で確認します。

たとえば、ディスク1の使用率が 50% で、ディスク2が15% の場合、ディスク1と2の負荷分散は35%です。この状況はしきい値の30を超えていますから警告が表示されます。

手動リバランスをするには、「ディスクのプロアクティブリバランス」をクリックします。

A012

ディスクの負荷分散がしきい値を超えると、「ディスクバランス」タブに詳細情報が表示されます。「ホスト名」「該当ホストのストレージデバイス名(例えばmpx:vmhba0:C0:T0:L0)」「リバランス状態(Proactive rebalance is needed)」「しきい値を下回るようにするために移動する必要のあるデータ量」を確認できます。下図は最適な状況のため、表示されていません。

ディスク容量使用率が80%近くになっているか、最大分散で警告が表示されていれば、手動リバランスを試みます。クラスタのリバランスでは大量のI/O操作が生成されるため、仮想マシンのパフォーマンスに影響を及ぼす可能性があることを考慮ください。「移動するデータ(量)」はリバランスをいつ実施するべきかの参考値になりますね!

A013

※vCenter Serverの健全性サービスを利用できない場合

vCenter Serverのサービスが停止している時には、vSphere Host Clientでも同様の情報を入手可能です。

A014

vSAN 6.6で追加されたesxcliコマンド

6.6から、次のコマンドが追加されています。

  • vSAN クラスタの健全性を表示: esxcli vsan health
  • vSAN デバッグ情報を表示: esxcli vsan debug

A015

< esxcli vsan health >

「vSANディスクバランス」はコマンドラインでも確認可能です。

A016

< esxcli vsan debug >

debugには次のオプションがあります。

A017

仮想マシンオブジェクトの情報を表示します。点線枠はコンポーネントのステータスです。どの物理ディスクに配置されているかを確認可能です。

A018

再同期されている仮想マシンオブジェクトのステータスを表示します。障害後のホスト再起動時/ホストのメンテナンスモード時/ディスク容量使用率のしきい値の超過時に再同期が開始されます。

A019

再同期が原因でクラスタに遅延が生じている場合や、再同期によるトラフィックがホスト上に大量に発生している場合には再調整を検討します。下図の赤点線枠の警告メッセージも考慮ください。

vSANクラスタを選択し、「監視」-「vSAN」-「コンポーネントの再同期」で「再同期の調整」をクリックします。再同期の調整の設定で、IOPS数を大きくするにはスライダを右に、IOPS数を小さくするには、スライダを左に移動します。

A020

GUIやCLIを使用して、vSANの様々な情報を入手可能ですね。状況に応じて選択いただければと思います。次回は、vRealize Operations ManagerとVMware vRealize Log Insightをご紹介します。

 

HPE教育サービスでは、vSANのVMware認定コースを提供開始します。トラブルに対応するにはアーキテクチャを知ることは重要です。ぜひこの機会に学んでみませんか。

次の開催日程は、1/29(月)-31(水)です。申し込みはお早めに!

VMware vSAN: Deploy and Manage [V6.6] 3日間コース

日本ヒューレット・パッカード株式会社 教育サービス 中川明美

記事担当者: マーケティング本部 三好哲生 (@miyo4i

Screenshot20141105at0820381

さて、第2弾です。今回はトラブルシューティング系ですね。トラブルには出くわしたくないものですが、もしもであってしまったときに・・・こうした情報がまとまっているのは良いですね。GUIからはもちろん、CLIからも様々な診断や操作が行なえます。次回もVMwareの別の有償ソフトウェアを利用したより運用の観点からの記事になるそうです。今回中川さんに記事を依頼したのは彼女の運用目線での記事がとても素敵だからです。どんな記事なのか、楽しみですね。

さて、第3弾は来週の公開です。

2017/11/28

名物vExpert アケミ姉さんのインフラ骨盤矯正ブログ vSAN編 #1

お声かけいただき、「ネットワールド らぼ」へ投稿することになりました。

自己紹介から始めます。HPE教育サービスの中川明美と申します。

HPE教育サービスでは、インストラクター兼コンサルタントを担当しています。ネットワールドさんとは数年前からのお付き合いです。書籍執筆のメンバーでもあります。2014年からvExpertの活動としてVMware製品のBlogを投稿しています。このたびVMwareとHPE製品に関わるBlogの依頼があり、お引き受けいたしました。

今回のテーマはVMware vSANです。導入事例も増え、注目度が高まりつつあります。HPE ProLiantやSynergyは「vSAN Ready Nodes」です。

アーキテクチャについては様々なサイトで紹介されていますから、こちらのBlogではトラブルシューティング時に使用するツールとTipsを取り上げます。

#1: VMware vSAN 6.6 What’s New

#2: トラブルトラブルシューティング時に役立つツール 1

#3: トラブルトラブルシューティング時に役立つツール 2

 

1回目は今回のテーマに関連するvSAN 6.6で提供された新機能や強化された機能をご紹介します。

 ホストベースのvSAN監視

vSANの管理および監視は、ESXiホストの管理ツールである、「vSphere Host Client」も使用可能です。基本の機能は、vSphere Web Clientと同様のメニューが提供されますから、vCenter Serverに接続できない場合にも引き続き操作可能です。A001

vSphere Host Clientの「健全性」は、シンプルな表示構成です。

「ストレージ」-「監視」-「健全性」タブを選択すると、コンポーネントの健全性を把握できます。

詳細な情報を知りたい場合は、各コンポーネントの右上のアイコン(クラスタなら下図の赤い枠)をクリックすると、追加情報が表示されます。A002_2

これ以降は、vSphere Web Clientで提供される機能です。

Configuration Assist

vSANクラスタの構成チェック機能「Configuration Assist」が追加されました。vSANに関わるコンポーネントの構成を検証し、問題や推奨 (ベストプラクティス) を提示します。

「ハードウェア互換性」や「ネットワーク構成」は、後に述べる「健全性」とほぼ同様の内容が表示されます。下図は、書き込みテストチェックを選択した画面です。問題に「書き込みテストが実行されていません」と表示されています。テストを実行してみます。A003_2 「監視」→「vSAN」→「プロアクティブテスト」とメニューを遷移し、該当のテスト項目を選択し、「今すぐテストを実行」をクリックします。リストにあるマルチキャストは、6.6では必要ありません。

A004_2

下図はテスト結果です。プロアクティブテストは導入後のエビデンスとして使えそうです。A005_2

健全性サービスの機能強化

<ハードウェア互換性>

ハードウェア互換性では、コントローラのファームウェアのチェックに加え、最新のOEMファームウェアやドライバのアップデートも可能です。

vSAN HCLは提案時にCompatibility Guideを確認するだけではなく、構築時には「健全性」のテスト結果から最適なファームウェアやドライバであるかの確認をお勧めします。

A006_2正しい健全性チェックのためには、vCenter Server内のvSAN HCL DBを最新にしてください。DBを最新にするには次の画面から行います。

A007_2

<オンライン健全性>

健全性に「オンライン健全性」が追加されました。

オンライン健全性は、新しいサポートの推奨事項やベストプラクティスを、リアルタイムに通知します。オンライン健全性を使用するには、カスタマエクスペリエンス改善プログラムに参加する必要があります。

A008_2

パフォーマンスサービスの機能強化

パフォーマンスサービスに、「ネットワーク」「再同期」「iSCSI」の統計が追加されました。

パフォーマンスサービスを使用するには、「設定」-「vSAN」-「健全性とパフォーマンス」で、パフォーマンスサービスを有効にします。

時間の範囲で、「時間の範囲の保存」を選択すると、指定した時間範囲 (下図なら現時点から過去1時間) のパフォーマンス情報を後から表示することも可能です。

A009_2

VMware vSAN 6.6ついては以上です。6.6.1では次の新機能および機能強化がなされています。VMware vSANはどんどん進化していますね。今後も楽しみです。

  • vSphere Update Manager によるvSANのビルドに関する推奨事項
  • パフォーマンス診断
  • Gen-9 HPEコントローラ (パススルーモード) のロケータLEDのサポート

 

HPE教育サービスでは、vSANのVMware認定コースを提供開始します。トラブルに対応するにはアーキテクチャを知ることは重要です。ぜひこの機会に学んでみませんか。

次の開催日程は、1/29(月)-31(水)です。申し込みはお早めに!

VMware vSAN: Deploy and Manage [V6.6] 3日間コース

日本ヒューレット・パッカード株式会社 教育サービス 中川明美

記事担当者: マーケティング本部 三好哲生 (@miyo4i

Screenshot20141105at0820381

今回はvSANのブログ記事です。HPEにおられるお友達の中川さん(アケミちゃん)にお願いしてかいてもらいました。Ready Nodes、VxRailなど、ハードウェア中心の訴求がなされる中で、ちゃんとvSANをソフトウェアとして理解することも重要だと思いまして、こんなブログを書いてもらいました。不定期連載ですが、インフラの骨盤をしっかり矯正して(笑)くれる内容になるはずです。

乞うご期待!

2017/09/06

HyperFlexのバックアップはVeeamにお任せ!2017

シスコ社のHCIであるHyperFlexのバックアップにはVeeam Backup & Replication(以下、VBR)で間違いないことは、前回お伝えしましたが、最新のVBR 9.5 Update 2では、更に進化し、HyperFlexのネイティブスナップショットとの連携が可能になりました!

VBRの特徴の1つであるストレージスナップショット連携は、これまでもDell EMC/NetApp/Nimble/HPE などのハードウェアストレージには対応しておりましたが、HCIのSDS(Software-Defined-Storage)としては、HyperFlexが初の対応です。

そんなHyperFlexですが、7月末にHyperFlexの最新バージョンである2.5がリリースされました。早速、HyperFlex 2.5(1b)とVBR 9.5 Update2の組み合わせでHyperFlexのネイティブスナップショットとの連携によるバックアップを試してみましたので、ちょっとご紹介しましょう。


まずは、HyperFlexの登録です。VBRの管理コンソールを起動し、[STORAGE INFRASTRUCTURE]で [Add Storage]をクリックします。 
Vbrhx01_3



「CISCO HYPERFLEX」をクリックします。
Vbrhx02_3



HyperFlexの管理用のIPアドレスを入力し、[Next]をクリックします。
Vbrhx03_3



HyperFlexの管理者ユーザー(admin)の認証情報を設定し、[Next]をクリックします。

Vbrhx04



そのまま[Next]をクリックします。

Vbrhx05



サマリーを確認して、[Next]をクリックします。HyperFlexのバージョン情報(2.5.1b-26284)も認識しています。
Vbrhx06



登録処理が実行され、登録が完了します。Vbrhx07_4



バックアップを実行してみたところ、HyperFlex スナップショットの作成と削除のメッセージが表示され、スナップショット連携のバックアップが成功しました。 

Vbrhx09

 

バックアップ中に仮想マシンのスナップショットを確認すると、「SENTINEL」というスナップショットが作成され、その下にVeeamによるテンポラリのスナップショットが作成されています。「SENTINEL」というスナップショットはHyperFlexのネイティブスナップショットを使う際に最初に作成されるスナップショットのため、VeeamからHyperFlexのスナップショットを呼び出していることが分かります。

Vbrhx10a_2


何故、HyperFlexのネイティブスナップショットと連携できると良いのか?HyperFlexとVBRを組み合わせるとどんなリットがあるのか?ピンと来ていない方は、下記のセミナーに参加いただけると、きっとお分かりいただけると思います。東京・名古屋・大阪・福岡で開催しますので、是非ご参加ください!

シスコの爆速堅牢なハイパーコンバージドインフラご紹介セミナー

https://networld.smartseminar.jp/public/seminar/view/814


このセミナーでは最新のHyperFlex 2.5の情報もお伝えします。HyperFlex 2.5では専用の管理ツールのHyperFlex Connectやレプリケーション機能など新機能が盛り沢山ですので、ご期待ください。これからHyperFlexを提案や導入しようとしている方は必見ですが、既にHyperFlexをご利用いただいている方のご参加もお待ちしております。

Vbrhx11_2



最後に、Ciscoと Veeamと言えば、アプライアンスの下記キャンペーンも好評につき、キャンペーン期間を延長しましたので、こちらも併せて宜しくお願い致します。http://www.networld.co.jp/campaign/cisco_veeam_backup/

 担当:臼井

2017/08/31

VMware Cloud on AWS 技術概要

本ブログエントリーはVMware社のR&DでSenior Staff Architectを務めているFrank Denneman氏のブログの翻訳版です。 Frank氏について、詳しくはこちらもご参照ください。

本記事の原文はVMware Cloud on AWS Technical Overviewで閲覧可能です。

ネットワールドのVMwareに関する情報はこちら

昨日我々はVMware Cloud on AWSサービスを立ち上げました。VMware Cloud on AWSはVMware vSphere上で動作するプライベート、パブリック、そしてハイブリッドクラウド環境上でのアプリケーションの稼働ををAWSサービスへの最適化されたアクセスと同時に実現します。このCloud SDDCはvSphere、NSXそしてvSANのテクノロジーによって構成され、みなさんが現状でお持ちのスキルセットで管理、運用できるため、非常に馴染み深いものとなります。AWSインフラストラクチャのベアメタルを活用し、このCloud SDDCはこれまでにない方法で拡張することができます。

VMware Cloud on AWSはサービスです。これはサービスに関して言及する際に製品のヴァージョンを利用しないということを意味します。その代わりに我々はこのサービスが最初に利用できるようになったものをファーストリリースと呼ぶことになります。その後の全てのリリースについてはフューチャーリリースと呼ぶことになります。VMware Cloud on AWSはVMwareによって運用されています。これは短く言うとVMwareがインフラストラクチャリソースに責任を負い、お客様はリソースの消費を担当するということです。この記事は最初に利用時のCloud SDDCのリソースキャパシティを探検するものとなります。

VMware Cloud on AWSのコンピューティング

最初の利用時、VMware Cloud on AWSの構成には4台のホストが含まれています。それぞれのホストは512GBのメモリと2つのCPUで構成されています。これらのCPUはカスタムビルドのIntel Xeon Processor E5-2686 v4 CPUです。それぞれのCPUは2.3GHzで動作する18のコアを内包しています。結果として物理クラスタのコア数は144となります。ハイパースレッディングが有効になっているため、仮想マシンは288のロジカルプロセッサを標準のCloud SDDCの構成として利用ができるようになっています。VMware Cloud on AWSは単一の固定のホスト構成で提供されており、ホスト構成へのコンポーネントの追加オプションは現時点では提供されていないことにご注意下さい。ですがスケールアウト型での拡張が最大で16ホストまで利用できるため、結果として576 CPUコア、8TBまでのメモリを利用することが可能です。

vSphere DRSとvSphere HAが有効になっており、最高の可用性とリソース利用効率を提供します。vSphere DRSは完全自動で、移行のしきい値は標準のvSphere DRSのレベルに設定されており、vSphere vMotion操作が過剰に行われないようになっています。クラスタリソースの高可用性がvSphere HAで提供されており、ハードウェアの自動復帰が行われます。

vSphereの高可用性はESXiホスト障害時の仮想マシンの再起動中にもリソースを保証するためにも利用されます。ESXiホストは監視されており、障害イベント時には障害ホスト上の仮想マシンが代替となるクラスタ内のESXiホストで再起動されます。オーバーヘッドを最小化しながら、生産性を最大化するため、クラスタのvSphere HAの設定は1台のESXiホスト分と等しく構成されています(%ベースのアドミッションコントロールポリシーで25%)。ホスト孤立時の対応は仮想マシンの電源を落とし、仮想マシンを再起動するにセットされています。

Vmcaws_fig1

ホスト障害の修復についてはVMwareが担当します。ホストの障害が恒久的なものであれば、VMwareはESXiホストの交換をユーザーを煩わせること無く行います。障害を起こしたハードウェアの自動的な交換は恒久的なホスト障害による長期間に渡るリソースの減少からの影響を削減します。Cloud SDDCは2つのDRSリソースプールで構成されています。一つ目のリソースプールはCloud SDDCを運用するための管理用の仮想マシンが置かれており、もう一つはお客様のワークロードを管理するためのリソースプールのトップレベルのプールです。お客様は子リソースプールを作成することができます。

Vmcrp720p

VMware Cloud on AWSのストレージ

SDDCクラスタはオールフラッシュのvSANを含んでおり、それぞれのホストは合計で仮想マシンが利用するための10TBの物理キャパシティを供給します。標準のCloud SDDCクラスタでは40TBの物理キャパシティを提供します。仮想マシンのキャパシティの消費は構成されているストレージポリシーに依存します。標準ではRAID-1障害許容の手法が適応されます。ですが、お客様はストレージプロファイルを作成し、よりオーバーヘッドの小さなRAID-5やRAID-6という障害許容手法を利用することもできます。RAID-6の障害許容手法を利用する際には最小でCloud SDDCクラスタ内に6ホストが必要となることにご注意下さい。

それぞれのESXiホストは8つのNVMeデバイスを保持しています。これらの8つのデバイスはvSANディスクグループをまたいで分散されています。単一のディスクグループ内では、1台のNVMeデバイスの1.7TBのストレージがWriteキャッシュ層として利用されます。ストレージキャパシティ層には他の3台のNVMeデバイスが利用され、合計すると5.1TBのストレージとなります。

Vmcaws_fig2

ストレージ暗号化

vSAN暗号化によるデータストアレベルの暗号化またはvSphereの仮想マシン暗号化による仮想マシンレベルの暗号化はVMware Cloud on AWSの最初のリリースでは利用できません。データセキュリティについては全てのストレージNVMeデバイスがAWSによってファームウェアレベルで暗号化されています。この暗号キーはAWSによって管理されており、公開されることも、VMwareやVMware Cloud on AWSのお客様が制御することもありません。

Cloud SDDCの構成

最初のリリースではCloud SDDCはAWSの単一のリージョンと可用性ゾーン(AZ)に限定されています。ハードウェア障害は自動的に検出され、自動修復によって、障害ホストは他のESXiホストへと入れ替えられます。もしも必要な場合にはvSANデータストアがユーザーを煩わせること無く自動的にリビルドを行います。

将来のVMware Cloud on AWSのリリースではVMwareとAWSのパートナーシップを通じてマルチ-AZでの可用性が2つの同一リージョン内の2つのAZをまたいでクラスタをストレッチすることで初めて実現される可能性があります。このまたとない機能によって、従来からのアプリケーションをAWSインフラストラクチャ上で高可用性を得るためにリファクタリングする必要はなくなります。その代わり、同期WriteレプリケーションがAZをまたいで活用されることになり、復元目標点(RPO - recovery point object)はゼロとなり、復元目標時間(RTO - recovery time object)はvSphere HAの再起動時間次第となります。

Spanningaz

VMware Cloud on AWSのネットワーク

VMware Cloud on AWSはNSXを中心として構成されています。このネットワークはCloud SDDC内の仮想マシンのネットワークの提供に最適化されている一方で、Amazon 仮想プライベートクラウド(VPC)ネットワークを抽象化しています。仮想マシンへの論理ネットワークの提供とクラスタスケールアウト時の新しいホストと論理ネットワークVMKernelネットワークとの自動的な接続によって簡単な管理を実現します。最初のリリースではユーザーはVMware Cloud on AWSにレイヤ3のVPN接続で接続します。しかし、将来のリリースのVMware Cloud on AWSではAWSのダイレクト接続とクロスクラウドのvSphere vMotion操作ができるようになります。

オンプレミスのvCenterサーバインスタンスとCloud SDDC内のクラスタ上で動作している管理コンポーネントとの接続にはIPsecのレイヤ3VPNがセットアップされます。またもう一つのIPsec レイヤ3 VPNが作成され、オンプレミスのワークロードとCloud SDDCのクラスタ内で動作している仮想マシンとの接続に利用されます。NSXは全てのネットワークとセキュリティに於いて利用され、Amazon VPCのネットワークから分離されています。コンピュートゲートウェイとDLRは暗黙的なネットワークトポロジの一部として事前に構成されており、お客様が変更することはできません。お客様はご自身のサブネットとIPの範囲を提供するだけです。

Vmcaws_fig4

VMware Cloud on AWSは皆様のワークロードに対応

VMware Cloud on AWSは皆様の現在のスキルセットとツールセットを使いながら利用できるクラウドのリソースを提供します。それぞれのCloud SDDCは今日最も要件の高いアプリケーションを動作できるだけの十分なリソースをご提供します。世界最高のエンタープライズソフトウェアが世界最高のクラウド事業者と融合し、これまでにない方法でデータセンタを稼働、拡張することを実現するのです。

更に詳しくは こちらへ https://cloud.vmware.com/vmc-aws/resources

記事担当者: マーケティング本部 三好哲生 (@miyo4i

Screenshot20141105at0820381

業界はVMworldで盛り上がっていますね。ちょっと時間がうまく取れなかったのでもっとタイムリーに翻訳記事を公開したかったのですが、少し遅れてのリリースです。これまではあまり語られてこなかった、VMware Cloud on AWSを契約するとどうしたリソースが利用できるのか?今回はこれが明らかになりました。すごいスペック・・・。2TB、288スレッドのクラスタ・・・以上に私がびっくりしたのはNVMeを8本も搭載し、うち2本=3.4TBもをWriteキャッシュに振り当てるという豪華っぷり!

NSXでAmazon VPCのネットワークをきれいに隠してしまうのもVMwareユーザーにはうれしいですね。マルチAZでのストレッチにもチャレンジしていくとのこと、ワクワクします。日本に来るのが待ち遠しいですね!

追記 : お値段は?という方がおられましたので、こちらです。米国の価格なのでそのまま日本に来るとは限りませんが、ご参考まで。 https://cloud.vmware.com/vmc-aws/pricing

2017/08/02

敢えて言おう、VeeamはvSANに対応していると!

VMwareのSoftware-Defined StorageであるVMware vSANは、vSphere 5.5 Update1でリリースされて以降、vSphereのバージョンアップに合わせて、何度かバージョンアップが行われています。最近ではvSphere 6.5dのリリースに合わせて、vSAN 6.6がリリースされました。

そんなvSANですが、vSphere6.5対応やvSAN対応を謳っていても、現在はvSAN 6.5以降には完全に対応できていないバックアップソフトが多い状況ではありますが、Veeam Backup & Replication(以下、VBR)は、前回ご紹介したVBR 9.5 Update1で既にvSAN 6.5に対応しており、更に、5月にリリースされたVBR 9.5 Update2でvSAN 6.6にも対応しているのです!

Release Notes for Veeam Backup & Replication 9.5 Update 2

 Platform support
   -VMware vSAN 6.6 support.

そこで、今回は実際に検証環境でVBR 9.5 Update2を使用してvSAN6.6上の仮想マシンのバックアップ・リストアを試してみました。


■検証構成

論理的には下記のような構成になっており、4ノードvSANで仮想マシンとして構成したVeamサーバがvSAN上の仮想マシンをData Domainにバックアップします。

 Config1_3

実際にはESXiはNestされた仮想マシンになっており、Data DomainもVirtual Edition(仮想アプライアンス)のため、全て仮想環境上で動作しています。vSpheer Web Clientで見ると下のような感じです。ESXiのビルドが5310538 になっていることから、ESXiが6.5.0dであること分かります。vSANは全てSSDでオールフラッシュ構成(エミュレーションですが…)で重複排除・データ圧縮が有効になっています。

Vsan1_3

■バックアップ

まずは、バックアップですが、バックアップ対象の仮想マシンの選択では、データストアでvSANのデータストアである[vsanDatastore]がきちんと見えています。

Vsan3_2

下の図がバックアップを実行した結果は下の図になりますが、「hotadd」と表示されていますので、仮想マシンのVeeamサーバがHotaddモードでのバックアップに成功しています。Nest環境のため、スループットが良くない点はご容赦ください。
 

Vsan4_2

■リストア

次にリストアをしてみましょう。リストアのウィザードではvSANデータストアの中に仮想マシンに別途、割り当てている仮想マシンストレージポリシー(Test-VM-Policy)が表示され、ストレージポリシーの情報含めてバックアップしていることが分かります。

Vsan5_2

リストアも問題なく成功しました。「hotadd」を表示され、リストアでもHotaddモードでvSANデータストアにリストアできていることが分かります。

Vsan6_2

リストアされた仮想マシンの仮想マシンの設定を確認してみると、割り当てていた仮想マシンストレージポリシー(Test-VM-Policy)も戻っていました。

Vsan7

仮想マシンストレージポリシーが戻るのは当たり前と思う方もいるかもしれませんが、vSAN対応を謳っているバックアップソフトでもStorage Policy-Based Management (SPBM) には対応できておらず、リストアすると、デフォルトの仮想マシンストレージポリシー(Virtual SAN Default Storage Policy)が割り当てられ、リストア後に手動で仮想マシンストレージポリシーの再割り当てが必要なものが多いのです。

vSAN環境では仮想マシンストレージポリシーで仮想マシンの冗長化を定義するため、バックアップソフトがSPBMに対応しているかどうかは重要です。また、他のバックアップソフトの場合、バックアップベンダーが独自にvSAN環境でテストを行い、vSAN対応を謳っていることがほとんどですが、VBRは独自にテストをしているだけでなく、VMware社のvSAN認定も取得し、VMware社のKBにも掲載されているほどです!

※vSAN データストアを使用した Veeam のバックアップと複製 (2150856) http://kb.vmware.com/kb/2150856


vSphere 6.5でvSANを利用するとなると、今後はvSAN6.6が前提になってきますが、VBRであれば、vSAN環境やvSANベースのハイパーコンバージドインフラ製品でも安心してバックアップできます。vSANの導入を検討している方や既にvSANを導入済みでvSAN 6.6へのバージョンアップを予定している方で、VBRを検証してみたいという方は、是非、評価版でお試しください!

■参考

Veeam Backup & Replication 評価版ダウンロード

VMware vSphere向け簡易手順書(日本語版評価ガイド)

Configuration for VMare VSAN

 担当 臼井

2017/07/31

VMware Cloud on AWS ー 想定通りのキャパシティの展開

本ブログエントリーは以前はPernixData社のテクノロジーエバンジェリストとして勤務し、現在はVMware社のR&DでSenior Staff Architectを務めているFrank Denneman氏のブログの翻訳版です。 Frank氏について、詳しくはこちらもご参照ください。

本記事の原文はVMware Cloud on AWS – Predictable Capacity Provisioningで閲覧可能です。

ネットワールドのVMwareに関する情報はこちら

VMworldのセッション LHC2971BU - Managing your Hybrid Cloud with VMware Cloud on AWS(VMware Cloud on AWSでハイブリッドクラウドを管理する)、私はこのセッションをEmad Younis氏と一緒に喋りますが、その旬日をしている際に、以下のような質問をTwitterで投げかけました:

訳: サーバーハードウェアを購入してそれをvSphereクラスタとして運用するまでの平均のリードタイムは今日現在どれ位ですか?

その結果、返信の数は圧倒的なものでした。今回のお話はそれほどでもありません。プロセス内の一つ一つのすべてのステップを自動化しようと我々が奮闘するのは面白いものです。Alan氏、Luc氏そしてWilliam氏のようにESXiホストのインストールや構成するスクリプトをつくるコミュニティを支援する人もいます。一貫性のある、人的ミスのない、迅速なプロセスです。時間のかかるサーバー展開のプロセスから貴重な時間を削り出すことができます。幾つかの会社はvRealizeスイートと連携し、ITサービスのポートフォリオ全体に一貫性のあるユーザーエクスペリエンスを作り上げています。また面白いことに、リードタイムの全体において、最も影響力のあるのが内部的な購入のプロセスです。2つの例を上げましょう :

訳 : 45~60日、最大で90日。10~30日が購入申請、30日が納期、1週間がケーブリングと検証とクラスターへの追加です。

訳 : はは! だったら、わからないよ。購入の承認は完全に予測不能。

訳 : 殆どの待ち時間は見積もり/購入/納期です。実際のセットアップは数分から、数時間。

訳 : 購入が承認されても納期に3週間です。時々クラスタへの追加と稼働まで3週間でいけることもあるけど。

そして、リストはどんどん伸びていきました。殆どの組織においては準備段階が非常に厳格で、よく定義されている手順のようでした。ですが、購入プロセスにおけるリードタイムは想定通りでも、一貫したものでもありませんでした。全てのメッセージがIT組織の俊敏性が縛られているというものでした。

IT組織はビジネスの要求に応じて迅速に反応できなくてはなりません。現状のワークロードのリソース管理ですらむす香椎のです、今後数ヶ月で挑戦しなくてはいけないことを考えてみてください。残念なことに新しいワークロードを追加するということは要求のカーブが線形になるということではありえません。(起こりうる)将来のお客さまのニーズに対応するため、その規模は2倍にもなるかもしれません、それができなければ新しいワークロードの追加はできないことになります。こうなると会社自身の基盤に影響を与えかねませんし、さらにITサービスを適切に運営する能力にも影響を与えかねません。

訳 : いつもの感じだと30~45日程度。管理プロセスに必要となる項目などで「次の」待ち時間を減らすために規模はほぼ倍になっています。

基本的に、サーバーリソースの購入についてのCAPEX(購入コスト)要素は大きくIT組織の実行力に影響もしくは妨げとなります。CAPEX/OPEX(運用コスト)についての戦略は多くの管理者やアーキテクトのフォーカスエリアからは外れています。これ自身は彼ら自身の意味での実行力を低下させるものではありません。多くののツイートがそれを証明してくれたとおり、VMware Cloud on AWSはホストのリソース調達のプロセスをCAPEXからOPEXへシフトさせ、より高速で、一貫性のある、そして想定通りの方法でコンピューティング、ストレージ、ネットワークリソースを提供してくれるのです。AWSの運用モデルを活用し、AWSインフラストラクチャで動作しているSDDCクラスタはボタンをクリックするだけでリサイズすることが可能です。クラスタを右クリックして、リサイズを選択して下さい。

Vmcresizecluster

追加したいホスト数を選択すれば、すぐさま新しい専属の物理ハードウェアがクラスタに追加されます。もう新しいワークロードに必要なリソースが追加されているのです。リサイズは同様にリソースを縮小することができるということも意味しています。もちろん、コストも下がることになります。

AWSとVMCの管理が統合されているため、新しいESXiホストは完全に新しいワークロードを迎え入れられる状態になっています。すべてのVMKernelネットワークと論理ネットワークは自動的に構成され利用できるようになります。vSANデータストアもホストが保持しているNVMeフラシュデバイスをローカルに保持しているホストで自動的に拡張されます。DRSが新しい物理リソースを検出し、自動的にクラスタのリバランスを実施するため、最も最適化されたリソースが利用できるようになります。

Erastic DRSとHAによる自動回復によって、専属のハードウェアリソースの追加と削除は完全に自動化されることになります。ですが、この話については別の記事でご紹介することにしましょう。

リソース管理の観点からは、心構えが完全に異なるものになります。VMCはインフラストラクチャ構成と管理にかける時間を減らし、リソースの消費によりフォーカスを当てられるようになります。今後数ヶ月でクラスタの構成に何が必要でしょうか? バースト時の戦略は?

残念ながら、サービスがまだリリースされていない現在、詳細をお話することはできません。VMworldではVMware Cloud on AWS関連セッションにびっくりするほどのラインアップを取り揃えています。  私自身も2つのVMworld両方でリソース管理についてのmeet the expertを実施します。この素晴らしいテクノロジーについてもっと話をしたいという方はぜひサインアップして下さい。

記事担当者: マーケティング本部 三好哲生 (@miyo4i

Screenshot20141105at0820381久しぶりにFrank氏がVMCの記事を更新しましたので、翻訳しました。クラスタにリソースを追加するまでに、何ヶ月かかる?そんな問いかけからスタートします。どの会社も購買プロセスが最も時間のかかるプロセスなのですね。

VMC on AWSも、いよいよ準備が整ってきて、VMworld前後には提供開始されるのでしょうか?ホストごとのリソーつ追加ですので、完全にオンプレミスのvSphereの管理の延長上で管理が行えます。

問題は・・・OPEXになるとは言え、リソースの追加の権限をどこまで持てるのか、というところですね。ITは電気屋、水道のようになれるのか・・・? まだまだIT屋がしなくてはならないことはたくさんあるように思います。

2017/05/03

vSphere Data Protection(VDP)6.1.4 

初期セットアップTips

vSphere Data Protection(VDP)6.1.4について初期セットアップ時のTipsを2つお知らせします。

1.vSphere Web ClientにVDPプラグインが表示されない場合の対処方法 

-----------

①https://<VDP_IP>:8543/vdp-plugin-package.zip にアクセスしてプラグインをダウンロードします。

②vCenter アプライアンスの下記の階層に
/var/lib/vmware/vsphere-client/vc-packages/vsphere-client-serenity/
vdp-plugin-package.zipをコピーします。

③vdp-plugin-package.zip をunzip すると ファイルとディレクトリに解凍されます。

vxvcenter:/var/lib/vmware/vsphere-client/vc-packages # ls
vsphere-client-serenity
vxvcenter:/var/lib/vmware/vsphere-client/vc-packages # cd vsphere-client-serenity/
vxvcenter:/var/lib/vmware/vsphere-client/vc-packages/vsphere-client-serenity # ls
vdp-plugin-package.zip
vxvcenter:/var/lib/vmware/vsphere-client/vc-packages/vsphere-client-serenity # unzip vdp-plugin-package.zip
Archive: vdp-plugin-package.zip
creating: plugins/
inflating: plugin-package.xml
inflating: plugins/service-plugin-6.1.4.jar
inflating: plugins/vdr-ui-war-6.1.4.war

④サービスを再起動します。(vSphere Web Clientの接続が5分程度中断します。)

# service-control --stop vsphere-client
# service-control --start vsphere-client

2.テストメールは問題ないのに<スケジュールしたステータスメールが送信されない場合の対処方法 

VDPのログは下記にあります。

/usr/local/avamar/var/vdr/server_logs/vdr-server.log

今回ご紹介する対処方法はログに次のメッセージが記録されている場合に有効です。
2017-04-15 20:00:00,186 ERROR [VDP-email-report-timer-task]-schedule.EmailReportTimerTask:
Failed to send the email summary report.
Reason: java.rmi.RemoteException: VI SDK invoke exception:com.vmware.vim25.ManagedObjectNotFound; nested exception is:


①vi でファイル /usr/local/avamar/lib/mcsutils.pmを編集します。 

以下の行を追加します。
. "-Dsecurity.provider.rsa.JsafeJCE.position=last "

追加する行は決まっていて、
. "-Dfile.encoding=UTF-8 "と
. "-Dlog4j.configuration=file://$mcsvar::lib_dir/log4j.properties "; # vmware/axis 行の間に追加します。


②VDPアプライアンスをリブートします。

                             担当:磯前

2017/02/28

空前絶後のォ!超絶怒涛のvSphere6.5対応バックアップ!!(Veeam B&R 9.5 Update1)

昨年11月にリリースされたvSphere 6.5ですが、VMwareを愛し、VMwareに愛された(?)バックアップソフトであり、インスタントVMリカバリやストレージスナップショット連携、全てのエージェントレスバックアップの産みの親とも言える(?)、Veeam Backup & Replication 9.5 (以下、VBR 9.5) が1月にリリースされたUpdate1で早くも対応しました!


◆Release Notes for Veeam Backup & Replication 9.5 Update 1
https://www.veeam.com/kb2222


「vSphere 6.5に対応しているバックアップソフトなら、既に他にあるよ」と思った方もいるかもしれませんが、そういったバックアップソフトはエージェントレスで仮想マシンバックアップするためのAPI(VMware vSphere Storage APIs – Data Protection)のSDKであるVirtual Disk Development Kit(以下、VDDK)が古いバージョン(6.06.0.2)を利用していることが多く、vSphre 6.5をサポートはしているものの、vSphere 6.5の新機能には対応できていません。


※VDDK 6.0.2リリースノート抜粋
https://www.vmware.com/support/developer/vddk/vddk-602-releasenotes.html
The VMware policy concerning backward and forward compatibility is for VDDK to support N-2 and N+1 releases. In other words, VDDK 6.0 and all of its update releases support vSphere 5.1, 5.5, and 6.5 (except new features).


VBR 9.5 Update 1ではVDDK6.5を利用していますので、vSphere 6.5に完全対応しています。そこで、今回はVBR 9.5 Update 1でのvSphere 6.5対応の一部をご紹介しましょう。


■新しいファイルシステムののサポート

vSphere 6.5の新しいVMFSのバージョン6では512eのサポートや領域の自動再利用などの機能追加が行われていますが、VBR 9.5 Update1ではVMFS6にも完全対応しています。他のバックアップソフトではVMFS6の場合、FC SANやiSCSI SANのようなSAN経由でバックアップするSANモードでのバックアップができないことが多いのですが、VBR 9.5 Update1ではVMSF6であってもSANモードでバックアップすることが可能です。

  

Vmfs6_4

                

VMFS5からVMFS6にはインプレースアップグレードができないため、vSphere 6.5を導入する場合には、最初からVMFS6にしておきたいところですが、VBR 9.5 Update 1ならVMFS6で構成しても安心です。最初はVMFS5で構成し、後でVMFS6にしたいという場合でもVMFS5の環境の仮想マシンをVBR9.5 Update 1でバックアップし、VMFS6にフォーマットし直した環境に対してリストアすることもできてしまいます。

また、VMFS6だけでなく、VSAN 6.5にも対応しています。vSphere環境やVSANを利用しているハイパーコンバージドインフラ製品は、今後、vSphere 6.5ベース(=VSAN 6.5)になっていきますが、VBR9.5 Update 1ならVSAN 6.5になっても心配ありません。



■仮想ハードウェアバージョン13のサポート

vSphere 6.5では新しい仮想ハードウェアバージョンの13が提供され、仮想NVMeコントローラやuEFIセキュアブート、VMFS6での自動領域再利用などの新機能を利用する場合には仮想ハードウェアバージョン13が必須となっています。

Vmhw13_4

  

VBR 9.5 Update1は、この仮想ハードウェアバージョン13にも完全対応していますが、VDDK 6.5を使っていないバックアップソフトでは、仮想ハードウェアバージョン13に完全に対応していないため、事前に仮想ハードウェアバージョン13に対応していることを確認しましょう。

■暗号化されたVMのサポート

vSphere 6.5ではハイパーバイザーにビルトインされた仮想マシンの暗号化機能が提供されていますが、VBR 9.5 Update 1では暗号化された仮想マシンのバックアップにも対応しています。

Efi_4

ただし、vSphere側の制限により、SANモードのバックアップは不可で、NBD(要SSL)モードかHotadd(要プロキシVM自体の暗号化)モードのみとなりますので、気を付けましょう。

Vmenc

 

NBDモード利用時の圧縮

vSphrere 6.5ではバックアップでも新機能が実装されています。ネットワーク経由でバックアップデータを転送するNBD(Network Block Device)モードでは、これまではバックアップデータがそのままESXiホストからプロキシサーバに送られてきましたが、VDDK 6.5ではNBDトラフィックの圧縮を有効にする機能が追加されています。

Nbdcomp_4


VBR 9.5 Update 1はNBD圧縮機能に対応していますので、NBDモードでバックアップしている環境では、vSphere 6.5&VBR 9.5 Update1にするだけで、バックアップのパフォーマンが向上するかもしれません。


今回はVBR 9.5 Update1でのvSphere 6.5対応を中心にご紹介しましたが、VBR 9.5自体も前バージョンから多くの新機能や機能拡張が行われていますので、下記のWebinarや資料をチェックして、空前絶後の超絶怒涛のバックアップを感じてください!

https://www.veeam.com/jp/videos/availability-suite-9-5-now-generally-available-9130.html

https://www.veeam.com/pdf/new/veeam_backup_9_5_whats_new_jp.pdf

担当:臼井

2016/12/28

NetBackupで仮想マシンの瞬間リカバリ!

はじめまして、宮内と申します。
普段は主にバックアップ製品を担当しています。以後お見知りおきを!

初めてのブログでご紹介するのはVeritas NetBackup
もともと高性能で有名なバックアップソフトウェアですが、最近はアプライアンスの新バージョン登場、ソフトウェア でも12月に新バージョン登場、と注目度が更にうなぎのぼり!(と思います)
こちらのブログでも、重複排除とアクセラレータ、 クラウド連携( API編クラウドゲートウェイ編 )、 SelfService など、過去に何度かホットな機能の紹介をさせていただいていますね。
一方で、便利なのに認知度の低い機能もちらほら。。
そこで!私からは、ちょっとニッチな便利機能を紹介したいと思います。

前置きが長くなりましたが、今回はインスタントリカバリ機能をご紹介します!

インスタントリカバリ(略称IR)とは:
バックアップデータを直接ESXiにマウントして仮想マシンを即座に起動させる機能

こんなイメージです↓

1

バックアップデータをESXiのデータストアに移動させることなく仮想マシンファイルを読み出すので、普通のリカバリよりも迅速に復旧できます。

IRは、以前のバージョンから搭載はされていたのですが、コマンドでしか操作できず、(GUIしか使えない初心者の私にとっては)ハードルの高いものでした。
NetBackup 7.7からはvSphere Web ClientからGUI操作でできるようになり使いやすくなったので、胸を張って紹介できます!

インスタントリカバリが使えるようになるまでの道のりはこちら↓

2 もうちょっと設定手順が簡単だといいんですが。。贅沢は言わない。

Webサーバーは既存のものがあればプラグインのインストールのためだけに作成しなくても大丈夫です。

それではインスタントリカバリをしていきましょう!
せっかくなのでNetBackupのプラグインは最新バージョンの 8.0 を入れてみました!!
※スクリーンショットには開発段階のものを含みます。


vSphere Web Client からのIRの流れはこちら↓

3

プラグインを入れた状態でvSphere Web Clientを起動します↓

4 赤いマークが目印です。

5つ並んだボタンの中から「Instant Recovery Wizard」を選んでリカバリ開始↓

5 あ、もちろんですが、リカバリの前に仮想マシンのバックアップはしておいてくださいね!

リカバリしたい仮想マシンを選びます↓

6 右下の"Add Virtual Machines"をクリックします。
左上に現在選んでいる仮想マシンの台数が表示されます。

リカバリするデータとか場所とか名前とか設定します↓

7

8

9

リカバリ前にはチェックが必要です↓

10 チェックが済んだらインスタントリカバリ実行!

すぐに起動してきました!↓

11 今回はIRしたマシンに「○○-irv」と名前をつけています。

12 こちらはNetBackupの管理画面。
今回は2分弱で2台の仮想マシンが起動したことが確認できます。

1台目は約30秒でリカバリできました。ちなみに、同じ仮想マシンを通常のリストアで復旧させたら、1台で約26分かかりました。
IRによって、リカバリ時間が1台あたり約25分の1まで短縮できましたね!
※本検証環境における参考値です。短縮できる時間は環境によって異なることがあります。

なお、NFSがうまく動作していないとリカバリに失敗することがあります。
リカバリ失敗時にNetBackupサーバーではステータスコード「5」が、Web-Clientのタスクでは「無効なデバイスです」といったメッセージがそれぞれ表示されていたら、NFSの不調を疑いましょう。
そんなときはバックアップサーバーで以下のコマンドを実行し、NFSの再起動を行ってみてください。

さて、IRは一時的にバックアップデータをマウントしており、起動した仮想マシンも一時的に使用することを前提としています。
そのため、このままではNetBackupのジョブが終了にならないので、必ずIRの終了処理が必要になります。

13 緑の走っている人のアイコンはジョブが実行中であることを示しています。

IRの終了処理には以下の2つがあります。

  • 仮想マシンを使い続ける:Initiate Instant Recovery Done
  • 仮想マシンを削除する:Deactive

"Initiate~"はvMotionで仮想マシンファイルをESXiのデータストアに移動させていないと選択できないので注意です。

終了処理はInstant Recovery Cleanupボタンから↓

14

ポップアップウィンドウの上部から仮想マシンへの処理を選択します↓

15 今回はvMotionを実行していないため、2台とも"Deactive"処理を行います。

16 リストに仮想マシンが表示されなくなったら全ての仮想マシンに対して処理が完了したサインです。

NetBackupの管理画面でも全てのアイコンが青色(ジョブ終了のマーク)になりました↓

17


以上でインスタントリカバリの操作は一通り終了です。いかがでしたか?

最後に、流れの中で紹介しきれなかったものも含め、インスタントリカバリのメリット・デメリットを書いて終わりにしようと思います。

メリット

  • とにかく仮想マシンの起動が早い
  • 一度に複数台の仮想マシンをリカバリできる(通常のリカバリは1台ずつ)
  • VM管理者(バックアップ管理者以外)がvSphere Web Clientからリストアできる

デメリット

  • インスタントリカバリが使えるようになるまでの設定が面倒
  • 復旧時の設定は通常のリカバリに比べて指定できる項目が少ない

ありがとうございました!皆様良いお年を!

宮内