通过

Exchange 2019 首选体系结构

  • 项目

对于每个面向本地客户的Exchange Server新版本，我们都会更新首选体系结构，并讨论我们希望客户了解哪些更改。 Exchange Server 2013 为我们带来了现代 Exchange 历史上的第一个首选体系结构，然后通过对 2016 年版本附带的更改进行优化，对 2016 Exchange Server进行了更新。 通过 2019 Exchange Server的此更新，我们将循环访问以前的 PA，以利用新技术和改进。

首选体系结构

PA 是Exchange Server工程团队的最佳做法建议，我们认为这是 2019 Exchange Server 2019 在本地环境中的最佳部署体系结构。

虽然 Exchange 2019 为本地部署提供了各种体系结构选择，但此处讨论的体系结构是最仔细的体系结构。 虽然还有其他受支持的部署体系结构，但不建议这样做。

遵循 PA 可帮助客户成为具有类似Exchange Server部署的组织社区的成员。 此策略可简化知识共享，并针对不可预见的情况提供更快速的响应。 我们自己的支持组织知道Exchange Server PA 部署应该是什么样子，并阻止他们在与客户合作解决支持案例之前花费长时间的学习和理解客户的自定义环境。

PA 在设计时考虑了几个业务要求，例如体系结构能够：

  • 包括数据中心内的高可用性和数据中心之间的站点复原能力

  • 支持每个数据库的多个副本，从而允许快速激活

  • 降低消息传递基础结构的成本

  • 通过围绕故障域进行优化并降低复杂性来提高可用性

PA 的特定规范性意味着不是每个客户都能逐字部署它。 例如，并非所有客户都有多个数据中心。 我们的某些客户可能有不同的业务要求或内部策略，他们必须遵守这些要求或内部策略，这需要不同的部署体系结构。 如果属于这些类别，并且想要在本地部署 Exchange，则尽可能遵守 PA 并仅在要求或策略迫使你有所不同的情况下，仍有一些好处。 或者，你始终可以考虑 Microsoft 365 或 Office 365，不再需要部署或管理大量服务器。

如果有必要，PA 会消除复杂性和冗余，以将体系结构驱动为可预测的恢复模式：发生故障时，将激活受影响数据库的另一个副本。

PA 涵盖以下四个重点领域：

  1. 命名空间设计

  2. 站点弹性数据中心对设计

  3. 服务器设计

  4. 数据库可用性组设计

对于 2019 Exchange Server，Exchange Server 2016 首选体系结构的四个类别中的三个没有变化。 命名空间设计、数据中心设计和 DAG 设计领域没有收到重大更改。 我们对紧跟Exchange Server 2016 PA 的客户部署非常满意，并认为没有必要偏离这些领域的建议。

Exchange Server 2019 PA 中最值得注意的变化集中在服务器设计领域，因为一些新的和令人兴奋的技术。

命名空间设计

在 2016 Exchange Server 命名空间规划和负载均衡原则文章中，Ross Smith IV 概述了 Exchange 2016 中提供的各种配置选项，这些概念继续适用于 2019 Exchange Server。 对于命名空间，选择是部署 绑定命名空间 (让用户优先使用特定数据中心) ，或者 (让用户在没有首选项) 的情况下连接到任何数据中心的 未绑定命名空间 。

建议的方法是使用无限模型，为每个客户端协议部署一个 Exchange 命名空间，用于站点复原数据中心对 (其中假定每个数据中心都表示其自己的 Active Directory 站点 - 请参阅下面) 的更多详细信息。 例如：

  • 对于自动发现服务：autodiscover.contoso.com

  • 对于 HTTP 客户端：mail.contoso.com

  • 对于 IMAP 客户端：imap.contoso.com

  • 对于 SMTP 客户端：smtp.contoso.com

每个 Exchange 命名空间在不使用会话相关性的第 7 层配置中跨两个数据中心进行负载均衡，导致数据中心之间代理 50% 的流量。 流量通过轮循机制 DNS、异地 DNS 或其他类似解决方案在站点弹性对中的数据中心平均分布。 从我们的角度来看，更简单的解决方案最不复杂且更易于管理，因此建议使用轮循机制 DNS。

我们为客户提供的一个警告是，确保为与 Exchange 体系结构关联的任何 DNS 记录分配较低的 TTL (生存时间，) 值。 如果使用轮循机制 DNS 时发生数据中心完全中断，则必须保持快速更新 DNS 记录的能力。 需要从脱机数据中心中删除 IP 地址，以便 DNS 查询不会返回这些地址。 例如，如果 DNS 记录的 TTL 值较长为 24 小时，则下游 DNS 缓存可能需要长达一天的时间才能正确更新。 如果不执行此步骤，可能会发现某些客户端无法正确转换为剩余数据中心内仍可用的 IP 地址。 在恢复之前脱机的数据中心并准备好再次承载服务时，不要忘记将 IP 地址添加回 DNS 记录。

Office Online Server场需要数据中心相关性，因此每个数据中心部署一个命名空间，负载均衡器利用第 7 层，并通过基于 Cookie 的持久性来维护会话相关性。

示例 Exchange 2019 组织体系结构布局。

如果环境中有多个站点可复原的数据中心对，则需要确定是要具有单个全球命名空间，还是要使用区域命名空间来控制发向每个特定数据中心的流量。 你的决策取决于网络拓扑和使用未绑定模型的相关成本;例如，如果你的数据中心位于 北美 和南非，则这些区域之间的网络链接可能不仅成本高昂，而且还可能具有高延迟，这可能会导致用户痛苦和操作问题。 在这种情况下，为每个区域部署具有单独命名空间的绑定模型是有意义的。 但是，地理 DNS 等选项使你能够部署单个统一命名空间，即使网络链接成本高昂;geo-DNS 允许用户根据客户端的 IP 地址将用户定向到最近的数据中心。

站点弹性数据中心对设计

若要实现高度可用 且 站点可复原的体系结构，必须具有两个或更多个连接良好的数据中心， (理想情况下，需要较低的往返网络延迟，否则复制和客户端体验将受到) 的不利影响。 此外，数据中心应通过不同运营运营商提供的冗余网络路径进行连接。

虽然我们支持跨多个数据中心扩展 Active Directory 站点，但对于 PA，我们建议每个数据中心都是其自己的 Active Directory 站点。 有两个原因：

  1. 仅当 DAG 的成员位于多个 Active Directory 站点中时，才能通过 Exchange Server 中的影子冗余和Exchange Server中的安全网实现传输站点复原能力。

  2. Active Directory 已发布指南 ，指出当子网之间的往返延迟大于 10 毫秒时，子网应放置在不同的 Active Directory 站点中。

服务器设计

在 PA 中，所有服务器都是物理服务器，并使用本地附加存储。 出于两个原因，部署物理硬件而不是虚拟化硬件：

  1. 服务器会进行缩放，以在最差故障模式下使用 80% 的资源。

  2. 虚拟化会带来轻微的性能损失，并增加了额外的管理和复杂性层，这引入了其他不会增加价值的恢复模式，特别是因为Exchange Server本身提供了相同的功能。

商品服务器

PA 中使用了商品服务器平台。 当前商品平台包括：

  • 具有最多 48 个物理处理器核心的 2U 双套接字服务器 (Exchange 2016 中的 24 个核心)

  • 最多 256 GB 的内存 (Exchange 2016 中的 192 GB)

  • 电池备份的写入缓存控制器

  • 服务器机箱中的 12 个或更多驱动器托架

  • 能够在同一机箱中混合使用传统的旋转盘片存储 (HDD) 和固态存储 (SSD) 。

缩放理论

请务必注意，尽管我们在 2019 Exchange Server增加了允许的处理器和内存容量，Exchange Server PG 的建议仍然是横向扩展而不是纵向扩展。 横向扩展与纵向扩展意味着我们更希望你部署更多服务器，每个服务器的资源略少，而不是使用最大资源并使用大量邮箱填充的少量密集服务器。 通过在服务器中查找合理数量的邮箱，可以减轻任何计划内或计划外中断的影响，并降低发现其他系统瓶颈的风险。

系统资源增加不应导致假设在 2019 Exchange Server使用允许的最大资源与 Exchange 2016 允许的最大资源进行比较时，会出现线性性能提升。 每个新版本的 Exchange 都会引入新的流程和更新，这反过来又使得将当前版本与以前的版本进行比较变得困难。 在确定服务器设计时，请遵循 Microsoft 提供的所有大小调整指南。

存储器

根据邮箱数量、邮箱大小和服务器的资源可伸缩性，可以为每个服务器直接附加其他驱动器托架。

每个服务器包含一个 RAID1 磁盘对，用于操作系统、Exchange 二进制文件、协议/客户端日志和传输数据库。

其余存储配置为 JBOD (仅一堆磁盘) 。 请注意，某些硬件存储控制器可能需要将每个磁盘配置为单磁盘 RAID0 组，以便利用写入缓存。 请咨询硬件制造商，确认系统的正确配置，以确保使用写入缓存。

Exchange Server 2019 PA 的新增功能建议为前面提到的 RAID1 磁盘对上尚未找到的所有内容提供两类存储。

传统存储类

此存储类包含Exchange Server数据库文件和Exchange Server事务日志文件。 这些磁盘是大容量 7.2 K RPM 串行附加的 SCSI (SAS) 磁盘。 虽然 SATA 磁盘也可用，但我们使用 SAS 等效项观察到更好的 IO 和更低的年化故障率。

为确保尽可能高效地使用每个磁盘的容量和 IO，每个磁盘最多部署四个数据库副本。 正常的运行时复制布局可确保每个磁盘不超过一个活动数据库副本。

传统存储磁盘池中至少有一个磁盘保留为热备用磁盘。 AutoReseed 已启用，并在磁盘故障后通过激活热备盘和启动数据库复制重排来快速还原数据库冗余。

固态存储类

此存储类包含 Exchange 2019 的新 MetaCache 数据库 (MCDB) 文件。 这些固态硬盘可能采用不同的外形规格，例如但不限于传统的 2.5“/3.5” SAS 连接驱动器或连接 M.2 PCIe 的驱动器。

客户应预期将大约 5-10% 的额外存储部署为固态存储。 例如，如果预计单个服务器在传统存储上保存 28 TB 的邮箱数据库文件，则建议为同一服务器额外添加 1.4-2.8 TB 的固态存储。

应尽可能以 3：1 的比例部署传统磁盘和固态磁盘。 对于服务器中的每三个传统磁盘，将部署一个固态磁盘。 这些固态磁盘将保存三个关联的传统磁盘中所有 DB 的 MCDB。 此建议限制了固态硬盘故障可能对系统施加的故障域。 当 SSD 发生故障时，Exchange 2019 将使用该 SSD 将其 MCDB 的所有数据库副本故障转移到另一个 DAG 节点，其中包含受影响数据库的 MCDB 资源正常。 如果更多数据库共享较少数量的固态硬盘，限制数据库故障转移次数可以减少影响用户的可能性。

如果存在固态硬盘故障 Exchange 高可用性服务，将尝试将受影响的数据库装载到每个受影响数据库仍存在正常 MCDB 的不同 DAG 节点上。 如果由于某种原因，某个受影响的数据库不存在正常的 MCDB，则 Exchange 高可用性服务将使本地受影响的数据库副本保持运行状态，而没有 MCDB 的性能优势。

例如，如果客户部署能够保留 20 个驱动器的系统，则其布局可能如下所示。

  • 2 个 HDD 用于 OS 镜像、Exchange 二进制文件和传输数据库

  • 12 个用于 Exchange 数据库存储的 HDD

  • 1 个 HDD 作为 AutoReseed 备用

  • 用于 Exchange MCDB 的 4 个 SSD，提供 5-10% 的累积数据库存储容量。

  • 客户可以选择添加备用 SSD 或另一个 AutoReseed 驱动器。

可以使用下图可视化此配置：

Exchange 2019 邮箱服务器磁盘布局示例。

在上面的示例中，我们有 120 TB 的 Exchange 数据库存储和 7.68 TB 的 MCDB 存储，大约是传统数据库存储空间的 6.4%。 使用如此数量的 MCBD 存储，我们完全一致地遵循 5-10% 的指导。 每个 10 TB 驱动器将保存 4 个数据库副本，每个 MCDB 驱动器将保存 12 个 MCDB。

常见存储设置

无论是传统磁盘还是固态磁盘，所有包含 Exchange 数据的磁盘都使用 ReFS (格式化，) 禁用完整性功能，并且 DAG 配置为使用 ReFS 设置磁盘格式：

Set-DatabaseAvailabilityGroup -Identity <DAGIdentity> -FileSystem ReFS

BitLocker 用于加密每个磁盘，从而提供静态数据加密，并缓解有关数据被盗或磁盘更换的担忧。 有关详细信息，请参阅 在 Exchange 服务器上启用 BitLocker。

数据库可用性组设计

在每个站点可复原的数据中心对中，你将有一个或多个 DAG。 不建议跨两个以上的数据中心拉伸 DAG。

DAG 配置

与命名空间模型一样，站点可复原数据中心对中的每个 DAG 都在未绑定模型中运行，活动副本均匀分布在 DAG 中的所有服务器中。 此模型：

  1. 确保在正常操作期间验证每个 DAG 成员的完整服务堆栈 (客户端连接、复制管道、传输等) 。

  2. 在发生故障期间，在尽可能多的服务器上分配负载，从而仅增量增加 DAG 中剩余成员的资源使用量。

每个数据中心都是对称的，每个数据中心的 DAG 成员数量相等。 这意味着每个 DAG 都有偶数数量的服务器，并使用见证服务器进行仲裁维护。

DAG 是 Exchange 2019 中的基本构建基块。 对于 DAG 大小，具有更多参与成员节点的 DAG 可提供更多的冗余和资源。 在 PA 中，目标是部署成员节点数较多的 DAG，通常从 8 成员 DAG 开始，并根据需要增加服务器数以满足要求。 仅当可伸缩性引入对现有数据库复制布局的担忧时，才应创建新的 DAG。

DAG 网络设计

PA 使用单个非组合网络接口进行客户端连接和数据复制。 只需要一个网络接口，因为最终我们的目标是实现标准恢复模式，而不管故障是发生服务器故障还是发生网络故障，结果都是相同的：数据库副本在 DAG 中的另一台服务器上激活。 此体系结构更改简化了网络堆栈，并消除了手动消除检测信号串话的需要。

见证服务器放置

见证服务器的位置决定了体系结构是否可以提供自动数据中心故障转移功能，或者在发生站点故障时是否需要手动激活来启用服务。

如果你的组织有一个具有网络基础结构的第三个位置，该网络基础结构与影响部署 DAG 的站点复原数据中心对的网络故障隔离开来，则建议在第三个位置部署 DAG 的见证服务器。 此配置使 DAG 能够自动将数据库故障转移到另一个数据中心，以响应数据中心级别的故障事件，而不管哪个数据中心发生中断。

如果组织没有第三个位置，请考虑将服务器见证放置在 Azure 中;或者，将见证服务器放在站点可复原数据中心对中的某个数据中心中。 如果在站点复原数据中心对中有多个 DAG，请将所有 DAG 的见证服务器放置在同一数据中心 (大多数用户物理位于) 的数据中心。 此外，请确保每个 DAG 的主 Active Manager (PAM) 也位于同一数据中心。

Exchange Server 2019 和所有早期版本都不支持使用 Windows Server 2016 故障转移群集中首次引入的云见证功能。

数据弹性

数据复原是通过部署多个数据库副本来实现的。 在 PA 中，数据库副本分布在站点复原数据中心对上，从而确保邮箱数据免受软件、硬件甚至数据中心故障的影响。

每个数据库有四个副本，每个数据中心有两个副本，这意味着 PA 至少需要四个服务器。 在这四个副本中，其中三个配置为高度可用。 第四个副本 (激活首选项编号最高的副本，) 配置为滞后的数据库副本。 由于服务器设计，数据库的每个副本都与其其他副本隔离，从而减少故障域并提高解决方案的整体可用性，如 DAG：超出“A”中所述。

滞后数据库副本的目的是为系统范围的灾难性逻辑损坏的罕见事件提供恢复机制。 它不适用于单个邮箱恢复或邮箱项目恢复。

滞后的数据库副本配置了为期 7 天的 ReplayLagTime。 此外，还启用了重播延迟管理器，以便在由于丢失非滞后副本而危及可用性时，为滞后副本提供动态日志文件播放。

以这种方式使用滞后数据库副本，请务必了解滞后数据库副本不是有保证的时间点备份。 滞后数据库副本的可用性阈值通常为 90%左右，原因是包含滞后副本的磁盘由于磁盘故障而丢失，滞后副本由于自动淡化) 而变为 HA 副本 (，以及滞后数据库副本正在重新生成重播队列的时间段。

为了防止意外 (或恶意) 项目删除，将使用 单项恢复 或 就地保留 技术，并将 “已删除项目保留期 ”窗口设置为满足或超过任何定义的项级恢复 SLA 的值。

由于所有这些技术都在发挥作用，因此不需要传统的备份;因此，PA 使用 Exchange 本机数据保护。

Office Online Server设计

至少需要在每个托管 Exchange 2019 服务器的数据中心部署一个Office Online Server (OOS) 场，其中包含至少两个 OOS 节点。 每个Office Online Server应至少有 8 个处理器核心、32 GB 内存和至少 40 GB 的专用于日志文件的空间。 Exchange 2019 邮箱服务器应配置为依赖于其数据中心的本地 OOS 场，以确保服务器之间尽可能低的延迟和尽可能高的带宽来向用户呈现文件内容。

摘要

Exchange Server 2019 继续改进早期版本的 Exchange 中引入的投资，并引入了最初发明用于 Microsoft 365 和 Office 365 的其他技术。

通过与首选体系结构保持一致，你将利用这些更改，并尽可能提供最佳的本地用户体验。 你将延续具有高度可靠、可预测和可复原的 Exchange 部署的传统。