了解 Exchange 2010 中的负载平衡

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

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

负载平衡是一种管理由哪些服务器接收通信的方法。负载平衡提供故障转移冗余以确保在计算机出现故障时，用户可以继续接收 Exchange 服务。 它还使您的部署能够处理比一台服务器能够处理的通信还多的通信，同时为客户端提供单一主机名。

除负载平衡外，Microsoft Exchange Server 2010 还为切换和故障转移冗余提供了多种解决方案。 这些解决方案包括：

• 高可用性与站点弹性   您可以在不同的地理位置部署两个 Active Directory 站点，使两者之间的邮箱数据保持同步，并且让一个站点在另一个站点出现故障后负担所有负载。Exchange 2010 使用数据库可用性组 (DAG) 来使邮箱在不同服务器上的多个副本保持同步。

• 联机邮箱移动   在联机邮箱移动中，最终用户在移动过程中可以访问他们的电子邮件帐户。 只有在过程结束时（发生最终同步时），才会短暂锁定用户帐户。 支持在 Exchange 2010 数据库之间和在 Exchange Server 2007 Service Pack 3 (SP3) 或 Exchange 2007 的更高版本与 Exchange 2010 数据库之间执行联机邮箱移动。您可以跨林或在同一林中执行联机邮箱移动。

• 卷影冗余   卷影冗余保护邮件在传输过程中的可用性和可恢复性。 使用卷影冗余时，如果要从传输数据库中删除邮件，将延迟删除操作，直至传输服务器确认针对该邮件的所有下一跃点均已完成。 如果在报告成功传递之前有任何下一跃点失败，则会重新提交该邮件，以便传递到未完成的跃点。

目录

负载平衡概述

了解 Exchange 2010 通信负载

了解负载平衡选项

负载平衡建议

相关性选项

负载平衡概述

负载平衡有两种主要用途。 当您的一个 Active Directory 站点中的一个客户端访问服务器出现故障时，负载平衡可以降低该故障造成的影响。 此外，负载平衡可确保您的客户端访问服务器和集线器传输计算机上的负载分配均匀。

Exchange 2010 负载平衡中的体系结构变化

Exchange 2010 中的多个变化使负载平衡对您的组织有着重大意义。针对客户端访问服务器角色的 Exchange RPC 客户访问服务和 Exchange 通讯簿服务通过将用于访问邮箱的连接终结点从 Outlook 和其他 MAPI 客户端移动到客户端访问服务器角色，而不是移动到邮箱服务器角色，来改善用户在邮箱故障转移过程中的体验。在较早版本的 Exchange 中，Outlook 直接与托管用户邮箱的邮箱服务器连接，而目录连接则通过邮箱服务器角色代理或直接连接到特定 Active Directory 全局编录服务器。 这些连接由客户端访问服务器角色处理，因此在部署中，必须使外部和内部 Outlook 连接在整个客户端访问服务器阵列中取得负载平衡以实现容错功能。

建议对各个 Active Directory 站点和各个版本的 Exchange 分别使用一个客户端访问服务器负载平衡阵列。不能使多个 Active Directory 站点共享一个客户端访问服务器负载平衡阵列，或者在同一个阵列中混合使用不同版本的 Exchange 或 Exchange 的不同 Service Pack 版本。

在现有组织内安装 Exchange 2010，并配置旧版本的命名空间，使其与以前版本的 Exchange 并存，则您的客户端将自动连接到 Exchange 2010 客户端访问服务器或服务器阵列。然后，Exchange 2010 客户端访问服务器或客户端访问服务器阵列将代理较早的 Exchange 版本上的邮箱的客户端请求，或将这些请求重定向到与邮箱版本匹配的 Exchange 2003 前端服务器或 Exchange 2007 客户端访问服务器。 有关详细信息，请参阅了解到 Exchange 2010 的升级。

注意：
可以将快速修复工程 (QFE) 与更新汇总混合使用，但前提是将它们应用到整个或部分阵列中。 建议对阵列中的所有计算机应用 QFE 和更新汇总。

负载平衡配置将直接影响客户端用于连接的主机名和您使用的安全套接字层 (SSL) 证书。 有关 Exchange 2010 证书的详细信息，请参阅了解数字证书和 SSL。

配置客户端访问服务器阵列

可以为每个 Active Directory 站点配置一个客户端访问服务器阵列。 配置客户端访问服务器阵列后，可以将邮箱数据库配置为将客户端访问服务器阵列用作 MAPI 终结点，而不是用作特定的客户端访问服务器。

有关客户端访问服务器阵列以及如何将邮箱数据库配置为将客户端访问服务器阵列用作特定的 Active Directory 站点的详细信息，请参阅了解 RPC 客户端访问。

了解 Exchange 2010 通信负载

配置负载平衡之前，应该首先了解 Exchange 2010 客户端访问服务器上的负载。Exchange 2010 客户端访问服务器接收以下三种类型的通信：

• 来自外部客户端的通信

• 来自内部客户端的通信

• 来自其他客户端访问服务器的代理通信

来自其他客户端访问服务器的代理通信指最初由外部或内部客户端发送给一个客户端访问服务器，但后来被代理到另一个客户端访问服务器的通信。 发生这种情况的原因有多种，但通常是由于原始客户端无法直接连接到目标客户端访问服务器而引起的。 当用户试图通过 Internet 访问邮箱，但邮箱却位于非面向 Internet Active Directory 的站点时，则可能会发生这种情况。 有关代理的详细信息，请参阅了解代理和重定向。

客户端访问服务器接收的每种类型的通信都包括协议列表的请求，并且来自具有不同特征的客户端设备和计算机。 这些差异会影响可以使用哪些负载平衡策略。

返回顶部

了解负载平衡选项

有多种不同的负载平衡解决方案，它们之间有几个主要的技术区别。

• 性能   该解决方案每秒可以处理多少请求？

• 可管理性   配置和部署负载平衡解决方案的简易程度如何？

• 故障转移自动化与检测 当客户端访问服务器或服务出现故障时，负载平衡器在检测方面的反应程度如何？

• 相关性 负载平衡解决方案支持客户端与客户端访问服务器之间的哪种相关性类型？

了解相关性

如果负载平衡解决方案提供客户端与客户端访问服务器相关性，则表示特定客户端与特定客户端访问服务器之间有长效关联。客户端可以是便携式计算机上运行的 Outlook、移动设备上运行的 Microsoft Exchange ActiveSync、Microsoft Office Outlook Web App、Exchange Web 服务或其他客户端应用程序。

这种长效关联或相关性可确保所有来自客户端的请求都发送到同一个客户端访问服务器。某些 Exchange 2010 协议要求相关性，而其他 Exchange 协议则不要求。

Windows 网络负载平衡

Windows 网络负载平衡 (WNLB) 是用于 Exchange 服务器的最常见的软件负载平衡器。为 Microsoft Exchange 部署 WNLB 时有一些限制。

• 无法在使用邮箱 DAG 的 Exchange 服务器上使用 WNLB，因为 WNLB 与 Windows 故障转移群集不兼容。如果您现在使用的是 Exchange 2010 DAG，但又想使用 WNLB，则需要在不同的服务器上运行客户端访问服务器角色和邮箱服务器角色。

• 由于性能问题，我们不建议在一个由 WNLB 实现负载平衡的阵列中有八个以上的客户端访问服务器。

• WNLB 不会检测服务中断。 WNLB 只按 IP 地址检测服务器中断。 这就是说，如果一个特定 Web 服务（如 Outlook Web App）出现故障，但服务器仍在运行，则 WNLB 不会检测到该故障，并且仍会将请求路由到该客户端访问服务器。 需要手动干预来从负载平衡池中删除出现中断的客户端访问服务器。

• WNLB 配置会导致端口泛滥，从而导致网络崩溃。

• 由于 WNLB 仅使用源 IP 地址执行客户端相关性，因此当源 IP 池较小时，这不是有效的解决方案。 当源 IP 池来自远程网络子网或组织在使用网络地址转换时，可能会发生这种情况。

负载平衡建议

有几种负载平衡选项可供选择。 您使用的选项取决于您网络的大小和配置。

具有源 IP 相关性的 Windows 网络负载平衡

第一个负载平衡选项是具有源 IP 相关性的 WNLB。 如果每个 Active Directory 站点的客户端访问服务器多于一个但少于八个时，适合采用此解决方案。此解决方案内置于 Windows 中，并不需要其他计算机。

还有两种您不想使用 WNLB 时的方案。

• 您的组织有不通过 WNLB 虚拟 IP 地址直接与客户端访问服务器通信的反向代理服务器。 该反向代理服务器对客户端访问服务器阵列隐藏客户端 IP 地址。 因此，源 IP 相关性无法正常发挥作用。 但是，您可能仍想使用 WNLB 来平衡内部通信负载。

• 您的组织有许多可以通过少量 IP 地址访问客户端访问服务器的客户端。 WNLB 可能会将整个 C 类子网关联到一个客户端访问服务器。

硬件负载平衡

如果一个 Active Directory 站点中有八个以上的客户端访问服务器，则您的组织将需要一个更强大的负载平衡解决方案。尽管有一些强大的软件负载平衡解决方案可以使用，但是最有效的是硬件负载平衡解决方案。有关 Exchange 2010 服务器负载平衡解决方案的详细信息，请参阅 Microsoft 统一通信硬件负载平衡器部署。

硬件负载平衡器支持非常高的通信吞吐量，并且可以配置为以多种方式平衡负载。 大多数硬件负载平衡器供应商都有关于其产品与 Exchange 2010 一同运行的情况的详细文档。 配置硬件负载平衡器最简单的方法是创建一个关于负载平衡器将应用的相关性方法的回退列表。例如，负载平衡器会首先尝试基于 cookie 的相关性，然后尝试 SSL 会话 ID，再然后尝试源 IP 相关性。

反向代理解决方案

如果您有一种反向代理解决方案，这种解决方案将服务器发布到 Internet 并且能够为这些服务器执行负载平衡，如 Microsoft Forefront Threat Management Gateway (TMG) 或 Forefront Unified Access Gateway (UAG)，我们建议您使用这种解决方案。

通信通过反向代理服务器到达客户端访问服务器后，客户端的原始 IP 地址就会被反向代理服务器的 IP 地址替换。 这将中断源 IP 相关性。 解决这一问题的方法有多种，其中包括将反向代理服务器配置为它将代理到的子网的默认网关。

但是，当前大多数反向代理服务器都可以使其发布到 Internet 的服务实现负载平衡。 对于支持负载平衡器创建的 cookie 负载平衡的 Exchange 服务，这些反向代理服务器也支持这种负载平衡。 此解决方案比源 IP 负载平衡更可靠。 为此，反向代理服务器必须能够读取和修改 HTTP 数据流。 如果使用 SSL，则意味着反向代理服务器必须对通信进行解密以读取内容，并在数据流内创建 cookie。 在某些情况下无法进行这种解密，例如，当您使用客户端证书身份验证时（在这种情况下，客户端连接到客户端访问服务器）。

返回顶部

相关性选项

不同的负载平衡解决方案提供将客户端与特定客户端访问服务器关联的不同方法。 在不同的负载平衡产品（硬件和软件）中，有几种类型的通用相关性。 但是，并非所有负载平衡选项中的所有相关性类型都一样，具体如以下示例所示：

• WNLB 只支持源 IP 相关性或者无相关性。

• 对于支持负载平衡器创建的 cookie 的协议，单独的服务器阵列中的软件负载平衡器可以使用这些 cookie；对于其余的协议，则可以使用源 IP 相关性。

• 具有 SSL 卸载功能的硬件负载平衡器使您可以配置更复杂的行为。 例如，您可以配置一组现有 cookie，这些 cookie 会对支持它们的协议产生影响，还可以配置负载平衡器创建的 cookie、SSL 会话 ID 和源 IP。

除不同的负载平衡解决方案支持的选项外，您还可以将某些步骤配置为仅应用于某些 Exchange 协议和服务。 每个协议的作用都有所不同，这有助于优化性能。

现有 cookie 或 HTTP 头

使用现有 cookie 或 HTTP 头是标识客户端并将其与特定客户端访问服务器关联的最可靠的方法。 这些 cookie 和 HTTP 头是由客户端或服务器将其作为通信协议的一部分创建的。 这一选项也不需要负载平衡器修改通信，从而有助于优化性能。

在使用此相关性选项时，务必注意下列内容：

• 负载平衡器必须支持此类型的相关性。 当前只有硬件负载平衡器支持此相关性。

• 此相关性仅适用于通过 HTTP 传递通信的协议。

• 协议中必须有现有 cookie 或 HTTP 头，它们在客户端会话中保持不变，并且对每个特定客户端或一小组客户端都是唯一的。

• 负载平衡器解决方案必须能够读取并解释 HTTP 数据流。 如果使用 SSL，则意味着负载平衡器必须对通信进行解密以读取内容。 有时，这会导致负载平衡器的负载增加。 此外，某些情况下（例如，当您对客户端连接到客户端访问服务器的 SSL 会话使用客户端证书身份验证时）无法进行这种解密。

Exchange 2010 协议中提供的适合负载平衡的现有 cookie 和 HTTP 头如下：

• HTTP 基本身份验证授权头   使用 HTTP 基本身份验证时，此授权头将适用。 基本身份验证是 Exchange ActiveSync 的默认身份验证类型，也是最常用的身份验证类型。 对于其他协议和身份验证方法，此授权头并不常用。基本身份验证授权头会将使用基本身份验证和来自特定用户的所有通信都发送到同一个客户端访问服务器。 当 Outlook 通信完全通过 HTTP 进行传输，并且客户端由反向代理服务器进行代理时，也会使用此授权头。

• HTTP OWA UserContext cookie   此 cookie 适用于 Outlook Web App（唯一使用此 cookie 的客户端）。当您对 Outlook Web App 使用基于表单的身份验证 (FBA)（此为默认配置）时，会在 Outlook Web App 会话之初创建少量请求，然后创建 UserContext cookie。 为确保这些请求使用相关性将客户端连接到相同的客户端访问服务器（只有这样才能使基于表单的身份验证发挥作用），使用 UserContext cookie 时必须有回退相关性选项。 我们建议您在负载平衡器获得要使用的 UserContext cookie 之前，使用 SSL 会话 ID 或源 IP 相关性作为回退选项，来为那些初始请求提供相关性。

  注意：
  通过显式登录访问特定邮箱的 Outlook Web App 请求导致使用具有其他名称和 ID 的 UserContext cookie。此 cookie 以 UserContext 开头，但后面添加了一个标识单个邮箱的字符串。 这增加了使用 UserContext cookie 进行负载平衡的复杂性，因为负载平衡器必须先找到以 UserContext 开头的 cookie。 这会导致性能降低。

• HTTP Exchange 控制面板 msExchEcpCanary cookie   此 cookie 仅适用于 Exchange 控制面板。

• HTTP Outlook 2010 OutlookSession cookie   硬件负载平衡器支持 OutlookSession cookie 以及其他一般 cookie。 下表描述了 Outlook RPC/HTTP 的 OutlookSession 客户端 cookie 支持要求：

  	Windows XP	Windows Vista	Windows 7
  Outlook 2003	不支持	不支持	不支持
  Outlook 2007	不支持	不支持	不支持
  Outlook 2007 Hosting Pack (KB2544404)	不支持	支持	支持
  Outlook 2010	不支持	支持	支持

  注意：
  Windows XP 上运行的 Microsoft Outlook 为了负载平衡不支持 OutlookSession cookie。在这种情况下，我们建议使用 IP 负载平衡。

• HTTP 远程 PowerShell MS-WSMAN cookie   此方法仅适用于远程 PowerShell。

返回顶部

负载平衡器创建的 Cookie

将客户端会话与客户端访问服务器关联的第二个可靠的方法是使用负载平衡器创建的 cookie。 负载平衡器将 HTTP cookie 添加到客户端/服务器协议会话中，然后用此 cookie 来确定应该由哪个客户端访问服务器处理传入请求。支持这一方法的 Exchange 2010 应用程序包括 Outlook Web App、Exchange 控制面板和远程 PowerShell。这种类型的 cookie 存在一些限制。

• 负载平衡器必须支持此类型的相关性。 目前只有在单独的服务器层上运行的硬件负载平衡器和软件负载平衡器支持此类型的相关性。

• 此方法仅适用于通过 HTTP 传递通信的协议。无法将此方法用于 RPC 客户端访问服务、Exchange 通讯簿服务、POP3 或 IMAP4。

• 负载平衡器解决方案必须能够读取并解释 HTTP 数据流。 如果使用 SSL，则意味着负载平衡器必须对通信进行解密以读取内容。 有时，这会导致负载平衡器的负载增加。 在其他情况下，负载平衡器无法解释 HTTP 数据流，例如，当您在客户端访问服务器上使用客户端证书身份验证时。

• 客户端必须能够接收来自服务器的任意 cookie，然后必须包含以后从客户端发送到服务器的所有未来请求中的 cookie。Exchange ActiveSync 客户端、Outlook Anywhere 客户端和一些 Exchange Web 服务客户端（如 MicrosoftOffice Communications Server 2007 设备）均不支持这一操作。

SSL 会话 ID

基于 SSL 会话 ID 的负载平衡比源 IP 相关性提供的内容更为详细，并且使您能够拆分来自不同客户端的通信，即使这些客户端来自同一个 IP 地址也是如此。 SSL 会话 ID 负载平衡的另一个优点是使您能够在不对 SSL 通信进行解密的情况下实现负载平衡。 当使用客户端证书身份验证时和当结束客户端访问服务器的 SSL 连接时，这个优点就发挥作用了。

不建议在以下两种情况下使用 SSL 会话 ID 相关性：

• 某些客户端（如 Internet Explorer 8）为客户端计算机上运行的每个浏览器进程重新创建 SSL 会话。 这将导致每个 Outlook Web App 窗口生成新的 SSL 会话。 由于这将中断 Outlook Web App 的客户端相关性，因此 Exchange 2010 不支持以这种方式部署负载平衡。 某些移动设备（如 Apple iPhone）也为其与 Exchange 的部分 Exchange ActiveSync 通信创建新的 SSL 会话。

  注意：
  当您使用客户端证书身份验证时，浏览器将使用同一个 SSL 会话来处理面向给定主机名的所有通信。 只要启用了客户端证书身份验证，SSL 会话 ID 对于 Outlook Web App 和 Exchange 控制面板来说就是有效的相关性选项。

• 对于 Outlook Anywhere，客户端访问服务器将使用 Windows RPC 代理组件对 RPC_DATA_IN 和 RPC_DATA_OUT 连接进行配对。 这可能会给性能带来负面影响。

源 IP

提供客户端与客户端访问服务器之间的相关性最常用的方法是使用源 IP 相关性。 负载平衡器会检查客户端的 IP 地址，并将来自特定源 IP 的所有通信都发送到特定客户端访问服务器。 这是 WNLB 支持的唯一的相关性类型。 使用源 IP 相关性时，需要考虑两个重要方面。

• 客户端更改 IP 地址后，相关性将中断。 当便携式计算机从有线 LAN 移到 Wi-Fi 或在不同 Wi-Fi 网络之间漫游时，会发生这种情况。 客户端更改 IP 地址后，会对用户产生影响。例如，当客户端使用 Outlook Web App 时，计算机每获取一个新的 IP 地址，用户就需要进行一次身份验证。

• 如果您的多个客户端从同一个 IP 地址访问您的负载平衡解决方案，则负载分配将变得不平衡。 这造成的影响取决于使用给定 IP 地址作为掩码的客户端的数量。 例如，您有四个客户端访问服务器，而 50% 的客户端从同一个 IP 地址访问您的负载平衡器，则至少 50% 的通信将转到一个客户端访问服务器上，其他三个客户端访问服务器将处理其余的通信。 为什么大部分客户端通过单个 IP 地址访问您的 Exchange 组织呢？原因主要有两个。

  • 网络地址转换器 (NAT) 或传出代理服务器，如 Microsoft Forefront Threat Management Gateway (TMG)。 当您的客户端和客户端访问服务器之间有 NAT 或传出代理服务器时，原始客户端 IP 地址将以 NAT 或传出代理服务器 IP 地址作为掩码。

  • 客户端访问服务器到客户端访问服务器的代理通信。 在某些情况下，某个客户端访问服务器将通信代理到另一个客户端访问服务器。 通常，这发生在 Active Directory 站点之间，因为客户端必须访问与它们的邮箱相同的 Active Directory 站点内的客户端访问服务器。 有关代理的详细信息，请参阅了解代理和重定向。

无相关性

最后一种相关性是无相关性。 不使用相关性时，来自客户端的每个请求都会随机分配给一个客户端访问服务器。 对于需要相关性的协议或者相关性有助于改善其性能的协议，我们不建议使用此选项。

配置 SSL 卸载时，对于不需要相关性的协议，建议您不要使用相关性。

返回顶部

负载平衡选项摘要

下表提供了可用的负载平衡选项的摘要。

每种选项都有各自的优缺点。

• 硬件负载平衡器通常包含性能和安全性功能，如 SSL 卸载和通信检查。

• 单独服务器层中的软件负载平衡器通常属于较大型软件包的一部分，具有预身份验证、SSL 卸载和大量通信检查等反向代理功能。 当软件负载平衡器对用户进行预身份验证时，如果这些用户关联到的客户端访问服务器出现故障，他们不需要重新进行身份验证。 但是，某些软件负载平衡器要求客户端与反向代理服务器之间具有相关性。 在这种情况下，反向代理服务器前必须有一个额外的负载平衡层，这些反向代理服务器才能为您的客户端访问服务器执行负载平衡任务。

 © 2010 Microsoft Corporation。保留所有权利。