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

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

	(New!) 1. vSphere タグを管理するためのコマンドレット ・vSphere 環境でのタグの管理 ・vSphere オブジェクトへのタグのアサイン ・vSphere オブジェクトからのタグの削除
	(追加) 2. 分散仮想スイッチ(vDS )用コマンドレット ・vDS マイグレーションを容易にする機能 ・プライベートVLAN の管理 ・vDS のポリシー管理 ・vDS のポート管理
	(New!) 3. 仮想マシンコンソール用コマンドレット ・vSphere 及び vCloud Director 仮想マシンのコンソールを開く ・複数のコンソールを同時に開く ・仮想マシンコンソールのURLを出力する
	(New!) 4. vCloud Director 5.5 のサポート
	(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 で運用管理に必要なコンソールをまとめたランチャーのようなものがつくれそうですね。

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

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

今回ご紹介する機能は、「待ち時間感度(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ではこの機能は設定できません）。

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

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

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

「待ち時間感度」機能を有効化し、ある仮想マシンが物理 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.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アプライアンスで利用することも可能になっています。

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

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

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

“個々のディスク”を選択することで、仮想マシンに構成されている仮想ディスクを個別に選択することができるようになります。

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

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

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

　この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がサポートする仮想マシンストレージポリシーについてご説明します。

　前回その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での読み込み、書き込みの動作やホスト障害時の動作についてご説明したいと考えています。

今回は、VMware 製品をオンラインで扱えるハンズオンラボをご紹介させて頂きます。
このハンズオンラボは、VMwareが提供する仮想化・クラウドソリューションを実際に使って稼動する大規模なクラウド型システムです。VMwareの最新の製品や機能、ソリューションをお持ちのパソコンの WEB ブラウザからオンデマンドで体感頂けます。
もちろん無償提供で、日本語でのラボも１８種類ご用意しております。

VMware NSXなど話題の製品からVMware vSphereのパフォーマンス最適化など皆様の関心が高いプログラムを多数ご用意しております。
厳選されたプログラムからお好きなコンテンツをお選びいただけますので、この機会に是非お試しください。

ハンズオンラボ利用の事前準備は非常に簡単です。下記の２種類の手順がございますのでご確認ください。
エンドユーザ様は、こちらの手順を参照し、ユーザ登録してください。

VMware のパートナー様は、Partner Central のアカウントを利用すると便利です。既にPartner Central のアカウントをお持ちであれば、ハンズオン用にアカウントを作る必要はなくこちらの手順よりラボを開始できます。

Partner Central には他にもオンラインで受講できる様々なトレーニングやキャンペーン情報、提案や設計などに役立つ各種資料を取り揃えておりますので、未だPartner Central のアカウントをお持ちでない方はこれを機に作成をお願い致します。アカウント作成手順は、こちらよりユーザ登録してください。

動画でのラボご紹介はこちら（英語のみ）

＜ハンズオンに利用できるデバイス＞
以下のブラウザ(最新版)を最低1つ搭載することが必要です。
Apple Safari、Google Chrome、Mozilla Firefox
ラボを快適に楽しむために、できるだけ最新のCPUを搭載したデバイス(タブレットよりラップトップを推奨)でのご利用をお奨めします。
Internet Explorer および iPad版Safari には対応しておりません。

次回は、ラボをより快適に利用できるポイントをご紹介します。

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

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

VDP とVDPA の機能比較は、以下のようになります。

バージョン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 へのレプリケーションジョブは、”レプリケーション”タブで作成します。レプリケーションジョブは、バックアップジョブに含まれるクライアント（仮想マシン）すべてもしくは、個々に選択することが可能です。

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

2． Microsoft SharePoint 対応エージェント

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

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

3． EMC Data Domain システムへのバックアップ

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

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

Data Domain を追加すると、バックアップジョブ作成時に保存先として、Data Domain Storage を選択できるようになります。

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

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

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

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

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

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

前回、その2では、ストレージポリシーを利用した仮想マシンのSLAの管理についてご説明しました。今回は、Virtual SANの読み書き、及び障害時の動作についてご説明します。

書き込み処理

　許容障害数＝1　で作成された仮想マシンを例にとってご説明します。このポリシーを適応され作成された仮想マシン（仮想ディスク）は、VMDKファイルが2つのホスト内のHDDに分かれて配置されます。

1.　上記ケースでは、ホストH1とH2にVMDKファイルが配置されています。その際、このオブジェクトに対するオーナーが決まります（上記例ではH1）
2.　仮想マシンはオブジェクトオーナであるH1に対し、書き込みの要求を発行します
3.　オブジェクトオーナーであるH1は書き込み要求を二つ作成し、H1 とH2 に対して発行します
4.　各ホストのSSD上で「準備」が完了すると、それぞれ「ACK」を返します（ライトバック動作となります）
5.　オーナーはH1、H2からの「ACK」を受け取るとIO完了を仮想マシンへ通知、仮想マシンでの書き込み処理が完了します
6.　SSD内のキャッシュは数秒間蓄積された後、HDDへディステージされ、SSD領域から削除されます

読み込み処理

上記と同じ仮想マシンでの読み込み処理について説明します。

1.　仮想マシンはオブジェクトのオーナーであるH1に対し、読み込みの要求を発行します
2.　オブジェクト（VMDK）はある容量毎に読み込みを実行するホストがあらかじめ決められています（上記例ではH2）*
3.　H2のキャッシュにヒットした場合はSSDから読み込みます
4.　キャッシュミスした場合はHDDから読み込まれ、SSDにキャッシュされます
5.　読み込んだ内容がH1に返ります
6.　仮想マシンの読み込み処理が完了します

※このアルゴリズムにより、同一領域が複数のSSDにキャッシュされることが無くなり、SSDの利用効率が最大化します。

障害及びホストメンテナンスに関して

　ディスク障害時やホスト障害時の仮想マシンの可用性、さらにはホストのメンテナンス時の考慮事項と具体的なオペレーションについてご説明します。

ディスク障害
　Virtual SANを構成するHDD 1 台が障害を起こした場合、適応されたストレージポリシーに従って仮想マシンの可用性が担保されます。この場合デフォルトである、許容する障害数＝1　以上で作成された仮想マシンに関しては連続稼働が担保されます。

　障害を起こしたHDDがエラー状態でオペレーション継続不能な状態に陥った場合、ホストは即座に復旧処理を開始します。上記の場合は薄青の仮想ディスクに対し復旧処理を開始し、以下のような状態となります。

※”障害を起こしたHDDがエラー状態でオペレーション継続不能な状態”　というのが実はミソです。上記したとおりHDDの障害が永久障害と判断される場合は即時復旧となりますが、例えばHDDの状態が分からない様な場合（疑似障害発生のためHDDを抜いた場合など）、ホストはコンポーネントの一時障害か永久障害か区別が付かないため下記ホスト障害同様、一定時間デバイスが復帰するのを待つ動作に入ります。HDDの復旧処理は重い処理であるため、一時障害で戻ってくるのであればそれを待つアルゴリズムになっているということです。

ホスト障害時
　ホスト障害時の仮想マシンの可用性は、vSphere HA（ホストの可用性）とVirtual SAN（ストレージの可用性）で担保されます。例えば、vSphere HAとVirtual SANを利用した以下のようなクラスタで、一番右のホストが障害でストップしてしまった場合を考えます。

上記で影響を受けるのは、以下のオブジェクトです。
　障害を起こしたホスト上で稼働する仮想マシン
　障害を起こしたホスト内に存在する仮想ディスク
　　薄青・・・3面ミラー構成
　　薄緑・・・2面ミラー構成

この場合、以下のようになります。

1.　障害を起こしたホスト上稼働していた2つの仮想マシンは、レプリカディスクを利用して他のホストで起動する（vSphere HA）
2.　一定時間経過してもホストが復帰しない場合*、ストレージポリシーに従い仮想ディスクの再配置を行う（Virtual SAN）

　※2の一定時間に関しては、ホストの詳細設定VSAN.ClomRepairDelayパラメータで定義されており、デフォルト値は60分となっています。

ホストメンテナンス・削除時
　通常のクラスタ環境同様、ホストをメンテナンスモードに変更します。このオペレーション時、以下のような確認画面が表示されます。オプションは以下の3つがあります。このオプションを利用することにより、管理者の意図した形でかつ安全に、ホストをVirtual SANから取り外すことが出来ます。なお、この作業は、必ずvSphere Web Clientで行ってください。vSphere Clientではサポートされません。

・アクセシビリティの確保（デフォルト）
　該当ホストをVirtual SANデータストアから外しても仮想マシンの動作に問題ない場合、仮想ディスクの待避は行いません。ホストへのパッチ適応や一時的なシャットダウンなど、ホストをメンテナンスしたい時に利用するオプションです。このオプションを選択すると、ストレージポリシーに違反する仮想マシンが出てくる可能性があります。このため、恒久的にホストを削除する場合には適さないオプションです。

・全データの移行
　該当ホスト内の仮想ディスクを他のホストへ待避します。多量のデータ転送が発生するため、メンテナンスモードに移行するまでの時間が長くなります。恒久的にホストをVirtual SANから削除する際に適するオプションです。

・データの移行なし
　仮想マシンの稼働にかかわらず、仮想ディスクのデータ待避を行いませんので仮想マシンが仮想ディスクへアクセスが出来なくなる可能性があります。

まとめ

　3回に渡りVirtual SANについてご紹介を行いました。Virtual SANは安価なホストローカルのストレージを利用する、拡張性に富んだストレージの新機能です。現在PublicBetaという位置づけですが、将来のFullサポートを視野に入れ、是非この段階での評価をご検討下さい。

Virtual SAN Public Beta登録サイト
http://www.vmware.com/vsan-beta-register.html

今回は、オンラインハンズオンラボをより便利に利用するテクニックついて記載します。
ラボの登録がまだの方は、こちらを参照しアカウント作成をお願いします。

テクニック１：マニュアルやコンソールの表示位置を変更
下記の画面キャプチャの通り、アイコンを操作することでコンソールやマニュアルの表示位置を自由自在に移動する事ができます。ディスプレイの画面サイズが小さい場合には特に有効です。

テクニック２：マニュアルを外部デバイスに表示
下記の画面キャプチャの通り、”SPLIT SCREEN” をクリックすると、外部デバイス（タブレット端末など）にマニュアルのみを表示する２次元バーコード及びURLが表示されます。マニュアルを表示させたいデバイスで、２次元バーコードをスキャンするか、表示されたURLに直接アクセスすることで表示されます。これを利用することでディスプレイを全画面で占有でき、オペレーションしやすくなります。

テクニック３：目次の利用
下記の画面キャプチャの通り、目次を利用することで、ラボの内容が把握でき、目的のラボのみを実行することができます。表示されているモジュールは、独立しておりはじめから実施する必要はありません。ラボを開始したモジュールをクリックすることでマニュアルも該当箇所にジャンプする仕組みになっております。

テクニック４：表示言語の変更
ラボの手順にはありませんが、Web ブラウザでオペレーションする日本語対応された製品は日本語での表示が可能です。日本語環境で製品を操作してみたい方におすすめです。
注１）中には日本語表示できないラボも有るかもしれませんが、その場合はご了承ください。
注２）マニュアル内の画面キャプチャは、日本語表示できません。あらかじめご了承ください。

下記は、Firefox での言語表示変更の手順です。
Step1：ブラウザのオプションを選択

Step2：Languages の Chooseボタンをクリック より言語を選択

Step3：AddボタンをクリックしJapanese を追加
Japanese を追加、OKボタンを押し、Option画面を閉じた後、一旦 Webブラウザを閉じます。再度起動すると、日本語表示されているはずです。

テクニック５：ラボを開始する前にその内容を知りたい。
ラボの概要は、現状英語表記となっておりますので和訳したリストを準備しました。
こちらリストより、目的のラボを簡単に探すことができます。
このリストの概要欄に記載された項番は、ラボ内のモジュールに相当しており、それぞれのモジュールの概要、所要時間、難易度が分かるように記載しております。

ラボには、一意のIDが割り振りされております。ラボの概要や、ラボ内で体感可能な製品を確認後、一意のラボIDを下記の画面キャプチャの通り検索して下さい。

VMware製品を導入する上で、どのソリューションが、「どのプラットフォーム上で稼働サポートをするのか」や「ゲストOSとして何をサポートするのか」を調べるためには、互換性ガイドの参照が欠かせません。

今回は、互換性ガイドの調査方法について紹介いたします。

1.互換性ガイドには大きく3つのカテゴリがあります。

ⅰ.システムの互換性ガイド・・・稼働システム/サーバ、サポートゲストOS、サポートホストOS　等の互換性が確認出来ます。

ⅱ.プロダクト互換性ガイド・・・VMware製品のバージョンの組み合わせ、サポートデータベース、アップグレードパスが確認出来ます。

ⅲ.パートナー製品との互換性ガイド・・・パートナー製品との互換性やサポート状況を確認できます。

1つの例として、ESXi5.5でサポートされるMicrosoftのゲストOSについて調べ方をご紹介します。

1.システムの互換性ガイドから「ゲストOS」を選択します。

2.Productとして「ESX/ESXi」、Release Versionとして「5.5」、OS Vendorとして「Microsoft」を選択します。

ここで、必要であれば「OS Family」等の細かな属性を指定することも可能です。

３．最後に「Update and View Results」で一覧が表示されます。

仮想化を導入する上で、稼働プラットフォームやサポートゲストOS等の情報は必須となりますので、是非活用ください。

みなさんこんにちは！
いつもVMware Japan Blogをご覧いただきありがとうございます。
本ブログですが、新製品情報を中心に更新しておりますが、
日頃vSphereをご利用されているユーザ様やパートナー様より

－vSphereにおけるエディション選択のポイントを教えてほしい
－各エディションにおける各機能の設定や操作方法を書いてほしい

等ご意見をいただいております。

ご存知のとおりvSphereには多くの機能があります。
http://www.vmware.com/jp/products/vsphere/compare.html

それぞれの機能が、何の為の機能なのか？どのような使い方をするのか？設定方法は？等
全部把握するには少し時間がかかってしまいますよね。
そこで「押さえておきたいvSphereの基本」と題して
今後vSphereを使用、提案するにあたりまずは押さえておきたい技術的な内容を
約３ヶ月にわたり毎週月曜連載します。

予定している内容は、ストレージ編、ネットワーク編、可用性編として
各分野のエキスパートが執筆担当させていただきます。

「押さえておきたいvSphereの基本」 1月20日(月)から毎週月曜更新！
～ストレージ編～
1.マニュアル操作でストレージ環境を最適化
2.ストレージと連携してパフォーマンスを最大化
3.優先度の定義付けと自動化
執筆担当：青山健二、中村朝之

～ネットワーク編～
1.ホスト単位でネットワークを構築する 〜標準スイッチ編〜
2.スケーラブルで高機能なネットワークを構築する 〜分散スイッチ編〜
3.仮想化環境でL3-L7 サービスを提供する 〜vCloud Networking and Security〜
執筆担当：岩渕友裕、下村京也

～可用性編～
・システム障害に備える仕組み～vSphere HAとFT編～
・物理リソースの有効活用と仮想マシンの最適配置～DRSとリソースプール編～
執筆担当：安齋宗一郎、岡野浩史

これからvSphereを勉強する方はもちろん、長くvSphereに
携わってる方も、ちょっとした技術情報としてご活用いただければ幸いです。
どうぞお楽しみに！

vSphere 5.5 へのアップグレードについて　その１ ～ vCenter Server 編 ～

2014年5月21日に vSphere 4.x（vCenter Server 4.x、および、ESX/ESXi 4.x）のジェネラル サポートが終了となります（詳細は、弊社ウェブサイトのVMware サポートポリシーの販売終了（エンド オブ アベイラビリティ）タブにある製品のライフ サイクル マトリックス（PDF）を参照してください）。

そこで、2回にわたり「vSphere のアップグレード」のドキュメントの参照ポイントについてご紹介します。

アップグレードを計画する上で、最初に行う必要があるのは、既存のハードウェアや関連ソフトウェア(特に vCenter Server や Update Manager で利用しているデータベース) が vSphere 5.5 でサポートされているかを確認する事です。

それぞれ以下のサイトで確認の上、必要な場合は、ハードウェアのリプレイス (32bit CPU を搭載したサーバの場合) や、関連ソフトウェアのアップグレードを行ってください。その後、vSphere 5.5 へのアップグレード作業を開始してください。

• ハードウェアの互換性についての確認（VMware Compatibility Guide）
• 関連ソフトウェアや弊社製品間の相互運用性の確認（Product Interoperability Matrix）

vSphere のアップグレードには次の様な段階的な工程があります。

ステップ１（vCenter Server） のポイント：

• vCenter Server 5.5のハードウェアやソフトウェアの要件については、「vSphere のアップグレード」のドキュメントの「システム要件」を参照して下さい。
• vCenter Server 5.5 でサポートされるインプレース アップグレード元のvCenter Serverのバージョン、vCenter Server 5.5へのアップグレードと同時にシステム移行 (ハードーウェアやオペレーティング・システムの変更の為) をしたい、vCenter Server 5.5で管理可能な ESX/ESXi のバージョン、などを確認するには、「vSphere のアップグレード」のドキュメントの「vCenter Server のアップグレードについて」を参照してください。
• vCenter Server 5.1 から 5.5 へのアップグレードを実施する場合、5.1 から導入されたSingle Sign-On の変更は vCenter Server のインストール、アップグレード、および、運用に影響しますので、「vSphere のアップグレード」のドキュメントの「vCenter Single Sign-On が vCenter Server アップグレードに与える影響 」を参照してください。
• vCenter Server 5.5 には、①Single Sign-On、②Web Client、③Inventory Service、④vCenter Serverの4つのコンポーネントが含まれています。
• 新規インストールもアップグレードもこの順番で行います。同様に、アップグレードの場合も新規インストールと同じインストーラを使用します。そのインストール ウイザードでアップグレードに必要な情報入力が求められます。詳細は「vSphere のアップグレード」のドキュメントの「vCenter Single Sign-On、Inventory Service、vCenter Server、vSphere Web Client のインストールまたはアップグレードに必要な情報」を参照してください。また、インストーラは、全てのコンポーネント (上記の①～④) を1台のサーバに配置する「シンプル・インストール」と、各コンポーネントを異なる複数のサーバに配置する「カスタム・インストール」を提供しています。
• 実際のアップグレードでは、既存環境の Single Sign-On コンポーネントの有無、インストーラーが提供している「シンプル・インストール」または「カスタム・インストール」のどちらを使用したアップグレードを行うかによってステップが異なります。詳細は「vSphere のアップグレード」のドキュメントの「vCenter Server のアップグレード」の該当するサブトピックを参照してください。
• アプライアンス版の vCenter Server を使用している場合、「vSphere のアップグレード」のドキュメントの「vCenter Server アプライアンスのアップグレードと更新」の各サブトピックを参照してください。

ステップ２（Update Manager）のポイント：

• Update Manager　を使用している場合、vCenter Server を 5.5 にアップグレードした後に、Update Manager も 5.5 へアップグレードする必要があります。詳細は「vSphere のアップグレード」のドキュメントの「Update Manager のアップグレード （サブトピック含め）」を参考にしてください。
• Update Manager の使用権はvSphereに含まれており、ESX/ESXi ホストへのパッチ適用、および、アップグレード、仮想マシンの VMware Tools、および、仮想ハードウェア バージョンのアップグレードの管理が可能で、手作業でのパッチ適用やアップグレードを実施する際の人的ミスを回避するのに非常に有益な製品です。今までご使用になられていない場合は、vSphere 5.5 へのアップグレードを期に 、是非、Update Manager の新規導入もご検討ください。

今回は、ステップ１（vCenter Server）とステップ２（Update Manager）の「vSphere のアップグレード」のドキュメントの参照ポイントについてご紹介しましたが、アップグレードに際しては必ず「vSphere のアップグレード」ドキュメントを事前にご一読される事をお勧めします。

次回は ～ vSphere ホスト (ESXi) と仮想マシン編 ～ として、ステップ３からステップ５の「vSphere のアップグレード」のドキュメントの参照ポイントについてご紹介する予定です。

皆様こんにちは！
先週お伝えしたとおり「押さえておきたいvSphereの基本」と題して、仮想環境をご利用するにあたり押さえておきたい機能、ポイントをストレージ、ネットワーク可用性に分けてお伝えしておきます。
初回はストレージ編です。vSphere 環境に限りませんが、ストレージはシステムを稼動させる上で非常に重要なリソースの1つとなるため、ストレージ選定において、容量、可用性、パフォーマンス、コストなどを検討する上で重要なポイントとなります。そこでvSphereが持っているストレージ関連の機能で、どのようなことが実現できるかご紹介していきます。今回は第1回目ということで Standard エディションや標準的に利用できるストレージに関する代表的な機能を３つご紹介致します。

・ストレージ環境を最適化にするファイルシステム～VMFS～
仮想化環境では、物理サーバ（ESXi）とストレージ（ボリューム）の関係が1 : 1となるような形で導入いただくことも可能ですが、m : nとなるように共有ストレージと併せて導入していただくと、システムの運用効率や可用性を高めていただくことができます。

ｍ：ｎのような環境を構成するためには、複数のESXiサーバが同じボリュームに同時にアクセスする必要があります。 FCやiSCSIを使用した共有ストレージ（ブロックデバイス）環境ではVMFSと呼ばれる共有可能なファイルシステム（Virtual Machine File System ）を提供しており、このVMFS でフォーマットされた領域に対して複数のESXiホストからアクセス可能としております。ファイルシステムを複数のESXiホストから共有している以上、整合性を保つ何かしらの”仕組み”が必要になってきますが、VMFSの場合SCSI-2のディスクリザベーションを利用して排他制御を実現しています。

共有ファイルシステムといっても特に難しい設定はなく、それぞれのESXiからマウントするだけとなっておりますので、特殊な設定等はなく簡単に実装できてしまいます。ちなみにこの排他制御、標準のVMFSではLUN単位に動作しますが、規模等によってはさらに効率よく実施するための仕組み/VAAIをハードウエア側(ストレージ)と協力して実装しております。(その点は次回に触れていきます。)その他、ファイルシステムの拡張性ももちろん兼ね備えております。仮想環境に関してはディスク容量の拡張が頻繁に行われる傾向がありますがハード側(ストレージ側)における動的拡張の後VMFSのファイルシステム拡張も動的に行えますので拡張作業も安心ですネ。

パフォーマンスでも様々な工夫がされており、特徴的なのがVMFSのブロックサイズです。
一般的にフィルシステムでフラグメントが多発している状況では、連続領域にファイルが配置されていないためI/Oリクエストが複数ブロックに分断され性能劣化の可能性がありますが、VMFSのブロックサイズ(1MB)は一般的なゲストOSのブロックサイズと比較してかなり大きく、ブロック境界を跨ぐ機会が少ないため、仮にVMFS 自体にフラグメントが発生していても性能劣化の影響が少ないです。このようにVMFSは地味な存在ですが、仮想環境をより安心にご使用していただくため大きな役割を担っております。

・より多くの仮想マシンを配置するための工夫～シンプロビジョニング～
様々なストレージ関連の製品で実装されていることもあり、”シンプロビジョニング”という言葉を聞いたことある方も多いかと思います。 一般的にシンプロビジョニング機能を利用していただくと、実際に利用可能な容量以上のボリュームを予め作成できるようになるため、将来の容量増加の見込みがつかないシステムなどに対し、使用していない容量の初期投資を抑えることが可能になります。

例えば、5年間運用するためにディスクサイズを100GB と算出した仮想マシンを10 台作成するとします。本来であれば、約1TB の容量が必要になりますが、1 年間運用した結果、それぞれの仮想マシンは平均20GB ほどしか消費しなかったとすると、導入時200GB 準備すればよかったことになります。ストレージのシンプロビジョニング機能を利用すれば、計画的な増設が可能になります。また、仮想ディスクをシンプロビジョニング形式で作成することにより、約1TB の容量に対して、ディスクサイズを100GB を想定した仮想マシンは10 台以上配置することが可能になり未使用の割り当て領域が削減され、効率的にストレージ容量を使用できるようになります。

特に仮想環境では導入当初は小さく始め、その後拡張していく傾向があります。vSphereのシンプロビジョニングを使用して、小さく始めて、必要があれば拡張していくという方式も可能となります。このvSphereのシンプロビジョニング機能も、全てのエディションでご使用いただけます。

・ストレージにおける仮想マシン配置の最適化～Storage vMotion～
仮想環境では、仮想マシンの増加等で構成変更が頻繁に発生する傾向にあります。その際仮想マシンのストレージ配置等構成変更が多く発生するのも仮想環境の特徴のひとつです。仮想マシンはストレージ上のボリューム(LUN等)に格納されておりますが、仮想マシンが増えていくと、容量が枯渇したり、IO競合が多く発生する可能性がありますので、将来的に仮想マシンの配置を変える可能性が高いことも考慮する必要があります。そこでvSphereでは仮想マシンの配置変更をオンラインで実施するための機能”Storage vMotion”を提供しております。

Storage vMotionの特徴としては仮想マシンを止めずに仮想マシンを配置しているストレージを変更できます。例えばFCストレージからiSCSIストレージへの移行も可能です。ストレージの容量が足りなくなってきたり、IOの激しい仮想マシンが他の仮想マシンに影響を及ぼす様であれば、IOの負荷分散として仮想マシンの配置変更をオンラインで実施できます。操作も以下のとおり数ステップでできてしまうので非常に簡単です。

Storage vMotionの操作
移行する仮想マシンを選んで「移行」を選択

「データストアの変更」を変更。ここで「ホストの変更」を選択するとvMotionになります

仮想マシンの移行先を選択します。

「終了」を押せばStorage vMotionが開始されます。

仮想環境では複数のシステムが物理的なリソースを共有している関係上、運用フェーズで仮想マシンの配置変更を実施することが多くなるかと思います。このStorage vMotionでシステムを止めずに仮想マシンの配置を変更できることは、私も通常業務で大変助かっております！

今回はvSphere Standard エディションで提供しているストレージに関する代表的な機能を３つご紹介させていただきました。今回ご紹介した機能、VMFSやシンプロビジョニング機能はエディションに関係なく標準的に実装されている機能です。Storage vMotionに関してはStandardエディションから実装されている機能になりますが、どの機能も仮想環境におけるストレージを下支えする重要な機能となっております。次回「押さえておきたいvSphereの基本」ストレージ編第２回目は、～ストレージと連携しパフォーマンスを最大化～するという題目でお送りします。

VMware青山健二/中村朝之

vSphere 5.5 へのアップグレードについて　その2 ～ ESXi 編 ～

全2回でお送りする vSphere 5.5へのアップグレードに関するブログ、その2はESXi編です。
その1 vCenter Server編はこちら。

前回お伝えした通り、vSphereのアップグレードには、以下の段階的な工程があります。
今回は、ステップ3〜5についてお伝えしていきます。

ステップ3（ESXi） のポイント：

• ESXi 5.5のハードウェア要件については、[vSphereのアップグレード]のドキュメントの[ESXiのハードウェア要件] を必ず参照して下さい。特にハードウェアの[VMwareの互換性ガイド]は必ず確認してください。以前のバージョンが動作したから5.5でも動作するだろう、と憶測するのは危険です。その他、ESXからESXiへアップグレードする際の注意点や、必要な事前確認項目の詳細については、[ホストのアップグレードの準備]を参照してください。
• ESXi5.5へのダイレクトアップデートが可能なのは、ESX/ESXi 4.0以上です。ESX/ESXi 3.5からのアップグレードを実施する場合は、1度ESX/ESXiを4.xへアップグレードする必要があります。
• ESXiの構成が比較的シンプル、かつホストの台数が少ない場合には、アップグレードではなく新規インストールのほうが適している場合があります。
• 実際のアップグレードでは、CD/DVD/USBを使用する方法や、スクリプトによるアップグレード、vSphere Update Managerを使用する方法などがあります。それぞれの詳細については、[ESXi5.5のアップグレードのオプション]を参照してください。
• esxcliコマンドを使用してESXiをアップグレードする場合は、VIB、イメージプロファイル、およびソフトウェアデポについて理解している必要があります。これらの詳細については、[VIB、イメージプロファイル、およびソフトウェアデポ]を参照してください。
• ホストが複数台あり、かつクラスタ環境であれば、アップグレード対象のホスト上から仮想マシンをvMotionで移動させ、ホスト上で仮想マシンが稼働していない状態にしてからESXiのアップグレードを実施する、ローリング・アップグレードを推奨します。ローリング・アップグレードを実施することで、アップグレードに伴うダウンタイムを回避することができます。またUpdate Managerを使用すると、自動的にローリング・アップデートが実施されます。

• ESXiのアップグレードが完了した後も、ホストのvCenter Serverへの再接続やライセンスの再適用など、いくつか必要となる事後作業があります。詳細は[ホストをアップグレードまたは移行した後に行う作業]を参照してください。

ステップ4（仮想マシン） のポイント：

• vSphereのアップグレートにおいて、仮想マシン側でアップグレードが必要となるのは、①VMware Tools　と、②仮想マシンのハードウェアバージョン　の2点です。
• ①VMware Tools や ②仮想マシンのハードウェアバージョン の互換性や、その他アップグレードの詳細については、[仮想マシンのアップグレード]を参照してください。
• 必ず ①VMware Tools　のアップグレードを先に実施し、次に ②仮想マシンのハードウェアバージョン をアップグレードしてください。
• これらのアップグレードは、実際には任意ですが、常にESXiと互換性がある中での最新バージョンにしておくことを推奨します。

ステップ5（VMFS） のポイント

• VMFS-3とVMFS-5の相違点については、[VMFS5 の VMFS3 との相違点]を参照してください。
• VMFS-5からVMFS-3へのダウングレードはできません。
• VMFS-5へのアップグレード後は、ESX/ESXi5.0以前のバージョンからはアクセスできなくなります。
• VMFS-3からアップグレードされたVMFS-5データストアと、新規作成もしくはフォーマットされたVMFS-5データストアでは、仕様が異なる部分があります。詳細は[VMFSデータストアのアップグレード] を参照してください。
• アップグレードの方法としては、ストレージを準備し、新しい VMFS-5 データストアを作成して、既存の仮想マシンを Storage vMotion で新しい VMFS-5 データストアへ移行する方法を推奨します。
• VMFS-5へのアップグレードは、vSphere Web ClientやvSphere Clientから、オンラインのまま実施することも可能です。

• 詳細なVMFSのアップグレード方法については、[vSphere Web Client での VMFS5 へのデータストアのアップグレード]、もしくは[vSphere Client での VMFS5 へのデータストアのアップグレード]を参照してください。

vSphere 5.5へのアップデート、第2回はステップ3(ESXi)とステップ4(仮想マシン)、ステップ5(VMFS)についてご紹介しました。vSphere環境のアップグレードは、作業前の事前確認と事前準備が重要です。繰り返しになりますが、アップデートに際しては必ず[vSphereのアップグレード]ドキュメントをご一読ください。

「押さえておきたいvSphere の基本」のネットワーク編として、仮想化環境におけるネットワークの基本を3回に分けてご紹介していきます。第一回は一般的な仮想スイッチの役割と機能及び、vSphere Standardエディションで使用できる標準スイッチ（vSphere Standard Switch 以下vSS と表記）について、分散スイッチ（vSphere Distributed Switch 以下vDS と表記）との差異を中心に解説します。

仮想スイッチは、仮想マシンと物理ネットワークを接続するためハイパーバイザ内に作成されたL2 スイッチとして、サーバ仮想化環境での導入が進んでいます。サーバの仮想化に比例して、仮想スイッチの導入も進んでおり、下記のグラフから既に2012 年の時点でデータセンターにおけるアクセスポート（サーバが接続されるスイッチのポート）数で、仮想スイッチの提供するポート数が、物理スイッチの提供するポート数を上回っていることが分かります。

また、仮想化環境において仮想スイッチは、仮想マシンを最初に接続するネットワーク機器となり、仮想マシンのトラフィックを集約する最初のポイントとなります。このことから、仮想スイッチは単に物理的なネットワークインターフェイスを共有させるだけではなく、下記ネットワーク関連機能の実装に、物理スイッチ以上に最適なポイントということができます。

・ネットワークポリシー（セキュリティ及び帯域制御）の適用
・ネットワーク統計情報の収集
・ネットワークトラフィックのモニタリング

このような背景から、今まで物理スイッチで実装してきた機能の多くを仮想スイッチでも実装してきています。また、パイパーバイザーと同様に集中管理可能であり、x86 ベースの豊富な機能といった仮想化環境特有の特徴を持っています。仮想スッチのアーキテクチャを表したのが下記の図となります。仮想マシンと物理ネットワーク機器の間に入り、ネットワーク機能を提供します。

仮想マシンは仮想NIC を持ち、IP 及びMAC アドレスは仮想NIC に割り当てられます。この仮想NIC が接続されるのが、仮想スイッチ上にある仮想マシン用ポートグループとなります。物理スイッチと接続されるホスト上の物理NIC は、固有のIP アドレスを持たず トラフィックをバイパスするケーブルと同等の役割となります。この他に、ホスト管理、vMotion、iSCSI、NFS、FCoE、Fault Tolerance、VSAN、などのESXi サービスのトラフィックを処理するためにホスト固有のIP を持つVMkernel ポートがあります。

なお、ネットワーク仮想化環境で提供されるVXLAN 論理ネットワーク（NSX では論理スイッチ、vCNS ではVirtual Wire と呼ばれる）は、仮想スイッチ上に仮想マシン用ポートグループとして作成されます。また、VXLAN トンネルを終端するVTEP（VXLAN Tunnel End Point）の実態はVMkernel ポートであり、VXLAN 構成時にVMkernel ポートが自動的にホスト上に作成されます。

VMware vSphere の実装では2種類の仮想スイッチがあります。vSphere Standard エディションで使用可能なホスト単位のネットワークを提供する標準スイッチ（vSS）、vSphere Enterprise Plus エディションで使用可能なデータセンター単位のネットワークを提供する分散スイッチ（vDS）です。ホスト単位でネットワークを構成し、分散スイッチ（vDS） が有する機能を使用する要件がない場合は標準スイッチ（vSS）のみで構成をとることが一般的です。L2 スイッチに求められる基本的なVLAN 機能や、標準的なチーミングを標準スイッチ（vSS）を用いて実装することが可能となります。

VLAN 構成及び設定については、「VLAN configuration on virtual switches, physical switches, and virtual machines (1003806)」、チーミング構成及び設定については、「NIC teaming in ESXi and ESX (1004088)」に解説があります。標準スイッチ（vSS）、分散スイッチ（vDS）の機能については下記表を参照ください。

表の中で、（5.1）等の括弧内に書いてある番号が、新機能として実装されたvSphere のバージョンとなり、水色のセル部分が分散スイッチ（vDS）固有の機能となります。特に管理、トラフィック制御、及びネットワーク仮想化に伴い必要とされる各種機能が分散スイッチ（vDS）に実装されており、下記のような要件がある場合には分散スイッチ（vDS）の実装が適していると言えます。

・複数のホストで使用するネットワークを効率的に管理する
・広帯域ネットワーク(10G 以上)に各種トラフィックを集約して使用する
・ネットワーク仮想化（VXLAN ネットワーク）の展開を予定している

次回「押さえておきたいvSphereの基本」ネットワーク編第2回目は、スケーラブルで高機能なネットワークを構築する 〜分散スイッチ編〜 という題目で、上記ポイントを中心にお送りします。

仮想化によるサーバ統合によりコスト削減を実現し、次のステップとして更なるコスト削減やインフラ管理の効率化のためにプライベートクラウドの実現を模索されているお客様も多くいらっしゃるかと思います。

ここで今一度、クラウドの定義について整理をしてみたいと思います。
米国国立標準技術研究所 (NIST: National Institute of Standards and Technology）によると、クラウドとは以下5つの特徴によって定義(注)されています。

１．オンデマンド・セルフサービス
２．幅広いネットワークサービス
３．リソースの共用
４．スピーディーな拡張性
５．サービスが計測可能であること

上記３．のリソースの共用のように、仮想化によって実現できることがクラウドの特徴として定義されている項目もありますが、仮想化しただけではクラウドの要件を完全に満たすことはできません。
サービス提供者を介さずにオンデマンドでコンピューティングリソースの提供を可能にするために必要な要素が自動化です。また、需要に応じてスピーディーにインフラの拡張/縮小させるためにも自動化が必要となります。
つまり、クラウドを実現するためには自動化というのは欠かせない要素となるわけです。

自動化と一口に言っても、いくつかのフェーズに分けて実装を進めます。
以下の図にありますとおり、クラウドの自動化に向け5つのフェーズに分けて進めます。

本ブログではVMwareが提供するITプロセスの自動化/オーケストレーションを実現するためのツールであるvCenter　Orchestratorを使った自動化の進め方について全5回に分けてご紹介していきます。

Orchestratorは非常に汎用的なツールですので、5つの全てのフェーズで利用可能ですがフェーズ1の自動化、フェーズ2の統合化に絞ってご説明をしていきます。

次回以降は以下の内容を予定しています。

2回目：vCenter Orchestratorのアーキテクチャ
3回目：vCenter Orchestratorを使ってみる（1）-フェーズ1を想定した使い方
4回目：vCenter Orchestratorを使ってみる（2）-フェーズ2を想定した使い方
5回目：vCloud Automation Centerとのインテグレーション

（注）http://www.ipa.go.jp/files/000025366.pdf

「押さえておきたいvSphere の基本」の可用性編として、2回に分けてvSphereのリソースコントロールの機能と可用性を高める機能のご紹介をしたいと思います。

1回目の今回は、vSphere上でゲストOSを運用する際、特定のESXiホストの負荷が高くなった場合、柔軟なリソースコントロールと稼働ホストの分散により、ゲストOSへの稼働に影響を最小限に抑える機能をご紹介します。

利用ケースとして、複数のESXiホストが稼働している状況で、各ホストのリソースを効率よく活用することにより、ゲストOS間のパフォーマンス劣化を防止することやより高い統合率での仮想環境の運用が可能になります。

その他、サーバリソースを追加した場合、新たに追加されたサーバのリソースの効率的な利用などもあります。

仮想マシンが増えてきた場合、それらの仮想マシンの負荷を想定して、どのサーバー上で稼働させればパフォーマンス最適化が図れるかを設計することは困難ですし、仮に設計が出来たとしても、時間の経過と共に負荷状態は変化していきますので常に最適な状態で運用し続けることは困難です。

そこで、非常に強力な機能としてvSphereにはDRS(vSphere Distributed Resource Scheduler)があります。

どのエディションで利用可能かについては「vSphere のエディションの比較」サイトを参照ください。注意点としてDRS機能を有効にするにDRS利用可能なエディションでクラスタを作成する必要があります。

DRSには以下の役割を持っています。

• ユーザーによる、VMパフォーマンス要件の最適化。
• VMのリソースの分離と共有を提供。
• 効率的なインフラストラクチャ活用とリソース管理。
• 包括的なクラスタ管理。

上記役割を満たすためのメカニズムとして以下の機能があります。

• 初期配置/ロードバランシング
• QoSの施行：共有、予約、制限、リソースプール
• ポリシーの施行：アフィニティルール、アンチアフィニティルール
• ホストメンテナンス時の退避

1.初期配置/ロードバランシング

DRSの「初期配置/ロードバランシング」を利用する際に、一番重要な考え方となるのが「VM の要求を満たす」つまり「VMやアプリケーションが問題なく稼働する」と言うことです。

1つ例を示します。

図1のようにクラスタ内の特定ホストのリソース（CPU・メモリ）が不足した結果、そのホスト上で稼働するVMが十分な要求リソースを確保出来なくなった場合、DRSにより不均衡解消に働きます。一方、図2のようにクラスタ内のホストが十分にリソースが確保されている場合、ホスト上で稼働しているVM数に少々のバラつきがあっても、DRSは発動されません。

図1.クラスタ内の特定ホストのリソースが不足した場合

図2.クラスタ内のホストは十分にリソースが確保されている場合

では、どのような方法でホストの「負荷」と「ばらつき」を評価するかというと、構成するホストの負荷（ホストの負荷 = (VMの負荷の合計) / (ホストのキャパシティ)）のばらつきを標準偏差として管理し、この標準偏差の値が、設定されたしきい値（保守的～積極的の5段階で設定）を超えた場合、vMotionを利用して仮想マシンをほかのサーバーに移行させます。

また、vMotionの実行も自動でVMがホスト間を移動するのではなく、管理者側に判断を仰ぐということも可能となっています（可用性ガイド参照）。

2.QoSの施行：共有、予約、制限、リソースプール

各VMの要求リソースリソースのコントロールをうまく行うことにより、VMの稼働を安定させることが可能となります。その方法としてリソースプールという機能がDRSでは設定可能となっています。

リソースプールの主な特徴は以下となっています。

• リソースの分離のための、強力なリソース抽象化機能
• ビジネス要件に応じて、リソースプールを作成可能
• プール内でのリソース共有と、プール間でのリソース隔離

リソースプールをうまく活用することにより、ホスト毎のリソース管理ではなく、クラスタ単位でリソースの管理が行えます。

このリソースプールは「予約」「制限」「シェア値」の設定により柔軟なリソース管理が可能です。

また、それぞれの設定項目に関しては、次のガイドライン（リソース割り当て設定の推奨事項）に従うことにより、仮想マシンのパフォーマンスを向上させるのに役立ちます。
合計使用可能リソースが頻繁に変化することが予想される場合は、[シェア] を使用して、仮想マシン間で適正にリソースを割り当てます。[シェア] を使用していて、ホストをアップグレードする場合、各シェアがより多くのメモリ、CPU、またはストレージ I/O リソースを表していても、各仮想マシンの優先順位は変わりません （同じシェア数のままです）。

[予約] では、ユーザーが使用可能にしたい量ではなく、条件に合った最小の CPU またはメモリの量を指定します。ホストは、仮想マシンのシェア数、需要予測、および制限に基づいて、使用可能な追加のリソースを割り当てます。予約によって表される具体的なリソースの量は、仮想マシンの追加や削除など、環境を変更しても変化しません。

仮想マシンの予約を指定する場合、すべてのリソースをコミットしないでください （10% 以上を未予約にしてください）。システム内のすべての容量が完全に予約された状態に近づくほど、アドミッション コントロールに違反せずに予約とリソース プール階層に変更を加えることが困難になっていきます。DRS の有効なクラスタでは、クラスタの容量またはクラスタ内の個々のホストの容量を完全にコミットする予約によって、DRS が仮想マシンをホスト間で移行できなくなることがあります。次のガイドラインは、仮想マシンのパフォーマンスを向上させるのに役立ちます。

合計使用可能リソースが頻繁に変化することが予想される場合は、[シェア] を使用して、仮想マシン間で適正にリソースを割り当てます。[シェア] を使用していて、ホストをアップグレードする場合、各シェアがより多くのメモリ、CPU、またはストレージ I/O リソースを表していても、各仮想マシンの優先順位は変わりません （同じシェア数のままです）。

[予約] では、ユーザーが使用可能にしたい量ではなく、条件に合った最小の CPU またはメモリの量を指定します。ホストは、仮想マシンのシェア数、需要予測、および制限に基づいて、使用可能な追加のリソースを割り当てます。予約によって表される具体的なリソースの量は、仮想マシンの追加や削除など、環境を変更しても変化しません。

仮想マシンの予約を指定する場合、すべてのリソースをコミットしないでください （10% 以上を未予約にしてください）。システム内のすべての容量が完全に予約された状態に近づくほど、アドミッション コントロールに違反せずに予約とリソース プール階層に変更を加えることが困難になっていきます。DRS の有効なクラスタでは、クラスタの容量またはクラスタ内の個々のホストの容量を完全にコミットする予約によって、DRS が仮想マシンをホスト間で移行できなくなることがあります。

3.ポリシーの施行

DRSでは仮想マシン間の依存性を、ルール設定により制御が可能となっています。

それぞれの動きの特徴と利用シーンを下表でまとめます。

まとめ

以上のように、DRSをうまく活用していただき、効率よい仮想環境の構築・運用をしていただければと思います。

みなさん、こんにちは。

前回に引き続き Orchestrator に関する 2 回目になります。

今まで仮想化環境の自動化はどう行っていますか。 Power CLI 等個別でスクリプトを作り込んでいたのではないでしょうか。個別でスクリプトを作り込む場合、例えば、データベースへの接続や Active Directory への接続等全てを作り込む必要があるので、非常に工数が必要な作業だと思います。

Orchestrator を使うことにより、個別カスタマイズを極力減らして、自動化の恩恵を受けることできます。

Orchestrator の注目度の高さは弊社のブログの PowerCLI のスレッド数と Orchestrator のスレッド数が比べてみると最近、非常に注目度が高いことがわかると思います。

VMware コミュニティへの新規スレッド数 [PowerCLI VS Orchestrator]

[出展元URL]

http://technodrone.blogspot.com/2014/01/vcenter-orchestrator-finally-gaining.html

上記グラフからもわかる通り Orchestrator は利用者数が伸びており、コミュニティでのやり取りも活発になっています。もし、Orchestrator で探している情報があれば、是非、Orchestrator ブログもチェックしてみてください。

VMware Orchestrator Blog (英語)

http://blogs.vmware.com/orchestrator/

また、Orchestrator は既存の PowerCLI を実行することもできるので既存のPowerCLI も無駄にすることなく利用できます。

では、Orchestrator のアーキテクチャに関して以下の項目に沿ってご紹介させていただきます。

1. 利用環境の種類に関して
2. アーキテクチャ(概要)
3. プラグイン
4. ライセンス
5. 保守

まずは、Orchestrator の環境をどのように準備するかに関して説明します。

Orchestrator ですが、以下のとおり、Windows 版とアプライアンス版の 2 つが用意されています。

1. Windows 版
2. アプライアンス版

[Windows 版]

Windows 上に vCenter を Simple  Install することにより Orchestrator も自動的にインストールされます。

Windows 版の vCenter をインストールを行った人は既に多くいるかと思いますが、その方々は既に Orchestrator のインストールも完了していることになります。

但し、Orchestrator のサービスは標準では自動的に起動しませんので、利用する際にはサービス (VMware vCenter Orchestrator Configuration / VMware vCenter Orchestrator Server) を手動で起動 (もしくは、自動的に起動するように設定変更) する必要があります。

[アプライアンス版]

アプライアンス版に関しては、下記の VMware のダウンロードサイトから ova ファイルをダウンロード・展開することにより利用することができます。

https://my.vmware.com/jp/web/vmware/details?productId=352&downloadGroup=VCL-VCOVA_550

OVA ファイルは Windows 環境を用意することなく非常に簡単に展開することが可能です。

vCenter Orchestrator のアーキテクチャの概要に関して示します。

Orchestrator 自身はワークフローの制御を行い、他のシステムとの連携はプラグインで行う形になっています。

その為、Orchestrator 側でのワークフローの作成は連携するシステムが異なっても同一の手順でワークフローを作成することが出来ます。異なるシステムと連携する際には利用するプラグインを変えるだけで利用することができます。

専用の管理画面からシンプルな操作性を実現しておりますので、ワークフローを作成する際には多くの操作をドラッグアンドドロップでワークフローの作成や INPUT や OUTPUT 等の引数の受け渡しを行うことが可能です。

Orchestrator がワークフローを管理して、プラグインを経由して外部システム等と連携を取り、様々なシステムに連携したワークフロー簡単に作成することが可能です。

自動化・統合化の恩恵を最大限に享受するためには他のシステムと連携できるかが非常に重要になってきますが、Orchestrator は非常に多くのプラグインを備えております。

vCenter Server やConfiguration Manger 等の VMware 製品はもちろん、REST や SNMP、SQL、SSH 等の標準プロトコルにも対応しているので様々なシステムと連携することが可能です。

さらに Active Directory や Windows PowerShell 等にも連携しているので、社内システムのワークフローを作成する上でも必要な機能が揃っています。

Orchestrator のライセンスは vCenter Server のライセンスに含まれているので Orchestrator 用に追加のライセンスコストは発生しません。

その為、vCenter のライセンスをお持ちの方はすぐに Orchestrator を試すことができます。

Orchestrator の製品自体の保守サポートは vCenter Server の保守に含まれております。

但し、SDK/API等の開発に関するお問い合わせは通常の保守窓口ではお受けしておりません。その為、SDK/API 関連のお問い合わせが必要な場合や商用環境や本番環境に関しては、別途、SDK Support Program のご加入をお勧めいたします。

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

次回以降は、vCenter Orchestrator の実際の画面をいくつかご紹介していきます。

次回以降は以下の内容を予定しています。

3回目：vCenter Orchestratorを使ってみる（1）- 自動化を想定した使い方

4回目：vCenter Orchestratorを使ってみる（2）- 統合化を想定した使い方

5回目：vCloud Automation Centerとのインテグレーション

～ストレージの能力を最大限に引き出す vSphere～
皆様こんにちは！前回は、vSphereのストレージ機能において比較的小規模環境(約ESXi2～3台)でも使用できる代表的な機能をご紹介しました。一般的に仮想基盤は小規模構成から運用開始することが多く、仮想基盤の運用に慣れていくに伴い、規模を拡張していくことが多いです。規模を拡張するにあたり、物理リソースを単に増やしてしまうとコストメリットがなかなか出しにくくなり、安全に統合率（ESXi上で稼動する仮想マシン数）を上げていくことも考慮していく必要があります。そこで安全に統合率を上げていく際、重要な役割を担うポイントの一つとしてストレージがあげられます。

■仮想基盤特有、ストレージのボトルネックを抑える
前回VMFSと呼ばれるファイルシステムをvSphereでは持っているとご説明をしました。複数のホストからアクセスされているような環境では、データの整合性のためにファイルシステムのメタデータの更新が必要となる場合、排他制御の仕組みが必要になってきます。vSphere 環境におけるメタデータの更新が必要となる代表的なオペレーションとしては、仮想マシンを新規作成、仮想マシンの起動/停止、vMotion、仮想マシンスナップショット取得時、等実行するタイミングになります。vSphere では、排他制御のためにSCSI-2のディスクリザベーションを利用しており、「LUN全体をロック」して他のホストからのアクセスを抑制するという動作になります。非常に短い時間ではありますが、他のホストで稼動している仮想マシンは、一時的にI/O ができない瞬間が発生してしまいます。 (図2)

■サーバ～ストレージ間のパスを整える
最後にESXi～ストレージ間のパスについてご紹介します。
仮想マシンが増えていくことにより、ESXi～ストレージを結ぶ”パス”をより有効に、安全に使用する必要もあります。vSphereでは標準でマルチパス機能を提供しております。もちろん経路障害によるフェイルオーバー動作であったり、IOの振り分け機能も提供しておりますが、Enterpriseエディションにある“”MultiPath”があることにより、ストレージベンダが提供するマルチパスソフトを使用することが可能になります。提供されているマルチパスソフトにより特徴があり、例えばより高度なIOロードバランシングによる帯域の有効活用が可能になったり、経路上の健全性を常に把握し、プロアクティブに障害検知を実施し影響を最小限に抑える等、ESXi～ストレージ間のパスをより整えることが可能になります。また複数のストレージにデータが分散している際、マルチパスソフト側でどのストレージにどのデータがあるのか把握できるので、目的のデータへ一発でアクセスでき余分なIOを発生させない、という特徴をもったマルチパスソフトもあります。ストレージベンダーが提供するより高度なマルチパスを使用することにより、見逃してしまいがちなリソースである「パス」をより有効に活用していただけることも可能になります。

VMware青山健二/中村朝之

「押さえておきたいvSphereの基本」
～ストレージ編～
1.マニュアル操作でストレージ環境を最適化
2.ストレージと連携してパフォーマンスを最大化
3.優先度の定義付けと自動化(Coming Soon!)

～ネットワーク編～
1.ホスト単位でネットワークを構築する 〜標準スイッチ編〜
2.スケーラブルで高機能なネットワークを構築する 〜分散スイッチ編〜(Coming Soon!)
3.仮想化環境でL3-L7 サービスを提供する 〜vCloud Networking and Security〜(Coming Soon!)

～可用性編～
・物理リソースの有効活用と仮想マシンの最適配置～DRSとリソースプール編～
・システム障害に備える仕組み～vSphere HAとFT編～(Coming Soon!)