次の方法で共有

高可用性とサイト復元の計画

  • [アーティクル]

 

適用先: Exchange Server 2010 SP2, Exchange Server 2010 SP3

トピックの最終更新日: 2016-11-28

Microsoft Exchange Server 2010 には、データベース可用性グループ (DAG) やメールボックス データベース コピーなどの新機能を備えた、メールボックス復元用の新しい統合フレームワークが組み込まれています。これらの新機能の展開は迅速でシンプルなプロセスですが、これらの機能を活用した高可用性とサイトの復元ソリューションをユーザーの期待、さらにはユーザーの業務要件を満たすものにするには、事前に入念な計画を立案する必要があります。

計画段階においてシステム設計者、管理者、およびその他の主な関係者は、展開の要件、特に高可用性とサイトの復元についての要件を把握する必要があります。 これらの機能の展開において満たしていなければならない一般的な要件がありますが、その他にも、ハードウェア、ソフトウェア、およびネットワークにおける要件があります。DAG のストレージ要件に関するガイダンスについては、「メールボックス サーバーの記憶域設計」を参照してください。

目次

一般的な要件

ハードウェア要件

格納域の要件

ソフトウェア要件

ネットワーク要件

ミラーリング監視サーバーの要件

サイトの復元計画

データセンターの切り替え計画

一般的な要件

DAG の展開およびメールボックス データベース コピーの作成の前に、以下のシステム全体に関わる推奨事項が満たされていることを確認します。

  • ドメイン ネーム システム (DNS) が実行されている必要があります。 通常は、この DNS サーバーで、動的更新を受け付けるように設定しておくことをお勧めします。 DNS サーバーが動的更新を受け付けない場合は、Exchange サーバーごとに DNS ホスト (A) レコードを作成する必要があります。 このレコードを作成しないと、Exchange は正常に動作しません。

  • DAG 内の各メールボックス サーバーは、同じドメインのメンバー サーバーである必要があります。

  • ディレクトリ サーバーでもある Exchange 2010 メールボックス サーバーを DAG に追加することはサポートしていません。

  • DAG に割り当てる名前は、15 文字以内の、有効で、使用可能な一意のコンピューター名である必要があります。

ハードウェア要件

一般に、DAG またはメールボックス データベース コピーに固有の特別なハードウェア要件はありあません。使用するサーバーは、「Exchange 2010 の前提条件」および「Exchange 2010 のシステム要件」のトピックで示されるすべての要件を満たしている必要があります。ハードウェア計画については、以下のトピックを参照してください。

格納域の要件

一般的に、DAG またはメールボックス データベース コピーに固有の特別な格納域の要件はありません。 DAG では、クラスター管理された共有格納域を必要とすることも、使用することもありません。クラスター管理された共有格納域は、DAG が Exchange 2010 に組み込まれているサード パーティ レプリケーション API を活用するソリューションを使用するように構成されている場合にのみ、DAG での使用がサポートされています。格納域の計画については、「メールボックス サーバーの記憶域設計」を参照してください。

ソフトウェア要件

DAG は、Exchange 2010 Standard Edition と Exchange 2010 Enterprise Edition の両方で利用できます。さらに、DAG には、Exchange 2010 Standard Edition および Exchange 2010 Enterprise Edition を実行しているサーバーを混在させることができます。

また、DAG の各メンバーは、同じオペレーティング システムを実行する必要があります。Exchange 2010 は、Windows Server 2008 と Windows Server 2008 R2 オペレーティング システムの両方でサポートされています。DAG のすべてのメンバーは、Windows Server 2008 または Windows Server 2008 R2 のいずれかを実行する必要があります。DAG のすべてのメンバーには、Windows Server 2008 と Windows Server 2008 R2 を混在させることはできません。

Exchange 2010 のインストールのための前提条件を満たす以外に、満たすべきオペレーティング システム要件があります。DAG は Windows フェールオーバー クラスタリング テクノロジを採用しているため、Windows の Enterprise バージョンが必要です。

ネットワーク要件

各 DAG および各 DAG メンバーで満たす必要がある特定のネットワーク要件があります。DAG ネットワークは、Exchange の旧バージョンで採用されていたパブリック、混合、プライベート ネットワークの各ネットワークに類似します。ただし、旧バージョンとは異なり、各 DAG メンバー内で単一のネットワークを使用する構成はサポートされています。さらに、用語に多少の変更があります。 パブリック、プライベート、混合の各ネットワークの代わりに、各 DAG には、他の Exchange 2010 サーバーやディレクトリ サーバーなどのその他のサーバーが DAG メンバーと通信するために使用する単一の MAPI ネットワークと、ログ配布とシード専用のネットワークであるレプリケーション ネットワーク (複数でも可、あるいは存在しなくてもかまいません) があります。

単一のネットワークがサポートされていますが、各 DAG には、単一の MAPI ネットワークと単一のレプリケーション ネットワークの 少なくとも 2 つのネットワークを備えることをお勧めします。 これにより、ネットワークとネットワーク パスに冗長性を持たせることが可能になり、システムがサーバー障害とネットワーク障害を区別できるようになります。 単一のネットワーク アダプターを使用すると、システムがこれらの 2 つのタイプの障害を区別できなくなります。

注意

このコンテンツ領域にある製品ドキュメントでは、各 DAG メンバーには少なくとも 2 つのネットワーク アダプターが備えられていること、各 DAG は MAPI ネットワークと少なくとも 1 つのレプリケーション ネットワークで構成されていること、さらに、システムがネットワーク障害とサーバー障害を区別できるようにすることを前提に説明します。

DAG のネットワーク インフラストラクチャを設計する際は、以下の点を考慮します。

  • DAG の各メンバーには、他のすべての DAG メンバーとの通信を可能にする少なくとも 1 つのネットワーク アダプターが必要になります。単一のネットワーク パスを使用する場合は、ギガビット イーサネットを使用することをお勧めします。各 DAG メンバーで単一のネットワーク アダプターを使用する場合、DAG ネットワークでのレプリケーションを有効にし、DAG ネットワークを MAPI ネットワークとして構成する必要があります。 他のネットワークが存在しないため、システムでは MAPI ネットワークをレプリケーション ネットワークとしても使用します。 さらに、各 DAG メンバーで単一のネットワーク アダプターを使用する場合は、単一のネットワーク アダプターとパスに考慮して、ソリューション全体を設計することをお勧めします。

  • 各 DAG メンバーで 2 つのネットワーク アダプターを使用すると、MAPI ネットワークとレプリケーション ネットワークをそれぞれ 1 つずつ装備できるので、次の回復動作が実行されます。

    • MAPI ネットワークに影響を及ぼす障害が発生した場合、サーバー フェールオーバーが発生します (アクティブ化可能な正常なメールボックス データベース コピーが存在することが前提となります)。

    • レプリケーション ネットワークに影響を及ぼす障害が発生した場合、MAPI ネットワークが障害による影響を受けていなければ、MAPI ネットワークの ReplicationEnabled プロパティ設定が False に設定されていても、ログ配布とシード操作によって元どおり MAPI ネットワークを使用するように戻されます。 障害が発生したレプリケーション ネットワークが回復し、ログ配布とシード操作を再開できるようになったら、レプリケーション ネットワークを手動で切り替える必要があります。MAPI ネットワークから回復したレプリケーション ネットワークにレプリケーションを変更するには、Suspend-MailboxDatabaseCopy および Resume-MailboxDatabaseCopy コマンドレットを使用して連続レプリケーションを中断して再開するか、Microsoft Exchange Replication サービスを再起動します。Microsoft Exchange Replication サービスの再起動による短時間の停止を防ぐため、中断と再開による操作をお勧めします。

  • 各 DAG メンバーは、同じ数のネットワークを備える必要があります。たとえば、1 つの DAG メンバー内で単一のネットワーク アダプターを使用するように計画する場合、DAG のすべてのメンバーも単一のネットワーク アダプターを使用する必要があります。

  • 各 DAG には、複数の MAPI ネットワークが備えないようにする必要があります。 MAPI ネットワークは、他の Exchange サーバー、および Active Directory や DNS などのその他のサービスへの接続を提供する必要があります。

  • 必要に応じて、さらにレプリケーション ネットワークを追加できます。 また、ネットワーク アダプター チームや同様のテクノロジを使用することで、個々のネットワーク アダプターが単一障害点になることを防止することもできます。ただし、チームを使用した場合は、ネットワーク自体が単一障害点になることを防止することはできません。

  • 各 DAG メンバー サーバーの各ネットワークは、それぞれ独自のネットワーク サブネット上になければなりません。 DAG 内の各サーバーは異なるサブネット上に設定できますが、MAPI とレプリケーション ネットワークは、以下のようにルーティング可能で、接続を提供する必要があります。

    • 各 DAG メンバー サーバーの各ネットワークは、サーバーの他の各ネットワークが使用するサブネットとは別の独自のネットワーク サブネット上にあります。

    • 各 DAG メンバー サーバーの MAPI ネットワークは、他の各 DAG メンバーの MAPI ネットワークと通信できます。

    • 各 DAG メンバー サーバーのレプリケーション ネットワークは、他の各 DAG メンバーのレプリケーション ネットワークと通信できます。

    • 特定の DAG メンバーサーバーのレプリケーション ネットワークから別の DAG メンバー サーバーの MAPI ネットワークへ、その逆、あるいは DAG 内の複数のレプリケーション ネットワーク間のハートビート トラフィックを許可する直接ルーティングは存在しません。

  • 他の DAG メンバーからの地理的な位置に関係なく、DAG の各メンバーは、他の各メンバー間で 500 ミリ秒未満のラウンド トリップ ネットワーク待ち時間が必要になります。データベースのコピーをホストしている 2 台のメールボックス サーバー間のラウンド トリップ待ち時間が増えると、レプリケーションが最新でなくなる可能性が高くなります。ソリューションの待ち時間にかかわらず、すべての DAG メンバー間のネットワークが、展開におけるデータ保護と可用性の目標を満たすことを検証する必要があります。待ち時間の長い構成では、必要な目標を実現するために、DAG、レプリケーション、およびネットワーク パラメーターの特別な調整 (データベース数の増加、データベースあたりのメールボックス数の削減など) が必要になる場合があります。

  • ラウンドトリップ待ち時間要件は、複数のデータセンター構成のネットワークの帯域幅と待ち時間についての最も厳格な要件ではない場合があります。 クライアント アクセス、Active Directory、トランスポート、連続レプリケーション、およびその他のアプリケーション トラフィックを含む全体的なネットワーク負荷を評価し、環境に必要なネットワーク要件を判断する必要があります。

  • DAG ネットワークでは、インターネット プロトコル Version 4 (IPv4) と IPv6 をサポートしています。 IPv6 は、IPv4 と併用される場合だけサポートされます。IPv6 のみの環境はサポートされません。 IPv6 アドレスおよび IP アドレスの範囲は、該当するコンピューターで IPv6 と IPv4 の両方が有効化されており、ネットワークで両方の IP アドレス バージョンがサポートされている場合にのみ使用できます。Exchange 2010 がこの構成で展開されている場合、すべてのサーバーの役割は、IPv6 アドレスを使用するデバイス、サーバー、およびクライアントとの間でデータを送受信できます。

  • 自動プライベート IP アドレス指定 (APIPA) は、Microsoft Windows の機能の 1 つで、動的ホスト構成プロトコル (DHCP) サーバーがネットワーク上で利用できないときに自動的に IP アドレスを割り当てます。APIPA アドレス (APIPA アドレスの範囲から手動で割り当てたアドレスを含めて) の使用は、DAG または Exchange 2010 ではサポートされません。

DAG 名と IP アドレスの要件

各 DAG には DAG の作成時に一意の名前が付けられ、1 つまたは複数の静的 IP アドレスが割り当てられるか、DHCP を使用するために構成されます。使用するアドレスが静的または動的に割り当てられたものかに関係なく、DAG に割り当てられたすべての IP アドレスは MAPI ネットワーク上にある必要があります。

各 DAG には、MAPI ネットワーク上に最低 1 つの IP アドレスが必要です。 MAPI ネットワークを複数のサブネットにまたがって構築するときは、DAG にさらに IP アドレスを追加する必要があります。 次の図は、DAG 内のすべてのノードが同じサブネット上に MAPI ネットワークを持つ DAG を示しています。

同じサブネット上に MAPI ネットワークを持つデータベース可用性グループ

この例では、各 DAG メンバーの MAPI ネットワークは、172.19.18.x サブネット上にあります。 このため、DAG にはそのサブネット上に単一の IP アドレスが必要になります。

次の図は、2 つのサブネット (172.19.18.) 間を拡張する MAPI ネットワークを持つ DAG を示しています。 x と 172.19.19.x の 2 つのサブネット間にわたる MAPI ネットワークを持つ DAG を示しています。

複数のサブネット上にある MAPI ネットワークを持つデータベース可用性グループ

この例では、各 DAG メンバーの MAPI ネットワークは、別のサブネット上にあります。 このため、DAG には 2 つの IP アドレス (MAPI ネットワーク上の各サブネットに 1 つずつ) が必要になります。

DAG の MAPI ネットワークを追加のサブネットに拡張するたびに、そのサブネットのための追加の IP アドレスを DAG に対して構成する必要があります。 DAG に対して構成される各 IP アドレスは、DAG の基になるフェールオーバー クラスターに割り当てられ、このクラスターによって使用されます。 DAG の名前は、基になるフェールオーバー クラスターの名前としても使用されます。

どのような時でも、DAG のクラスターは割り当てられた IP アドレスの 1 つのみを使用します。 Windows フェールオーバー クラスタリングは、クラスター IP アドレスとネットワーク名リソースがオンラインで接続されるときにこの IP アドレスを DNS に登録します。 IP アドレスとネットワーク名の使用以外に、Active Directory 内でクラスター名オブジェクト (CNO) が作成されます。クラスターの名前、IP アドレス、CNO は、DAG のセキュリティ保護と内部通信のためにシステムによって内部的に使用されます。管理者とエンドユーザーは、DAG 名または IP アドレスとインターフェイスしたり、接続したりする必要はありません。

注意

クラスターの IP アドレスとネットワーク名はシステムによって内部的に使用されますが、これらのリソースが利用可能な Exchange 2010 では強い依存関係はありません。基になるクラスターの IP アドレスとネットワーク名リソースがオフラインでも、DAG メンバーのサーバー名を使用することで DAG 内では引き続き内部通信が行われます。 ただし、これらのリソースの可用性を定期的に監視して、30 日間以上オフライン状態にならないようにすることをお勧めします。 基になるクラスターが 30 日以上オフライン状態であると、クラスターの CNO アカウントが Active Directory のガベージ コレクション メカニズムによって無効化されることがあります。

DAG のネットワーク アダプターの構成

各ネットワーク アダプターは、その使用目的に基づいて正しく構成する必要があります。 MAPI ネットワークで使用するネットワーク アダプターは、レプリケーション ネットワークで使用するネットワーク アダプターとは別に構成します。 各ネットワーク アダプターを正しく構成するばかりでなく、MAPI ネットワークが接続順序の最上位になるように Windows でネットワーク接続の順序も構成する必要があります。ネットワーク接続の順序の変更方法の詳細な手順については、「プロトコルのバインドの順序を変更する (英語の場合があります)」を参照してください (このサイトは英語の場合があります)。

MAPI ネットワーク アダプターの構成

MAPI ネットワークで使用することを目的とするネットワーク アダプターは、次の表に示すように構成する必要があります。

ネットワーク機能 設定

Microsoft ネットワーク用クライアント

有効

QoS パケット スケジューラ

必要に応じて有効

Microsoft ネットワーク用ファイルとプリンター共有

Enable

Internet Protocol version 6 (TCP/IP v6)

必要に応じて有効

Internet Protocol version 4 (TCP/IP v4)

有効

Link-Layer Topology Discovery Mapper I/O Driver

有効

Link-Layer Topology Discovery (LLTD) レスポンダー

有効

次のように MAPI ネットワーク アダプターの TCP/IP v4 プロパティを構成します。

  • DAG メンバーの MAPI ネットワークの IP アドレスは、DHCP を使用するために手動での割り当て、または構成が可能です。DHCP を使用する場合は、サーバーの IP アドレスには永続的な予約を使用することをお勧めします。

  • MAPI ネットワークは通常、既定のゲートウェアを使用しますが、これは必須ではありません。

  • 少なくとも 1 つの DNS サーバー アドレスを構成する必要があります。 冗長性のために複数の DNS サーバーを使用することをお勧めします。

  • [この接続のアドレスを DNS に登録する] チェック ボックスをオンにする必要があります。

レプリケーション ネットワーク アダプターの構成

レプリケーション ネットワークで使用することを目的としたネットワーク アダプターは、次の表に示すように構成する必要があります。

ネットワーク機能 設定

Microsoft ネットワーク用クライアント

無効

QoS パケット スケジューラ

必要に応じて有効

Microsoft ネットワーク用ファイルとプリンター共有

無効

Internet Protocol version 6 (TCP/IP v6)

必要に応じて有効

Internet Protocol version 4 (TCP/IP v4)

有効

Link-Layer Topology Discovery Mapper I/O Driver

有効

Link-Layer Topology Discovery (LLTD) レスポンダー

有効

次のようにレプリケーション ネットワーク アダプターの TCP/IP v4 プロパティを構成します。

  • DAG メンバーのレプリケーション ネットワークの IP アドレスは、DHCP を使用するために手動での割り当て、または構成が可能です。DHCP を使用する場合は、サーバーの IP アドレスには永続的な予約を使用することをお勧めします。

  • レプリケーション ネットワークには通常、既定のゲートウェイがありません。MAPI ネットワークに既定のゲートウェイがある場合は、他のネットワークには既定のゲートウェイがありません。 レプリケーション ネットワーク上でのネットワーク トラフィックのルーティングは、レプリケーション ネットワーク間でルーティング可能なゲートウェイ アドレスを使用する他の DAG メンバーの対応するネットワークへの永続的で静的なルートを使用することで構成できます。 このルートに一致しない他のすべてのトラフィックは、MAPI ネットワークのアダプター上に構成されている既定のゲートウェイによって処理されます。

  • DNS サーバー アドレスを構成しないようにします。

  • [この接続のアドレスを DNS に登録する] チェック ボックスをオンにしないようにします。

一般的な要件

ミラーリング監視サーバーの要件

ミラーリング監視サーバーは、DAG の外部にあるサーバーで、DAG が偶数のメンバーを持つときにクォーラムを達成および保持するのに使用されます。奇数のメンバーを持つ DAG はミラーリング監視サーバーを使用しません。偶数のメンバーを持つすべての DAG がミラーリング監視サーバーを使用します。 ミラーリング監視サーバーには、Windows Server を実行しているコンピューターであればどのコンピューターでも指定できます。ミラーリング監視サーバーの Windows Server オペレーティング システムのバージョンが、DAG メンバーによって使用されるオペレーティング システムと一致しなければならないという要件はありません。

クォーラムは、DAG の下のクラスター レベルで保持されます。 DAG メンバーの過半数がオンラインで、DAG の他のオンライン メンバーと通信可能であるときに DAG はクォーラムを持ちます。 このようなクォーラムの考え方は、Windows フェールオーバー クラスタリングにおけるクォーラムの概念のひとつの側面です。 フェールオーバー クラスターにおけるクォーラムに関係する必要な側面が、クォーラム リソースです。 クォーラム リソースは、クラスター状態とメンバーシップを決定する方法を提供するフェールオーバー クラスター内部にあるリソースです。 また、クォーラム リソースは構成情報を格納するための永続的な記憶域を提供します。 クォーラム リソースに付随する機能として、クォーラム ログがあります。これは、クラスターの構成データベースです。 クォーラム ログには、クラスターのメンバーであるサーバー、クラスター内にインストールされているリソース、これらのリソースの状態 (たとえば、オンラインかオフラインか) などの情報が記録されます。

各 DAG メンバーが DAG の基になるクラスターの構成方法を示す一貫したビューで表示されることは重要なことです。 クォーラムは、クラスターに関連するすべての構成情報の最終リポジトリとして動作します。また、クォーラムは、"スプリットブレイン" 現象を回避するためのタイ ブレーカーとして使用されます。スプリット ブレイン現象は、DAG メンバーが相互に通信できないが、稼動しているときに発生する状態です。 スプリットブレイン現象は、DAG メンバー (および偶数のメンバーを持つ DAG の場合は、DAG ミラーリング監視サーバー) の過半数が常に使用可能であることを要求し、さらに DAG が運用可能な状態にするために通信を行うことで防止されます。

サイトの復元計画

日々多くのビジネスで、高い信頼性と可用性を備えたメッセージング システムへのアクセスがビジネス成功の基になるという認識が高まっています。 多くの組織では、メッセージング システムはビジネス継続性計画の一部であり、組織のメッセージング サービスの展開はサイトの復元を考慮して設計されます。 基本的に、多くのサイトの復元ソリューションでは、第 2 データセンターにハードウェアを展開する必要があります。

最終的に、DAG メンバー数やメールボックス データベース コピー数などの DAG の設計全体は、多様な障害シナリオを網羅する各組織の回復に関するサービス レベル契約によって左右されます。 計画段階においてソリューションの設計者と管理者は、特にサイトの復元に必要な要件などの展開の要件を確認します。ソリューションの設計者と管理者は、使用する場所と必要な回復に関する SLA の目標を確認します。 SLA によって、高可用性とサイトの復元を提供するソリューション設計の基となる 2 つの要素、回復時間の目標 (RTO) と回復ポイント目標 (RPO) が決定されます。 これら 2 の値は共に分単位で計測されます。RTO は、サービスの復元にかかる時間を指します。RPO は、回復操作の完了後に許容されるデータを表します。 また、SLA にはプライマリ データセンターの問題が解決した後にプライマリ データセンターが完全なサービスを提供する状態まで戻すことが規定されることもあります。

さらに、ソリューションの設計者と管理者は、サイト復元保護を必要とするユーザー セットを特定し、マルチサイト ソリューションをアクティブ/パッシブ構成にするか、またはアクティブ/アクティブ構成にするかも決定します。 アクティブ/パッシブ構成では、通常スタンバイ データセンター内でユーザーはホストされません。 アクティブ/アクティブ構成では、ユーザーは両方の場所でホストされ、ソリューション内のデータベース総数のうちの一定の割合に、第 2 データセンターで優先度の高いアクティブな場所が割り当てられます。 1 つのデータセンターのユーザー向けのサービスに障害が発生すると、これらのユーザーは他のデータセンターでアクティブ化されます。

多くの場合、適切な SLA を作成するには次の基本的な質問に答える必要があります。

  • プライマリ データセンターの障害発生後に、どのようなレベルのサービスが必要か。

  • ユーザーにはデータが必要であるか、またはメッセージング サービスだけが必要か。

  • データはどれだけ迅速に必要とされるか。

  • 何人のユーザーをサポートする必要があるか。

  • ユーザーは自分のデータにどのようにアクセスするか。

  • どのようなサービス レベル契約 (SLA) でスタンバイ データセンターをアクティブ化するか。

  • どのようにしてプライマリ データセンターにサービスを戻すか。

  • リソースはサイトの復元ソリューション専用であるか。

これらの問題に回答することで、メッセージング ソリューションのためのサイトの復元設計の具体化を開始します。 サイト障害からの回復の中心的な要件は、バックアップ メッセージング サービスをホストするバックアップ データセンターに、必要なデータを届けるソリューションを作成することです。

名前空間の計画

Exchange 2010 では、サイトの復元構成を展開するときの名前空間設計の計画方法が変わりました。データセンターの切り替えを正常に実行するには、適切な名前空間の計画を立案することが重要になります。名前空間という観点から、サイトの復元構成で使用される各データセンターはアクティブであると考えられます。そのため、各データセンターには、そのサイトのさまざまな Exchange 2010 サービスのためにデータセンター独自の一意の名前空間が必要になります。これには、Outlook Web App、Outlook Anywhere、Exchange ActiveSync、Exchange Web サービス、RPC Client Access、POP3 (Post Office Protocol version 3)、IMAP4 (Internet Message Access Protocol version 4)、SMTP (Simple Mail Transfer Protocol) などのための名前空間があります。さらに、データセンターの 1 つは、自動検索のための名前空間もホストします。この設計を使用すると、プライマリ データセンターから第 2 データセンターへの単一データベースの切り替えを実行して、データセンターの切り替えの検証と実践の一環として、第 2 のデータの構成も検証できます。

ベスト プラクティスとして、クライアントが使用する Exchange ホスト名にスプリット DNS を使用することをお勧めします。スプリット DNS とは、内部 DNS サーバーがホスト名の内部 IP アドレスを返し、外部 (インターネットに直接接続されている) DNS サーバーが同じホスト名のパブリック IP アドレスを返す DNS サーバー構成のことをいいます。スプリット DNS を使用した場合、同じホスト名が内部と外部で使用されるので、この方法であれば必要なホスト名の数を最小限にすることができます。

次の図は、サイトの復元構成のための名前空間の計画を示しています。

サイト復元 DAG 展開のための名前空間

上記に示すように、各データセンターは独立した一意の名前空間を使用し、それぞれにそれらの名前空間のスプリット DNS 構成内に DNS サーバーを配置します。プライマリデータセンターとみなされる Redmond データセンターは protocol.contoso.com の名前空間で構成されます。Portland データセンターはprotocol.standby.contoso.com の名前空間で構成されます。名前空間には、スタンバイの指定を含めることができます。例の図と同様、名前空間は、地域を基準に (たとえば、protocol.portland.contoso.com)、または組織のニーズに合った他の名前付け規則を基準に指定することができます。重要な要件は、使用する名前付け規則に関係なく、各データセンターにデータセンター独自の一意の名前空間を設定することです。

FailbackURL の構成

Microsoft Internet Explorer を含む一部の Web ブラウザーでは、各ブラウザー セッション中、オペレーティング システムにより提供される DNS キャッシュとは別の DNS ネーム キャッシュを保持します。データセンターの切り替え後、プライマリ データセンターにフェールバックする間、この別のキャッシュが Web ブラウザーで使用されていることにより、Outlook Web App ユーザーが同じ URL に繰り返しリダイレクトされるログオン ループが発生することがあります。

フェールバック プロセス中、Outlook Web App 名前空間の IP アドレスは、DNS 内でスタンバイ データセンターのエンドポイントからプライマリ データセンターの元のエンドポイントに変更されます。 DNS レコードの TTL が期限切れになった後、またオペレーティング システムの DNS キャッシュがクリアされた後でも、独自の異なる名前キャッシュを維持する Web ブラウザーは、その名前空間がプライマリ データセンター内でホストされていても、スタンバイ データセンターのエンドポイントへの接続を継続する可能性があります。

通常、異なる名前キャッシュをクリアし、ログオン ループを防止するには、Web ブラウザーを閉じるだけで十分です。ただし、Outlook Web App 仮想ディレクトリの FailbackURL プロパティを構成して、すべての Web ブラウザーと Outlook Web App ユーザーでこの問題を軽減できます。FailbackUrl パラメーターには、Outlook Web App がプライマリ サイトにフェールバックした後にクライアント アクセス サーバーへの接続に使用するホスト名を指定します。この名前空間には、元のクライアント アクセス サーバーの IP アドレスをポイントする別の DNS エントリが必要になります。FailbackUrl パラメーターの値は、Outlook Web App 仮想ディレクトリの ExternalUrl パラメーターの値とは異なる必要があります。Outlook Web App ユーザーが資格情報を入力すると、クライアント アクセス サーバーは、リダイレクト URL がユーザーが閲覧している URL と同じかどうかを検出します。URL が同じ場合、クライアント アクセス サーバーは、FailbackUrl パラメーターが構成されているかどうかを確認します。

  • FailbackUrl パラメーターが構成されている場合、ユーザーをその URL にリダイレクトします。ここで、ユーザーは Outlook Web App にアクセスできるはずです。

  • FailbackUrl パラメーターが構成されていない場合、サーバーの構成変更によってメールボックスへのアクセスが一時的に禁止されているというエラー メッセージがユーザーに表示されます。メッセージによって、すべてのブラウザー ウィンドウを閉じ (このため、ブラウザーの名前キャッシュがクリアされます)、数分してから再試行するように指示されます。

証明書の計画

単一のデータセンター内で DAG を展開する場合、証明書の設計に関する考慮事項は特にありません。 ただし、サイトの復元構成の複数のデータセンター間に DAG がまたがる場合は、証明書に関する特定の考慮事項がいくつかあります。 一般に、証明書設計は、使用するクライアントと、証明書を使用する他のアプリケーションによる証明書要件によって左右されます。 ただし、証明書の種類や数について準拠すべき特定の推奨事項とベスト プラクティスがいくつかあります。

ベスト プラクティスとして、クライアント アクセス サーバー、リバース プロキシ サーバー、トランスポート サーバー (エッジおよびハブ) で使用する証明書の数は最小限に抑えることをお勧めします。 各データセンター内のこれらのサービス エンドポイントすべてに対して単一の証明書を使用することをお勧めします。 このアプローチにより、必要な証明書の数が最小限に抑えられ、ソリューションのコストと複雑性の両方が削減されます。

Outlook Anywhere クライアントの場合、データセンターごとに単一のサブジェクトの別名 (SAN) 証明書を使用し、証明書内に複数のホスト名を含めることをお勧めします。データベース、サーバー、またはデータセンターの切り替え後に Outlook Anywhere の接続が確実に行われるようにするには、各証明書で同じ証明書のプリンシパル名を使用し、Microsoft の標準フォーム (msstd) の同じプリンシパル名で Outlook プロバイダー構成オブジェクト Active Directory を構成する必要があります。たとえば、mail.contoso.com の証明書のプリンシパル名を使用する場合、次のように属性を構成します。

Set-OutlookProvider EXPR -CertPrincipalName "msstd:mail.contoso.com"

Exchange と統合するアプリケーションの一部には、追加の証明書の使用を必要とする場合がある特定の証明書要件があります。Exchange 2010 は、Office Communications Server (OCS) と共存できます。 OCS には、証明書のプリンシパル名に OCS サーバー名を使用する 1024 ビット以上の証明書を含めた証明書が必要です。 証明書のプリンシパル名に OCS サーバー名を使用すると、Outlook Anywhere が正しく機能しなくなるので、OCS 環境に対応した別の証明書をさらに使用する必要があります。

Exchange 2010 クライアント アクセスのための SAN 証明書の使用の詳細については、「クライアント アクセス サーバーのホスト名を複数使用するように SSL 証明書を構成する」を参照してください。

ネットワークの計画

各 DAG、および DAG のメンバーである各サーバーで満たす必要があるネットワーキング要件のほかに、サイトの復元構成固有の要件と推奨事項がいくつかあります。すべての DAG と同様に、DAG メンバーが単一サイトまたは複数のサイトのいずれに展開されようと、DAG メンバー間のラウンドトリップ リターン ネットワーク待ち時間は 500 ミリ秒未満にする必要があります。 さらに、複数のサイトにまたがる DAG について推奨する次のような特定の構成設定があります。

  • MAPI ネットワークをレプリケーション ネットワークから隔離する必要があるWindows ネットワーク ポリシー、Windows ファイアウォール ポリシー、またはルーター アクセス制御リスト (ACL) を使用して、MAPI ネットワークとレプリケーション ネットワーク間のトラフィックを遮断する必要があります。この構成は、ネットワーク ハートビートの漏話を防止するために必要になります。

  • クライアントに直接接続された DNS レコードには、5 分間の TTL (Time to Live) を設定する必要がある クライアントで体験するダウンタイム時間は、切り替えが発生できる速度ばかりではなく、DNS レプリケーションが発生する速度と更新された DNS 情報に対するクライアントの照会速度にも依存します。内部および外部両方の DNS サーバーの Exchange、Outlook Web App、Exchange ActiveSync Web サービス、Exchange Anywhere、SMTP、POP3、IMAP4、RPC クライアント アクセスなどのすべての Outlook クライアント サービスの DNS レコードの TTL は 5 分に設定する必要があります。

  • レプリケーション ネットワーク全体の接続を構成するには、静的なルートを使用する 各レプリケーション ネットワーク アダプター間にネットワーク接続を提供するには、永続的な静的ルートを使用します。これは、静的な IP アドレスを使用するときに各 DAG メンバーで実行される迅速で 1 回限りの構成です。レプリケーション ネットワークの IP アドレスを取得するために DHCP を使用する場合、DHCP を使用してレプリケーションの静的なルートを割り当てることが可能で、これにより構成プロセスを簡略化することができます。

一般的なサイトの復元計画

高可用性に関する上記の要件に加え、(複数のデータセンターにまたがる DAG などの) サイトの復元構成での Exchange 2010 の展開についての推奨事項が他にもあります。 計画段階で実行する内容がサイトの復元ソリューションの成功に直接影響することになります。 たとえば、名前空間の設計が適切でないと、証明書上に問題が発生する可能性があったり、また証明書の構成が正しくないと、ユーザーがサービスにアクセスできなかったりする場合があります。

第 2 データセンターをアクティブ化するためにかかる時間を最小限に抑え、障害が発生したデータセンターのサービス エンドポイントを第 2 データセンターがホストできるようにするには、適切な計画を立案する必要があります。たとえば、

  • サイトの復元ソリューションのサービス レベル契約 (SLA) の目的を十分に理解し、ドキュメント化する必要があります。

  • 第 2 データセンター内のサーバーには、2 つのデータセンター内の合計ユーザー人口をホストするのに十分な容量を確保する必要があります。

  • 第 2 データセンターでは、プライマリ データセンターで提供されるすべてのサービスを有効にする必要があります (ただし、サイトの復元 SLA の中にそのサービスが含まれていない場合は除きます)。このようなサービスには、Active Directory、ネットワーキング インフラストラクチャ (DNS や TCP/IP など)、テレフォニー サービス (ユニファイド メッセージングを使用している場合)、サイトのインフラストラクチャ (電力や冷却など) があります。

  • 一部のサービスでは障害が発生したデータセンターのユーザーにサービスを提供できるようにするために、ユーザーが適切なサーバー証明書を構成する必要があります。サービスによってはインスタンス化が許可されず (POP3 や IMAP4 など)、単一の証明書の使用のみが許可されるものがあります。このような場合、証明書を、複数の名前を含めたサブジェクトの別名 (SAN) 証明書にするか、複数の名前に、ワイルドカード証明書を使用できるような類似名を付ける必要があります (ただし、組織のセキュリティ ポリシーによってワイルドカード証明書の使用が許可されていなければなりません)。

  • 第 2 データセンター内に必要なサービスを定義する必要があります。たとえば、最初のデータセンターの異なるトランスポート サーバーに 3 つの異なる SMTP URL が設定されている場合、第 2 データセンター内に少なくとも 1 台の (3 台すべてではなく) トランスポート サーバーで負荷をホストできるように適切な構成を定義する必要があります。

  • データセンターの切り替えをサポートするために必要なネットワーク構成を正しく設定する必要があります。これは、たとえば、負荷分散の構成を正しく設定し、グローバル DNS を構成し、さらに適切なルーティングを構成してインターネット接続を有効にしていることを意味します。

  • データセンターの切り替えに必要な DNS 変更を有効にする戦略を理解する必要があります。DNS 変更の TTL (Time to Live) 設定などの特定の DNS 変更は、SLA で効力を持たせるために規定し、ドキュメント化する必要があります。

  • ソリューションをテストする戦略を立案して、SLA に盛り込むことも必要です。時間の経過に伴って展開の質と実行可能性が低下することがないようにするには、定期的に展開を検証することが唯一の方法です。 展開の検証後には、ソリューションの成功に直接影響する構成部分を明示的にドキュメント化する必要があります。 さらに、展開のこれらのセグメント前後の変更管理プロセスを強化することをお勧めします。

一般的な要件

データセンターの切り替え計画

適切な計画と準備には、実際のクライアント アクセス サーバーやハブ トランスポート サーバーなどの第 2 データセンター リソースの展開ばかりでなく、データセンターの切り替え操作に必要な変更事項を最小限にするためのこれらのリソースの事前構成があります。

注意

第 2 データセンターのメールボックス データベースの自動アクティブ化をブロックしている場合も、第 2 データセンター内にクライアント アクセスおよびハブ トランスポート サービスが必要になります。これらのサービスは、データベースの切り替えと、第 2 データセンター内のサービスとデータのテストと検証を実行するために必要になります。

データセンターの切り替えプロセスの動作をより深く理解するには、Exchange 2010 データセンターの切り替えの基本操作を理解することが有用です。

次の図に示すように、サイトの復元展開は 2 つのデータセンターにメンバーを持つ DAG で構成されます。

2 つのデータセンターにメンバーを持つデータベース可用性グループ

DAG が複数のデータセンターにまたがる場合は、DAG メンバーの過半数をプライマリ データセンターに配置するか、または各データセンターのメンバー数を同じにする場合は、プライマリ データセンターがミラーリング監視サーバーをホストするように DAG を設計する必要があります。このように設計すると、2 つのデータセンター間のネットワーク接続に障害が発生しても、プライマリ データセンターでサービスが提供されることが保証されます。ただし、同時にこのような設計はプライマリ データセンターに障害が発生すると、第 2 データセンター内のメンバーのクォーラムが失われることも意味します。

部分的なデータセンター障害というものは起こり得るものであり、また起こるものです。プライマリ データセンターで有効なサービスと管理の提供を不可能にするために必要な機能が失われる場合、第 2 データセンターをアクティブ化するためにデータセンターの切り替えを実行すべきであることが推測されます。アクティブ化プロセスには、管理者が、部分的に稼動状態にある存続しているサーバーのサービスを中断する構成があります。その後、第 2 データセンター内でアクティブ化を続行します。これは、両方のサービス セットを同時に稼動しないようにするためです。

クォーラムが失われたため、第 2 データセンター内の DAG メンバーは自動的にオンラインになることはできません。したがって、第 2 データセンター内でメールボックス サーバーをアクティブ化するには、障害が発生したデータセンターのサーバーが内部的に (ただし一時的にのみ) DAG から削除された時点で、DAG メンバー サーバーで強制的にクォーラムを作成する手順も必要になります。これにより、安定した、ある程度の障害がさらに発生してもそれに耐え、稼動し続ける部分的なサービス ソリューションが提供されます。

注意

障害がさらに発生してもそれに耐えられるための 1 つの前提条件として、DAG が少なくとも 4 つのメンバーを持ち、その 4 つのメンバーが 2 つの Active Directory サイトにまたがっている (たとえば、各データセンター内に 2 つ以上のメンバーが配置されている) ことが挙げられます。

これは、第 2 データセンター内のメールボックス役割機能を再構築するための基本的なプロセスです。第 2 データセンター内の他の役割のアクティブ化には、第 2 データセンターで影響を受けたサーバーに対する明確なアクションは必要ありません。代わりに、第 2 データセンター内のサーバーが、通常プライマリデータ センターでホストされるサービスのサービス エンドポイントになります。たとえば、通常プライマリ データセンターでホストされるユーザーは、Outlook Web App への接続に https://mail.contoso.com/owa を使用します。データセンター障害が発生した後、これらのサービスのエンドポイントは、切り替え操作の中で第 2 データセンター内のエンドポイントに移動します。切り替え操作中、プライマリ データセンターのサービスのエンドポイントは、第 2 データセンター内の同じサービスの代替 IP アドレスに再度指定されます。これにより、切り替えプロセス中に Active Directory に保存された構成情報への変更が最小限に抑えられます。通常、この手順を実行するには次の 2 つの方法があります。

  • DNS レコードを更新する。

  • DNS と負荷分散装置を再構成して代替 IP アドレスを有効/無効にし、データセンター間のサービスを移動する。

ソリューションをテストするための戦略を立案する必要があります。この戦略を SLA に盛り込む必要があります。時間の経過に伴って展開の質が低下することがないようにするには、定期的に展開を検証することが唯一の方法です。

これらの計画手順を慎重に実行することが、データセンターの切り替えが正常に完了できるかどうかに直接影響することになります。たとえば、名前空間の設計が適切でないと、証明書上に問題が発生する可能性があったり、また証明書の構成が正しくないと、ユーザーがサービスにアクセスできなかったりする場合があります。

展開の検証後には、データセンターの切り替えの成功に直接影響するすべての構成部分を明示的にドキュメント化する必要があります。さらに、展開のこれらのセグメント前後の変更管理プロセスを強化することをお勧めします。

第 2 データセンターのアクティブ化、障害が発生した (プライマリ) データセンターの再アクティブ化などのデータセンターの切り替えの詳細については、「データセンターの切り替え」を参照してください。

一般的な要件

 © 2010 Microsoft Corporation.All rights reserved.