Home > Blogs > Japan Cloud Infrastructure Blog > タグ別アーカイブ: vSphere 5.5

タグ別アーカイブ: vSphere 5.5

vSphere 5.5 の新機能紹介 vSphere Data Proteciton Advanced(VDPA)

今回は、vSphere のバージョン5.1 より導入されているバックアップとリカバリソリューションvSphere Data Protection Advanced(VDPA) に焦点を当て、先日発表されましたバージョン5.5 で追加された新機能・特徴の概要をご紹介します。

VDPA は、先日ご紹介させていただいたおりますVDP を機能拡張させたバックアップソリューションになります。VDP は、vSphere Essential Plus および上位エディションにバンドルされておりますが、VDPA はバックアップ対象の仮想マシンをホストしているCPU 単位のライセンス購入が必要となります。
ライセンスの追加や割り当ては、”構成”タブより実施します。

図1. ライセンスの登録と割り当て
VDP とVDPA の機能比較は、以下のようになります。

(1) 平均的な仮想マシンサイズおよび日次更新率をもとに60 日間保持として算出
(2) アプライアンスあたりのサポートされる保護対象仮想マシン数の上限数は、VDP 100 VMs, VDP Advanced 400 VMs

図2. VDP とVDP Advanced の比較
バージョン5.5 で追加されたVDPA の主な新機能は以下となります。(VDP と共通される新機能はこちらをご参照ください)

1. バックアップ データ レプリケーション
2. Microsoft SharePoint 対応エージェント
3. EMC Data Domain システムへのバックアップ
4. 自動バックアップ検証機能

それぞれの機能について見ていきましょう。

1. バックアップ データ レプリケーション
VDP 5.5 では、レプリケーション機能が新たに追加されましたが、送信先としてEMC Avamar のみをサポートしております。VDPA 5.5では、EMC Avamarだけではなく、VDPAも送信先として利用いただけるようになります。

VDPA へのレプリケーションジョブは、”レプリケーション”タブで作成します。レプリケーションジョブは、バックアップジョブに含まれるクライアント(仮想マシン)すべてもしくは、個々に選択することが可能です。

図3. レプリケーションジョブの作成ウィザード
レプリケーションが完了すると、送信先に設定しているVDPA の”リストア”タブにクライアント名が表示され、レプリケーション先でクライアントのリストアが可能になります。

図4. 送信先のVDPA での”リストア”タブ
2. Microsoft SharePoint 対応エージェント

VDPA 5.5 では、5.1 で提供していたExchange やSQL エージェントに加え、SharePoint のエージェントも追加されました。
各アプリケーションのエージェントは、”構成”タブよりダウンロードが可能になっており、アプリケーションを実行する仮想マシンにインストールします。

図5. 各アプリケーションエージェントのダウンロードリンク
各アプリケーションエージェントをインストールする際、VDPA の仮想アプライアンスのホスト名を入力して、アプリケーションのバックアップを取得できるようにします。
アプリケーションのバックアップジョブは、イメージバックアップ同様に”バックアップ”タブから、”新しいバックアップジョブの作成”ウィザードを利用します。

図6. “新しいバックアップジョブの作成”ウィザード
3. EMC Data Domain システムへのバックアップ

VDPA 5.5 では、バックアップデータを仮想ディスクファイル(vmdk) だけではなく、EMC Data Domain システムへ保存することが可能になりました。Data Domain と連携させることで、VDPA にさらなるスケールとパフォーマンスを提供します。
VDPA からData Domain へのバックアップデータの転送効率を最大化するためにDD Boost を利用することが可能です。また、バックアップデータは、Data Domain アプライアンス内でグローバルに重複排除されるため、VDPA が複数あるような環境では、非常に有効です。

 

図7. Data Domain とVDPA の連携
Data Domain をバックアップデバイスとして追加するには、VDPA のWeb コンソールの”ストレージ”タブから実施します。VDPA のWeb コンソールにアクセスするためには、ブラウザより次のURL にアクセスします。
https://<VDPA のIP アドレス もしくは ホスト名>:8543/vdp-configure/

図8. VDPA のWeb コンソール
Data Domain を追加すると、バックアップジョブ作成時に保存先として、Data Domain Storage を選択できるようになります。

図9. バックアップジョブ作成時の保存先の選択
4. 自動バックアップ検証機能

取得されたバックアップデータが有効なものか、本当にリストアが必要になる前に確認しておくことは、RPO やRTO の観点で非常に重要になります。
VDPA 5.5 では、取得されたバックアップデータが有効かを、自動的に検証する機能を提供しております。

デフォルトでは、ゲストOS とのハートビートが検証のために使用され、オプションでゲストOS 上に配置されたスクリプトを実行させることが可能です。
この機能を利用するためには、仮想マシンに最新バージョンのVMware Tools がインストールされていることが必要になります。

バックアップ検証ジョブは、”リストア”タブの”バックアップ検証”より作成します。

図10. バックアップ検証ジョブの作成ウィザード
自動バックアップ検証では、以下のような一連の動作が自動で実行されます。
1. テンポラリの検証用仮想マシンが作成され、バックアップデータがリストアされます。
2. リストアされた仮想マシンが起動されます。起動前に仮想マシンのNIC は無効化されています。
3. OS 起動後、VMware Tools とのハートビートが検証されます。
4. オプションでスクリプトの実行が検証されます。
5. テンポラリで作成された検証用仮想マシンの電源がOFF され、削除されます。

自動バックアップ検証の結果は、vCenter の”タスク”や”イベント”、VDP プラグインの ”レポート”タブ、Email レポートなどで確認可能です。

図11. “レポート”タブでのバックアップ検証結果の確認
まとめ
VDP Advanced は、VDP からのアップグレードが可能であり、お客様の環境に応じた導入が可能になっております。中規模程度のvSphere 環境に理想的なバックアップおよび、リカバリソリューションを提供します。

vSphere 5.5 の新機能紹介 VMware Virtual SAN その2

前回その1でVirtual SANの概要と構築方法についてご説明しました。今回はその続編として、ポリシーベースのストレージ管理とそのポリシーを利用したVirtual SANデータストア上への仮想マシンの作成についてご説明します。

※このポリシーベースのストレージ管理は、Virtual SANに限った物ではなく、今後提供されるストレージの機能で実装することを予定しています。

ストレージポリシー

ストレージポリシーとは、VMwareがSoftware-Defined Storageで定義している重要な仕組みの一つで、ストレージの可用性、パフォーマンス等のSLAをストレージの機能と連携しながらポリシーで管理していく仕組みを提供するものです。ポリシーベースのストレージ管理には大きく3つの領域があります。

1. ストレージが有する機能及び通知する領域
ストレージが機能として包含しその機能を外部に対して公開する領域です。

2.ポリシーテンプレートを扱う領域
上記したストレージプロバイダに基づきポリシーのテンプレートを作成する領域です。

3.テンプレートを仮想マシンに適応する領域
作成されたテンプレートを仮想マシンに適応する領域です。適応されたテンプレートはストレージ側で理解され、仮想ディスクがポリシー(SLA)に従って配置されることになります。

それぞれの領域を順を追ってご説明します。

1. ストレージが有する機能及び通知する領域
この領域には実装方法が大きく2つあります。

ストレージ自身が機能として実装
ストレージが実装している機能を自身で外部公開するもの。上記例では、ストレージが有する可用性99.99%、パフォーマンス100K IOPSを外部に公開している部分となります。外部公開には、ストレージプロバイダ* という仕組みを利用します。Virtual SANもこの機能に対応しています。

ユーザにより手動で定義される物
上記がサポートされていないストレージの場合、ユーザー側でタグという形で定義することが可能です。例えばSSDで構成されたデータストア(群)をPlatinum、SATAで構成されたデータストア(群)をBronzeとしてタグ付けすることが可能です。ストレージプロファイルに比べると限定的な定義しか出来ず、どちらかというとデータストアをTire化+グルーピングして管理という利用法になります。

Virtual SANでは、ストレージプロバイダを利用することにより以下の5種類の定義を行うことが可能です。

・許容される障害数(デフォルト:1 最大:3)
1つのストレージオブジェクトについて許容されるホスト、ネットワーク、およびディスク障害の数を定義します。指定した値+1 個の仮想ディスクが作成されます。

・ストライプ数 (デフォルト:1 最大:12)
単一のVMDKをストライピングして書き込むHDDの数を定義します。

・領域の予約 (デフォルト:0% 最大:100%)
Virtual SANでは仮想ディスクは Thin Provisioningでデプロイされます。領域を確保したい場合は、ここで値を指定します。設定した値(割合)が vmdk に対し Virtual SAN内で予約されます。
(例)50%設定の場合、10GBのVMDKファイル作成の際に5GB分が予約されます。

・フラッシュ読み取りキャッシュの予約 (デフォルト:0% 最大:100%)
読み取りキャッシュ用に予約したい場合に指定します。

・強制的なプロビジョニング (デフォルト:無効)
「はい」を指定すると、Virtual SANデータストアが仮想マシン作成ポリシーの要件を満たさない場合でもプロビジョニングされます。

※設定を変更する場合は、機能と影響範囲を良く理解した上で実施する必要があります。例えばストライプ数は、アプリケーション要件がSSD1台のパフォーマンスを超えない場合、デフォルトの1(ストライプ無し)に設定することをお勧めします。ストライピングによる無用なVirtual SANネットワークへの負荷発生を押さえるためです。

※ストレージプロバイダに関して
ストレージの機能をvCenter Server側から利用するためには、ストレージプロバイダをvCentere Serverへ登録する必要があります。この登録作業は通常手動で行う必要がありますが、Virtual SANの場合はVirtual SANの有効化と共にストレージプロバイダが自動登録され利用可能となります。このため、Virtual SANでは、ストレージプロバイダを手動で登録する必要はありません。

自動的に登録されたVirtual SAN用ストレージプロバイダ

2.ポリシーテンプレートを扱う領域
Virtual SANだけではありませんがポリシーテンプレートを作成するには、以下のように行います。まず、ホーム画面より仮想マシンストレージポリシーアイコンをクリックします。

「ベンダー固有の機能に基づくルール」でVSANを選択すると、先ほどの5個のポリシーがプルダウンで表示されます。この中で最低 1 つのポリシーを定義します。

例えば、オブジェクトあたりのディスクストライプ数:1 / 許容する障害の数:1 等を指定してポリシーの作成が可能です。ウィザードを複数回繰り返すことにより、複数のポリシー作成も可能です。

下記は、ポリシーを3個作成した時の例です。

3.テンプレートを仮想マシンに適応する領域
2で作成したポリシーを適応して仮想マシンを作成します。具体的には、仮想マシン作成ウィザードの中のストレージの選択画面で、仮想マシンストレージポリシーを選択することにより、ストレージポリシーを適応した仮想マシンの作成が可能です。

Virtual SANでは、Thin Provisioningでデプロイされます。このためディスクタイプは定義済みとなっており、変更することは出来ません。

仮想マシン作成後、仮想ディスクがどのホストに配置されたかを確認することも可能です。例えば、ストライプ数2、許容する障害数1で仮想マシンを作成したときのディスクの配置は以下のようになります。

これでVirtual SAN上に、ポリシー通りに仮想マシンを配置することが出来ました。

次回、その3では、Virtual SANでの読み込み、書き込みの動作やホスト障害時の動作についてご説明したいと考えています。

vSphere 5.5 の新機能紹介 VMware Virtual SAN その1

このBlogは製品出荷前の情報を含みます。出来る限り正確な情報をお伝えするよう努めておりますが、実際に出荷される製品に搭載される機能や表示と異なる可能性があります。今回ご紹介するVirtual SANのステータスは 2013年 10月末現在 Public Beta であり、実環境での利用はサポートされません。また、最大構成や構成上の制限等は将来変更される可能性があります。あらかじめご了承ください。

Virtual SAN の特徴

今回ご紹介するVirtual SANは、従来のvSphereのストレージ概念とは全く異なる、拡張性に富んだストレージの新機能です。VMwareがSoftware-Defined Storage で定義しているポリシーベースでの管理もサポートしています。主な特徴を下記します。

1. ローカルディスクを利用した共有ストレージ
Virtual SANの最大の特徴は、各ホストに分散配置された内蔵ストレージを集約し、各ホストから利用可能な1つの共有ストレージとして提供することです。ホスト内蔵の安価で大容量な SAS/SATA の磁気ディスクと高速な SSD を組み合わせた、大容量かつ高速・低遅延な共有ストレージ領域を提供します。

2. 仮想ディスクレベルで設定可能なSLA
Virtual SANは従来のLUN+VMFSではなく仮想ディスクを直接オブジェクトとして管理します。このため、従来、LUN毎にしか定義できなかったパフォーマンスや可用性が仮想ディスク毎に定義可能となります。

3. 拡張が容易なスケールアウト型のストレージ
上記にも関連しますが、ホストの追加と共にデータストアも拡張される分散スケールアウト型のストレージです。

4. ポリシーベースのストレージ管理
仮想環境が大規模化してくるとストレージもTierの管理が必要となってきます。その際、従来行っていたストレージの物理構成(Raidの種類、デバイスの種類、プロトコルの種類)に基づいた手法では管理が煩雑となります。そこで、Virtual SANでは、可用性やパフォーマンスなどのポリシーをベースとしたストレージ管理手法を提供します。

Virtual SAN構成要素

Virtual SANは、SSDとHDDを有する3台以上のホストと、そのホスト間を接続する Virtual SANネットワークで構成されます。構成要素は下記の通りです。

・Virtual SANネットワーク
ホスト間のストレージプロトコルの転送を担当します。通信速度としては、1Gbps 及び、10Gbps の両方をサポートしています。*

・SAS/SATAコントローラ
SSDやSAS/SATAのHDDを接続するためのストレージコントローラです。Raidコントローラではパススルーモード、または、HBAモードをサポートしている必要があります。

・SSD
ホストに搭載する、SAS/SATA/PCIeのデバイスを利用します。SSDは恒久的なデータの置き場所ではなく、リードキャッシュ、ライトバックキャッシュとして利用されます。このSSDのパフォーマンスが、Virtual SANデータストアのパフォーマンスに大きく影響します。

※Virtual SANとして定義したSSDデバイスは、VMFS/vSphere Flash Read Cache/ホストスワップ領域として利用出来ません。

・磁気ディスク(HDD)
仮想ディスクを恒久的に保存する領域で、Virtual SANデータストアの容量を構成する部分となります。SSDでキャッシュミスした場合の読み出しと、SSDにライトバックされた書き込みキャッシュを最終的にディステージする領域を提供します。

※ESXiをインストールしたHDDデバイスはVirtual SAN用のHDDとして利用出来ません。

・ディスクグループ
SSDとHDDは個別にVirtual SAN領域に追加されるのではなく、ディスクグループとしてまとめてVirtual SAN領域に組み込まれます。1 つのディスクグループには必ず1台のSSDと、1~6台のHDDが含まれます。ディスクグループはホストあたり最大5個作成可能です。このため、ホストあたり、SSDは最大5台、HDDは最大30台までVirtual SANでの利用が可能となります。

※Virtual SANネットワークには10Gbpsを強く推奨します。理由は以下の通りです。
Virtual SANでは仮想マシンのvmdkを配置したホストと、仮想マシンが稼働するホストが同一ホストであるとは限りません。また、レプリカの作成やストライピングデータ転送に伴い、Virtual SANネットワークには多量のトラフィックが発生する可能性があります。現行のSATA SSDが6Gbpsインターフェイスを備えていることから考えても、1GbpsのVirtual SANネットワークではパフォーマンス上のボトルネックが生じる可能性が高いというのがその理由です。

Virtual SAN 全体イメージ

・Virtual SANデータストアは、1 つの共有データストアとして各ホストからアクセスが可能です
・仮想ディスクを配置するホストと、仮想マシンが稼働するホストに依存性はありません
vMotion での移行も通常の共有ストレージ同様自由に行うことが出来ます
・各仮想ディスク単位で可用性やパフォーマンス等のポリシーを定義することが出来ます
例えば、下記例では、緑の仮想ディスクは3面ミラー、濃い青の仮想ディスクはミラーとなっています

Virtual SAN の構築

Virtual SANの構築は極めて簡単です。以下手順を示します。
なお、この作業はc#版のvSphereClientからは実行できません。vSphereWebClientをご利用下さい。

1. Virtual SANネットワークの定義
Virtual SANを利用するにはまず、各ホストに対し、Virtual SANネットワークの定義を行います。

2. Virtual SANの有効化
Virtual SANはクラスタ単位で有効/無効の設定を行います。有効化の際のオプションとして、以下の二つがあります。

自動・・・Virtual SAN有効化と同時にホスト内のSSDとHDDをVirtual SANデータストアとして自動的に追加
手動・・・Virtual SANを有効化するのみ。Virtual SANデータストアに追加するSSD、HDDは別途手動で設定

3. ライセンスキーの入力
Virtual SANの利用にはライセンスキーの入力が必要です。VMwareが提供する他のアプリケーションのライセンスキーと異なり、クラスタレベルでライセンスキーを定義するところにご注意下さい。


※この設定を行わない場合、Virtual SAN構成を作成しても、Virtual SANデータストアの容量が”0”のままとなります。

4. Virtual SANで利用するSSD/HDDの選択(ディスクグループの作成)
手順2で手動を選択した場合、Virtual SANに追加するディスクを選択する作業が必要になります。

・ディスクグループの作成をクリックし、Virtual SANで利用するSSD 1 台と、HDD 1~6台を選択します。
・ディスクグループが複数ある場合は、上記作業を繰り返します。

選択されたディスクはVirtual SANに組み込まれ、Virtual SANクラスタに所属する各ホストから利用可能となります。
下記では、300GBのSATA HDD を搭載した4ホストでVirtual SANを構成した例を示します。

作成後のVirtual SANクラスタの拡張も簡単です。この場合、以下のような様々な方法がサポートされています。

・既存のディスクグループへのHDDの追加・・・容量の拡張
・既存のホストへのディスクグループ(SSD+HDD)の追加・・・IOPSと容量の拡張
・新規ホストとディスクグループの追加・・・IOPS、容量とホストリソースの拡張

また、ディスクの追加を伴わなず、ホストのみVirtual SANクラスタへ追加することも可能です。このようにVirtual SANは必要なリソースを柔軟に追加・拡張することが可能です。

次回、Virtual SANがサポートする仮想マシンストレージポリシーについてご説明します。

vSphere 5.5 の新機能紹介 – VMのパフォーマンスを最大化する、待ち時間感度 (Latency-Sensitivity) 機能

今回ご紹介する機能は、「待ち時間感度(Latency-Sensitivity)」 – CPU オーバーヘッドをできるだけ小さくすることにより仮想マシンのパフォーマンスを最大化し、同時にアプリ応答時間および遅延を最小化する機能です。

vSphere 環境上での仮想マシンのパフォーマンスについては、バイナリートランスレーション技術の最適化および VT-x やAMD-V といった CPU ベンダーによるハードウェア仮想化支援機能を利用することにより、これまでも物理ホスト上でネイティブに動作する場合とほとんど遜色のないパフォーマンスをたたき出すことに成功しています。
First SAP SD Benchmark on vSphere 5 Shows Performance within 6% of Native” (英語)
http://blogs.vmware.com/performance/2011/08/first-sap-sd-benchmark-on-vsphere-5-shows-performance-within-6-of-native.html
Performance Study of Oracle RAC on VMware vSphere® 5.0” (英語)
http://www.vmware.com/resources/techresources/10295

 CPU 処理のオーバーヘッドおよびネットワーク遅延

とはいえ従来の ESXi には、ある仮想マシンにたいし(特定の)物理 CPU(コア)を排他的に使用できるようにする機能はなく、他の仮想マシンと物理 CPU が共有されてしまうことを完全に排除することはできませんでした。(代替え策として、CPU アフィニティと予約を組み合わせることにより、特定の物理 CPU をある仮想マシンに「擬似的に」占有させるしか方法がありませんでした)
したがって、仮想マシンにたいして必ず物理 CPU が割り当てられていることを保証する手段がなかったため、マイクロ秒単位の非常に短時間のレスポンスを要求するようなアプリケーション(アプリ全体の中ではごく一部ですが)を、仮想マシン上で要求レベルどおりに動作させることは、大きなチャレンジでした。

また ESXi では、複数の仮想マシンにたいし効率よく物理 CPU を割り当てるために、 CPU スケジューリング機能を備えています。CPU スケジューリング機能は、VMware による長年の進化改良により、非常に効率のよいものになっていますが、ハイパーバイザが介在するため、VM-VM間、VM-ハイパーバイザ間のコンテキスト・スイッチングなど、ごく微少なオーバーヘッドが生じてしまいます。

また ESXi では、仮想マシン上の仮想 NIC と物理ホスト上の物理 NIC 間に、仮想スイッチを介在させるなどの、ネットワーク仮想化技術を実装しています。仮想ネットワークでパケットの頻繁な転送処理による効率低下を防止するため、仮想マシン-VMkernel間のパケット転送は、バッチによって処理しています(これを仮想 NIC コアレッシングといいます)。
これとは別に、仮想マシン側で短いパケットの多数受信した場合 CPU コストがかかります。受信処理を効率化し、仮想マシンの CPU コストを低下させるために、VMXNET3 仮想 NICでは、LRO (Large Receive Offload)という機能を実装しています。LRO 機能により、複数の短いパケットを単一の長いパケットにアグリゲートします。これにより、パケット処理における CPU コストを削減し、CPU 使用率を低下させています。
これらの仮想ネットワークのパケット転送効率化機能により、パケット受信および CPU 処理の効率化を図っていますが、その一方、(短い)パケットを受信したばあい、アグリゲート処理が加わるため若干の遅延が生じてしまいます。

待ち時間感度(Latency-Sensitivity)機能

上記の CPU スケジューリングのオーバーヘッドおよびネットワーク遅延を最小化するため、新たに「待ち時間感度」を設定する機能が導入されました。
待ち時間感度を設定することにより、下記のような効果を実現します。

  1. 物理リソースへの排他的アクセス権を与える
    CPU スケジューラは、CPU オーバーヘッドの有無を含むいくつかの要因を考慮し、物理 CPU への排他的アクセスを有効化するかどうか決定します。さらに、仮想 CPU の予約値を100%に設定することにより、仮想マシンの物理 CPU への排他アクセスを保証することが可能になります。
    (注意:待ち時間感度を有効化するには、仮想マシンのメモリ予約を設定しておく必要があります)
  2. 仮想化レイヤーをバイパスする
    仮想 CPU を100%予約することにより、一旦物理 CPU への排他アクセスが得られると、その物理 CPU 上は他のコンテキストが存在しないため、VMkernelの CPU スケジュールレイヤーをバイパスし、仮想マシンから直接 VM exit処理が可能になります。(VM exit についてはこちらを参照下さい)
    これにより、VMkernel とのコンテキスト・スイッチングに要する CP Uコストが削減されます。VM exit 処理そのものはなくなりませんが、EPT などのハードウェア仮想化支援機能を利用している場合は、VM exit 処理のコストは相対的に小さいものになります。
  3. 仮想化レイヤーのチューニングを行う
    仮想 NIC として、VMXNET3 準仮想化デバイスを使用している場合は、仮想 NIC コアレッシングと LRO を自動的に無効化します。
    これにより、パケット送受信にともなう遅延を最小化します。
    SR-IOV などの物理 NIC のパススルー技術を同時に使用した場合に、さらにパフォーマンスを向上させることが可能になります。

待ち時間感度(Latency-Sensitivity)設定を有効化する方法

待ち時間感度機能は、ESXi ホスト単位ではなく、仮想マシンごとに個別に設定します(デフォルトでは無効化されています)。
Web Client にて仮想マシンアイコンを右クリックし、[設定の編集]を選択します。[仮想マシン オプション]タブを選択し、[設定]を展開すると、「待ち時間感度」という欄が表示されます(vSphere Clientではこの機能は設定できません)。

上図のように、メニューには、”低”, “標準”, “中”, “高”の4つの項目がありますが、このうち”低”と”中”は試験的サポートとなりますので説明は省略します。
他の(正式サポートされる)メニュー項目の意味は下記の通りです。

  • – 上記で説明した機能すべてが有効化されます。[高]に設定するには、仮想マシンのメモリ予約が必要です。
  • 標準 – 「待ち時間感度」機能が無効化され、通常の仮想マシンの設定になります。

「待ち時間感度」機能利用時の注意点

「待ち時間感度」機能を有効化し、ある仮想マシンが物理 CPU を占有した場合、(たとえその仮想マシンがアイドル状態であっても)他の仮想マシンはその物理 CPU を利用できない場合がありますので、結果としてホスト全体の CPU 使用率が低下してしまう可能性があります。
また、仮想 NIC コアレッシングと LRO が無効化されるため、パケット送受信に関する遅延は低下しますが、パケットあたりの CPU コストが上昇します。したがってネットワークの全体的なスループットが低下し、CPU 使用率が上昇する可能性があります。
このような注意点がありますので、「待ち時間感度」機能をむやみに有効化することは避け、CPU のレスポンスタイムやネットワーク遅延に厳しいアプリケーションを動作させる場合のみ、有効化することをお奨めします。
「待ち時間感度」機能の技術詳細、ベンチマーク結果などについてホワイトペーパーが公開されておりますので、そちらも参照下さい。
Deploying Extremely Latency-Sensitive Applications in VMware vSphere 5.5
https://www.vmware.com/resources/techresources/10383

vSphere 5.5の新機能紹介 – VMware vCenter Orchestratorの新機能

ITプロセスの自動化を組織に導入・推進していくためには、特にITのサービス化という観点から、マネジメント、エンドユーザ、エンジニア、管理者を含む組織内の全ての関係者が取り組みに関わっていくことが不可欠と言えます。その際、これまで手作業で行われていた自動化の対象となり得る管理作業や業務フローを継続的に洗い出し、それらを短いサイクルで俊敏に実装して組織に導入していくためのフレームワークを確立することが重要になります。

今回は、VMwareの提供するクラウドソリューションにおけるITプロセスの自動化・オーケストレーションの基盤・統合レイヤとして存在感を増しつつあるVMware vCenter Orchestrator(以下vCO)について、先日リリースされたバージョン5.5 で追加された主な新機能をご紹介します。

VMwareにおける自動化ツールセットの位置付け

なお、これまでvCOについて聞いたこと、もしくは実際にお使いになられたことがない方も多いと思いますが、この製品自体は以前より存在しており、実はvCenter ServerをSimple Install(vCenter Server 5.0では通常のインストール)するとvCOも標準でインストールされています。また、vCOをvCenter Serverと別サーバにインストール(スタンドアロン)したり、仮想アプライアンス版を利用することも可能です。

vCenter Server上に標準でインストールされているvCOサービス

以下にvCOのアーキテクチャ(概観)を示します。

vCOのアーキテクチャ(概観)

vCO 5.5では、成長する仮想化/クラウド基盤への対応がメインテーマの一つとなっており、特に拡張性(Scalability)や可用性(High Availability)の点で大きく改善されています。また、vCO Clientの機能性も向上し、開発者がよりシンプルかつ効率的にワークフローを開発できるようになっています。

vCO 5.5では、大きく以下のカテゴリについて機能向上及び追加がなされています。

成長する仮想化/クラウド基盤への対応

  • クラスタモードのサポート

開発生産性の向上

  • ワークフローデバッガ
  • 失敗した最後のアクティビティからのワークフロー再開

その他の機能向上

  • vSphere Web Clientとの連携
  • 国際化(i18n)

vCO Client

成長する仮想化/クラウド基盤への対応

1. クラスタモードのサポート

仮想化/クラウド基盤の規模が拡大するに従って、その自動化をサポートするオーケストレーションレイヤのスケーラビリティや可用性を考慮する必要性が高まります。vCO 5.5で導入されたクラスタモードを利用することで、vCOサーバ(ワークフロー実行エンジン)の同時処理能力や可用性を高めることができます。

クラスタモード

vCOのクラスタではフェイルオーバーをサポートしています。クラスタはActive/ActiveまたはActive/Standby構成が可能で、クラスタモードの設定でアクティブノードの数を指定します。

クラスタモードにおけるアクティブノード数の指定

クラスタ中の全ノードがアクティブの場合、あるノードに障害が発生した場合は別のアクティブノードが直ちにセッションを引き継いで処理を継続します。一方、スタンバイノードが存在する場合、アクティブノードからのハートビートが途切れて障害を検出すると、スタンバイノードがアクティブになり処理を引き継ぎます。

また、外部のロードバランサと組合わせることで、動的なスケールアップ/ダウンも可能になります。

開発生産性の向上

1. ワークフローデバッガ

アプリケーションの開発において、デバッガは開発生産性を左右する大きな要素の一つです。vCO 5.5で新たに導入されたワークフローデバッガを利用することで、開発者はより迅速かつ容易にワークフローをトラブルシュート/テストすることができます。

ワークフローデバッガ

ワークフローを「デバッグモード」で実行する際には、個々のワークフローアクティビティに対してブレークポイントを設定し、ステップ実行しながらフローのある時点における変数値にアクセスすることが可能です。

ブレークポイント

2. 失敗した最後のアクティビティからのワークフロー再開

vCO 5.5では、ワークフローの実行に失敗した際に、失敗したアクティビティの状態からワークフローを再開する機能が導入されています。この機能は個々のワークフローまたはシステムレベルで設定されます。

ワークフロー実行に失敗した際の再開機能の設定

この機能を有効にしていると、ワークフローが失敗した際に次のようなポップアップが表示され、処理を再開して継続することができるようになります。

失敗したワークフローの再開

また、ワークフローの再開時には入力パラメータを修正することも可能です。

再開時のパラメータ値の修正

その他の機能追加および改善

最後に、vCO 5.5におけるその他の主な改善点についてご紹介します。

1. vSphere Web Clientとの連携

vCOではバージョン5.1以降、SSO認証と組合わせることでvSphere Web Clientと連携できるようになり、vCO Clientからだけでなく、Web Client上からもvCOサーバの状態を監視したりワークフローを実行することが可能です。

個々のワークフローはvCenterのオブジェクトに関連付けることができ、Web Clientのコンテキストメニューの一つとして表示されます。これにより、例えばWeb Client上で対象となるホストを選択して、新しい仮想マシンを作成するカスタムのワークフローを実行するようなことが簡単にできます。この仕組みを使えば、標準では用意されていない機能をメニューとして追加することで、Web Clientの機能を簡単に拡張することができます。

vSphere Web Clientとの連携

vSphere Web Clientからのワークフロー実行

vCO 5.5では、Web Clientの管理画面上で対象となるvCOサーバをオンデマンドで追加できるようになっています(5.1以前は、個々のvCOサーバの管理画面上から設定されたインスタンスを自動検出することのみが可能でした)。

Web Clientの管理画面上でのvCOサーバの追加

2. 国際化(i18n)

vCO 5.5の国際化(i18n)対応レベルは、前のバージョンと同じくlevel 1となります。GUIのローカライズ(l10n)などはされていませんが、非英語OS上での動作及び、非英語テキストの処理をサポートしています。また、vCO 5.5ではローカルのdate/timeフォーマット及び地域設定に対応しています。

vCOの各種コンポーネントにおける非英語テキストの対応状況については、下記マニュアルの該当項目をご確認下さい。

Installing and Configuring VMware vCenter Orchestrator 5.5 –   Non-ASCII Character Support in Orchestrator (p.15)
http://pubs.vmware.com/vsphere-55/topic/com.vmware.ICbase/PDF/vcenter-orchestrator-55-install-config-guide.pdf

まとめ

VMware vCenter Orchestrator 5.5では、拡張性や可用性、機能性などの面で、大きく以下のカテゴリについて機能向上及び追加がなされています。

  • 成長する仮想化/クラウド基盤への対応
  • 開発生産性の向上
  • その他

ここでは全てを紹介することはできませんでしたが、vCO 5.5におけるその他の機能拡張及び、製品の詳細については以下サイトの情報も是非ご参照下さい。

VMware vCenter Orchestrator 5.5 Release Notes (What’s New含む)
https://www.vmware.com/support/orchestrator/doc/vcenter-orchestrator-55-release-notes.html
vCenter Orchectrator 製品情報
http://www.vmware.com/products/vcenter-orchestrator/
VMware vCenter Orchestrator Blog
http://blogs.vmware.com/orchestrator/

なお、vCOを本番環境で導入頂く際には、通常の製品サポートの他にVMware SDK Support のご購入を強く推奨致します。

VMware SDK Support Program
https://www.vmware.com/support/services/sdk.html

vSphere 5.5の新機能紹介 PowerCLI 5.5

vSphere 5.5 シリーズの新機能についてリレー形式のエントリでご紹介させていただいて来ましたが、今回はコマンドライン大好きな方にお送りします。

本エントリでは、VMware PowerCLI 5.5 の新機能概要についてご紹介させていただきます。なお、このブログエントリは VMware PowrtCLI Blog の“PowerCLI 5.5 What’s New-Overview” を抄訳、実機での確認を追記したものになります。

image
(New!)
1. vSphere タグを管理するためのコマンドレット

・vSphere 環境でのタグの管理
・vSphere オブジェクトへのタグのアサイン
・vSphere オブジェクトからのタグの削除
image
(追加) 2. 分散仮想スイッチ(vDS )用コマンドレット
・vDS マイグレーションを容易にする機能
・プライベートVLAN の管理
・vDS のポリシー管理
・vDS のポート管理
image
(New!) 3. 仮想マシンコンソール用コマンドレット
・vSphere 及び vCloud Director 仮想マシンのコンソールを開く
・複数のコンソールを同時に開く
・仮想マシンコンソールのURLを出力する
image
(New!) 4. vCloud Director 5.5 のサポート
image
(New!) 5. ホストライセンス
・ホストへのライセンス付与

では、具体的にどういう動きをするのかを一部だけになりますが簡単に確認してみましょう。

 

1. vSphere タグを管理するためのコマンドレット

>Get-Tag

タグの一覧を表示します。

>Get-TagAssignment

タグの付与状況の一覧を表示します。

 

3. 仮想マシンコンソール用コマンドレット

>Open-VMConsoleWindow 仮想マシン名

これだけで、ブラウザのウィンドウが立ち上がりコンソールが表示されます。

コンソールを起動せずに、URLだけを出力する場合は次のように実行します。

>Open-VMConsoleWindow 仮想マシン名 -UrlOnly

パワーオフ状態のVMのコンソールだけをまとめて開く場合、次のように実行します。

>Get-VM | Where-Object{($_.PowerState) -eq "PoweredOff" | Open-VMConsole Window

うまく組み合わせると、PowerCLI で運用管理に必要なコンソールをまとめたランチャーのようなものがつくれそうですね。

なお、このブログエントリは、製品出荷前のバイナリ及びマニュアルをベースに記載しています。出来る限り正確な情報をお伝えするよう努めておりますが、実際に製品に搭載される機能や表示とは異なる可能性があります。あらかじめご了承の上、ご利用下さい。

vSphere 5.5 の新機能紹介 – vCenter Serverの新機能

このBlogは、製品出荷前バイナリ及びマニュアルをベースに記載しています。出来る限り正確な情報をお伝えするよう努めておりますが、実際に製品に搭載される機能や表示と異なる可能性があります。あらかじめご了承の上、ご利用下さい。

今回は VMware vCenter Server 5.5(以下vCenter 5.5) の新機能についてご紹介します。
vCenter 5.5 の主な新機能は下記のとおりです。

  1. vCenter Single Sign-On の強化
  2. vCenter Server Appliace 内蔵データベースのスケーラビリティ向上
  3. vCenter 用データベースのクラスターテクノロジーの正式サポート

また新機能ではありませんが、vCenter Server の旧バージョン(4.1/5.0/5.1)からのアップグレード方法について、若干の注意点がありますので、それについても記載します。

1. vCenter Single Sign-On の強化

vCenter 5.1 に同梱されていた Single Sign-on サービス(以下SSO)は、vCenter 5.5 では全面的に刷新され、主にスケーラビリティ、信頼性などが大きく向上しています。
また、従来はデータ格納用として SQL Server など外部データベースシステムが必要でしたが、vCenter 5.5の SSO では外部データベースが不要となり、SSO 内部でデータを保持するよう変更されました。これにともない、SSO マルチサイト構成における、サイト間のデータの同期については、SSO モジュール自身の機能で行えるようになりました(従来は外部データベースのリプリケーション機能が必要でした)。
SSO の機能向上などの詳細については、あらためて別の項でご紹介します。

2. vCenter Server Appliace 内蔵データベースのスケーラビリティ向上

vCenter 5.5 でも引き続き、OSを同梱した仮想アプライアンス形式である vCenter Server Appliace (以下vCSA)を提供します。
従来の vCSA では、内蔵データベース(vPostgres)にて管理可能な ESXi ホスト、仮想マシンなどのオブジェクト数に大きな制限があり、最大 5ホスト、50VMまでのみ対応となっていました。
vCSA 5.5 ではこの制限が大幅に緩和され、最大 100ホスト、3,000VMまで対応できるよう向上しました。従来の数十倍のオブジェクトが管理可能になったわけです。
多くのオブジェクトを管理する環境で使用する際の注意点として、vCSA 5.5 デプロイ時のデフォルトの仮想CPU数、メモリサイズ、仮想ディスクのサイズでは不足する場合がありますので、その場合は仮想メモリ、ディスクサイズ等を増やす必要があります。
管理対象オブジェクト数に対する vCSA 仮想マシンのサイジングのガイドにつきましては、「vCenter Server およびホスト管理ガイド」に記載されていますが、メモリサイズについては下記のとおりです。

VMのメモリサイズ
オブジェクト数
4GB以上 10ホストおよび100VM未満
8GB以上 10から100ホスト、または100-1000VM
16GB以上 100から400ホスト、または1000から4000VM
24GB以上 400ホスト以上、または4000VM以上 (外部DB使用時)

内蔵データベース上にこれらのオブジェクトの情報を格納する場合は、vCSA 仮想マシンに仮想ディスク(VMDK)を別途追加する必要がある場合があります。仮想ディスクの追加方法につきましては、下記ナレッジベースを参照ください。
Increase the disk space in vCenter Server Appliance (2056764) ” (英語)
http://kb.vmware.com/kb/2058187

内蔵データベースに情報を格納する場合は vCSA 仮想マシンのディスク使用量が徐々に増加していきますので、ディスクの残り容量が枯渇していないかどうか、定期的に監視することを強く推奨します。
vCSA 仮想マシンのディスク使用率は、vCSA の管理ウェブコンソール(https://<vCSAのFQDN>:5480)にて監視することが可能(vCenter Server タブ > Summary リンク: 右図参照)ですが、より利便性を高めるために、自動で監視しアラートを通知するためのガイドを提供しています。設定方法につきましては、下記のナレッジベースを参照ください。
Monitor vCenter Server Appliance database disk usage (2058187) ” (英語)
http://kb.vmware.com/kb/2058187

3. vCenter 用データベースのクラスターテクノロジーの正式サポート

vCenter 5.5(Windows 版および vCSA)にて Oracle などの外部データベースを使用する場合、それらのデータベースシステムで利用可能な高可用性テクノロジー(Oracle RAC など)を、 vCenter Server 用データベースとして正式サポートするようになりました。サポートするクラスターテクノロジーの製品名およびバージョン等につきましては、弊社ナレッジベースにて提供する予定です。

4. 旧バージョンからのアップグレード

vCenter 5.1 から vCenter のサービスは、Single Sign-On, Inventory Service, vCenter の3つのモジュールに分割され、それぞれ別のシステムにインストールすることが可能になっています。また Web Client を利用するためには、さらに Web Client Service をインストールする必要があります。
vCenter 5.1 以降では、vCenter をインストールする場合、Simple Install、Custom Installの二つの方法が利用可能です。前者は、SSO、Inventory Service、vCenter を同一システムに一括してインストールする方法です。後者はそれぞれのサービスを別々のシステムに個別にインストールする場合に使用します。
vCenter 5.5 でもSimple Install、Custom Installのそれぞれが利用可能ですが、vCenter の旧バージョンからアップグレードする場合は、それぞれのモジュールのインストール場所およびアップグレード順序についても考慮点があります。
特に注意しなければならないのは、アップグレード順序で、下記の順番でアップグレードする必要があります。

  1. SSO
  2. Web Client
  3. Inventory Service
  4. vCenter

アップグレード元 vCenter のバージョン、および個々のモジュールの配置場所により、アップグレードの方法が異なりますので、下図を参照下さい。

vCenter 5.5 へのアップグレードについては、弊社ナレッジベースに詳細がありますので、そちらを参照ください。
Upgrading to vCenter Server 5.5 best practices (2053132) ” (英語)
http://kb.vmware.com/kb/2053132

VMware vCloud Director 5.5 – 新機能紹介

このBlogは、製品出荷前バイナリ及びマニュアルをベースに記載しています。出来る限り正確な情報をお伝えするよう努めておりますが、実際に製品に搭載される機能や表示と異なる可能性があります。あらかじめご了承の上、ご利用下さい。

今回は、VMware vCloud Director 5.5で追加された主な新機能についてご紹介します。

vCloud Director 5.5では、大きく以下の3つのカテゴリについて機能向上及び追加がなされています。

■カタログ機能

  • 共有カタログに対する組織単位でのアクセス制限
  • 複数のvCloud Directorインスタンス間でのカタログの公開/購読
  • カタログ内のコンテンツに対する自動バージョン付け
  • 任意のファイル形式のサポート

vAppの展開及びライフサイクル管理

  • テンプレートからのvAppの展開時における仮想マシンハードウェア設定の編集
  • vAppテンプレートレベルでのゲストOSのカスタマイズ設定の編集(※)
  • 実行中の仮想マシンにおける仮想NICの追加、取り外し、接続及び切断(ホットアド/リムーブ)
  • 実行中/サスペンド中のvApp/仮想マシンのメモリ状態を含むクローンの作成
  • vAppの(カタログを介さない)直接展開及びエクスポート
  • OVAファイル形式のサポート

追加サポート

  • vCloud DirectorセルのオペレーティングシステムとしてCentOSのサポート
  • Google Chrome Webブラウザのサポート
  • Mac OS Xにおける仮想マシンコンソールアクセスのサポート

※注意事項:

「vAppテンプレートレベルでゲストOSのカスタマイズ設定を編集できる」機能は、本ブログ執筆時点では急遽リリース見送りになっています。この決定は各種デモやホワイトペーパーの作成後になされたとのことで、所々で言及されているケースがあります。この機能のご利用を検討されていた場合は、vCloud Director 5.5ではリリースされない予定ですのでご注意下さい。
詳しくは、以下のブログエントリの内容もご確認下さい。

A Summary of What’s New in vCloud Director 5.5
http://blogs.vmware.com/vsphere/2013/09/a-summary-of-whats-new-in-vcloud-director-5-5.html

また、前バージョンと同様にvCloud Directorセルの仮想アプライアンス(SLES 11 SP2ベース)も提供されますが、vCloud Director 5.5においてもPoC/評価目的限定での使用を想定しております。本番環境での使用はサポートされません。

■カタログ機能の向上

1. 共有カタログに対する組織単位でのアクセス制限

組織間でのカタログ共有機能は以前から存在していましたが、これまでは「すべての組織に発行(shared)」か「その他の組織にこのカタログを発行しない(nonshared)」のいずれかを選択することしかできませんでした。vCloud Director 5.5では、ユーザがカタログを共有する「特定の組織」を明示的に選択することが可能になり、よりきめ細やかなアクセス制御を行うことができます。なお、vCloud Director 5.1では組織間でのカタログ共有を「公開」タブで指定していましたが、5.5では「公開」は次節で説明する複数vCloud Directorインスタンスを跨いだ組織間でのカタログ公開/購読(外部公開)の意味となり、共有する組織の指定はメンバーの追加と合せて「共有」指定の一部となっています。

共有カタログに対する組織単位でのアクセス制限

2. 複数のvCloud Directorインスタンス間でのカタログの公開/購読

vCloud Director 5.1以前のバージョンでは、複数のサイト(異なるvCloud Directorインスタンス)で同じ内容のコンテンツを利用したい場合、サイト毎にカタログを管理する必要があり、運用管理にコストがかかっていました。vCloud Director 5.5では、あるvCloud Directorインスタンスのカタログを外部に「公開」し、利用者側で公開されたカタログを「購読」することで、vCloud間でコンテンツを共有することが可能になりました。この公開/購読機能を利用することで、同一のvAppテンプレートやメディアファイルの運用管理が非常に簡素化されます。

カタログの公開/購読

カタログの公開側では「サブスクリプションURL」を生成し、オプションでパスワードによる保護が可能です。一方購読側では、カタログの新規作成時に外部カタログへのサブスクライブを選択し、購読対象のURLとパスワードを(オプションで)指定します。カタログのコンテンツはデフォルトでは購読時に完全同期し、以降はカタログの更新に合せて自動的に同期します。この動作は変更可能で、購読時にはカタログのメタデータのみを取得し、オンデマンドで同期させることもできます(大規模なカタログを購読する場合に特に有効)。

カタログの公開/購読(2)

また、サイト間のコンテンツのレプリケーションは、デフォルトではVMware独自プロトコルであるhttpsベースのVCSP(VMware Content Subscription Protocol)により実行されます。カタログの公開側では、同期対象のコンテンツをスプール領域に事前エクスポート(キャッシング)することで、同期処理が高速化されます。さらに、スプール領域のコンテンツに対して、VCSPの代わりにサードパーティ製レプリケーションツールを使用することも可能です。

3. カタログ内のコンテンツに対する自動バージョン付け

vCloud Director 5.5では、vAppテンプレートやメディアファイルを含むカタログ上のすべてのコンテンツに対する、シンプルな自動バージョン付け機能が追加されています。バージョン番号は、コンテンツをカタログに追加する際に割り当てられ、更新される度に自動的に加算されます。この機能により、これまでのようなファイルの命名規則ベースの煩雑な方法に代わるシンプルなバージョン管理が可能になります。

コンテンツの」自動バージョン付け

なお、更新の際にはコンテンツが旧バージョンから新バージョンに置き換わりますが、例えば変更履歴や更新者履歴などの(変更監査のための)情報は保持されません。

4. 任意のファイル形式のサポート

これまでのバージョンでは、vAppテンプレート(OVF)及び仮想マシンへのマウントを目的としたメディア(ISO、フロッピーイメージ)のみがアップロード可能でした。vCloud Director 5.5では、カタログが任意のファイル形式をサポートするようになりました。この機能により、例えばログファイルやWord文書、vCenter Orchestratorのワークフローなど、組織間やvCloud Directorインスタンス間での様々なタイプのファイル共有が容易になります。

任意のファイル形式のサポート

vAppの展開及びライフサイクル管理

1. テンプレートからのvAppの展開時における仮想マシンハードウェア設定の編集

vCloud Director 5.5では、カタログからvAppテンプレートを選択して新しいvAppを展開するタイミングで、仮想マシンハードウェア設定(CPU、メモリ及びハードディスク)をカスタマイズできるようになっています。これまでは、構成毎にvAppテンプレートを用意しておく(もしくは一旦展開した後に個別の仮想マシンに対するプロパティを編集する)必要があり、ストレージ容量やテンプレート管理のコスト、あるいは展開時の手間がかかっていました。この機能により、1つのテンプレートでの複数vApp構成への対応や、操作が簡単になります。なお、展開時に設定を変更した場合も、元のvAppテンプレートの設定情報は保持されます。

vApp展開時の仮想マシンハードウェア設定の編集

なお余談ですが、vCloud Director 5.5ではCPU数の設定でソケット及びソケットあたりのコア数の指定も可能になっています。

2. 実行中の仮想マシンにおける仮想NICの追加、取り外し、接続及び切断(ホットアド/リムーブ)

実行中の仮想マシンに対してハードディスクを追加、取り外し及び拡張する機能はvCloud Director 5.1で導入されましたが、vCloud Director 5.5では仮想NICのホットアド/リムーブ及び接続/切断の機能が追加されました。これによって、仮想NICの構成変更の際に仮想マシンをシャットダウンする必要が無くなり、ダウンタイムが短縮されます。

仮想NICのホットアド/リムーブ

制限事項として、実行中の仮想マシンのプライマリNICに対しては、削除やネットワーク・IPモードの変更操作を実行することはできません。また、スナップショットを含む仮想マシンに関しては、NIC構成の変更自体が不可となります。

スナップショットを含む仮想マシンのNIC構成

3. 実行中/サスペンド中のvApp/仮想マシンのメモリ状態を含むクローンの作成

vCloud Director 5.1までは、実行中の仮想マシンのメモリ状態を含んだスナップショットの作成のみが可能でした。実行中やサスペンド中の仮想マシン群をメモリ状態も含めてクローンしたり、テンプレートとしてカタログに登録する機能は、特にアプリケーション開発やテスト、トラブルシューティング環境において求められてきましたが、vCloud Director 5.5で実装されています。

メモリ状態を含むクローンの作成

なお、この機能を利用するためにはvCenter Server 5.5が必要となります。また、カタログからのエクスポートやvCenter Serverインスタンス間でコピーされる場合にはメモリ状態が失われます。

4. vAppの(カタログを介さない)直接展開及びエクスポート

これまで、vCloud Director環境上にvAppを展開する際には、事前にvAppテンプレートをカタログに登録しておく必要がありました。vCloud Director 5.5では、カタログを介すことなくOVFパッケージから直接インポートして展開することが可能になりました。これにより、ストレージ容量やvApp展開までの時間が削減できます。

vAppの直接展開

また、vAppをOVFまたはOVA(単一)ファイルとしてローカルに直接ダウンロード(エクスポート)することも可能になっています。

vAppのダウンロード

5. OVAファイル形式のサポート

vCloud Director 5.5では、これまでのOVF形式のファイルに加えて最近使用するケースが増えつつあるOVA(単一)ファイル形式にも対応しています。

OVAファイル形式のサポート

追加サポート

最後に、vCloud Director 5.5で新たに追加された主なサポート項目についてご紹介します。

1. vCloud DirectorセルのオペレーティングシステムとしてCentOSのサポート

vCloud Directorセルを構築する際には、これまでは商用OSであるRed Hat Enterprise Linux(RHEL)のみがサポートされていました。vCloud Director 5.5では、これに加えてCentOS(V.6.1 – 6.4)がサポート対象として追加され、vCloud Director導入の際のコスト的な敷居が下がっています。

2. Google Chrome Webブラウザのサポート

これまでサポートされていたIE、Firefoxに加えて、Google Chromeブラウザのサポートが追加されています。

3. Mac OS Xにおける仮想マシンコンソールアクセスのサポート

これまで、Mac OS XではvCloud Directorの仮想マシンコンソールがサポートされておらず、Macユーザにとって不便な環境でした(WindowsやLinux環境を別途用意する必要があるなど)。vCloud Director 5.5では、Mac OS X上で利用可能なFirefoxおよびGoogle ChromeがHTML5ベースの仮想マシンコンソールをサポートしたことで、Macユーザに対するvCloud環境の利便性が高まっています。

なお、HTML5ベースの新しい仮想マシンコンソールの実装は、Mac OSのみで使用されます。Windows及びLinux環境では、従来どおりのVMRC(VMware Remote Console)プラグインが有効になります。また注意事項として、HTML5ベースの実装ではVMRCに比べて以下の機能制限があります。

  • デバイスのサポートなし(コンソールからのCD-ROMのマウント/アンマウント不可)
  • クリップボードのサポートなし(コンソールとの間でのコピー&ペースト不可)
  • コンソール上で自動的にマウスをつかむ/リリースする機能のサポートなし

まとめ

vCloud Director 5.5では、使いやすさ、機能性及び管理性の面で、大きく以下の3つのカテゴリについていくつかの重要な機能追加と向上がなされています。

  • カタログ機能
  • vAppの展開及びライフサイクル管理
  • 追加サポート

また、以下のホワイトペーパーも是非ご参照頂ければと思います。

What’s New with VMware vCloud Director 5.5
http://www.vmware.com/files/pdf/products/vCloud/Whats-New-VMware-vCloud-Director-55-Technical-Whitepaper.pdf

VMware vSphere 5.5 AppHAについて

このBlogは、製品出荷前のバイナリ及びマニュアルをベースに記載しています。出来る限り正確な情報をお伝えするよう努めておりますが、実際に製品に搭載される機能や表示とは異なる可能性があります。あらかじめご了承の上、ご利用下さい。

今回は、VMware vSphere 5.5のAppHAの機能を紹介します。

VMware vSphere 5.5より、ゲストOS内で稼働するアプリケーションの状態監視を行えるようになりした。

監視対象アプリケーションのサービスが停止した際、「サービスの再起動」または「仮想マシンのリセット」が実行されます。また、同時にvCenterへのアラート通知と管理者へのメール通知を行うことも可能です。

従来、VMware vSphere HAではアプリケーションの監視を有効にするには、適切な SDK を入手し、これを使用して監視対象となるアプリケーションのハートビートの開発/設定する必要がありました。AppHAでは、特別な開発を必要とせず、仮想マシン内で稼働するサービスに対しての保護が可能となります。

AppHAは従来のvSphere HA機能と連携して、ホスト障害から仮想マシン内で稼働するアプリケーションの保護まで可能となりました。



 

 

 

現行バージョンで監視対象と出来る、アプリケーションは下記となります。
※ 2013/9/25追記:アプリーショーンの最新のサポート状況に関しては弊社マニュアルを参照ください。

  • Microsoft SQL Server2005
  • Microsoft SQL Server2008
  • Microsoft SQL Server2008R2
  • Microsoft SQL Server2012
  • Microsoft Internet Information Services6
  • Microsoft Internet Information Services7
  • Microsoft Internet Information Services8
  • VMware vFabric tc Server6
  • VMware vFabric tc Server7
  • Apache Tomcat6
  • Apache Tomcat7
  • Apache HTTP Server1.3
  • Apache HTTP Server2.0
  • Apache HTTP Server2.2

 1.稼働コンポーネントについて

AppHAを設定するには、下記のコンポーネントの導入が必要となります。

各コンポーネントの稼働要件については、弊社ドキュメントでご確認ください。

1.vCenterサーバ

2.AppHAサーバ(仮想アプライアンス)

3.vFabric Hyperic Server(仮想アプライアンス)

4.vFabric Hyperic Agent(監視対象となる仮想マシン内で稼働)

2.AppHAの設定について

仮想マシン内で稼働する、アプリケーションの監視方法はすべて、ユーザーが事前に定義するポリシーにより決定されます。

AppHAを利用して、監視対象アプリケーションの登録方法とポリシー設定について紹介します。

AppHAは、vFablic Hyperic Serverと連携して稼働するため、AppHAのデプロイ後、vFabric HQ Serverと監視対象となる仮想マシンにvFabric Hyperic Agentの登録が必要となります。vFablic Hyperic ServerとvFabric Hyperic Agentの導入方法については、マニュアルを参照ください。

1.AppHAの初期設定として、AppHA Plug-InよりvFablic Hyperic Serverの接続情報を指定します。

2.監視ポリシーを追加します。

3.ポリシー名とコメントを設定します。

4.監視対象となるサービスの種類を選択します。

5.監視対象のサービスが停止した場合の対処方法について設定をします。

6.vCenter Serverに対してアラートの設定とメール通知の設定をします。

7.すべての設定が完了後、仮想マシン内で稼働するサービスに対して作成したポリシーを割り当てます。

また事前に、vFabric Hyperic ServerにvCenterの登録をしておく必要がありますので、登録をしていない場合、名前を「VC」としてNew Server登録を行ってください。

設定の詳細に関してはマニュアル「Fabric Hyperic Resource Configuration and Metrics」の「vSphere」の章を参照ください。

8.設定が完了して、ステータスが「Available」となると監視が開始されます。

なお、VMware vSphere HAの設定は「仮想マシンとアプリケーションの監視」で設定する必要があります。

まとめ

仮想環境において仮想マシン内で稼働するアプリケーションの監視が容易に行えるようになりましたので、是非 ご利用ください。

vSphere 5.5 の新機能紹介 ネットワーク2 (トラフィックのフィルタリングとマーキング)

このBlogは、製品出荷前バイナリ及びマニュアルをベースに記載しています。出来る限り正確な情報をお伝えするよう努めておりますが、実際に製品に搭載される機能や表示と異なる可能性があります。あらかじめご了承の上ご利用下さい。

今回は先日発表されましたVMware vSphere 5.5 で追加されたネットワークの新機能のなかから、トラフィックのフィルタリングとマーキングの概要をご紹介します。vSphere 5.5 では、分散仮想スイッチ(vDS)のポートグループレベルでトラフィックのフィルタリングとマーキング機能を実装します。フィルタリング機能は、物理スイッチのアクセスコントロールリスト(ACL)に相当するものとなり、パケットヘッダに基づいてトラフィックをコントロールしセキュリティを確保します。マーキング機能は、重要なトラフィックにタグ付けを行い、付与されたタグをもとに物理ネットワーク上でトラフィックを優先制御することで、End-to-End でサービス品質を確保します。

 

■特徴
・分散仮想スイッチ(vDS)のポートグループ単位で設定を行います。
・対象となるトラフィックを、MACアドレス、IPアドレス/プロトコルタイプ/ポート番号 、システムトラフィックから指定します。
・入力または出力、あるいはその両方をフィルタリング対象として選択します。
・マーキングでは、Differentiated Service Code Point (DSCP)、及び802.1p Class of Service (CoS)で定義されたタグを付与できます。
・仮想マシンにより近いポイントとなる分散仮想スイッチでフィルタリング及びマーキングを行うことで、End-to-End でのセキュリティとサービス品質を確保します。


なお、VXLAN 環境で付与されたDSCP タグは、オリジナルのIPヘッダからVXLAN でカプセル化した際に付加されるIPヘッダにコピーされるため、物理ネットワーク上でタグを認識し優先制御を実施することが可能です。


下記のキャプチャから、両方のIPヘッダ内にDSCP タグがセットされていることが確認できます。


■設定
「ネットワーク」で適用する「ポートグループ」を選択し、「管理」-「設定」-「ポリシー」画面で、「編集」を選択します。ポートグループの設定画面で、「トラフィックのフィルタリングとマーキング」を選択します。ステータスを有効にし、ルールを追加します。


フィルタリングを実施する場合は、「許可」もしくは「ドロップ」を選択します。マーキングを行う場合は、「タグ」を選択します。


タグを選択した場合、CoS もしくは、DSCP の値をセットします。


フィルタリングもしくはマーキングの対象となるトラフィックを指定します。


システムトラフィック、MACアドレス、IPアドレスの詳細を定義します。システムトラフィックでは、あらかじめ定義されたトラフィックを選択します。


以上、vSphere 5.5 のトラフィックのフィルタリングとマーキングの概要をご紹介いたしました。