Home > Blogs > Japan Cloud Infrastructure Blog > 月別アーカイブ: 2013年10月

月別アーカイブ: 2013年10月

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

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

バージョン5.5 で追加されたVDP の主な新機能は以下となります。

1. 柔軟なバックアップ データの配置
2. 仮想ディスク単位のバックアップに対応
3. 粒度の高いバックアップ スケジューリングにより、顧客のニーズに対応
4. vCenter Server に依存せずに任意の仮想マシンをリストア
5. オフサイトへのバックアップ データの保管と、長期保管への対応

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

1. 柔軟なバックアップ データの配置
vSphere 5.1 で導入されたVDP のアプライアンスは、容量毎(0.5 TB /1.0 TB / 2.0 TB) に仮想アプライアンスを提供しておりました。使用したい容量の仮想アプライアンスをデプロイすれば、必要な容量の仮想ディスクが接続されいるので、非常に簡単にセットアップすることが可能です。しかしながら、このデプロイ方法では、仮想アプライアンスのOSとバックアップを取得するための領域が同じ仮想マシンフォルダ内に配置されてしまうため、バックアップ領域(仮想ディスク)をOSとは異なるデータストアに配置するような構成をとることができませんでした。

5.5 では、容量別に仮想アプライアンスは提供されず、1つのアプライアンスのみが提供され、VDP のWeb コンソールを通じて容量(仮想ディスク)を構成します。

下の画面のようにVDP 仮想アプライアンスの容量は、初期セットアップ画面で構成するようになりました。また、既存にあるVDPのバックアップデータを新規にデプロイしたVDPアプライアンスで利用することも可能になっています。

図1. VDP 仮想アプライアンスの初期セットアップ画面1
バックアップ データを保存するための仮想ディスクを任意のデータストアに配置することができるようになりました。下の画面は、容量0.5 TB を選択した場合に、構成に必要な256 GB の仮想ディスク3 個をどのデータストアに配置するかを選択する画面になります。

図2. VDP 仮想アプライアンスの初期セットアップ画面2
2. 仮想ディスク単位のバックアップに対応
vSphere 5.1 で導入されたVDP のバックアップ対象の最小単位は、それまで提供されていたVMware Data Recovery の仮想ディスクとは異なり、仮想マシンとなりました。お客様によっては、これまでのバックアップ単位とは異なる可能性がありました。
5.5 からは、仮想ディスクを個別に選択することができるようになり、バックアップが必要な仮想ディスクのみをバックアップする、粒度の高いバックアップが可能になりました。

下の画面のようにバックアップジョブ作成時には、仮想マシンの”フル イメージ” もしくは”個々のディスク” を選択することができるようになりました。

図3. バックアップジョブ作成時のデータ タイプの選択
“個々のディスク”を選択することで、仮想マシンに構成されている仮想ディスクを個別に選択することができるようになります。

図4. バックアップジョブ作成時のバックアップ ターゲットの設定
3. 粒度の高いバックアップ スケジューリングにより、顧客のニーズに対応
VMware Data Recovery やVDP は、これまでバックアップを開始する時刻を指定することができませんでした。
5.5 では、より多くのアプリケーションやビジネス ニーズに対応するため、分単位でバックアップスケジュールを指定することが可能になりました。

図5. バックアップジョブ作成時のバックアップ スケジュールの設定
4. vCenter Server に依存せずに任意の仮想マシンをリストア
通常VDP による仮想マシンのリストアはvCenter Server に接続されたvSphere Web Client のプラグインを利用して実施しますが、vCenter Server が何らかの理由で利用できない場合、VDP の仮想アプライアンスの Web コンソールを利用して、直接ホストへリストアすることが可能になりました。
素早く仮想マシンをリカバリすることで、サービスのダウンタイム削減を図ることが可能になります。

図6. vSphere Web Client を利用したリストア

図7. VDP 仮想アプライアンスのWeb コンソールを利用した非常時のリストア
5. オフサイトへのバックアップ データの保管と、長期保管への対応
VDP および VDP Advanced は、EMC Avamar をベースとしております。
5.5 では、新たにバックアップデータを外部保管するソリューションとして、”レプリケーション” 機能が提供されます。これによりサービスプロバイダは、Avamar を利用して、VDP からレプリケーションされたバックアップデータをアーカイブするサービスをお客様に提供することができるようになります。また、既にAvamar を実装されているお客様も、同様にAvamar をVDP のバックアップデータをレプリケーションするターゲットとして、指定することができるようになります。
レプリケーションのスケジュールと保持ポリシーは、カスタマイズ可能であり、バックアップジョブのスケジュールと保持ポリシーとは、別に構成することが可能です。

図7. レプリケーションジョブ作成時のデスティネーションの設定

まとめ
VDP のバージョン5.5 では、VMware Data Recovery で提供されていた機能の多くを使用できます。また、これまで提供されていないバックアップジョブの時刻指定やレプリケーション機能が加わわったことにより、より多くのニーズに応えられるバックアップソリューションになっています。

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 で運用管理に必要なコンソールをまとめたランチャーのようなものがつくれそうですね。

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

ネットワーク仮想化 設計ガイドのレビュー その3

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

今回は VXLAN を構成するESXi ホストが、異なるネットワークに 所属する場合について記載する予定でしたが
この間に VMworld 2013 が開催され VMware NSX について新しい発表されましたので、先にこちらに紹介したいと思います。

VMware NSX は、VMware のネットワーク仮想化の機能を担う革新的な製品です。

特に重要なのは、VXLAN を実装するにあたり、物理ネットワークで、マルチキャストの実装が必須でなくなった点です。
特定の相手だけと通信することが可能なマルチキャストはメリットがありますが、それを利用する物理ネットワーク全体に実装するには少々敷居が高い部分もありました。VMware NSX では、これを利用する側で選べるようになっており、マルチキャストモード、ユニキャストモード、混在させるハイブリットモードという柔軟な設計が可能になります。
また、これまで、なぜマルチキャストが必要なのかを考えることで、VMware NSX のマルチキャストフリーの実装を理解しやすくなります。

今回は、下図のネットワーク構成を例にマルチキャストが必要な理由について見ていきます。
VLAN10とVLAN20で分割され、ESXi ホストは L3 越えで接続されています。4つの ESXi ホストで、VXLAN5001、5002という2つの セグメントを構成しています。また、1つの VXLAN 上に存在する仮想マシンは、複数のホスト上に点在しているのが見てとれます。

この VXLAN セグメント内で、仮想マシン同士が初めて通信する時、目的の仮想マシンがどの ESXi ホスト上に存在しているかをマルチキャストを使って確認をしていました。VXLAN セグメント1つにつき、1つのマルチキャストアドレスがアサインされておりますので、通信相手がどこのホスト上にいるかは、このマルチキャストアドレスに問い合わせ(注1)をしていました。
また今回のようなネットワーク構成では、ESXi ホスト間のセグメントが分割されておりますので、ルーティングを担うネットワークデバイスで、マルチキャストルーティングが必要でした。
(注1)各仮想マシンが所属している ESXi ホストの Virtual Tunnel End Point(以降 は VTEP) がマルチキャストアドレスに問い合わせを実施

言い換えると、vCNS 5.1での VXLAN 実装は、仮想マシンがどの ESXi 上に存在しているか把握しておらずマルチキャストに依存していたということになります。
この点を改善し、どの ESXi ホスト上にどんな仮想マシンが所属しているかを、NSXコントローラーで、一元管理する実装にしました。
NSXコントローラーは、各 ESXi ホストへこの情報を伝達することで通信相手の ESXi ホストが特定でき、マルチキャストに頼らない VXLAN 実装が可能となりました。

下図は、VMware NSX for vSphere のコンポーネントを表しています。
赤枠のNSXコントローラは仮想マシンとして提供され、他にもMACアドレス、ARP、VTEP の情報を保持、伝達する役割を担います。