Exchange Server中的负载均衡
Exchange 2016 及更高版本中的负载均衡基于 Exchange 2013 中提供的 Microsoft 高可用性和网络复原平台构建。 如果这与第三方负载均衡解决方案 (硬件和软件) 的可用性相结合，则有多个选项可用于在 Exchange 组织中实现负载均衡。
Exchange 2013 中引入的 Exchange 体系结构更改带来了邮箱服务器和客户端访问服务器角色。 将此与 Exchange 2010 进行比较，Exchange 2010 在单独的服务器上运行客户端访问、邮箱、中心传输和统一邮件。
Exchange 2016 和 2019 使用最少的服务器角色提供：
简化了邮箱服务器运行客户端访问服务和边缘传输服务器角色的部署。
在传输管道中管理的邮件流，它是将邮件路由到邮箱服务器上的传输服务分类程序的服务、连接、队列和组件的集合。
通过部署负载均衡器来分配客户端流量，实现高可用性。
Exchange 2013 引入的 HTTP 协议标准意味着 Exchange 2016 和 Exchange 2019 中不再需要会话相关性。 会话相关性允许对已启用消息传送的服务建立持久连接，因此用户不必多次重新输入其用户名和密码。
以前，Exchange 2007 和 Exchange 2010 支持通过 HTTP for Outlook Anywhere 使用 RPC。 Exchange 2013 通过 HTTP 引入了 MAPI，尽管默认情况下未启用它。 现已在 Exchange 2016 和 Exchange 2019 中默认启用。
使用 HTTP 协议后，所有本机客户端在 Exchange Server 中使用 HTTP 和 HTTP 进行连接。 此标准协议无需关联，以前需要这种关联，以避免在负载均衡将连接重定向到其他服务器时出现新的用户凭据提示。
Exchange Server中的服务器角色
Exchange 2016 和 Exchange 2019 的服务器角色数量的减少简化了 Exchange 实现和硬件要求。 Exchange 2016 和 2019 中的服务器角色数量从 7 减少到 2：邮箱服务器和边缘传输服务器。 邮箱服务器角色包括客户端访问服务，而边缘传输服务器在 Exchange 2016 和 Exchange 2019 中提供安全邮件流，就像在早期版本的 Exchange 中一样。
在 Exchange 2013 中，客户端访问服务器角色确保当用户尝试访问其邮箱时，服务器将请求代理回主动为用户邮箱提供服务的邮箱服务器。 这意味着，在邮箱本身上为用户呈现Outlook 网页版 (以前称为Outlook Web App) 等服务，无需关联。
Exchange 2016 和 Exchange 2019 中仍保留相同的功能。 如果两个邮箱服务器托管不同的邮箱，它们可以在必要时相互代理流量。 托管邮箱的活动副本的邮箱服务器为访问邮箱的用户提供服务，即使用户连接到其他邮箱服务器也是如此。
若要详细了解服务器角色更改，请参阅Exchange Server体系结构一文中的 Exchange Server。
| 服务器角色 | 服务 |
|---|---|
| 邮箱服务器 | 使用 EdgeSync 管理从 Active Directory 到边缘传输服务器上的 AD LDS 实例的收据和配置信息的单向复制。 仅复制让边缘传输执行反垃圾邮件并启用端到端邮件流所需的信息。 |
| 边缘传输 | 使用管理所有入站和出站 Internet 邮件流：
不是 Active Directory 林的成员。 |
边缘传输服务器虽然不是必需的，但与早期 Exchange 版本一样位于外围网络中，为 Exchange 组织提供安全的入站和出站邮件流。
在 了解边缘传输服务器上的传输服务一文中详细了解传输服务。
Exchange Server中的协议
从 Exchange 2016 开始，所有本机 Exchange 客户端都使用 HTTP 协议连接到指定的服务，并在登录时提供给用户使用客户端访问服务 SSL 证书加密的 HTTP Cookie。 已登录用户可以在运行客户端访问服务的其他邮箱服务器上恢复会话，而无需重新进行身份验证。 使用同一 SSL 证书的服务器可以解密客户端身份验证 Cookie。
通过 HTTP，可以在 Exchange 网络中使用服务或应用程序运行状况检查。 根据负载均衡器解决方案，可以实施运行状况探测来检查系统的不同组件。
客户端仅 HTTP 访问的效果是负载均衡也更简单。 如果需要，可以使用 DNS 对 Exchange 流量进行负载均衡。 你会向客户端提供每个邮箱服务器的 IP 地址，HTTP 客户端将处理这些杂务。 如果 Exchange 服务器发生故障，协议会尝试连接到另一台服务器。 但是，对 DNS 进行负载均衡存在一些缺点，Exchange Server中的以下负载均衡选项部分对此进行了讨论。
在 Exchange Server 中的 MAPI over HTTP 一文中详细了解 HTTP 和Exchange Server。
Exchange Server 中的负载均衡选项
在此示例中，数据库可用性组中配置的多个服务器 (DAG) 托管运行客户端访问服务的邮箱服务器。 这提供了高可用性，Exchange 服务器占用空间较小。 客户端连接到负载均衡器，而不是直接连接到 Exchange 服务器。 不需要负载均衡器对，但我们建议在群集中部署以提高网络复原能力。
请注意，DAG 使用 Microsoft 群集服务。 无法在与 Windows 网络负载均衡 (NLB) 相同的服务器上启用这些服务。 因此，使用 DAG 时，Windows NLB 不是一个选项。 在这种情况下，有第三方软件和虚拟设备解决方案。
使用 DNS 是对 Exchange 流量进行负载均衡的最简单选项。 使用 DNS 负载均衡，只需向客户端提供每个邮箱服务器的 IP 地址。 之后，DNS 轮循机制会将该流量分发到邮箱服务器。 如果一台 Exchange 服务器完全失败，HTTP 客户端足够智能，可以连接到另一台服务器。
简单性是有代价的，但在这种情况下，DNS 轮循机制并不真正对流量进行负载均衡，因为无法以编程方式确保每个服务器都能获得公平份额的流量。 此外，没有服务级别监视，因此当单个服务发生故障时，客户端不会自动重定向到可用的服务。 例如，如果Outlook 网页版处于失败模式，则客户端将看到错误页。
在外部发布时，DNS 负载均衡需要更多外部 IP 地址。 这意味着组织中的每个 Exchange 服务器都需要外部 IP 地址。
有一些更优雅的解决方案可用于对流量进行负载均衡，例如使用传输层 4 或应用程序层 7 来帮助分配客户端流量的硬件。 负载均衡器监视每个面向 Exchange 客户端的服务，如果发生服务故障，负载均衡器可以将流量定向到另一台服务器，并使有问题的服务器脱机。 此外，某种级别的负载分发可确保没有单个邮箱服务器代理大多数客户端访问。
负载均衡服务可以使用第 4 层、第 7 层或组合来管理流量。 每个解决方案都有优点和缺点。
第 4 层负载均衡器在传输层工作，无需检查内容即可定向流量。
由于它们不检查流量内容，因此第 4 层负载均衡器可节省传输时间。 但是，这伴随着权衡。 第 4 层负载均衡器仅知道 IP 地址、协议和 TCP 端口。 负载均衡器仅知道单个 IP 地址，只能监视单个服务。
第 4 层负载均衡的优势包括：
无需内容检查) (需要更少的资源。
在传输层分配流量。
第 4 层解决方案的风险是，如果服务失败，但服务器仍可用，则客户端可以连接到失败的服务。 这意味着，可复原的第 4 层实现需要为每个服务配置多个 IP 地址，并为每个服务配置单独的 HTTP 命名空间，例如，owa.contoso.com、eas.contoso.com、mapi.contoso.com，这允许服务级别监视。
第 7 层负载均衡器在应用程序层工作，可以检查流量内容并相应地定向流量内容。
第 7 层负载均衡器放弃第 4 层负载均衡的原始性能优势，以便简化单个命名空间，例如，mail.contoso.com 和按服务监视。 第 7 层负载均衡器了解 HTTP 路径（例如 /owa 或 /Microsoft-Server-ActiveSync 或 /mapi），并且可以根据监视数据将流量定向到工作服务器。
第 7 层负载均衡优势包括：
只需一个 IP 地址。
检查内容，并可以定向流量。
提供可脱机的失败服务的通知。
处理负载均衡器 SSL 终止。
在应用层分配流量并了解目标 URL。
SSL 应在负载均衡器终止，因为它提供了一个集中的位置来更正 SSL 攻击。
需要进行负载均衡的端口包括一些端口，例如 IMAP4 或 POP3 的端口，这些端口甚至可能不会在 Exchange 组织中使用。
| TCP 端口 | 角色 | 使用 |
|---|---|---|
| 25 | 邮箱 | 入站 SMTP |
| 587 | 邮箱 | 客户端的入站 SMTP |
| 110 | 邮箱 | POP3 客户端 |
| 143 | 邮箱 | IMAP4 客户端 |
| 443 | 邮箱 | HTTPS (Outlook 网页版、自动发现、Web 服务、ActiveSync、 MAPI over HTTP、RPC over HTTP、OAB、EAC) |
| 993 | 邮箱 | 保护 IMAP4 客户端 |
| 995 | 邮箱 | 保护 POP3 客户端 |
Exchange Server 中的负载均衡部署方案
Exchange 2016 为命名空间和负载均衡体系结构带来了极大的灵活性。 在 Exchange 组织中有许多用于部署负载均衡的选项，从简单的 DNS 到复杂的第三方第 4 层和第 7 层解决方案，我们建议你根据组织的需求查看所有选项。
以下方案具有优势和限制，了解每种方案是实现最适合 Exchange 组织的解决方案的关键：
方案 A 单个命名空间，无会话相关性：第 4 层或第 7 层
方案 B 单个命名空间，无会话相关性：第 7 层
方案 C 具有会话相关性的单个命名空间，第 7 层
方案 D 多个命名空间且无会话相关性，第 4 层
方案 A 单个命名空间，无会话相关性：第 4 层或第 7 层
在此第 4 层方案中，为 HTTP 协议客户端部署了单个命名空间（mail.contoso.com）。 负载均衡器不维护会话相关性。 由于这是第 4 层解决方案，因此负载均衡器配置为仅检查单个虚拟目录的运行状况，因为它无法区分Outlook 网页版请求和 RPC 请求。
从此示例中的负载均衡器的角度来看，运行状况是按服务器而不是指定命名空间的协议。 管理员必须选择要针对运行状况探测的虚拟目录;建议选择大量使用的虚拟目录。 例如，如果大多数用户使用 Outlook 网页版，请在运行状况探测中选择Outlook 网页版虚拟目录。
只要Outlook 网页版运行状况探测响应正常，负载均衡器就会将目标邮箱服务器保留在负载均衡池中。 但是，如果Outlook 网页版运行状况探测因任何原因失败，则负载均衡器将从与该命名空间关联的所有请求的负载均衡池中删除目标邮箱服务器。 这意味着，如果运行状况探测失败，该命名空间的所有客户端请求都会定向到另一个服务器，而不管协议如何。
方案 B 单个命名空间，无会话相关性：第 7 层
在此第 7 层方案中，将为所有 HTTP 协议客户端部署单个命名空间（mail.contoso.com）。 负载均衡器不维护会话相关性。 由于负载均衡器是为第 7 层配置的，因此存在 SSL 终止，并且负载均衡器知道目标 URL。
建议将此配置用于 Exchange 2016 和 Exchange 2019。 负载均衡器配置为检查负载均衡池中目标邮箱服务器的运行状况，并在每个虚拟目录上配置运行状况探测。
例如，只要Outlook 网页版运行状况探测响应正常，负载均衡器就会将目标邮箱服务器保留在Outlook 网页版负载均衡池中。 但是，如果Outlook 网页版运行状况探测因任何原因失败，则负载均衡器将从负载均衡池中删除目标邮箱服务器，以便Outlook 网页版请求。 在此示例中，运行状况按协议进行，这意味着，如果运行状况探测失败，则只有受影响的客户端协议定向到另一个服务器。
方案 C 具有会话相关性的单个命名空间，第 7 层
在此第 7 层方案中，将为所有 HTTP 协议客户端部署单个命名空间（mail.contoso.com）。 由于负载均衡器是为第 7 层配置的，因此存在 SSL 终止，并且负载均衡器知道目标 URL。 负载均衡器还配置为检查负载均衡池中目标邮箱服务器的运行状况。 在每个虚拟目录上配置运行状况探测。
但是，启用会话相关性会降低容量和利用率。 这是因为涉及更多关联选项、基于 Cookie 的负载均衡或安全套接字层 (SSL) 会话 ID，需要更多的处理和资源。 建议你与供应商核实会话相关性如何影响负载均衡可伸缩性。
与前面的方案一样，只要Outlook 网页版运行状况探测响应正常，负载均衡器就会将目标邮箱服务器保留在Outlook 网页版负载均衡池中。 但是，如果Outlook 网页版运行状况探测因任何原因失败，则负载均衡器将从负载均衡池中删除目标邮箱服务器，以便Outlook 网页版请求。 此处，运行状况按协议进行，这意味着，如果运行状况探测失败，则只有受影响的客户端协议会定向到另一个服务器。
方案 D 多个命名空间，没有会话相关性
具有多个命名空间且没有会话相关性的最后一个方案提供每个协议的运行状况检查和第 4 层电源。 为每个 HTTP 协议客户端部署唯一的命名空间。 例如，可将 HTTP 协议客户端配置为 mail.contoso.com、mapi.contoso.com 和 eas.contoso.com。
此方案提供按协议运行状况检查，而不需要复杂的负载均衡逻辑。 负载均衡器使用第 4 层，未配置为维护会话相关性。 负载均衡器配置检查负载均衡池中目标邮箱服务器的运行状况。 在此设置中，运行状况探测配置为针对每个虚拟目录的运行状况，因为每个虚拟目录都有唯一的命名空间。 由于它是针对第 4 层配置的，因此负载均衡器不知道正在访问该 URL，但结果就像它知道一样。 由于运行状况是每个协议的，因此如果运行状况探测失败，则只有受影响的客户端协议会定向到另一个服务器。
Exchange Server 中的负载均衡和托管可用性
监视可用的服务器和服务是高可用性网络的关键。 由于某些负载均衡解决方案不知道目标 URL 或请求的内容，因此可能会给 Exchange 运行状况探测带来复杂性。
Exchange 2016 和 Exchange 2019 包括一个内置的监视解决方案，称为托管可用性。 托管可用性（也称为“活动监视”或“本地主动监视”）是内置监视和恢复操作与 Exchange 高可用性平台的集成。
托管可用性包括脱机响应方。 调用脱机响应方时，将从服务中删除受影响的协议 (或服务器) 。
若要确保负载均衡器不会将流量路由到托管可用性标记为脱机的邮箱服务器，必须将负载均衡器运行状况探测配置为检查 <virtualdirectory>/healthcheck.htm， <https://mail.contoso.com/owa/healthcheck.htm>例如 。
在托管可用性中详细了解 托管可用性。