次の方法で共有

高可用性とサイトの回復性を計画する

  • [アーティクル]

計画段階では、システム設計者、管理者、その他の主な関係者は、展開のビジネス要件とアーキテクチャ要件 (特に、高可用性とサイトの復元性に関する要件) を把握することが求められます。

これらの機能の展開において満たしていなければならない一般的な要件がありますが、その他にも、ハードウェア、ソフトウェア、およびネットワークにおける要件があります。

一般的な要件

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

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

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

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

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

ハードウェア要件

一般に、DAG またはメールボックス データベース コピーに固有の特別なハードウェア要件はありあません。 使用するサーバーは、Exchange Server前提条件に記載されているすべての要件を満たしている必要があります。

格納域の要件

一般に、DAG またはメールボックス データベース コピーに固有の特別な格納域要件はありません。 DAG では、クラスター管理された共有格納域を必要とすることも、使用することもありません。 クラスター管理共有ストレージは、EXCHANGE SERVERに組み込まれているサード パーティ レプリケーション API を利用するソリューションを使用するように DAG が構成されている場合にのみ、DAG での使用がサポートされます。

ソフトウェア要件

DAG の各メンバーは、同じオペレーティング システムを実行している必要があります。 Exchange Server 2016 は、Windows Server 2012、Windows Server 2012 R2、およびWindows Server 2016でサポートされています。 Exchange Server 2019 は、Windows Server 2019 および Windows Server 2022 オペレーティング システムでサポートされています。 特定の DAG 内では、すべてのメンバーは同一のサポートされているオペレーティング システムを実行している必要があります。

注:

windows Server 2022 サーバーのサポートは、Exchange Server 2019 CU12 (2022H1) で導入されました。

Exchange Serverをインストールするための前提条件を満たすだけでなく、オペレーティング システムの要件を満たす必要があります。 DAG は Windows フェールオーバー クラスタリング テクノロジを使用するため、Windows Server 2012、Windows Server 2012 R2、Windows Server 2016、Windows Server 2019、または Windows Server 2022 オペレーティング システムの Standard または Datacenter バージョンが必要になります。

ネットワーク要件

DAG ごとに、および DAG メンバーごとに満たす必要がある特定のネットワーク要件があります。 各 DAG には、DAG メンバーが他のサーバー (たとえば、他の Exchange サーバーやディレクトリ サーバー) と通信するために使用する 1 つの MAPI ネットワークと、ログ配布とシード処理専用のネットワークである 0 個以上の レプリケーション ネットワークが必要です。

以前のバージョンの Exchange では、DAG 用のネットワークを少なくとも 2 つ (MAPI ネットワーク用とレプリケーション ネットワーク用) 用意することをお勧めしていました。 Exchange 2016 と Exchange 2019 では、複数のネットワークがサポートされていますが、推奨は物理ネットワーク トポロジによって異なります。 物理的に分離された DAG メンバー間に複数の物理ネットワークが存在する場合は、別々の MAPI ネットワークとレプリケーション ネットワークを使用すると冗長性が向上します。 部分的には物理的に分離されているものの、単一の物理ネットワーク (単一の WAN リンクなど) に収束している複数のネットワークが存在する場合は、MAPI とレプリケーションの両方のトラフィック用の単一の物理ネットワーク (10 ギガビット イーサネットを推奨) を使用することをお勧めします。 これにより、ネットワークとネットワーク パスが簡略化されます。

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

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

  • DAG メンバーごとに 2 つずつのネットワーク アダプターを使用すると、1 つの 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 メンバー サーバーの各ネットワークは、それぞれ独自のネットワーク サブネット上になければなりません。 DAG 内の各サーバーは異なるサブネット上に設定できますが、MAPI とレプリケーション ネットワークは、以下のようにルーティング可能で、接続を提供する必要があります。

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

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

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

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

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

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

  • DAG ネットワークでは、インターネット プロトコル バージョン 4 (IPv4) と IPv6 がサポートされています。 IPv6 は、IPv4 も使用されている場合にのみサポートされます。純粋な IPv6 環境はサポートされていません。 IPv6 アドレスと IP アドレス範囲の使用は、そのコンピューターで IPv6 と IPv4 の両方が有効になっていて、ネットワークが両方の IP アドレス バージョンをサポートしている場合にのみサポートされます。 この構成にExchange Serverが展開されている場合、すべてのサーバー ロールは、IPv6 アドレスを使用するデバイス、サーバー、クライアントとの間でデータを送受信できます。

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

DAG 名と IP アドレスの要件

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

Windows Server 2012で実行されている各 DAG には、MAPI ネットワーク上の少なくとも 1 つの IP アドレスが必要です。 MAPI ネットワークを複数のサブネットにまたがって構築するときは、DAG にさらに IP アドレスを追加する必要があります。 クラスター管理アクセス ポイントなしで作成された Windows Server 2012 R2、Windows Server 2016、Windows Server 2019、または Windows Server 2022 で実行されている DAG は、IP アドレスを必要としません。

次の図は、DAG 内のすべてのノードが同じサブネット上に MAPI ネットワークを持つ DAG を示しています。

同じサブネット上に MAPI ネットワークを持つ DAG

単一サブネット上の DAG。

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

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

複数のサブネットにわたる MAPI ネットワークを持つ DAG

複数のサブネットにわたって拡張された DAG。

この例では、各 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 Serverにハード依存関係はありません。 基になるクラスターの管理アクセス ポイント (IP アドレスやネットワーク名リソースなど) がオフラインの場合でも、内部通信は DAG メンバー サーバー名を使用して DAG 内で行われます。 ただし、これらのリソースの可用性を定期的に監視して、30 日間以上オフライン状態にならないようにすることをお勧めします。 基になるクラスターが 30 日以上オフライン状態であると、クラスターの CNO アカウントが Active Directory のガベージ コレクション メカニズムによって無効化されることがあります。

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

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

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

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

ネットワーク機能 Settings
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) レスポンダー 有効

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

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

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

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

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

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

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

ネットワーク機能 Settings
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 フェールオーバー クラスタリングにおけるクォーラムの概念の 1 つの側面です。 フェールオーバー クラスターのクォーラムに関連して必要な側面は、 クォーラム リソースです。 クォーラム リソースは、フェールオーバー クラスター内のリソースであり、クラスターの状態とメンバーシップの決定につながる仲裁手段を提供します。 クォーラム リソースには、構成情報を格納するための永続的なストレージも用意されています。 クォーラム リソースのコンパニオンはクォーラム ログであり、クラスターの構成データベースです。 クォーラム ログには、クラスターのメンバーであるサーバー、クラスターにインストールされているリソース、それらのリソースの状態 (オンラインやオフラインなど) などの情報が含まれます。

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

サイトの復元計画

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

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

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

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

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

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

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

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

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

  • どのような SLA でスタンバイ データセンターをアクティブ化するか。

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

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

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

証明書の計画

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

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

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

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

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

ネットワークの計画

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

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

  • クライアントに接続する DNS レコードの Time to Live (TTL) の値は 5 分である必要があります。クライアントが発生するダウンタイムの量は、切り替えの実行速度だけでなく、DNS レプリケーションの実行速度や更新された DNS 情報のクエリにも依存します。 Outlook on the web (旧称Outlook Web App)、Exchange ActiveSync、Exchange Web サービス、Outlook Anywhere、SMTP、POP3、IMAP4 を含むすべての Exchange クライアント サービスの DNS レコードは、内部 DNS サーバーと外部 DNS サーバーの両方で TTL 5 分で設定する必要があります。

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

一般的なサイト復元計画

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

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

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

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

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

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

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

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

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

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