今回は、仮想環境におけるサーバ移行 (P2V, V2V) の基本的な考え方を、VMware 社が無償提供するツールである VMware vCenter Converter のご紹介を交えながら説明します。

昨今では、仮想化によるサーバ統合は企業の IT インフラにとって欠かせないソリューションの一つとなっており、新規のインフラを物理サーバではなく仮想化基盤を前提に構築するケースも珍しくなくなってきています。このとき、既存の物理サーバ環境をどのように移行していくかは、仮想化を加速させていく上で検討すべき重要なポイントとなります。もちろん、通常の移行作業のように OS やアプリケーションの再インストールやデータ移行などを新しい仮想マシン上で一から行うことも可能ですが、移行作業にかなりの工数と時間、そしてコストがかかってしまいます。

既存の物理環境から仮想環境への移行を効率的、かつ低コストで進めていくために、専用のツールを利用する方法があります。VMware vSphere の環境においても、サードパーティ製のツールの他に、VMware 社が無償で提供する VMware vCenter Converter (以下、vCenter Converter) を使用するケースが多くなっています。

■P2V/V2Vとは？

vCenter Converter の説明に入る前に、いくつかの用語を整理したいと思います。

P2Vとは Physical to Virtual の略で、既存の物理サーバを専用のツールを使って仮想環境上に移行することを言います。これは、物理サーバディスクのバックアップを取得して、異なるハードウェア構成の新しい仮想マシン上にリストアするイメージになりますが、既存の構成は可能な限り維持されます。また、ツールによっては新しい仮想マシンの設定をカスタマイズすることも可能です。

P2V は、サーバ統合の他、テストやトラブルシューティング時、あるいは物理サーバのバックアップを仮想マシンとして取得するといったディザスタリカバリ用途でも使われます。また、ディスクサイズの変更などを目的に利用することもあります。最近では、数百台という単位で P2V を実施して一気に仮想化を進めるケースが多くなってきています。

P2V (Physical to Virtual)

一方、V2V とは Virtual to Virtual の略で、仮想化プラットフォーム間で仮想マシンを移行することを言います。

vCenter Converter では、Hosted タイプのワークステーション製品 (VMware Workstation、VMware Fusion および VMware Player) と vSphere 製品間での移行をサポートしています。

V2V (Virtual to Virtual)

■vCenter Converter 概要

vCenter Converter は、VMware 社が提供する P2V/V2V ツールで、「VMware vCenter Converter Standalone (以下、vCenter Converter Standalone)」 という製品をダウンロードして無償で使用することが可能です(以前は VMware vCenter Server に付属する有償の Enterprise エディションがありましたが、現在は提供されておりません)。

vCenter Converter 製品ページ: http://www.vmware.com/products/converter/

vCenter Converter Standalone

特長として、ウィザードベースの簡単な GUI 操作で利用でき、移行作業の工数を大幅に削減できることが挙げられます。また、例えば VMware Workstation と vSphere 上の仮想マシンのフォーマットは異なりますので、このようなプラットフォーム間で仮想マシンを移行する際の V2V 用途としても使うことができます。

vCenter Converter Standalone の概要

上の図で「Source (移行元) 」として「Third-party Virtual Machines」 「Third-party System Images」 とありますが、このように vCenter Converter では Hyper-V Server 上の仮想マシンや、Acronis TrueImage、Norton Ghost、Symantec Backup Exec System Recovery (LiveState Recovery) といったイメージバックアップソフトのイメージも、インポートして移行できます。

移行元の指定

なお、サポートする Source のリストについては、製品マニュアルやリリースノート等をご確認下さい。

VMware vCenter Converter Standalone 5.5 Release Notes: https://www.vmware.com/support/converter/doc/conv_sa_55_rel_notes.html

■サポートする移行元OS

vCenter Converter Standalone では、移行元の OS として Windows と Linux をサポートしています。以下に、vCenter Converter Standalone 5.1 および 5.5 においてサポートする OS およびバージョンの一覧を示します(実際にご利用を検討される際には、製品マニュアルやリリースノート、互換性リストなどで最新情報をご確認下さい)。

1. Windows

以下は、Windows OS におけるサポート状況です。

Windows: バージョン毎のサポート

2. Linux

一方、以下は Linux OS におけるサポート状況になります。

Linux: バージョン毎のサポート

■サポート及びライセンス

vCenter Converter Standalone は無償でダウンロードしてご利用いただけますが、弊社サポートは付属しておりません。vCenter Server 製品及び SnS をご購入頂いているお客様は、その中に vCenter Converter Standalone 製品のサポートも含まれます。また、単体でのサポートをインシデント単位で購入することも可能です。詳細は以下の KB をご確認下さい。

Support entitlement for VMware vCenter Converter Standalone 5.0.x (2007410) 

また、バージョン毎の製品サポート情報 (製品ライフサイクル) については以下をご確認下さい。

VMware Lifecycle Product Matrix

vCenter Converter Standalone のコミュニティでは、日々利用者によるディスカッションやフォーラムによる Q/A が活発に行われています。製品を利用する際の有益な情報源となりますので、是非アクセスいただければと思います。

Community: VMware Converter Standalone

■vCenter Converter による P2V 移行 の手法

ここからは、vCenter Converter Standalone による P2V 移行の手法をご紹介します。vCenter Converter Standalone には、大きく以下の手法があります。

• ホットクローン
• サードパーティツールによる移行

上記方法で移行できない場合は、他のツールを利用するか、新規構築による通常の移行作業を実施することになります。

1. ホットクローン

ホットクローンは、ターゲットとなる移行元マシンの OS が起動したまま移行処理を行う方法で、専用のサーバ(Windows OS)上に vCenter Converter Standalone をインストールして、そこから移行元と宛先にそれぞれ接続して処理を実行します（「ホット」とは OS が起動している状態を指しています）。その際、移行元マシンにエージェントがプッシュインストールされ、宛先との間でディスクデータのコピーが行われます。

ホットクローン

この手法の特徴として、OS を起動したまま移行が行われることが挙げられますが、当然移行処理中にOS 上でサービスが稼動していれば、データの不整合が発生する可能性は残ります(VSS との連携はサポートします)。このため、実行時にはできるだけファイルに差分が発生しないようにサービス(特にウイルス対策ソフト、インベントリ管理ソフト、DB ファイルをロックするようなサービスなど)を停止させたり、1回目のコピーが終了した時点で発生した差分を「同期」コピーしたりといった処理が行われます。OS は起動していますが、基本的には利用者にサービスを提供したまま移行を継続できるといった機能ではない点にご注意下さい。

この方式では、ドライバに依存しないということが最大のメリットです（ OS が起動している状態では最適化されたドライバが組み込まれていますので、ディスク上のファイルを必ず読み込むことができます）。また、リモートの vCenter Converter Standalone マシン上から複数の物理サーバに対して一元的に移行処理が実行できるため、特に移行対象のサーバ台数が多い場合にも作業をスケールさせることが可能です。環境によっては(十分なネットワーク帯域が確保されているなど)、WAN 越しに移行処理を実行するといったことも考えられます。

なお、既存環境にエージェントがインストールされますが、これによる変更は局所的で、影響はほとんどありません。移行完了後に自動的にアンインストールすることも可能です。

2. サードパーティツールによる移行

これは vCenter Converter Standalone から見れば少し特殊な方法ですが、サードパーティツールで取得したイメージバックアップを仮想環境上に移行することができます。

サードパーティツールによる移行

この方式では、大きく

• vCenter Converter Standalone を介さない方法
• vCenter Converter Standalone を介する方法

があります。

一つ目の方法では、あらかじめ仮想環境上に物理サーバと同じディスク構成の仮想マシンを作成し、ここに通常のイメージバックアップソフトの手順でリストアを実施します(この場合は、vCenter Converter Standalone は関係しないです)。

一方、二つ目の方法では、あらかじめ取得されているイメージバックアップを vCenter Converter Standalone にインポートして、仮想マシンに変換します。

バックアップイメージの選択

これらの方法の違いは、vCenter Converter Standalone を介する場合は処理の一環としてデータのコピー後のカスタマイズ処理などを実行できることです。

この方式をうまく利用すると、例えば静止点が確保できるツールを使ってイメージバックアップを取得しておいてから仮想環境への移行を実施したり、また vCenter Converter Standalone ではどうしてもエラーが出て移行処理を完了できない場合の代替手段にできる可能性もあります。

ただ、サードパーティツールのライセンスコストが追加でかかること、また vCenter Converter Standalone をそのまま使う場合に比べて追加の作業工数がかかる点は、デメリットといえます。

3. 新規構築による通常の移行

先ほど「上記方法で移行できない場合」と説明しましたが、実は通常の移行作業という選択肢は非常に重要です。P2V を行う場合、何がなんでもツールを使った移行を行うことにこだわってしまいがちですが、時にはトラブルの解決にこだわるあまり、大幅に作業工数を超過した上に移行が完了せず、しかもコストが肥大化してしまうなど、本末転倒な結果になる危険性もあります。

仮想環境への移行において、必ずしもP2Vツールを使う必要はない

のです。vCenter Converter Standalone は銀の弾丸ではありません (P2V では古い物理環境からの移行も多いため、構成上の問題や移行後のパフォーマンス劣化問題など、個別に対処しないといけない問題も発生します)。移行計画では、既存の物理環境のアセスメントと事前テストを十分に行った上で、仮に移行が上手く行かない物理マシンが存在した場合の代替手段を計画しておくことが重要です。移行作業全体としてのトータルコストを考慮して、適材適所でツールを活用して下さい。

(参考1) P2Vにおけるコールドクローン

ホットクローンでは移行中に OS が起動しているため、データ差分(不整合)が発生する可能性がどうしても0にはなりません。対象の物理サーバを一旦シャットダウンして、静止点を確保した状態で移行できればこのような不整合は発生しません(このような方法をコールドクローンと呼びます)が、vCenter Converter Standalone では、P2V におけるコールドクローンをサポートしていません。

vCenter Converter でも、以前は vCenter Converter Enterprise の一部として Converter Cold Boot CD というツールが提供されており、CD-ROM から vCenter Converter 起動してコールドクローンする手法がサポートされていました。システムをイメージバックアップするツールと同じように、CD から起動された Windows 上で vCenter Converter のアプリケーションが実行されているイメージになります。

コールドクローン

この手法では、エージェントを送り込むなどの変更がないため既存環境への影響がないこと、また OS が起動していない状態でコピーが実行されるためデータ整合性が保たれることなどのメリットがあります。しかし、移行対象の物理サーバ一台ごとに ISO イメージをマウントして実行するための工数がかかることや、Boot CD 内に移行対象サーバの RAID Card や NIC のドライバがないと実行できないなど、作業の工数やスケーラビリティ、そして互換性の面でどうしてもデメリットや制約が多くなります。

(参考2) V2Vとコールドクローン

次に、V2V の場合のクローン方法についても補足しておきます。vCenter Converter Standalone で V2V を実行する場合、基本的に仮想マシンが実行中の状態では移行処理を開始することはできず、コールドクローンとなります。

V2Vにおけるコールドクローン

ただし、移行対象の仮想マシンを「物理サーバ」とみなして P2V の移行手順を実行することで、ホットクローンを行うことは可能です。

■移行処理の実行時におけるステージとトラブルシューティング

次の図は、vCenter Converter Standalone による移行処理の実行時におけるステージを示しています。移行処理は大まかに3つのステージに分かれており、それぞれ前半で準備処理および移行先での仮想マシンの作成、中盤でディスクデータのコピー処理、後半で仮想マシンの再構成やカスタマイズなどが実施されます。このステップを理解しておくと、仮に途中で処理が停止した場合にも問題をある程度切り分けることができます。

移行処理実行中の vCenter Converter Standalone の動作

一例として、進捗状況が0-5%の間で処理が停止した場合は、ログを確認しつつ移行元、宛先ホストに対してきちんとネットワークの疎通ができているか、移行先のデータストア容量は十分か、などを確認します。一方、処理が中盤まで実行された段階でエラーが発生した場合は、ネットワークケーブルの確認やネットワークの通信状況などを確認し、必要に応じて処理をリトライします。

データ転送にかかる時間は、移行処理を円滑に進める上で重要な要素になります。例えば vCenter Converter Standalone では移行時にディスクサイズの変更が可能ですが、サイズを小さくする場合はファイルレベルのコピー処理となり、サイズを変えない、あるいは大きくする場合のブロックレベルでのコピーより大幅に処理時間がかかります。

デスクサイズの変更

このように、移行処理にかかる時間は様々な要素によって影響を受けますので、移行計画の時点で要件を洗い出し、事前に十分なテストを行うことをお薦めいたします。これは、移行対象の物理サーバの台数が多い場合は特に重要です。

■まとめ

今回は、仮想環境におけるサーバ移行の基本的な考え方を、VMware 社が無償提供するツールである vCenter Converter のご紹介を交えながら説明しました。ＩＴインフラの仮想化、そしてクラウド化を推進する際の旅のお供として、vCenter Converter を道具箱に加えていただければ幸いです。

次回以降は、以下のようなテーマを 予定しています。どうぞお楽しみに！

• vCenter Converter Standalone のインストール
• Windows Server, Linux の P2V
• Hyper-V からの V2V
• サードパーティツールを使った P2V, V2V
• Windows 7 の Fusion/Workstation への移行

　以前のブログエントリで、2013年度のvExpert 受賞者の発表をご連絡させていただきましたが、今回は申し込みが開始されたご案内です。
　
　VMware vExpert は、過去1年間に、VMwareコミュニティー全体に大きく貢献された個人を表彰させて頂く一年更新のプログラムです。ブログや掲示板、Twitterといったオンライン上での貢献の他、社内外への弊社製品技術促進、講演活動、執筆、ユーザ会などで貢献された方を表彰いたします。
　
　vExpert は個人に付与されるものであり、所属組織に対して付与されるものではありません。過去1年のVMwareコミュニティへの貢献や技術普及活動を評価するもので、資格認定ではございませんのでご注意ください。

候補者の方は3つのパスで申し込むことができます。

Evangelist Path：
著書、ブログ、ツール制作者、講演者などで貢献された方が対象となります。

Customer Path：
成功事例、インタビュー記事、事例講演やユーザー会での活動などを行なって頂いた方が対象となります。

VPN (VMware Partner Network) Path：
VMware パートナー企業にお勤めで、技術の習得を欠かさず継続され、技術の普及に貢献された方や講演活動などで貢献された方が対象となります。VMware 社員のリファレンスを推奨いたします。

今年からカテゴリが下記のように分かれており、申し込みは年間を通して可能ですが、四半期毎の終わりに審査・投票がされ、翌四半期に受賞者が発表されます。

• Hybrid Cloud
• End User Computing
• Server Virtualization
• Network Virtualization
• Storage Virtualization
• Security（Fast Track対象者 = 2013年度受賞者のみ）

　申し込み方法は下記いずれかのサイトから自薦または他薦で2013年度の活動について英語で記入する形となります。

申し込みサイト：

Current 2013 vExperts use the 2014 vExpert Fast Track application
（2013年受賞者用Fast Track サイト）：http://bit.ly/1ikZ8hi
2014 vExpert application
（2014年vEXPERT 申し込みサイト）:http://bit.ly/LMJqB5
Recommend a colleague to apply for 2014 vExpert
（推薦者申し込みサイト）: http://bit.ly/1bobFfF

プログラムに関するお問い合わせ先は vexpert@vmware.com となります。
なお、最新情報についてはtwitter アカウント@vExpert （英語）で随時アップデートしていく予定です。

このブログエントリは、VMTN blog の下記エントリを抄訳したものです。詳細につきましては原文　vExpert 2014 applications are open　をご参照ください。

「押さえておきたいvSphere の基本」のネットワーク編として、仮想化環境におけるネットワークの基本を3回に分けてご紹介していきます。第2回は、vSphere Enterprise Plus エディションに対応した分散スイッチ（vSphere Distributed Switch 以下vDS と記載）固有の機能のなかから、標準スイッチ（vSphere Standard Switch 以下vSS と記載）にはない下記3つのポイントについて解説を行います。

・複数のホストで使用するネットワークを効率的に管理する
・広帯域ネットワークに各種トラフィックを集約して使用する
・VXLAN を使用しネットワーク仮想化を実装する

■ 複数のホストで使用するネットワークを効率的に管理する
単一のホスト上に構成される標準スイッチ（vSS）に対し、分散スイッチ（vDS）は、複数のESXi ホストにまたがって構成することができます。

トラフィックの処理を行うデータプレーンは、標準スイッチと同様にプロキシスイッチとして各ホストに配置されますが、管理プレーンをvCenter に配置することでネットワーク構成の一元管理を実現しています。例えば仮想マシン用ポートグループを作成する際、標準スイッチ（vSS）では各ESXi ホスト上で個々に設定を実施することになるのに対し、分散スイッチ（vDS）では、1回設定をするだけで構成が完了します。また、仮想マシンがvMotion によって異なるホストに移行した後も、分散仮想スイッチ（vDS）上では同じポートに接続されていることになり、統計情報やステート情報を引き継ぐことができます。

■ 広帯域ネットワークに各種トラフィックを集約して使用する
10Gbps のNIC を搭載したサーバが普及してきており、vSphere 5.5 からは40Gbps のNIC がサポートされてきています。こうした背景から、ESXi ホストのネットワークを構成する際に、トラフィックのタイプごとに個別の物理リンク（1Gbps）を使用する構成ではなく、1本の物理リンク（10Gbps）のなかに複数の種類のトラフィックを通す構成をとるケースがあるのではないでしょうか。このような構成では、異なる特性を持つトラフィックが単一の物理ネットワークを共有することになるため、トラフィックの特性に合わせた帯域の制御を考慮する必要があります。ESXi ホスト内でトラフィックを制御するための方法として、分散スイッチ（vDS）ではネットワークI/O コントロール（以下NIOC と記載）を提供します。

NIOC は、トラフィックの重要度に応じて使用帯域を制御します。例えば10Gbps の帯域を、NFS, FT, vMotion, 仮想マシンのトラフィックで共有する構成を考えてみましょう。NIOC が無効な環境では、vMotion 実施時に、vMotion のトラフィック（グラフ中の赤線）が他のトラフィックを圧迫します。これにより仮想マシンの提供するサービスに影響が発生し、FT 等遅延に敏感な機能にも影響がでます。

一方、NIOC が有効な環境では、シェア値に基づいて各トラフィックが制御されるため、vMotion 時にも、FT, NFSといったトラフィックは圧迫されることなく、健全なパフォーマンスを維持します。

分散スイッチ（vDS）を活用することで、このように広帯域ネットワークを使用する際に必須となるトラフィック管理の機能を実装することができます。NIOC の詳細については、「VMware® Network I/O Control: Architecture, Performance and Best Practices」を合わせてご参照ください。

■ VXLAN を使用しネットワーク仮想化を実装する
VXLAN を使用し、論理ネットワークを展開する際にも、分散スイッチ（vDS）は必須のコンポーネントとなります。VXLAN の論理ネットワーク（vCNS ではVirtual Wire, NSX for vSphere では論理スイッチと呼ばれる）は、分散スイッチ（vDS）上に仮想マシン用ポートグループとして実装されます。また、VXLAN のトンネルを終端するVTEP（VXLAN Tunnel End Point）は、分散スイッチ（vDS）上にVMkernel ポートとして実装されます。

なお、VXLAN の実装のためには分散スイッチ（vDS） の他に、vCNS（vCloud Networking and Security）もしくは、NSX for vSphere が必要となります。下記はNSX for vSphere の論理スイッチを構成する画面となります。

これらのコンポーネント上で構成をおこなったVXLAN 論理ネットワークが、分散スイッチ（vDS）上に仮想マシン用ポートグループとして動的に展開されます。VXLAN の実装については、ネットワーク仮想化 – VXLAN の設定を合わせてご参照ください。

さらに、vCloud Automation Center といったCMP（Cloud Management Platform）と連携を行うことで、仮想マシンの展開と同時に必要となる論理ネットワークを動的に作成し、分散スイッチ（vDS）上にポートグループを展開することが可能になります。 ネットワークの仮想化及び、SDDC（Software Defined Data-Center）環境において、分散スイッチ（vDS）は必須のコンポーネントとなります。

次回「押さえておきたいvSphereの基本」ネットワーク編第3回目は、仮想化環境でL3-L7 サービスを提供する 〜vCloud Network and Security編〜 という題目で、vCloud Suiteのコンポーネントとして、ネットワークの上位レイヤーのサービスを提供するvCloud Networking and Security（vCNS）についてご紹介します。

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

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

～可用性編～
・物理リソースの有効活用と仮想マシンの最適配置～DRSとリソースプール編～

「押さえておきたいvSphere の基本」のネットワーク編として、仮想化環境におけるネットワークの基本を3回に分けてご紹介しています。最後の第3回は、効率性と俊敏性に優れ、拡張可能な仮想ネットワークとセキュリティを実現するvCloud Networking and Security (以下、vCNS) を解説します。

■ データセンターのネットワークとセキュリティの課題

今日、サーバー仮想化によって仮想マシンを簡単に素早く(数分で)展開出来き、運用効率も飛躍的に向上しました。物理サーバーを調達して構成していた時代からは格段の進歩を遂げています。しかし、いくら仮想マシンを素早く展開して運用効率を上げても、それを取り巻くネットワークやセキュリティ サービスはどうでしょうか？サーバー仮想化によって仮想マシンが動的に構成されるのに、ネットワークは未だに物理的に構成されているため、結果として仮想マシンの柔軟性を最大限に引き出せない現実があります。

例えば、以下のような問題に直面された方は多いのではないでしょうか。

• 必要なネットワークやセキュリティ サービスを準備、設定変更するのに数日または数週間かかる。(ビジネスニーズに応じた迅速な導入、拡張が制限される。仮想マシンは数分で準備できるのに！！）

• 物理ネットワークとセキュリティ境界の制限によって、仮想マシンを動的に移行・構成出来ない。(サーバーリソースの使用率の最適化を防いでいる)

• ネットワーク機器への手動による構成や設定変更、専用アプライアンス等による異なる管理インターフェースを使用する事による効率性の低下。(オペレーションコストの増大)

これらの課題を解決策するにはどうすれば良いでしょうか？
その答えとして、サーバー仮想化のように、物理的なネットワーク機器からネットワーク機能を分離するネットワーク仮想化が考えられます。そのソリューションとして、VMwareはvCNSを提供しています。

 では、vCNSが実現可能なネットワーク仮想化の機能をご紹介します。

■ vCNS主な機能

vCNSはいくつかのコンポーネントから構成されています。

論理ネットワーク(VXLAN) :
L3ネットワーク上にカプセル化された仮想L2ネットワーク作成します。物理ネットワークのセグメントに制限されないため、Clusterや物理ネットワーク境界の制約に縛られない、 柔軟で拡張性に優れたコンピュータリソースプールが作成出来ます。

VXLANの設定方法は、「ネットワーク仮想化 – VXLAN の設定1」、「ネットワーク仮想化 – VXLAN の設定2」をご参照下さい。

Edge Gateway：
仮想アプライアンスとして展開したEdge Gatewayサーバーによって、L3-L7ネットワークサービスを提供します。提供される機能は以下になります。

• ファイアウォール
• ロードバランサー
• VPN (IPsec、SSL)
• ルーティング
• NAT
• DHCP
• HA

例えば、テナント単位やIPセグメントの境界に導入します。

App Distributed Firewall：
ハイパーバイザーレベルで動作するファイアウォールで、仮想マシンの仮想NICレベルでインバウンド、アウトバウンドのコネクションを制御します。vCenterのオブジェクトを使用して設定することが可能なため、管理と運用の効率化が可能になります。

App Distributed Firewallの実装例 は、テックペーパー「Secure Segmentation of Tier 1 Applications in the DMZ」をご参照下さい。

vCloud Ecosystem Framework：
vCNSは、サードパーティ ソリューションを仮想環境にインテグレーションできるようにAPI を提供しています。これによって、vCNSでは提供されていないIPSやWAN最適化機能などのネットワークサービスを仮想ネットワーク環境へ導入することが出来ます。

■ vCNSのメリット

vCNSのこれらの機能は、仮想環境上で必要なときにいつでも簡単に作成することが出来ます。また、仮想マシンに関連付けて設定が行われるので、仮想マシンが物理サーバー間を移動したとしても、再設定を行う必要もありません。VMware vCloud Director や VMware vCloud Automation Center、vCenterといった管理ツールとシームレスに統合されているため、設定の自動化やUIの違いによる管理コストの増大も防ぐことが可能になります。

■ ライセンス、エディション

以前は個別ライセンスでも提供していましたが、現在はvCloud Suiteのコンポーネントとして提供しています。エディションもなくなり、全ての機能がvCloud Suiteの全エディションでご利用できます。
詳しくは、「vCloud Networking and Security の製品ページ(英語)」をご参照下さい。

■ VMware によるネットワーク仮想化の未来

VMwareがネットワーク仮想化を推進する理由は、ネットワーク仮想化がSoftware-Defined Data Center(SDDC)の重要な要素であるためです。そのため、vCNSはSDDCを実現するvCloud Suite のライセンスに組み込まれています。
また、VMware は昨年VMware NSX をリリースしました。こちらもネットワーク仮想化を実現するためのコンポーネントになりますが、vCNSよりも性能、拡張性、機能の向上が行われています。

今後のVMwareのネットワーク仮想化と、その先にあるSDDCの展開にご期待下さい！

「押さえておきたいvSphereの基本」

〜ストレージ編〜
1.マニュアル操作でストレージ環境を最適化
2.ストレージと連携してパフォーマンスを最大化
3.優先度の定義付けと自動化

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

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

プライベートクラウド実現に向けた自動化のニーズ

みなさん、こんにちは。

Orchestrator に関する 4 回目になります。過去の記事を確認したい方は下記のリンクよりご確認ください。

=================================

1 回目はこちら

2 回目はこちら

3 回目はこちら

=================================

今回は、Orchestrator の統合化ということで Orchestrator を使って Active Directory 上のユーザーやグループを操作する場合を例をご紹介します。

今回は単純に Orchestrator から Active Directory 上にコンピュータを登録・削除するという非常に単純な方法をご紹介しますが、他のシステムと連携することでたとえば、[バーチャルマシンを複製] -> [Active Directory へ登録] や [バーチャルマシンを削除] -> [Active Directory 上のコンピュータオブジェクトの削除] 等といった運用上の作業を自動化することが可能になります。

なお、本画面はインターネット上で公開されているハンズオンラボ環境で実施しております。皆様ご自身で検証環境を作ることなく同様の操作を実施することが可能です。是非、本ブログの操作および Orchestrator のその他の機能を触ってみてください。

ハンズオンラボへのログイン操作方法は下記 URL をご確認ください。

登録方法 : http://blogs.vmware.com/jp-cim/2013/12/hol.html

今回、ご紹介する環境は ハンズオン ID : “HOL-SDC-1307 – vCloud Automation Solutions” 上で実施しておりますので、皆様も同様の動作を環境を構築することなくご確認いただくことが可能です。

1-1. ハンズオン環境にログインして、デスクチップ上の Orchestrator 管理画面を開きます。

1-2. ログイン画面が表示されたら、[password] 欄に “vcoadmin” と入力して、[Login] ボタンをクリックします。

1-3. Orchestrator 管理画面にログインできたら、左ペインの “Workflow” タブをクリックします。その後、[admin@vcac-w8-01a] – [Library] – [Microsoft] – [Active Directory] – [Computer] と順番にクリックします。

1-4. “Create a computer in a group” を右クリックして、”Start workflow” をクリックします。

1-5. [Parent group for the new computer] 欄の “Not set” をクリックします。

1-6. [Filter:] 欄に “Computers” と入力し、”Computers” を選択し、[Select] ボタンをクリックします。

1-7. [Name for the new computer] 欄に “VCOocks” と入力し、[Submit] ボタンをクリックします。(“VCOrocks” はコンピュータ名です。適宜、変更して入力していただくことも可能です)

1-8. ワークフローが完了したら、右上の最小化ボタンで Orchestrator 画面を最小化します。

1-9. デスクトップ上の “Active Directory” 管理画面をクリックして、開きます。

1-10. “Active Directory” 管理画面が表示されたら、左ペインより [corp.local] – [Computers] と順番にクリックします。手順3 – 7 で追加した “VCOocks” コンピュータが作成されていることが確認できます(もし、違う名前でコンピュータを登録されている場合、異なる名前のコンピュータ名が表示されます)。

1-11. コンピュータオブジェクトが追加できたことを確認できたら、右上のバツボタンで “Active Directory” の管理画面を終了します。

2-1. 最小化している Orchestrator の画面を開きます。(Orchestrator 管理画面を閉じている場合は再度、起動・ログインします)

2-2. 左ペインの “Workflow” タブをクリックします。その後、[admin@vcac-w8-01a] – [Library] – [Microsoft] – [Active Directory] – [Computer] と順番にクリックします。

2-3. “Destroy a computer” を右クリックして、”Start workflow” をクリックします。

2-4. [Computer to destroy] 欄の “Not Set” をクリックします。

2-5. [Filter:] 欄に “VCO” と入力し、”VCOocks” を検索できたら選択し、[Select] ボタンをクリックします。(異なるコンピュータを登録した場合は異なる名前のコンピュータを検索して選択します)

2-6. [Computer to destroy] 欄に “VCOrocks” が選択できたら、[Submit] ボタンをクリックします。

2-7. ワークフローが終了したことを確認し、画面右上の最小化ボタンをクリックします。

2-8. デスクトップ上の “Active Directory” 管理画面をダブルクリックして、管理画面を開きます。

2-9. 左ペインの [corp.local] – [Computer] をクリックして、登録されていた “VCOocks” コンピュータオブジェクトが削除されていることを確認します。

いかがでしたでしょうか。無事、コンピュータアカウントの追加と削除が行えましたでしょうか。

今回は単純な Active Directory のコンピュータオブジェクトの追加・削除ですが、vCenter や他のシステム (PowerShell や ssh はもちろん、REST や SOAP 等) と連携してワークフローを作成することにより多くのメリットを受け取ることが出来ます。

是非、身の回りの毎日・毎週・毎月行っている業務を思い出して、日々の繰り返し業務を自動化できるかを考えてみてください。

次回は最終回で、以下の内容を予定しています。

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

ネットワーク仮想化と VMware NSX は統合により視認性を大きく改善する

※この記事は、2013年10月15日の Brad Hedlund による記事の翻訳版です。

記事の概要

これまで VMware NSX に関する議論の多くは、優れた俊敏性と、完全に自動化されたネットワーク プロビジョニングという VMware NSX の主要な特性に関するものでした。仮想マシンと同等のスピードおよび可搬性を備え、完全な機能を持った L2 ～ L7 仮想ネットワークをソフトウェア コンテナ内に作成する機能です。これは非常に重要な機能ですが、同じくらい重要な機能がほかにもあります。それは、ネットワーク仮想化と VMware NSX が Software-Defined Data Center 時代の運用における視認性を大きく変革するという点です。

統合による新たな視認性

ネットワークとコンピューティングの統合は、別々でありながら密接に関連するこの 2 つのサービスを安定して共存させる理想的なアーキテクチャによって実現されています。まだあまり注目されていませんが、この統合は本質的に視認性を向上します。理由は簡単で、プラットフォームが 1 つになることで、同期された統合ビューで複数のサービスとそれらの関係をリアルタイムで確認できるためです。1 か所から確認できるようになることで、これまで考えられていた以上に高度なアプリケーションと運用ツールを実現できます。

VoIP 端末により実現した音声とデータの統合、および接続制御のソフトウェアを例として考えてみましょう。データ端末と音声利用者の関係を 1 か所で確認できるようにすることで、マルチメディア、場所情報、在席情報などの充実したサービスを利用したコラボレーションが実現しました。音声 / データの統合によるメリットは最終段階にならないとわからないかもしれませんが、インフラの統合では初期段階で明らかなメリットがあります。

VMware NSX によって実現するネットワークの仮想化は、異なるサービスでありつつ密接に関連している複数の仮想サービス （仮想コンピューティング、仮想ネットワーク、および物理ネットワーク ファブリック） の統合につながります。俊敏性に優れ、自動化されたネットワーク プロビジョニングの初期段階のメリットは明らかであり、とても重要です。ただし、繰り返しますが、あまり目立ちませんが同様に重要なメリットである、サービスの視認性の向上も実現するでしょう。ネットワーク仮想化と VMware NSX を使えば、単一のプラットフォームで、アプリケーション環境、アプリケーションが使用する完全な L2 ～ L7 ネットワーク サービス、およびサーバが転送される物理ネットワーク ファブリックを詳細にわたって確認することができます。

VMware NSX は仮想コンピューティングを仮想および物理ネットワークと統合する

この統合と視認性を実現する理想的なプラットフォームは、ハイパーバイザー、およびそれに対応するプログラム可能なソフトウェア仮想スイッチです。ハイパーバイザーは、仮想マシン （アプリケーション）、仮想ネットワーク、物理ネットワーク、およびストレージ アクセスのちょうど中間に位置付けられます。VMware NSX は、ハイパーバイザー内でこの戦略的な位置付けを十分に活用します。また、統合制御ソフトウェアを通じて、個々のアプリケーション、それらが利用する L2 ～ L7 ネットワーク サービス、および物理ネットワーク間の流動的な関係を、NSX では 1 か所からまとめて測定および確認できるようになります。

シンプルな例として、ロード バランシング サービスに関連付けられた N 台の仮想マシンの階層からなるアプリケーションを考えてください。単一の API で次のことができます。各仮想マシンと対応するロード バランサの物理的な場所を確認できます。ロード バランサと各仮想マシン間のトラフィックを測定してプロファイルを作成できます。ロード バランサと各仮想マシン間の物理ネットワーク接続の問題を検出してフラグを付けることができます。仮想ネットワーク ポート上の構成エラーを検出してフラグを付けることができます。影響があるインスタンスを特定できます。ロード バランサ インスタンスの負荷と健全性を確認できます。ポート カウンタとフル パケット キャプチャを利用しながらトラフィックを監視できます。ベースラインまたはテンプレートとの比較をこれらすべての特性について行えます。アプリケーション特有のビューを、関連するアプリケーションの所有者とネットワーク運用担当者に提示できます。包括的で目的を絞った視認性により、ノイズの中からより多くのシグナルを抽出できるようになります。

トラブルシューティング

物理ネットワークの健全性ヒートマップ

統合によりトラブルシューティングの基盤も強化されます。相互に依存する複数のドメインを単一のプラットフォームで確認できると、問題があるドメインを迅速に識別するための出発点とすることができます。VMware NSX はハイパーバイザー内で理想的な場所に配置されています。相互に依存する 2 つのドメイン、つまり仮想ネットワークと物理ネットワークの重要な接点です。VMware NSX では、完全な L2 ～ L7 仮想ネットワークの健全性と状態を確認できます。また、VMware NSX はすべてのハイパーバイザー仮想スイッチおよびゲートウェイ間の物理ネットワーク （トンネル健全性プローブあり） の健全性を常にテストしており、API クエリと NSX Manager のヒート マップを通じてリアルタイムで確認できます。

たとえば、物理ネットワークの問題が原因で接続の問題が発生している場合、VMware NSX は直ちにこれを検出し、影響のあるハイパーバイザーと仮想マシンを特定できます。トラブルシューティング対象のドメインを迅速に特定し （物理環境）、問題の範囲を調査して、作業に着手するためのより実用的な情報を得られます。また、接続の問題が仮想ネットワーク内だけに存在する場合を考えます。ACL またはファイアウォール ルールの構成ミスが原因の可能性があります。VMware NSX はこれが物理ネットワークの問題ではないことを直ちに識別します。仮想ネットワーク （TraceFlow & Port Connections） を通じてトラフィックを挿入 / 追跡するツールを提供し、仮想スイッチおよびトラフィックをドロップしている ACL を特定します。

仮想ネットワーク内のブロックされているフローの統合管理

VMware NSX for vSphere のブロックされているフローの監視

例として （上図）、VMware NSX for vSphere で提供される Flow Monitoring ツールでは、仮想ネットワーク内でファイアウォール ルールが適用されているすべてのフローに対するグローバルなビューを提供します。これにより、トラブルシューティングの際に、仮想ネットワークのどこかでブロックされた個別のフローに関する詳細情報 （リアルタイムまたは履歴） を確認できます。詳細情報には、関連するアプリケーションのタイプ、ソースとターゲット、時刻、および特定のルールが含まれます。この情報はいつでも数クリックで確認できます。

この分析機能はすべて、プログラム可能な単一のインターフェイスである NSX API を通じて利用できます。VMware はすでに既存の運用ツールを拡張して、vCenter Operations Manager や Log Insight などで NSX API を活用できるようにしています。また、パートナーはすでに NSX との連携に着手し、優れたツールを拡張して、仮想ネットワークと物理ネットワークを可視化し、関連付けようとしています。いくつか例を見てみましょう。

トラフィック フローを可視化し、仮想ネットワークと物理ネットワークを関連付ける

ハイパーバイザー内では、VMware NSX は仮想コンピューティング レイヤーのアプリケーションに隣接しており、フローのすべてを直接確認できます。また、NSX がキャプチャしたフロー データのすべては、標準インターフェイス （IPFIX） を使用して監視ツールにエクスポートできます。この監視ツールは標準フロー データを物理ネットワークから収集することもできます。また、任意の標準インフラストラクチャ ハードウェア上で仮想 / 物理フローを関連付けて統合ビューに表示できます。

NetFlow Logic および Splunk を使用した仮想から物理へのトラフィック フローの視認性

たとえば、VMware NSX は NetFlow Logic および Splunk （上図） と容易に連携できます。VMware NSX および ToR （Top of Rack） スイッチから取得した標準 IPFIX と NetFlow のエクスポートを単純に集約して関連付けることで、仮想ネットワークと物理ネットワーク上を流れるトラフィックを可視化します。トラフィック量が多いフローを確認できます。トラフィック ソースを選択して、そのやり取りの仮想ネットワークと物理パスを確認できます。たとえば （上図）、やり取りを 1 つ選択して、そのトラフィックの仮想と物理の詳細 （例： ソース VM IP アドレス > ソース Hypervisor IP アドレス > ソース ToR スイッチと入力ポート > 仮想ネットワーク VXLAN ID > ターゲット ToR スイッチと出力ポート > ターゲット Hypervisor IP アドレス > ターゲット VM IP アドレス > Tx/Rx 接続状態 > 時刻ごとの使用帯域 を確認できます。

物理および仮想ネットワーク トポロジを可視化して関連付ける

VMware NSX は、任意の仮想マシンの物理的な位置および接続されている完全な L2 ～ L7 仮想ネットワーク トポロジを常に認識します。また NSX は、ハイパーバイザーの運用状態、およびNSX アプライアンスのネットワークの健全性と統計情報を確認できる標準 SNMP インターフェイスを提供します。NSX API および SNMP を介してこの情報に容易にアクセスできるので、物理ネットワーク管理ツールが、仮想ネットワークとその運用状態の詳細情報を取得するのは非常に簡単です。

物理および仮想ネットワーク トポロジを可視化して EMC Smarts と関連付ける

例として、EMC Smarts を使えば、VMware NSX API と連携して、物理ネットワーク トポロジを VMware NSX 仮想ネットワーク トポロジと組み合わせて関連付け、依存関係のマップを作成することができます。上図の例では、ラックの一番上にある特定のスイッチに問題が発生している場合、影響があるテナント、アプリケーション、仮想ネットワーク、およびハイパーバイザーのマップを確認できることがわかります。別の例として、詳細にわたって仮想 / 物理ネットワークの可視化および関連付けを行う Riverbed 社の Cascade ソリューションも開発されています。

包括的なダッシュボードと Log Insight による分析

VMware NSX は多くの運用データを生成します。それらはすべて標準の Syslog データを使用してエクスポートできますし、NSX API を使用してもアクセスできます。例として、VMware Log Insight という複数の VMware プラットフォームにまたがるマシンのデータを集約して分析することができるソリューションを使うと、VMware NSX のデータも分析することができます（下図）。

Log Insight を使用した VMware NSX の運用データの視認性

VMware NSX は、vCenter Operations Manager （下図） や Log Insight （上図） などの既存の VMware の運用ツールと密接に連携します。これによりさまざまな機能 （パフォーマンス分析とアクセス プロセスのリアルタイムでの関連付け、仮想マシンと仮想ネットワーク インターフェイスの統計情報、物理ネットワーク インターフェイスの統計情報、ネットワークの健全性、物理ネットワーク フローのログ、予測的な根本原因分析の機能など） が提供され、任意の標準ネットワーク ファブリックにまたがって問題を迅速に診断するための、完全な運用上の視認性が得られます。これらの強力なツールは、コンピューティング チームとネットワーク チームが共同で利用することになると想定しています。

vCenter Operations Manager による包括的な監視と根本原因分析

VMware vCenter Operations Manager も、VMware NSX API でアクセスできる豊富なネットワーク情報を利用できるように拡張されました。

VMware vC Ops を使用した全体的な仮想インフラストラクチャの視認性と根本原因分析

VMware NSX の統合は vCenter Operations Manager （上図） に組み込まれており、NSX のネットワークの視認性のデータは、既存のコンピューティングおよびストレージの運用データと統合されます。それにより、仮想インフラストラクチャ全体の状態を確認し、トラブルシューティングに利用できる、単一の包括的なツールが形成されます。たとえば、ハイパーバイザーの CPU、ストレージ、ネットワークの健全性ヒート マップなどが、通常のしきい値を動的に認識し、異常を検知します。また、詳細なメトリックまで掘り下げて、根本原因分析のためにイベントを関連付けます。

視認性と機能による大きな変革

VMware NSX により実現した全体的な視認性は、それ自体が重要なメリットといえます。ただし、遠隔監視や L2 ～ L7 ネットワーク サービスなどのハイパーバイザー仮想スイッチ レイヤーでの高度な機能と組み合わせると、以前は考えられなかったツールが提供されるようになります。それが、Software-Defined Data Center にメリットをもたらす運用機能の変革の始まりとなります。また、既存の監視ツール （IPFIX、sFlow、ERSPAN、SNMP、Syslog） は VMware NSX 用に拡張され、パケットに入口となるソース （ハイパーバイザー仮想スイッチ） で収集された、全体的な視認性に関する情報を取得します。ソースは、仮想環境で測定およびキャプチャするためのより重要な場所です。

パケット検査から詳細なアプリケーション セマンティクスへ

数十年間、ネットワークの運用では、「視認性」 についてはパケット ヘッダの検査で十分でした。パケット ヘッダを検査するネットワーク スイッチがセキュリティ ポリシー （ACL） や QoS （サービス品質） の役割を果たしていたのでしょう。あるいはトラフィックを識別するために監視ツール上のパケット ヘッダを調査している運用担当者がその役割を担っていたのかもしれません。どちらにしろ、ポリシーと視認性は、パケット ヘッダに含まれる基本的な情報と同じくらいの重要性しかありませんでした。たとえば、トラフィックが正当なアプリケーション プロセスからのものか、問題または異常のあるプロセスからのものかは識別できませんでした。インスタンスに提供されたトラフィックが、実際に健全なアプリケーション プロセスで使用されたものかどうかはわかりませんでした。ユーザー名、組織、アプリケーションのバージョン、ライフサイクル （開発 / テスト / 本番） などは識別できませんでした。物理ネットワークにおけるパケット ヘッダの 「視認性」 には、（設計上でも） アプリケーション環境に関して有用な詳細情報は含まれていませんでした。

対照的に、VMware NSX は、完全な L2 ～ L7 仮想ネットワークとハイパーバイザーの統合を通じて、仮想コンピューティング レイヤーにあるアプリケーション セマンティクスとメタデータに対する詳細な視認性を確保します。

アプリケーション固有で ID に対応した視認性 （アクティビティの監視）

VMware NSX によるアプリケーションと ID に対応したネットワーク アクティビティの監視

VMware NSX for vSphere は、アプリケーションに関連するネットワーク アクティビティを、仮想マシン上の個々のプロセス レベルで監視できます。仮想マシンは、トラフィック （上図）、ユーザー ID、組織グループ、アプリケーションのバージョン、所有者権限、オペレーティング システムなどの情報を送受信しています。たとえば、特定のアプリケーション プロセスに送信されたトラフィック、特定のマシン セットに向けたトラフィック、特定の Active Directory グループから送信されたトラフィックに焦点を絞ることができます。仮想コンピューティングに深く組み込まれた仮想ネットワーク プラットフォームだけが、このような、アプリケーションに関連した視認性を容易に提供できます。監視は始まりにすぎません。このレベルの視認性は、より高度なアプリケーション テンプレート、振る舞いに関するプロファイル、およびセキュリティ ポリシーを作成するために使用できます。

アプリケーションに関連する視認性はたしかに素晴らしいものですが、特定の仮想マシンが送信 / 受信している任意のトラフィックまたはすべてのトラフィックを迅速に確認する必要がある場合があります。パケット ヘッダの検査は、この目的ではもちろん現在でも有用なツールで、VMware NSX を使用することによる制約はありません。実際、ハイパーバイザーでの位置付けにより、NSX は任意の仮想マシンのステートフル トラフィック フローを、仮想ネットワーク インターフェイス （仮想 NIC） で直接、リアルタイムで選択的に分析できます。

仮想マシンのネットワーク インターフェイスでの直接的なリアルタイムのステートフル フロー監視 （Live Flow）

仮想マシンの仮想 NIC ごとの Live Flow の視認性

たとえば、VMware NSX for vSphere では、組み込みツールである Live Flow による監視機能 （上図） が提供されます。これにより、単純に任意の仮想マシンのネットワーク インターフェイスを選択して、（リアルタイムで） すべてのフローとその状態の概要を確認できます。対象の仮想マシンにおけるすべてのフローの完全な詳細情報を確認できます。詳細情報には、各フローの方向、フローごとのバイト数とパケット数、各フローで許可されているファイアウォール ルール、IP アドレスとポート番号、および各接続の状態が含まれます。追加の手順は必要ありません。リモート ツールへのフル パケット キャプチャの構成や、自分の仮想マシンに割り当てられる IP アドレスの調査は必要ありません。対象のネットワーク トラフィックの視認性に対するシンプルなタスクのために、VMware NSX はシンプルなツールを提供します。この情報はいつでも数クリックで確認できます。

フル パケット キャプチャが必要な場合は、任意の仮想マシンの仮想ネットワーク ポートから直接リモート監視システムに対して、SPAN / RSPAN / ERSPAN を使用してポート ミラーリングを選択的に確立できます。また、物理ネットワーク上のポートからのパケットをキャプチャする必要がある状況では、現在は多くの管理ツールが Wireshark などの VXLAN のフィルタを提供しており、それによりトンネル パケットを容易にデコードできます。

セキュリティ ポリシーとコンプライアンスの視認性

もちろん、「視認性」 とはネットワーク トラフィックを確認して把握することだけではありません。トラブルシューティングは、ネットワークの仮想化によりもたらされる包括的な視認性からメリットを享受できる多くの重要な分野の 1 つです。例として、コンプライアンスのためにセキュリティ ポリシーの監査を行うタスクを考えてください。このために、VMware NSX for vSphere は Service Composer と呼ばれる組み込みツールを使用して、リアルタイムのアプリケーション セキュリティ ポリシーを確認し、定義するための代表的な手段を提供します。

セキュリティ ポリシーとアプリケーションの分離に対するリアルタイムでの統合された視認性

VMware NSX Service Composer を使用したアプリケーションのセキュリティ ポリシーの視認性

Service Composer の [Canvas] ビューには、作成したセキュリティ グループ、各グループのオブジェクト、および各グループに適用されたサービス （ステートフル ファイアウォール分離など） が表示されます。たとえば （上図）、PCI アプリケーションのセキュリティ グループがあり、IT アプリケーションからの厳格な分離ポリシーが構成されています。これは、PCI コンテナのファイアウォールのアイコンをクリックするだけで確認できます。この分離は、ハイパーバイザー内の VMware NSX 分散配置されたカーネルのステートフル ファイアウォールにより適用され、中央のビューにリアルタイムで表示されます。

将来的な展望： 測定とインテリジェントな最適化

今日のプラットフォームの機能、統合、および視認性の堅牢な基盤は、ソフトウェアにより完全に実現されています。さらなる機能、また任意の標準ハードウェアやネットワーク アーキテクチャ上でそれを実現するスピードに期待しています。

End-to-End の遠隔監視

運用の視認性を最大限実現するための重要なツールは End-to-End の測定です。あるアプリケーション トラフィックのソースと目的を確認することに加え、特定の期間における、 アプリケーションのパフォーマンス プロファイルと振る舞いについて知りたい場合があります。真の End-to-End の遠隔測定法とは、可能な限りデータ ソースに近づいて測定することです。その点で、VMware NSX はトラフィックのソースで理想的な位置にあります （仮想コンピューティング レイヤーに深く組み込まれている）。また、ハイパーバイザー内でフロー ベースの仮想スイッチで遠隔監視を実装しています。つまり、任意の 2 つの端末間における任意のやり取りは、直接ソースとターゲット （ハイパーバイザー仮想スイッチ） で説明、測定、およびマークすることができます。

Network DRS

ハイパーバイザーの VMware NSX 仮想スイッチは、カーネル ファスト パス内の L2 ～ L4 ネットワーク サービスに対応しています。レイヤー 2 スイッチ、レイヤー 3 ルーティング、双方向のステートフル ファイアウォール、ACL、QoS などがすべて、x86 マシンの速度で、ハイパーバイザー カーネル内でローカルで処理されます。前述したアプリケーションの認識と End-to-End の遠隔監視とを組み合わせることで、ワークロードの配置をインテリジェントに最適化し、アプリケーションで可能な最高のパフォーマンスを実現するのに必要なすべての情報と機能が得られます。

Network DRS： ネットワーク対応の最適なワークロード配置

たとえば、マルチ ティア アプリケーションにおいて、レイヤー 3 ルーティングとファイアウォール セキュリティにより分離された 2 つの仮想マシン間の重要なトラフィックを、End-to-End の遠隔監視により測定する場合を考えてください。この情報により、仮想コンピューティング レイヤーは、最適化されたパフォーマンスとそのトラフィックを物理ネットワークから削除するというメリットを実現するために、2 つの仮想マシンを同一のハイパーバイザーに移行することを決定できます。つまり最適な配置は最適なパス（経路）より優れています。

物理ネットワーク接続の問題が特定のハイパーバイザー間の問題を引き起こす別のシナリオを考えてください。VMware NSX は常に物理ネットワークの健全性をテストしているので、問題を迅速に発見できるだけでなく、影響があるハイパーバイザー、ネットワーク サービス、および仮想マシンを特定できることを思い出してください。物理ネットワークの課題に対応しながら、仮想コンピューティング レイヤーがこの情報を活用して、影響のある仮想マシンを、影響のない別のハイパーバイザーにプロアクティブに移行することができます。End-to-End の遠隔測定法はアクションが実際に役に立ったかどうかをあとで検証できます。

エレファント フローの検出と応答

Network DRS の別の例は、VMware NSX のフロー ベースのハイパーバイザー仮想スイッチ内の End-to-End の遠隔監視が、特定のフローを 「エレファント」 として検出し、プロファイリングするシナリオです。「エレファント」 とは、寿命は短いが重要な小さなフロー「マウス」を、無意識に踏みつける、寿命の長い大きなフローのことです。全体的に、確認対象となる可能性があるフローが多いので、VMware NSX は、この遠隔測定法がハイパーバイザー仮想スイッチ全体に分散されるように理想的に配置されています。各ハイパーバイザー仮想スイッチは自身のローカル トラフィックの一部を測定します。エレファント フローが検出されたら、タグ付けされ、処理されます。処理の内容は、重要な小さなフローから離れるように移行する、視認性とネットワーク ファブリックのポリシーのために QoS のマークを適用する、などです。

任意のハードウェア、クラウド、およびハイパーバイザーに対する視認性

もちろん、ここまで話したことはすべて、ソフトウェア プラットフォームである VMware NSX により実現されます。VMware NSX は、任意のネットワーク ハードウェア、任意のハイパーバイザーで動作し、任意のクラウド ポータルからプロビジョニングされ、任意のアプリケーションに対応するように設計されています。ハードウェアに依存しないソフトウェアにより、運用の視認性とツールの機能の両方の一貫性が保たれ、インフラストラクチャのライフサイクルを通じてさまざまなハードウェアとネットワーク アーキテクチャ上で正規化されます。

今後について

VMware NSX は現在一般公開されており、VMware およびパートナーの運用ツールと強固に連携しています。この記事は、長期的視点で見ると、SDDC 向けの運用ツールの変革において VMware NSX ができることのほんの一部に触れただけにすぎません。VMware では引き続き、このプラットフォームとネットワークの未来を形作るのに役立つ、お客様からの貴重なフィードバックをお待ちしております。ご協力よろしくお願いします。

以前のブログエントリでご紹介させていただいたように、今年度からvExpert の申し込みが四半期単位となりました。

VMware vExpert は、過去1年間に、VMwareコミュニティー全体に大きく貢献された個人を表彰させて頂く一年更新のプログラムです。ブログや掲示板、Twitterといったオンライン上での貢献の他、社内外への弊社製品技術促進、講演活動、執筆、ユーザ会などで貢献された方を表彰しています。

vExpert は個人に付与されるものであり、所属組織に対して付与されるものではありません。過去1年のVMwareコミュニティへの貢献や技術普及活動を評価するもので、資格認定ではございませんのでご注意ください。

その第1四半期の受賞者が下記ブログエントリ（英語サイトになります。）にて発表されましたのでご案内いたします。

vExpert 2014 Announcement　(https://blogs.vmware.com/vmtn/2014/04/vexpert-2014-announcement.html)

第2四半期の申し込みは始まったばかりですので、我こそは！と思われる方は下記リンクからお申し込みください。

2014 vExpert application
（2014年vEXPERT 申し込みサイト）:http://bit.ly/LMJqB5

以前のブログエントリにあった2013年受賞者用Fast Track　サイト及び推薦者申し込みサイトは現在クローズ中ですのでご注意ください。

IT部門に求められる代表的な要件はいつの時代も変わりません。すなわち、1)投資、運用の「コスト削減」、2) ITサービスの「俊敏性」と「柔軟性」の向上、3) 耐障害性、事業継続、ガバナンスといった「リスク管理」です。

特にITサービスの俊敏性といった面を見ると、まずインフラの提供に数日から数週間、その後のアプリケーションの提供に更に数週間から数ヶ月かかっているのがこれまで一般的でした。

インフラの面だけを見ると、仮想化によるサーバー統合で、投資コスト削減、ならびに提供までの時間短縮による俊敏性向上はある程度は実現されますが、ITサービス全体で見ると、まだまだ人の手を介することが多く、サービス提供が遅い、運用コストが高い、標準化されていない、といった課題があります。

そこで更なるコスト削減やインフラ管理の効率化のため、プライベートクラウドを構築し、自動化を促進されているお客様も多いのではないでしょうか。

ただ、一言に自動化といっても、実施しなければならないことは以下に示す通り非常に多くあります。

IT部門ではこれらを考慮し、既存のインフラ、ツールを利用しつつ、様々なユーザーのニーズに対応しなくてはなりません。

vCoud Automation Center (vCAC)は、これまで運用担当者による操作、現場で開発したスクリプト、そして機器やアプリケーション毎にバラバラに提供されている各種ツールを使用して実施していたこれら処理を自動化し、「サービスとしてITを提供」する事を可能にします。

vCACの主な機能は以下の通りです。

1. カタログからのインフラ/アプリケーション/カスタムサービスの展開および自動化
   • 標準化されたITサービスの展開
   • ユーザーへの迅速なサービス提供の実現
   • 自動化によるオペレーションミス、コンフィグレーションエラーの削減
   • 構築時に都度対応していたネットワーク/ストレージ/アプリケーションチームとの連携不要
2. 複数のハイパーバイザー、クラウドコントローラ、および物理サーバを管理可能
   • vSphere、vCloud Director etc …
   • Hyper-V、KVM、Xen、Amazon etc …
3. 新しいITサービス(XaaS)をウィザードから数分で作成し、即時ユーザーへ展開 (ストレージ/バックアップ/デスクトップなど)
4. IT部門のガバナンスを効かせたクラウドサービスのライフサイクル管理機能を実装
   • 承認/回収/コスト等の承認ワークフロー機能を提供
   • 運用の集約による運用管理工数、コストの削減

本ブログでは、vCACでできることをピックアップし、全4回に分けてご紹介していきます。

次回以降は以下の内容を予定しています。
2回目：vCACでできること (1) ～プロビジョニング～
3回目：vCACでできること (2) ～申請・承認～
4回目：vCACインストール概要

本エントリでは、最新のVMware vSphere の機能を理解し、簡単に検証していただくためにご利用いただくための簡単な裏技をご紹介します。機能検証や操作手順の確認のであれば、本ブログで以前ご紹介した（http://blogs.vmware.com/jp-cim/2013/12/hol.html）ハンズオンラボをご利用いただくのも良いのですが、ハイパーバイザーのインストールを含めた構築作業そのものやハンズオンラボのシナリオに無い操作をご体験していただくことができません。

VMware vSphere はVMware Fusion やVMware Workstation, VMware Player を使用するとMac OSX やWindows のPC 上で簡単に構築することができます。
このように、ハイパーバイザー上に仮想マシンを構築し、ハイパーバイザーをインストールしてさらにゲストマシンをインストールする構成を”Nested（ネステッド） ”と呼びます。

ネステッド構成は、互換性リストに掲載されているハードウェアが準備できない場合等に、手持ちの環境で手軽に検証環境を構築できることがこの構成の大きなメリットです。
なお、下記KBにあるように、ネステッドの構成の場合は本番環境としてご利用いただくことはできませんのでご注意ください。

Support for running ESXi/ESX as a nested virtualization solution (http://kb.vmware.com/kb/2009916)

最近では、このネステッド環境に特化したVMware tools もFling (フリーウェア）として提供されています。

https://labs.vmware.com/flings/vmware-tools-for-nested-esxi

では、早速VMware Fusion を使用してネステッドESXi を構築してみましょう。

1. 仮想マシンライブラリで＋（追加）→新規をして仮想マシンを新規作成します。

2. ディスクまたはイメージからインストールを選択します。

３．「別のディスクまたはイメージを使用」をクリックしてあらかじめダウンロードしておいたハイパーバイザーのインストールイメージを指定します。

4．「仮想マシンの構成が完了しました。」とメッセージが表示されます。

このままだと、デフォルトの仮想マシン構成（vCPU 2コア、4GB RAM 、40GB ディスク）という構成になりますので、適時ご利用いただいている環境に合わせてサイズを変更します。

VMware Fusion でネステッド構成を構築した場合、ネットワークアダプタはE1000 となりますが、vSphere on vSphere の場合はvmxnet3 を利用するとより安定したパフォーマンスが得られます。

ここまででひととおり完了です。

作成した仮想マシンを起動すると、ESXi のインストーラが始まりますので、通常と同じようにインストールします。Mac の場合に、F11キーが直接入力できませんので、fn + ⌘(Command) + F11 もしくは、仮想マシン→キーの送信→F11 を使用して入力します。

インストールが完了した画面がこちらになります。

お手軽な検証環境をつかって、操作方法の確認等にぜひお役立てください。

参考KB

Installing ESXi in VMware Fusion (http://kb.vmware.com/kb/2009580)　

Support for running ESXi/ESX as a nested virtualization solution (http://kb.vmware.com/kb/2009916)

こんにちは。VMwareの中村です。
突然ですが、現在皆様がお使いの仮想基盤のリソース使用率はどのくらいでしょうか？
また、物理サーバ(ESXi)あたりに稼働している仮想マシン数はどのくらいでしょうか？

このようなご質問をすると、サーバ仮想化は導入したものの、

「リソース使用率はあまり高くないけど、
パフォーマンスの影響が怖いので必要最低限しか仮想マシンを載せない…」

等、サーバ仮想化の利点を十分に活かせずお困りのユーザ様が多くいらっしゃいます。
確かに仮想基盤は物理リソースを占有ではなく「共有」していることから
物理リソースを無駄なくより有効に活用する場合に”ノウハウ”が必要になってきます。

この”ノウハウ”が思った以上の「壁」となってしまい、結局は物理リソースを共有して
有効活用するという仮想基盤の特徴を活かせないままご使用されていることが多いようです。

そこでVMwareは「仮想基盤を物理リソースを安全に有効活用したい！」というお客様の
課題をご支援するため、
「VMware vCenter Operations Manager (略してvC Ops)」をご提供しております。
このvC Opsでは、より仮想基盤自体が可視化されるので、物理リソースの状態を把握しやすくなり

あと何台仮想マシンが載るのか？
いつ物理リソースが枯渇するのか？
ムダなリソースはどこで発生しているのか？

等把握することができ、根拠をもった将来の計画も立て易くなります。
このシリーズではvC Opsを使って、安全に仮想基盤を活用していただく方法について
5回に分けてご紹介して参ります。

仮想基盤のリソース状況を知る！
～VMware vCenter Operations Manager活用法～

第1回　あとどのくらい仮想マシン載せられるか？（リソース残量を知る）
第2回　どこにリソースの無駄が発生しているのか！（リソースの無駄と削減）　　
第3回　より多くの仮想マシンを安全に載せていく（統合率を上げていく）
第4回　将来、物理リソースがどのくらい必要か？（需要予測）
第5回　使用環境における”ポリシー”の設定

来週から開始します。最後までご愛読いただけますようよろしくお願い致します！
執筆者
VMwareSE　塚田大輔 & 中村朝之

関連リンク
vC Opsのラボ簡単オンラインラボ

今回がOrchestratorの最終回となります。

直近の2回で実際にOrchestratorを使ってみるということで、vCenterに関する処理を自動化するためのワークフローの作成、プラグインの使用例としてOrchestratorを使ってActive Directoryに対する操作を行ってきましたが、今回はvCloud Automation Center（以下 vCAC）との連携機能について見ていきたいと思います。
vCACとはセルフサービスカタログを提供することで、ITサービスの俊敏性や柔軟性を向上させ、IT運用コストを削減するための製品です。vCACのブログでも触れられておりますとおり、vCACとして仮想マシンのプロビジョニングの自動化や、申請/承認ワークフローの実装といった機能を持ち合わせていますが、システムのニーズに従ってより複雑なワークフローを構成するケースも出てくるかと思います。その際に、Orchestratorを使用することでVMware製品だけでなく、標準プロトコルやパートナー様提供のアプリケーションプラグインを経由することで、外部システム連携のワークフローを容易に作成するができます。

vCAC 6.0では、OrchestratorとUIレベルでのインテグレーションが進められております。vCAC 6.0で提供される標準ポータルのUIからOrchestratorのワークフローにアクセスすることができます。

・「Advanced Services」-「Service Blueprints」でプラスボタンを押下で、OrchestratorのLibraryにアクセス可能

・「Administration」-「Import workflow packages」で、OrchestratorでExportしておいたWorkflowをインポート可能

vCAC/Orchestratorの実際の操作につきましては、以下オンラインハンズオンのコンテンツ（HOL-SDC-1321）を用意しております。vCACのポータルに、OrchestratorによるADユーザ登録のワークフローを標準メニューとして追加する内容が含まれておりますので、アクセスしてみて下さい。

http://www.projectnee.com/HOL

HOL-SDC-1321 ｖCloud Automation Center (vCAC) 6 from A to Z

最後になりますが、Orchestratorのプラグインについては以下VMware Solution Exchangeのサイトに情報がございます。直近で提供されているプラグインの確認の際には、こちらのサイトをご一読下さい。
（Orchestratorのプラグイン以外にも、Virtual Applianceや各種パートナー様のソリューションの情報も提供されています。）

https://solutionexchange.vmware.com/

アーカイブ
1回目:プライベートクラウド実現に向けた自動化のニーズ
2回目:vCenter Orchestratorのアーキテクチャ
3回目:vCenter Orchestratorを使ってみる(1)
4回目:vCenter Orchestratorを使ってみる(2)

仮想環境を運用する上で、メモリの利用状況の確認は非常に重要な情報の1つとります。
今回は、VMware® vCenter Server™(以下vCenter)から確認できるメモリ情報の見方をご紹介したいと思います。

vCenterでは、以下の3つの画面でメモリの状況を確認することができます。

1. 仮想マシンのハードウェア
2. ホストメモリ
3. ゲストメモリ

最初に、仮想マシンのハードウェアで確認できる値を紹介します。

図1．仮想マシンハードウェア

図1で確認できる通り、「仮想マシンハードウェア」の画面で表示される、メモリに関する情報は以下のように表示されています。

• メモリ使用率：2048MB、266MB使用
• ホストオーバヘッド：41MB

メモリ使用率で表示される、最初の値（2048MB）は、仮想マシンを作成した際にメモリとして設定をした値となります。

次に、XXXMB使用（266MB）の部分は、以前のC#クライアントでは「アクティブなゲストメモリ」と表示されていた項目となっており、仮想マシンが活発に利用しているメモリを、一定期間の内部統計値より計算しています。

ホストのオーバーヘッド(41MB)は、仮想マシンをパワーオンするために必要なオーバーヘッド メモリの量となっており、内部的にはページ・テーブルなどの情報を含んでいます。
見積に関してはマニュアルを参照ください。（仮想マシン上のオーバーヘッド メモリ）

次に、「監視」タブの「リソース割り当て」で確認できる情報を紹介します。
ここではメモリ情報として「ホストメモリ」と「ゲストメモリ」の2つのポートレットで情報の確認が可能です。

まずは、ホストメモリからご紹介します。
ホストメモリで確認できる情報は、ESXi で消費していると認識しているメモリ量を表します。

図2　ホストメモリ

図2にある通り、メモリに関する情報は以下のように表示されています。
消費：1.83GB、オーバーヘッド：41.00MB、予約、制限、構成済み：2GB、シェア、割り当て最低限度：854.00MB、オーバーヘッド予約：37.87MBの項目があります。

消費（1.83GB）とはホストの物理メモリを仮想マシンが消費しているメモリ量となります。

つまり、今回の例では2GBの割り当てたメモリの内、1.83GBメモリが消費されているということになります。

この項目の注意点として、パフォーマンスタブのメモリ項目の「消費」とは違う点です。

こちらの消費は、オーバーヘッドを含みますが、パフォーマンスタブのメモリ項目の「消費」はオーバーヘッドを含みません。

オーバーヘッド(41.00MB)は、前項で紹介したとおり、仮想マシンをパワーオンするために必要なメモリオーバーヘッドとなっております。「ホストのオーバーヘッド」と同じ値となります。

構成済み(2.00GB)は、前項で紹介したとおり、仮想マシンを作成した際のメモリとして設定をした値となります。
メモリ「使用率」の最初の値と同じ値となります。

割り当て最低限度（854.00MB）は、すべての仮想マシンが割り当てられたリソースを全て消費した場合、該当の仮想マシンに割り当てることができるメモリ量となります。
重度なオーバーコミットが発生した場合、この値に基づいてメモリの確保を行います。
オーバーコミットをしている環境では、注意して確認すべき値の1つとなります。

オーバーヘッド予約（37.87MB）は仮想化オーバーヘッド用に予約されているメモリの量となります。

最後に、ゲストメモリについて紹介します
ゲストメモリとはゲスト OS で消費していると認識しているメモリ量を表します。

図3　ゲストメモリ

図3にある通り、メモリに関する情報は以下のように表示されています。
有効なゲストメモリ：266.00MB、プライベート：1.73GB、共有：251.00MB、バルーン済み：0.00B、圧縮済み：440.32KB、スワップ済み：23.00MB、未アクセス：583.68KBの項目があります。

有効なゲストメモリ(266.00MB)は、前項で紹介したとおり、実際に読み書きを行っている(物理メモリにタッチしている)メモリの値を、一定期間の内部統計値より計算しています。
メモリ「使用率」の2つ目の値の「XXXMB使用」と同じ値になります。

プライベート(1.73GB)とは、仮想マシンが物理メモリとしてバッキングされている容量を表します。
今回の例では1.73GBは物理的にメモリが確保されています。

共有、バルーン済み、圧縮済み、スワップ済みに関しては、マニュアルを参照ください。今回は説明を省略させていただきます。

未アクセス(583.68KB)とは、ゲストにより参照されないメモリの量となります。

今まで紹介した各値は、下図のようにあらわされます。

vCneter上で確認できるメモリ情報は仮想環境を運用するうえで、有用な情報が多く含まれています。
まずは、こちらの内容を確認後、さらに詳細な調査が必要な場合はメトリック情報を、各種ツールでの取得をして下さい。

例えばvCenter Operations Managerなどを利用すると、仮想基盤の様々な情報を判りやすく取得することが可能となります。

こんにちは、VMwareの塚田です。

今週から始まる連載「VMware vCenter Operations Manager活用法」では、VMware® vCenter Operations Manager (vC Ops)の活用ノウハウを具体的に紹介致します。第1回目のテーマは「現在運用中の仮想基盤へ何台くらい仮想マシンを載せられるのか？」です。

リソースの残り容量を把握する事は意外に難しい

仮想基盤を運用されていると、仮想マシンを後何台くらい基盤へ追加できるか？という事を知りたいと思う事が度々あると思います。そのような時、皆さんはどのような方法で調べますか？

真っ先に思い浮かぶのはvCenter Serverのパフォーマンス チャートだと思います。パフォーマンス チャートは、CPU使用率やメモリの使用量、データストアの使用済み容量と空き容量等、仮想基盤のリソースの最新の利用状況を詳細に把握する事を支援してくれます。また、リソースの統計情報を一定期間アーカイブしてくれるので、過去にさかのぼってリソースの利用状況を調べる事も可能です。

しかし、その便利なパフォーマンス チャートも、仮想基盤に追加可能な仮想マシンの台数については何も教えてくれません。それを知るためには、下に挙げるような手順を経て計算するしか方法がありません。

1. vCenter Serverのパフォーマンス チャートのデータをエクスポートする
2. エクスポートしたデータを表計算ソフト等へ取り込んで、以下の情報を算出する
   • 仮想基盤上の仮想マシンの平均的な構成（vCPU数、仮想メモリの容量、仮想ディスクの容量、仮想NIC等）
   • 仮想基盤の仮想マシンの平均的なリソース使用量（CPU、メモリ、仮想ディスク、仮想NIC等）
3. 算出された仮想マシンの平均的な構成とリソース使用量から、残りリソースで平均的な構成の仮想マシンを何台作成可能か算出

いかがですか？結構な工数がかかりそうですね。また、このような複雑な計算を頻繁に行う事も大変そうですね。

このように、「仮想マシンをあと何台作成できるか？」という一見簡単そうな疑問に答えるのも、実際は結構な工数がかかったり、ある程度の知識が必要だったりする事がご理解いただけると思います。

vC Opsは残り容量を常に分かり易く表示

しかし、「基盤全体のパフォーマンスに影響なく仮想マシンを後何台作成できるのか？」、または「仮想基盤の空き容量はどれくらいか？」とは仮想基盤の運用者であれば常に把握しておきたい基本的な情報の一つだと思います。vC Opsを用いれば、このような基本的な情報も手間をかけずに常に把握することが可能です。

vC Opsは、クラスタ全体のリソースの残り容量を次の2つの観点で仮想基盤の運用管理者へ分かり易く伝えます。

図1. 仮想基盤の残りリソースを「残り時間」（日数）と「残り容量」（台数）で表示

• 残り時間（日数）
  • CPU、メモリ、ストレージの容量とI/O数、およびネットワークの各種リソースの内、最も早く枯渇するリソースを特定し、それが枯渇するまでの残り時間を「日数」で表示します。
• 残り容量（作成可能な仮想マシンの台数）
  • 基盤上の仮想マシンの平均的な構成を算出し、残ったリソースから同じ構成の仮想マシンを何台作成する事が可能か「台数」

リソース毎の枯渇時期も予測し、リソース増強計画の作成を支援

また、vC Opsは先ほど挙げた各種リソース（CPU、メモリ、ストレージの容量とI/O数、ネットワーク）それぞれについて詳細な利用状況のレポートも作成、表示します。その内容は以下の通りです。

• 枯渇するまでの残り時間（日数）
• 過去のリソース利用状況（過去2週間）
• 最新のリソース利用状況（今週）
• 未来のリソース利用状況の予測（来週から 半年先まで）

図2. リソース枯渇までの残り時間を把握することが可能

これを参照することにより、運用管理者は最も早期に枯渇しそうなリソースを特定することが可能であり、この情報を元に以下のような対策を取る事が可能になります。

• リソースの追加計画を作成する
• 日程上、または予算上の都合によりリソース追加が難しい場合は、仮想マシンの構成を見直してリソースを節約する事を計画する

そして、vC Opsはリソースの追加計画の作成を支援する機能、仮想マシンの構成を見直してリソースの節約を支援する機能も備えています。これらについては、今後の連載において紹介致します。

まとめ

vC Opsは、仮想基盤を運用管理する上で把握しておくべき基本的な情報の1つである、リソースの残り容量を常に計算しています。そして、その結果をいつどのリソースが最も早期に枯渇するか、仮想マシンを何台まで作成可能か、というとても分かり易い形式で管理者へ伝えます。

管理者はvC Opsのダッシュボードを見るだけで、いつまでにリソースを増強すべきか計画を練ったり、仮想マシンの構成を見直してリソースの消費量を抑制する事を検討したりする事が可能になります。

次回以降の連載の内容（予定）は以下の通りです。是非お楽しみにして下さい。

仮想基盤のリソース（キャパシティ？）状況を知る！
～VMware vCenter Operations Manager活用法～

執筆者：VMware SE 塚田 大輔

VMware パートナー様限定 vCenter Operations Manager, vSphere with Operations Management のウェブセミナーを下記の通り開催します。

VMware のパートナーの皆様で、vCenter Operations Manager, vSphere with Operations Management の販売に携われている方、ご興味をお持ちの方、その他パートナー様であればどなたでもご参加いただくことができます。
このウェブセミナーは過去に実施したセミナーで好評であった２つのセッションを選択し、ウェブセミナーの形式で提供するものになります。以前に同様なセミナーにご参加できなかったパートナーの皆様、この機会に是非ご参加頂き、今後のビジネスにお役立てください！2日間通しての参加がお勧めです。

• 2014年5月14日（水）17:00 ～ 18:00
  vCenter Operations Managerの提案方法を考えよう！
  ～ 事例を参考にした提案のポイントと成功するPOCのシナリオ ～

• 2014年5月15日（木）17:00 ～ 18:00
  vCenter Operations ManagerのPoCを成功させる！

お申し込み方法は下記の通りです。

1. 最初に必ずこちらよりPartner Centralにログインしてください。
2. Partner Central にログイン後、表示が英語の場合、Language の設定を日本語に設定してください。
3. 上記手順を踏んだ後、それぞれのセッションの参加申し込みをこちらから行います。

また、Partner Central のアカウントをお持ちでない方は、この機会に是非アカウント登録していただき、その上で上記の手順で申し込みください。パートナーセントラルのアカウント登録方法はこちらになります。

vSphere App HA （以下App HA）を使用すると、環境内の仮想マシンで実行中のアプリケーションの高可用性を定義できます。

先日、App HA 1.1がリリースされましたので、今バージョンで強化されたポイントについてご紹介します。

1.カスタムのサービスの作成と、登録について

・・・App HAで標準としてサポートされていないプラグインを使用するための、カスタムサービスを定義することができます。

カスタムサービスの設定手順について、ご紹介します。

# /opt/vadm-engine/bin/custom_service.sh add
Enter service name: JBoss7.1

Adding custom service 'JBoss7.1'

2014-04-16 15:51:03,260 [main] INFO  c.v.v.d.service.ConfigurationService - Configuration:
        DB Host:        127.0.0.1
        DB Port:        5432
        DB Name:        apphadb
        DB Username:    appha
        Config schema:  dbconfig
        Postgres bin:   /var/lib/pgsql/bin

2014-04-16 15:51:03,264 [main] INFO  c.v.v.dbconfig.service.FacadeService - Validating configuration

Operation succeeded.
Restarting vSphere App HA ...

　　　

• タイプ別 Best Practices（コツ） FAQ(質問) お知らせ やってみよう（実践ガイド） 基本
• 製品別 vSphere 5.5 – vCenter 5.5 – vCenter Server – vCloud – vShield – vCenter Operations Management – Orchestrator
• 機能別 アップグレードクラウド ストレージ ネットワーク パフォーマンス 可用性 自動化 負荷分散

こんにちは、VMware の山口です。今回は事業継続ソリューションの製品である VMware vCenter Site Recovery Manager（以降SRM）にて、いざという時の為に役立つ機能をご紹介します。

SRM は、保護したい仮想マシン群（以降、保護対象）を、予め定義されたステップ（以降、リカバリプラン）に従い、データセンター間でレプリケーション(*1)し、いざ事業継続が困難となった時（災害復旧）や、予測される災害の時（計画移行）に、安全且つ確実に、フェイルオーバー(*2)することが出来ます。

*1レプリケーションとは、「データの整合性を保ちながらデータセンター間で、コピーする処理」を意味します。
*2ファイルオーバーとは「システムの冗長化技術の一種で、処理中のサーバやシステムに障害が発生しても、予備のシステムがそのまま処理を続行する技術」を意味します。

SRM を利用した時と、しない時での大まかなステップを下記に比較します。システムによっては増減があると思いますが、このステップをいざとなった時に、人手によるオペレーションで、迅速且つ正確に実行するのは非常に困難と思います。

下図は、リカバリプランを示しています。このステップに従い、自動的に保護対象をフェイルオーバーさせるので人的オペレーションを予防することができます。

今日は、SRM の埋もれがちですが、ユニークな機能の一つとして、再保護という機能もご紹介します。
これは、その名の通り、フェイルオーバーされた保護対象を、再保護する機能です。
下図は、サイトAとサイトB間で、保護対象（WEBシステム）を計画移行している様子です。計画移行されたサイトBの保護対象を再保護すると、再度サイトBで更新された情報をサイトAにレプリケーションし、保護された状態になります。

つまり、サイトAからサイトBに情報をレプリケーションしていた時と逆の状態となり、再度、計画移行や災害復旧が可能になります。

なお、この場合は、元のリカバリプランを真逆に実行することになりますので、新たな作成は不要です。

このように、非常に有効な機能でありますが、実際にやってみたいという方は、こちらのサイトより、マニュアルを入手頂きお試し頂ければと思います。

今回はせっかくなので、実際にこのオンラインラボを使って、計画移行と再保護を実施してみます。
この部分だけお試し頂くこともできますので上記のマテリアルを入手頂き、P27から開始してみてください！
※オンラインラボのアカウントをお持ちでない方は、P8を参照し作成してくださいね！

下記の画面キャプチャは（P29）、WEBシステムの計画移行を実施しているところになります。数クリックで保護対象のシステムを計画移行できることが実際に体感できます。

下記のキャプチャは（P31）、再保護しているところです。
この数クリックの操作で、計画移行した保護対象のシステムを、”再度”、保護することが可能です。

画面キャプチャ下部の最近のタスクで、どのような処理がされているか見ることができます。有事の際に、人間の手でこれほど早く、正確にオペレーションするのはおそらく難しいと思います。
複数のサイトにvSphereをお持ちの方で、有事に備えたいという方、ぜひSRMの利用をご検討頂ければ幸いでございます。

こんにちは！VMwareの中村です。
前回は「あと何台くらい仮想マシンを載せられるか？」がテーマでしたが今回のテーマは「どこにリソースの無駄が
発生しているのか！」です。仮想基盤はリソースを共有している為、効率よく使っていきたいというのが
インフラ管理者の思いです。現状皆様はどうでしょうか？下記の表は実際あるユーザさんのアセスメント結果です。

リソースを必要以上に割り当ててしまう主な要因として

• 仮想マシンのスペックをピーク時を考慮して設計
• 仮想マシンのスペックはアプリケーションに依存するのでインフラ管理者は判断できない

インフラ管理者としては、ムダなく効率よくリソースを使っていきたいのですが
リソースが過剰に割り当てられているのか、適切に割り当てられているのか、どう判断してたらいいのか？
インフラ管理者にとっては悩ましい部分かと思います。
そこでVMware vCenter Operations Manager(vC Ops)が活躍します。
ではvC Opsを使用してどのように無駄を把握して検討していくか、流れをみていきましょう。

★全体を俯瞰して把握

vC Opsのダッシュボードにある「効率」を選択します。
仮想基盤全体で現状どのくらい最適に使用されているか、またはムダがないかどうか、全体感を目視することができます。

★特定

続いてどの仮想マシンにおいて過剰にリソースが割り当てられているかリスト化します。
【計画】-【表示】-【無駄】-【過剰サイズ仮想マシン】においてvC Opsが「このくらいのリソースでいいのでは？」
という推奨値を出してくれます。
また、パワーオフ状態の仮想マシンもリスト化してくれますのでこちらも重宝します。

★検討と実施

では、リソース割り当てが過剰である仮想マシンがいくつかあった際、どの仮想マシンに対して
スペックを変更（縮小）していくか？検討するにあたり、まず考慮しなくてはいけない部分として
下記が挙げられるます。

• まずどのVMから実施していくか？
• 本当にスペック変更して大丈夫か？(ピーク時を考慮できるのか？等)

目安として、まずワークロードの変動が少ない仮想マシンからスペックを変更していくと影響が少ないでしょう。
変動が大きい場合、ピーク時における影響も考慮しなくてはいけないので、vC Opsを使って各仮想マシンにおける
“ワークロード”の傾向を確認してみましょう。また、負荷（stress）バッチスコアを参考にするのもよいでしょう。
スコアの低いVM程ワークロードの変動幅が小さいので、スペックを下げる優先度の高い候補としても目安になる値です。

「構成済みvCPU」の隣に「vCPU数推奨値」という列があります。これが計算されたCPUの適正サイズを示しています。
そして、その横に「推奨値中のCPU需要の割合」という項目があります。これは適正サイズに変更した後のCPUの状況を
推測してくれます。

メモリに関しては、「構成済みメモリ」の隣に「推奨メモリ」という列があります。これが計算されたメモリの適正サイズを
示しています。これはアクティブメモリの値なので、通常は、一気にこの値に変更するというよりも、少しずつ適正値に
近づけていくようにしましょう。

まとめ

普段、何気なく使用している仮想基盤。どのくらい有効的に使用できているか、数値的に把握するのは
少し難易度が高いかもしれません。皆様が普段お使いの仮想基盤も、もしかして必要以上に余剰なリソースが
あるかもしれません。このvC Opsをある意味、体脂肪計のように使っていただき、現在どこにリソースの無駄があるのか？
を常に把握していただき、限りあるリソースを有効的に使用できる仮想基盤を目指しましょう！

仮想基盤のリソース状況を知る！
～VMware vCenter Operations Manager活用法～
第1回　あとどのくらい仮想マシンを載せられるか？（リソース残量を知る）
第2回　どこにリソースの無駄が発生しているのか！（リソースの無駄の把握と削減）
第3回　より多くの仮想マシンを安全に載せていく（統合率を上げていく）Coming Soon
第4回　将来、物理リソースがどのくらい必要か？（重要予測）Coming Soon
第5回　使用環境における”ポリシー”の設定 Coming Soon

VMware では最新の情報をお届けする座学セミナーや、実機を触りながら製品の良さを理解する体感セミナーを開催しております。

直近のセミナーは下記よりチェックできます！！

IT価値創造塾のセミナー紹介
http://vmware-juku.jp/seminar/index.html

VMwareのイベント紹介
http://www.vmware.com/jp/events/

是非、ご参加下さい！！

VMware vCenter Operations Manager には様々な他社製品と連携できる機能が用意されており、これから数回にわたり vCenter Operations Manager と連携できる製品について紹介させていただきます。今回ご紹介するHP様の HP StoreFront Analytics Pack for vCenter Operations Manager による3 PAR ストレージとの連携については、事前に日本HPの3PAR担当プリセールスの伊東様とVMwareにて共同検証を実施、その結果に基づいて伊藤様より当ブログ用の記事を執筆、ご提供いただきました。その内容を、読者の皆さんにご紹介させていただきます。

HP 3PARをVMwareの仮想環境で利用されている方も多いと思います。そのような方、もしくは今後3PARを導入予定の方に是非ご覧いただきたいBlogです。

HP StoreFront Analytics Pack for vCenter Operations Manager
今回ご紹介するHP StoreFront Analytics Pack for vCenter Operations Manager という製品では、VMware vCenter Operations Manager（以下vC Opsと記載）とHP 3PARを連携させるためのAdapterが提供されています。このAdapterを利用することにより、vC Opsが通常取得可能な仮想マシンやホストの情報はもとより、3PARハードウェア内部の情報、例えば、コントローラ、ドライブ、ドライブシャーシ、ポート、ファンに至るまで、”3PARの健康状態” をvC Opsの管理画面から一気通貫で確認することが可能となります。

HP 3PAR StoreServシリーズ

HP 3PAR Management Console画面

従来の管理手法では、例えば3PARのパフォーマンスを細かくチェックしたい場合、3PARのストレージ管理ツールにアクセスしなければなりませんでした。これが本製品を利用することにより、ストレージの負荷状況や、データ領域などのリソースの利用状況が仮想環境の管理ツールであるvC Opsに取り込まれ、ひとつの管理コンソールで視覚的に非常に簡単に見ることができるようになります。

最終的にはこのようなイメージとなります。

以下、vC Ops環境へのアダプタのインストール方法や活用方法について解説していきたいと思います。

①HP 3PAR用Adapterのインストール
3PAR Adapterインストールは極めて簡単です。まず3PAR用のアダプタを用意します。アダプタは以下のサイトからダウンロードが可能で60日間は評価期間として使用することが可能です。

＜HP Software Depotサイト＞
https://h20392.www2.hp.com/portal/swdepot/index.do
※HP Storage > Storage Software > HP StoreFront Analytics for VMware vCenter Operations Manager

https://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=vCOPS

• Zipファイルをダウンロードしたら解凍しておきます。
• 解凍するとhpsfap4vcops_1_0.pak というファイルが出てきます。これがアダプタになります。
• アダプタのvCOpsへのインストールは非常に簡単で、vC Opsの管理画面（/admin）にアクセスし管理画面で更新の処理を行います。
• 下図のように更新パッケージにhpsfap4vcops_1_0.pakを選択し更新するだけで完了です。

②Adapterのモニタ対象となる3PARを登録
アダプタのインストール後にモニタ対象となる3PARを登録します。

• サードパーティのアダプタの機能を利用するには、カスタム画面（/vcops-custom）にログインします。
• ログイン後、環境タブ > 構成 > アダプタインスタンス…を選択します。

アダプタインスタンスの管理画面で、新規アダプタインスタンスの追加を行います。

アダプタインスタンスの追加ボタンを押し、アダプタインスタンス名、および Data Source Network Nameを入力し完了です。

③3PARアダプタの活用方法
このアダプタを使うことにより、vC Opsから3PARの情報を以下の様に確認することが可能となります。

HP Storage Monitoringタブ
3PARの全体的な状態を確認することが可能です。

• 対象となる3PARを選択することにより、そのリソース状況が一覧で表示されます。
• ハードウェアデバイスがアイコンで一個一個表示され、健全性はデバイスをランキングで表示、ヒートマップによる現在の負荷状況を一元的に確認することができます。
• ヒートマップはハードウェアデバイス(ドライブやポート)とボリューム毎のIOPSおよび、CPG（3PAR特有のボリュームプール）とボリューム毎の容量使用率を表示できます。

各デバイスの右下の色がその健全性を表しており、緑→黄色→赤という順番に健全性が低くなっていきます。

ストレージで最もボトルネックとなりやすいデバイスはハードディスクドライブになりますが、それも一覧で表示されるため、どの部分に負荷がかかっているか即座に確認することが可能です。

上図は、一部のドライブに極端にI/O負荷がかかっているような状態を表しており、数本のドライブが赤く表示されています。

※3PARは通常は全てのドライブに均一にデータを配置させるため、一部のドライブがホット=赤い状態になることはありませんが、今回は検証するためあえて従来のストレージに近いデータ配置を作りました。

健全性として赤く表示されているところは状況を確認したいところだと思いますが、さらに詳細な情報を確認するためにはリソース詳細を表示させます。

下図が”Storage System”に対してリソース詳細を表示した際の例になります。

※リソース詳細へのリンクはStorage System以外にも様々なオブジェクトに対して設定されており、各オブジェクトの詳細情報の確認が可能です。

健全性のステータスが低い原因を細かく突き止めていくことができます。この例では、特定のストレージで動的閾値を超えてしまっていることが原因であることが分かります。

今度は閾値を超えてしまった原因が何か？を突き止めるために、さらに当該ドライブをダブルクリックすることでIOPSなど選択したメトリックを表示し状況が確認できます。

この例では、当該ドライブのIOPSが直近で579～629の間で推移しているのが分かります。

ドライブ１台あたりのIOPSとしては非常に高い値（通常は200IOPS）ですので、IOPSを下げるために何らかの対策（他のドライブにデータを分散する、ドライブを追加する等）を講じなければいけないと判断することができます。

デバイスアイコンの色から始める解析のアプローチ以外の方法としては、下図の健全性の低いランキング（ハードウェアだけでなく論理構成も表示）から上位のリソースの詳細を見て行く方法や、

現状の負荷状況をヒートマップから見て、負荷の高い箇所の詳細情報を確認することで根本原因を突き止めることができるようになります。
例えば下記ヒートマップでは、今回準備した72本の物理ディスクが表示されています。

HP Storage Trouble Shootingタブ
ここまでの内容はストレージ内部の監視・解析方法になりますが、Trouble Shootingでは仮想マシンやデータストアから3PARのデバイスまでを下図のようなツリーで見ることができ、それらのマッピング状況を確認することができます。

そのため、仮想マシンに何らかのトラブルが見つかった場合に、その根本原因を探す先として、3PARのデバイスにまで目を向けることができます。それをひとつの画面でできるのです。

下記 VM TO STORAGE MAPPINGの画面ではStorage Monitoringタブに出てきたようなアイコンではなく、各デバイスはバッジで簡素化され表示されています。そのため、より視認しやすく、問題の箇所を即座に特定できるようになっています。

バッジの色から問題のあるリソースをダブルクリックでたどっていくことで、ここからも同じようにパフォーマンス状況まで確認し、問題の原因を特定することができます。

vC Opsの標準の監視項目は、データストアや仮想マシンより上位のリソースを監視します。

3PARのアダプタは仮想マシン/データストアから下位層のリソースを監視しています。

両方のツリーを組み合わせて見ていくことで、上位層から下位層までの関連するトラブル箇所を容易に確認することができるようになります。

④HP 3PARが持つ他のvSphere連携ツールとの役割の違い

下表にて以前から存在する3PARとvSphere環境を連携させるツールであるManagement Plug-in & Recovery Managerと、今回ご紹介したStoreFront Analytics Pack for vCenter Operations Manager（vC Ops アダプタ）の目的・機能を比較してみました。

まとめ

vC Opsにより可能となる仮想ホスト環境を俯瞰した監視方法に3PARのアダプタを追加することで、重要や役割を持つストレージのデバイスや論理構造にまで監視できる範囲を簡単に拡大できますので、vSphere環境のストレージとして3PARをご利用いただければ、より安心して日々の運用ができるようになります。

是非ご利用下さい！！