Home > Blogs > Japan Cloud Infrastructure Blog > 月別アーカイブ: 2014年9月

月別アーカイブ: 2014年9月

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

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

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

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

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

 

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

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

 

vRnvDP3

 図1:VR と VDP

 

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

 

§2. vSphere Replicationとは?

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

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

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

 

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

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

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

 

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

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

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

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

 

rep_home

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

 

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

 

§2.2. vSphere Replication の構成要素

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

 

 

rep_arc_simple_v2

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

 

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

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

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

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

 

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

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

 

rep_step

 

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

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

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

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

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

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

 

 

rep_rpo

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

 

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

 

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

 

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

 

§1.4. FAQ ~vSphere Replication

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

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

 

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

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

  rep_arc_simple_single

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

 

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

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

 

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

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

 

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

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

 

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

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

 

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

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

 

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

 

 

dedupe3

 図8:VDP の仕組み

 

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

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

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

 

VDPProcess2

 

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

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

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

 

plugin図9:VDP プラグイン

 

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

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

 

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

 

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

 

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

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

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

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

 

 

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

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

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

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

 

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

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

 

 

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

 

§3.5. VDP まとめ

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

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

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

※2015年4月update
vSphere 5.5 までは VDP のバックアップ用ストレージ増加や、遠隔地へのデータ保護が可能な VDP のアップグレード版 vSphere Data Protection Advanced ( VDPA )がありましたが、vSphere 6 からは VDPA の機能が VDP に統合され、Essential Plusからお手軽に高機能のバックアップが行えるようになりました!

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

 

§4. おわりに

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

VRvsVDP

 

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

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

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

 

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

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

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

 

~ はじめに ~

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

fig_01_new

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

 

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

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

 

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

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

 

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

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

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

NIOC_01_new

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

 

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

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

NIOC_02

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

 

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

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

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

 

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

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

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

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

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

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

LBT_01_new

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

 

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

 

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

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

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

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

vDS_01

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

 

vDS_02

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

 

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

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

 

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

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

 

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

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

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

SIOC_01_new_

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

 

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

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

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

 

§ 2 . 2 Storage DRS とは?

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

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

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

StorageDRS_01_new

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

 

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

~ おわりに ~

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

VMware SE 氏田裕次

 

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

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

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

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

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

LI1

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

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

LI2

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

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

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

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

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

LI3

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

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

LI5

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

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

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

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

LI5.5

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

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

LI6

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

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

LI7

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

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

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

LI8

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

 

VMworld 2014 からの注目セッション 第1回 – What’s New in vSphere

皆様こんにちは。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で必要なリソースとなっています。

1

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

・ROBOの課題は?

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

2

・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のライセンスを是非ご検討下さい。

3

□次期vSphereのTech Preview

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

beta

・vCenter跨ぎのvMotion

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

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

4

・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の機能と組合わせることで、システムを止めずに遠隔地のリソースも有効に使ったシステム管理が可能となります。

5

・複数vCPUでのFTサポート

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

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

6

・コンテンツライブラリ

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

7

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

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

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

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

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

89

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

 

 

VMware vCenter Converter のインストールと Windows 2003 のP2V

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

server

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

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

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

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

スクリーンショット 2014-09-05 15.23.19

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

<作業ステップ>
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 の登録はこちらが参考になります。

WS000000

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

WS000003

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

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

WS000005

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

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

WS000007

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

WS000009

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

WS000029

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

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

WS000031-1

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

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

WS000015-5WS000016-1

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

WS000047

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

WS000050-1

Step4:仮想マシン動作確認

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

スクリーンショット 2014-09-08 16.30.02

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

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

スクリーンショット 2014-09-08 16.31.16

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

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

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

新卒 SE 社員が贈る vSphere のキソ!第4回~仮想マシンの配置管理はDRSにお任せ! ~

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

〜はじめに〜

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

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

図3。クラスタ構成図

図1. クラスタ構成図

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

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

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

図2。 自社のvSphereの環境光製図

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

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

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

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

図0.3のESXiホスト間の負荷の偏り

図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発動後の​​負荷のロードバランス

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

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

物理サーバメンテナンス時も、 ESXi サーバをメンテナンスモードにすることによって、仮想マシンの再配置を自動的に行ってくれます。

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

〜 DRS の設定〜

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

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

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

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

図6。 DRS設定画面

図6. DRS設定画面

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

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

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

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

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

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

図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のキソ!
第1回 vSphereを俯瞰する
第2回 仮想環境におけるネットワークとストレージ
第3回 vMotionとvSphere HA/vSphere FTの違いとは?
第4回 仮想マシンの配置管理はDRSにお任せ!
第5回 様々な仮想マシンが混在&混雑しても大丈夫!?ネットワーク と ストレージの帯域を維持する仕組み
第6回 vSphere でココまでできる!データ保護
第7回 仮想環境となが〜くお付き合いしていく
第8回 ( おまけ編 ) まだまだあった!ストレージ関連機能

新卒 SE 社員が贈る vSphere のキソ!第3回~vMotionとvSphere HA/vSphere FTの違いとは?~

こんにちは!

毎週恒例となって参りました 新卒 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 は、起動している仮想マシンをシャットダウンすることなく、動かしたまま別の物理サーバに移動する機能です。(図1)起動したままの移行ということで、”ホット移行”とも表されます。

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

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

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

図2. vMotion による移行は数クリックで完了

図2. 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 を利用するためには、クラスタの構成が必須だからです。クラスタは複数の物理サーバを論理的にグループ化したもので、まとめられたサーバはあたかも一つの大きなリソースであるかのように扱うことができます。(図3)

図3.クラスタ構成図

図3.クラスタ構成図

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

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

 

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

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

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

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

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

 

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

図5. 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 も含めて整理したのが表6です。

表6. vMotion と HA / FT の比較

機能

使用目的

設定対象

仮想マシン停止

ダウンタイム

オペレーション

vMotion

計画停止削減

仮想マシン単位

なし

ゼロ

手動

HA

物理サーバ障害対策

クラスタ単位

あり

数分

自動

FT

物理サーバ障害対策

仮想マシン単位

なし

ゼロ

自動

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

 

終わりに

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

VMware SE川崎 一青

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