通过

Skype for Business 的负载平衡要求

  • 项目

总结：在实现Skype for Business Server之前，请查看负载均衡注意事项。

负载均衡在池中的服务器之间分配流量。 如果有前端池、中介服务器池或边缘服务器池，则需要为这些池部署负载均衡。

Skype for Business Server支持两种类型的客户端到服务器流量负载均衡解决方案：域名系统 (DNS) 负载均衡和硬件负载均衡 (通常缩写为 HLB) 。 DNS 负载均衡具有多种优势，包括更简单的管理、更高效的故障排除，以及能够将大部分Skype for Business Server流量与任何潜在的硬件负载均衡器问题隔离开来。

自行确定哪种负载均衡解决方案适用于部署中的每个池，但请记住以下限制：

  • 内部边缘接口和外部边缘接口必须使用同一类型的负载平衡。 您不能在一个接口上使用 DNS 负载平衡的同时，在另一个接口上使用硬件负载平衡。

  • 某些类型的流量需要硬件负载平衡器。 例如，HTTP 流量需要硬件平衡负载器而非 DNS 负载平衡。 DNS 负载平衡对客户端到服务器的 Web 流量不起作用。

如果选择对某个池使用 DNS 负载平衡，但仍需对流量（如 HTTP 流量）实现硬件负载平衡器，则会大大简化硬件负载平衡器的管理。 例如，配置硬件负载平衡器将更简单，因为它仅管理 HTTP 和 HTTPS 流量，而所有其他协议将由 DNS 负载平衡管理。 有关详细信息，请参阅 DNS Load Balancing。

对于服务器到服务器的流量，Skype for Business Server使用拓扑感知负载均衡。 服务器读取中央管理存储中的已发布拓扑以获取拓扑中服务器的 FQDN，并在服务器之间自动分配流量。 管理员不必设置或管理此类型的负载平衡。

如果使用 DNS 负载平衡并且需要阻止至特定计算机的流量，则仅仅删除池 FQDN 中的 IP 地址条目是不够的。 您还必须删除计算机的 DNS 条目。

硬件负载平衡器要求

Skype for Business Server缩放的合并边缘拓扑针对新部署的 DNS 负载均衡进行了优化，这些部署主要使用 Skype for Business Server 或 Lync Server 与其他组织联合。 如果以下任何方案都需要高可用性，则必须在边缘服务器池上使用硬件负载均衡器，以实现以下情况：

  • 与使用 Office Communications Server 2007 R2 或 Office Communications Server 2007 的组织联合

  • 在 Exchange 2010 与 SP1 之前使用 Exchange UM 的远程用户交换 UM

  • 与公共 IM 用户的连接

重要

不支持对一个接口使用 DNS 负载平衡，而对另一个接口使用硬件负载平衡。 必须对两个接口都使用硬件负载平衡，或者对两个接口都使用 DNS 负载平衡。

注意

如果使用硬件负载平衡器，则为内部网络连接部署的负载平衡器必须配置为仅对发往运行访问边缘服务和 A/V 边缘服务的服务器的流量进行负载平衡。 它不能对发往内部 Web 会议边缘服务或内部 XMPP 代理服务的流量进行负载平衡。

注意

Skype for Business Server不支持直接服务器返回 (DSR) NAT。

若要确定硬件负载均衡器是否支持Skype for Business Server所需的必要功能，请参阅用于Skype for Business的基础结构。

运行 A/V 边缘服务的边缘服务器的硬件负载平衡器要求

下面是运行 A/V 边缘服务的边缘服务器的硬件负载均衡器要求：

  • 对内部和外部端口 443 关闭 TCP nagling。 Nagling 是将若干小数据包整合到单个大数据包以提高传输效率的过程。

  • 关闭外部端口范围 50，000 - 59，999 的 TCP 导航。

  • 请不要对内部或外部防火墙使用 NAT。

  • 边缘内部接口必须位于与边缘服务器外部接口不同的网络上，并且必须禁用它们之间的路由。

  • 运行 A/V 边缘服务的边缘服务器的外部接口必须使用可公开路由的 IP 地址，并且在任何边缘外部 IP 地址上不得使用 NAT 或端口转换。

  • 负载平衡器不得更改客户端的源地址。

其他硬件负载均衡器要求

Web 服务的Skype for Business Server大大降低了基于 Cookie 的相关性要求。 如果要部署Skype for Business Server并且不会保留任何 Lync Server 2010 前端服务器或前端池，则不需要基于 Cookie 的持久性。 但是，如果您暂时或永久保留任何 Lync Server 2010 前端服务器或前端池，您仍会在为 Lync Server 2010 部署和配置时使用基于 Cookie 的持久性。

注意

如果您决定使用基于 Cookie 的相关性，但您的部署不需要它，如此做没有任何负面影响。

对于 不使用基于 Cookie 的相关性的部署：

  • 在端口 4443 的反向代理发布规则上，将“转发主机头”设置为 True。 这可确保转发原始 URL。

对于将使用基于 Cookie 的相关性的部署：

  • 在端口 4443 的反向代理发布规则上，将“转发主机头”设置为 True。 这可确保转发原始 URL。

  • 不得将硬件负载平衡器 Cookie 标记为 httpOnly

  • 硬件负载平衡器 Cookie 不得具有过期时间

  • 硬件负载平衡器 Cookie 必须名为 MS-WSMAN（这是 Web 服务预期的值，不能更改）

  • 必须在其传入 HTTP 请求没有 Cookie 的每个 HTTP 响应中设置硬件负载平衡器 Cookie，无论该同一 TCP 连接上的上一个 HTTP 响应是否已获得 Cookie 都是如此。 如果负载平衡器将 Cookie 插入优化为每个 TCP 连接只发生一次，则不得使用该优化

注意

典型的硬件负载均衡器配置使用源地址相关性和 20 分钟。 TCP 会话生存期适合 Lync Server 和 Lync 2013 客户端，因为会话状态是通过客户端使用和/或应用程序交互来维护的。

如果部署移动设备，则您的硬件负载平衡器必须能对 TCP 会话中的单个请求进行负载平衡（实际上，您必须能基于目标 IP 地址对单个请求进行负载平衡）。

谨慎

如果要部署移动设备，则硬件负载均衡器必须能够单独对 TCP 连接中的每个请求进行负载均衡。 最新的 Apple iOS 移动应用程序要求传输层安全性 (TLS) 1.2 版。

谨慎

有关第三方硬件负载均衡器的详细信息，请参阅用于Skype for Business的基础结构。

以下是控制器和前端池 Web 服务的硬件负载平衡器要求：

  • 对于内部 Web 服务 VIP，在硬件负载平衡器上设置 Source_addr 持久性（内部端口 80 和 443）。 对于Skype for Business Server，Source_addr持久性意味着来自单个 IP 地址的多个连接始终发送到一个服务器以保持会话状态。

  • 使用 TCP 空闲超时 1800 秒。

  • 在反向代理与下一跃点池的硬件负载均衡器之间的防火墙上，创建一个规则以允许端口 4443 上的流量从反向代理到硬件负载均衡器。 必须将硬件负载平衡器配置为侦听端口 80、443 和 4443。

硬件负载平衡器关联要求的摘要

客户端/用户位置 外部 Web 服务 FQDN 关联要求 内部 Web 服务 FQDN 关联要求
Lync Web App (内部和外部用户)
移动设备（内部和外部用户）
 无相关性
 源地址相关性
Lync Web App 仅 (外部用户)
移动设备（内部和外部用户）
 无相关性
 源地址相关性
Lync Web App 仅 (内部用户)
移动设备（未部署）
 无相关性
 源地址相关性

硬件负载平衡器的端口监控

在硬件负载平衡器上定义端口监控来确定特定服务何时由于硬件或通信故障而不再可用。 例如，如果前端服务器服务 (RTCSRV) 停止，因为前端服务器或前端池发生故障，则 HLB 监视还应停止接收 Web 服务上的流量。 可在 HLB 上实施端口监控来监控以下各项：

前端服务器用户池 - HLB 内部接口

虚拟 IP/端口 节点端口 节点计算机/监视器 持久性配置文件 注释
<pool>web-int_mco_443_vs
443
 443
 前端
5061
 源
 HTTPS
<pool>web-int_mco_80_vs
80
 80
 前端
5061
 源
 HTTP

前端服务器用户池 - HLB 外部接口

虚拟 IP/端口 节点端口 节点计算机/监视器 持久性配置文件 注释
<池>web_mco_443_vs
443
 4443
 前端
5061
 无
 HTTPS
<池>web_mco_80_vs
80
 8080
 前端
5061
 无
 HTTP

DNS Load Balancing

Skype for Business Server启用 DNS 负载均衡，这是一种软件解决方案，可以大大减少网络上负载均衡的管理开销。 DNS 负载均衡平衡Skype for Business Server特有的网络流量，例如 SIP 流量和媒体流量。

如果部署 DNS 负载均衡，组织的硬件负载均衡器管理开销将降至最低。 此外，将消除与错误配置 SIP 流量的负载均衡器相关的问题的复杂故障排除。 还可以阻止服务器连接，以便使服务器脱机。 DNS 负载均衡还可确保硬件负载均衡器问题不会影响 SIP 流量的元素，例如基本呼叫路由。

下图显示了一个包含内部和外部 DNS 负载均衡的示例：

使用公共 IPv4 地址的边缘网络图

DNS 网络图的示例。

如果使用 DNS 负载均衡，则还可以购买比使用硬件负载均衡器处理所有类型的流量更低的硬件负载均衡器。 应使用已通过互操作性资格测试的负载均衡器Skype for Business Server。 有关负载均衡器互操作性测试的详细信息，请参阅 Lync Server 2010 负载均衡器合作伙伴。 其中的内容适用于Skype for Business Server。

前端池、边缘服务器池、控制器池和独立中介服务器池支持 DNS 负载均衡。

DNS 负载均衡通常在应用程序级别实现。 例如，应用程序 (运行 Skype for Business) 的客户端尝试通过连接到从 DNS A 和 AAAA (返回的 IP 地址之一来连接到池中的服务器，前提是使用 IPv6 寻址) 记录查询来查询池的完全限定域名 (FQDN) 。

例如，如果名为 pool01.contoso.com 的池中有三台前端服务器，则会发生以下情况：

  • 运行Skype for Business运行 DNS 的客户端查询 pool01.contoso.com。 查询返回三个 IP 地址并缓存它们，如下所示 (不一定按以下顺序) ：

    pool01.contoso.com 192.168.10.90

    pool01.contoso.com 192.168.10.91

    pool01.contoso.com 192.168.10.92

  • 客户端尝试建立传输控制协议 (TCP) 连接到其中一个 IP 地址。 如果失败，客户端将尝试缓存中的下一个 IP 地址。

  • 如果 TCP 连接成功，则客户端与 TLS 协商连接到 pool01.contoso.com 上的主注册器。

  • 如果客户端在没有成功连接的情况下尝试所有缓存的条目，则通知用户当前没有运行Skype for Business Server的服务器可用。

注意

基于 DNS 的负载均衡不同于 DNS 轮循机制 (DNS RR) 通常指负载均衡，它依赖于 DNS 来提供与池中的服务器相对应的不同顺序的 IP 地址。 通常，DNS RR 仅启用负载分发，但不启用故障转移。 例如，如果使用 IPv6 寻址) 查询，则与 DNS A 和 AAAA 返回的一个 IP 地址的连接 (失败，则连接将失败。 因此，DNS 轮循机制本身不如基于 DNS 的负载均衡可靠。 可以将 DNS 轮循机制与 DNS 负载均衡结合使用。

DNS 负载均衡用于以下各项：

  • 将服务器到服务器 SIP 负载均衡到边缘服务器

  • 统一通信应用程序服务 (UCAS) 应用程序（例如会议自动助理、响应组和呼叫寄存）进行负载均衡

  • 阻止与 UCAS 应用程序的新连接 (也称为“清空”)

  • 对客户端和边缘服务器之间的所有客户端到服务器流量进行负载均衡

DNS 负载均衡不能用于以下各项：

  • 到控制器或前端服务器的客户端到服务器的 Web 流量

DNS 负载均衡和联合流量：

如果 DNS SRV 查询返回了多个 DNS 记录，则 Access Edge 服务始终选取具有最低数值优先级和最高数值权重的 DNS SRV 记录。 Internet 工程任务组文档“用于指定服务位置的 DNS RR (DNS SRV) ” RFC 2782，DNS SRV RR 指定如果定义了多个 DNS SRV 记录，则首先使用优先级，然后是权重。 例如，DNS SRV 记录 A 的权重为 20，优先级为 40，DNS SRV 记录 B 的权重为 10，优先级为 50。 将选择优先级为 40 的 DNS SRV 记录 A。 以下规则适用于 DNS SRV 记录选择：

  • 首先考虑优先级。 客户端必须尝试联系 DNS SRV 记录定义的目标主机，该记录可以达到的编号最低。 应按权重字段定义的顺序尝试具有相同优先级的目标。

  • 权重字段指定具有相同优先级的条目的相对权重。 较大的权重应按比例获得较高的选择概率。 当没有任何服务器选择时，DNS 管理员应使用权重 0。 如果存在权重大于 0 的记录，则权重为 0 的记录的选择机会应很小。

如果返回多个优先级和权重相等的 DNS SRV 记录，则访问边缘服务将选择先从 DNS 服务器收到的 SRV 记录。

前端池和控制器池上的 DNS 负载均衡

可以对前端池和控制器池上的 SIP 流量使用 DNS 负载均衡。 部署 DNS 负载均衡后，仍需为这些池使用硬件负载均衡器，但仅适用于客户端到服务器的 HTTPS 流量。 硬件负载均衡器用于通过端口 443 和 80 从客户端发出的 HTTPS 流量。

尽管这些池仍需要硬件负载均衡器，但它们的设置和管理将主要用于硬件负载均衡器管理员习惯于的 HTTPS 流量。

DNS 负载均衡和支持较旧的客户端和服务器

DNS 负载均衡仅对运行 Skype for Business Server 或 Lync Server 2010 的服务器以及 Lync 2013 和 Skype for Business 客户端支持自动故障转移。 早期版本的客户端和 Office Communications Server 仍可以连接到运行 DNS 负载均衡的池，但如果它们无法连接到 DNS 负载均衡所引用的第一台服务器，它们将无法故障转移到池中的另一台服务器。

此外，如果使用 Exchange UM，则必须至少使用 Exchange 2010 SP1 才能获得对Skype for Business Server DNS 负载均衡的支持。 如果使用早期版本的 Exchange，则用户将不会为以下 Exchange UM 方案提供故障转移功能：

  • 在手机上播放企业语音邮件

  • 从 Exchange UM 自动助理转移呼叫

所有其他 Exchange UM 方案将正常工作。

在前端池和控制器池上部署 DNS 负载均衡

在前端池和控制器池上部署 DNS 负载均衡需要对 FQDN 和 DNS 记录执行几个额外的步骤。

  • 使用 DNS 负载均衡的池必须有两个 FQDN：由 DNS 负载均衡 (使用的常规池 FQDN（如 pool01.contoso.com) ），解析为池中服务器的物理 IP;另一个 FQDN 用于池的 Web 服务 (（如 web01.contoso.com) ），该 FQDN 解析为池的虚拟 IP 地址。

    在拓扑生成器中，如果要为池部署 DNS 负载均衡，若要为池的 Web 服务创建此额外的 FQDN，则必须在“指定此池的 Web 服务 URL”页中选择“替代内部 Web 服务池 FQDN 检查”框并键入 FQDN。

  • 若要支持 DNS 负载均衡使用的 FQDN，必须预配 DNS 来解析池 FQDN (例如，pool01.contoso.com) 池中所有服务器的 IP 地址 (例如 192.168.1.1、192.168.1.2 等) 。 应仅包括当前部署的服务器 IP 地址。

    谨慎

    如果有多个前端池或前端服务器，外部 Web 服务 FQDN 必须是唯一的。 例如，如果将前端服务器的外部 Web 服务 FQDN 定义为 pool01.contoso.com，则不能对另一个前端池或前端服务器使用 pool01.contoso.com 。 如果同时部署控制器，则为任何控制器或控制器池定义的外部 Web 服务 FQDN 必须不同于任何其他控制器或控制器池以及任何前端池或前端服务器。 如果决定使用自定义 FQDN 替代内部 Web 服务，则每个 FQDN 必须不同于任何其他前端池、控制器或控制器池。

边缘服务器池上的 DNS 负载均衡

可以在边缘服务器池上部署 DNS 负载均衡。 如果这样做，则必须注意一些注意事项。

在以下情况下，在边缘服务器上使用 DNS 负载均衡会导致故障转移能力丧失：

  • 与运行 Lync Server 2010 之前发布的 Skype for Business Server 版本的组织联合。

  • 除了基于 XMPP 的提供商和服务器（如 Google Talk）以外，与公共即时消息 (IM) 服务 AOL 和 Yahoo！ 的用户进行即时消息交换，Google Talk 是目前唯一受支持的 XMPP 合作伙伴。

只要池中的所有边缘服务器都已启动并运行，这些方案就会起作用，但如果一个边缘服务器不可用，则发送到该边缘服务器的任何请求都将失败，而不是路由到另一个边缘服务器。

如果使用 Exchange UM，则必须至少使用 Exchange 2013 才能在 Edge 上获取Skype for Business Server DNS 负载均衡的支持。 如果使用早期版本的 Exchange，则远程用户将不具有以下 Exchange UM 方案的故障转移功能：

  • 在手机上播放企业语音邮件

  • 从 Exchange UM 自动助理转移呼叫

所有其他 Exchange UM 方案将正常工作。

内部边缘接口和外部边缘接口必须使用同一类型的负载平衡。 您不能在一个边缘接口上使用 DNS 负载平衡的同时，在另一个边缘接口上使用硬件负载平衡。

在边缘服务器池上部署 DNS 负载均衡

若要在边缘服务器池的外部接口上部署 DNS 负载均衡，需要以下 DNS 条目：

  • 对于 Access Edge 服务，需要为池中的每个服务器提供一个条目。 每个条目都必须解析 Access Edge 服务的 FQDN (例如，sip.contoso.com) 池中某个边缘服务器上的 Access Edge 服务的 IP 地址。

  • 对于 Web 会议边缘服务，需要为池中的每个服务器提供一个条目。 每个条目都必须解析 Web 会议边缘服务的 FQDN (例如，webconf.contoso.com) 池中某个边缘服务器上的 Web 会议边缘服务的 IP 地址。

  • 对于音频/视频边缘服务，需要为池中的每个服务器提供一个条目。 每个条目都必须解析音频/视频边缘服务的 FQDN (例如，av.contoso.com) 池中某个边缘服务器上的 A/V 边缘服务的 IP 地址。

若要在边缘服务器池的内部接口上部署 DNS 负载均衡，必须添加一条 DNS A 记录，该记录将边缘服务器池的内部 FQDN 解析为池中每个服务器的 IP 地址。

在中介服务器池上使用 DNS 负载均衡

可以在独立中介服务器池上使用 DNS 负载均衡。 所有 SIP 和媒体流量都通过 DNS 负载均衡进行均衡。

若要在中介服务器池上部署 DNS 负载均衡，必须预配 DNS 以解析池 FQDN (例如，mediationpool1.contoso.com) 池中所有服务器的 IP 地址 (例如 192.168.1.1、192.168.1.2 等) 。

使用 DNS 负载均衡阻止流向服务器的流量

如果使用 DNS 负载平衡并且需要阻止至特定计算机的流量，则仅仅删除池 FQDN 中的 IP 地址条目是不够的。 您还必须删除计算机的 DNS 条目。

请注意，对于服务器到服务器的流量，Skype for Business Server使用拓扑感知负载均衡。 服务器读取中央管理存储中的已发布拓扑以获取拓扑中服务器的 FQDN，并在服务器之间自动分配流量。 若要阻止服务器接收服务器到服务器的流量，必须从拓扑中删除该服务器。