Home > Blogs > Japan Cloud Infrastructure Blog > 作成者別アーカイブ: Shuichi Machida

作成者別アーカイブ: Shuichi Machida

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 でのセッション内容を交えてご紹介する予定です。

VMware vCenter Converter で P2V, V2V ~ 第1回 仮想環境におけるサーバ移行 (P2V, V2V) の基本

今回は、仮想環境におけるサーバ移行 (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 を実施して一気に仮想化を進めるケースが多くなってきています。

vi-migration1-1

P2V (Physical to Virtual)

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

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

V2V (Virtual to Virtual)

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

vCenter Converter Standalone

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

vCenter Converter Standalone の概要

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: バージョン毎のサポート

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

2. Linux

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

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

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 越しに移行処理を実行するといったことも考えられます。

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

(追記:2014/03/25) WAN越しの変換処理は、Release Notesの「Known Issues」に記載がありますが現在のvCenter Converter Standaloneではサポートされている構成ではありません。

https://www.vmware.com/support/converter/doc/conv_sa_55_rel_notes.html#knownissues

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におけるコールドクローン

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

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

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

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

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

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

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

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

デスクサイズの変更

デスクサイズの変更

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

■まとめ

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

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

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

vSphere 5.5の新機能紹介 – VMware vCenter Orchestratorの新機能

ITプロセスの自動化を組織に導入・推進していくためには、特にITのサービス化という観点から、マネジメント、エンドユーザ、エンジニア、管理者を含む組織内の全ての関係者が取り組みに関わっていくことが不可欠と言えます。その際、これまで手作業で行われていた自動化の対象となり得る管理作業や業務フローを継続的に洗い出し、それらを短いサイクルで俊敏に実装して組織に導入していくためのフレームワークを確立することが重要になります。

今回は、VMwareの提供するクラウドソリューションにおけるITプロセスの自動化・オーケストレーションの基盤・統合レイヤとして存在感を増しつつあるVMware vCenter Orchestrator(以下vCO)について、先日リリースされたバージョン5.5 で追加された主な新機能をご紹介します。

VMwareにおける自動化ツールセットの位置付け

なお、これまでvCOについて聞いたこと、もしくは実際にお使いになられたことがない方も多いと思いますが、この製品自体は以前より存在しており、実はvCenter ServerをSimple Install(vCenter Server 5.0では通常のインストール)するとvCOも標準でインストールされています。また、vCOをvCenter Serverと別サーバにインストール(スタンドアロン)したり、仮想アプライアンス版を利用することも可能です。

vCenter Server上に標準でインストールされているvCOサービス

以下にvCOのアーキテクチャ(概観)を示します。

vCOのアーキテクチャ(概観)

vCO 5.5では、成長する仮想化/クラウド基盤への対応がメインテーマの一つとなっており、特に拡張性(Scalability)や可用性(High Availability)の点で大きく改善されています。また、vCO Clientの機能性も向上し、開発者がよりシンプルかつ効率的にワークフローを開発できるようになっています。

vCO 5.5では、大きく以下のカテゴリについて機能向上及び追加がなされています。

成長する仮想化/クラウド基盤への対応

  • クラスタモードのサポート

開発生産性の向上

  • ワークフローデバッガ
  • 失敗した最後のアクティビティからのワークフロー再開

その他の機能向上

  • vSphere Web Clientとの連携
  • 国際化(i18n)

vCO Client

成長する仮想化/クラウド基盤への対応

1. クラスタモードのサポート

仮想化/クラウド基盤の規模が拡大するに従って、その自動化をサポートするオーケストレーションレイヤのスケーラビリティや可用性を考慮する必要性が高まります。vCO 5.5で導入されたクラスタモードを利用することで、vCOサーバ(ワークフロー実行エンジン)の同時処理能力や可用性を高めることができます。

クラスタモード

vCOのクラスタではフェイルオーバーをサポートしています。クラスタはActive/ActiveまたはActive/Standby構成が可能で、クラスタモードの設定でアクティブノードの数を指定します。

クラスタモードにおけるアクティブノード数の指定

クラスタ中の全ノードがアクティブの場合、あるノードに障害が発生した場合は別のアクティブノードが直ちにセッションを引き継いで処理を継続します。一方、スタンバイノードが存在する場合、アクティブノードからのハートビートが途切れて障害を検出すると、スタンバイノードがアクティブになり処理を引き継ぎます。

また、外部のロードバランサと組合わせることで、動的なスケールアップ/ダウンも可能になります。

開発生産性の向上

1. ワークフローデバッガ

アプリケーションの開発において、デバッガは開発生産性を左右する大きな要素の一つです。vCO 5.5で新たに導入されたワークフローデバッガを利用することで、開発者はより迅速かつ容易にワークフローをトラブルシュート/テストすることができます。

ワークフローデバッガ

ワークフローを「デバッグモード」で実行する際には、個々のワークフローアクティビティに対してブレークポイントを設定し、ステップ実行しながらフローのある時点における変数値にアクセスすることが可能です。

ブレークポイント

2. 失敗した最後のアクティビティからのワークフロー再開

vCO 5.5では、ワークフローの実行に失敗した際に、失敗したアクティビティの状態からワークフローを再開する機能が導入されています。この機能は個々のワークフローまたはシステムレベルで設定されます。

ワークフロー実行に失敗した際の再開機能の設定

この機能を有効にしていると、ワークフローが失敗した際に次のようなポップアップが表示され、処理を再開して継続することができるようになります。

失敗したワークフローの再開

また、ワークフローの再開時には入力パラメータを修正することも可能です。

再開時のパラメータ値の修正

その他の機能追加および改善

最後に、vCO 5.5におけるその他の主な改善点についてご紹介します。

1. vSphere Web Clientとの連携

vCOではバージョン5.1以降、SSO認証と組合わせることでvSphere Web Clientと連携できるようになり、vCO Clientからだけでなく、Web Client上からもvCOサーバの状態を監視したりワークフローを実行することが可能です。

個々のワークフローはvCenterのオブジェクトに関連付けることができ、Web Clientのコンテキストメニューの一つとして表示されます。これにより、例えばWeb Client上で対象となるホストを選択して、新しい仮想マシンを作成するカスタムのワークフローを実行するようなことが簡単にできます。この仕組みを使えば、標準では用意されていない機能をメニューとして追加することで、Web Clientの機能を簡単に拡張することができます。

vSphere Web Clientとの連携

vSphere Web Clientからのワークフロー実行

vCO 5.5では、Web Clientの管理画面上で対象となるvCOサーバをオンデマンドで追加できるようになっています(5.1以前は、個々のvCOサーバの管理画面上から設定されたインスタンスを自動検出することのみが可能でした)。

Web Clientの管理画面上でのvCOサーバの追加

2. 国際化(i18n)

vCO 5.5の国際化(i18n)対応レベルは、前のバージョンと同じくlevel 1となります。GUIのローカライズ(l10n)などはされていませんが、非英語OS上での動作及び、非英語テキストの処理をサポートしています。また、vCO 5.5ではローカルのdate/timeフォーマット及び地域設定に対応しています。

vCOの各種コンポーネントにおける非英語テキストの対応状況については、下記マニュアルの該当項目をご確認下さい。

Installing and Configuring VMware vCenter Orchestrator 5.5 –   Non-ASCII Character Support in Orchestrator (p.15)
http://pubs.vmware.com/vsphere-55/topic/com.vmware.ICbase/PDF/vcenter-orchestrator-55-install-config-guide.pdf

まとめ

VMware vCenter Orchestrator 5.5では、拡張性や可用性、機能性などの面で、大きく以下のカテゴリについて機能向上及び追加がなされています。

  • 成長する仮想化/クラウド基盤への対応
  • 開発生産性の向上
  • その他

ここでは全てを紹介することはできませんでしたが、vCO 5.5におけるその他の機能拡張及び、製品の詳細については以下サイトの情報も是非ご参照下さい。

VMware vCenter Orchestrator 5.5 Release Notes (What’s New含む)
https://www.vmware.com/support/orchestrator/doc/vcenter-orchestrator-55-release-notes.html
vCenter Orchectrator 製品情報
http://www.vmware.com/products/vcenter-orchestrator/
VMware vCenter Orchestrator Blog
http://blogs.vmware.com/orchestrator/

なお、vCOを本番環境で導入頂く際には、通常の製品サポートの他にVMware SDK Support のご購入を強く推奨致します。

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

VMware vCloud Director 5.5 – 新機能紹介

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

今回は、VMware vCloud Director 5.5で追加された主な新機能についてご紹介します。

vCloud Director 5.5では、大きく以下の3つのカテゴリについて機能向上及び追加がなされています。

■カタログ機能

  • 共有カタログに対する組織単位でのアクセス制限
  • 複数のvCloud Directorインスタンス間でのカタログの公開/購読
  • カタログ内のコンテンツに対する自動バージョン付け
  • 任意のファイル形式のサポート

vAppの展開及びライフサイクル管理

  • テンプレートからのvAppの展開時における仮想マシンハードウェア設定の編集
  • vAppテンプレートレベルでのゲストOSのカスタマイズ設定の編集(※)
  • 実行中の仮想マシンにおける仮想NICの追加、取り外し、接続及び切断(ホットアド/リムーブ)
  • 実行中/サスペンド中のvApp/仮想マシンのメモリ状態を含むクローンの作成
  • vAppの(カタログを介さない)直接展開及びエクスポート
  • OVAファイル形式のサポート

追加サポート

  • vCloud DirectorセルのオペレーティングシステムとしてCentOSのサポート
  • Google Chrome Webブラウザのサポート
  • Mac OS Xにおける仮想マシンコンソールアクセスのサポート

※注意事項:

「vAppテンプレートレベルでゲストOSのカスタマイズ設定を編集できる」機能は、本ブログ執筆時点では急遽リリース見送りになっています。この決定は各種デモやホワイトペーパーの作成後になされたとのことで、所々で言及されているケースがあります。この機能のご利用を検討されていた場合は、vCloud Director 5.5ではリリースされない予定ですのでご注意下さい。
詳しくは、以下のブログエントリの内容もご確認下さい。

A Summary of What’s New in vCloud Director 5.5
http://blogs.vmware.com/vsphere/2013/09/a-summary-of-whats-new-in-vcloud-director-5-5.html

また、前バージョンと同様にvCloud Directorセルの仮想アプライアンス(SLES 11 SP2ベース)も提供されますが、vCloud Director 5.5においてもPoC/評価目的限定での使用を想定しております。本番環境での使用はサポートされません。

■カタログ機能の向上

1. 共有カタログに対する組織単位でのアクセス制限

組織間でのカタログ共有機能は以前から存在していましたが、これまでは「すべての組織に発行(shared)」か「その他の組織にこのカタログを発行しない(nonshared)」のいずれかを選択することしかできませんでした。vCloud Director 5.5では、ユーザがカタログを共有する「特定の組織」を明示的に選択することが可能になり、よりきめ細やかなアクセス制御を行うことができます。なお、vCloud Director 5.1では組織間でのカタログ共有を「公開」タブで指定していましたが、5.5では「公開」は次節で説明する複数vCloud Directorインスタンスを跨いだ組織間でのカタログ公開/購読(外部公開)の意味となり、共有する組織の指定はメンバーの追加と合せて「共有」指定の一部となっています。

共有カタログに対する組織単位でのアクセス制限

2. 複数のvCloud Directorインスタンス間でのカタログの公開/購読

vCloud Director 5.1以前のバージョンでは、複数のサイト(異なるvCloud Directorインスタンス)で同じ内容のコンテンツを利用したい場合、サイト毎にカタログを管理する必要があり、運用管理にコストがかかっていました。vCloud Director 5.5では、あるvCloud Directorインスタンスのカタログを外部に「公開」し、利用者側で公開されたカタログを「購読」することで、vCloud間でコンテンツを共有することが可能になりました。この公開/購読機能を利用することで、同一のvAppテンプレートやメディアファイルの運用管理が非常に簡素化されます。

カタログの公開/購読

カタログの公開側では「サブスクリプションURL」を生成し、オプションでパスワードによる保護が可能です。一方購読側では、カタログの新規作成時に外部カタログへのサブスクライブを選択し、購読対象のURLとパスワードを(オプションで)指定します。カタログのコンテンツはデフォルトでは購読時に完全同期し、以降はカタログの更新に合せて自動的に同期します。この動作は変更可能で、購読時にはカタログのメタデータのみを取得し、オンデマンドで同期させることもできます(大規模なカタログを購読する場合に特に有効)。

カタログの公開/購読(2)

また、サイト間のコンテンツのレプリケーションは、デフォルトではVMware独自プロトコルであるhttpsベースのVCSP(VMware Content Subscription Protocol)により実行されます。カタログの公開側では、同期対象のコンテンツをスプール領域に事前エクスポート(キャッシング)することで、同期処理が高速化されます。さらに、スプール領域のコンテンツに対して、VCSPの代わりにサードパーティ製レプリケーションツールを使用することも可能です。

3. カタログ内のコンテンツに対する自動バージョン付け

vCloud Director 5.5では、vAppテンプレートやメディアファイルを含むカタログ上のすべてのコンテンツに対する、シンプルな自動バージョン付け機能が追加されています。バージョン番号は、コンテンツをカタログに追加する際に割り当てられ、更新される度に自動的に加算されます。この機能により、これまでのようなファイルの命名規則ベースの煩雑な方法に代わるシンプルなバージョン管理が可能になります。

コンテンツの」自動バージョン付け

なお、更新の際にはコンテンツが旧バージョンから新バージョンに置き換わりますが、例えば変更履歴や更新者履歴などの(変更監査のための)情報は保持されません。

4. 任意のファイル形式のサポート

これまでのバージョンでは、vAppテンプレート(OVF)及び仮想マシンへのマウントを目的としたメディア(ISO、フロッピーイメージ)のみがアップロード可能でした。vCloud Director 5.5では、カタログが任意のファイル形式をサポートするようになりました。この機能により、例えばログファイルやWord文書、vCenter Orchestratorのワークフローなど、組織間やvCloud Directorインスタンス間での様々なタイプのファイル共有が容易になります。

任意のファイル形式のサポート

vAppの展開及びライフサイクル管理

1. テンプレートからのvAppの展開時における仮想マシンハードウェア設定の編集

vCloud Director 5.5では、カタログからvAppテンプレートを選択して新しいvAppを展開するタイミングで、仮想マシンハードウェア設定(CPU、メモリ及びハードディスク)をカスタマイズできるようになっています。これまでは、構成毎にvAppテンプレートを用意しておく(もしくは一旦展開した後に個別の仮想マシンに対するプロパティを編集する)必要があり、ストレージ容量やテンプレート管理のコスト、あるいは展開時の手間がかかっていました。この機能により、1つのテンプレートでの複数vApp構成への対応や、操作が簡単になります。なお、展開時に設定を変更した場合も、元のvAppテンプレートの設定情報は保持されます。

vApp展開時の仮想マシンハードウェア設定の編集

なお余談ですが、vCloud Director 5.5ではCPU数の設定でソケット及びソケットあたりのコア数の指定も可能になっています。

2. 実行中の仮想マシンにおける仮想NICの追加、取り外し、接続及び切断(ホットアド/リムーブ)

実行中の仮想マシンに対してハードディスクを追加、取り外し及び拡張する機能はvCloud Director 5.1で導入されましたが、vCloud Director 5.5では仮想NICのホットアド/リムーブ及び接続/切断の機能が追加されました。これによって、仮想NICの構成変更の際に仮想マシンをシャットダウンする必要が無くなり、ダウンタイムが短縮されます。

仮想NICのホットアド/リムーブ

制限事項として、実行中の仮想マシンのプライマリNICに対しては、削除やネットワーク・IPモードの変更操作を実行することはできません。また、スナップショットを含む仮想マシンに関しては、NIC構成の変更自体が不可となります。

スナップショットを含む仮想マシンのNIC構成

3. 実行中/サスペンド中のvApp/仮想マシンのメモリ状態を含むクローンの作成

vCloud Director 5.1までは、実行中の仮想マシンのメモリ状態を含んだスナップショットの作成のみが可能でした。実行中やサスペンド中の仮想マシン群をメモリ状態も含めてクローンしたり、テンプレートとしてカタログに登録する機能は、特にアプリケーション開発やテスト、トラブルシューティング環境において求められてきましたが、vCloud Director 5.5で実装されています。

メモリ状態を含むクローンの作成

なお、この機能を利用するためにはvCenter Server 5.5が必要となります。また、カタログからのエクスポートやvCenter Serverインスタンス間でコピーされる場合にはメモリ状態が失われます。

4. vAppの(カタログを介さない)直接展開及びエクスポート

これまで、vCloud Director環境上にvAppを展開する際には、事前にvAppテンプレートをカタログに登録しておく必要がありました。vCloud Director 5.5では、カタログを介すことなくOVFパッケージから直接インポートして展開することが可能になりました。これにより、ストレージ容量やvApp展開までの時間が削減できます。

vAppの直接展開

また、vAppをOVFまたはOVA(単一)ファイルとしてローカルに直接ダウンロード(エクスポート)することも可能になっています。

vAppのダウンロード

5. OVAファイル形式のサポート

vCloud Director 5.5では、これまでのOVF形式のファイルに加えて最近使用するケースが増えつつあるOVA(単一)ファイル形式にも対応しています。

OVAファイル形式のサポート

追加サポート

最後に、vCloud Director 5.5で新たに追加された主なサポート項目についてご紹介します。

1. vCloud DirectorセルのオペレーティングシステムとしてCentOSのサポート

vCloud Directorセルを構築する際には、これまでは商用OSであるRed Hat Enterprise Linux(RHEL)のみがサポートされていました。vCloud Director 5.5では、これに加えてCentOS(V.6.1 – 6.4)がサポート対象として追加され、vCloud Director導入の際のコスト的な敷居が下がっています。

2. Google Chrome Webブラウザのサポート

これまでサポートされていたIE、Firefoxに加えて、Google Chromeブラウザのサポートが追加されています。

3. Mac OS Xにおける仮想マシンコンソールアクセスのサポート

これまで、Mac OS XではvCloud Directorの仮想マシンコンソールがサポートされておらず、Macユーザにとって不便な環境でした(WindowsやLinux環境を別途用意する必要があるなど)。vCloud Director 5.5では、Mac OS X上で利用可能なFirefoxおよびGoogle ChromeがHTML5ベースの仮想マシンコンソールをサポートしたことで、Macユーザに対するvCloud環境の利便性が高まっています。

なお、HTML5ベースの新しい仮想マシンコンソールの実装は、Mac OSのみで使用されます。Windows及びLinux環境では、従来どおりのVMRC(VMware Remote Console)プラグインが有効になります。また注意事項として、HTML5ベースの実装ではVMRCに比べて以下の機能制限があります。

  • デバイスのサポートなし(コンソールからのCD-ROMのマウント/アンマウント不可)
  • クリップボードのサポートなし(コンソールとの間でのコピー&ペースト不可)
  • コンソール上で自動的にマウスをつかむ/リリースする機能のサポートなし

まとめ

vCloud Director 5.5では、使いやすさ、機能性及び管理性の面で、大きく以下の3つのカテゴリについていくつかの重要な機能追加と向上がなされています。

  • カタログ機能
  • vAppの展開及びライフサイクル管理
  • 追加サポート

また、以下のホワイトペーパーも是非ご参照頂ければと思います。

What’s New with VMware vCloud Director 5.5
http://www.vmware.com/files/pdf/products/vCloud/Whats-New-VMware-vCloud-Director-55-Technical-Whitepaper.pdf