高可用性とサイトの復元計画Planning for high availability and site resilience

製品: Exchange Server 2013Applies to: Exchange Server 2013

計画段階では、システム設計者、管理者、その他の主な関係者は、展開のビジネス要件とアーキテクチャ要件 (特に、高可用性とサイトの復元性に関する要件) を把握することが求められます。During the planning phase, the system architects, administrators, and other key stakeholders should identify the business requirements and the architectural requirements for the deployment; in particular, the requirements about high availability and site resilience.

これらの機能の展開において満たしていなければならない一般的な要件がありますが、その他にも、ハードウェア、ソフトウェア、およびネットワークにおける要件があります。There are general requirements that must be met for deploying these features, as well as hardware, software, and networking requirements that must also be met.

一般的な要件General requirements

データベース可用性グループ (DAG) の展開およびメールボックス データベース コピーの作成の前に、以下のシステム全体に関わる推奨事項が満たされていることを確認します。Before deploying a database availability group (DAG) and creating mailbox database copies, make sure that the following system-wide recommendations are met:

  • ドメイン ネーム システム (DNS) が実行されている必要があります。通常は、この DNS サーバーで、動的更新を受け付けるように設定しておくことをお勧めします。DNS サーバーが動的更新を受け付けない場合は、Exchange サーバーごとに DNS ホスト (A) レコードを作成する必要があります。このレコードを作成しないと、Exchange は正常に動作しません。Domain Name System (DNS) must be running. Ideally, the DNS server should accept dynamic updates. If the DNS server doesn't accept dynamic updates, you must create a DNS host (A) record for each Exchange server. Otherwise, Exchange won't function properly.

  • DAG 内の各メールボックス サーバーは、同じドメインのメンバー サーバーである必要があります。Each Mailbox server in a DAG must be a member server in the same domain.

  • ディレクトリサーバーでもある Exchange 2013 メールボックスサーバーを DAG に追加することはサポートされていません。Adding an Exchange 2013 Mailbox server that's also a directory server to a DAG isn't supported.

  • DAG に割り当てる名前は、15 文字以内の、有効で、使用可能な一意のコンピューター名である必要があります。The name you assign to the DAG must be a valid, available, and unique computer name of 15 characters or less.

ハードウェアの要件Hardware requirements

一般に、DAG またはメールボックス データベース コピーに固有の特別なハードウェア要件はありあません。Generally, there are no special hardware requirements specific to DAGs or mailbox database copies. 使用するサーバーは、「 exchange 2013 の前提条件」および「 exchange 2013 のシステム要件」のトピックで規定されているすべての要件を満たしている必要があります。The servers used must meet all of the requirements set forth in the topics for Exchange 2013 prerequisites and Exchange 2013 system requirements.

格納域の要件Storage requirements

一般に、DAG またはメールボックス データベース コピーに固有の特別な格納域要件はありません。Generally, there are no special storage requirements specific to DAGs or mailbox database copies. DAG では、クラスター管理された共有格納域を必要とすることも、使用することもありません。DAGs don't require or use cluster-managed shared storage. クラスター管理された共有記憶域は、dag で使用するために、Exchange 2013 に組み込まれたサードパーティレプリケーション API を活用するソリューションを使用するように構成されている場合にのみサポートされます。Cluster-managed shared storage is supported for use in a DAG only when the DAG is configured to use a solution that leverages the Third Party Replication API built into Exchange 2013.

ソフトウェア要件Software requirements

Dag は、Exchange 2013 Standard および Exchange 2013 Enterprise の両方で使用できます。DAGs are available in both Exchange 2013 Standard and Exchange 2013 Enterprise. また、DAG には、Exchange 2013 Standard および Exchange 2013 Enterprise を実行しているサーバーの混在を含めることができます。In addition, a DAG can contain a mix of servers running Exchange 2013 Standard and Exchange 2013 Enterprise.

DAG の各メンバーは、同じオペレーティングシステムを実行している必要もあります。Each member of the DAG must also be running the same operating system. Exchange 2013 は、Windows Server 2008 R2、Windows Server 2012、および Windows Server 2012 R2 オペレーティングシステムでサポートされています。Exchange 2013 is supported on the Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 operating systems. 特定の DAG のすべてのメンバーは、同じオペレーティングシステムを実行する必要があります。All members of a specific DAG must run the same operating system. Windows Server 2012 R2 は、Exchange 2013 Service Pack 1 以降を実行している DAG メンバーに対してのみサポートされています。Windows Server 2012 R2 is supported only for DAG members that are running Exchange 2013 Service Pack 1 or later.

Exchange 2013 をインストールするための前提条件を満たすだけでなく、オペレーティングシステムの要件を満たす必要があります。In addition to meeting the prerequisites for installing Exchange 2013, there are operating system requirements that must be met. DAG は Windows フェールオーバー クラスタリング テクノロジを採用しているため、Windows Server 2008 R2 の Enterprise または Datacenter バージョンか、Windows Server 2012 または Windows Server 2012 R2 オペレーティング システムの Standard または Datacenter バージョンが必要です。DAGs use Windows Failover Clustering technology, and as a result, they require the Enterprise or Datacenter version of Windows Server 2008 R2, or the Standard or Datacenter version of the Windows Server 2012 or Windows Server 2012 R2 operating systems.

ネットワーク要件Network requirements

各 DAG および各 DAG メンバーについて、特定のネットワーク要件を満たす必要があります。There are specific networking requirements that must be met for each DAG and for each DAG member. 各 DAG には1つのMAPI ネットワークが必要です。これは、dag メンバーが他のサーバー (たとえば、他の Exchange 2013 サーバーまたはディレクトリサーバー) と通信するために使用します。また、0個以上のレプリケーションネットワーク(これはログ専用のネットワーク) を使用します。送料とシード。Each DAG must have a single MAPI network, which is used by a DAG member to communicate with other servers (for example, other Exchange 2013 servers or directory servers), and zero or more Replication networks, which are networks dedicated to log shipping and seeding.

以前のバージョンの Exchange では、DAG 用のネットワークを少なくとも 2 つ (MAPI ネットワーク用とレプリケーション ネットワーク用) 用意することをお勧めしていました。In previous versions of Exchange, we recommended at least two networks (one MAPI network and one Replication network) for DAGs. Exchange 2013 では、複数のネットワークがサポートされていますが、推奨されるのは物理ネットワークトポロジによって決まります。In Exchange 2013, multiple networks are supported, but our recommendation depends on your physical network topology. 物理的に分離された DAG メンバー間に複数の物理ネットワークが存在する場合は、別々の MAPI ネットワークとレプリケーション ネットワークを使用すると冗長性が向上します。If you have multiple physical networks between DAG members that are physically separate from one another, then using a separate MAPI and Replication network provides additional redundancy. 部分的には物理的に分離されているものの、単一の物理ネットワーク (単一の WAN リンクなど) に収束している複数のネットワークが存在する場合は、MAPI とレプリケーションの両方のトラフィック用の単一の物理ネットワーク (10 ギガビット イーサネットを推奨) を使用することをお勧めします。If you have multiple networks that are partially physically separate but converge into a single physical network (for example, a single WAN link), then using a single network (preferably 10 gigabit Ethernet) for both MAPI and Replication traffic is recommended. これにより、ネットワークとネットワーク パスが簡略化されます。This provides simplicity for the network and the network path.

DAG のネットワーク インフラストラクチャを設計する際は、以下の点を考慮します。Consider the following when designing the network infrastructure for your DAG:

  • DAG の各メンバーには、他のすべての DAG メンバーとの通信を可能にする少なくとも 1 つのネットワーク アダプターが必要になります。単一のネットワーク パスを使用する場合は、少なくとも 1 ギガビット以上のイーサネット、可能であれば、10 ギガビット イーサネットの使用をお勧めします。さらに、各 DAG メンバーで単一のネットワーク アダプターを使用する場合は、単一のネットワーク アダプターとパスに考慮して、ソリューション全体を設計することをお勧めします。Each member of the DAG must have at least one network adapter that's able to communicate with all other DAG members. If you're using a single network path, we recommend that you use a minimum of 1 gigabit Ethernet, but preferably 10 gigabit Ethernet. In addition, when using a single network adapter in each DAG member, we recommend that you design the overall solution with the single network adapter and path in mind.

  • DAG メンバーごとに 2 つずつのネットワーク アダプターを使用すると、1 つの MAPI ネットワークと 1 つのレプリケーション ネットワーク、レプリケーション ネットワークの冗長性、および以下の回復動作が実現します。Using two network adapters in each DAG member provides you with one MAPI network and one Replication network, with redundancy for the Replication network and the following recovery behaviors:

    • MAPI ネットワークに影響を及ぼす障害が発生した場合、サーバー フェールオーバーが発生します (アクティブ化可能な正常なメールボックス データベース コピーが存在することが前提となります)。In the event of a failure affecting the MAPI network, a server failover will occur (assuming there are healthy mailbox database copies that can be activated).

    • レプリケーションネットワークに影響を与える障害が発生した場合、mapi ネットワークが障害の影響を受けないと、mapi ネットワークでReplicationenabledプロパティが False に設定されていたとしても、ログ配布およびシード操作が mapi ネットワークの使用に戻ります。.In the event of a failure affecting the Replication network, if the MAPI network is unaffected by the failure, log shipping and seeding operations will revert to use the MAPI network, even if the MAPI network has it's ReplicationEnabled property set to False. 障害が発生したレプリケーション ネットワークが回復し、ログ配布とシード操作を再開できるようになったら、レプリケーション ネットワークを手動で切り替える必要があります。When the failed Replication network is restored to health and ready to resume log shipping and seeding operations, you must manually switch over to the Replication network. MAPI ネットワークから回復したレプリケーション ネットワークにレプリケーションを変更するには、 Suspend-MailboxDatabaseCopy および Resume-MailboxDatabaseCopy コマンドレットを使用して連続レプリケーションを中断して再開するか、Microsoft Exchange Replication サービスを再起動します。To change replication from the MAPI network to a restored Replication network, you can either suspend and resume continuous replication by using the Suspend-MailboxDatabaseCopy and Resume-MailboxDatabaseCopy cmdlets, or restart the Microsoft Exchange Replication service. Microsoft Exchange Replication サービスの再起動による短時間の停止を防ぐため、中断と再開による操作をお勧めします。We recommend using suspend and resume operations to avoid the brief outage caused by restarting the Microsoft Exchange Replication service.

  • 各 DAG メンバーは、同じ数のネットワークを備える必要があります。たとえば、1 つの DAG メンバー内で単一のネットワーク アダプターを使用するように計画する場合、DAG のすべてのメンバーも単一のネットワーク アダプターを使用する必要があります。Each DAG member must have the same number of networks. For example, if you plan on using a single network adapter in one DAG member, all members of the DAG must also use a single network adapter.

  • 各 DAG には、複数の MAPI ネットワークが備えないようにする必要があります。MAPI ネットワークは、他の Exchange サーバー、および Active Directory や DNS などのその他のサービスへの接続を提供する必要があります。Each DAG must have no more than one MAPI network. The MAPI network must provide connectivity to other Exchange servers and other services, such as Active Directory and DNS.

  • 必要に応じて、さらにレプリケーション ネットワークを追加できます。また、ネットワーク アダプター チームや同様のテクノロジを使用することで、個々のネットワーク アダプターが単一障害点になることを防止することもできます。ただし、チームを使用した場合は、ネットワーク自体が単一障害点になることを防止することはできません。その上、チームを使用すると DAG の複雑さが不要に増すことになります。Additional Replication networks can be added, as needed. You can also prevent an individual network adapter from being a single point of failure by using network adapter teaming or similar technology. However, even when using teaming, this doesn't prevent the network itself from being a single point of failure. Moreover, teaming adds unnecessary complexity to the DAG.

  • 各 DAG メンバー サーバーの各ネットワークは、それぞれ独自のネットワーク サブネット上になければなりません。DAG 内の各サーバーは異なるサブネット上に設定できますが、MAPI とレプリケーション ネットワークは、以下のようにルーティング可能で、接続を提供する必要があります。Each network in each DAG member server must be on its own network subnet. Each server in the DAG can be on a different subnet, but the MAPI and Replication networks must be routable and provide connectivity, such that:

    • 各 DAG メンバー サーバーの各ネットワークは、サーバーの他の各ネットワークが使用するサブネットとは別の独自のネットワーク サブネット上にあります。Each network in each DAG member server is on its own network subnet that's separate from the subnet used by each other network in the server.

    • 各 DAG メンバー サーバーの MAPI ネットワークは、他の各 DAG メンバーの MAPI ネットワークと通信できます。Each DAG member server's MAPI network can communicate with each other DAG member's MAPI network.

    • 各 DAG メンバー サーバーのレプリケーション ネットワークは、他の各 DAG メンバーのレプリケーション ネットワークと通信できます。Each DAG member server's Replication network can communicate with each other DAG member's Replication network.

    • 特定の DAG メンバーサーバーのレプリケーション ネットワークから別の DAG メンバー サーバーの MAPI ネットワークへ、その逆、あるいは DAG 内の複数のレプリケーション ネットワーク間のハートビート トラフィックを許可する直接ルーティングは存在しません。There is no direct routing that allows heartbeat traffic from the Replication network on one DAG member server to the MAPI network on another DAG member server, or vice versa, or between multiple Replication networks in the DAG.

  • 他の DAG メンバーからの地理的な位置に関係なく、DAG の各メンバーは、他の各メンバー間で 500 ミリ秒未満のラウンド トリップ ネットワーク待ち時間が必要になります。データベースのコピーをホストしている 2 台のメールボックス サーバー間のラウンド トリップ待ち時間が増えると、レプリケーションが最新でなくなる可能性が高くなります。ソリューションの待ち時間にかかわらず、すべての DAG メンバー間のネットワークが、展開におけるデータ保護と可用性の目標を満たすことを検証する必要があります。待ち時間の長い構成では、必要な目標を実現するために、DAG、レプリケーション、およびネットワーク パラメーターの特別な調整 (データベース数の増加、データベースあたりのメールボックス数の削減など) が必要になる場合があります。Regardless of their geographic location relative to other DAG members, each member of the DAG must have round trip network latency no greater than 500 milliseconds between each other member. As the round trip latency between two Mailbox servers hosting copies of a database increases, the potential for replication not being up to date also increases. Regardless of the latency of the solution, customers should validate that the networks between all DAG members is capable of satisfying the data protection and availability goals of the deployment. Configurations with higher latency values may require special tuning of DAG, replication, and network parameters, such as increasing the number of databases or decreasing the number of mailboxes per database, to achieve the desired goals.

  • ラウンドトリップ待ち時間要件は、複数のデータセンター構成のネットワークの帯域幅と待ち時間についての最も厳格な要件ではない場合があります。クライアント アクセス、Active Directory、トランスポート、連続レプリケーション、およびその他のアプリケーション トラフィックを含む全体的なネットワーク負荷を評価し、環境に必要なネットワーク要件を判断する必要があります。Round trip latency requirements may not be the most stringent network bandwidth and latency requirement for a multi-datacenter configuration. You must evaluate the total network load, which includes client access, Active Directory, transport, continuous replication, and other application traffic, to determine the necessary network requirements for your environment.

  • DAG ネットワークは、インターネットプロトコルバージョン 4 (IPv4) および IPv6 をサポートしています。DAG networks support Internet Protocol version 4 (IPv4) and IPv6. IPv6 は、IPv4 も使用されている場合にのみサポートされます。純粋な IPv6 環境はサポートされていません。IPv6 is supported only when IPv4 is also used; a pure IPv6 environment isn't supported. Ipv6 アドレスと IP アドレス範囲の使用は、そのコンピューターで IPv6 と IPv4 の両方が有効になっている場合にのみサポートされ、ネットワークは両方の IP アドレスバージョンをサポートしています。Using IPv6 addresses and IP address ranges is supported only when both IPv6 and IPv4 are enabled on that computer, and the network supports both IP address versions. この構成で Exchange 2013 が展開されている場合、すべてのサーバーの役割は、IPv6 アドレスを使用するデバイス、サーバー、およびクライアントとの間でデータを送受信することができます。If Exchange 2013 is deployed in this configuration, all server roles can send data to and receive data from devices, servers, and clients that use IPv6 addresses.

  • 自動プライベート IP アドレス指定 (APIPA) は、Windows の機能の 1 つで、動的ホスト構成プロトコル (DHCP) サーバーがネットワーク上で利用できないときに自動的に IP アドレスを割り当てます。Automatic Private IP Addressing (APIPA) is a feature of Windows that automatically assigns IP addresses when no Dynamic Host Configuration Protocol (DHCP) server is available on the network. APIPA アドレス (APIPA アドレスの範囲から手動で割り当てられたアドレスを含む) は、Dag または Exchange 2013 によって使用することはサポートされていません。APIPA addresses (including manually assigned addresses from the APIPA address range) aren't supported for use by DAGs or by Exchange 2013.

DAG 名と IP アドレスの要件DAG name and IP address requirements

各 DAG には DAG の作成時に一意の名前が付けられ、1 つまたは複数の静的 IP アドレスが割り当てられるか、DHCP を使用するために構成されます。使用するアドレスが静的または動的に割り当てられたものかに関係なく、DAG に割り当てられたすべての IP アドレスは MAPI ネットワーク上にある必要があります。During creation, each DAG is given a unique name, and either assigned one or more static IP addresses, or configured to use DHCP. Regardless of whether you use static or dynamically assigned addresses, any IP address assigned to the DAG must be on the MAPI network.

Windows Server 2008 R2 または Windows Server 2012 上で実行している各 DAG には、MAPI ネットワーク上に最低 1 つの IP アドレスが必要です。MAPI ネットワークを複数のサブネットにまたがって構築するときは、DAG にさらに IP アドレスを追加する必要があります。クラスターの管理アクセス ポイントを使用せずに作成された、Windows Server 2012 R2 上で動作している DAG には IP アドレスが必要ありません。Each DAG running on Windows Server 2008 R2 or Windows Server 2012 requires a minimum of one IP address on the MAPI network. A DAG requires additional IP addresses when the MAPI network is extended across multiple subnets. DAGs running on Windows Server 2012 R2 that are created without a cluster administrative access point do not require an IP address.

次の図は、DAG 内のすべてのノードが同じサブネット上に MAPI ネットワークを持つ DAG を示しています。The following figure illustrates a DAG where all nodes in the DAG have the MAPI network on the same subnet.

同じサブネット上に MAPI ネットワークを持つ DAGDAG with MAPI network on same subnet

単一サブネット上の DAGDAG on single subnet

この例では、各 DAG メンバーの MAPI ネットワークが 172.19.18. にあります。xサブネットIn this example, the MAPI network in each DAG member is on the 172.19.18.x subnet. このため、DAG にはそのサブネット上に単一の IP アドレスが必要になります。As a result, the DAG requires a single IP address on that subnet.

次の図は、172.19.18.x と 172.19.19.x の 2 つのサブネット間にわたる MAPI ネットワークを持つ DAG を示しています。The next figure illustrates a DAG that has a MAPI network that extends across two subnets: 172.19.18.x and 172.19.19.x.

複数のサブネットにわたる MAPI ネットワークを持つ DAGDAG with MAPI network on multiple subnets

複数のサブネットにまたがる DAGDAG extended across multiple subnets

この例では、各 DAG メンバーの MAPI ネットワークは、別のサブネット上にあります。このため、DAG には 2 つの IP アドレス (MAPI ネットワーク上の各サブネットに 1 つずつ) が必要になります。In this example, the MAPI network in each DAG member is on a separate subnet. As a result, the DAG requires two IP addresses, one for each subnet on the MAPI network.

DAG の MAPI ネットワークを追加のサブネットに拡張するたびに、そのサブネットのための追加の IP アドレスを DAG に対して構成する必要があります。DAG に対して構成される各 IP アドレスは、DAG の基になるフェールオーバー クラスターに割り当てられ、このクラスターによって使用されます。DAG の名前は、基になるフェールオーバー クラスターの名前としても使用されます。Each time the DAG's MAPI network is extended across an additional subnet, an additional IP address for that subnet must be configured for the DAG. Each IP address that's configured for the DAG is assigned to and used by the DAG's underlying failover cluster. The name of the DAG is also used as the name for the underlying failover cluster.

どのような時でも、DAG のクラスターは割り当てられた IP アドレスの 1 つのみを使用します。Windows フェールオーバー クラスタリングは、クラスター IP アドレスとネットワーク名リソースがオンラインで接続されるときにこの IP アドレスを DNS に登録します。IP アドレスとネットワーク名の使用以外に、Active Directory 内でクラスター名オブジェクト (CNO) が作成されます。クラスターの名前、IP アドレス、CNO は、DAG のセキュリティ保護と内部通信のためにシステムによって内部的に使用されます。管理者とエンドユーザーは、DAG 名または IP アドレスとインターフェイスしたり、接続したりする必要はありません。At any specific time, the cluster for the DAG will use only one of the assigned IP addresses. Windows Failover Clustering registers this IP address in DNS when the cluster IP address and Network Name resources are brought online. In addition to using an IP address and network name, a cluster name object (CNO) is created in Active Directory. The name, IP address, and CNO for the cluster are used internally by the system to secure the DAG and for internal communication purposes. Administrators and end users don't need to interface with or connect to the DAG name or IP address.

注意

クラスターの IP アドレスとネットワーク名はシステムによって内部的に使用されますが、これらのリソースを使用できることは、Exchange 2013 には依存しません。Although the cluster's IP address and network name are used internally by the system, there is no hard dependency in Exchange 2013 that these resources be available. 基になるクラスターの管理アクセス ポイント (IP アドレスとネットワーク名リソースなど) がオフラインでも、DAG メンバーのサーバー名を使用することで DAG 内で引き続き内部通信が行われます。Even if the underlying cluster's administrative access point (e.g., it's IP address and Network Name resources) is offline, internal communication still occurs within the DAG by using the DAG member server names. ただし、これらのリソースの可用性を定期的に監視して、30 日間以上オフライン状態にならないようにすることをお勧めします。However, we recommend that you periodically monitor the availability of these resources to ensure that they aren't offline for more than 30 days. 基になるクラスターが 30 日以上オフライン状態であると、クラスターの CNO アカウントが Active Directory のガベージ コレクション メカニズムによって無効化されることがあります。If the underlying cluster is offline for more than 30 days, the cluster CNO account may be invalidated by the garbage collection mechanism in Active Directory.

DAG のネットワーク アダプターの構成Network adapter configuration for DAGs

各ネットワーク アダプターは、その使用目的に基づいて正しく構成する必要があります。MAPI ネットワークで使用するネットワーク アダプターは、レプリケーション ネットワークで使用するネットワーク アダプターとは別に構成します。各ネットワーク アダプターを正しく構成するばかりでなく、MAPI ネットワークが接続順序の最上位になるように Windows でネットワーク接続の順序も構成する必要があります。ネットワーク接続順序の変更方法の詳細手順については、「プロトコルのバインドとネットワーク プロバイダーの順序を変更する」を参照してください。Each network adapter must be configured properly based on its intended use. A network adapter that's used for a MAPI network is configured differently from a network adapter that's used for a Replication network. In addition to configuring each network adapter correctly, you must also configure the network connection order in Windows so that the MAPI network is at the top of the connection order. For detailed steps about how to modify the network connection order, see Modify the protocol bindings and network provider order.

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

MAPI ネットワークで使用することを目的とするネットワーク アダプターは、次の表に示すように構成する必要があります。A network adapter intended for use by a MAPI network should be configured as described in the following table.

ネットワーク機能Networking features SettingsSettings

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

有効Enabled

QoS パケット スケジューラQoS Packet Scheduler

必要に応じて有効Optionally enabled

Microsoft ネットワーク用ファイルとプリンター共有File and Printer Sharing for Microsoft Networks

有効Enabled

Internet Protocol version 6 (TCP/IP v6)Internet Protocol version 6 (TCP/IP v6)

有効Enabled

Internet Protocol version 4 (TCP/IP v4)Internet Protocol version 4 (TCP/IP v4)

有効Enabled

Link-Layer Topology Discovery Mapper I/O DriverLink-Layer Topology Discovery Mapper I/O Driver

有効Enabled

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

有効Enabled

次のように MAPI ネットワーク アダプターの TCP/IP v4 プロパティを構成します。The TCP/IP v4 properties for a MAPI network adapter are configured as follows:

  • DAG メンバーの MAPI ネットワークの IP アドレスは、DHCP を使用するために手動での割り当て、または構成が可能です。DHCP を使用する場合は、サーバーの IP アドレスには永続的な予約を使用することをお勧めします。The IP address for a DAG member's MAPI network can be manually assigned or configured to use DHCP. If DHCP is used, we recommend using persistent reservations for the server's IP address.

  • MAPI ネットワークは通常、既定のゲートウェアを使用しますが、これは必須ではありません。The MAPI network typically uses a default gateway, although one isn't required.

  • 少なくとも 1 つの DNS サーバー アドレスを構成する必要があります。冗長性のために複数の DNS サーバーを使用することをお勧めします。At least one DNS server address must be configured. Using multiple DNS servers is recommended for redundancy.

  • [この接続のアドレスを DNS に登録する] チェック ボックスをオンにします。The Register this connection's addresses in DNS check box should be selected.

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

レプリケーション ネットワークで使用することを目的としたネットワーク アダプターは、次の表に示すように構成する必要があります。A network adapter intended for use by a Replication network should be configured as described in the following table.

ネットワーク機能Networking features SettingsSettings

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

無効Disabled

QoS パケット スケジューラQoS Packet Scheduler

必要に応じて有効Optionally enabled

Microsoft ネットワーク用ファイルとプリンター共有File and Printer Sharing for Microsoft Networks

無効Disabled

Internet Protocol version 6 (TCP/IP v6)Internet Protocol version 6 (TCP/IP v6)

有効Enabled

Internet Protocol version 4 (TCP/IP v4)Internet Protocol version 4 (TCP/IP v4)

有効Enabled

Link-Layer Topology Discovery Mapper I/O DriverLink-Layer Topology Discovery Mapper I/O Driver

有効Enabled

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

有効Enabled

次のようにレプリケーション ネットワーク アダプターの TCP/IP v4 プロパティを構成します。The TCP/IP v4 properties for a Replication network adapter are configured as follows:

  • DAG メンバーのレプリケーション ネットワークの IP アドレスは、DHCP を使用するために手動での割り当て、または構成が可能です。DHCP を使用する場合は、サーバーの IP アドレスには永続的な予約を使用することをお勧めします。The IP address for a DAG member's Replication network can be manually assigned or configured to use DHCP. If DHCP is used, we recommend using persistent reservations for the server's IP address.

  • レプリケーション ネットワークには通常、既定のゲートウェイがありません。MAPI ネットワークに既定のゲートウェイがある場合は、他のネットワークには既定のゲートウェイがありません。レプリケーション ネットワーク上でのネットワーク トラフィックのルーティングは、レプリケーション ネットワーク間でルーティング可能なゲートウェイ アドレスを使用する他の DAG メンバーの対応するネットワークへの永続的で静的なルートを使用することで構成できます。このルートに一致しない他のすべてのトラフィックは、MAPI ネットワークのアダプター上に構成されている既定のゲートウェイによって処理されます。Replication networks typically don't have default gateways, and if the MAPI network has a default gateway, no other networks should have default gateways. Routing of network traffic on a Replication network can be configured by using persistent, static routes to the corresponding network on other DAG members using gateway addresses that have the ability to route between the Replication networks. All other traffic not matching this route will be handled by the default gateway that's configured on the adapter for the MAPI network.

  • DNS サーバー アドレスを構成しないようにします。DNS server addresses shouldn't be configured.

  • [この接続のアドレスを DNS に登録する] チェック ボックスをオンにしないようにします。The Register this connection's addresses in DNS check box shouldn't be selected.

監視サーバーの要件Witness server requirements

ミラーリング監視サーバーは、DAG の外部にあるサーバーで、DAG が偶数のメンバーを持つときにクォーラムを達成および保持するのに使用されます。A witness server is a server outside a DAG that's used to achieve and maintain quorum when the DAG has an even number of members. DAG のメンバーの数が奇数の場合は、ミラーリング監視サーバーを使用しません。DAGs with an odd number of members don't use a witness server. 偶数のメンバーを持つすべての DAG がミラーリング監視サーバーを使用する必要があります。All DAGs with an even number of members must use a witness server. ミラーリング監視サーバーには、Windows Server を実行しているコンピューターであればどのコンピューターでも指定できます。The witness server can be any computer running Windows Server. ミラーリング監視サーバーの Windows Server オペレーティング システムのバージョンが、DAG メンバーによって使用されるオペレーティング システムと一致しなければならないという要件はありません。There is no requirement that the version of the Windows Server operating system of the witness server matches the operating system used by the DAG members.

クォーラムは、DAG の下のクラスター レベルで保持されます。DAG メンバーの過半数がオンラインで、DAG の他のオンライン メンバーと通信可能であるときに DAG はクォーラムを持ちます。このようなクォーラムの考え方は、Windows フェールオーバー クラスタリングにおけるクォーラムの概念のひとつの側面です。フェールオーバー クラスターにおけるクォーラムに関係する必要な側面が、クォーラム リソースです。クォーラム リソースは、クラスター状態とメンバーシップを決定する方法を提供するフェールオーバー クラスター内部にあるリソースです。また、クォーラム リソースは構成情報を格納するための永続的な記憶域を提供します。クォーラム リソースに付随する機能として、クォーラム ログがあります。これは、クラスターの構成データベースです。クォーラム ログには、クラスターのメンバーであるサーバー、クラスター内にインストールされているリソース、これらのリソースの状態 (たとえば、オンラインかオフラインか) などの情報が記録されます。Quorum is maintained at the cluster level, underneath the DAG. A DAG has quorum when the majority of its members are online and can communicate with the other online members of the DAG. This notion of quorum is one aspect of the concept of quorum in Windows failover clustering. A related and necessary aspect to quorum in failover clusters is the quorum resource. The quorum resource is a resource inside a failover cluster that provides a means for arbitration leading to cluster state and membership decisions. The quorum resource also provides persistent storage for storing configuration information. A companion to the quorum resource is the quorum log, which is a configuration database for the cluster. The quorum log contains information such as which servers are members of the cluster, what resources are installed in the cluster, and the state of those resources (for example, online or offline).

各 DAG メンバーが DAG の基になるクラスターの構成方法を示す一貫したビューで表示されることは重要なことです。クォーラムは、クラスターに関連するすべての構成情報の最終リポジトリとして動作します。また、クォーラムは、スプリットブレイン現象を回避するためのタイ ブレーカーとして使用されます。スプリットブレイン現象は、DAG メンバーが相互に通信できないが、稼動しているときに発生する状態です。スプリットブレイン現象は、DAG メンバー (および偶数のメンバーを持つ DAG の場合は、DAG ミラーリング監視サーバー) の過半数が常に使用可能であることを要求し、さらに DAG が運用可能な状態にするために通信を行うことで防止されます。It's critical that each DAG member have a consistent view of how the DAG's underlying cluster is configured. The quorum acts as the definitive repository for all configuration information relating to the cluster. The quorum is also used as a tie-breaker to avoid split-brain syndrome. Split brain syndrome is a condition that occurs when DAG members can't communicate with each other but are running. Split brain syndrome is prevented by always requiring a majority of the DAG members (and in the case of DAGs with an even number of member, the DAG witness server) to be available and interacting for the DAG to be operational.

サイトの復元計画Planning for site resilience

日々多くのビジネスで、高い信頼性と可用性を備えたメッセージング システムへのアクセスがビジネス成功の基になるという認識が高まっています。多くの組織では、メッセージング システムはビジネス継続性計画の一部であり、組織のメッセージング サービスの展開はサイトの復元を考慮して設計されます。基本的に、多くのサイトの復元ソリューションでは、第 2 データセンターにハードウェアを展開する必要があります。Every day, more businesses recognize that access to a reliable and available messaging system is fundamental to their success. For many organizations, the messaging system is part of the business continuity plans, and their messaging service deployment is designed with site resilience in mind. Fundamentally, many site resilient solutions involve the deployment of hardware in a second datacenter.

最終的に、DAG メンバー数やメールボックス データベース コピー数などの DAG の設計全体は、多様な障害シナリオを網羅する各組織の回復に関するサービス レベル契約によって左右されます。計画段階においてソリューションの設計者と管理者は、特にサイトの復元に必要な要件などの展開の要件を確認します。ソリューションの設計者と管理者は、使用する場所と必要な回復に関する SLA の目標を確認します。SLA によって、高可用性とサイトの復元を提供するソリューション設計の基となる 2 つの要素、目標復旧時間と目標復旧時点が決定されます。これら 2 の値は共に分単位で計測されます。目標復旧時間は、サービスの復元にかかる時間を指します。目標復旧時点は、回復操作が完了した後のデータがどの程度最新のものであるかを表します。また、SLA にはプライマリ データセンターの問題が解決した後にプライマリ データセンターが完全なサービスを提供する状態まで戻すことが既定されることもあります。Ultimately, the overall design of a DAG, including the number of DAG members and the number of mailbox database copies, will depend on each organization's recovery service level agreements (SLAs) that cover various failure scenarios. During the planning stage, the solution's architects and administrators identify the requirements for the deployment, including in particular the requirements for site resilience. They identify the locations to be used and the required recovery SLA targets. The SLA will identify two specific elements that should be the basis for the design of a solution that provides high availability and site resilience: the recovery time objective and the recovery point objective. Both of these values are measured in minutes. The recovery time objective is how long it takes to restore service. The recovery point objective refers to how current the data is after the recovery operation has completed. An SLA may also be defined for restoring the primary datacenter to full service after its problems are corrected.

さらに、ソリューションの設計者と管理者は、サイト復元保護を必要とするユーザー セットを特定し、複数サイト ソリューションをアクティブ/パッシブ構成にするか、またはアクティブ/アクティブ構成にするかも決定します。アクティブ/パッシブ構成では、通常スタンバイ データセンター内でユーザーはホストされません。アクティブ/アクティブ構成では、ユーザーは両方の場所でホストされ、ソリューション内のデータベース総数のうちの一定の割合に、第 2 データセンターで優先度の高いアクティブな場所が割り当てられます。1 つのデータセンターのユーザー向けのサービスに障害が発生すると、これらのユーザーは他のデータセンターでアクティブ化されます。The solution's architects and administrators will also identify which set of users require site resilience protection, and determine if the multiple site solution will be an active/passive or active/active configuration. In an active/passive configuration, no users are normally hosted in the standby datacenter. In an active/active configuration, users are hosted in both locations, and some percentage of the total number of databases within the solution has a preferred active location in a second datacenter. When service for the users of one datacenter fails, those users are activated in the other datacenter.

多くの場合、適切な SLA を作成するには次の基本的な質問に答える必要があります。Constructing the appropriate SLAs often requires answering the following basic questions:

  • プライマリ データセンターの障害発生後に、どのようなレベルのサービスが必要か。What level of service is required after the primary datacenter fails?

  • ユーザーにはデータが必要であるか、またはメッセージング サービスだけが必要か。Do users need their data or just messaging services?

  • データはどれだけ迅速に必要とされるか。How rapidly is data required?

  • 何人のユーザーをサポートする必要があるか。How many users must be supported?

  • ユーザーは自分のデータにどのようにアクセスするか。How will users access their data?

  • どのような SLA でスタンバイ データセンターをアクティブ化するか。What is the standby datacenter activation SLA?

  • どのようにしてプライマリ データセンターにサービスを戻すか。How is service moved back to the primary datacenter?

  • リソースはサイトの復元ソリューション専用であるか。Are the resources dedicated to the site resilience solution?

これらの問題に回答することで、メッセージング ソリューションのためのサイトの復元設計の具体化を開始します。サイト障害からの回復の中心的な要件は、バックアップ メッセージング サービスをホストするバックアップ データセンターに、必要なデータを届けるソリューションを作成することです。By answering these questions, you begin to shape a site resilient design for your messaging solution. A core requirement of recovery from site failure is to create a solution that gets the necessary data to the backup datacenter that hosts the backup messaging service.

証明書の計画Certificate planning

単一のデータセンター内で DAG を展開する場合、証明書の設計に関する考慮事項は特にありません。ただし、サイトの復元構成の複数のデータセンター間に DAG がまたがる場合は、証明書に関する特定の考慮事項がいくつかあります。一般に、証明書設計は、使用するクライアントと、証明書を使用する他のアプリケーションによる証明書要件によって左右されます。ただし、証明書の種類や数について準拠すべき特定の推奨事項とベスト プラクティスがいくつかあります。There are no unique or special design considerations for certificates when deploying a DAG in a single datacenter. However, when extending a DAG across multiple datacenters in a site resilient configuration, there are some specific considerations with respect to certificates. Generally, your certificate design will depend on the clients in use, as well as the certificate requirements by other applications that use certificates. But there are some specific recommendations and best practices you should follow with respect to the type and number of certificates.

ベスト プラクティスとして、Exchange サーバーとリバース プロキシ サーバーに使用する証明書の数は最小限に抑えてください。各データセンター内のこれらのサービス エンドポイントすべてに対して単一の証明書を使用することをお勧めします。このアプローチにより、必要な証明書の数が最小限に抑えられ、ソリューションのコストと複雑性の両方が削減されます。As a best practice, you should minimize the number of certificates you use for your Exchange servers and reverse proxy servers. We recommend using a single certificate for all of these service endpoints in each datacenter. This approach minimizes the number of certificates that are needed, which reduces both cost and complexity for the solution.

Outlook Anywhere クライアントの場合、データセンターごとに単一のサブジェクトの別名 (SAN) 証明書を使用し、証明書内に複数のホスト名を含めることをお勧めします。データベース、サーバー、またはデータセンターの切り替え後に Outlook Anywhere の接続が確実に行われるようにするには、各証明書で同じ証明書のプリンシパル名を使用し、Microsoft の標準フォーム (msstd) の同じプリンシパル名で Active Directory の Outlook プロバイダー構成オブジェクトを構成する必要があります。たとえば、mail.contoso.com の証明書のプリンシパル名を使用する場合、次のように属性を構成します。For Outlook Anywhere clients, we recommend that you use a single subject alternative name (SAN) certificate for each datacenter, and include multiple host names in the certificate. To ensure Outlook Anywhere connectivity after a database, server, or datacenter switchover, you must use the same Certificate Principal Name on each certificate, and configure the Outlook Provider Configuration object in Active Directory with the same Principal Name in Microsoft-Standard Form (msstd). For example, if you use a Certificate Principal Name of mail.contoso.com, you would configure the attribute as follows.

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

Exchange と統合するアプリケーションの一部には、追加の証明書の使用を必要とする場合がある特定の証明書要件があります。Some applications that integrate with Exchange have specific certificate requirements that may require using additional certificates. Exchange 2013 は、Office Communications Server (OCS) と共存していることができます。Exchange 2013 can co-exist with Office Communications Server (OCS). OCS には、証明書のプリンシパル名に OCS サーバー名を使用する 1024 ビット以上の証明書を含めた証明書が必要です。OCS requires certificates with 1024-bit or greater certificates that use the OCS server name for the Certificate Principal Name. 証明書のプリンシパル名に OCS サーバー名を使用すると、Outlook Anywhere が正しく機能しなくなるので、OCS 環境に対応した別の証明書をさらに使用する必要があります。Because using an OCS server name for the Certificate Principal Name would prevent Outlook Anywhere from working properly, you would need to use an additional and separate certificate for the OCS environment.

ネットワークの計画Network planning

各 DAG、および DAG のメンバーである各サーバーで満たす必要があるネットワーキング要件のほかに、サイトの復元構成固有の要件と推奨事項がいくつかあります。すべての DAG と同様に、DAG メンバーが単一サイトまたは複数のサイトのどちらに展開されるとしても、DAG メンバー間のラウンドトリップ リターン ネットワーク待ち時間は 500 ミリ秒未満にする必要があります。さらに、複数のサイトにまたがる DAG について推奨する次のような特定の構成設定があります。In addition to the specific networking requirements that must be met for each DAG, as well as for each server that's a member of a DAG, there are some requirements and recommendations that are specific to site resilience configurations. As with all DAGs, whether the DAG members are deployed in a single site or in multiple sites, the round-trip return network latency between DAG members must be no greater than 500 milliseconds. In addition, there are specific configuration settings that are recommended for DAGs that are extended across multiple sites:

  • Mapi ネットワークは、レプリケーションネットワークから分離する必要があります。 windows ネットワークポリシー、windows ファイアウォールポリシー、またはルーターアクセス制御リスト (acl) を使用して、mapi ネットワークとレプリケーションネットワークの間のトラフィックをブロックする必要があります。MAPI networks should be isolated from Replication networks: Windows network policies, Windows firewall policies, or router access control lists (ACLs) should be used to block traffic between the MAPI network and the Replication networks. この構成は、ネットワーク ハートビートの漏話を防止するために必要になります。This configuration is necessary to prevent network heartbeat cross talk.

  • クライアントに直接接続している DNS レコードは、Time To Live (TTL) の値を5分にする必要があります。クライアントで発生するダウンタイムは、スイッチオーバーが発生する速度だけでなく、DNS レプリケーションの実行速度や、クライアントからのクエリの数によっても異なります。DNS 情報を更新しました。Client-facing DNS records should have a Time to Live (TTL) value of 5 minutes: The amount of downtime that clients experience is dependent not just on how quickly a switchover can occur, but also on how quickly DNS replication occurs and the clients query for updated DNS information. Outlook Web App、Exchange ActiveSync、Exchange Web サービス、Outlook Anywhere、SMTP、POP3、IMAP4 を含むすべての Exchange クライアントサービスの DNS レコードは、内部および外部の両方の DNS サーバーで、TTL が5分に設定されている必要があります。DNS records for all Exchange client services, including Outlook Web App, Exchange ActiveSync, Exchange Web services, Outlook Anywhere, SMTP, POP3, and IMAP4 in both the internal and external DNS servers should be set with a TTL of 5 minutes.

  • 静的ルートを使用して、レプリケーションネットワーク間の接続を構成します。各レプリケーションネットワークアダプター間にネットワーク接続を提供するには、固定の静的ルートを使用します。Use static routes to configure connectivity across Replication networks: To provide network connectivity between each of the Replication network adapters, use persistent static routes. これは、静的な IP アドレスを使用するときに各 DAG メンバーで実行される迅速で 1 回限りの構成です。This is a quick and one-time configuration that's performed on each DAG member when using static IP addresses. レプリケーション ネットワークの IP アドレスを取得するために DHCP を使用する場合、DHCP を使用してレプリケーションの静的なルートを割り当てることが可能で、これにより構成プロセスを簡略化することができます。If you're using DHCP to obtain IP addresses for your Replication networks, you can also use it to assign static routes for the replication, thereby simplifying the configuration process.

一般的なサイト復元計画General site resilience planning

高可用性を実現するために上記の要件に加えて、Exchange 2013 をサイトの復元可能な構成に展開する際には、他にも推奨事項があります (たとえば、複数のデータセンターにまたがる DAG の拡張)。In addition to the requirements listed above for high availability, there are other recommendations for deploying Exchange 2013 in a site resilient configuration (for example, extending a DAG across multiple datacenters). 計画段階で実行する内容がサイトの復元ソリューションの成功に直接影響することになります。What you do during the planning phase will directly affect the success of your site resilience solution. たとえば、名前空間の設計が適切でないと、証明書上に問題が発生する可能性があったり、また証明書の構成が正しくないと、ユーザーがサービスにアクセスできなかったりする場合があります。For example, poor namespace design can cause difficulties with certificates, and an incorrect certificate configuration can prevent users from accessing services.

第 2 データセンターをアクティブ化するためにかかる時間を最小限に抑え、障害が発生したデータセンターのサービス エンドポイントを第 2 データセンターがホストできるようにするには、適切な計画を立案する必要があります。次に、例を示します。To minimize the time it takes to activate a second datacenter, and allow the second datacenter to host the service endpoints of a failed datacenter, the appropriate planning must be completed. The following are examples:

  • サイトの復元ソリューションの SLA の目的を十分に理解し、ドキュメント化する必要があります。The SLA goals for the site resilience solution must be well understood and documented.

  • 第 2 データセンター内のサーバーには、2 つのデータセンター内の合計ユーザー人口をホストするのに十分な容量を確保する必要があります。The servers in the second datacenter must have sufficient capacity to host the combined user population of both datacenters.

  • 第 2 データセンターでは、プライマリ データセンターで提供されるすべてのサービスを有効にする必要があります (ただし、サイトの復元 SLA の中にそのサービスが含まれていない場合は除きます)。このようなサービスには、Active Directory、ネットワーキング インフラストラクチャ (DNS や TCP/IP など)、テレフォニー サービス (ユニファイド メッセージングを使用している場合)、サイトのインフラストラクチャ (電力や冷却など) があります。The second datacenter must have all services enabled that are provided in the primary datacenter (unless the service isn't included as part of the site resilience SLA). This includes Active Directory, networking infrastructure (for example, DNS or TCP/IP), telephony services (if Unified Messaging is in use), and site infrastructure (such as power or cooling).

  • 一部のサービスでは障害が発生したデータセンターのユーザーにサービスを提供できるようにするために、ユーザーが適切なサーバー証明書を構成する必要があります。サービスによってはインスタンス化が許可されず (POP3 や IMAP4 など)、単一の証明書の使用のみが許可されるものがあります。このような場合、証明書を、複数の名前を含めた SAN 証明書にするか、複数の名前に、ワイルドカード証明書を使用できるような類似名を付ける必要があります (ただし、組織のセキュリティ ポリシーによってワイルドカード証明書の使用が許可されていなければなりません)。For some services to be able to service users from the failed datacenter, they must have the proper server certificates configured. Some services don't allow instancing (for example, POP3 and IMAP4) and only allow the use of a single certificate. In these cases, either the certificate must be a SAN certificate that includes multiple names, or the multiple names must be similar enough so that a wildcard certificate can be used (assuming the security policies of the organization allows the use of wildcard certificates).

  • 第 2 データセンター内に必要なサービスを定義する必要があります。The necessary services must be defined in the second datacenter. たとえば、最初のデータセンターに異なるトランスポートサーバー上の3つの異なる SMTP 送信先がある場合は、2番目のデータセンターで、ワークロードをホストするために少なくとも1つのトランスポートサーバーを有効にするように、適切な構成を定義する必要があります。For example, if the first datacenter has three different SMTP destinations on different transport servers, the appropriate configuration must be defined in the second datacenter to enable at least one (if not all three) transport server to host the workload.

  • データセンターの切り替えをサポートするために必要なネットワーク構成を正しく設定する必要があります。これは、たとえば、負荷分散の構成を正しく設定し、グローバル DNS を構成し、さらに適切なルーティングを構成してインターネット接続を有効にしていることを意味します。The necessary network configuration must be in place to support the datacenter switchover. This might mean making sure that the load balancing configurations are in place, that global DNS is configured, and that the Internet connection is enabled with the appropriate routing configured.

  • データセンターの切り替えに必要な DNS 変更を有効にする戦略を理解する必要があります。TTL 設定などの特定の DNS 変更は、SLA で効力を持たせるために既定し、ドキュメント化する必要があります。The strategy for enabling the DNS changes necessary for a datacenter switchover must be understood. The specific DNS changes, including their TTL settings, must be defined and documented to support the SLA in effect.

  • ソリューションをテストする戦略を立案して、SLA に盛り込むことも必要です。時間の経過に伴って展開の質と実行可能性が低下することがないようにするには、定期的に展開を検証することが唯一の方法です。展開の検証後には、ソリューションの成功に直接影響する構成部分を明示的にドキュメント化する必要があります。さらに、展開のこれらのセグメント前後の変更管理プロセスを強化することをお勧めします。A strategy for testing the solution must also be established and factored into the SLA. Periodic validation of the deployment is the only way to guarantee that the quality and viability of the deployment doesn't degrade over time. After the deployment is validated, we recommend that the part of the configuration that directly affects the success of the solution be explicitly documented. In addition, we recommend that you enhance your change management processes around those segments of the deployment.