了解传输中的 SMTP 故障转移和负载平衡

Exchange 2010
 

适用于: Exchange Server 2010 SP2, Exchange Server 2010 SP3

上一次修改主题: 2016-11-28

当组织中拥有多个集线器传输服务器时,Exchange 会自动在组织中的所有集线器传输服务器间分布邮件通信。当所有服务器都可用时,负载分布可成功地均匀分布负载。但是,当一个或多个服务器不可用时,剩余服务器间的负载分布可能会不均匀,尤其是当组织跨多个 Active Directory 站点分布时。

在 Microsoft Exchange Server 2010 Service Pack 1 (SP1) 中,针对用于在集线器传输服务器间分布负载的决策制定机制进行了几处改进。

是否正在查找与邮件路由相关的管理任务?请参阅管理邮件路由

目录

Exchange Server 2010 RTM 行为

Exchange 2010 SP1 改进

针对传输服务器的 Windows 网络负载平衡或第三方负载平衡解决方案

在 Exchange 2010 的正式发布 (RTM) 版中,当某个传输服务器需要将几封邮件路由到相同目标时,该服务器最初会确定这些邮件的下一个跃点。如果该下一个跃点有多个目标服务器,则它会使用增强域名系统 (DNS) 提供的轮循机制方式,对用于传递邮件的连接进行负载平衡,以便在目标服务器间均匀分布。例如,请考虑一个拓扑,其中有两个 Active Directory 站点,每个站点中有三个集线器传输服务器(如下图所示)。当 Site A 中的集线器传输服务器(例如 Hub02)需要向 Site B 发送邮件时,该邮件的下一个跃点为 Site B。下一个跃点中可能有三个目标:Hub04、Hub05 和 Hub06。服务器会在这三个目标间均匀地分布连接数,如下图所示。随着时间的推移,此操作会在连接间形成均匀的邮件分布。

Exchange Server 2010 RTM 中的负载平衡

同样,Site B 中的集线器传输服务器也会在 Hub01、Hub02 和 Hub03 间均匀地分布发送给 Site A 中收件人的邮件数。此外,因为向 Site A 订阅了 Edge01,所以对于发送给 Internet 的邮件,下一个跃点的目标是 Hub01、Hub02 和 Hub03。

如果下一个跃点中的一个或多个服务器不可用,则会出现问题。例如,假设 Site B 中的 Hub04 不可用,因为要按计划进行维护。Site A 中的服务器不会保持 Site B 中的每个服务器的可用性状态。Site A 中的服务器会在 Site B 中的三个集线器传输服务器之间分布以 Site B 为目标的负载。这些连接中大约有三分之一会发送到 Hub04,但是不会成功。这些连接会故障转移到下一个可用服务器,因而 Site B 中的一个集线器传输服务器处理的负载会显著多于另一个服务器处理的负载,如下图所示。

不均匀的负载平衡

只要在通常具有两个以上目标的下一个跃点中存在不可用的服务器,便可能会发生这种不利行为。下一个跃点可以是另一个 Active Directory 站点(如上面的示例所示),也可以是将多个集线器传输服务器列为源服务器的连接器(例如,上图所显示拓扑中的已订阅边缘传输服务器的发送连接器)。

对于从邮箱服务器进行的邮件提交,这不会成为问题。邮件提交服务会检测站点中的不可用集线器传输服务器,不会尝试传递给这些服务器。在前面展示的示例中,虽然 Site B 中有一个集线器传输服务器可能因站点间通信而加重负载,但 Site B 中的邮箱服务器生成的负载将平均地分布在 Hub05 与 Hub06 之间。

Exchange Server 2010 RTM 行为

为了解决上一节中描述的问题,在 Exchange 2010 SP1 中添加了一个新组件,称为正常服务器选择器。正常服务器选择器会维护一个由不可用服务器组成的列表。此列表由增强 DNS 用于在应用轮循机制逻辑进行负载平衡时,筛选出所有不可用的服务器。为了演示正常服务器选择器如何帮助进行负载平衡,请考虑上图中显示的问题状况。在 Exchange 2010 SP1 中,增强 DNS 会首先编译下一个跃点 Site B 中的潜在目标列表。随后要求正常服务器选择器筛选该列表。正常服务器选择器会报告下一个跃点 Site B 的 Hub04 不正常。增强的 DNS 将从下一个跃点 Site B 的潜在目标列表中删除 Hub04,并将仅在 Hub05 与 Hub06 之间使用轮询机制负载平衡,如下图所示。

使用正常服务器选择器的负载平衡

在最简单的形式中,正常服务器选择器会跟踪被视为不正常的服务器,以便在轮循机制负载平衡中不包括这些服务器。从正常服务器选择器的角度而言,不正常服务器是指连接试图向其返回任何 Windows 套接字 (Winsock) 错误代码的服务器。

对于每个不正常服务器,正常服务器选择器都会保留以下信息:

  • 服务器 IP 地址

  • 重试计数

  • 上次重试时间

当某个服务器被标记为不正常时,正常服务器选择器会确保再次尝试与该特定服务器连接,以检测该服务器何时联机。正常服务器选择器使用以下设置确定对不正常服务器重试连接的频率:

  • QueueGlitchRetryInterval 和 QueueGlitchRetryCount   这些设置确定正常服务器选择器在特定服务器首次被标记为不正常时,对该服务器重试连接的次数和间隔时间。这些设置在 EdgeTransport.exe.config 文件中配置。这些设置的默认值为 1 分钟和 4 次重试。这些值表示使用默认配置时,会每分钟尝试连接一次不正常服务器,共尝试四次。

  • TransientFailureRetryInterval 和 TransientFailureRetryCount   如果不正常服务器不可用,则正常服务器选择器会使用这些设置确定下一组重试的频率。每个传输服务器都需配置这些设置。默认值为 5 分钟(在边缘传输服务器上为 10 分钟)和 6 次重试。这些值表示使用默认配置时,在经过前四分钟后,会每五分钟尝试连接一次不正常服务器,共尝试六次。

  • OutboundConnectionFailureRetryInterval   如果不正常服务器不可用,则正常服务器选择器会继续按此参数中指定的频率重试连接。每个传输服务器都需配置此设置。默认值为 10 分钟(在边缘传输服务器上为 30 分钟)。这表示使用默认配置时,在经过前 34 分钟后,会每 10 分钟尝试连接一次不正常服务器。

有关如何配置这些设置的分步说明,请参阅配置邮件重试间隔、重新提交间隔和过期间隔

当到时间重试连接时,正常服务器选择器仅允许对不正常服务器进行一次连接尝试。如果该连接成功,则 SMTP 出站组件会通知正常服务器选择器连接成功。此时,正常服务器选择器会从不正常服务器列表中删除该服务器。

传输的卷影冗余组件包括检测信号功能。检测信号是一种简单 SMTP 连接,用于查询以前向目标服务器提交的邮件的状态。正常服务器选择器筛选不会阻止卷影冗余管理器发出检测信号连接尝试。如果某个服务器具有已提交给不正常服务器的卷影邮件,则会尝试对该服务器进行检测信号连接。如果与不正常服务器的检测信号连接成功,则正常服务器选择器会立即将该目标服务器从不正常服务器的列表中删除。

若要了解有关卷影冗余和检测信号的详细信息,请参阅了解卷影冗余

在 Exchange 2010 SP1 中,连接日志包含有关正常服务器选择器和增强负载平衡功能的诊断信息。当正常服务器选择器将某个服务器添加到不正常服务器的列表中时,会在连接日志中记录该事件。若要查找此事件,请在连接日志中搜索短语“MarkedUnhealthy”。在包含此短语的行中,可以找到以下信息:

  • 目标主机 IP 地址

  • 目标主机完全限定域名 (FQDN)

  • 收到的 Winsock 错误

  • 状态:MarkedUnhealthy

  • 当前失败计数

  • 下次重试时间

在此条目中,可以通过评估 Winsock 错误代码来确定失败原因。有关 Winsock 错误代码及其定义的完整列表,请参阅 Windows 套接字错误代码

还可以通过分析Current Failure CountNext Retry Time字段,来确定失败的连接尝试次数以及针对目标服务器的下一次计划重试。

必须在传输服务器上启用连接日志记录,才能查看这些诊断信息。默认情况下,会在集线器传输服务器和边缘传输服务器上禁用连接日志记录。有关配置连接日志记录的详细信息,请参阅配置连接日志记录

Exchange Server 2010 RTM 行为

如本主题中前面所述,Exchange 2010 使用增强型 DNS 在“边缘传输”、“集线器传输”和“邮箱”服务器之间对所有组织内邮件通信自动进行负载平衡。但是,此功能不对从非 Exchange 源(如外部电子邮件服务器、第三方反垃圾邮件或防病毒解决方案、Exchange 组织外的任何内部邮件服务器、业务线 (LOB) 应用程序以及基于 POP 或基于 IMAP 的电子邮件客户端)接收的邮件进行负载平衡。

如果有一个或多个此类邮件源,则可选择使用一个统一的 SMTP 命名空间(如 smtp.contoso.com)对传入的 SMTP 通信进行负载平衡,这样可将外部电子邮件分布到组织内的各个传输服务器上。既支持 Windows 网络负载平衡 (NLB),也支持来自第三方供应商的基于硬件的负载平衡解决方案。有关经供应商测试和 Microsoft 审查后满足 Exchange 2010 要求的负载平衡器的列表,请参阅 Microsoft 统一通信负载平衡器部署(英文)。

重要重要说明:
不支持使用负载平衡解决方案处理组织中 Exchange 服务器之间的邮件通信。必须从在环境中部署的任何负载平衡解决方案中排除 Exchange 服务器之间的邮件通信。

最常见的情况是处理从 Internet 传入的邮件。无需部署负载平衡解决方案即可将负载分布到各个边缘传输服务器上。使用首选值相同的 DNS 轮循机制和邮件交换记录(MX 记录)即可实现这一点,如下图所示。

使用 DNS 轮循机制和 MX 记录对 Internet 邮件进行负载平衡

如果选择使用 Windows NLB 或硬件负载平衡解决方案分布传入的 Internet 邮件,则需要发布一个指向负载平衡解决方案的 MX 记录。负载平衡器将传入邮件分布到其配置中列出的所有边缘传输服务器,如下图所示。

使用负载平衡解决方案分布 Internet 邮件

Exchange 2010 使用接收连接器接受传入邮件。默认情况下,Exchange 2010 集线器传输服务器利用 SMTP 在 TCP 端口 25 上收到电子邮件后,由名为“默认接收连接器”的接收连接器处理该邮件。

POP 或 IMAP 客户端向 Exchange 2010 集线器传输服务器提交电子邮件时,默认情况下通过 TCP 端口 587 提交该邮件。这表示从 POP 或 IMAP 客户端提交的电子邮件由一个名为“默认客户端接收连接器”的单独的接收连接器进行处理。

如果计划针对集线器传输服务器应用负载平衡解决方案,则应为该用途创建一个单独的接收连接器,并确保仅对该特定连接器处理的通信进行负载平衡。向集线器传输服务器添加额外的 IP 地址,然后将此 IP 地址与新的接收连接器关联,即可达到此目的。此外,应在接收连接器上禁用“Exchange Server 身份验证”选项,以确保 Exchange 通信在路由时不经过该连接器。下图显示的配置中使用负载平衡器将从 POP3 或 IMAP4 客户端和非 Exchange SMTP 服务器接收的邮件分布到两个集线器传输服务器上。

在集线器传输服务器之间对非 Exchange 邮件进行负载平衡

Windows NLB 是最常用于 Exchange 服务器的软件负载平衡器。针对 Windows 集线器传输服务器部署 Exchange 2010 NLB 时有一些限制:

  • 不能在同时具有集线器传输服务器角色和邮箱服务器角色并且还加入数据库可用性组 (DAG) 的 Windows 服务器上使用 Exchange NLB。

    这是因为 Windows NLB 功能与 Windows 故障转移群集不兼容。如果想在使用 Exchange 2010 DAG 的同时使用 Windows NLB,则需要在不同的计算机上运行集线器传输服务器角色和邮箱服务器角色。此外,DAG 成员与集线器传输服务器角色在同一服务器上共存时,Windows NLB 将影响邮件路由。若要了解详细信息,请参阅使用 DAG 时的集线器传输和邮箱服务器角色共存

  • 我们建议不要在由 Windows NLB 进行负载平衡的阵列中放置超过八个集线器传输服务器。如果需要对超过八个集线器传输服务器进行负载平衡,则应部署基于硬件的解决方案。

  • Windows NLB 无法检测服务中断。

    而只能按 IP 地址检测服务器中断。如果 Exchange 传输服务发生故障,但服务器仍在运行,则 Windows NLB 检测不到该故障,仍会将传入电子邮件路由到该集线器传输服务器。需要进行手动干预,从负载平衡池中删除出现中断的集线器传输服务器。

  • Windows NLB 配置可能会产生端口泛滥,从而导致网络崩溃。

    这是因为 Windows NLB 被设计为同时将所有传入客户端数据包传送到所有交换机端口。尽管这种行为可大大提高 Windows NLB 的吞吐量,但可能会导致交换机的占用率很高。

有关配置 Windows NLB 的详细步骤,请参阅为集线器传输服务器配置 Windows 网络负载平衡

如果需要对超过八个集线器传输服务器进行非 Exchange 邮件通信的负载平衡,则要求负载平衡解决方案具有更大的可伸缩性。尽管有一些强大的软件负载平衡解决方案可以使用,但是最有效的是硬件负载平衡解决方案。

与 Windows NLB(只能按 IP 地址检测服务器中断)不同的是,配置硬件负载平衡器后,该平衡器可检测 Exchange 传输服务的故障情况,并且在无需任何手动干预的情况下即可将传入的电子邮件路由到其他集线器传输服务器。

有关配置硬件负载平衡解决方案的详细步骤,请参阅为集线器传输服务器配置硬件负载平衡

 © 2010 Microsoft Corporation。保留所有权利。
显示: