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

新卒 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回 ( 追加編 ) まだまだあった!ストレージ関連機能