规划高可用性和站点复原能力

在规划阶段，系统结构设计师、管理员和其他主要利益相关方应确定部署的业务要求和体系结构要求；尤其是高可用性和站点恢复的要求。

部署这些功能必须满足一些常规要求，还必须满足硬件、软件和网络连接要求。

常规要求

在部署数据库可用性组 (DAG) 和创建邮箱数据库副本之前，请确保符合以下系统范围建议：

• 域名系统 (DNS) 必须在运行。 理论上，DNS 服务器应该接受动态更新。 如果 DNS 服务器不接受动态更新，则必须为每个 Exchange 服务器创建 DNS 主机 (A) 记录。 否则，Exchange 不能正常运行。

• DAG 中的每个邮箱服务器必须是相同域中的成员服务器。

• 不支持将同样是目录服务器的 Exchange 邮箱服务器添加到 DAG。

• 分配给 DAG 的名称必须是不超过 15 个字符的有效、可用和唯一的计算机名称。

硬件要求

通常，DAG 或邮箱数据库副本没有特定的特殊硬件要求。 使用的服务器必须满足Exchange Server先决条件中所述的所有要求。

存储要求

通常，没有特定于 DAG 或邮箱数据库副本的特殊存储要求。 DAG 不需要也不使用群集托管共享存储。 仅当 DAG 配置为使用利用内置于 Exchange Server 中的第三方复制 API 的解决方案时，才支持在 DAG 中使用群集管理的共享存储。

软件要求

DAG 的每个成员都必须运行相同的操作系统。 Windows Server 2012、Windows Server 2012 R2 和 Windows Server 2016 支持 Exchange Server 2016。 Windows Server 2019 和 Windows Server 2022 操作系统支持 Exchange Server 2019。 在特定的 DAG 中，所有成员都必须运行受支持的相同操作系统。

除了满足安装Exchange Server的先决条件外，还必须满足操作系统要求。 DAG 使用 Windows 故障转移群集技术，因此，它们需要标准版或数据中心版Windows Server 2012、Windows Server 2012 R2、Windows Server 2016、Windows Server 2019 或 Windows Server 2022 操作系统。

网络要求

每个 DAG 和每个 DAG 成员都必须符合特定的网络要求。 每个 DAG 必须有一个 MAPI 网络，DAG 成员使用该网络与其他服务器通信 (例如，其他 Exchange 服务器或目录服务器) ，以及零个或多个 复制网络，这些网络是专用于日志传送和种子设定的网络。

在 Exchange 的以前版本中，我们建议对 DAG 至少使用两个网络（一个 MAPI 网络和一个复制网络）。 在 Exchange 2016 和 Exchange 2019 中，支持多个网络，但我们的建议取决于物理网络拓扑。 如果 DAG 成员之间的多个物理网络在物理上彼此分开，那么使用分开的 MAPI 网络和复制网络将能提供额外的冗余。 如果多个网络在物理上部分分开，但合并成一个物理网络（例如，单个 WAN 链路），那么建议对 MAPI 和复制流量使用单个网络（最好是 10 千兆以太网）。 这样可以简化网络和网络路径。

为 DAG 设计网络基础结构时，请考虑下列事项：

• DAG 的每个成员必须具有至少一个能够与所有其他 DAG 成员通信的网络适配器。 如果您使用的是单个网络路径，我们建议您使用最少 1 千兆的以太网，最好是 10 千兆的以太网。 此外，在每个 DAG 成员中使用单一网络适配器时，我们建议在设计总体解决方案时考虑单一网络适配器和路径。

• 在每个 DAG 成员中使用两个网络适配器可提供一个 MAPI 网络和一个复制网络，以及复制网络冗余和以下恢复行为：

  • 如果故障影响 MAPI 网络，将发生服务器故障转移（假定可以激活健康的邮箱数据库副本）。

  • 如果故障影响复制网络，如果 MAPI 网络不受故障影响，则日志传送和种子设定操作将还原为使用 MAPI 网络，即使 MAPI 网络将其 ReplicationEnabled 属性设置为 False 也是如此。 当发生故障的复制网络恢复正常并准备好时恢复日志传送和种子设定操作时，必须手动切换到复制网络。 若要将复制从 MAPI 网络更改为还原后的复制网络，可以使用 Suspend-MailboxDatabaseCopy 和 Resume-MailboxDatabaseCopy cmdlet 暂停和恢复连续复制，也可以重新启动 Microsoft Exchange 复制服务。 建议使用暂停和恢复操作以避免因重新启动 Microsoft Exchange 复制服务而导致的短时间中断。

• 每个 DAG 成员都必须具有相同数量的网络。 例如，如果计划在一个 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 毫秒。 随着承载数据库副本的两个邮箱服务器之间的往返延迟增加，未更新复制的可能性也会增加。 无论解决方案的延迟如何，客户都应验证所有 DAG 成员之间的网络是否能够满足部署的数据保护和可用性目标。 具有较高延迟值的配置可能需要对 DAG、复制和网络参数进行特殊调整（如增加数据库数或减少每个数据库的邮箱数），才能实现所需目标。

• 对于多数据中心配置，往返延迟要求可能不是最严格的网络带宽和延迟要求。 必须评估网络总负载（其中包括客户端访问、Active Directory、传输、连续复制和其他应用程序通信）以确定您的环境所需的网络要求。

• DAG 网络支持 Internet 协议版本 4 (IPv4) 和 IPv6。 仅当同时使用 IPv4 时才支持 IPv6；不支持纯 IPv6 环境。 仅当在计算机上同时启用 IPv6 和 IPv4，并且网络支持这两种 IP 地址版本时，才支持使用 IPv6 地址和 IP 地址范围。 如果在此配置中部署了Exchange Server，则所有服务器角色都可以向使用 IPv6 地址的设备、服务器和客户端发送数据以及接收数据。

• 自动专用 IP 寻址 (APIPA) 是 Windows 的一种功能，当网络上没有任何动态主机配置协议 (DHCP) 服务器可用时，它将自动分配 IP 地址。 APIPA 地址 (包括 APIPA 地址范围中的手动分配地址) 不支持由 DAG 或Exchange Server使用。

DAG 名称和 IP 地址要求

在创建过程中，会为每个 DAG 指定一个唯一名称，并分配一个或多个静态 IP 地址，或配置为使用 DHCP。 不论使用静态地址还是动态分配的地址，分配给 DAG 的任何 IP 地址必须在 MAPI 网络上。

在 Windows Server 2012 上运行的每个 DAG 都需要 MAPI 网络上的至少一个 IP 地址。 当 MAPI 网络跨多个子网扩展时，DAG 需要其他 IP 地址。 在没有群集管理访问点的情况下创建的 Windows Server 2012 R2、Windows Server 2016、Windows Server 2019 或 Windows Server 2022 上运行的 DAG 不需要 IP 地址。

下图说明了 DAG，其中 DAG 中的所有节点在相同子网上都具有 MAPI 网络。

MAPI 网络位于相同子网上的 DAG

在此示例中，每个 DAG 成员中的 MAPI 网络都位于 172.19.18 . x 子网上。 因此，DAG 在该子网上需要具备单一 IP 地址。

下图显示的 DAG 具有跨以下两个子网扩展的 MAPI 网络：172.19.18. x 和 172.19.19. x。

MAPI 网络位于多个子网上的 DAG

在此示例中，每个 DAG 成员中的 MAPI 网络都位于单独的子网上。 因此，DAG 需要两个 IP 地址，MAPI 网络上每个子网有一个地址。

DAG 的 MAPI 网络每次跨其他子网扩展时，必须为 DAG 配置该子网的其他 IP 地址。 为 DAG 配置的每个 IP 地址被分配到 DAG 的基础故障转移群集，并由该群集使用。 DAG 的名称也用作基础故障转移群集的名称。

在任何特定时间，DAG 的群集将仅使用分配的 IP 地址之一。 当群集 IP 地址和网络名称资源进入联机状态时，Windows 故障转移群集会在 DNS 中注册此 IP 地址。 除了使用 IP 地址和网络名称外，在 Active Directory 中还将创建群集名称对象 (CNO)。 系统还将在内部使用群集的名称、IP 地址和 CNO 来保护 DAG 并进行内部通信。 管理员和最终用户不需要对接或连接 DAG 名称或 IP 地址。

DAG 的网络适配器配置

必须根据预期用途正确配置每个网络适配器。 用于 MAPI 网络和复制网络的网络适配器的配置并不相同。 除正确配置每个网络适配器外，还必须在 Windows 中配置网络连接顺序，以便 MAPI 网络在连接顺序中排首位。 若要详细了解如何修改网络连接顺序，请参阅修改协议绑定和网络提供商顺序。

MAPI 网络适配器配置

应按照下表中的描述配置供 MAPI 网络使用的网络适配器。

MAPI 网络适配器的 TCP/IP v4 属性配置如下：

• 可以手动分配 DAG 成员的 MAPI 网络的 IP 地址，或将其配置为使用 DHCP。 如果使用 DHCP，我们建议对服务器的 IP 地址使用永久保留。

• MAPI 网络通常使用默认网关，尽管不需要网关。

• 必须配置至少一个 DNS 服务器地址。 为实现冗余，建议使用多个 DNS 服务器。

• 应选中“在 DNS 中注册此连接地址”复选框。

复制网络适配器配置

应按照下表中的描述配置供复制网络使用的网络适配器。

复制网络适配器的 TCP/IP v4 属性配置如下：

• 可以手动分配 DAG 成员的复制网络的 IP 地址，或将其配置为使用 DHCP。 如果使用 DHCP，我们建议对服务器的 IP 地址使用永久保留。

• 复制网络通常没有默认网关，如果 MAPI 网络有默认网关，则其他网络不应有默认网关。 可以使用持久的静态路由配置复制网络上的网络通信路由，将网络通信路由到使用网关地址的其他 DAG 成员上的相应网络，该网关地址具有在复制网络之间路由的能力。 与此路由不匹配的所有其他通信都将由在 MAPI 网络的适配器上配置的默认网关处理。

• 不应配置 DNS 服务器地址。

• The Register this connection's addresses in DNS check box shouldn't be selected.

见证服务器要求

“见证服务器”是 DAG 外部的服务器，当 DAG 的成员数为偶数时，使用该服务器可实现和维护仲裁。 DAG 的成员数为奇数时，则不使用见证服务器。 成员为偶数的所有 DAG 必须使用见证服务器。 见证服务器可以是运行 Windows Server 的任何计算机。 不要求见证服务器的 Windows Server 操作系统版本与 DAG 成员使用的操作系统匹配。

仲裁在 DAG 下的群集级别维护。 当 DAG 的大多数成员处于联机状态，并且可以与 DAG 的其他联机成员通信时，DAG 才进行仲裁。 此仲裁概念是 Windows 故障转移群集中仲裁概念的一个方面。 在故障转移群集中与仲裁相关的必需方面是“仲裁资源”。 仲裁资源是故障转移群集内部的资源，它可为导致群集状态和成员身份决策提供一种仲裁方法。 仲裁资源还为存储配置信息提供了永久存储区。 仲裁资源的配套组件是“仲裁日志”，它是群集的配置数据库。 仲裁日志包含以下信息：哪些服务器是群集的成员，群集中安装了哪些资源，以及这些资源的状态（例如，联机或脱机）。

每个 DAG 成员对如何配置 DAG 基础群集应具有一致看法，这一点至关重要。 仲裁充当了与群集相关的所有配置信息的权威性存储库。 仲裁还用作关系断开裁判，以避免“网络分区”症状。 网络分区症状是在 DAG 成员无法相互通信（但是在运行）时发生的一种情况。 始终要求大多数 DAG 成员（在 DAG 成员为偶数时使用 DAG 见证服务器）可用并处于交互状态，使 DAG 能够正常工作，这样即可防止网络分区症状。

规划站点恢复

越来越多的业务人员认识到，每天访问可靠而又可用的邮件系统是其成功的基础。 对于许多组织而言，邮件系统是业务连续性计划的一部分，并且在设计邮件服务部署时应考虑站点恢复。 基本上，许多站点恢复解决方案都涉及在第二个数据中心中部署硬件。

最终，DAG 的总体设计（其中包括 DAG 的成员数和邮箱数据库副本数）将取决于每个组织的包括各种故障情形的恢复服务级别协议 (SLA)。 在规划阶段中，解决方案的结构设计师和管理员将确定部署要求，尤其是站点恢复要求。 他们确定要使用的位置和所需的恢复 SLA 目标。 SLA 将确定两个特定的元素，这两个元素应是设计高可用性和站点恢复解决方案的基础：恢复时间目标和恢复点目标。 这两个值都以分钟为单位度量。 恢复时间目标是指恢复服务所需的时间。 恢复点目标指在完成恢复操作之后数据的新旧程度。 还可以将 SLA 定义为在解决主数据中心的问题之后，将还原为完整服务。

解决方案的结构设计师和管理员还将确定哪一组用户需要站点恢复保护，并确定多网站解决方案是主动/被动配置还是主动/主动配置。 在主动/被动配置中，备用数据中心中通常不驻留任何用户。 在主动/主动配置中，用户同时驻留在两个位置，在该解决方案中，数据库总数中有一定的百分比在第二个数据中心的首选活动位置。 当一个数据中心的用户的服务出现故障时，将在另一数据中心中激活这些用户。

构造适当的 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 需要 1024 位或更高版本的证书，这些证书使用 OCS 服务器名称作为证书主体名称。 因为将 OCS 服务器名称用作证书主体名称会阻止 Outlook Anywhere 正常工作，所以需要在 OCS 环境中使用其他单独证书。

网络规划

除了必须满足每个 DAG 和属于 DAG 成员的每个服务器的特定网络要求外，还有一些特定于站点恢复配置的要求和建议。 与所有 DAG 一样，无论 DAG 成员部署在单个网站还是多个网站，DAG 成员之间的往返返回网络延迟均不得大于 500 毫秒。 此外，对于跨多个站点扩展的 DAG 还有一些特定的配置设置建议：

• MAPI 网络应与复制网络隔离：Windows 网络策略、Windows 防火墙策略或路由器访问控制列表 (ACL) 应用于阻止 MAPI 网络与复制网络之间的流量。 此配置是防止网络检测信号交叉对话所必需的。

• 面向客户端的 DNS 记录的生存时间 (TTL) 值为 5 分钟：客户端经历的停机时间不仅取决于切换的速度，还取决于 DNS 复制发生的速度以及客户端查询更新的 DNS 信息的速度。 内部和外部 DNS 服务器中的所有 Exchange 客户端服务的 DNS 记录（包括 Outlook 网页版 (以前称为 Outlook Web App) 、Exchange ActiveSync、Exchange Web Services、Outlook Anywhere、SMTP、POP3 和 IMAP4）的 DNS 记录应设置为 5 分钟。

• 使用静态路由配置跨复制网络的连接：若要在每个复制网络适配器之间提供网络连接，请使用永久性静态路由。 使用静态 IP 地址时，这是对每个 DAG 成员执行的一次性快速配置。 如果在使用 DHCP 为复制网络获取 IP 地址，则还可以使用它为复制分配静态路由，从而简化配置过程。

常规站点恢复规划

除了上面列出的高可用性要求外，还有一些其他建议用于在站点复原配置中部署Exchange Server (，例如，) 跨多个数据中心扩展 DAG。 在计划阶段中，哪些问题会直接影响站点恢复解决方案的成功。 例如，糟糕的命名空间设计可以导致证书出现问题，不正确的证书配置可能阻止用户访问服务。

为了尽可能缩短激活第二个数据中心所需的时间，并允许第二个数据中心托管故障数据中心的服务终结点，必须完成适当的规划。 示例如下：

• 必须充分理解和记录网站恢复解决方案的 SLA 目标。

• 第二个数据中心中的服务器必须具有足够的容量，以便承载两个数据中心的组合用户群。

• 第二个数据中心必须启用在主数据中心中提供的所有服务（除非这些服务未作为网站恢复 SLA 的一部分包括在内）。 这包括 Active Directory、网络基础结构 (例如 DNS 或 TCP/IP) 、电话服务 (（如果 Exchange 2016 中的统一消息正在使用) ）以及站点基础结构 (（例如电源或冷却) ）。

• 为使某些服务能够服务于发生故障的数据中心中的用户，必须为这些服务配置正确的服务器证书。 有些服务不允许实例化（例如，POP3 和 IMAP4），只允许使用单一证书。 在这些情况下，证书要么必须是一个包括多个名称的 SAN 证书，要么必须是非常相似的多个名称，以便能够使用通配符证书（假定组织的安全策略允许使用通配符证书）。

• 在第二个数据中心中必须定义必要的服务。 例如，如果第一个数据中心在不同的传输服务器上有三个不同的 SMTP URL，那么必须在第二个数据中心中定义合适的配置，使至少一个（如果不是全部三个）传输服务器承载工作负荷。

• 要支持数据中心切换，必须已配置了必要的网络。 这可能意味着，确保配置了负载平衡，配置了全局 DNS，并且启用了配置适当路由的 Internet 连接。

• 必须了解支持数据中心切换所需的 DNS 更改策略。 必须定义和记录特定的 DNS 更改（包括其 TTL 设置），才能支持有效的 SLA。

• 还必须建立测试解决方案的策略，并将其包括在 SLA 中。 定期验证部署是保证部署的质量和实用性不随时间的推移而降级的唯一方式。 在验证部署之后，我们建议明确记录直接影响解决方案成功的配置部分。 此外，还建议围绕这些部署部分加强更改管理过程。