Home > Blogs > Japan Cloud Infrastructure Blog

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

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

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

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

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

Ops_1_1

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

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


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

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

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

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

ops1_2

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

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

やってみよう!vSphere on VMware Fusion編

本エントリでは、最新の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(ネステッド) ”と呼びます。

nested

nested2

ネステッド構成は、互換性リストに掲載されているハードウェアが準備できない場合等に、手持ちの環境で手軽に検証環境を構築できることがこの構成の大きなメリットです。
なお、下記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. ディスクまたはイメージからインストールを選択します。

仮想マシンを作成_と_仮想マシンのライブラリ

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

新しい仮想マシン_と_nested_と_仮想マシンのライブラリ

新しい仮想マシン_と_nested

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

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

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

新しい仮想マシン_と_nested_と_仮想マシンのライブラリ 2ここまででひととおり完了です。

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

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

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

参考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)

vCloud Automation Center 概要 ~IT部門に求められること~

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

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

01

 

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

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

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

02

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

 

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

03

 

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

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

04

 

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

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

 

vExpert 2014 第1四半期受賞者発表

以前のブログエントリでご紹介させていただいたように、今年度から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 サイト及び推薦者申し込みサイトは現在クローズ中ですのでご注意ください。

 

VMware NSX による Software-Defined Data Center (SDDC) の視認性の変革

ネットワーク仮想化と 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 では引き続き、このプラットフォームとネットワークの未来を形作るのに役立つ、お客様からの貴重なフィードバックをお待ちしております。ご協力よろしくお願いします。

vCenter Orchestratorを使ってみる(2)

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

みなさん、こんにちは。

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. Active Directory 上のコンピュータアカウントの作成

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

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

vCO-blog-4st-001

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

vCO-blog-4st-002

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

vCO-blog-4st-003

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

vCO-blog-4st-004

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

vCO-blog-4st-005

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

vCO-blog-4st-006

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

vCO-blog-4st-007

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

vCO-blog-4st-008

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

vCO-blog-4st-009

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

vCO-blog-4st-010

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

vCO-blog-4st-011

 

2. Active Directory 上のコンピュータアカウントの削除

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

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

vCO-blog-4st-012

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

vCO-blog-4st-013

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

vCO-blog-4st-014

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

vCO-blog-4st-015

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

vCO-blog-4st-016

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

vCO-blog-4st-017

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

vCO-blog-4st-019

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

vCO-blog-4st-009

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

vCO-blog-4st-020

 

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

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

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

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

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

押さえておきたいvSphere の基本~ネットワーク編 第3回~

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


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

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

1

 

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

  • 必要なネットワークやセキュリティ サービスを準備、設定変更するのに数日または数週間かかる。(ビジネスニーズに応じた迅速な導入、拡張が制限される。仮想マシンは数分で準備できるのに!!)
  • 物理ネットワークとセキュリティ境界の制限によって、仮想マシンを動的に移行・構成出来ない。(サーバーリソースの使用率の最適化を防いでいる)
  • ネットワーク機器への手動による構成や設定変更、専用アプライアンス等による異なる管理インターフェースを使用する事による効率性の低下。(オペレーションコストの増大)

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

 2

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


■ vCNS主な機能

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

3


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

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


Edge Gateway

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

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

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

5


App Distributed Firewall

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

6

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


vCloud Ecosystem Framework

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

7

 

■ 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編〜

押さえておきたいvSphereの基本~ストレージ編 第3回~

皆様こんにちは。前回は、vSphere のEnterprise エディションで提供される機能によりストレージの能力を最大に活用する方法をお伝えいたしました。引き続き、「押さえておきたいvSphereの基本」と題して、“ストレージを自動的に整える”方法をお伝えします。

ストレージを自動的に整えるとは、どういうことでしょうか?ストレージの能力/性能が最大限に活用できるようになれば、より多くの仮想マシンをストレージ上に配置できるようになります。しかしながら、仮想マシンのI/Oが競合し、ストレージの能力を超えてしまった場合には、仮想マシンのパフォーマンスは悪化してしまいますので、ストレージに対して性能や容量を整える工夫が必要になってきます。

■ストレージを整える

様々なサービスを提供する仮想マシンは、仮想マシン毎にI/O 数、レスポンスタイム、スループット、容量などストレージに対する要件が存在します。仮想マシンが安定して稼働するためには、きちんと仮想マシンの特性を理解して、バランスよく配置することが求められます。例えば、午前にI/O 要求が高まる仮想マシンと午後にI/O 要求が高まる仮想マシンを同一データストアに配置するという形になります。ところが、実際の仮想化環境というのは時間、分、秒といったもっと細かい粒度で稼働状況が変化していきます。また、仮想マシンの増減やシステムを利用するユーザの増減などによっても、CPUやメモリと同じようにストレージの要件は時間の経過とともに変化していきます。そのため、すべての仮想マシンの稼働状況を把握し、IT管理者の方が手動でバランスよく配置し続けることは作業負荷が重くなってしまいます。vSphere のEnterprise plus エディションでは、そのような課題を解決する機能を提供しております。

具体的な例を見ていきます。こちらの図1では、5つの仮想マシンが3台のホストと1つのデータストア上で稼働をしています。ホストは分散されておりますが、データストアは1つのみであり、5つの仮想マシンはこのデータストア上に配置されています。各仮想マシンは、稼働状況に応じて必要なI/Oを発行していますが、あるタイミングでストレージの能力を超えるI/Oが仮想マシンから発行された場合、ディスクI/Oに関する資源の取り合いが発生し、仮想マシンのパフォーマンスが劣化してしまう、またはそのデータストアに配置される仮想マシン全体に影響してしまうことも考えられます。パフォーマンス劣化する仮想マシンが、重要であればあるほど、問題が大きくなりますので、そのようなことが起きたとしても、影響をできるだけ少なくする必要があります。それが、仮想マシンのI/O優先順位を”整える”という機能(Storage I/O Control)です。

3-11

図1:複数の仮想マシンがデータストアを共有する= IOリソースの共有

この機能はストレージの能力に余裕がある場合では発動しませんが、ストレージの能力が枯渇した際(競合状態)に発動されることになります。図2のグラフは、仮想マシンのI/O優先順位を整えるよう設定した各仮想マシンの稼働状況になります。Phase1~3 は、いずれもストレージの能力が枯渇している時間となっており、単一ホストではなく、複数のホストに跨っていても状況を理解し、優先順位に応じて各仮想マシンからのI/O が整えられています。
各仮想マシンの優先順位は予めVM5(4000) >>> VM3,4(750) > VM1,2 (500) としております。
()内は仮想マシンに設定したシェア値です。

Phase2 の時間帯では、非常に高い優先順位を設定している仮想マシン(VM5)がシャットダウンされたことにより、使えるストレージ資源に空きが生じます。稼働している他の仮想マシンは、Phase1 の時より多くのストレージ資源を使えるようになっているため、各仮想マシンのパフォーマンスが向上しています。そして、再びPhase3 でVM5を起動すると、ストレージ資源が優先的にVM5 に提供されるようになります。仮想マシンのI/Oを整えることにより、ストレージ資源を有効活用し、たとえ枯渇したとしても、vSphereの機能で影響を最小限にすることできます。

3-22

図2:シェア値(優先度)の違いにおける負荷の様子

仮想マシンのI/Oの優先順位を整えるという説明をしてきましたが、Storage I/O Controlはストレージが一時的に資源不足になった際の対応策となります。常時発動されているという状況は配置している仮想マシンに対して、常にストレージの資源が足りていないということになりますので、恒久的な対策が必要になります。
例えば、1つのストレージ(データストア)の能力を上げるという方法もありますが、vSphere のEnterprise plusエディションでは、ホストと同じように複数のデータストアをデータストア クラスタとして、”束ねる”ことができます。データストア クラスタに資源が足りなくなった際、新たにデータストアを追加し、データストア クラスタのトータルの資源を簡単に増加させることが可能になります。例えば、100iops,100GBの資源を提供可能なデータストアが3つ登録されているデータストアクラスタは、300iops,300GBのひとつの資源と考えることができるようになります。

3-33

さらに自動的にこのデータストアクラスタを有効活用できるStorage DRS という機能を使用すれば、データストア クラスタ内(複数のデータストア間)で、過去の統計情報を基に負荷や容量を自動的に整えてくれます。自動的に整えられる際は、第1回でご紹介したStorage vMotion を使用し、システム停止させることなく行われます。※ホストのDRS と同様に手動モードで実施することも可能です。

仮想化環境において、ストレージ環境を整える機能を活用することにより、ストレージの負荷や容量を監視しながらの仮想マシンの配置、移行といったIT管理者の負荷を減らす事ができ、仮想環境の特性を活かしたより有効的な使用ができるようになります。

まとめ
今回、vSphere Enterprise plus エディションで提供している機能(ストレージに対する負荷や容量を自動的に整える機能)をご紹介させていただきました。主にESXiが10台以上となる環境では積極的に使用していただきたい機能になります。人間で例えると骨盤のずれで偏りができてしまうと、肩こりや頭痛など体全体の調整を崩してしまったり、本来のパフォーマンスが出せなかったりすることがあるかと思います。この「ズレや偏り」を治すため、整体やマッサージ等コンディションを整えたりします。ストレージでも同様、IOや容量の偏りが原因でシステム全体に影響がでてしまい、本来もっている能力を出せないことは非常にもったいないことです。是非vSphereの機能を有効活用していただき、仮想基盤のコンディション(すなわちパフォーマンス)をさらに高めていただければ幸いです!!

3-4
VMware青山健二/中村朝之

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

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

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

vCenter Orchestratorを使ってみる(1)

Orchestrator の第3回目です。
今回は、vCenter Orchestrator を実際に操作してみたいと思います。

第2回でご説明致しました通り、OrchestratorはvCenterのライセンスに含まれますので、追加のライセンスコストは不要です。よって、vCenterのライセンスをお持ちの方であればすぐにお使い頂くことが可能です。かつ、Windows環境であればOrchestratorはインストール済みですので、サービスを起動して頂ければすぐに使える状態にあります。

以降は、OrchestratorがインストールされているWindows環境を想定した手順をご説明していきます。

・Orchestratorの構成

まずは、”VMware vCenter Orchestrator Configuration”、”VMware vCenter Orchestrator Server”という2つのサービスを起動します。

Picture1

スタートメニューから、「すべてのプログラム」-「VMware」を選択して、”vCenter Orchestrator Home Page”を開きます。Orchestrator Serverを構成するために、Orchestrator Configurationをクリックします。

Picture2

以下のデフォルトの情報でログインします。
Username  :vmware
Password  :vmware

Picture3

初めてのログイン直後にパスワードの変更を求められるので、新しいパスワードを入力して下さい。
左ペインからネットワークを選択し、IPアドレスのドロップダウンボックスからOrchestratorのIPアドレスを選択し、”Apply changes”ボタンを押下します。

Picture4

左ペインからAuthenticationを選択します。
Windows環境では、Authentication ModeはSSOになっています。(SSO以外の認証方法としてLDAPを設定することができますが、Windows環境では特にSSOから変更する必要はないかと思います。)

Picture5

左ペインからLicensesを選択します。
“Use vCenter Server license”を選択し、vCenterの”Host”、および適切なユーザ名/パスワードを入力して下さい。

Picture6

左ペインからStartup Optionsを選択します。
Authenticationの変更等を行った際には、vCOサーバを再起動して下さい。

ここまでが、Orchestratorを使用する前準備です。

 

・vCenter Orchestrator Clientからの操作

スタートメニューから「すべてのプログラム」-「VMware」を選択して、” vCenter Orchestrator Client”を選択します。Windows環境の標準はSSOですので、SSOで認証が受けられるユーザにてログインして下さい。

Picture7

ログイン後、Workflowsタブを選択すると、事前に構築されたワークフローのライブラリ一覧を確認することができます。vCenterに対する処理のライブラリだけでなく、SSHやSQL等のプラグインによって提供されるライブラリも確認することができます。

Picture8

今回は、vCenterに対して事前定義されたワークフローを実行してみたいと思います。

「Library」-「vCenter」-「Virtual Machine management」-「Snapshot」配下にある仮想マシンに対するSnapshot処理のワークフローを使用します。
「Create snapshots of all virtual machines in a resource pool」を選択して右クリックし、「Start Workflow」を選択します。これにより、特定のリソースプール配下に存在する全てのVMに対して一括してスナップショットを作成することが可能となります。

Picture9

「Not Set」をクリックします。

Picture10

test1、test2が所属するTest-RPを選択します。選択後に「Submit」を押下することで、test1、test2の2台のVMに対してSnapshotが作成されることを確認してみましょう。

Picture11

次に、「Remove snapshots of a  given size」を選択することで、ある一定以上にSnapshotのサイズが大きくなったVMを対象にして、Snapshotを削除することが可能となります。
Snapshotのサイズが大きくなることによるシステムに与える影響は非常に大きいですが、Orchestratorの基本機能を使うことによりvSphere環境を安定的に稼働させることが可能となります。

以下は、Snapshotサイズが100MBを超えた際に、Snapshotを自動的に削除する設定を行った例です。

Picture12

また、スケジュールタスクとしてWorkflowを保存することも可能です。
これによって、定期的にSnapshotサイズをOrchestratorに監視させることで、Snapshot運用時のリスクを最小化することが可能となります。以下は、「Recurrence」を「Every Day」に設定していますので、一日一回Snapshotサイズをチェックするワークフローの構成例となります。

Picture13

・Workflowの実体

事前定義されたWorkflowを選択してSchemaタブを選択すると、そのWorkflow内で実際に行なわれる処理の流れを確認することができます。

以下は、Snapshotを作成するだけの単純な処理となりますので非常にシンプルですが、より複雑なWorkflowの構成になっている処理もありますので、参照してみて下さい。

Picture14

また、createSnapshotをダブルクリックすると、その処理のコードの内容を確認することもできます。実際にSnapshotを作成するためのJavascriptのコードを確認することができるので、何かJavascriptを使って自動化する既存の仕組みなどがあるようであれば、参考になるかと思います。

Picture15

ここまでは、事前定義された2つのワークフローを使用することで、自動化できるSnapshot関連の処理について見て来ました。今回はご紹介できておりませんが、事前定義されたワークフローを複数組み合わせることで、より複雑な処理をOrchestratorによって自動化することが可能です。クラウドの実現に向けた自動化の要件を満たす最適なツールですので、是非一度触ってみて頂ければと思います。

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

4回目:vCenter Orchestratorを使ってみる(2)
5回目:vCloud Automation Centerとのインテグレーション

 

アーカイブ
1回目:プライベートクラウド実現に向けた自動化のニーズ 
2回目:vCenter Orchestratorのアーキテクチャ

 

押さえておきたいvSphereの基本-可用性編 vSphere HA/FT

押さえておきたいvSphere の基本」の可用性編の1回目として、前回、vSphere DRSをご紹介しました。
今回は、2回目として、ホスト障害の際にも仮想マシンの稼働を最大化する機能、vShpere HA、vSphere FTに関して順にご紹介します。

vSphere HA

ESXiホスト上で稼働している仮想マシンは、そのホストが障害で止まってしまった場合、稼働停止を余儀なくされます。
vSphere HAは、ホスト障害により止まってしまった仮想マシンを他の正常なホスト上で再稼働する機能を提供します。

HA-FT-3

例えば3台のホストがvSphere HAで構成されている上記の様なケースで、真ん中のホストが何らかの障害により止まってしまった場合、このホスト上で動いていた仮想マシンは停止してしまいます。この障害を検知すると、他の正常なホスト(上記の場合は左右ホスト)が仮想マシンを自動的に再度稼働させます。vSphere HA を利用することにより、ホスト障害の際にもサービスのダウンタイムを最小限に抑えることが可能となります。

物理環境の仮想化への移行の理由は、有り余る物理ホストのリソースの有効活用と、ホスト集約によるTCOの削減というところが多いのですが、仮想環境へ移行すると、vSphere HA が利用可能となり、可用性が飛躍的に向上するということも大きなメリットの1つです。なお、vSphere HA が利用可能なライセンスに関しては、こちらをご確認下さい。

vSphere HA のその他の特徴としては、以下があります。

・仮想レイヤで提供する機能のためシンプルかつ簡単(一般的なクラスタウェアの様な複雑さはありません)
・OSやアプリケーションを選ばない
・Active-Active構成も可能で、専用の待機系を保有する必要がない

vSphere HAは、vSphere DRS 同様、vCenter Serverで定義されるCluster の1 つのオプション機能です。通常のvSphereの環境が構築されていれば、クラスタの新規作成やvSphere HA の定義、クラスタへのホストの追加等も極めて簡単です。

1. クラスタ作成ウィザードを起動し、クラスタの”入れ物”を作成
HA-FT-7

2. クラスタに参加させるホストをドラックアンドドロップでクラスタへ移動
HA-FT-8

これだけです。vSphere HA の場合、仮想マシンを配置するためのデータストアとしてVMFSやNFS等の共有ストレージが必要ですが、VMFSはデフォルトでクラスタファイルシステムに対応しているため、上記のように簡単にクラスタ環境を構築することが可能となります。この簡単構成もvSphereを利用する大きなメリットの1つです。

vSphere HA 動作詳細

vSphere HAは、各ホスト上で稼働する、Fault Domain Manager (FDM) と呼ばれるAgentによりその機能が提供されています。vSphere5.0以降に採用された FDM では、サーバの死活を監視するため基本的にクラスタに1台存在するマスターノードとその他のスレーブノード間でハートビートが実行されます。このハートビートが途切れたことをトリガーに仮想マシンの再稼働等の動作に移るというのが大まかな動作となります。

HA-FT-4-1

vSphere 4.xまでは、FDMの代わりにAutomated Availability Manager (AAM)という仕組みが採用されていました。以前のAAMと比較したFDMの特徴は下記の通りです。

・プライマリ/セカンダリホストの概念はない
・ハートビート用に管理ネットワークとストレージデバイスの両方を使用
・vSphere HA ではエージェントの配布/構成の並列処理が可能になり、クラスタの構成完了までの時間が大幅に短縮

HA-FT-5-2

vSphere 4.x時代の vSphere HAと区別するため、以降、

vSphere 4.x時代のvSphere HA・・・AAM
vSphere 5.0以降のvSphere HA・・・FDM

と記載させていただきます。FDM を構成する要素は下記の通りです。

・マスター
 すべてのスレーブホストをハートビートにより監視
 保護対象の仮想マシンのリストと電源状態を監視
 スレーブ障害時は、仮想マシンをフェールオーバー
 HAクラスタの構成管理と、構成変更時のスレーブへの情報通知
 クラスタ状態を定期的にvCenter Server にレポート

・スレーブ
 ローカルで動作している仮想マシンの実行状態の監視、及びマスターへの通知
 マスターホストの監視(マスター障害時はスレーブの中からマスターを 1 台を選出)

・ハートビートデータストア
 ハートビートデータストアは、AAMにはなかったFDMの独自の機能の1つで、管理ネットワークの通信断時にホストの死活判断を行うための仕組みを提供します。スプリットブレーンを排除するため、AAMではゲートウェイへの疎通確認のみ実装されていましたが、FDMではハートビートデータストアも利用可能となり、ネットワークパーティションに対するより強固な対応が可能となります。ハートビートデータストアの特徴は以下の通りです。

マスターによる障害検出の流れ
・スレーブからのハートビートが停止
・ハートビートデータストアにアクセスし、該当ホストのロックを調べる
 1. ロックされていない場合
  ホスト障害と判断
 2. ロックされている場合
  隔離アドレスへのpingを実施
 2-1. 疎通する場合
  ネットワークパーティション状態と判断
 2-2. 疎通しない場合
  隔離状態と判断

HA-FT-13

vSphere HA では上記のようにホスト障害を検知し、仮想マシンをフェールオーバーします。

vSphere HA オプション

vSphere HA を構成する際のオプションである、アドミッションコントロールと仮想マシンの監視に関してご説明します。

アドミッションコントロール
ホスト障害時に全ての仮想マシンを確実にフェールオーバーさせるためには、フェールオーバー用のサーバリソースをあらかじめ確保しておく必要があります。vSphere HA ではその仕組みのことをアドミッションコントロールと呼びます。

HA-FT-9

例えば上記の様な 3 ホストの vSphere HA クラスタの場合、各ホストのリソース使用量を 60% 以下に抑えておけば、いざ、ホストが1 台障害を起こした場合でも全ての仮想マシンを他の2 ホストにフェールオーバーすることが可能です。この必要なリソースを確保しておく仕組みをアドミッションコントロールと呼び、以下の設定がサポートされています。

 ・ホスト障害の台数を指定(デフォルトで 1 ホストが設定されている)
 ・CPU / メモリ毎に割合を指定
 ・フェイルオーバーホストの指定

 ※この他、アドミッションコントロールを無効にすることも設定上は可能ですが、ホスト障害の際仮想マシンのフェールオーバーに失敗するリスクがありますのでお勧めできません。

HA-FT-12

仮想マシンの監視
仮想マシンの監視は、仮想OSが何らかの原因でハングしてしまったような場合に仮想マシンをリセットする機能です。仮想マシンの監視には以下の3種類があります。

・無効(デフォルト)
・仮想マシンの監視のみ
・仮想マシンとアプリケーションの監視

仮想マシンがハングしたかどうかの判断には仮想マシンにインストールするVMware Tools及び、仮想マシンのIOステータスが利用されます。VMware Toolsのハートビートが設定時間内に受信出来ず、かつ、仮想マシンのIOも確認できない場合、仮想マシンがハングしたと判断され、仮想マシンがリセットされます。アプリケーションの監視を利用する場合は、本機能をサポートしたサードパーティ製のアプリケーション監視ソフトウェア、もしくはEnterprise PlusライセンスでサポートされるApp HA によるアプリケーション監視の仕組みが別途必要となります。

HA-FT-14

vSphere FT

上記でご説明したvSphere HAは、ホスト障害時に仮想マシンが一度落ちてしまいますが、vSphere FTを利用することでそのダウンタイムを0 にすることが可能です。vSphere FTは、vSphere HAで構成されたホスト上の仮想マシンに対して有効化することが出来ます。つまり、vSphere FT は、vSphere HAで既に保護された仮想マシンの中から、可用性を極限まで高めたい仮想マシンに対して設定を有効化するということになります。

vSphere FTの概要
仮想マシンに対してvSphere FTを有効化すると、プライマリ仮想マシンのコピー(セカンダリ仮想マシン)が他のホスト上に作成されます。プライマリ仮想マシンとセカンダリ仮想マシンはFTネットワークを介して常に同期しており、万が一プライマリ仮想マシンが稼働しているホストが障害で止まってしまった場合は、セカンダリ仮想マシンがすぐさま処理を引き継ぎます。さらに、3ホスト以上でvSphere HAが構成されている場合には、3台目のホストに対しセカンダリ仮想マシンが作成されます。このため、ホスト障害時においても、vSphere FTにより可用性が担保されない時間を極めて短くする仕様となっています。

HA-FT-16-2

vSphere FTの動作詳細
 1. vMotionネットワーク経由で、異なるホストにプライマリ仮想マシンのコピー(セカンダリ仮想マシン)が生成 される
 2. プライマリ仮想マシンにて発生するディスク読み込み、パケット受信、各種デバイスからの入力、 HW割り込み等をキャプチャし、
  VMkernel内のFTログバッファに格納(Record)
 3. ログをFTログネットワーク経由で、セカンダリ仮想マシンに転送
  転送されたログに基づき、セカンダリ仮想マシン上で、プライマリ仮想マシンと同じ処理を並列実行(Replay)
 4. ディスクへや各種デバイスへの出力等のアウトプット処理はプライマリ仮想マシンからのみ行われる
   セカンダリ仮想マシンからのアウトプットはVMkernel上で廃棄され、実際には行われない
 5. FTログネットワーク経由で、プライマリ – セカンダリ仮想マシン間の死活監視を行う
   障害が検出されるとフェールオーバー処理を実行

HA-FT-17

vSphere FTの制限事項
上記したとおり、vSphere FTは極めて高い可用性を実現できますが、以下の機能を利用することが出来ません。
 ・マルチvCPU(VMは1vCPU構成のみ可能)
 ・MSCS構成
 ・RVI/EPT(自動的にOffになる)
 ・準仮想化ゲスト
 ・ホットプラグデバイス
 ・NPIV
 ・VMDirectPath
 ・スナップショットを持った仮想マシン
 ・Storage vMotion
 ・物理互換RDM
   など。詳細は、vSphere可用性マニュアル、及び、KBをご確認下さい。

まとめ
vSphere HA/FTは共に、特殊なハードウェアや難しいクラスタウェア等のソフトウェアを必要としない高可用性の仕組みを提供します。
物理環境からvSphere環境へ移行するだけでvSphere HAがサポートする高い可用性が手に入るというのは仮想化導入の大きなメリットとも言えますし、さらに高い可用性が必要な場合は、少し制限事項も多いですが、vSphere FTをご検討頂ければと思います。

今回は、押さえておきたいvSphereの基本の可用性編としてvSphere HA/FTを取り上げました。押さえておきたいvSphereの基本の他のシリーズに関しては、下記リンクをご確認下さい。

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

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

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