Home > Blogs > Japan Cloud Infrastructure Blog

VMworld 2014からの注目セッション第5回 – Recovery as a Service (RaaS) with vCloud Air

皆さんこんにちは。VMware高木です。

 

8月末に米国サンフランシスコにて開催されましたVMworld 2014の注目セッション5回目は、セッション番号HBC1534、Recovery as a Service (RaaS) with vCloud Airについてご紹介します。

001

日本ではサービス提供予定をこの夏に発表したばかりの『vCloud Air』は、VMwareが提供するクラウドサービスの総称です。そのクラウドサービスの1つとしてDisaster Recovery(RaaS)が提供されています。※日本ではQ4(10月〜12月)中にDisaster Recoveryサービスが開始される予定です。

 

それでは、本セッションの紹介に入って行きたいと思います。画面左側のデータセンターは、既にvSphereを使ってサーバ仮想化を実現しているユーザ環境を示しています。そのvSphere環境の災害対策として、vSphere上の仮想マシンを、右側のvCloud Air上のDisaster Recovery(RaaS)専用リソースに保護する、というサービスです。

 

ちなみにユーザ環境のAD/DNSは、vCloud Air上のIaaSサービスのVPC(Virtual Private Cloud=共有型クラウド)リソース上のADと連携していますので、AD/DNSも保護されていることが分かります。

002

以下、vCloud Air Disaster Recoveryの主な特徴です。

・Disaster Recoveryサイトを自前で用意する事なく、vSphere上の仮想マシンの災害対策が行えるため、コスト効果が高いクラウドベースのDisaster Recoveryサービス。

・vSphereの基本機能である非同期レプリケーション、vSphere Replicationを使って仮想マシンを保護、フェイルオーバーする。

003

その他の特徴は以下の通りです。

・仮想マシンごとにレプリケーション、フェイルオーバーを任意に設定。

・レプリケーションでは、15分〜24時間のRPOを設定。

・最初の同期では、ディスクを配送しオフラインで移行する事も可能。

・1年間に2回までのフェイルオーバーテストが可能。※1回のテストは7日間まで。

・実際にvCloud Air側にフェイルオーバーした際には、30日間まで本番稼働することが可能。

004

このDisaster Recoveryサービスは、Disaster Recovery(RaaS)用のVDC(Virtual Data Center)リソースを購入する事により使用出来ます。

 

まず、ベースとなるVDCリソースを購入頂きます。

□10GHz vCPU

□20GB vRAM

□1TBストレージ

□10Mbpsの帯域

□2つのパブリックIP

□2回のフェイルオーバーテスト

期間は1ヶ月、12ヶ月、24ヶ月、36ヶ月から選択出来ます。

005

ベースとなるVDCリソースでは足りない場合、それぞれオプションで追加する事が出来ます。

ストレージ、帯域〜フェイルオーバーテスト等、幅広いリソースをオプションとして追加できます。

006

最初の同期では、オフラインでデータを移行する事が出来ます。

 

vCloud ConnectorのODT(Offline Data Transfer)機能を使って、保護対象の仮想マシンをexport、vCloud Air側にimportする事により、最初の同期で帯域を圧迫させる心配はありません。特に保護対象の仮想マシンの容量が大きい場合には効果的です。

007

vCenter Web Clientとフルに連携しているため、普段お使い頂いているvCenterから操作が可能です。

008

vSphere Repliationのトラフィックは、SSLでセキュリティが担保されますので、安心してお使い頂けます。

009

vCloud Air Disaster Recoveryを使用する上での要件は以下の通りです。

・vSphere 5.1以上

・vSphereは、Essential Plus以上のエディション※Essential ではvSphere Replicationが使用できない

・vCenter 5.1以上

・vSphere Replication仮想アプライアンス5.6以上※最新のvSphere Replication 5.8では設定画面等日本語化されています

・インターネット環境に出られる事

010

次に、実際にvCloud Air Disaster Recoveryを使って仮想マシンを保護する設定方法を見て行きましょう。まず、vSphere Replicationを使うので、vSphere Replication 5.6の仮想アプライアンスを展開し、vCenterに登録します。このvSphere Replication 5.6にはセキュアにvCloud Air Disaster Recoveryへのレプリケーションを実現出来る機能が含まれています。

011

そして、レプリケーション先となるvCloud Air側のVDCのAPIを確認します。確認は、vCloud AirのWeb UIから行います。

012

確認したら、vCenterから、vSphere Replicationのターゲットサイトの登録を行います。確認したVDCのAPIをコピーしたら、その内容をターゲットサイト先情報として入力します。

013

ターゲットサイトとしてVDCを登録したら、次にターゲットとなるネットワークを設定します。テスト用には、外部との疎通が取れないIsolatedネットワーク。リカバリ用には外部との疎通が可能なRoutedネットワークを設定します。※vCloud Air側には、予め内部通信用のIsolatedネットワーク、外部通信用のRoutedネットワークの2つが準備されています。

014

続いて、保護対象の仮想マシンごとに、vSphere Replicationの設定を行います。レプリケーション先としては新しいメニューとなる”Replicate to a cloud provider”を選択します。

015

すると既にターゲットサイトとして登録したVDCが表示されますので、そちらを選択。後は、通常のvSphere Replication同様にVSSを使う or 使わない、RPOは何分(15分〜1,440分)という設定をするだけです。

016

通常のvSphere Replication同様にvCenterからvSphere Replicationのモニタリングや操作が行えます。

 

最後にvCloud Air Disaster Recoveryのメリットをもう一度お伝えして、第5回注目セッション『HBC1534、Recovery as a Service (RaaS) with vCloud Air』のご紹介を終わりたいと思います。

 

・災害対策用として、自前でDisaster Recoveryサイトを建てる必要がない。=コストを抑えてvSphere環境の災害対策が始められる。

・vSphere Replication機能を使って仮想マシンを保護するため、既存のvSphere環境に別途製品を購入する必要がない。SANベースのレプリケーションも不要です。

・普段お使い頂いているvCenterから操作ができる。

・仮想マシン単位で簡単に保護できる。=アプリケーションの保護要件に応じて、個々の仮想マシンに別々のポリシーを適用できる。

・初回の同期で帯域を消費しない様、オフライン移行が可能。

・vCloud Air Disaster Recoveryリソースは柔軟に追加が出来る。=保護対象の仮想マシン数に応じて、スケールアップ、スケールアウトが可能。

 

引き続き、VMworld 2014の注目セッションブログにご期待下さい。

VMworld 2014 からの注目セッション 第4回 – DevOps (後編) – 継続的デリバリーと VMware vRealize Code Stream

皆様こんにちは、VMware の町田と申します。 今回は、8月末に米国サンフランシスコで開催されたVMworld 2014にて発表された数あるトピックより、日本でも注目が高まってきている DevOps  に関連するセッションの内容を取り上げながら、VMware のクラウド管理ソリューションを Dev(開発)とOps(運用)の協調という視点からご紹介する記事の [後編]となります。

はじめに

[前編]の記事はこちらになります:

また先日発表された、 DevOps における継続的デリバリー ソリューションである VMware vRealize Code Stream について、[前編]の内容もここでおさらいしておきます。 ~~~ VMworld 2014 EUROPE の開催に合わせて、日本でも2014年10月15日(日本時間)付けでクラウド管理プラットフォームの最新版「VMware vRealize Suite 6」を含む、新たなクラウド管理製品群と機能群を発表しました。この中で、DevOps における継続的デリバリーを実現する「VMware vRealize Code Stream」という製品も発表されています。この製品が、VMworld 2014 US で[Tech Preview]として紹介された Continuous Delivery for DevOps の正式名称となります。 ~~~

リリースパイプライン管理とアーティファクト管理

「VMware vRealize Code Stream」 は、[前編]で紹介した Application Services のアプリケーション展開を管理するという考えをもう一歩進めて、開発チームの継続的統合(CI)環境と連携することで、各環境へのアプリケーション展開を含めたリリースパイプライン全体の自動化の実現(継続的デリバリー)を目指すものです。

vmworld2014-4-devops-7-0

次の図は、「Dev (開発)」、「Test (テスト)」、「UAL – Load (ユーザ受け入れ、負荷テスト)」、「SIT – Staging (システム統合テスト – ステージング)」、「Production (本番)」という5つのステージをもつリリースパイプラインをあらわしており、ステージによって AWS、プライベートクラウドといった別の環境にアプリケーションが展開されることが想定されています。

このような環境で、各ステージ内では「プロビジョニング」「テスト」「デプロイ」「カスタム」「アーティファクト」といった個々のタスクを外部のツール(例えば Jenkins や Artifactory、vCAC、vCO のカスタムワークフローなど)と連携しながら実行してアプリーションをクラウド環境上に展開していきます。各ステージ間には「ゲート」が存在し、例えば「前のステージのテスト実行結果が100%のときだけ次のステージに進む」「前のステージで人手による受け入れテストの実行結果が90%以上の時に、管理者が承認をすることで次のステージに進む」といった自動化が可能になります。

vmworld2014-4-devops-7-5

継続的デリバリを実現するリリースパイプラインの管理ツールとしては、アジャイル開発における Thought Reader である ThoughtWorks 社の Go などがありますが、VMware がこのカテゴリのツール開発に力を入れている背景には、SDDC 環境への移行を推進されているお客様からの声として、IaaS を超えた、クラウド環境におけるアプリケーションのリリース作業全体の管理を実現できる製品に対するご要望が多くなってきたことがあります。

その他のトピック

ここからは、 DevOps に関連するセッションの中から、個人的に気になったものを簡単にご紹介します。

1. VMware vCloud Air

VMware がグローバルで提供するハイブリッドクラウドサービスである vCloud Air (日本でも2014年7月にに、日本での提供が開始される予定であることをアナウンス)ですが、VMworld のセッションスライド内でも 「DevOps」 がうたわれています。

vmworld2014-4-devops-8-3-0

vCloud Air の文脈でも、アプリケーションのリリースにかかる時間について言及されています。

vmworld2014-4-devops-8-3-1

“Infrastructure as Code” を実現するツールとして Chef のプラグインが紹介されていました。

vmworld2014-4-devops-8-3-2

また、DevOps サービスとして「CI – as-a-Service」 を提供予定であるというアナウンスもありました。今後、開発者と運用者の生産性を向上させるためのツールが vCloud Air 上にサービスとして展開されていくという期待ができます。

vmworld2014-4-devops-8-3-3

2. Pivotal CF

開発者の目線で言うと、IaaS++ 、つまりApplication Services が提供する機能を使って頑張るというのは、結構面倒に感じます。開発者が欲しいのは、究極的には API を提供する黒箱と、アプリケーションを監視するためのツール そんなことを、VMworld 2014 のあるセッションのスライドは語っています。

vmworld2014-4-devops-8-1-0

これはまさに PaaS の世界です。 Pivotal CF と vCAC、[Tech Preview] Continuous Delivery for DevOps がインテグレーションする世界についても語られていたのですが、これが中々面白いです。 vCAC のカタログ管理とセルフサービスポータルの機能とインテグレーションすることで、 Pivotal CF のサービスなどの管理性が非常に向上します。 また、Continuous Delivery for DevOpsのようなツールからすると、vCAC も Pivotal CF もアプリケーションのプロビジョニング先、つまりエンドポイントとして見えるようになります。リリースパイプライン管理の対象となるクラウド環境に、Pivotal CF のような PaaS がインテグレーションされるというのは夢が広がります。

vmworld2014-4-devops-8-1-2

vmworld2014-4-devops-8-1-3

なお、冒頭で「開発者の目線でいうと結構面倒」といいましたが、これまでのやり方をできるだけ変えないで、物事を漸進的に進めていくために、多くのエンタープライズにとって IaaS++ のアプローチはとても重要だと考えています。

3. Docker / Fargo(VMfork)

VMworld 2014 のセッションでは、VMware の DevOps ソリューションを Docker と組み合わせた場合に取りうるアプローチについて、3つの方面からまとめていました。

vmworld2014-4-devops-8-2-1

この図の中で、Docker コンテナが実行する箱として「VMfork」と書かれているのが興味深いです。VMfork とは VMworkd 2014 で「Project Fargo」として紹介されていた仮想マシンの超高速クローニング技術のことで、実行中の親仮想マシンから 子仮想マシンを fork させる時に、仮想ディスクのリンククローン+メモリも差分管理することで、ms のオーダーで新しい仮想マシンを用意できるようにするものです。

vmworld2014-4-devops-8-2-3

コンテナ技術は仮想化を使わなくても良いという話も聞きますが、コンテナをホストするリソースが足りなくなれば、物理か仮想かは置いておいても新しいリソースを追加する必要はあります。コンテナをサポートするSDDC 上で、Docker コンテナをサポートする仮想マシンが超高速で展開される、そういった組み合わせも面白いと思います。

vmworld2014-4-devops-8-4

最後に

[前編][後編]の2回にわたって、VMware のクラウド管理ソリューションをDevOps の視点からご紹介しましたが、いかがでしたでしょうか?繰り返しになりますが、本記事が、これまで主にインフラの観点から VMware に触れていただいている方々が、DevOps という観点から VMware のクラウド運用管理製品や周辺技術に対して目を向けていただける一つのきっかけになりましたら、大変うれしく思います。

VMworld 2014 からの注目セッション 第4回 – DevOps (前編) – SDDCとIaaS++

皆様こんにちは、VMware の町田と申します。 今回は、8月末に米国サンフランシスコで開催されたVMworld 2014にて発表された数あるトピックより、日本でも注目が高まってきている DevOps  に関連するセッションの内容を取り上げながら、VMware のクラウド管理ソリューションを Dev(開発)とOps(運用)の協調という視点から前編・後編の二回に分けてご紹介します。

はじめに

VMworld 2014 では、多くのエンタープライズ環境がソフトウェアデリバリプロセスにおいて抱える 「安定かつ継続した、ビジネスのスピードにあわせた俊敏なリリース」「コスト削減」「変更への柔軟な対応」などの課題に対して、VMware  のクラウド管理ソリューションの導入がもたらす価値について、特に DevOps の視点から複数のセッションが提供されました:

この中で筆者が特に注目する内容としては、MGT3210-S セッション内で [Tech Preview] として紹介された「Continuous Delivery for DevOps」 があります。こちらについては、本記事の[後編]でご紹介します。

vmworld2014-4-devops-0-1

※ 補足: 最新情報

~~~

VMworld 2014 EUROPE の開催に合わせて、日本でも2014年10月15日(日本時間)付けでクラウド管理プラットフォームの最新版「VMware vRealize Suite 6」を含む、新たなクラウド管理製品群と機能群を発表しました。この中で、DevOps における継続的デリバリーを実現する「VMware vRealize Code Stream」という製品も発表されています。この製品が、VMworld 2014 US で[Tech Preview]として紹介された Continuous Delivery for DevOps の正式名称となります。

~~~

また、その他で DevOps と関連するものとしては、以下に挙げるセッションがありました。

vCloud Air 環境での”Infrastructure as Code” の実現や、VMware vCloud Automation Center (vCAC)と Puppet の連携、vCAC と PaaS (Pivotal CF) の連携、今ホットな Docker といった、さまざまなテーマで DevOps と絡めた話題が出ていました。

余談

いきなり話が逸れますが、企業が 大変な労力とコストをかけてアプリケーションを開発/テストして、さらなる労力をかけてリリースして運用、保守しているのは、(当然のことですが)ビジネスの価値を高めるためであり、それらは間接的にはアプリケーションを使うことによる業務効率の向上であったり、直接的には売上の増加であったりします。ITシステムに対する要求管理は、今も昔もアプリケーション開発における最も難しいテーマの一つです。

ところで、皆様の組織では、 アプリケーションに対するたった一行のソースコードの変更を本番環境に反映させる(リリースする)までに、どれぐらい時間がかかるでしょうか?また、そのプロセスは安定かつ繰り返し可能なものでしょうか?

サイクルタイム

この問いは、リーンソフトウェア開発有名なポッペンディーク夫妻の書籍で投げかけられているものです。

“How long would it take your organization to deploy a change that involves just one single line of code? Do you do this on a repeatable, reliable basis? “

(Mary Poppendieck; Tom Poppendieck, “Implementing Lean Software Development, Addison-Wesley Professional, 2006”)

ITシステムがビジネスの要求に対していかに「俊敏」に対応できているか常に振り返るためのきっかけとして、非常に示唆に富んでいます。ITによるビジネスの俊敏性向上とは、サイクルタイムをいかに短く、かつ安定したもにできるかにかかっていると言えるからです。「ビジネス」と言ってしまうと新規アプリケーション開発をイメージして、Ops(運用)の方々にはあまり関係のない話に思われるかもしれませんが、ここでの「変更」とは、リリース後の機能追加や、バグの緊急修正及びリリースなど、システムを利用する多くの利害関係者からの、継続的な要求への対応を含んでいます。

より技術的な観点からは、「継続的デリバリ」のバイブルである書籍の著者であるジェズ・ハンブル氏らが書いている言葉が心に響きます。

“Release your software at the push of a button.” 

(Jez Humble; David Farley, “Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation”, Addison-Wesley Professional, 2010”)

ソフトウェアのリリースは、(究極的には)ボタンを一回押すだけで完了できてしかるべきもの、ということでしょうか。

変えないで済む、そして大きな成果を生む

脱線ついでに、もう一つ余談を。

ハイパーバイザーが実現する仮想化には、1つの美学があると思っています。それは

  • OSより上で動作するものや、それに関連するものに対して、これまでとまったく変わっていないという幻想を与える

ことです。Docker などのコンテナ技術が注目を集めている今では時に過小評価されるかもしれませんが、新しい技術を組織に導入して浸透させていく際には極めて重要な性質です。変わっていないということは、大部分において、これまでのやり方をそのまま踏襲できるということです。ITの世界ではとにかく目新しく、革新的な(に見える)技術が目を引きがちですが、VMware はそういった中長期的な将来のIT基盤のあり方を変えるようなテクノロジーにも注視する一方で、物理環境から仮想化基盤、そしてその上で従来のアーキテクチャに基づいて作成されたアプリケーションを展開して運用しているような環境から、漸進的にSDDC、そしてハイブリッドクラウド環境へと移行していけるようなソリューションに力を注いでいます。

IT業界で話題になるテクノロジや手法は、 エンジニアを多く抱えたWeb系の最先端IT企業が中心になって推進しているケースが多く、エンタープライズのITでそのまま導入しようとした場合にまったく新しいやり方や、高度な技術的スキルが要求されることも多いです。やり方が新しければ新しいほど、組織構造や業態、技術者のスキルセットと照らし合わせた場合に、採用のための障壁が高くなります。

これから構築していく新しいアプリケーションに対しては、新しいやり方を試すのはそれほど難しくないかもしれません。

では、すでに構築して運用・保守しているアプリケーションのライフサイクルを、これからどうやって管理していけばよいでしょうか?今やモバイル・クラウド時代に突入し、ビッグデータやサービス指向のアーキテクチャも Web サービスの普及とともに広がってきています。

アプリケーション開発チーム

アジャイルソフトウェア開発宣言が公開されたのは2001年のことですが、それから13年、欧米ではすっかり主流の開発手法となっています。

vmworld2014-4-devops-2-1-2

VMworld 2014 のセッションでも、Facebook、LinkedIn などの先端的な Web 系企業では1日に10、100、もしくはそれ以上の回数アプリケーションをデプロイしているような例も語られていました(これは極端な例かもしれませんが)。

vmworld2014-4-devops-2-1

アジャイル開発の考え方の最大の特徴の一つは、要求管理の方法にあります。アジャイルは「変化に対応する」ための開発方法とも言えますが、それはひとえに「要件に優先順位をつけて、必要な時に必要なものをジャスト・イン・タイムで計画して作る」「最初に想定していても、必要ないとわかった時点で作らない」点にあります。つまり、ウォーターフォールのようにプロジェクトの最初期で時間をかけて「計画」された要件に縛られるようなことはありません。

アジャイル開発では、従来からの「スコープ」「コスト」「スケジュール」というソフトウェア開発における「鉄の三角形」に代わり、「(リリースされるソフトウェアによって実現される)価値」「品質」を変動できないものとしてとらえ、プロジェクトの制約となる要素のうち「スコープ」を調整することで、変化に対応しながらも安定かつ継続したリリースを実現します。

vmworld2014-4-devops-2-2

ここで、頻繁にリリースされるソフトウェアの品質を支えるのが、ソースコードのバージョン管理、テスト駆動開発(TDD)及びテスト自動化、継続的統合(CI)といった、ツールを活用した自動化及び各種のプラクティスとなります。

ただし、仮にアジャイル開発を採用し、うまく現場でまわすことができていたとしても、それだけでは開発チームの悩みは尽きることはないでしょう。

従来からのクライアント-サーバ、あるいはWeb 3階層モデルなどに従ってアプリケーションを設計した場合、デプロイ可能な成果物が完成した後のリリース作業はコストのかかる、骨の折れる作業であることには変わりありません。この要因としては、多くの人員や手作業が必要なケースが多いことや、構成管理が大変なこと、インフラの準備のための時間と工数、また(特にエンタープライズでは通常だと思いますが)「開発チーム」と「運用チーム」をはじめとする複数の組織が関わっていることなどが挙げられます。リリース対象の環境自体も、オンプレの物理環境から仮想化基盤、プライベートクラウド、パブリッククラウドといったように様々な選択肢を検討する必要がでてきており、複雑さとそれに伴うコストは増す一方です。特に、インフラのことについては開発チームだけではなかな手も足もでません。

そのため、AWS などのパブリック IaaS を(シャドーITとしてIT部門を通さずに)利用したり、また最近では PaaS (例えば Pivotal CF など)の検討や、Docker のようなコンテナ技術を活用した新しいアプリケーションの構築、パッケージ化、配布、実行のモデルに注目するケースが増えてきているのでしょう。

これらの根底には、常にアプリケーションリリースのサイクルタイムへの意識があります。

インフラ運用チーム

ここ数年来、仮想化技術が広く普及したこともあり、物理サーバを仮想化基盤に統合してコストを削減するという考え方は、ごく普通のことになりました。VMware では、(VMware の考える) エンタープライズのIT基盤及び組織が進むべき道として、最近では次のようなスライドを使って説明しています。

vmworld2014-4-devops-3

Ops (運用)の視点から見た場合、例えばエンドユーザのPC利用環境(仮想ワークスペースも含む)の整備などは、アプリケーション開発が絡まない、ITを活用したビジネス生産性向上のための投資といえます。

アプリケーション開発ライフサイクルにおける開発チームの課題と最近の動向については先ほど触れましたが、そこで

特に、インフラのことについては開発チームだけではなかなか手も足もでません。

と書きました。SDDC、ネットワークの仮想化、ストレージの仮想化、ハイブリッドクラウド、クラウド運用管理・・・、インフラ管理者にとって新しい技術や概念が目白押しです。そのような中、競争の激しいビジネスからの要求に応えるため、一秒でも早いサイクルタイムの実現のため、多くの課題を抱えながらアプリケーション開発を続ける開発チームに対して、インフラ及びOps (運用)チームは今何が求められるでしょうか?

Dev と Ops を隔てる壁

特にエンタープライズではその傾向が強いと思いますが、システム開発のライフサイクルにおいては、一般にDev(開発) と Ops (運用) には高い壁があるケースが多いです。

次のスライドは、VMworld 2014 の複数のセッションで使われていたものです。

端的に言うと、両者の利害は一致していません。

開発チームはインフラやアプリケーションのリリースに対するスピードを求め、一方で運用チームはその職務上、安定した運用及びトラブルの予防のためにできるだけ変化がないこと、そして厳しく管理することを求めます。

開発チームはビルドしてデプロイ可能になった成果物を運用チームに渡します。開発チームが掌握できるローカルのテスト環境はまだしも、ユーザ受け入れテスト環境、負荷テスト環境、ステージング環境、そして本番環境・・。開発チームの手を離れてから、実際にアプリケーションが利用可能になるまでに、どれぐらいの時間がかかるでしょうか。アジャイル開発を導入している組織で、デプロイ可能な成果物は1週間に1回リリースできても、インフラ側で環境にデプロイして運用に持っていくまでのスピードが対応できないため、結局実際にアプリケーションが本番環境にリリースされるのは3ヶ月~半年に1回、という例もあるようです。

この壁は、もし存在するのであれば今後もずっと存在していてよいものでしょうか?

DevOps とは?

実は、この壁は先ほどご紹介したような1日に10、100、もしくはそれ以上の回数アプリケーションをデプロイするような環境の企業には存在していません。

Wikipedia によると、DevOps とは

DevOps(デブオプス)は、ソフトウェア開発手法の一つ。開発 (Development) と運用 (Operations) を組み合わせたかばん語であり、開発担当者と運用担当者が連携して協力する開発手法をさす。ただし2013年現時点では厳密な定義は存在しておらず、抽象的な概念に留まっている。

とあります。

物事を最適化する方法として、holistic approach (全体論的アプローチ) という言葉が使われることがありますが、アジャイル開発における「チーム」もこのようなアプローチであり、DevOps も開発と運用が連携して協調することで、これまで(誰もがうすうす感づいていながら)システム開発ライフサイクルにおいて非効率であった部分(特にサイクルの後半)に対応していこうとするものです。

vmworld2014-4-devops-5-2

ただ、注意点としてこのような取り組みは、ややもすると「組織論」に偏りがちです。体制を変えていく必要があるのは大前提なのですが、複雑さを増す一方のクラウド時代の今、手作業と人間によるコミュニケーションでの改善には限界があります。是非、ツールには適切に投資し、最大限活用することをご検討ください。これはベンダーの立場での都合の良い意見とも取れますが、ITが魔法のような速度で世の中やビジネスを変えているのはソフトウェアの力(とそれを支える強力なインフラ)であり、ツールは特定の目的を最適に実現することを目指して作られたソフトウェアです。

[今できること] SDDC と IaaS++

DevOps のような開発と運用が交わるような領域において、作業の協調、高度な自動化、ハイブリッドクラウド環境への対応、といった技術的にも複雑な取り組みを着実に推進していくためには、そのインフラとなるしっかりとした土台が欠かせません。その中で、VMware がご提供可能なものとしては、SDDC のビジョンを実現する VMware のクラウド運用管理製品を中心としたソリューションになります。

vmworld2014-4-devops-6-1

開発チームはこれまでも、開発・テスト環境の準備という観点で非常に苦労してきました。例えば開発者のPC環境のセットアップもその一つです。VMware Workstation などの仮想化製品を使って、PC上にテンプレートから展開した開発・テスト環境を用意するケースも多いと思います(最近では Vagrant がよく話題に上りますね)。

SDDC をベースとする強固な土台を導入していくことで、クラウド環境を使ってこれらの作業を支援し、さらなる効率化を進めることが可能です。

例:

  • NSX によるネットワーク仮想化によって、テスト環境の仮想マシン群に対して隔離された論理(L2)ネットワークを個別に提供
  • vSAN によるストレージ仮想化によって、ストレージのコスト及び管理工数を削減しつつ、必要に応じてリソースをスケールアウトできる、開発環境に最適なクラスタを構成
  • vCAC のポータルを通して仮想マシンの提供を含む各種のサービスを統合していくことで、管理性を保ちながらも、必要なリソースがセルフサービスですぐに手に入る環境を開発者に対して提供

これらは一例ですが、開発、テストにおける作業効率の向上、そしてサイクルタイムの短縮につながります。

ここまでは、システム開発ライフサイクルにおける「ビルド」「テスト」といった主に開発チームの作業をインフラとして支援する範囲となりますが、DevOps という観点から見た、VMware ソリューションとしての 最初のターゲットは、アプリケーションのデプロイ作業の最適化です。

vmworld2014-4-devops-6-1-2

VMware では、仮想化基盤あるいは IaaS 上への仮想マシンのプロビジョニング及び構成に加えて、アプリケーションのデプロイ及び構成管理を含めた部分を簡素化及び自動化するためのソリューションをご提供しています(VMware ではこれを IaaS++ と表現することもあります)。

このソリューションは、以前は VMware vFabric Application Director という名称でしたが、vCAC の一部として統合され、さらに vCAC 6.1 では Application Services と名称が変わっています。

Application Services のクラウド管理製品としての特徴は、n階層の構成を含むアプリケーションをGUIツールを使ってブループリントとしてモデル化し、同一のブループリントから AWS、vCloud、vCAC といった様々なクラウド環境に対してアプリケーションをデプロイできることです。これにより、開発環境、テスト環境、本番環境といった、要件によって異なる環境に同じ構成のアプリケーションを何度もデプロイしなければいけないケースで、一貫性を確保した、安定したデプロイ環境を構築することができます。このような要件は、今後は前提として検討しなければならなくなるでしょう。

vmworld2014-4-devops-6-4

アプリケーションのブループリントは、使用するOSの仮想マシンテンプレートを指定する「Logical Templates」、そのOS上で動作するDBなどのミドルウェアを指定する「Services」、そしてさらにミドルウェア上にデプロイされるアプリケーションを指定する「Application Components」などで構成されます。これらの要素は、GUIパレット上でドラッグ&ドロップして、要素を積み重ねることで関係を表現します。また、仮想マシンのプロビジョニングやアプリケーションのデプロイの順番は、依存関係を表すラインで要素間を結ぶことで表現します。

vmworld2014-4-devops-6-5

「Services」や「Application Components」などの要素は、ミドルウェアやアプリケーションを仮想マシン上にインストールして構成する動作を指定する、重要な役割を担っています。「Services」を例にとると、これらは「Apache v.2.2.0」「vFabric RabbitMQ v2.4.1」「MySQL v5.0.0」といった個々のミドルウェア毎に管理され、それぞれがApplication Services におけるアプリケーション展開のライフサイクル(INSTALL, CONFIGURE, START, UPDATE, ROLLBACK, TEARDOWN)において行うべき動作を、スクリプトとして記述しています。これらの要素は、スクリプト及び(デプロイ時にカスタマイズ可能な)プロパティからなるテンプレートに過ぎません。なお、このスクリプトですが、Windows では「Windows CMD」「PowerShell」「BeanShell」が、Linux では「Bash」及び「BeanShell」がサポートされています。

vmworld2014-4-devops-6-8

Application Services ではブループリントで定義された依存関係から個々の要素の実行順序が導き出され、仮想マシンのプロビジョニング後にそれぞれのスクリプトが順番に呼び出されることによってアプリケーションの展開が実行されていきます。

また、Application Services ではアプリケーション展開後にも、同一のインスタンスに対して一部の構成を変更した上での「Update」や、変更後にエラーが見つかった際の「Rollback」、アプリケーションの取り壊しを行う「TEARDOWN」、そして削除といったライフサイクル管理を行うことができます。

vmworld2014-4-devops-6-9

“Infrastructure as Code” を実現する Puppet や Chef などのツールを使ったことのある方なら、例えば次のような DSL 定義を思い浮かべられたかもしれません(これは Puppet のマニフェストの一例です)。

Application Services は、まさに同じようなことを、異なるアプローチで実現するツールといえます。

vmworld2014-4-devops-6-6

 Application Services はクラウド環境における “Dev” と “Ops” の協調作業プラットフォーム

IaaS++ として Application Services についてご紹介してきましたが、DevOps という視点でまとめると、Application Services とは「クラウド環境における “Dev” と “Ops” の協調作業プラットフォーム」です。仮想化基盤やクラウドの管理者は環境毎の仮想マシンテンプレートやテナントを準備し、カタログ管理者はスクリプトの作成などで開発者、運用者と連携しながら「Services」や「Application Components」のカタログを管理し、アプリケーションアーキテクトはアプリケーションブループリントを作成します。各環境へのリリース段階では、デプロイヤがブループリントを利用し、環境毎のプロパティ値をカスタマイズした上でデプロイし、その後も連携しながらライフサイクルを管理する。このような、クラウドインフラを含めたアプリケーション展開の構成管理を、一つのツールを使って実現することができます。

vmworld2014-4-devops-6-7

なお、開発者とは「成果物」の管理を通して連携しています。例えば、開発チームが CI ツール (Jenkins) でビルドして作成するアプリケーションのモジュールを Application Services 側に登録して、ブループリントで指定された「Application Components」が実行時にそのモジュールをダウンロードしてインストールする、といった連携が実現できます。

vmworld2014-4-devops-6-11

Puppet Integration

Bash などのスクリプトを使うと聞いて、「うげっ」と思われた方もいるかと思います。時代は DSL ではないのか、宣言的な、あるべき状態の記述ではないのかと。ご安心下さい。Application Services では Puppet とのインテグレーションもサポートしています。これにより、アプリケーションの展開プロセス全体のオーケストレーションや仮想マシンのプロビジョニングは Application Services が行いますが、各仮想マシン上の構成は Puppet Master 及び Agent におまかせする、ということも可能です。vCAC 6.1 ではインテグレーションもさらに強化されています。

vmworld2014-4-devops-6-10

個人的には、Bash / PowerShell などの良く使われているツールを使うことができるもの、既存資産の有効活用や、今までと大きくやり方を変えないで済む点で、特にエンタープライズ環境ではメリットの一つだと考えます。

最後に

本記事が、これまで主にインフラの観点から VMware に触れていただいている方々が、DevOps という観点から VMware のクラウド運用管理製品や周辺技術に対して目を向けていただける一つのきっかけになりましたら、大変うれしく思います。

なお[後編]では、先日発表された新製品である VMware vRealize Code Stream を中心に、VMware が今後視野に入れている DevOps 関連のソリューションについて、VMworld 2014 でのセッション内容を交えてご紹介する予定です。

VMworld 2014 から第 3 回 – Virtual SAN Ready Node と Hardware Guidance

VMworld 2014 からの注目セッションの第 3 回目は、Software-Defined Data Center 向けの Software-Defined Storage である Virtual SAN (VSAN)を導入する際のシステム構成に関するガイドをご紹介します。

How to Build a Virtual SAN – Virtual SAN のシステム構成について

Virtual SAN を導入するには、現在 3 つのアプローチがあります。

  1. Virtual SAN Ready Node で構成
  2. VMware Compatibility Guide に掲載されている ESXi + Vitual SAN 対応のハード、コンポーネントで構成
  3. コンバージドインフラ(統合インフラ)製品である EVO:RAIL を利用

EVO:RAIL については、本シリーズの第 2 回目に説明がありますので、今回は Virtual SAN Ready Node による構成方法と VMware Compatibility Guide を参照しながらの構成方法について説明します。

1. Virtual SAN Ready Node による構成

Virtual SAN Ready Node とは、サーバ OEM ベンダより提供される Vitrual SAN 推奨構成です。VSAN で必要となるハードウェアコンポーネント、vSphere と Virtual SAN が事前に構成されているので、システム構築時間を大幅に短縮することができます。また、構成のプロファイルとして、サーバワークロード向け(Low, Medium, High)と VDI ワークロード向け(Full Clone、Linked Clone)の 5 つのプロファイルが用意されており、導入するシステムのワークロード、規模に合わせて選べるようになっています。

VSAN-Rdy-Step1 VSAN-Rdy-Step2

 

この Virtual SAN Ready Node の構成詳細は、VMware Virutal SAN Ready Nodes  で確認可能で、8/15/2014 版のガイドでは、8 社のサーバ OEM ベンダから 40 種類の構成が Virtual SAN Ready Node として登録されています。

VSAN-Rdy-Node

Virtual SAN Ready Node としては、将来以下のようなコンフィグレーションもリリースされる計画があります。

    • Ready Nodes for Blade Servers with Direct Attached Storage
    • Ready Nodes with High Density Storage From Factors
    • Ready Nodes with Hardware Checksum Protection
    • Ready Nodes with Hardware Encryption
    • Ready Nodes with end to end 12G support
    • Ready Nodes with NVMe devices for super-charged performance
    • Ready Nodes with All Flash

2. VMware Compatibility Guide で Virtual SAN 対応のハード、コンポーネントを確認して構成

Virtual SAN は、Virtual SAN Ready Node に掲載されている機器だけでなく、Virtual SAN 動作認定されているコンポーネントを組み合わせて自由に構成することも可能です。Virtual SAN を利用するには、ホストが最小 3 台、内蔵 HDD と SSD とクラスタを構成するためのネットワークが必要となりますので、要件に合わせる形で構成していきます。

VSAN-Req

 

基本的には、導入する ESXi バージョンに対応したハードウェアで構成しますが、SSD、HDD、SAS/SATA コントローラ(ストレージコントローラ)については Virtual SAN 用の VMware Compatibility Guide  がありますので、ここに掲載のあるコンポーネントで構成します。

VSAN Build Your Own

VSAN-BYO-VCG

それでは、この VMware Compatibility Guide に沿って構成していきます。

1. I/O Controller

I/O Controller セクションで、Virtual SAN でサポートされる I/O Controller (ストレージコントローラ)と対応しているデバイスドライバが確認可能です。

VSAN-BYO-IOcontrollerリストに出てくるコントローラの詳細を確認すると、そのカードでサポートされている RAID モード(Pass-Through モードか RAID0)、ESXi やデバイスドライバのバージョンを確認することができます。

2. HDD

Virtual SAN は、SAS、NL SAS、SATA HDD をサポートし、大容量向けの 7,200 RPM、パフォーマンス向けの 10,000 RPM、より高いパフォーマンス向けの 15,000 RPM のドライブの中から構成します。

3. SSD

SSD についても、HDD 同様に Virtual SAN 対応しているもので構成する必要があります。SSD については Performance Class という項目があり、構成時に SSD のパフォーマンスを考慮する事が出来るようになっています。

Performance Class:
 Class B: 5,000-10,000 writes per second
 Class C: 10,000-20,000 writes per second
 Class D: 20,000-30,000 writes per second
 Class E: 30,000+ writes per second

4. その他のパーツ

サーバ本体(3 台以上 32 台まで)、NIC、ESXi 起動用デバイスについては、お使いになる ESXi のバージョンでサポートされているもので構成します。

Hardware Solution Guidance

ここでは Virtual SAN 用のハードウェア構成上の注意点について説明します。

起動用デバイス

ESXi 起動用デバイスについては、ESXi ホストに搭載されているメモリ容量に依存します。

  • メモリ容量が 512GB 未満
    Virtual SAN 領域とは別の磁気ディスクや SSD、容量 4GiB 以上の容量を持った SD/USB
  • メモリ容量が 512GB 以上
    Virtual SAN 領域とは別の磁気ディスクや SSD

フラッシュデバイス

Virtual SAN において、全てのリード・ライト処理は、フラッシュ階層に直接渡されます。また、Virtual SAN では、フラッシュベースのデバイスは 2 つの目的に利用されます。

  1. 不揮発性のライトバッファ(容量の 30%)
  2. リードキャッシュ(容量の 70%)

Virtual SAN においては、フラッシュデバイスの選択は、最もパフォーマンスに影響するので、製品の選択には注意を払う必要があります。

磁気ディスク (HDD)

SSD の選定と、SSD:HDD の比率は、クラスタの性能を左右します。大まかなガイドラインでは、10% となります。

ストレージコントローラ

SAS/SATA ストレージコントローラに関するガイドは以下のものがあります。

  • Pass-Through モードと RAID0 モードをサポート
  • ストレージ コントローラーのキュー深度が重要
    より深いストレージコントローラーのキュー深度はパフォーマンスを向上させる
    参考:キュー深度は、VMware Compatibility Guide で確認可能
  • ストレージコントローラがサポートするドライブ数を確認する必要がある
  • RAID0 モードを利用する場合の SSD の性能は、ストレージコントローラに依存
  • RAID0 モードの場合、ESXi はフラッシュベースのデバイスと磁気ディスクを区別できない場合がある
    その場合は、esxcli コマンドを使用し、デバイスを SSD とするフラグを立てる
    参考:Enabling the SSD option on SSD based disks/LUNs that are not detected as SSD by default (2013188)

ネットワーク

ネットワークに関するガイドは以下のものがあります。

  • 1Gb / 10Gb をサポート(10Gb を強く推奨)
    1Gb の場合は、Virtual SAN 専用のネットワークとすることを推奨
  • ジャンボフレームにより僅かながら性能向上する可能性あり
    新規デプロイの場合は有効にする
  • Virtual SAN は仮想スイッチと分散仮想スイッチをサポート
    備考:Virtual SAN のライセンスに分散仮想スイッチのライセンスも含まれます
  • ネットワーク帯域の性能は、通常のワークロードよりも、ホストの待機やリビルドに対して大きな影響を与える

最後に

VMware Compatibility Guide は、比較的頻繁にアップデートされていますので、Virtual SAN 環境を構成/構築される場合は、その都度サポート状況を確認するようにして下さい。

 

デルストレージEqualLogicと VMware vCenter Operations Managerの連携をご紹介!

みなさん、こんにちは。

VMware vCenter Operations Manager(vC Ops)にはストレージと連携できる機能が用意されております。今回はデルストレージEqualLogicと連携した機能を vExpert 2014でもあるデル株式会社の中川明美様にご紹介していただきます。それでは中川様よろしくお願い致します。


 

こんにちは!デル株式会社の中川明美です♪

前回デルストレージCompellentとVMware vCenter Operations Manager(vC Ops)の連携をご紹介させていただきましたが、今回は、私デルの中川明美よりDellのストレージ 「EaualLogic」と連携する「Dell EqualLogic Adapter for VMware vCenter Operations Manager(EqualLogic vCOPS Adapter)」についてご紹介します。vC OpsとEqualLogicストレージが連携することにより、EqualLogicストレージの構成コンポーネント(Groups/Members/Pools/Volumes)をvC Opsのオブジェクトとし、関連する他のオブジェクト(ホスト/データストア/仮想マシン)と同じ画面で表示することが可能です。またEqualLogicストレージのパフォーマンス情報から仮想基盤の問題原因分析の一つの手段とすることも可能です。

 

Dell EqualLogicとvC Opsとの関係

下図は、Dell EqualLogicコンポーネントとvC Opsとの関係を示しています。

Dell EqualLogicが提供するコンポーネントには、「EqualLogic SAN Headquarters」「Dell EqualLogic Statistics Agent」「Dell EqualLogic vCOps Adapter」があります。


EqualLogic SAN Headquartersから収集したデータを、SAN HeadquartersサーバーにインストールしたDell EqualLogic Statistics AgentとDell EqualLogic vCOps Adapterが連携し、vC OpsのDell EqualLogicダッシュボードに表示します。SAN Headquarters (SAN HQ) は、EqualLogic標準の監視ツール(フリーツール)です。SAN HQを使用してもEqualLogicのパフォーマンスを監視することはできますが、vSphere環境とは連携していませんので、どの仮想マシンのワークロードが問題に関与しているかを分析するために時間を要する場合も考えられます。

eql_1

 

vC Opsのおさらい

vC OPSでは分析結果を、ダッシュボードに「健全性」「リスク」「効率」のスコアを「バッジ」と「」で表示します。このバッジの色で、緊急性があるのか、将来に問題があるのか、さらに統合率を高めることができるのかを一目で判断できます。緑なら「現在問題がない」、オレンジなら「近い将来に問題が発生する可能性がある」こと示しています。

eql_2

 

Dell EqualLogicダッシュボードにアクセス!

EqualLogic vCOPS Adapterを準備したら、Custom UI(https://UI仮想マシンのIPアドレス/vcops-vsphere/)に接続します。下図が接続後の画面です。「ダッシュボート」メニューから、Dell EqualLogic用の4つのダッシュボードに切り替えることが可能です。

eql_3

EqualLogic & VMware Relationship Dashboard~構成要素のつながりを一目で把握~

最初に、EqualLogicと連携した仮想化基盤を把握できる「EqualLogic & VMware Relationship」ダッシュボードを確認しましょう。このダッシュボードは、vC OpsのvSphere UI(標準UI)と同様のバッジで健全性スコアを表示します。仮想マシン、その仮想マシンのファイルが格納されたデータストア、仮想マシンが配置された ESXi ホスト、それらと関連性のあるEqualLogicの各コンポートを可視化します。

「EqualLogic-VMware Relationship View」では各リソースの状態を、「健全性ツリー」では、関連したリソースの階層構造と各リソースの健全性とアラート数を表示します。健全性ツリーで表示されたアラートの詳細が「Alerts」に表示されます。他に画面下部に「Metric Sparklines」と「メトリックグラフ」が表示されます。

下図では、「EqualLogic-VMware Relationship View」で赤色表示されている「nkgw-vmfs01」Volumeを選択し、「健全性ツリー」で関連するリソースを表示しています。「Alerts」にはこのデータストアの「残り時間」アラートが表示されています。

eql_4

残り時間のアラームをドリルダウンすると、健全性の推移やVolumeの詳細情報まで得ることも可能です。

eql_5

EqualLogic Top-N Reports Dashboard

さらに詳細なパフォーマンス情報を確認したいのであれば、このダッシュボードを使用します。

9つのメトリックに関する、最も高い使用率Top25のVolumeを表示します。最大容量、空き容量、最大遅延などその他パフォーマンスに関する情報を確認するために使用します。

  • Total I/Os per second•
  • Write I/Os per second•
  • Read I/Os per second•
  • Total KB per second•
  • Write Latency•
  • Read Latency•
  • Queue Depth•
  • CVolume Capacity•
  • Least Free Space

eql_6

 

EqualLogic Storage At a Glance Dashboard

EqualLogicの全コンポーネントの概要を表示します。

画面左側の「Group Selector」「Pool Selector」「Volume Selector」ではEqualLogicの各コンポーネントの健全性を色と数値で表示し、画面右側の「Metrics Sparkline」では、画面左側で選択したコンポーネントのメトリックデータを視覚的に表現する小さなグラフ(スパークライン)を使用して表示します。また「Selected Storage Array Health Tree」では、EqualLogicの全コンポーネントの健全性をグラフィカルに表示します。「Alerts」では、EqualLogicグループ内のアラートを表示します。

eql_7

 

EqualLogic Storage Metrics Dashboard

選択したリソース(EqualLogicコンポーネント)のメトリックを詳細に表示します。「Select Resource to View Metrics」で詳細なメトリックを表示したいコンポーネントを選択します。「Select Metrics to Graph」ではグラフ化したいメトリックを選択します。「Metric Graph」でグラフ化されたメトリックが表示されます。

eql_8

 

FirmwareとSoftwareの必要要件

次が各Productの必要要件となります。

EqualLogic Support Siteから入手可能です。https://eqlsupport.dell.com

ストレージ連携機能はvC Opsの「Advanced」エディションから提供されます。

Product Revision
EqualLogic vCOPS Adapter VMware vCenter Operations Manager 5.7.1 以降
Dell EqualLogic Statistics Agent PS Series firmware 6.0.7 以降
SAN Headquarters 3.0, 3.0 1

 

おわりに

EqualLogic vCOPS Adapterの概要をご紹介させていただきました。ストレージを含めた仮想基盤を一目で把握し、管理することができるのは便利ですね。EqualLogicをお持ちのお客様は多いので、ストレージと仮想基盤の管理にお困りであれば是非お声がけください!!

インフラストラクチャ・コンサルティング・サービス本部 テクニカルコンサルタント 中川 明美
eql_9

 

 

新卒 SE 社員が贈る vSphere のキソ! 第7回 ~ 仮想環境となが〜くお付き合いしていくために ~

こんにちは! とうとう本連載もラストとなってしまいました。 新卒 SE 社員が贈る vSphere のキソ! 第7回は私、川崎( Kawasaki )が担当致します。 今回は、「仮想環境となが〜くお付き合いをしていく」をテーマといたしまして、 VMware vCenter Operations Manager (以下 vC Ops)という製品をご紹介して参ります。

〜仮想環境と長くお付き合いする為に…〜

はじめに、環境の運用管理とは何ができれば上手く行えていると言えるでしょうか。状況を正確に把握し、効果的なアクションをとり、より少ないコストで効率的にパフォーマンスを高く維持できれば、良い運用が行えていると言えるのではないでしょうか。この「状況を正確に把握する」という部分が、物理環境から仮想環境へ移行した際に少し難しくなるポイントです。

 

図1.物理環境と仮想環境でのリソース使用の比較

図1.物理環境と仮想環境でのリソース使用の比較

 

本連載の過去の記事でも触れておりますが、仮想環境ではリソースが仮想化され、複数のOSで同一の物理ホストのリソースを共有します。また、物理ホスト間でもリソースをプール化して、全体としての最適な利用が行える点を紹介して参りました。

仮想環境ではゲストOSから見てリソースの使用率が高くないか、だけではなく、他のOSとはリソースの取り合いによるパフォーマンス低下はどれほどか、物理サーバ間でのリソース融通による最適化の機会はないか、といったことも考える必要があります。実際、既に仮想環境をご利用いただいているお客様の中にも、管理に課題を感じていらっしゃる方は多く、以下のようなお声を頂いております。

      公共系 A機関 ご担当者様

「どの物理サーバでどの仮想マシンが稼働しているかをExcelで管理していましたが、何かが起こった際の影響範囲の特定が非常に困難でした。また、一部のシステムでパフォーマンスが落ちてきた場合に、リソースが不足しているのか、アプリケーションに問題があるのかなどの切り分けが困難で、原因究明までにかなりの時間を要していました。」

      メディア系B社 ご担当者様

仮想マシンの配置やキャパシティプランニングはすべてExcelを使って手作業で行っており、非常に手間がかかっていました。さらに仮想マシンで必要となるリソースの割り当てについても、妥当性の基準が明確化されておらず、システムの健全性やリソース配分の効率性を評価できていませんでした。」

これらのお客様には、vC Ops を導入いただき、こういった課題の解決に役立ていただきました。まずは、vCenter と vC Ops での管理方法を比較することで、vC Ops はどのように役に立つのか見ていきましょう。

 

〜vCenterのみでOK?〜

vCenter のみの場合と vC Ops も利用した場合、どのように変わるか、参考ケースを見ながら比較していきます。

≪参考ケース≫
IT管理者のAさんは、 vSphere をベースとした仮想環境の管理を任されています。担当している物理サーバの数は20台ほどですが、仮想マシンのパフォーマンスが悪い場合には、まずAさんが問題を切り分けて、必要に応じてネットワークやストレージ、アプリケーションの各担当者に連絡して対処をお願いしています。

物理から仮想に移行したことで、追加のハードウェアなしにサーバ数を増加させることができ重宝していますが、最近仮想マシン数の増加とともに環境が複雑になり障害原因の特定に時間がかかるようになってきました。また、来年の予算を考えるにあたって追加リソースの申請が必要ですが、仮想マシンごとに負荷も違うためどう考えればいいかわかりません。

  • 障害原因の特定

ここでは、障害原因の特定を行う際を例にとり、管理方法の変化を見てみます。障害の発生を確認した場合の対処までの流れについて、vCenter Server のみを用いた場合と、vC Ops を用いた場合を比較します。全体の流れの一例を示したのが、図2です。

 

図2.障害対応方法の違い:vSphere Web Client と vC Ops

図2.障害対応方法の違い:vSphere Web Client と vC Ops

 

vCenter Server の管理画面である vSphere Web Client や vSphere Client からもホストや仮想マシンに関する様々な情報を収集することは可能です。しかしながら、その情報は多岐にわたるため、広範囲な参照先から得た情報を管理者が統合して判断に結び付ける必要があります。一方で、vC Ops を用いた場合には、障害の監視、関連オブジェクトの参照、各オブジェクトの詳細情報が一括して得られるような設計となっているため、管理者の判断を助け、対処にとりかかるまでの時間も短縮できます。

  • キャパシティ管理

次に、リソースを追加する際の容量計算の流れを例に、キャパシティ管理方法の違いを見ます。同様に vCenter Server のみを用いた場合とvC Ops を用いた場合を比較します。(図3)

 

図3.キャパシティ管理方法の違い:vSphere Web Client と vC Ops

図3.キャパシティ管理方法の違い:vSphere Web Client と vC Ops

 

vCenter Server を用いた場合、多くの状況ではそのデータをExcel等で集計しなおすことが多いのではないでしょうか。ホストや仮想マシンの割り当て容量をExcelに集計し、vCenter Server で得られるパフォーマンス情報とユーザーからのヒアリングを元に適切な容量を考えます。

そして、それをもとにキャパシティ不足の仮想マシンや追加の仮想マシン用のリソースを計算します。このような流れの問題点は、Excelでの管理に時間がかかる点、また、本当に必要な容量を知ることはかなり困難で、結局のところ安全策として必要以上のリソース割り当てとなりがちな点です。

一方で vC Ops を用いた場合には、現状の把握はダッシュボードから一目瞭然で、適切な容量の計算も、ホストとしては残り容量の表示が、仮想マシンとしてはサイジングの過不足に関する表示があり、クリックするだけで、一覧で見ることができます。

また、追加リソースに関しては、推奨されるオーバーコミット率に従って考え、実際に任意のサイズの仮想マシンとリソースを追加して試算を行うことで、必要な容量であることを簡単に知ることができます。最後にこれらの情報をファイルとして出力して説明の根拠とすることができます。

 

以上まとめますと、vCenter Server のみを用いた仮想環境の管理では、以下の2つの課題がありました。

①  vCenter Server だけでは長年の経験と専門スキルを要する (工数と時間がかかる理由)

② 運用メンバーの管理手法が属人化している (人手で集約・集計している結果)

そしてこれらの課題を vC Ops は次のように解決します。

①  vC Ops 上の表示の確認で済む (工数と時間を短縮)

②  vC Ops が自動で集計・分析する (工数の削減と根拠の明確化)

 

〜vCenter Operations Managerの概要〜

それでは、 vC Ops自体の説明に入って参ります。はじめに、 vC Ops を導入した場合の環境構成から説明いたします。 vC Ops は2つの仮想アプライアンスが展開され、 vCenter Server から収集したデータを解析し、表示します。(図4) vCenter Server は一つまたは複数を対象とすることができます。

図4.vCenter Operations Manager の構成

図4.vCenter Operations Manager の構成

集めたデータは、 vC Ops で解析されます。この解析により、各リソースの数値データは単にグラフ化されるのではなく、仮想環境は良いパフォーマンスを発揮しているのか、何かとるべきアクションはあるのか、といった管理者にとって役立つ情報として表示されます。ダッシュボードと呼ばれる vC Ops の基本画面は以下のような見た目となっております。(図5)

図5. vC Ops ダッシュボード画面

図5. vC Ops ダッシュボード画面

このダッシュボード画面は、左から“健全性”、“リスク”、“効率”の縦3列に分かれており、それぞれ以下のような内容を表しています。

  • 健全性  :「現在の状況」    障害やパフォーマンス低下について
  • リスク    :「将来の予測」    = 今後のパフォーマンス低下要因はないか、リソースは十分か
  • 効率     :「構成の最適化」         = 構成を変更することで、リソース節約の可能性はあるか

これらの指標(“バッジ”と呼びます)によって、管理者はひと目で環境の特徴を把握できますし、必要であれば詳細な情報も掘り下げて見ていくことも可能です。例えば、ある仮想マシンについて性能劣化の要因を調べる際には、関連するオブジェクトを一括して表示することで、どこに原因があるか突き止める大きな助けとなります。(図6)

図6.関連するオブジェクトを一括表示

図6.関連するオブジェクトを一括表示

また、個別のオブジェクトに関してそれ自体の情報を詳細に見る、という意味では、図7のような画面から確認できます。

図7.個別オブジェクトの詳細情報表示

図7.個別オブジェクトの詳細情報表示

他にも vC Ops では俯瞰的な見方から、詳細に特化した見方まで、情報の表示のされ方は豊富に用意されています。これにより、実際の運用管理の場面でも、その時々の目的に応じた情報を得ることが可能となります。   このような vC Ops の機能は、評価版を展開して実際にご使用いただくことで、さらによく確認していただけます。評価版のインストールガイドは操作ガイドとともにリンク先の記事にございますので、ぜひご活用ください。

http://blogs.vmware.com/jp-cim/2014/07/vcops_operations_guide.html

vC OpsとvSOM〜

vSOM という製品をご存知でしょうか? vSOM は、「 VMware vSphere with Operations Management 」の略で、 vSphere と vC Ops のスタンダードエディションが合わさったものになっています。(図8)vC Ops のライセンスは通常「25仮想マシン数単位のライセンス」に対し、 vSOM のライセンスは vSphere 同様CPU単位のライセンスとなります。したがって、vC Ops を利用される際に、「仮想マシン数が将来増加する可能性もあるなぁ…」という場合には、vSOM を入手することで仮想マシン数を意識する必要はなくなります。

図8.vSOM は vSphere と vC Ops のセット製品

図8.vSOM は vSphere と vC Ops のセット製品

詳細は弊社ウェブページをご覧ください。(http://www.vmware.com/jp/products/vsphere-operations-management/

〜第7回まとめ〜

vCenter Operations Manager を紹介して参りましたが、いかがでしたでしょうか?本製品のことが少しでも理解され、使うことによるメリットも感じていただけましたら幸いです。こちらの製品は、ハンズオンラボでも体験可能ですので、ぜひお試しください。(http://labs.hol.vmware.com/HOL/catalogs/  ラボ番号:HOL-SDC-1401)

〜本連載まとめ〜

さて、本シリーズは「新卒 SE 社員が贈る vSphere のキソ!」と題しまして、4名の新卒SEにより全7回でお贈りして参りました。”新入社員の目線”として先輩SEの皆様とは多少異なるテイスト?で連載して参りましたがいかがでしたでしょうか?何はともあれ、本シリーズを通じて少しでもVMware製品の理解を深めていただけましたらとても嬉しいです。

私どもは今年の4月に入社しほぼ知識がないところからのスタートでした。VMwareに関する勉強には少なからず苦労しておりますが、わかってくると楽しく、ついつい時間が過ぎてしまうこともしばしばです。今後初めてVMwareを導入されるユーザ様や提案されるパートナー様におきましては、新しい概念や用語で苦労されるかもしれません。

その際は本連載を読み返していただくと幸いです。私たち自身も日々勉強することも多いですが、皆様のご指導も受けながら一緒に盛り上げていけましたらとても嬉しく思います。vForum 2014でもセッションを持ちますので是非お越しください!

最後になりましたが、お読みいただき誠にありがとうございました。
VMware新卒社員 SE 氏田裕次/川崎一青/椨木正博/野田裕二

新卒 SE 社員が贈る vSphereのキソ!
第1回 vSphereを俯瞰する
第2回 仮想環境におけるネットワークとストレージ
第3回 vMotionとvSphere HA/vSphere FTの違いとは?
第4回 仮想マシンの配置管理はDRSにお任せ!
第5回 様々な仮想マシンが混在&混雑しても大丈夫!?ネットワーク と ストレージの帯域を維持する仕組み
第6回 vSphere でココまでできる!データ保護
第7回 仮想環境となが〜くお付き合いしていく

VMworld 2014 からの注目セッション 第2回 – Software-Defined Data Center と Hyper-Converged Infrastructure他

皆様こんにちは、VMwareの塚田と申します。

今回は、8月末に米国サンフランシスコで開催されたVMworld 2014にて発表された数あるトピックより、比較的大きな注目を集めたVMware EVO:RAILに関連するセッションを取り上げ、より詳細な情報をご紹介致します。

VMworldでは、VMware EVO:RAILに関連するセッションが複数提供されました。本ブログ記事ではその中から下記セッションのの内容に沿ってVMware EVO:RAILについて紹介致します。

  • SDDC3245 (Software-Defined Data Center through Hyper-Converged Infrastructure)
  • SDDC2095 (Overview of EVO:RAIL: The Radically New Hyper-Converged Appliance 100% Powered by VMware)

Hypver-Converged Infrastructure – SDDC導入に最適化されたアプローチ

今年のVMworldにおける弊社からの発表、または発信内容のテーマの一つがSoftware-Defined Data Center(以下SDDC )の推進です。

SDDCにおいては、サーバ、ストレージ、ネットワーク等のデータセンター内のハードウェア資源は全てソフトウェアによって仮想化および抽象化され、リソースプールとして利用可能になります。また、それら仮想化されたリソースの運用管理はソフトウェアやAPIによって自動化され、ビジネス部門やITサービスの利用者からの要求に迅速に応えられようになります。

お客様が自社のITインフラをSDDCへ移行させたい、あるいは新規に導入したい、と考えられた時、お客様が取りうる導入方法(アプローチ)は下記の3通りのいずれかであるとVMwareは考えます。

evorail_fig01

  1. Build Your Own(アラカルト)
      • サーバやストレージ、ネットワーク機器などのハードウェア、仮想化ソフトウェア、管理ソフトウェアなどを個別に選択して調達し、お客様に合わせて統合する
      • 利点:お客様の要件に沿ったカスタマイズが可能であり、構成上の自由度が最も高い
  2. Converged Infrastructure(統合インフラストラクチャ)
    • サーバ、ストレージ、およびネットワーク機器が単体シャーシ、またはラック内に工場出荷時に構成済み。ソフトウェアはオプションとして選択可能。
    • 利点
      • パッケージ済みなので購入が容易
      • お客様に合わせてカスタマイズが可能
      • 一本化されたサポート窓口
  3. Hyper-Converged Infrastructure(高度な統合インフラストラクチャ)
    • 仮想化ソフトウェアとハードウェア(サーバ、ストレージ、ネットワーク)がSDDCを前提として統合済み
    • それらのために最適化された管理ソフトウェアも同梱
    • 利点
      • 購入が容易
      • ハードウェアとソフトウェアがSDDC向けに設計済み
      • より短時間で導入可能
      • 一本化されたサポート窓口

SDDC実現への3番目のアプローチであるHyper-Converged Infrastructure の特徴は、その用途をSDDC実現のために絞り込み、導入にかかる事前検討や調整の対象を徹底的に削減していることです。その代わり、カスタマイズの自由度が下がったり、拡張性に制限がかかったりするなどのトレードオフが伴いますが、SDDC実現を最優先にしたアーキテクチャであると言えます。

SDDC向け専用アプライアンス – VMware EVO:RAIL

VMware EVO:RAILは、このSDDC向けのHyper-Converged Infrastructureのアーキテクチャに沿ったハードウェア アプライアンスです。

evorail_fig02 evorail_fig03

VMware EVO:RAILは、2RUのシャーシ内に4台のサーバノードが搭載され、各ノードは次のようなスペックを備えています。

  • Intel Xeon E5-2620 v2プロセッサ(6コア)x 2
  • 192GBメモリ
  • ストレージ
    • 146GB SAS HDD、または32GB SATADOM(ESXiの起動ディスク)
    • 400GB SSD x 1
    • 1.2TB SAS HDD x 3
  • ネットワーク
    • 10Gb Ethernet x 2
    • 100Mbps/1Gbps管理用NIC x 1

また、下記のソフトウェアが予め組み込まれています。

  • vSphere 5.5(Enterprise Plusエディション)
  • VMware Virtual SAN
  • VMware vCenter Log Insight
  • EVO:RAIL Engine

VMware EVO:RAILはサーバノード間の共有ストレージを持っていません。その代わり、各サーバノードが内蔵しているSSDとHDDをVMware Virutal SANによって共有データストアとして使用します。

SDDCの導入と管理の複雑性を排除した管理ソフトウェア「EVO:RAIL Engine」

evorail_fig04

また、EVO:RAIL Engineは、VMware EVO:RAILのための管理用ソフトェアです。お客様は、VMware EVO:RAILの最初のセットアップから仮想マシンの作成など毎日の運用までを、このEVO:RAIL Engineで行うことが可能です。

VMware EVO:RAILをセットアップをする際は、PCからHTML5対応ブラウザを使って接続すれば開始可能です。セットアップにあたってESXiやvCenter Server、VSAN等に関する知識やスキルは必ずしも必要ではなく、インフラのことを意識せず、仮想マシンの作成や運用に専念することが可能です。

セッションでは、EVO:RAIL Engineを使うことにより、VMware EVO:RAILの初期化から最初の仮想マシンを作成するまで約15分で完了するデモを紹介していました。

evorail_fig05

また、EVO:RAIL Engineは最大4台までのVMware EVO:RAILを管理することが可能であり、増設もとても簡単です。2台目以降のVMware EVO:RAILをネットワークへ接続すると、クラスタへ自動的に追加され、コンピュート(CPU, メモリ)とストレージそれぞれの容量が自動的に拡張されます。一般的なサーバ用途の仮想マシンであればVMware EVO:RAIl 1台あたり100台、仮想デスクトップ(VDI)用であれば仮想マシンを同250台まで作成可能です。アアプライアンスを追加することにより、サーバならば最大400台、仮想デスクトップであれば最大1,000台まで拡張することが可能です。

VMware EVO:RAILはOEMパートナーから提供されます

evorail_fig08 evorail_fig09

ここまでVMware EVO:RAILの説明をして参りましたが、VMwareが「EVO:RAIL」というハードウェア製品を開発し販売するわけではございません。この点はくれぐれもご注意ください。

VMwareはVMware EVO:RAILを構成するためのソフトウェア(vSphereやEVO:RAIL Engine等)を開発し、これのOEM契約を結んだパートナー(以下EVO:RAILパートナー)各社へ提供しています。EVO:RAILパートナーが、このEVO:RAILソフトウェアと各社が開発、または調達したハードウェアを組み合わせ、各社それぞれのVMware EVO:RAILアプライアンスを開発し提供します。

本ブログ執筆時点でのVMware EVO:RAILのOEMパートナーは、Dell, EMC, Fujitsu, Inspur, Super Micro、およびネットワンシステムズの6社です。特にネットワンシステムズは、VMware EVO:RAILに基づくアプライアンス製品「NetOne Integrated System Appliance for VMware EVO:RAIL」を10月1日より販売開始することを発表されました(ネットワンシステムズによる発表資料へのリンク)。他のOEMパートナーからも日本国内でのVMware EVO:RAILアプライアンスの発表が続くと予想されますので是非お待ち下さい。

VMware EVO:RAILはOEMパートナーから提供されます

まとめ – VMware EVO:RAILの利点

ここまで述べてきました通り、 VMware EVO:RAILは、VMwareが推進するアーキテクチャ “Software-Defined Data Center” (SDDC)を実現するために特化したインフラストラクチャ アプライアンスです。これを用いる利点を再度まとめてみます。

SDDCのための基盤を最速で導入、構築することが可能。

VMware EVO:RAILは、SDDCのためのインフラとして求められる性能や信頼性、拡張性を備えながら、複雑性を徹底的に排除しています。セットアップ時に必要な設定項目もIPアドレスや管理者のパスワードなど必要最小限にとどめられています。また、ハードウェア、およびソフトウェアが相互に密に連携しています。それらのため、導入後最短15分で最初の仮想マシンを起動することが可能なくらい、SDDCを最速で構築することが可能です。

基盤構築や運用のために仮想化技術やハードウェアの専門知識は必須でありません

VMware EVO:RAILの運用管理は専用の管理用ソフトウェア”EVO:RAIL Engine”を用います。その操作にあたっては、VMware ESXiやvCenter Server等の仮想化ソフトウェア、そしてサーバやストレージ等ハードウェアに関する知識も必須ではありません。また、それらの技術に精通した専門家を雇用しづらい組織や、専門家が配置されていない拠点においてもSDDCのための基盤を導入することが可能です。

拡張が非常に容易、そのため常に最適な構成で利用可能

VMware EVO:RAILは最大4台(サーバノードは最大16台)まで拡張することが可能です。また、増設も非常に容易です。EVO:Engineが増設されたシャーシを認識すると、追加されたCPU, メモリ、HDDやSDD等のリソースが利用できるよう自動的に再構成します。その間も、仮想マシンを稼働させ続けられます。

このように拡張が非常に容易なので、必要になった時にリソースを追加することが可能です。そのため、お客様は常にジャストサイズの構成のVMware EVO:RAILを利用することが可能であり、過剰なリリースを抱える必要はありません。

以上

新卒 SE 社員が贈る vSphere のキソ!第6回 ~vSphere でココまでできる!データ保護~

『新卒 SE が贈る vSphere のキソ!』 第6回は VMware vSphere が可能にするデータ保護機能である、「vSphere Replication(VR)」と「vSphere Data Protection(VDP)」をご紹介いたします。

この二つの機能、どちらも仮想マシンおよび仮想マシン内のデータの保護に用いることのできる機能なのですが、ここでは、 vSphere Replication と vSphere Data Protection を「用途に応じて使用していただく」にはどの様な点に注意を向ければよいかについて述べていきます。

このブログを読むことで、「○○のときには vSphere Replication!」「△△のときには vSphere Data Protection!」と即答できるようになっていただければと思います。

また、今回ご紹介する2つの機能、vSphere Essentials Plus Kit 以上のエディションに同梱されておりますので (エディションについては、こちらでご確認ください)、是非ご活用いただければ幸いです。

 

§1. vSphere Replication と vSphere Data Protection ~「どちらか or どちらも」~

「どちらもデータ保護のためのソリューションであれば、ふたつも必要無いのでは?」と思われるかも知れませんが、vSphere Replication は主に「サイト切り替え時における仮想マシンのすばやい復旧」、vSphere Data Protection は主に「仮想マシンのバックアップデータの保存」という目的が存在し、その目的に応じた違いが存在します(図1)。

 

vRnvDP3

 図1:VR と VDP

 

ここからは、そんな vSphere Replication と vSphere Data Protection のそれぞれの特徴、および使用方法について述べていきます。まずは vSphere Replication から説明いたします。

 

§2. vSphere Replicationとは?

こんにちは、川崎です。読者の皆様は、 vSphere Replication をご存知ですか?ここでは、以下のような疑問やイメージに対して、実際のところをご理解いただければと思います。

  • vSphere Replication って何ができる?
  • 使いこなすのは難しい?
  • 災害対策って高そう。

本稿をお読みいただくことでこのような疑問を解決し、ぜひ vSphere Replication をご利用していただければと思います。では、早速説明を始めていきましょう!

 

§2.1. vSphere Replication による仮想マシンの保護

vSphere Replication は、vSphere に組み込まれたレプリケーション(複製)の仕組みで、仮想マシンにサイトレベルの障害に対する可用性を提供します。全体的な構成のイメージとしては、図2のようになります。

 rep1図2:vSphere Replication による仮想マシンの保護

 

図2で示した環境では、保護サイトにある仮想マシンのうち、緑色にハイライトされたものが特にビジネス継続性の観点から重要で早期の復旧が必要です。 vSphere Replication の保護対象に指定されており、リカバリサイトに複製されてサイト単位の障害に備えています。

vSphere Replication の特徴的な点としては、仮想マシン単位でレプリケーションが行える点管理が vCenter から一元的に行える点が挙げられます。仮想マシンを一つの単位としてレプリケーションを行うことで、システムの中でも早期の復旧が必要な重要な仮想マシンを自由に保護対象として選択することができます。

また、仮想マシン単位のレプリケーションを行うことにより、「ハードウェア非依存」という仮想マシンの特徴をリカバリにおいても活用する事が可能です。このため、ストレージアレイベースのレプリケーションの様に保護サイトとリカバリサイトで同等のストレージを持つ必要がなくなり、容易にディザスタリカバリ(災害対策)を行う環境を構築する事ができる様になります。

さらに、 vSphere Replication による仮想マシンの複製、リカバリといった管理は、 vSphere Web Client から一元的に行うことができます(図3)。

 

rep_home

図3:vSphere Replication は vCenter から一元的に管理

 

レプリケーションの管理が仮想マシンの一般的な管理と統合されていることで、システム管理者はツールごとに使い分ける必要がなく、レプリケーションの計画、作成からリカバリまでを一つの画面で簡単に行えます。

 

§2.2. vSphere Replication の構成要素

まずは、 vSphere Replication の全体的な構成と、そこで登場する要素を抑えていきましょう。例として、レプリケーション先が別のサイトであり、別の vCenter によって管理されている場合は図4のような構成が考えられます。

 

 

rep_arc_simple_v2

図4:vSphere Replication の全体構成と仮想マシン複製の流れ

 

図4では、左の保護サイトにある仮想マシンを、右のリカバリサイトにレプリケーションしています。鍵となる以下の登場人物を覚えましょう。

 vSphere Replication アプライアンス (VR アプライアンス) :vSphere Replication を司る仮想アプライアンスです。vSphere Replication アプライアンスには、仮想アプライアンス管理インターフェース (VAMI) が用意されており、vSphere Replication データベース、ネットワーク設定、公開鍵証明書、アプライアンスのパスワード再構成といった設定はこのインターフェースから行えます。このアプライアンスは ova ファイルとして提供されており、 vSphere ESXi サーバ上に簡単に展開する事ができます。

vSphere Replication Agent (VR Agent):各 ESXi サーバ内にインストールされ、仮想マシンの変更データをリカバリサイトの VR アプライアンスに送信します。これはあらかじめ ESXi にインストールされてあるため、ユーザは意識せずに使用する事ができます。

ネットワークファイルコピー (NFC) :リカバリサイトの VR アプライアンスは、仮想マシンの変更データを受け取ると問題が無いか確認した上で、対象となるESXi サーバを通じて書き込みます。この際、ネットワークファイルコピーを通じて書き込みが行われます。NFC においても VR エージェントと同様に  ESXi にインストールされております。

 

§2.3. 「導入 → 構成 → リカバリ」の流れ

では実際に導入から、レプリケーションの構成、そしてリカバリまでの流れを見てみましょう。全体の流れとしては、下に示されるようにレプリケーションの構成までは3ステップ、リカバリとフェイルバックもそれぞれ簡単な操作で行えるようになっています。

 

rep_step

 

まず、VR アプライアンスを展開するとホーム画面に vSphere Replication というアイコンが出現し、クリックすると vCenter が登録されていることがわかります。レプリケーション先が別の vCenter となる場合は、 vCenter ごとに VR アプライアンスを展開します。次に、ターゲットサイト(リカバリサイト)の vCenter を登録します。ただし、ターゲットサイトとして同一 vCenter 管理下のリソースを使用したい場合には改めて登録の必要はありません。繰り返しになりますが、別の vCenter を登録する際には、ターゲットサイト側にも事前に VR アプライアンスが展開してある必要があります。

これらの準備によってレプリケーションを行うための構成は完了です。対象とする仮想マシンを選択し、レプリケーションの構成を行います。レプリケーションの構成時にはいくつかのオプション機能を設定することが可能です。オプションとしてカスタマイズできる設定には、下記の3つがあります。

  • ž   ゲストOSの静止( VSS 対応)
  • ž   RPO
  • ž   複数時点のスナップショット

ゲストOSの静止は、 vSphere Replication による移行時にアプリケーションの整合性を保ち、データ損失を防ぐ仕組みで、ゲストOSが対応している場合に有効にすることができます。
(「対応OSは「 vSphere Replication 5.5 互換性マトリックス」をご覧ください。)

RPOは復旧ポイントオブジェクティブを指し、リカバリ時に何時間前(あるいは何分前)の状態に戻せることを保障するようにレプリケーションを作成するか、というレプリケーションの頻度を定める指標です。最短15分~24時間の範囲で設定することが可能です。(図5)

仮想マシンのレプリケーションはスナップショットのように複数時点の履歴を同時に保持することが可能です。一日あたりの数と日数を決めることで、「一日3ポイント×一週間」、「一日1ポイント×20日」といった設定を施し、直近の状態だけでなく一定期間前の状態にもリカバリ可能になります。

 

 

rep_rpo

図5:RPO を15分~24時間で設定可能 / 複数時点の履歴を保持可能

 

いざ障害が生じて復旧が必要になった際には、リカバリを行います。ようやく vSphere Replication の本領発揮か!? と思われるところですが、操作としてはごく簡単に、数クリックで完了してしまいます。(図6)まず、レプリケーションもとの仮想マシンが生きているかどうかに応じてリカバリ前に改めて同期するかを選択し、次いでリカバリ先の所属データセンターとフォルダ(選択は任意)、リカバリ先で使用するリソース(ESXi サーバ)を選択します。

 

rep_rcv図6:リカバリは数ステップの選択で完了

 

最後に、フェイルバックを行う際の方法についても説明いたします。フェイルバックは、「リカバリサイトで一時的に稼動させていたが、もとのサイトが復旧したため戻したい」という状況で必要になる作業です。このような場合には、リカバリ先のサイト(ターゲットサイト)からもとのサイト(ソースサイト)に向けて、手動で逆方向のレプリケーション(リバースレプリケーション)を構成することで、 vSphere Replication を用いてフェイルバックを行うことが可能です。ただし、リバースレプリケーション構成前に、ソースサイトの該当仮想マシンはインベントリから登録解除しておく必要があります。これらは全て手動の操作となります。
ちなみに、VMware vCenter Site Recovery Manager という別の製品を用いることで、操作を自動化することができます!

 

§1.4. FAQ ~vSphere Replication

Q.ストレージアレイベースでのレプリケーションとの違いを教えてください。

A.一言で言えばストレージの機能を用いるか、ホスト(ESXi)を用いるかの違いとなります。ハイパーバイザベースのレプリケーションのメリットとしては、低コストでの各仮想マシンのデータ保護、ストレージベンダーの選択の柔軟性、リカバリ用リソースを平常時に有効活用可能、といった点が挙げられます。

 

Q.単一の vCenter で管理された環境内でもレプリケーションは可能ですか?

A. vSphere Replication は同一のサイト内、または同一の vCenter 内でも利用可能です。登録されている vCenter が一つでも、レプリケーション先のストレージを別のものに指定して耐障害性を高めるといった使用が考えられます(図7)。

  rep_arc_simple_single

図7:単一の vCenter 内での VR の利用

 

Q.VDPのバックアップでは不十分なのでしょうか?

A.まず、バックアップでは同サイト内でデータのコピーが行われる構成も一般的に考えられますが、サイト単位の障害への対策という意味では別サイトへのレプリケーション(複製)が必要です。また、遠隔サイトへのバックアップとの違いとしては、保存されているデータの形式が異なります。 vSphere Replication では、立ち上げまでの時間が短くなるよう仮想マシンごとに .vmdk 形式で保存されていますが、VDPを用いたバックアップでは仮想マシンのデータ形式にリストアするまでに余計に時間がかかることが予想されますので、用途に応じて使い分けることが重要です。

 

Q.定期的なデータ更新となるとネットワーク帯域をかなり消費するのでは?

A.初回の同期時には全てのデータを転送するためそれなりに時間を要しますが、その後は変更された差分のみ(ブロック単位)を送信するため、ネットワーク帯域の消費を抑えることができます。ネットワーク帯域の要件に関しては RPO の設定にも依存するため、マニュアルを参考に加味してご検討ください。

 

Q.レプリケーション対象が多い場合、負荷が集中するのでは?

A.VRアプライアンスを追加で展開することにより、負荷を分散したり、レプリケーション可能な仮想マシン数を増やしたりすることが可能です。詳細はリンク先を参照ください。
http://kb.vmware.com/kb/2034768 , http://kb.vmware.com/kb/2087771

 

Q.9時~18時などと時間指定して、更新がある時間のみレプリケーションしたいのですが?

A.残念ながら vSphere Replication では、指定された時間帯のみのレプリケーションには対応しておりません。しかしながら、vSphere Replication は変更されたブロックのみを送信するため、変更が加えられていない場合のレプリケーションデータはほぼ0となり、ネットワーク等への負荷はありません。また、固定のスケジュールで縛らずRPO でデータの新しさを担保することで、例外的な操作に対しても一定したサービスレベルを維持しております。

 

§3. vSphere Data Protection ~vSphere が実現するバックアップ~

ここまでは vSphere Replication の概要についてお話ししてまいりましたが、ここからはvSphere を使用したバックアップソリューションである vSphere Data Protection ( VDP )について、椨木(たぶき)が、VDP の導入、および VDP を用いたバックアップジョブの作成、データのリストアまでを追いつつ、VDP の特徴を併せてご紹介していきます。

 

§3.1. VDP とは ~仮想アプライアンスによるバックアップ~

 

 

dedupe3

 図8:VDP の仕組み

 

第一回のブログから、仮想マシンはファイルで構成されている旨をお伝えいたしましたが、VDP もこの特徴を利用して、仮想マシンを構成するファイルをコピーすることでバックアップを行っています。

VDP は仮想アプライアンスとして、ESXi サーバ上で動作します。VDPは管理対象の仮想マシンを構成するファイルをデータストアから取得し、VDPのアプライアンスの仮想ディスク、”デデュープストア”にバックアップを保管します(図8)。

また、バックアップおよびリストアを vSphere Web Client から行うことが出来るのも大きな特徴です。ここからは vSphere 環境に VDP を導入し、バックアップ、およびリストアを行うまでの流れをご紹介していきます。

 

VDPProcess2

 

§3.2. VDPの導入 ~仮想アプライアンスによる簡単な展開~

VDP は仮想アプライアンスとして ESXi サーバ上で稼動させます。 Open Virtualization Aechive (.ova) ファイルとして VDP をダウンロードし、vSphere Web Client 上で展開します。

展開が終了し、VDP の設定が終わると、vSphere Web Client に VDP のプラグインが追加されます(図9)。詳しい VDP の展開、設定の方法については2014年6月2日のブログをご参照ください。

 

plugin図9:VDP プラグイン

 

§3.3. バックアップジョブの作成 ~5ステップで作成~

バックアップジョブは図10の様に VDP プラグインから簡単に作成する事が可能です。

 

bujob図10:バックアップジョブの作成

 

schedule図11:5ステップでジョブが作成終了

 

また、バックアップジョブの作成も図11のように

  1. バックアップするデータは仮想マシンのフルイメージか、仮想マシン内のディスクのデータか
  2. どの仮想マシンに対してバックアップを実行するか
  3. どのくらいの頻度でバックアップを行うか(スケジューリング)
    ・毎日 / 週に一回 / 月に一回
  4. バックアップしたデータの保存期間の設定
    ・無期限 / 日、月、年単位
  5. バックアップジョブの名前の決定

の5つのステップで簡単に作成する事が可能です。vSphere Data Protection と vSphere Replication の大きな違いのひとつは、バックアップデータを長期保存できることです。vSphere Replication は最長で24日前のデータまでしか保存する事ができませんが、vSphere Data Protection は(データストアの容量が許せば)毎日取るバックアップデータを無期限に保存する事ができ、いつでも昔のシステムに戻す事が可能です。

一方で vSphere Replication の RPO は最短15分前に設定できますが、vSphere Data Protection の RPO は最短1日となっており、「災害時になるべく最近のデータを保持したシステムを復旧させたい」といったニーズに対しては vSphere Replication の方がニーズにあった機能を提供する事ができます。

 

 

§3.4. データのリストア ~仮想マシンからファイルまで~

データのリストアも、vSphere Web Client から行います。

リストアするデータは仮想マシンごとに選択する事ができ、各仮想マシンのデータはバックアップを行った時間別に並んでおり、好きな世代のデータをリストアする事が可能です。また、仮想マシン内のディスク単位(vmdk 単位)でリストアを行うこともできます(図12)。

 restore図12:仮想マシン単位のリストア

 

また、仮想マシンをリストアする際は、既存の稼働中の仮想マシンにリストアするデータを上書きする事も可能ですが、別の仮想マシンとしてリストアする事もでき、これによって世代の異なる仮想マシンの状態を同時に確認する事が可能です。これを用いると、例えば仮想マシンに不具合が生じた際に、どのくらい前まで仮想マシンの状態を戻せばよいかの検証を行うことができます。

また、各仮想マシンを利用しているシステム管理者は、仮想マシンのゲストOSレベルのファイル(Windows であればレジストリやプログラムファイルなど)をリストアするファイルとして選択する事が可能です。ファイルレベルのリストアと呼んでいます。ユーザは自分の使用している仮想マシンのWeb ブラウザから専用のリストアクライアントにログインする事で、管理者に問い合わせること無くファイルをリストアする事ができます(図13)。

 

 

flr図13:ファイルレベルのリストア

 

§3.5. VDP まとめ

以上で vSphere Data Protection についての紹介を終えますが、いかがでしたでしょうか。

仮想マシンのバックアップ・リストアを vSphere 環境から簡単に行うことが出来ることがご理解いただけたかと思います。また、VDP は仮想マシン同士で同じデータがあればひとつにまとめてバックアップを行う重複排除機能や、仮想マシンのデータに変更があった部分のみをバックアップする変更ブロックトラッキング機能など、仮想基盤のバックアップに必要な機能が使用できます。

さらに、VDP のアップグレード版として、遠隔地へのデータ保護やバックアップに用いるデータストアのサイズの増加、自動でバックアップ検証を行う機能等を利用できるようになる vSphere Data Protection Advanced ( VDPA )もありますので、用途に応じて選択する事ができます。

VDPA の情報、 VDP の詳しい機能の説明については IT 価値創造塾のサイトをご参照ください。

 

§4. おわりに

表1:vSphere Replication と vSphere Data Protection の違い

VRvsVDP

 

vSphere Replication と vSphere Data Protection のご説明、いかがでしたでしょうか。今回のブログを通して、データ保護に関する要求に応じてどちらの製品をあてはめれば良いか、ご理解いただけたかと思います。表1にもまとめてありますので、併せてご確認ください。

「vSphere HA」や「vMotion」 と同様、VR と VDP 、どちらもお使いいただくことが vSphere のメリットを最大限引き出す近道ですので、ぜひ覚えておいていただければ幸いです。

さて、次回の 『vSphere のキソ!』は、いよいよ最終回!川崎君による、仮想環境の可視化ツール『vCenter Operations Manager』の紹介です。お楽しみに!

 

新卒 SE 社員が贈る vSphereのキソ!
第1回 vSphereを俯瞰する
第2回 仮想環境におけるネットワークとストレージ
第3回 vMotionとvSphere HA/vSphere FTの違いとは?
第4回 仮想マシンの配置管理はDRSにお任せ!
第5回 様々な仮想マシンが混在&混雑しても大丈夫!?ネットワーク と ストレージの帯域を維持する仕組み
第6回 vSphere でココまでできる!データ保護
第7回 仮想環境となが〜くお付き合いしていく

新卒 SE 社員が贈る vSphere のキソ!第5回~様々な仮想マシンが混在&混雑しても大丈夫!?ネットワーク と ストレージの帯域を維持する仕組み~

みなさん、こんにちは! VMware 新卒 SE の氏田 ( Ujita ) と申します。
第 5 回となる今回の新卒ブログでは、 ” 様々な仮想マシンが混在し、かつネットワークやストレージ I/O が混雑している時であっても、各仮想マシンのサービスレベルを維持できる” ということについてお話しします!
仮想環境におけるネットワークとストレージについてよく知らないという方は、椨木君による第 2 回のブログをご覧ください。

 

~ はじめに ~

仮想環境を最大限に生かすには、サーバリソースをプール化し、システムごとに切り分けるというアプローチが大切です ( 図 1 ) 。サーバリソースをプール化することによって、特定の ESXi サーバの負荷を他のサーバで補うことが可能になるため、サーバ統合率を向上させることができます。また、管理者の方にとっては、どのサーバ上でどの VM が動いているかを気にする必要がなくなります ( 詳しくは、前回のブログ ( DRS ) をご覧ください ) 。

fig_01_new

図 1 . システムごとにリソースを切り分ける

 

しかし、このような環境では一つの ESXi サーバ上に様々なシステムの VM が混在することになるため、各 VM のサービスレベルを維持できるのかという不安を持たれる管理者の方も少なくないと思います。この不安はもっともなことであるといえます。実際に、 DRS を適用した場合、 CPU やメモリなどのサーバリソースは最適化できますが、ネットワークやストレージの利用帯域については考慮されていません。 VM がどこに移動しても安心するためには、 CPU 、メモリの他に、ネットワークやストレージの利用帯域を含めたサービスレベルを担保したいのではないでしょうか。

そこで、今回のブログでは、このような問題を一気に解決できる ネットワーク IO コントロール ストレージ IO コントロール という機能についてご紹介します!これらの機能を有効にすることで、同一の ESXi サーバ上に様々な VM が混在している場合であっても、各 VM のサービスレベルを簡単に維持することができます!
また今回は、 ネットワークやストレージの帯域を効率よく利用するための機能である LBT ( Load Based Teaming )Storage DRS といった機能についても併せてご紹介します!

 

§ 1 . ネットワーク編 ~混在&混雑時でも仮想マシンのトラフィックを維持する仕組み~

まずは、ネットワークリソースを各 VM に適切に分配する仕組みである ネットワーク I/O コントロール から見ていきましょう。

 

§ 1 . 1 ネットワーク IO コントロール ( NIOC ) とは?

ネットワーク IO コントロール ( 以下 NIOC ) とは、物理 NIC のトラフィックが輻輳している時に、優先的に送出するトラフィックの種類を設定できる機能です。

最初に、 VMware vSphere におけるトラフィックの種類についてご説明します。
vSphere 環境では、ネットワーク帯域もリソースのひとつとして捉え、各種トラフィックリソースが ESXi サーバの帯域をみんなで仲良く使います。ネットワークのトラフィックリソースは、 FT トラフィックや vMotion トラフィックなど、事前に定義されたものがいくつかありますが、ユーザ側で特定のポートやポートグループをひとつのネットワークリソースとして定義することも可能です ( 図 2 ) 。

NIOC_01_new

図 2 . ネットワークリソースの定義

 

NIOC では、定義されたネットワークリソースにサービスレベルの設定をすることで、優先して帯域を利用できるトラフィックや仮想マシンを指定することができます。

具体的には、各ネットワークリソースにシェア値というものを設定し、ネットワークに輻輳が起きた場合、このシェア値の割合に基づいて、 ESXi サーバの帯域を割り当てるという仕組みです ( 図 3 ) 。

NIOC_02

図 3 . ネットワークリソースのシェア値を設定

 

では実際に、輻輳が起きた場合、開発用 VM トラフィックにどの程度の帯域幅が割り当てられるか計算してみます。
図 3 をベースとした場合、開発用 VM のシェア値の割合は、全体値 ( 20 + 5 + 10 + 10 ) 分の 20 、すなわち、 20 ÷  ( 20 + 5 + 10 + 10 ) = 0.444 となります。 NIC 一枚あたり、 10 Gbps となりますので、 10 Gbps × 0.444 = 4.44 Gbps の帯域が割り当てられることになります。この例では、 ESXi サーバには NIC が 2 枚搭載されているので、開発用 VM のネットワーク用に担保されている帯域は、合計で 8.88 Gbps ということになります。

このように、 NIOC を利用することで、ネットワークのサービスレベルが異なる仮想マシンが混在していても、それぞれの仮想マシンのサービスレベルを制御することができます。言い換えれば、大事な仮想マシンのトラフィック ( シェア値 : 大 ) が重要でない仮想マシンのトラフィック ( シェア値 : 小 ) に影響されないように設定できると言うことです。

( ※ シェア値はネットワークに輻輳が起きたときのみ発動されるものなので、輻輳が起きていない状態であれば、どのような仮想マシンであっても上限なく、自由にネットワーク帯域を利用することが可能です! )

 

§ 1 . 2 LBT ( Load Based Teaming : 物理 NIC に基づいた負荷分散 ) とは?

次に、 ESXi サーバ上の物理 NIC を最大限活用する機能である LBT ( Load Based Teaming ) についてご説明します。

同一 ESXi サーバ上で稼働する仮想マシンは、限られた物理 NIC をみんなで仲良く使わなければならないので、全ての物理 NIC を可能な限り有効に活用することが重要になってきます。

vSphere には、どの仮想マシンがどの物理 NIC を利用するかを紐付ける方式がいくつかありますが、デフォルトの設定では、仮想マシンがつながっているポートと物理 NIC が 1 対 1 で結びつきます ( ポート ID ベース ) 。しかし、これでは、ある仮想マシンが多くのネットワーク帯域を利用しようとした場合、同じ物理 NIC に紐付いている仮想マシンが影響を受けてしまう可能性があります。

また、仮想マシンが利用する物理 NIC が通信相手の IP によって変わる方式 ( ターゲット IP ハッシュベース ) もありますが、この方式でも、ある仮想マシンが同一の宛先に大量のデータを送信する場合、同じ物理 NIC を利用している仮想マシンへの影響を無視できません。

前置きが長くなりましたが、 vDS という仮想スイッチ ( 後述 ) を利用している場合に限り、仮想マシンと物理 NIC に特別な紐付けを行うことができます。これこそ、今回ご紹介する LBT です! LBT では、物理 NIC の負荷に基づいて、各仮想マシンがどの物理 NIC を利用するか決定します。具体的には、30 秒ごとに物理 NIC の使用率をチェックし、とある物理 NIC の使用率が 75 % 以上であった場合、負荷が均等になるように仮想マシンと物理 NIC の紐付けを更新します ( 図 4 ) 。

LBT_01_new

図 4 . LBT ( 物理 NIC に基づいた負荷分散 )

 

LBT を利用していれば、特定の仮想マシンのトラフィックが幅を利かせていても、他の仮想マシンのトラフィックが逃げ場を失うことはありません。

 

§ 1 . 3 分散仮想スイッチ ( vDS : vSphere Distributed Switch )

最後に、NIOC や LBT を利用するために必須となる分散仮想スイッチ ( vDS ) について簡単にご説明します。

標準仮想スイッチ ( vSS ) だけだと設定は大変!?
前回までのブログでは、仮想マシンを ESXi サーバ間で移行することにより様々なメリット ( DRS 、 HA など ) が得られることをご紹介してきましたが、実は、仮想マシンを他のサーバ上に移動させる際には、あらかじめ両サーバに同一の仮想スイッチを設定しておく必要があります。 ESXi サーバが 2 台や 3 台ならまだマシですが、それ以上になってくると、全てのサーバに全く同じ仮想スイッチを設定するのはかなり面倒な作業となり、設定ミスをするリスクも増大してしまいます。

しかし、分散仮想スイッチを利用すると、複数の ESXi サーバに同じ仮想スイッチを一気に展開することが可能になります ( 図 5 ) ( もちろん設定の変更も一発でOK! ) 。 この分散仮想スイッチは、論理的には、 ”複数の ESXi サーバにまたがった 1 つの仮想スイッチ” と捉えることができます ( 図 6 ) 。

vDS_01

図 5 . 分散仮想スイッチ ( 複数の ESXi サーバに同じ仮想スイッチを一気に展開 )

 

vDS_02

図 6 . 分散仮想スイッチ ( 論理的には一つの仮想スイッチとなる )

 

分散仮想スイッチを利用することで、複数の ESXi サーバへのネットワーク設定が楽になるほか、様々な機能が利用できるようになります( 今回ご紹介した、NIOC や LBT はほんの一部です )。

分散仮想スイッチについて詳しく知りたいという方は、「押さえておきたいvSphere の基本~ネットワーク編 第2回~」をご覧ください。

 

§ 2 . ストレージ編 ~混在&混雑時でも仮想マシンのストレージ I/O を維持する仕組み~

それでは次に、仮想マシンがストレージを快適に利用するための仕組みについてご説明します。

 

§ 2 . 1 ストレージ I/O コントロール ( SIOC ) とは?

ストレージ IO コントロール ( 以下 SIOC ) とは、特定のストレージへの I/O が集中し、レイテンシが大きくなった場合、優先的に I/O を行う仮想マシンを設定できる機能です。先ほど出てきた NIOC のストレージ版と言っても過言ではありません。ストレージ I/O を ” シェア値に基づいて各仮想マシンに割り当てる ” という考え方も同じです。

ただ、ネットワークと異なり、ストレージには複数の ESXi サーバからアクセスがあるため、SIOC ではストレージを利用しているサーバ間でシェア値を共有する必要があります。図 7 をご覧ください。

SIOC_01_new_

図 7 . SIOC ( ストレージ IO コントロール )

 

実は、 図 7 ( a ) のように、SIOC を使わなくても、単体の ESXi サーバの中だけであれば I/O を優先する仮想マシンを指定することは可能です。しかし、この仕組みは他の ESXi サーバにからのストレージ I/O を意識していないため、他の ESXi サーバに存在する優先度の低い仮想マシンにストレージ帯域を奪われてしまう可能性があります。ストレージ側から見れば、管理者が意図しない I/O 割合になるのは明らかです。

そこで、 SIOC では、特定のストレージを利用している仮想マシンのシェア値を ESXi サーバ間で共有してから各 VM のシェア値割合を計算します ( 図 7 ( b ) )。こうすることで、重要な仮想マシンの I/O が、重要でない仮想マシンに影響されないようにサービスレベルを担保することができます。

ただし、 SIOC を利用して仮想マシンのストレージサービスレベルが維持できていたとしても、特定のストレージの高負荷状況が長く続くのも良くありません。
実は、この場合には、次に説明するStorage DRS が有効に働きます!

 

§ 2 . 2 Storage DRS とは?

仮想マシンの実体は、共有ストレージ上のファイルであるというお話が第 2 回のブログでありました。仮想マシンの台数が増えてくると、当然ストレージへの I/O 要求が増加するため、ストレージ間での I/O 負荷の分散が重要になります。そのため、インフラ管理者の方は、仮想マシンを展開する際、各データストアの空き容量や、予想される I/O 量などを確認し、適切な配置先を選択する必要がありました。

しかし、 Storage DRS を利用すると、この煩わしい仮想マシンの初期配置を自動で行ってくれます。更に、特定のデータストアへの I/O 負荷が慢性的に高くなっている場合には、そのデータストア上に配置されている仮想マシンを他のストレージへ自動的に移すことで I/O 負荷を分散してくれます ( 図 8 ) 。仮想マシンのデータストアを移行する際には、 Storage vMotion が使われるので、仮想マシンが停止する心配はありません。

仮想マシンのデータストア初期配置やストレージ I/O 負荷分散は、管理者が データストアクラスタ として定義したプール化されているストレージに対して行われます ( 実際には、データストアクラスタに対して Storage DRS を有効にするという形になります ) 。

StorageDRS_01_new

図 8 . Storage DRS によるストレージ I/O 負荷分散

 

ESXi サーバをクラスタ化した場合、 DRS という便利な機能が利用できましたが、データストアも同様にクラスタ化することで、 Storage DRS という便利な機能が利用できるようになるのですね。
 

~ おわりに ~

仮想環境では、複数の ESXi サーバやストレージをクラスタ化して、一つの大きなリソースとして扱うことが多いです。そのため、一つのサーバやストレージに様々なシステムの仮想マシンが混在するという状態は避けられません。今回は、このような環境で重要となる、各物理リソースを効率よく利用する仕組み ( LBT 、Storage DRS ) や仮想マシンへの適切なリソース割り当て ( NIOC 、SIOC ) についてご説明させていただきました。
みなさんには、今回のブログを通して、様々なシステムが混在する環境でも各仮想マシンのサービスレベルを担保できるということをご理解いただき、これまでよりも大胆にリソースをプール化していただけたらと思います。次回もお楽しみに!

VMware SE 氏田裕次

 

新卒 SE 社員が贈る vSphereのキソ!
第1回 vSphereを俯瞰する
第2回 仮想環境におけるネットワークとストレージ
第3回 vMotionとvSphere HA/vSphere FTの違いとは?
第4回 仮想マシンの配置管理はDRSにお任せ!
第5回 様々な仮想マシンが混在&混雑しても大丈夫!?ネットワーク と ストレージの帯域を維持する仕組み
第6回 vSphere でココまでできる!データ保護
第7回 仮想環境となが〜くお付き合いしていく

インテリジェントな運用に必要なログ管理ツール(VMware vCenter Log Insight)のご紹介

こんにちは。本日は、”Interop Tokyo 2014 マネージメントコーナー紹介” の中でも名前が挙がりましたクラウド環境を効率的に管理できるようになるVMware vCenter Log Insight (以下Log Insight) という製品をご紹介したいと思います。

Log Insight は、システム監視、トラブルシューティング、根本原因分析などに必要となるログの収集、解析、検索向けに、自動化されたログ管理機能を提供します。

ご存知のようにVMware 製品で構成されている環境では、さまざまな場所にログが存在しております。例えば、弊社製品であるESXi やvCenter Server 、仮想マシンのOS やアプリケーション、そして物理のインフラストラクチャ等、それぞれにログが存在しております。

LI1

分散されているログを集中的に管理、分析するためには、新たな統合運用管理手法が必要となり、それを実現してくれるのが、Log Insight になります。

それでは、実際にLog Insight の画面を見てみましょう。こちらは、Interactive Analytics の画面になり、収集した全ログの中からキーワードやログ内でフィールド化されている項目、時間などの条件を入力し、某検索エンジンと同じように、非常に簡単に検索を実施し、該当するイベントを抽出していくことができるようになります。

LI2

残念ながら、画面の日本語化はされておりませんが、日本語入力、表示および検索はバージョン2.0 より可能になっております。

画面を見ていただくと、Log Insight 上には、すでに30,208,304 ものイベントが蓄積されていることがわかります。

では、試しにこの中から何か検索してみましょう!

過去1 時間に、”hostname” に”controlcenter.corp.local” が含まれているイベントを抽出してみます。”Add Filter” ボタンを押し、条件を追加していきます。また、期間を過去1 時間に設定し、条件に一致するイベントを抽出します。

この条件に一致するイベントが表示されます。イベント数が30,208,304 → 624 と少なくなっていることがわかります。

LI3

“Add Filter” で、さらに条件を追加して、見なければいけないイベントを絞り込んでいきます。

”keyword” に”audit failure” が含まれ、“task” に”login” が含まれているイベントを探します。

LI5

この条件に該当するイベントを簡単に素早く絞り込むことができました。

今回は、特定のホスト名と、Windows ログイン失敗時にイベントログに出力されるものを条件にして、検索をしておりますが、”hostname” を条件に加えなければ、ログインの失敗を繰り返しているようなホスト名を探し出すことができます。

※バージョン2.0 からは、Windows用のエージェントが提供されており、Windows マシンのイベントログの情報もLog Insight で収集できるようになりました。

こちらの画面は、後日イベントを確認しているため、期間をカスタム(特定の日時を指定)に変更しております。

LI5.5

Log Insight を使用すると、分散された非常に多くのイベントの中から、簡単に該当するイベントを見つけた出すことができます。

よく実行するクエリを、お気に入りやDashboard に登録したり、定期的にクエリを実行し、一定期間内に出力された場合には、メール通知やvCenter Operations Manager にイベントとして通知することも可能です。

LI6

Log Insight のもう一つの顔であるDashboards を見てみましょう。このDashboard は、様々なクエリで表示される情報をまとめて表示させることが可能になります。

Dashboard には、ユーザがカスタマイズして構成できるものと、コンテンツパックにより提供されるものがあります。こちらの画面は、vSphere のコンテンツパックで提供されており、インストール後、すぐにご使用いただけるように標準でインストールされております。

LI7

コンテンツパックは、Dashboards 以外にもQueries 、Alerts 、Extracted Fields などが提供され、Log Insight を使って、効率よく製品に特化した監視や分析ができるようになっています。

コンテンツパックは、弊社が提供するもの(vSphere、vCAC やView など)やサードパーティ(Brocade 、Cisco 、EMC 、NetApp など)のものが用意されており、VMware Solution Exchange からダウンロード可能になっております。

ダウンロードしたコンテンツパックは、”Import Content Pack” より簡単に追加することができます。

LI8

今回はLog Insight(バージョン2.0) という製品をご紹介させていただきました。Log Insight は、VMware vCenter Operations Manager(以下vC Ops) と 併せてご使用いただくことで、お客様のIT環境をよりインテリジェントに運用、管理していただくことが可能になります。すでにvC Ops をご使用されている方も、是非Log Insight を一度ご評価してみて下さい。