あるグループから別のグループへ移行するとき、更新は自動的に行われるとは限らず、また自動更新が望ましいとも限りません。

Henrik Walther

Exchange Server 2010 と Hyper-V

Q. Exchange Server 2010 の展開を計画しています。当社では内規により新規のサーバーはすべて Hyper-V で稼働する仮想マシン (VM) である必要があります。アプリケーションとサービスの可用性を向上するため、すべての Hyper-V のルート サーバーは Hyper-V のフェールオーバー クラスターに参加しています。

最近、Microsoft Exchange チームのブログで Exchange Server 2010 のハードウェアによる仮想化のサポートの拡張に関する発表を読み、特に次の点に関心を持ちました。

「DAG のメンバーとなっているメールボックス サーバーをクラスター化されたルート サーバー間で移動または自動的にフェールオーバーするハイパーバイザー ベースのクラスタリング ソリューション、高可用性ソリューション、または移行ソリューションと Exchange Server 2010 の高可用性ソリューション (データベース可用性グループ (DAG)) を組み合わせて使用することがサポートされるようになりました」

これは当社にとって朗報です。と言うのも、DAG に参加している Exchange Server 2010 のメールボックス サーバーを Hyper-V のフェールオーバー クラスターで VM として展開することが可能になるからです。これらのソリューションを組み合わせて使用する際、他に留意する点はありますか。

A. Exchange Server 2010 の展開には、打って付けのタイミングです。ご指摘のとおり、マイクロソフトでは DAG をホストベースのフェールオーバー クラスタリングや移行テクノロジと組み合わせて使用することがサポートされるようになりました。これは Hyper-V だけでなく、Windows Server Virtualization Validation Program (SVVP) に参加しているすべてのハードウェア仮想化ベンダーにも適用されます。

しかし、DAG メンバーのライブ マイグレーションを計画する場合には、留意すべき重要な点がいくつかあります。まず、この機能をサポートするためには、Exchange Server 2010 SP1 以降が必要です。また、パススルー ディスクではなく、クラスターの共有ボリュームを使用することを強く推奨します。Exchange 製品グループと Hyper-V チームが、この 2 つの方法のテストを実施した結果、クラスターの共有ボリュームを使用した場合、ストレージ リソースの移動に伴うオフライン時間が半分で済むことが判明しました。

サーバーのオフライン時間が 5 秒を超えると、DAG ノードはクラスターから削除されます。そのため、Hyper-V フェールオーバー クラスターでは 5 秒以内にリソースを移行できるようにすることが重要です。5 秒以内に移行できない場合には、クラスターのハートビート タイムアウトの値を増やします。ただし、この設定は 10 秒以上にしないことをお勧めします。

Hyper-V のホスト サーバーに Hyper-V 関連の最新の更新プログラムが適用されていることを確認します。ライブ マイグレーションを行うネットワークで、ジャンボ フレームが有効になっており、関連するスイッチがジャンボ フレームをサポートしていることを確認します。また、各 Hyper-V ホストの受信バッファーを 8,192 に変更し、ライブ マイグレーションを行うネットワークでは可能な限り高い帯域幅 (5 GB 以上推奨) を使用することを推奨します。

各 VM は、移動またはオフライン時に、状態をディスクに保存して復元するように構成されていることが重要です。ターゲット ノードで VM が実行されている場合には、フェールオーバーにより、コールド ブートが行われる必要があります。そのため、移行の計画には、シャットダウンとコールド ブートも含めます。[クラスター制御されたオフライン操作] は、既定では [状態の保存] に設定されています。この設定を [シャットダウン] に変更し (図 1 参照)、ある Hyper-V ノードから別のノードにライブ マイグレーションが行われた場合に、サーバーがコールド ブートを行うようにする必要があります。

[クラスター制御されたオフライン操作] の設定を [シャット ダウン] にする

図 1 [クラスター制御されたオフライン操作] の設定を [シャット ダウン] にする

最近公開されたホワイトペーパー「Windows Server 2008 R2 の Hyper-V を使用して Exchange Server 2010 を仮想化するためのベスト プラクティス (英語)」には、Hyper-V を使用した Exchange Server 2010 の仮想化に関する多くの有益な情報が含まれています。また、最後になりますが、TechNet ライブラリの記事「Exchange 2010 のシステム要件」には、この新しいサポートの情報が反映されています。

FQDN の登録

Q. 当社では Exchange Server 2010 を展開しており、クライアント アクセス サーバー (CAS) の役割をインストールしたサーバーが 12 台あります。アクティブ/パッシブ ユーザー配布のデータセンター モデルを採用しています。つまり、プライマリ データセンターとフェールオーバー データセンターがあります。各データセンターには、CAS の役割をインストールしたサーバーを 6 台ずつ配置しています。ハードウェア ベースの負荷分散装置によるソリューションを使用して、各データセンターのクライアント アクセス トラフィックの負荷分散を行っています。ユーザー数は約 50,000 で、その多くは社内から Outlook 2007 または Outlook 2010 クライアントを使用してメールボックスに接続しています。

最近、Exchange チーム ブログのこの投稿を読みました。この投稿では、すべてのユーザーに対して社内の Outlook クライアントで Kerberos 認証を有効にすることを推奨し、その理由を説明しています。これを読んで、社内の Outlook クライアントで Kerberos 認証を有効にする計画に着手しました。

しかし、このブログ記事を熟読し、TechNet で公開されている Exchange Server 2010 の関連ドキュメントも確認しましたが、どの完全修飾ドメイン名 (FQDN) をサービス プリンシパル名 (SPN) として登録する必要があるのかという点について、やや不明な点があります。自動検出 FQDN の場合はどうしたらよいでしょうか。この FQDN も登録する必要はありますか。

A. 自動検出 FQDN に関して、少々困惑されているお気持ちは理解できます。多くの顧客は、通常、自動検出 FQDN に、autodiscover.<会社名>.com という名前を付けています。この FQDN は、社外から接続するクライアント (主に Outlook Anywhere と Exchange ActiveSync を使用したデバイス) のプロファイルを自動生成するためのものです。

Outlook 2007 と Outlook 2010 の機能には自動検出サービスを利用しているものがいくつかあります。たとえば、不在時のアシスタント (OOF)、オフライン アドレス帳 (OAB)、ユニファイド メッセージング(UM) です。しかし、社内の Outlook 2007 と Outlook 2010 クライアントでは、自動検出 FQDN を使用せず、社内の自動検出サービスの Uniform Resource Identifier (URI) を使用して Active Directory のサービス接続ポイント (既定では、CAS の FQDN) を検索します (図 2 参照)。

CAS アレイの CAS 間でクライアント トラフィックを分散するために負荷分散ソリューションを使用する場合、通常、負荷分散装置で実行されている各仮想サービスに関連付けられた仮想 IP アドレス (VIP) を指すように、社内の自動検出サービス URI を構成します。顧客によっては、このために専用の FQDN を使用する場合もあります。また、Outlook Web App (OWA)、Exchange コントロール パネル (ECP)、OAB、Exchange Web サービスで使用しているのと同じ FQDN を使用する場合もあります。

社内の自動検出サービスの URI の FQDN

図 2 社内の自動検出サービスの URI の FQDN

エンドポイントの更新

Q. 当社では、プライマリ データセンターとフェールオーバー データセンターの両方で、サイトの復元性を向上する Exchange Server 2010 ソリューションを構成しています。先日、データセンターの障害回復計画の手順を確認するために、データセンターの計画的な切り替えを実施しました。この切り替え作業中に気付いたことがあります。プライマリ データセンターの CAS アレイの DNS レコードがフェールオーバー データセンターの CAS アレイを指すように切り替わった後、社内の Outlook クライアントは正常に接続できましたが、 クライアントの接続エンドポイントは更新されないままでした。

プライマリ データセンターで CAS アレイが使用できない状態で、その CAS アレイの DNS レコードがフェールオーバー データセンターの CAS アレイを指すように更新された場合、Outlook クライアントの接続エンドポイントも更新される仕様になっていないのでしょうか。

A. ご指摘の動作は、実は仕様どおりです。プライマリ データセンターの CAS アレイの DNS レコードがフェールオーバー データセンターの CAS アレイに関連付けられた IP アドレスを指すように変更された場合、接続エンドポイントは更新されない仕様となっており、また更新されるべきでもありません。ご指摘のように、CAS アレイ名が接続可能な IP アドレスとして解決される限り、Outlook クライアントは問題なく接続されます。

この動作により、データセンターを切り替えたときに行われるときのオーバーヘッドが軽減されます。留意する必要があるのは DNS のレプリケーションのみで、Outlook クライアントのプロファイルが更新されたかどうかについて心配する必要はありません。

プロファイルの更新

Q. 当社には複数の Active Directory サイトがあり、すべてのサイトに Exchnage Server 2010 SP1 を実行しているサーバーがあります。各サイトには、CAS の役割がインストールされているサーバーが 3 台あります。各サイトで 3 台の CAS の役割をインストールしているサーバー間でクライアント トラフィックを分散させるため、CAS アレイと DAG を作成し、メールボックスの復元性を高めています。

ある物理サイトから別の物理サイトにユーザーが完全に移動する場合があります。その場合、そのユーザーのメールボックスを移動先のサイトのメールボックス データベースに移動します。移動先のメールボックス データベースの RPC Client Access Server の値と異なる RPC CAS の値を持つメールボックス データベースからユーザーのメールボックスを移動するため、ユーザーの Outlook プロファイルは、移動先のメールボックス データベースの RPC CAS の値を反映して更新されるものと考えていました (図 3 参照)。

メールボックス データベースの RPC Client Access Server の値

図 3 メールボックス データベースの RPC Client Access Server の値

当社では Outlook 2003 クライアントは使用しておらず、Outlook 2007 と Outlook 2010 のみを使用しています。これまでのところ、プロファイルの修復を実行する以外に、Outlook のプロファイルを更新する方法がわかりません。

A. サイトをまたいでメールボックスを移動したとき (RPC CAS の値が異なる別のメールボックス データベースに移動したとき)、Outlook のプロファイルが自動的に更新されると考えたお気持ちはわかります。しかし、ご指摘の動作は、実は仕様どおりです。

この動作の理由は、移動元の CAS (アレイ) が Active Directory のプロパティに基づいてアクセスするメールボックスを決定することと関係しています。Active Directory の情報が最新であれば、間違ったメールボックス データベースにアクセスすることも、anecWrongServer 応答を受信することもありません (この応答は、Outlook のプロファイルの更新をトリガーするのに必要です)。Exchange 製品グループでは、この動作が理想的なものではないことを認識していますが、修正の具体的な見通しに関する情報はありません。

信頼せよ、しかし検証せよ

Q. 当社では Exchange Server 2010 のグループと他のグループ間におけるフェデレーションの設定に取り組んでいます。Exchange 2010 組織間でフェデレーションの信頼を確立するためには、サードパーティの証明機関 (CA) が発行した信頼された証明書を使用する必要があったと記憶しています。この記憶が正しいかどうか、確認させてください。

A. おそらく、その情報は Exchange Server 2010 SP1 がリリースされる以前に目にされたのではないかと思います。Exchange Server 2010 RTM では、2 つの Exchange 2010 組織間でフェデレーションの信頼を確立するためには、サードパーティの CA が発行した信頼された証明書が必要でした。

しかし、これは Exchange Server 2010 SP1 のリリース時に変更されました。Exchange Server 2010 SP1 では、自己署名証明書または社内 PKI で発行された証明書を使用することが可能です。実際、新しいフェデレーションの信頼ウィザードでは、フェデレーションの信頼に使用するための自己署名証明書を自動的に作成してインストールします (図 4 参照)。

新しいフェデレーションの信頼ウィザードで作成された新しい自己署名証明書

図 4 新しいフェデレーションの信頼ウィザードで作成された新しい自己署名証明書

Henrik Walther

Henrik Walther は、マイクロソフト認定資格を持つ専門家です。IT ビジネスの分野で 15 年以上の経験がある、Exchange Server 2007 および Exchange Server MVP です。Timengo Consulting (デンマークを拠点とするマイクロソフト認定ゴールド パートナー) でテクノロジ アーキテクトを、Biblioso Corp. (ドキュメント管理とローカライズ サービスを専門とする米国の企業) でテクニカル ライターを務めています。

関連コンテンツ