Exchange 2010 SP1 仮想化について
原文の記事の投稿日: 2011 年 10 月 11 日 (火曜日)
Exchange 2010 の仮想化サポートについて、いくつかの重要な変更を発表してから (「Announcing Enhanced Hardware Virtualization Support for Exchange 2010 (英語)」を参照)、数か月が過ぎました。それ以来、特定の展開シナリオと、そのような展開に及ぼすサポートの変更の影響について、いくつかのすばらしい質問が寄せられました。質問の量を考えると、そろそろ追加の情報や説明を投稿するのが良いようです。
最初に、背景について簡単に説明しておきましょう。サポート内容を変更したとき、一番考慮したのは、仮想化展開を使用した結果、Exchange サービスの可用性が低下するような状態になってはならないということでした。別の言い方をすれば、Exchange 2010 製品の物理展開で実現できる高度な可用性を、仮想化プラットフォームを展開することで一切低下させないようにしました。もちろん、製品がそのまま動作することに加え、仮想化スタックによって提供される追加の機能によって、通常の動作時に Exchange データが失われることがないことも確認しました。
これらの点を踏まえて、変更した内容と、それが本当に意味するところの概要を、以下に示します。
Exchange 2010 SP1 (以降) が展開される場合:
- ユニファイド メッセージングを含むすべての Exchange 2010 サーバー ロールが、仮想マシンでサポートされます。
- ユニファイド メッセージング仮想マシンには、次の特別な要件が適用されます。
- 仮想マシンには 4 つの仮想プロセッサが必要です。メモリのサイズは標準のベスト プラクティス ガイダンスで決定します。
- ユニファイド メッセージング ロールの各仮想マシンでは、4 つの物理プロセッサ コアをいつでも使用できます。つまり、プロセッサ オーバーサブスクリプションは使用できません。この要件は、物理プロセッサ リソースを利用する、ユニファイド メッセージング ロールの仮想マシンの機能に影響を及ぼします。
- Exchange サーバー仮想マシン (DAG に含まれる Exchange メールボックス仮想マシンなど) は、仮想マシンが移動したりオフラインになったときに、状態を保存して復元するように構成されていない場合、ホストベースのフェールオーバー クラスタリングおよび移行テクノロジと組み合わされている可能性があります。ターゲット ノードで仮想マシンをアクティブ化する場合、すべてのフェールオーバー動作は、コールド ブートを行う必要があります。すべての計画的な移行では、シャットダウンとコールド ブート、または、Hyper-V ライブ マイグレーションのようなテクノロジを利用するオンライン移行を行う必要があります。仮想マシンのハイパーバイザー移行は、ハイパーバイザー ベンダーによってサポートされます。したがって、ハイパーバイザー ベンダーが Exchange 仮想マシンの移行をテストし、サポートしていることが必要です。マイクロソフトは、このような仮想マシンの Hyper-V ライブ マイグレーションをサポートしています。
サポートに関する説明の中で出てきたいくつかの用語について、皆が同じ意味でとらえることができるように、ここで定義しておきましょう。
- コールド ブート: システムの電源がオフの状態から、オペレーティング システムがクリーン スタートした状態にする動作を表します。コールド ブートでは、オペレーティング システムの状態は保持されていません。
- 保存された状態: 仮想マシンの電源がオフになった場合、ハイパーバイザーは、通常、仮想マシンのその時点での状態を保存できます。これにより、仮想マシンの電源が再びオンになったときに、"コールド ブート" で起動されるのではなく、その時点の状態に戻りまます。"保存された状態" は、Hyper-V の "保存" 処理の結果です。
- 計画的な移行: システム管理者が、あるハイパーバイザー ホストから別のハイパーバイザー ホストへ仮想マシンの移動を開始する場合、これを計画的な移行といいます。これは、単独の移行です。つまり、システム管理者は、時間ベース、または、ハードウェアやソフトウェアの障害以外の、システム内で発生するイベントの結果として、仮想マシンの移動を行う自動化を構成できます。ここで重要なことは、Exchange 仮想マシンが正常に動作していることであり、場合によっては再配置される必要があるということです。これは、ライブ マイグレーション、vMotion などのテクノロジを通じて行うことができます。Exchange 仮想マシン、または、VM が配置されているハイパーバイザー ホストに何らかの障害が発生した場合、それによる結果は "計画的" ではありません。
ユニファイド メッセージング サーバーの仮想化
行った変更の 1 つに、Hyper-V およびサポートされている他のハイパーバイザーにおけるユニファイド メッセージング ロールのサポートの追加がありました。この記事の最初で述べたように、サポート内容を変更しても製品の動作はそのまま変わらず、かつ、ユーザーに最善のサービスを提供することを目指しました。そのため、Exchange Server 2010 SP1 を UM サポートで展開する必要があります。その理由はきわめて単純です。UM ロールは、Microsoft Lync チームが提供するメディア コンポーネントに依存します。Lync のパートナーは、Exchange 2010 SP1 のリリースに先立って、仮想展開で高品質のリアルタイム オーディオ処理が可能となるような作業を行いました。そこで、Exchange 2010 の SP1 リリースで、その変更を UM ロールに統合しました。それが実現された後で、ユーザー操作が最適なものになるように追加のテストを行い、サポート内容を変更したのです。
ご存知のように、UM が実行されている仮想マシン (およびハイパーバイザー ホスト コンピューター) の CPU 構成には、固有の要件があります。これは、低レベルのユーザー エクスペリエンス (低レベルの音声品質という形で現れます) に対する追加保険です。
ホストベースのフェールオーバー クラスタリングおよび移行
サポートの変更によって生じた混乱の多くは、ホストベースのフェールオーバー クラスタリングおよび移行テクノロジと Exchange 2010 DAG の組み合わせに関する詳細に起因しています。ここでは、ごく簡単に説明します。
最初に、サードパーティの移行テクノロジ (VMware の vMotion など) をサポートするかどうかについて説明します。マイクロソフトでは、これらのテクノロジと Exchange 2010 を使用して、サードパーティのハイパーバイザー製品の統合をサポートすることはできません。それは、これらのテクノロジが、サードパーティ ハイパーバイザーのサポートの、他の要因を対象とするサーバー仮想化検証プログラム (英語) (SVVP) に含まれていないからです。ここではサポートに関する一般的な説明を行っていますが、それに加えて、ハイパーバイザー ベンダーが、その移行/クラスタリング テクノロジと Exchange 2010 の組み合わせをサポートしていることを確認する必要があります。簡単に言うと、ハイパーバイザー ベンダーがその移行テクノロジを Exchange 2010 でサポートしていれば、マイクロソフトは Exchange 2010 をその移行テクノロジでサポートします。
次に、ホストベースのフェールオーバー クラスタリングを定義する方法について説明します。これは、ホストレベルの障害に反応して、影響を受けた VM を代替サーバーで自動的に起動できる機能を提供するテクノロジです。障害シナリオにおいて、VM が代替ホストでコールド ブートから起動されるならば、提供されるサポートの範囲でこのテクノロジの使用が完全にサポートされます。保存された状態は、残りの DAG メンバーにとって "古い" ものとなるため、VM がディスクに保持されている保存された状態から起動しないことが重要です。
3 番目に、サポートの説明における移行テクノロジとは、あるホスト コンピューターから別のホスト コンピューターへの VM の計画的な移動を実現するテクノロジのことです。また、これは、リソースの負荷分散の一環として発生する、自動化された移動の場合もあります (ただし、システム内の障害には関係しません)。移行は、VM がディスクに保持された保存された状態から起動しない限り、完全にサポートされます。つまり、状態と VM メモリをネットワークを通じて転送することによって、ダウンタイムを認識することなく、VM を移動するテクノロジが、Exchange 2010 との使用でサポートされています。この構成で使用する場合、サードパーティ ハイパーバイザー ベンダーは移行テクノロジのサポートを提供する必要があるのに対して、マイクロソフトは Exchange のサポートを提供することに注意してください。Microsoft Hyper-V の場合、これは、ライブ マイグレーションはサポートされるが、クイック マイグレーションはサポートされないことを意味します。
Hyper-V では、VM で "移動" 処理を選択したときの既定の動作が、実際にはクイック マイグレーションとなることに注意してください。サポートされる状態を Exchange 2010 SP1 DAG メンバーが維持するためには、以下の VM 設定に示されているように、この動作を調整する必要があります (ここに表示されている設定は、Hyper-V を使った展開の方法を示しています)。
図 1: データベース可用性グループ メンバーの適切な Hyper-V 仮想マシン動作
具体的に見てみましょう。Hyper-V では、DAG メンバーに対してライブ マイグレーションがサポートされており、クイック マイグレーションはサポートされていません。図は、これがサポートされることを示しています。
図 2: Hyper-V ではデータベース可用性グループのライブ マイグレーションがサポートされる (大きなスクリーンショットの参照)
これはサポートされません。
図 3: データベース可用性グループのクイック マイグレーションはサポートされない
このブログにより、SP1 変更におけるサポートと指針が明確になれば幸いです。ご意見やご要望がありましたら、ぜひお寄せください。
Jeff Mealiffe
これはローカライズされたブログ投稿です。原文の記事は、「Demystifying Exchange 2010 SP1 Virtualization」をご覧ください。