皆様こんにちは。VMwareの秋山と申します。
本稿では、Breakout セッション以外のVMworldの見所として、VMworld Partyについてご紹介してまいります。

■  VMworld Party
水曜日の夜は、VMworld Partyということで、モスコーンセンターのすぐ近くにあるイェルバ・ブエナ ガーデンズというモスコーンセンターのWESTと同じくらいの大きさの講演でPM7:00から開催されました。会場内では、筋肉系のエンターテイメントが実施されたり、かつらをかぶって記念撮影が出来たり、大きな画面でいろいろな映像を流したりしながら、ビールやワイン等のアルコールといろいろな軽食が取れるようになっています。
 

こちらでは、楽しみながらエンドユーザ様やパートナー様等の参加者様同士のコミュニケーションをとってもらうためのネットワーキングイベントとしての位置づけされています。アメリカのお客様同士でのコミュニケーションが主になるかと思いますが、ざっと1万人近いお客様が参加されているようには感じました。

また、弊社CEOのPat GelsingerがEMCのCEOであるJoe Tucciからの指名によりアイス・バケツ・チャレンジも実施されました。こちらは、ご存知の方も多いかと思いますが、筋萎縮性側索硬化症(ALS)協会への寄付を募る活動で、氷水を頭からかぶるものになります。実施後弊社CEOが次に指名したかは残念ながら聞き取れませんでした。。。

 
また、8時半からはモスコーンセンターのNorthでコンサートが開催されました。コンサートは、BlackKeysというUSで今年Breakしているグループのようですが、私は、疎く知らなかったです。。。(有名なようなみんなスマフォで写真とってました)

最終日の前日になりますが、まさに参加者様を交えた打ち上げといった雰囲気のイベントであったかと思います。

■  ご注意
VMworld 2014速報ブログシリーズでは、USで開催されているVMworld 2014について現地から速報でお届けしています。発表時点での予定情報であり、本ブログに記載されている製品仕様やロードマップは将来予告無く変更になる可能性があります。

こんにちは！

毎週恒例となって参りました 新卒 SE 社員が贈る vSphere のキソ！ 第3回である今回は私、川崎（ Kawasaki ）が担当致します。

今回扱うのは、 vSphere の持つ機能のうち、 vMotion と vSphere HA (以下HA) / vSphere FT (以下FT) です。これらの機能は少し紛らわしい部分がありますので、その違いをクリアにしていきたいと思います。

ずばり vMotion と vSphere HA　の違いとは！？

はじめに、ずばり vMotion と HA の違いは何か、どんな時に使う機能なのか、ということから触れていきたいと思います。まずは、それぞれがどんな場合に有用な機能なのか見てみましょう。

vMotion の使い時

•  例えば…物理サーバにCPU予防交換の必要があるため一度停止したいが、そこで稼動しているサービスは平日には止めることができない。土日に出勤してメンテナンス作業を実行する必要がある。
• 例えば…負荷分散の最適化のためにシステムの構成を変更したいが、日中は仮想マシンを停止できない。夜間に一度仮想マシンを停止して、別の物理サーバに移行することで適正な負荷バランスにしよう。
  ⇓  これが vMotion を用いると…
• 稼働中の仮想マシンを別物理サーバに移行でき、仮想マシンで動いているシステムを止めずに、物理サーバのメンテナンスや負荷分散が可能！

HA　の使い時

• 例えば…物理サーバが障害で停止してしまったため、その上で動いていたサービスも停止してしまった。早急に復旧が必要だが、データセンターまで出向いての対応には多くの時間を要する。
• 例えば…仮想化はしたものの、突発的な障害に対処するため土日昼夜を問わず監視をしている。
  ⇓  これが HA を用いると…
• 月曜の朝来たら物理ホストが一台、障害により停止していた。しかしながら、 HA の機能により全ての仮想マシンは別ホストで問題なく稼動しており、IT管理者は余裕を持って対応できた♪

これらのケースからも読み取れるように、 vMotion は計画的な物理サーバの停止に対応する機能である一方、 HA は非計画的な物理サーバの障害に対応して可用性を確保する機能です。したがって、 vMotion は物理サーバのメンテナンスなど計画的に物理サーバを停止する必要がある場合に使用する移行機能であるのに対し、 HA は機能としては常に有効にしておき、いざ物理サーバに障害が起きた際に自動で保護してくれる復旧の仕組みとなります。

では、それぞれの機能の詳細を見て参りましょう。

vMotion　～仮想マシンのホット移行～

vMotion は、起動している仮想マシンをシャットダウンすることなく、動かしたまま別の物理サーバに移動する機能です。（図１）起動したままの移行ということで、”ホット移行”とも表されます。

図１． vMotionによる仮想マシンのホット移行

この vMotion による仮想マシンの移行は、管理画面から仮想マシンを指定し、図２のようなウィザードに従って進めることで数クリックの簡単な操作により完結することができます。（詳細はオンラインラボ、NEE HOL-SDC-1310 http://labs.hol.vmware.com/HOL/catalogs/　でいつでもご確認できます！）

図２． vMotion による移行は数クリックで完了

 vMotion の機能は、ホストの定期メンテナンスや一部パーツの交換等で、物理サーバを計画的に停止しなければならない際に有効です。 vMotion によって停止する物理サーバから別の物理サーバへ仮想マシンを退避しておくことで、仮想マシンとして、あるいはその仮想マシンの提供しているITサービスとしてはダウンタイムがなくなります。

なお、 vMotion を行うためには、対象物理サーバ (= ESXiサーバ)が vCenter に登録されていること、移行元、移行先の物理サーバのCPU互換性があること、共有ストレージが構成されていることが必要です。CPUの互換性に関しては、同じメーカーかつ同一の互換性グループに属するファミリのもの同士でなければなりません。詳細はこちらをご確認ください。 (http://kb.vmware.com/kb/1991, http://kb.vmware.com/kb/1992)

FAQ ～vMotion～

Q．移行の前後ではMACアドレスやIPアドレスは変わりますか？
A． vMotionによる移行ではMACアドレスとIPアドレスは保持されます。仮想マシンの場合IPアドレスは vNIC ごとに割り当てられるため、これが vMotion による移行前後でそれぞれ保持されることになります。

Q．後日物理サーバを追加していくとCPUの互換性確保ができなくなりそうですが…?
A． Enhanced vMotion Compatibility (EVC) により異なるCPU世代間の vMotion が可能です。クラスタ内で EVC のベースラインを定義することにより、クラスタ内の全ての物理サーバを同一の CPU 機能に統一します。詳細はこちらをご覧ください。（http://kb.vmware.com/kb/2011037）

Q．移行先の物理サーバとの間に共有ストレージがありません。
A．vMotion とvSphere Storage vMotion という機能を同時にご利用いただくことで、共有ストレージがない物理サーバ間でも移行することが可能です。（クロスホスト vMotion とも呼ばれます）

Q．移行中に加えられた変更について整合性は保たれますか？
A． vMotion は実行中のメモリおよび全てのシステム状態を移行先の物理サーバにコピーし、移行元の仮想マシンをサスペンドして切り替えます。実行中のメモリトランザクションをコピーした後に移行先で仮想マシンを再開するため、トランザクションの整合性も保たれます。

Q．一般的にvMotionに要する時間はどの程度ですか？
A．ネットワークの状況に依存しますが、数秒から数分程度で完了する場合が一般的です。

“クラスタ”の構成

ここで、HA / FT の紹介を行う前に、クラスタという概念について説明いたします。なぜなら HA / FT を利用するためには、クラスタの構成が必須だからです。クラスタは複数の物理サーバを論理的にグループ化したもので、まとめられたサーバはあたかも一つの大きなリソースであるかのように扱うことができます。（図３）

図３．クラスタ構成図

このような物理ホストのグルーピングのメリットは、それらをひと括りに一つの大きなコンピュータのように扱うことで、個別に稼動していた場合を超えるサービス品質を提供できることです。これら複数の物理ホストはクラスタ内で各自の持つリソースを互いに共有するため、各時刻で余剰のリソース能力(CPU, Memory)を最適に配分することで処理能力を上げたり、計画的/非計画的なホストの停止に対応する可用性の確保を実現したりします。

そのクラスタに対して HA 機能を有効にすることで、クラスタ内に含まれる仮想マシンは全て HA　により保護されることになります。また、 FT の保護を施したい場合には、仮想マシンを選択して FT を有効化することで、自動でクラスタ内の別ホストにセカンダリが作成されます。なお、 vMotion の利用にはクラスタの構成は不要です。

 HA / FT ～物理サーバ障害における可用性を向上～

計画外停止( ＝ 物理ホスト障害)に対して可用性を向上する機能が HA と FT です。 HA は “High Availability” ( ＝ 高可用性) を意味し、アクティブースタンバイの可用性を提供する機能です。 HA を使用しない場合、ある物理サーバが障害等で機能を停止するとその上で起動している仮想マシンも停止してしまいます。それに対し、予めクラスタを構成して　HA を有効にしておくことで、同じクラスタ内の別の物理サーバで自動的に再起動することが可能です。（図４）HAの場合、仮想マシンが再起動するまで数分の停止が発生しますが、仮想マシンが自動的に起動するだけでも管理者としては助かります。

図４． HA により仮想マシンを別ホストで再起動

FT (Fault Tolerance) は、物理サーバ障害が発生しても無停止でサービスを継続する機能です。保護対象となる仮想マシン（プライマリ）に対し、別の物理ホスト上にセカンダリというコピーマシンを作成します。（図５）これらは常に同期し、仮にプライマリ仮想マシンが起動している物理サーバが停止しても、すぐに切り替わってセカンダリで動作し続けることが可能です。これにより物理サーバ障害によるダウンタイムを０にすることができますので、特にダウンタイムが許容されないシステムがある場合はご使用を検討ください。現状では FT 機能が対象とできる仮想マシンはvCPUが１つの仮想マシンに限られています。

図５． FT のアクティブなセカンダリによる保護

FAQ  ～ HA / FT ～

Q． HA で仮想マシンが再起動した場合、実行中だったアプリケーションはどうなりますか？
A．仮想マシンが再起動されるため、アプリケーションは一度終了されます。Crash Consistent ( = OSが起動している状態で電源を落ちる状態）ではありますが、仮想マシンの起動とともに特定のアプリケーションが起動するよう設定しておくことで、アプリケーションやサービスの再開までを自動化することも可能です。

Q．クラスタ内に HA に必要なリソースの余裕があるか確認できますか？
A．クラスタで”許容するホスト障害数” を設定したり一定割合を予約したりすることができます。これにより常に物理サーバ障害時に必要なリソースを確保した計画的なリソース使用が可能です。

Q． HA で再起動される先の物理サーバは指定できますか？
A．アドミッションコントロールポリシーにより特定のホストをフェイルオーバーホストとして再起動する物理サーバに指定可能です。（ただし、リソースの空き具合により他のホストで再起動する可能性もあります。）

Q． FT で保護されている仮想マシンのセカンダリに対して操作を行うとどうなりますか？
A．セカンダリに対する操作は行えず、プライマリに対する操作のみが反映されます。

Q． 一度物理サーバの障害に対応すると FT の保護はなくなりますか？
A． プライマリ、またはセカンダリのホストに障害が発生した場合、クラスタ内にある別の物理サーバに新たなセカンダリが生成されて保護状態が継続されます。

vMotion と HA の使い分け

これまで見てきたように、 vMotion と HA は、仮想マシンを移行して別のホスト上で動かすという点では共通していますが、移行の際に起動したままか再起動するか、利用シーンが計画的な移行か非計画的な障害対応か、クラスタの構成は不要か必要か、といった違いがあります。このような違いを FT も含めて整理したのが表６です。

表にあるような特徴を押さえておくことで、 vMotion と HA / FT の違いを明確に整理しておくことができます。特にそれぞれの機能を使用するシーンや目的は全く異なるため、機能をよく理解することでvSphereをこれまで以上に使いこなしていただけたらと思います。

終わりに

以上いかがでしたでしょうか？仮想マシンのホット移行を行うvMotionと、アクティブースタンバイ / アクティブーアクティブの可用性を提供する HA / FT という機能。どちらも　vSphere　を語る上で外せない重要な機能です。この記事で少しでも理解を深めていただけましたら幸いです。

VMware SE川崎 一青

新卒 SE 社員が贈る vSphereのキソ！
第１回 vSphereを俯瞰する
第２回 仮想環境におけるネットワークとストレージ
第３回 vMotionとvSphere HA/vSphere FTの違いとは？

みなさん、こんにちは！ VMware 新卒 SE の野田です。
少しずつ vSphere について、理解が深まってきているのではないでしょうか？
第4回目は管理者にうれしい、仮想マシンの配置に絶大な効果を発揮する機能 vSphere Distributed Resource Scheduler （以下 DRS ）をご紹介します。

〜はじめに〜

DRS というのは” Distributed Resource Scheduler “という単語の頭文字を繋げた略称です。訳すと“分散リソーススケジューラ”となります。 ESXi サーバの物理リソース CPU /メモリを効率的に使いましょう！そんな感じ感じの解釈をされた方もいるのではないでしょうか。果たして DRS とはどんな機能なのか？見ていきましょう。

その前に、まずは前回登場したクラスタのおさらいです。
クラスタの構成
 vCenter Server の配下にある複数の ESXi サーバを論理的にグループ化し、 ESXi  サーバ群を作ります。このサーバ群を協調動作させる仕組みを”クラスタ”と呼びます。

図1. クラスタ構成図

クラスタとして一つにまとめられたサーバ群は、あたかも一つの大きなリソースであるかのように扱うことができました。前回の例では図1のようにクラスタは一つの大きなコンピュータのように扱える、とご説明しました。このクラスタの構成が、今回ご紹介する DRS には必須となってきます。

では、本題に入ります。ここから少しの間、社会の IT 管理者になったつもりで考えてみてください。

【状況】
あなたは IT 管理者として自社の仮想基盤の整理を任されています。今、自社の仮想基盤では10台の ESXi サーバ上で100台の仮想マシンが動いています。（図2参照）

図2. 自社のvSphereの環境構成図

あなたの会社がある新規サービスを立ち上げるため、仮想マシンを展開することになりました。しかし自社の ESXi サーバはリソースが飽和状態のものや時間帯によって大きく変化したりと様々です。（仮想環境は生き物です）

課題1. どこの ESXi サーバ上で新規の仮想マシンをパワーオンすべき？
おそらく ESXi サーバ1台1台のリソースの消費具合を確認し、展開先の ESXi サーバを探そうと考えたのではないでしょうか。 ESXi サーバの台数が多くなればなるほど、各 ESXi サーバのリソースを調べるのにも大変な労力と時間を消費します。見つかったとしてもすぐ負荷負荷状況が変わる可能性もあります。困りました…。

課題2. ESXi サーバ間に負荷の偏りが出てきた場合（図3参照）

図3. ESXiホスト間の負荷の偏り

手動で仮想マシンを他の ESXi サーバに移行して ESXi サーバ間の負荷の均衡をとります。移行先の ESXi サーバのリソースに余裕があればよいですが、どの ESXi サーバにどの仮想マシンを移行すればよいのか？判断が難しい。困りました…。

課題3. 物理サーバのメンテナンスやハードウェア交換、パッチの更新やメンテナンスの時期

各 ESXi サーバのリソースを調べながら、手動で仮想マシンをリソースに余裕のある ESXi ホストへ移行していくのも根気のいる作業。こちらも課題2と同様、どの ESXi サーバにどの仮想マシンを退避したらいいのか？もちろん移行先にある仮想マシンに影響がでないようにしなくては…。

せっかく仮想基盤にしたにもかかわらず悩ましい課題がでてきてしまいました。こういった状況で存在感を示すのが「 DRS 」という機能です。先ほどクラスタは複数の ESXi サーバを、一つの大きなコンピュータ（リソース）として扱える、と説明しました。管理者はクラスタ上に仮想マシンが存在する！と意識しておりますが、実際どこの ESXi サーバ上に仮想マシンが配置されるかはこの DRS にお任せできてしまいます。

課題1. どこの ESXi サーバで新規の仮想マシンをパワーオンすべき？
⇓
DRS によって、仮想マシンはクラスタ内で最適な ESXi サーバ上に自動（もしくは管理者が承認後）で展開されます。

課題2. ESXi サーバ間に負荷の偏りが出てきた場合
⇓
負荷の偏りが発生した時点で、自動（もしくは管理者が承認後）で適切な ESXi サーバ上に移行されます。（図4参照）

図4. DRS 発動後の​​負荷のロードバランス

課題3。物理サーバのメンテナンスやハードウェア交換、パッチの更新やメンテナンスの時期
⇓
物理サーバメンテナンス時も、 ESXi サーバをメンテナンスモードにすることによって、仮想マシンの再配置を自動的に行ってくれます。

このように、 DRS は仮想マシンをどの ESXi サーバ上へ展開するか？といったことを考える必要はなく、単にクラスタに仮想マシンを展開するといった感覚で仮想マシンの展開を可能にしています。課題1～3について考慮する必要は無くなりますね。
どうですか？クラスタ単位で考えると、今まで以上に仮想基盤を有効に使う事ができるかもしれません。

〜 DRS の設定〜

では DRS の設定を行ってみましょう。 DRS として仮想マシンの再配置が行われるタイミングは以下の2つです。
A ）仮想マシンのパワーオン時
B ）クラスタ内のリソースに偏りが生じたとき
この2つに意識しながら、 DRS の設定を行います。

図5. DRS によって再配置が行われるタイミング

 DRS の設定で特徴的なのが「自動化レベル」と「移行のしきい値」です。 DRS を有効にしても仮想マシンを移行するタイミングは自分で確認したい！という方には自動化レベルの設定が役に立ちます。

図6. DRS設定画面

自動化レベル
 DRS には以下3種類の自動化レベルが提供されています。

●完全自動化
仮想マシンをパワーオンすると、仮想マシンが最適な ESXi サーバに自動で移行されます。また、 DRS がクラスタ内の負荷の偏りを検出し、自動で仮想マシンの移行を行ないます。 IT 管理者は仮想マシンがどの ESXi サーバで動いているかあまり意識しません。自動化レベルの設定ではこの完全自動化がデフォルト値となっています。

●一部自動化
仮想マシンをパワーオンした段階は、完全自動化と同じくDRS により仮想マシンが最適なホストに配置されます。しかし、クラスタ内のリソースに偏りが出てくると、仮想マシンの移行推奨が表示され、IT管理者が承認後、仮想マシンの再配置が行われます。

●手動
この場合、自動的な仮想マシンの移行は行われません。つまり、仮想マシンをパワーオンすると、推奨の ESXi サーバのリスト表示、またクラスタのリソースに偏りが出た場合、仮想マシンの移行を推奨する表示がされ、いずれもIT管理者の承認後仮想マシンの配置、再配置が行われます。

では DRS が発動するタイミング B )のクラスタのリソースに偏りが出た場合ですが、少しの偏りでも再配置をするのか、大きく偏りが出た場合に再配置をするのか？を定義するのが「移行しきい値」です。

図7. 移行しきい値設定画面

移行しきい値
クラスタ内の ESXi サーバ間のリソースの偏り具合によって移行するかしないかを決定します。この決定する値のことを移行しきい値と呼びます。図7に示す通り、しきい値は1（保守的）〜5（積極的）までの5段階あり、デフォルトは3に設定されています。しきい値1はメンテナンスモードと呼ばれ、仮想マシンの再配置はメンテナンスモードが実行された際のみ行なわれます。移行しきい値は、値が大きくなるにつれ、少しの偏りでも仮想マシンの再配置（積極的な再配置）が行なわれるようになります。

再配置先を限定する〜ホストアフィニティ〜

 DRS を使用すると、仮想マシンの再配置先はクラスタ上の全ての ESXi サーバとなります。ここでゲストOSで使用しているソフトウェアライセンスの関係上等で、再配置先の ESXi サーバを限定したい！というご要望があるかと思います。このような状況で役に立つのが、 DRS のホストアフィニティという機能です。前もって仮想マシンをグルーピングしておき、その仮想マシンが動く ESXi サーバを限定することでソフトウェアライセンスの節約や、仮想マシンの所在をはっきりさせておくことも可能となります。また、このグルーピングは DRS のみならず、HAの時にも有効に働きます。

まとめ

 DRS についてご紹介しましたが、いかがでしたでしょうか？ DRS でできることを一度ご理解いいただくと、この機能にきっと魅力を感じると思います。そして一度でも DRS を使ったことがある方は「 DRS がない環境はちょっと大変…と思われているかもしれません。ちなみに、VMwareでは事例を紹介しております。こちらのお客様　、4台の物理サーバ上に130 VM （統合率32.5）を稼働させ、リソースを有効に使用させてさせております。是非こちらのお客様のお声もご参照ください。
 DRS を使用されているお客様にうかがうと、「この機能はやはり便利♪」とおっしゃっておりました。今後もこの DRS の魅力を理解しながら、仮想基盤のリソースを更に有効に、またもっと楽に管理して頂ける様、私自身も vSphere の魅力をご紹介していきたいと思います。

次回もお楽しみに！

– VMware SE 野田裕二

新卒 SE 社員が贈る vSphereのキソ！
第１回 vSphereを俯瞰する
第２回 仮想環境におけるネットワークとストレージ
第３回 vMotionとvSphere HA/vSphere FTの違いとは？
第４回 仮想マシンの配置管理はDRSにお任せ！

皆様、こんにちは。VMware山口です。今回は大変好評なP2Vシリーズの第２弾として VMware vCenter Converter (以降Converter) のインストールをしてみます。
また、今回はせっかくなので来年にサポート終了控えております Windows 2003 サーバを実際の物理サーバからP2Vしてみたいと思います。物理サーバを用意してWindows 2003をインストールするステップが一番大変でした。

その際にハマったポイントもそのままシェアさせて頂きます。Windows 2003サーバがインストールされた物理サーバとなると、５、６年前のものが多いと思いますが、故障の確率も上がっている頃と思います。本ブログを通して仮想環境に移行させるお手伝いが出来れば幸いです。

P2Vにはどのような手法があるのか、サポートOS等の前提知識を習得したい場合は、こちら第１弾のBlogをご参照ください。

今回のシナリオは下図の通り移行対象のWindows2003がインストールされた物理サーバ１台から、Converter サーバを利用して移行対象を抽出し、vCenter サーバで管理されたESXiホスト上にP2Vします。Converter サーバを利用せずに、Converterソフトウエアを直接移行対象にインストールして移行することも可能です。どちらのやり方でも結構ですが、移行対象の数が多い場合にはConverterサーバを用意した方が効率的と言えます。

簡単に解説します。
①はConverterサーバから移行対象に対しエージェントがプッシュインストールされます。
②のエージェントは移行対象をイメージファイルを移行先に転送します。
③移行対象のイメージファイルは移行対象の物理サーバと移行先のESXiホスト間で転送されます。
④様々なジョブの制御はConverterサーバより行われます。

なお、今回は移行対象を１台として記載しております。システムの規模、重要度によっては綿密な移行計画が必要になりますのでご注意ください。

＜作業ステップ＞
Step0：事前準備
Step1：Converterの入手
Step2：Converterのインストール
Step3：コンバージョンの設定
Step4：仮想マシン動作確認

Step0：事前準備

＜用意するもの＞

• Converterサーバ
• 移行対象のOSメディア
• Converterソフトウエア（下記に入手方法あり）
• ネットワークスイッチ、ケーブル等
• 作業手順書

＜事前リハーサル＞

本番移行前に必ず事前移行テストすることをお勧めします。P2Vを実行すると移行元のOSはなくなるわけではなく、コピーされる仕組みですのでテスト目的での平行稼働が可能です。正常動作することを確認の上、本番移行を行ってください。また、万が一のトラブルに備え、バックアップも取得もお勧めします。

Step1:Converterの入手

Converterは無償で入手できるソフトウエアです。こちらのURLよりダウンロードすることができます。My VMwareのアカウントをお持ちで無いお客様は登録が必要です。Downloadボタンを押してソフトウエアを入手します。今回は VMware-converter-en-5.5.2-1890136.exe を利用しています。

My VMware の登録はこちらが参考になります。

Step2:Converterのインストール
入手したソフトウエアをConverterサーバにインストールします。ウィザードに従って進めて頂ければ特に迷う所は無いと思います。なお、今回Converter用のサーバにはWindows 2008 R2を利用しています。

Step3:コンバージョンの設定

デスクトップに表示されたConverterのアイコンをクリックし、Converterを起動させたらConvert machineをクリックします。

下図は、Source（移行元）を選択するところです。今回はパワーオンしたまま移行するホットクローン方式で実施します。従って、Select source type（ソースタイプの選択）は、Powered-on machine を選択します。

次はA remote machineを選択肢、移行対象のIPアドレス、ユーザ/パスワード、OSファミリーを選択します。なお、移行対象にConverterをインストールしている場合には、This Local machine を選択します。こちらも試しましたが、特に問題なく実行できます。

続いて、プッシュインストールされるエージェントの利用後の扱いを選択します。移行完了と同時に自動的に削除するか、マニュアルで削除するかです。特に理由が無い限り、下図の通り自動削除で良いかと思います。

ここまでは順調でしたが、下図の通りエージェントインストール中エラーとなりました。結論から書きますと移行対象の時刻が正しく設定されておらず、認証がうまく行っていないことが原因でした。結果としてエージェントがプッシュインストールできずエラーとなりました。こちらは正しく時刻設定することで回避可能です。

余談ですが、Windows ゲスト OS で、ファイアウォール、ユーザー アクセス制御（UAC）機能がある場合に同様のエラーがでる可能性があります。詳しくはKB2079864をご覧ください。

続いて、Destination system （移行先）を設定します。今回はvCenter サーバを指定しますので、移行先のタイプはVMware Infrastructure virtual machine を選択します。次のそのvCenterのIPアドレス、ユーザ/パスワードを設定します。

認証に成功すると、証明書の警告がでますが、Ignoreをクリックします。

続いて、移行先（vCenter上）での仮想マシン名と、配置場所（フォルダとデータストア）を選択します。

最後に仮想マシン化する時のオプションを設定します。例えばディスクサイズを変更したり、接続する仮想ネットワークを選んだりします。 Windows 2003の場合には、Microsoft社より提供されているSysprepというツールを利用してOSのカスタマイズを（コンピュータ名やSIDの変更）実施することも可能です。今回はオプション無しで実施します。

Finishをクリックすると、ジョブ（P2V）が開始します。下図の通り進捗が確認できます。

Step4:仮想マシン動作確認

P２Vのジョブが完了すると、移行先に仮想マシン（移行対象）が作成されます。初回起動すると右下のホップアップが表示されドライバーをインストールするOSの処理があります。これは新しい環境上でOSが動作する際に必ず起きますので、正常な動作となります。また、下図の通りドライバーがうまくインストールされない場合があります。

まず、VMware toolsがインストールされているか確認し、されていない場合にはインストールします。VMware toolsは、仮想マシンとして動作するためとデバイスドライバを提供します。

余談ですが、VMware toolsがインストールしていないで仮想マシンのコンソールをマウス操作するとマウスコントロールが取られたままの状態になります。CTRL+ALTでマウスがリリースされます。

今回は移行元のWindows 2003をクローンしましたので、コンピュータ名が重複したエラーが出でました。必要に応じて変更してください。なお、仮想マシン化すると、IPアドレスは仮想NICが保持るようになります。その仮想NICのMACアドレスは、VMware のベンダーIDのものに変更されますので重複することはありません。

今回は、ほぼ未使用のWindows2003 を利用しました。ほぼトラブルなく移行完了しました。今回のブログでは触れられていないノウハウなど、Converterを使用するときのベストプラックティスがKB1033253に詳しくまとめられています。また、今回のWindows 2003 サーバのサポート終了を機にサーバ仮想化の世界へ足を踏み入れる方は是非弊社の新卒社員が書いたブログが参考になりますのでご覧下さい。

新卒 SE 社員が贈る vSphereのキソ！
第１回 vSphereを俯瞰する
第２回 仮想環境におけるネットワークとストレージ
第３回 vMotionとvSphere HA/vSphere FTの違いとは？
第４回 仮想マシンの配置管理はDRSにお任せ！

皆様こんにちは。VMwareの大原と申します。

8月末より、米国サンフランシスコにてVMworld2014が開催されました。 概要につきましては、VMware日本法人からVMworldに参加したメンバーから速報ブログとして情報をお届けしましたが、今回はいくつかのセッションにフォーカスして、より詳細な情報を数回に分けてお届けして行きたいと思います。

第1回目として、多くのお客様にお使い頂いているvSphereの最新情報について触れられている、セッション番号INF1502 (What’s New in vSphere) の内容についてご紹介をしていきます。

本セッションでは、以下の3つのトピックについて触れられています。

・vSphere 5.5 update 2
・vSphere for ROBO
・次期vSphereのTech Preview

それでは、各トピックについて見て行きたいと思います。

□ vSphere 5.5 update 2

vSphere 5.5 update 2に関しましては、9月9日に既にリリースされています。 新しいハードウェアのサポートやバグフィックスに加え、vCenterのサポートデータベースの追加が含まれています。
詳細につきましては、以下のリリースノートをご一読下さい。
https://www.vmware.com/support/vsphere5/doc/vsphere-vcenter-server-55u2-release-notes.html

□ vSphere for ROBO

・ROBOとは？

ROBOとはリモートオフィス/ブランチオフィスの略です。
地域や企業規模によって若干異なりますが、24%程度がROBOで必要なリソースとなっています。

一方で、仮想化を進める目的も異なります。ハードウェアの抽象化や標準化、俊敏性の向上、可用性の向上、コンプライアンスの強化など共通の目的も多く存在しておりますが、リソース利用の効率化を目的とした統合率向上などはROBO環境での目的には含まれません。
例えば、本社側での平均統合率は1CPUあたり8-10VM、ROBOでの平均統合率は1CPUあたり1.5-2VMという非常に興味深い結果となっております。

・ROBOの課題は？

ROBO環境での課題として上げられるのは、IT管理者の不足です。 本社側には専門の担当がいらっしゃいますが、ROBO環境の場合には現場のSEの方が片手間で行っているケースも多いかと思います。 よって、何か問題が発生したとしても、迅速な対応ができないケースも出てきます。 また、本社側からの見た場合、ROBO環境へのネットワークがシングルポイントとなってしまっていることで、管理に影響を与える可能性もあります。 そして何よりも、上記のような課題がありながらも、ROBO環境でのIT予算は限られているケースが多いということです。

・vSphere for ROBOで使用可能な機能

今回発表したROBO用のライセンスは、各拠点に対して25VMを分散して配置させて稼働させることができるライセンス体系であり、かつ25VMを上限として単一のサイトでの使用も可能なライセンス体系となっております。また、遠隔地で求められる可用性向上のための機能として、FTおよびStorage vMotionが含まれています。 従来、ROBO環境で使われていたEssential Plusのライセンスには、それらの ライセンスが含まれておりませんでしたので、機能的に大きなメリットがあります。

価格につきましては、本Blog執筆時点で外部情報として公開はされておりませんが、以下ブログ内にドルベースでStandardが3000ドル、Advancedが4500と記載があり、従来のEssential Plusと比較(※1)して、コスト的にもメリットのあるライセンス体系となっております。

http://blogs.vmware.com/vsphere/tag/vsphere-robo

(※1)vSphere for ROBOの価格は、上記Blogから抜粋しています。

極力コストを抑えつつ、高い可溶性が求められる小規模のROBO環境をお持ちのお客様は、ROBOのライセンスを是非ご検討下さい。

□次期vSphereのTech Preview

今回のVMworldでは、次期vSphereに関するTech Previewが公開されました。ここでは、Tech Previewに関する情報をお届け致します。 合わせまして、Publicベータも始まっておりまして、どなたでも登録することで次期vSphereをダウンロードして触って頂くことが可能です。 ご興味ございましたら、Publicベータにも是非ご参加下さい。（以下のスライド内のリンクを参照下さい。）

・vCenter跨ぎのvMotion

従来のvMotionは同一vCenter管理下のリソースに対してのみ実行可能でしたが、vCenterを跨いだvMotionが可能となります。 その際、移動先のvCenter上で管理されているポートグループを指定します。

仮想環境の拡大にあたり、vCenterの管理が分かれるケースもあるかと思いますが、vCenterを跨いでvMotionを行うことによりインフラ全体の冗長性が向上すると共に、管理の共通化が進む可能性もあり非常に注目される機能と言えるでしょう。

・Long Distance vMotion

遠隔拠点へのvMotionもサポートされるようになります。 vSphere4.1ではRTT (Round Trip Time) が5ms、vSphere5.0でRTTが10msと徐々にサポートされるRTTが大きくなってきましたが、次期vSphereで100msまでのRTTをサポートされるようになります。 従来、EMC VPLEXなどのソリューションと組み合わせることでLong Distance vMotionが実現可能でしたが、vSphereの機能のみで遠隔地へのvMotionが実行可能となります。

vMotionの実行にあたり、メモリイメージや、場合によってはvmdkも転送するので、遅延だけではなくある程度の帯域も必要となりますが、追加の特殊なハードウェアを使わず遠隔地へのvMotionを行えるのが大きなメリットです。 vCenter跨ぎのvMotionの機能と組合わせることで、システムを止めずに遠隔地のリソースも有効に使ったシステム管理が可能となります。

・複数vCPUでのFTサポート

vSphere 4.0 から提供されたFTの機能ですが、これまでは1vCPUのVMでのみサポートされていました。 そして遂に、次期vSphereで最大4vCPU環境でのFTがサポートされるようになります。

専門の管理者がいない環境でのサーバ障害発生時の影響の最小化や、システムダウンが許されないデータベースサーバやメールサーバ用途のVMに対する可用性向上のために有効な機能となります。

・コンテンツライブラリ

vCenter配下では様々なオブジェクトが管理されています。複数vCenterを構成する際には、Linked Modeを使用することでロールやライセンス情報の同期は可能ですが、VMテンプレート、OVF、ISOなどは複数vCenter間で同期することはできませんでした。 vCenter跨ぎでvMotionを実行する機能を使用する場合、各vCenter間で同様の情報を保持させるというニーズも出てくるかと思いますが、Content Library の機能により実現可能となります。

・仮想データセンターとポリシーベースの管理

仮想データセンターは、単一vCenter配下の複数のクラスタリソースを束ねたオブジェクトです。仮想データセンターはアプリケーションやビジネスユニット、プロジェクト毎に定義をしていきます。

ポリシーベースの管理の機能とは、IT管理者がVMの配置やストレージに関するポリシーを予め作成しておき、各ポリシーを特定のクラスタやホスト、データストアと紐付けます。

仮想データセンターとポリシーベースの管理を連携させることにより、 仮想データセンターの管理者がvCenterのリソースの詳細を知ることなく、決められたポリシーに準じて仮想マシンの配置を最適化することができます。

企業は組織毎に、もしくはそれらの組織から求められるサービスレベル毎に、複数の仮想データセンターを定義することで管理性を向上させることが可能です。

今週のトピックである”What’s New in vSphere”は以上となります。
来週以降もVMworldから注目のセッションをピックアップしていきますので、是非ご期待下さい！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

～ はじめに ～

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

図 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 ) 。

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

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

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

図 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 ) 。

図 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 ) 。

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

図 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 をご覧ください。

図 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 を有効にするという形になります ) 。

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

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

～ おわりに ～

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

VMware SE 氏田裕次

新卒 SE 社員が贈る vSphereのキソ！
第１回 vSphereを俯瞰する
第２回 仮想環境におけるネットワークとストレージ
第３回 vMotionとvSphere HA/vSphere FTの違いとは？
第４回 仮想マシンの配置管理はDRSにお任せ！
第５回 様々な仮想マシンが混在&混雑しても大丈夫！？ネットワーク と ストレージの帯域を維持する仕組み

『新卒 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）。

 図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のようになります。

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

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

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

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

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

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

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

§2.2. vSphere Replication の構成要素

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

図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ステップ、リカバリとフェイルバックもそれぞれ簡単な操作で行えるようになっています。

まず、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日」といった設定を施し、直近の状態だけでなく一定期間前の状態にもリカバリ可能になります。

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

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

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

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

§1.4. FAQ ～vSphere Replication～

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

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

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

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

図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 とは ～仮想アプライアンスによるバックアップ～

 図8：VDP の仕組み

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

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

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

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

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

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

図9：VDP プラグイン

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

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

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

図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）。

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

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

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

図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 の違い

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

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

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

新卒 SE 社員が贈る vSphereのキソ！
第１回 vSphereを俯瞰する
第２回 仮想環境におけるネットワークとストレージ
第３回 vMotionとvSphere HA/vSphere FTの違いとは？
第４回 仮想マシンの配置管理はDRSにお任せ！
第５回 様々な仮想マシンが混在&混雑しても大丈夫！？ネットワーク と ストレージの帯域を維持する仕組み
第６回 vSphere でココまでできる！データ保護

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

今回は、８月末に米国サンフランシスコで開催された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は考えます。

1. Build Your Own（アラカルト）
   • サーバやストレージ、ネットワーク機器などのハードウェア、仮想化ソフトウェア、管理ソフトウェアなどを個別に選択して調達し、お客様に合わせて統合する
   • 利点：お客様の要件に沿ったカスタマイズが可能であり、構成上の自由度が最も高い

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

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

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

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」

また、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分で完了するデモを紹介していました。

また、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パートナーから提供されます

ここまで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 のキソ！ 第７回は私、川崎（ Kawasaki ）が担当致します。 今回は、「仮想環境となが〜くお付き合いをしていく」をテーマといたしまして、 VMware vCenter Operations Manager （以下 vC Ops）という製品をご紹介して参ります。

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

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

図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

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

• キャパシティ管理

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

図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 は２つの仮想アプライアンスが展開され、 vCenter Server から収集したデータを解析し、表示します。（図4） vCenter Server は一つまたは複数を対象とすることができます。

図4．vCenter Operations Manager の構成

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

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

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

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

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

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

また、個別のオブジェクトに関してそれ自体の情報を詳細に見る、という意味では、図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 のセット製品

詳細は弊社ウェブページをご覧ください。（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製品の理解を深めていただけましたらとても嬉しいです。

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

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

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

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

みなさん、こんにちは。

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環境とは連携していませんので、どの仮想マシンのワークロードが問題に関与しているかを分析するために時間を要する場合も考えられます。

vC Opsのおさらい

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

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

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

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｣にはこのデータストアの｢残り時間｣アラートが表示されています。

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

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

EqualLogic Storage At a Glance Dashboard

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

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

EqualLogic Storage Metrics Dashboard

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

FirmwareとSoftwareの必要要件

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

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

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

おわりに

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

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

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 つのプロファイルが用意されており、導入するシステムのワークロード、規模に合わせて選べるようになっています。

この Virtual SAN Ready Node の構成詳細は、VMware Virutal SAN Ready Nodes  で確認可能で、8/15/2014 版のガイドでは、8 社のサーバ OEM ベンダから 40 種類の構成が Virtual SAN Ready 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 とクラスタを構成するためのネットワークが必要となりますので、要件に合わせる形で構成していきます。

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

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

1. I/O Controller

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

リストに出てくるコントローラの詳細を確認すると、そのカードでサポートされている 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 環境を構成/構築される場合は、その都度サポート状況を確認するようにして下さい。

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

はじめに

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

• MGT3210-S (Management Product Overview and Glimpse into the Future)
• OPT2668 (DevOps Demystified! Proven Architectures to Support DevOps Initiatives)

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

※ 補足：　最新情報

～～～

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 と関連するものとしては、以下に挙げるセッションがありました。

• HBC2371 (HBC2371 – Stick a Knife in IT! Chef + vCloud Hybrid Service = A Well Done Cloud)
• MGT2650 (Streamline Infrastructure Management with VMware and Puppet)
• MGT3095 (vCloud Automation Center and Pivotal Cloud Foundry – Better PaaS Solution)
• SDDC3281 (A DevOps Story: Unlocking the Power of Docker with the VMware platform and its ecosystem)
• SDDC3350 (VMware and Docker – Better Together)

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年、欧米ではすっかり主流の開発手法となっています。

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

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

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

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

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

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

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

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

インフラ運用チーム

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

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 も開発と運用が連携して協調することで、これまで（誰もがうすうす感づいていながら）システム開発ライフサイクルにおいて非効率であった部分（特にサイクルの後半）に対応していこうとするものです。

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

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

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

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

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

例：

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

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

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

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

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

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

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

「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」がサポートされています。

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

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

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

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

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

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

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

Puppet Integration

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

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

最後に

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

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

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

はじめに

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

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

また先日発表された、 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)環境と連携することで、各環境へのアプリケーション展開を含めたリリースパイプライン全体の自動化の実現（継続的デリバリー）を目指すものです。

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

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

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

その他のトピック

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

1. VMware vCloud Air

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

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

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

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

2. Pivotal CF

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

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

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

3. Docker / Fargo(VMfork)

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

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

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

最後に

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

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

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

日本ではサービス提供予定をこの夏に発表したばかりの『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も保護されていることが分かります。

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

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

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

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

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

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

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

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

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

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

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

□10GHz vCPU

□20GB vRAM

□1TBストレージ

□10Mbpsの帯域

□2つのパブリックIP

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

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

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

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

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

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

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

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

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

・vSphere 5.1以上

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

・vCenter 5.1以上

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

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

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

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

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

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

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

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

通常の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の注目セッションブログにご期待下さい。

みなさん、こんにちは。

今回の記事では、8月末に米国サンフランシスコで開催されたVMworld 2014にて発表された数あるトピックより、vCenter Operationsマネージャーを利用して、仮想環境上でアプリケーションの運用をより効率的に行う方法をご紹介します。

仮想環境上で稼働するアプリケーションを監視する方としては「Hyperic」（http://www.vmware.com/jp/products/vfabric-hyperic）を利用する方法があります。
Hypericを利用してゲストOS上にHypericエージェントをインストールすることにより、プロセスやWindows Serviceをはじめ、様々なアプリケーションのメトリックを収集することが可能となります。

さらにHypericで収集された情報をvCenter Operationsと連携することによりアプリケーションの稼働監視や分析を行うことが可能となります。

VMworld 2014では下記のアプリケーションとの連携について将来バージョンにおける
連携が発表されております。

1.MSSQL

ソリューションの特徴は以下です。
・自動検知による、MSSQLサービスとインスタンスの登録
・クラスタ構成の可視化
・デフォルトKPIによる静的および動的な監視
・vSphere上で稼働するアプリケーション・コンポーネントの自動の相関関係の発見

2.Microsoft Exchange

ソリューションの特徴は以下です。
・メールボックスとCASロールの自動検知
・DAGの検知
・関連する全サイトの情報伝搬
・デフォルトKPIによる静的および動的な監視
・vSphere上で稼働するアプリケーション・コンポーネントの自動の相関関係の発見

3.vCAC

4．SAP HANA

ソリューションの特徴は以下です。
・エージェント不要でデータ収集
・SAP HANAシステムへは負荷は軽微
・Out-of-the-box ダッシュボードの提供（トラブルシューティング、診断法と分析）
・300以上は、SAP HANA Studioの中で入手不可能300以上の判断基準
・SAP HANAとvSphereの間の関係マッピング

まとめ
仮想環境上で稼働する様々なアプリケーションの管理・監視のソリューションについてご紹介いたしましたが、如何でしたでしょうか。

11/5（水）～6（木）にプリンスタワー東京でvForum2014が開催されます。

こちらでも、今回のVMworldと同様のセッションが数多く講演されますので、ぜひご来場ください。

こんにちは、パートナーSEの川﨑です。今回は VMware vSphere 6.0 のリリースに伴う、VMware vSphere vMotion の機能アップデートについてご紹介いたします。vMotion の機能拡張は今回のアップグレードの目玉の一つとなっておりますので、ぜひご注目ください。

■クロス vCenter vMotion（ vCenter Server システム間のvMotion ）

クロス vCenter vMotion とは、異なる vCenter Server の配下にある ESXi ホスト間で vMotion を可能にする機能です。これまで、vSphere 5.5 まででは、vMotion は同一の vCenter 下でしか行うことができませんでした。今後は、図1のイメージのように、異なるvCenter に所属するホストやクラスタを移行先として vMotion で移行することが可能です。（図1では、”CentOS2” という仮想マシンを ”172.16.119.132” の vCenter 下の ”Cluster2” というクラスタから、”172.16.119.131” の vCenter 下の ”VSAN” というクラスタへの移行を示しています。）

図１．クロスvCenter vMotion での移行イメージ

クロス vCenter vMotion の実施方法は通常の vMotion となんら変わらず、図2のように仮想マシンを選択して、アクションとして”移行”を選択し、”計算リソースのみ変更します”または”計算リソースとストレージの両方を変更します”を選択してウィザードを進めることで、通常の vMotion 同様に移行を行うことが可能です。

なお、異なる vCenter 間での移行時の要件については弊社ドキュメントの下記ページをご参照ください。

http://pubs.vmware.com/vsphere-60/index.jsp?topic=%2Fcom.vmware.vsphere.vcenterhost.doc%2FGUID-897E10D6-A413-4699-B3C6-498AA80CB9ED.html

図２．クロスvCenter vMotion の実施方法

クロス vCenter vMotion が可能となったことで、これまで vCenter の管理範囲ごとに区切られていた仮想基盤が vCenter の縛りを超えて一つの共通プラットフォームとして扱えるようになります。データセンターごとに vCenter を分けていたケースなどでは、今回初めて vMotion での移行が可能になり、嬉しい機能拡張ではないでしょうか。

vCenter Server を超えた際に気になる点の一つとして、仮想マシンに関する様々な情報は引き継がれるのか、といった点があります。実際には多くの情報は引き継がれ、仮想マシンの MAC アドレスや、タスクの履歴、シェアや予約値といったリソース設定、HA・DRS の設定等は引き継がれますが、パフォーマンスデータは引き継がれない仕様となっております。詳細は補足として、記事の最後に記載いたします。

■長距離 vMotion 移行

長距離 vMotion 移行は、長距離に離れたデータセンター間など、遅延が大きい環境間での vMotion を可能にします。通常の vMotion で許容される RTT (=round trip time) は 5ms ですが、これが Long Distance vMotion では 150ms まで許容されます。これにより、アメリカであれば大陸の東西、日本であればシンガポールまでの距離であっても、vMotion で仮想マシンを移動させることができます。 （*レイテンシは実際に利用する回線の品質にも依存します。上記はあくまで一例とお考え下さい。）

http://kb.vmware.com/kb/2106949

図３．長距離vMotion移行の実施イメージ

■vMotion ネットワーキング

vMotion のネットワーク周りについてもアップデートがあります。一つは、TCP/IP スタックが複数構成できるようになったことにより、vMotion についても専用のTCP/IP スタックが構成可能となりました。VMKernel アダプタの作成時に、TCP/IP スタックとして ”vMotion” を選択することで設定することができます。（図４）

図４．vMotion専用TCP/IPスタックの設定

TCP/IP スタックが vMotion 専用で構成できるようになったことに伴い、vMotion 用ネットワークが異なる L2 セグメントに跨る場合にも柔軟に構成できるようになりました。従来は vMotion 用トラフィックが有効化された VMKernel アダプタ も管理ネットワークと同一の TCP/IP スタックを利用しましたが、vSphere 6.0 では個別にデフォルトゲートウェイやルーティングテーブルの構成を持つことが可能です。なお、仮想マシンの接続されるネットワークについては同一のL2ネットワークセグメントへの接続が必要です。（図５では青線が vMotion 用ネットワーク、緑線が仮想マシン用ネットワークを示しています）

図５．vMotion ネットワークの構成例

次に、クロス vSwitch vMotion について触れます。vSphere 5.5 まででは、vMotion 時には接続前後で接続する標準仮想スイッチ(vSS)、または分散仮想スイッチ (vDS) の仮想マシンポートグループを選択することはできず、移行前後で同じ仮想マシンポートグループ（vSS の場合は同じラベルのポートグループ）に接続する必要がありました。vSphere 6.0 では、移行後に接続する仮想マシンポートグループの選択が可能となり、例えば vSS の仮想マシンポートグループに接続されていた仮想マシンを vDS の仮想マシンポートグループに接続することも可能となりました。ただし、vDS から vSS への移行は選択できない点と、移行前後で IP アドレスの変更はされないため、仮想マシンのネットワーク接続確保のためには同一の L2 ネットワークに接続し続けることが必要な点には注意が必要です。

図６．vMotion 移行ウィザード中でのネットワーク選択

■補足：クロス vCenter vMotion で引き継がれる情報、引き継がれない情報について

下記で、クロス vCenter vMotion での移行前後で、引き継がれる情報と引き継がれない情報を整理いたします。内容については、一部検証結果に基づく情報であることをご承知ください。

①UUID

uuid.bios と vc.uuid は保持され、uuid.location は変更されます。これらは vmx ファイルを参照することで確認可能です。

②MACアドレス

MACアドレスの変更はありません。また、移行元の vCenter Server では、 MAC アドレスをブラックリストに追加して、新しく作成された仮想マシンにその MAC アドレスが割り当てられないようにします。

③HA/DRS ルール

基本的には下記ルールはクロス vCenter vMotion 後も保持されます。

• アフィニティルール
• VM ごとのオーバーライドルール
  • 自動化レベル
  • 起動優先順位
  • ホスト分離時の対応

ただし、下記の場合は例外的に保持されないことが社内の検証で確認されています。（判定は VM ごとに行われます）

• アフィニティルール
  • VM ごとのオーバーライドルールが設定されている場合
    
• VM ごとのオーバーライドルール
  • 移行先のクラスタの設定と同じ設定がされている場合
    
    

＊アフィニティルールは VM 間で設定している場合、適用には双方の VM でルールが保持される必要があります

④リソース設定

仮想マシンに対する CPU、メモリリソースのシェア、予約、制限値は保持されます。

⑤タスクデータ

タスクデータは引き継がれます。

⑥パフォーマンスデータ

パフォーマンスデータは移行の前後で引き継がれません。

⑦vRealize Operations Manager 上のデータ

vRealize Operations Manager 上のパフォーマンスデータは移行前後で引き継がれません。

■終わりに

vSphere の基本的な機能の一つである vMotion ですが、vSphere 6.0 では更なる機能拡張がなされました。上記のアップデートを踏まえて、更に vMotion を使いこなしていただけたらと思います。最後までお読みいただきありがとうございます。

テクニカルサポートエンジニアのMarieです。

みなさん、VMwareのサポートにどのような印象をお持ちでしょうか。
職人のようなサポートエンジニアがログを見てさくさくっと回答していると思われるかもしれませんが、
技術的な調査に取りかかる以前に 「何が出来なくてどうお困りなのか」 をお伺いするのに苦労していたりもします。

私が日々お仕事をしていて感じるのは「事象や構成が整理されているお問い合わせは、解決までのスピードが早い！」ということです。
長引いているケースが技術的に難しくて複雑であるとは限らなくて、事象や構成がはっきりしないために技術的な調査が進められないということもあるのです。

この連載では、スムーズな問題解決のためのヒントになるようなお話しをしていきたいと思います。
技術的な話が少なくて拍子抜けかもしれませんが、「サポートエンジニアも結構地道な作業をしているのね！」と感じていただけるかと思います。
徐々にステップアップしていきましょう！

第１回　トラブル発生時に役立つ 4 つのリソース　←This Post
第２回　サポートリクエスト（SR）と情報採取
第３回　応用編

今回はトラブル発生時に役立つリソースとその使い方をご紹介いたします。

1. ナレッジベース（http://kb.vmware.com/）
   障害の発生事例や対処法、トラブルシューティング方法、ベストプラクティス等を検索することができます。
2. 各種ドキュメント（http://www.vmware.com/jp/support/support-resources/pubs/）
   製品マニュアルやリリースノートなど、各種ドキュメントが公開されています。
3. コンパチビリティガイド（http://www.vmware.com/resources/compatibility/search.php）
   VMware製品とハードウェアやOSの互換性をチェックすることができます。
4. VMware製品間の相互運用性マトリックス（http://partnerweb.vmware.com/comp_guide2/sim/interop_matrix.php）
   VMware製品間の互換性をチェックすることができます。

これから紹介するページは、弊社のサイト（http://www.vmware.com）トップ画面の [サポート] からアクセスできます。
設計・構築時にご利用いただいているものもあるかと思いますが、今回はトラブル発生時にどのようなポイントを確認したらいいかという観点でご説明したいと思います。
はじめての方も、まずは手を動かしながら色々調べてみましょう！

1. ナレッジベースKnowledge Base（http://kb.vmware.com/）
まずはここ、1つ目はナレッジベース（Knowledge Base）です。
障害の事例や対処法、トラブルシューティング方法、ベストプラクティス等を検索することができます。
エラーメッセージやコンポーネント名、ハードウェア名などで検索してみて下さい。
最近は日本語に翻訳された記事も増えてきているのですが、英語で書かれた記事をベストエフォートで翻訳していますので、最新情報ではない可能性もあります。
例えば、日本語版では回避策なしと案内されている場合も、オリジナルの英語版では回避策や修正についての情報がアップデートされているかもしれません。
日本語版の記事にはオリジナルの英語版へのリンクがありますので、必ずこちらも合わせて確認するようにして下さいね。

2. 各種ドキュメント（http://www.vmware.com/jp/support/support-resources/pubs/）

そして2つ目、製品ドキュメントやリリースノートをはじめ各種ドキュメントが公開されています。

まずは html 版の vSphere 5.5 の製品マニュアルである「VMware vSphere 5.5 ドキュメント センター（http://pubs.vmware.com/vsphere-55/topic/com.vmware.ICbase/Welcome/welcome.html）」を見てみます。
上記のページ「VMware vSphereのドキュメント（http://www.vmware.com/jp/support/support-resources/pubs/vsphere-esxi-vcenter-server-pubs/）」各ガイド欄にリンクされています。

確認してもらいたいポイントに沿ってご紹介します。

・構成（システム要件、インストール方法など）
要件を満たしていないシステムでは予期せぬトラブルが発生することがあります。
ご利用いただいている環境がシステム要件を満たしているか、インストールや設定方法に問題が無かったか確認してみましょう。
お客様のシステムはお客様が一番よく知っているはずなので、ここは頑張っていただきたいポイントです！

システム要件を見てみます。
vSphere のインストールとセットアップから展開できます。

例えば、vCenter Server, Web Client, Inventory Service, Single Sign-On すべて同じマシンの構成だと 12GB 以上のメモリが必要ですが、この条件を満たしていないマシンをたまに見かけますね。
基本的なことではありますが、念のためひとつひとつ確認してみて下さい。
・トラブルシューティングガイド
トラブルシューティングガイドでは、よくあるトラブルについて、問題・原因・解決方法が説明されています。
このガイドに記載の無い問題であったとしても、類似の問題から何かヒントを得られるかもしれませんので目を通してみて下さい。


次に確認していただきたいのがリリースノートです。
リリースノートには新機能の紹介だけでなく、既知の問題とその回避策も公開されています。

「VMware vSphereのドキュメント（http://www.vmware.com/jp/support/support-resources/pubs/vsphere-esxi-vcenter-server-pubs/）」ページに戻り、vCenter Server 5.5.x の一番新しいバージョン（5.5 Update 2d）のリリースノートを見てみます。
既知の問題の欄をご参照下さい。
ここで紹介されている問題にあてはまりそうな場合、回避策を試してみて下さい。

トラブル時の確認という観点でいうと製品ドキュメントとリリースノートあたりですが、他にも色々なドキュメントが公開されています。
製品への理解を深めるのにお役立てください。

3. コンパチビリティガイドVMware Compatibility Guide （http://www.vmware.com/resources/compatibility/search.php）

3つ目、少しレベルアップして構成にあわせた確認をしていきましょう。
ストレージやネットワークなど問題が絞りこめている場合は、改めてハードウェアのコンパチビリティを確認してみて下さい。
項目によっては互換性の有無だけではなく、推奨設定なども確認できます。

試しに私が使っているマシンのHBAのコンパチビリティを確認してみましょう。
vmhba0として認識されているIntel Corporation Avoton AHCI Contorollerにポイントします。

esxcfg-infoコマンドで詳細を確認してみます。

ESXi のバージョンも確認しましょう。
Buildは1892794 なので、ESXi 5.5U1 とのコンパチビリティを確認することになります。

Web Clientからもハードウェアの情報を確認できます。
インベントリツリーで [ホストおよびクラスタ] - [該当のホスト] – [管理タブ] でネットワークやストレージアダプタを確認できます。

詳細な情報を確認したい場合は、[管理タブ] の右隣 [監視タブ] の [ハードウェアステータス] から該当のアダプタを選択して下さい。

ESXiのバージョン、Buildは [サマリタブ] の [構成]　から確認できます。

では、確認した情報を元に検索してみます。

調べる対象はSATA controller なので [What are you looking for] は [IO Device] 、[I/O Device Type] は [SATA] に設定しました。
[Brand Name] や [VID] や [DID] も esxcfg-info や ハードウェアステータスタブ の内容を参考に選択し、 [Update and View Results] で検索を実行します。

出ましたっ！

ESXi 5.5U1とIntel Corporation Avoton AHCI Contorollerには互換性があることが確認できました。

ドライバのバージョンも問題ありませんね。
最新のドライバがあればアップデートしておくとベストです。

手順やよくある質問についてはこちらをご覧下さい。

* VMware KB: Identifying correct driver for ESXi/ESX host PCI devices (HBA) using VMware Hardware Compatibility Guide (HCL) (1031534)
http://kb.vmware.com/kb/1031534
* VMware KB: Identifying and downloading the appropriate driver for your adapter: Process and FAQ (2050194)
http://kb.vmware.com/kb/2050194

4. VMware製品間の相互運用性マトリックスVMware Product Interoperability Matrixes（http://partnerweb.vmware.com/comp_guide2/sim/interop_matrix.php）

見落としがちな4つ目、VMware製品間の相互運用性マトリックス（VMware Product Interoperability Matrixes）では製品同士の互換性を確認することができます。
バージョンアップや旧環境からの移行の後に問題が発生したなんていう時は、念のため確認してみて下さい。

では私の使っているマシンにインストールされている ESXi とそれを管理している vCenter Server の互換性を確認してみます。
ESXi はBuild 1892794 なのでESXi 5.5U1、vCenter Server はBuild 2183111 なので 5.5U2 に該当します。
[Select a Solution] で [ESX/ESXi] を選択し、[Version] を指定するとESXi5.5.U1の列が追加されました。

今回確認したいのは vCenter Server との互換性です。
[Add Plat form/Solution] には [vCenter Server] を選択し [Add] すると [vCenter Server] の行が追加されました。

チェックが付いているのが互換性ありのしるしです。
ESXi 5.5U1 と vCenter Server 5.5U2 は互換性に問題が無い組み合わせであることが確認できました。
手順は以下のKBが参考になります。

* VMware KB: Using the VMware HCL and Product Interoperability Matrixes (2006028)
http://kb.vmware.com/kb/2006028

---

ここまで調べてみて、いかがでしたでしょうか。
問題は解決しましたか？

どれにもあてはまらない…
案内されている方法を試してみたけど直らない…

という場合はサポートリクエスト（SR）を発行してみましょう。
「それなら最初から問い合わせすればよかった！」と思っているかもしれないみなさまに、
「ここまで手を動かした努力は決して無駄ではない！」ということをお伝えしたいです。

最初にお話したように、スムーズな問題の解決のためには、問題に対するお客様のご理解がとても大切です。
コンパチビリティを確認してみて、普段ご利用いただいている環境のことがより理解できたのではないでしょうか。
また、ナレッジベースやドキュメントを検索しているうちに、発生している事象が整理されてきたのではないかと思います。

次回はサポートリクエスト（SR）の発行と情報採取についてお話したいと思います。

連載　vSphere 問題解決までのヒント！
第１回　トラブル発生時に役立つ 4 つのリソース
第２回　サポートリクエスト（SR）と情報採取
第３回　応用編

はじめに

vSphere 6.0 で実装されたVMware vSphere Virtual Volumes （VVol） は、対応するストレージと連携することにより初めて利用可能となる機能です。VVolの全体的な話はこちらでご紹介させていただきましたが、今回は、主にストレージ側から見たVVol の実装とそのメリットについて、日本HPの3PAR担当プリセールスの伊東様に執筆いただきましたのでご紹介いたします。

VVol 概要とメリット

vSphere 6.0 から新たに実装されたVVol はストレージベンダーにとっては2015年で最も重大なニュースであり非常に大きなインパクトを与えています。特にSANストレージがVVol に対応することでこれまでのLUN + VMFSでは不可能であったり不便であったりしたことが大幅に改善されます。

どのように改善、変化したかということを下図で示します。SANストレージとNASストレージでは同じ利用目的のデバイスでありながら管理の方法やその特性が全く違っていました。

　

VVol を利用すると、vCenter Server からSANもNASも同じVVol Datastoreの定義をすることができ、見え方、使い方の違いを無くすことができます。

　

SANストレージにとっては、今まではほぼ不可能に近かった仮想マシン毎にボリュームを分け、サービスレベルを個別に設定することが可能になり、様々なメリットが生じてきます。

VVol の対応により、SANストレージは今までと同様の高いパフォーマンスを提供しながらストレージリソースのシンプルな管理、きめ細かなSLA定義、効率の良いストレージ機能の提供が可能となります。

3PAR とVVol の関係について

HP 3PARとVVol には長い歴史があります。まだ3PAR がHP にマージされる前の4年以上前からVVol との関係がスタートしています。その後、3PAR はHP の主力ストレージとなりましたが、HP がVVol のオリジナル開発パートナー5社のうち1社となり、更に3PAR がFCストレージのリファレンスプラットフォームに選ばれました。開発の途中経過はHPのブログやエキシビションで発表しており、2014年半ばにはVVol のベータプログラム開始時に準備が整っていた3製品のうちの1つとなりました。最終的にVVol がGAとなった2015年3月時点でもVVol が提供する機能を全てカバーしています。

では、HP 3PAR がVVol の機能をどのように実装し、実際にどのように動作するかということを解説していきます。

VVol をサポートするための実装

・VASA 2.0プロバイダ

　vCenter Server / ESXとやり取りするストレージ管理サービスでvCenter Serverからのリクエストを受け取り、ストレージの機能や制御の伝達・翻訳する役目を果たします。

・プロトコルエンドポイント

　FCファブリックのアクセスをシングルポイントにする仮想デバイスで通常のLUN 検出コマンドで検出されます。ストレージ管理ツールに触る必要が無く、ストレージ管理者が介在しなくてもvCenter Serverからストレージの切り出しが可能です。各仮想マシンにはVMDK, Config, Swap, Memory, Snapshotなど複数個の3PAR VV*（Virtual Volume）が作成されることになるため、従来よりも多数の3PAR VVが作成されることになりますが、3PAR はもともと多数のボリューム構成をサポートしており、その範囲内であれば全く問題なく利用可能です。

　*3PAR VV（Virtual Volume）とは：3PAR内では、ホストに提供するLUに相当するボリューム のことを従来よりVirtual Volumeと呼んでいます。
　　vSphere VVol環境ではVVol = 3PAR VVとなります。なおvSphere VVolはVirtual Volumesとも呼びますので、混同しないようご注意ください。

・VVol Datastore（ストレージコンテナ）

　3PAR ではオプション機能のVirtual Domainを利用すると1台の3PAR を仮想的に複数のストレージとして管理単位を分割出来るためストレージコンテナを複数に分割することが可能です。Virtual Domainを利用しない場合は3PAR が丸ごと1台がストレージコンテナとなります。

3PARのVASAプロバイダはビルトインで、3PARのコントローラノード上のサービスとして動作します。インストールなど不要でコマンドによりサービスを起動するだけで即座に利用可能となります。

VASAプロバイダがストレージコントローラ上に組み込まれていることによって得られる見過ごすことのできないメリットがあります。

・インストール不要で追加のセットアップや構成が不要

・高可用性、自動フェイルオーバ

・個別のバージョン管理、アップデートが不要

ストレージ装置によっては仮想アプライアンスなどの形でVASAプロバイダが提供されているケースもあり、構築にそれなりの手間が生じますが、3PARのVASAプロバイダは上記の通り極めて簡単に構築可能で、かつ、可用性に優れる実装となっています。

また、3PARがサポートするVV（ボリューム） 数は下記の通り、非常に多数を作成することが出来るため、VVol で懸念となるボリューム数の増大は3PAR では全く気にする必要がありません。

モデル	7200/7400	7440/7450	10000
最大VV数	16000	32000	32000

 

VVol + 3PARで何が出来るか？

VVol 環境で利用可能となる3PAR の独自機能を下記に挙げます。

・ベンダーニュートラルな機能として提供（VVol 必須の機能）

　　Thin / Thick Provisioning

・ベンダー固有の機能として提供

　　Common Provisioning Group ：ボリューム構成テンプレート

　　　　　　　　　　　　　　プライマリ用とスナップショット用を別々に選択可能

　　Thin Persistence（Zero Detect）：ゼロデータ検知・リクラメーション

　　Thin Dedupe：重複排除機能

・その他vCenter Serverから行えるストレージ機能

　スナップショットの作成

　　Virtual Copy（スナップショット機能）との連携：

　　　仮想マシンの操作メニューからスナップショット作成を行うと、3PAR側でVirtual Copyを作成

・現時点で3PAR 管理ツールにより設定すれば使える3PAR 機能

　　ストレージQoS：Priority Optimization

　　フラッシュキャッシュ：Adaptive Flash Cache

　　※将来的にはVVolに対応した機能として提供する予定です。

Storage Policy-based Management（SPBM）のサポート

仮想マシンのストレージに対するビジネスニーズを満たすためのフレームワークです。

• SPBM によって、仮想マシンをストレージ上でプロビジョニングする際にアプリケーションの要件にマッチしたボリュームを提供するための仕組みになります。
  • ストレージがサポートしている機能をvSphereのPolicy-base Provisioning エンジンに対して公開
  • 仮想マシンが作成される際、ビジネスニーズにマッチした機能をアサインする
    • 仮想マシン毎、必要な機能がボリュームに対してアサインされる（スナップショットも仮想マシン毎）
  • SPBMエンジンは、要件を満たし互換性を持ったデータストア（ローカルディスク、LUN、vSAN、VVol ）がどれかというのを認識
  • 仮想マシンは適切なESXホストおよびストレージでプロビジョニングされる
  • SPBM は各ボリュームのコンプライアンスを監視
  • 仮想マシンに紐づけたストレージが機能要件を十分に満たしているかを監視していく役割も担っている

3PARでVVolを利用するための環境

• vSphere 6
• 3PAR OS ：3.2.1MU2 Patch 12
• 3PARソフトウェアライセンス類
  • OS Suite        ：必須
  • Virtual Copy         ：必須
  • Virtual Domain        ：オプション
  • Priority Optimization    ：オプション
• FC HBA, FCoE アダプタ

3PARでVVol を利用するために最初に実施すること

下記の手順でVVol利用の準備を行います。

1. VASA プロバイダ サービスの起動： 3PAR CLI にて、"startvasa" コマンドを実行
2. ＜オプション＞VVol 用のドメイン、ユーザの作成
3. CPGの作成 ：全てのCPG が機能プロファイルとしてvSphere に提供されます
4. VASA プロバイダの登録：vCenter Server から VASA プロバイダをスキャン
5. ESXi ホストを 3PAR に登録：通常の手順で登録。ESXからプロトコルエンドポイントを確認
6. VVol データストア（Storage Container）をマウント：通常のデータストアと同じ手順。
7. ストレージポリシーを作成

手順のイメージをいくつか紹介します。

1. VASAプロバイダの準備はサービスの確認と開始のコマンドを実行するだけで完了です。

④VASA プロバイダの登録はvCenter Server の新しいストレージプロバイダの追加を実行します。

⑤ESXi ホストの登録を実施しますが、3PAR では通常行っているホストの登録コマンドを実行するだけで完了です。またホスト登録の実施を行うだけでプロトコルエンドポイントとなるLUが有効になります。

　ホスト登録のための3PAR コマンド：cli# createhost –persona 11 <host name> <WWN>　

　ESXi 側では通常のデバイスのスキャンを行い、ストレージデバイスにLU が確認できることと、そのデバイスがプロトコルエンドポイントとして認識されていることを確認します。

　

※プロトコルエンドポイントはESXi から見るとSCSIデバイスが見えますが、3PAR 内ではボリュームの実体は作られません。

⑥VVol データストアのマウントをした後、データストアのサマリ情報を見るとストレージ機能プロファイルという項目があり、そこに3PAR の CPG が列挙されてきます。CPGには 3PAR のドライブタイプ、 RAID レベル、ストライプ幅を決める設定が含まれます。

⑦ストレージポリシーの作成では3PARの機能の組み合わせを一つ一つ構成していきます。

まずポリシー名を設定します。

次にルールセットを作成で、ルールの中に 3PAR の機能を選択していきます。

プライマリボリューム用の CPG、スナップショットデータを格納用のCPGの選択、リクラメーション機能のThin Persistence、重複排除機能のThin Deduplicationを必要に応じて追加します。

この例では、プライマリボリュームはFCドライブのRAID 1に、スナップショットはFCドライブのRAID 6 に、リクラメーション機能もONというポリシーを設定したことになります。

ルールの設定の後は、互換性ありと表示されているVVol のデータストアを選択します。

設定内容の確認を行い、ポリシーの作成は完了となります。

 

仮想マシンの作成

最後に一番重要な、仮想マシンの作成とそれに伴い自動的に作成されるボリュームについて、実際の作成画面等を用いて紹介していきます。

通常の手順で新規仮想マシンの作成を開始します。

ストレージの選択で、仮想マシン ストレージ ポリシーでVVol 用に作成したポリシーを選択します。ここで選択したポリシーに応じて仮想マシンの作成と共にボリュームが作成されます。

仮想マシン ストレージ ポリシーで選択されたポリシーに対して、互換性のあるデータストアが互換性ありにリストアップされます。ここでは"VVOL"という名前で作成されたVVol データストアを選択します。

最後はサマリが表示され問題なければ完了となります。

 

仮想マシンを作成すると、3PAR 上で仮想マシンに応じたVVが自動的に出来上がります。通常運用では3PAR側のVVの状態を特に意識する必要はありませんが、参考までにその確認の方法を紹介します。

VVol 用に自動的に作成された3PAR VVの表示コマンドshowvolvm –vvの実行結果で仮想マシンとVVol 名、VVol タイプ等と3PAR VVとの対応が確認できます。仮想マシン作成時点では、Config 用とData 用のボリュームが作成されています。

仮想マシンのパワーオンを実行するとSwap 用のボリュームが自動的に作られます。

仮想マシンのスナップショットを作成では、従来の手順で仮想マシンのメニューからスナップショットの作成を実行します。

スナップショットの作成手順を行うことでVVol の場合は自動的にストレージネイティブのスナップショット機能 = 3PARではVirtual Copy が自動的にとられます。

仮想マシンのメモリのスナップショットをチェックしておくと VVol ではストレージ側に Memory というタイプのボリュームを作成します。

以上、仮想マシンの作成やスナップショットの作成は全てvCenter Server 側の UI から実施可能で、3PAR 側でのボリュームの確認は任意ですので必要に応じて 3PAR のコマンドから確認してください。

現時点でまだ VVol 機能に対応していないストレージ QoS やフラッシュキャッシュ機能は 3PAR のコマンドから設定いただきご利用いただくことが可能となっております。将来的には VVol 機能の一つとして選択できるように実装される予定です。

 

最後に

HP 3PAR が VVol の開発当初から関わり、リリースと同時に完全にサポートしていることをご理解いただいたと思いますが、 VVol 機能自体がまだまだ発展途上の技術であり今後にのびしろを多く残している機能です。

特に2015年5月時点では VVol で作成されたボリュームをストレージでレプリケーションする機能は実装されていませんし、バックアップに関しても対応しているバックアップソフトウェアも少ないのが現状です。

3PAR は引き続きVVol 対応用の機能を拡充し VVol の進化に追従していく予定ですので、是非今からご利用のご検討をスタート頂ければと思います。