思科会议服务器上的负载平衡逻辑

简介

本文档介绍负载均衡白皮书中介绍的Cisco Meeting Server(CMS)（以前称为Acano产品）的负载均衡逻辑。本文档在流程图中演示此过程，并详细介绍选择算法。

先决条件

要求

Cisco 建议您了解以下主题：

• Cisco Meeting Server Call Bridge组件（及其集群）
• 思科会议服务器API配置

使用的组件

本文档中的信息基于Cisco Meeting Server 2.4.x版本。

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。

什么是CMS的负载均衡算法？

CMS版本2.1中引入了负载均衡，以便有效利用会议资源。它尝试将托管相同空间的呼叫网桥之间的分布呼叫数降至最低。此机制基于会话发起协议(SIP)中的Replaces报头，在Cisco Unified Communications Manager(CUCM)中作为呼叫控制受支持。Expressway版本X8.11（或更高版本）以及CMS版本2.4或更高版本也支持此功能。CMA呼叫（厚客户端和WebRTC类型）可以从CMS版本2.3开始进行负载均衡。

注：目前任何CMS版本都不支持Lync/Skype呼叫的负载均衡，因此此流程图不适用。

注：负载均衡逻辑仅适用于对CMS空间的呼叫，因此不适用于网关呼叫（P2P呼叫）或此时段的双归属呼叫。

负载均衡过程在如何使用配置呼叫网桥下的设置对传入呼叫进行负载均衡部分的白皮书中突出显示。它以文本格式显示，并在此处的流程图（下载）中显示。

流程图使用了一些缩写和术语：

• CB =呼叫网桥
• ExistingConferenceLoadLimit =现有ConferenceLoadLimitBasisPoints * loadLimit
  （默认情况下，现有ConferenceLoadLimitBasisPoints等于8000，相当于80%）
• NewConferenceLoadLimit = newConferenceLoadLimitBasisPoints * loadLimit
  （默认情况下，newConferenceLoadLimitBasisPoints等于5000，相当于50%）

如果引用了MediaProcessingLoad，则会在呼叫到达的特定呼叫网桥上看到它。此负载值可以通过/system/load上的API GET实时验证，并提供此呼叫网桥在该时刻处理的实际负载的表示。

如果呼叫最终位于最右下方的框中，则会将呼叫重定向到具有最高优先级的服务器。这可以是呼叫网桥服务器本身，也可以是呼叫所在呼叫网桥组中的其他服务器。如果无法根据负载和空间在呼叫网桥上是否处于活动状态做出决策，则存在多个呼叫网桥的关联。在这种情况下，最终决策取决于分配给每个空间的默认呼叫网桥首选项。此呼叫网桥首选项是在创建空间时自动分配的，不可配置，因为它基于多个属性的哈希值。这会导致所有呼叫网桥上不同空间的均匀（随机）分布。

要查看特定空间的Call Bridge首选项，您需要在CMS事件日志中验证这一点，如以下示例所示。

负载均衡算法示例

本节包含可能方案的示例，以及呼叫所在的CMS事件日志如何显示流程图中涵盖的负载均衡过程。

对于这些示例，实验设置用于包含三个呼叫网桥的呼叫网桥组。existingConferenceLoadLimitBasisPoints和newConferenceLoadLimitBasisPoints配置已设置为默认值，分别对应于loadLimit值的80%和50%。

要检查特定呼叫网桥上的当前MediaProcessingLoad，您可以浏览到https://<ip-or-fqdn-of-callbridge>:<webadmin-port>/api/v1/system/load，然后使用图片中显示的API或管理员帐户登录。

示例1：任何呼叫网桥均无负载

在本示例中，任何呼叫网桥都没有激活的呼叫。因此，所有服务器的MediaProcessingLoad等于零。

当您呼叫其中一个呼叫网桥（此处为集群1）（在CMS和呼叫控制设备上启用了负载均衡）时，您会看到呼叫到达的呼叫网桥上的事件日志：

2018-12-29  10:51:29.490  Info     call 75: incoming SIP call from "sip:1060@steven.lab" to local URI "sip:stejanss.space@cluster.steven.lab"
2018-12-29  10:51:29.565  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster1' (priority: 1, load level: 0, conference is running: 0)
2018-12-29  10:51:29.712  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster2' (priority: 2, load level: 0, conference is running: 0)
2018-12-29  10:51:29.717  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster3' (priority: 0, load level: 0, conference is running: 0)
2018-12-29  10:51:29.717  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: using remote server 'cluster3' (priority: 0, load level: 0, conference is running: 0)
2018-12-29  10:51:29.717  Info     replacing call 'f8eeea46e0f0790a@10.10.50.13' to conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93 on server 'cluster3'
2018-12-29  10:51:29.876  Info     call 75: ending; remote SIP cancel (remote cancel) - not connected after 0:00

其中您可以看到呼叫网桥组中每个呼叫网桥的replace查询行，它向我们显示了分为三个部分的负载均衡算法：

• priority — 该空间的呼叫网桥首选项
• load level — 此时呼叫网桥的负载级别
• 会议正在运行 — 该呼叫网桥上的空间是否处于活动状态的布尔值

由于当时没有呼叫进入系统，因此任何系统都不会产生负载（全部为0），并且会议不会在任何地方运行（全部为0）。在这方面，最终决定取决于空间的呼叫网桥首选项。优先选择较低的优先级，因此呼叫被替换到名为cluster3的呼叫网桥，正如替换呼叫线路所见的。

在呼叫网桥cluster3上，您可以看到指示此替换呼叫的事件日志行（以及呼叫网桥来自哪个呼叫网桥（此处为cluster1），以及相同的会议ID和呼叫ID）：

2018-12-29  10:51:29.784  Info     replacing call 'f8eeea46e0f0790a@10.10.50.13' from server 'cluster1' into conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93
2018-12-29  10:51:29.787  Info     call 193: outgoing SIP call to "1060@steven.lab" from space "Steven Janssens's space"
2018-12-29  10:51:29.792  Info     call 193: setting up UDT RTP session for DTLS (combined media and control)
2018-12-29  10:51:29.909  Info     call 193: compensating for far end not matching payload types
2018-12-29  10:51:29.911  Info     participant "1060@steven.lab" joined space bc218bfb-3bda-44f6-89a7-80d8dd616a80 (Steven Janssens's space)

如果呼叫已在优先级值最低的呼叫网桥上着陆（此处为cluster3，表示此空间），则您仍然可以在事件日志中看到相同的替换查询行，但它现在指示它使用本地服务器，且没有替换呼叫行：

2018-12-29  11:05:25.202  Info     call 194: incoming SIP call from "sip:1060@steven.lab" to local URI "sip:stejanss.space@cluster.steven.lab"
2018-12-29  11:05:25.233  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster3' (priority: 0, load level: 0, conference is running: 0)
2018-12-29  11:05:25.376  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster2' (priority: 2, load level: 0, conference is running: 0)
2018-12-29  11:05:25.378  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster1' (priority: 1, load level: 0, conference is running: 0)
2018-12-29  11:05:25.378  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: using local server 'cluster3' (priority: 0, load level: 0, conference is running: 0)
2018-12-29  11:05:25.380  Info     call 194: setting up UDT RTP session for DTLS (combined media and control)
2018-12-29  11:05:25.404  Info     participant "1060@steven.lab" joined space bc218bfb-3bda-44f6-89a7-80d8dd616a80 (Steven Janssens's space)

示例2：呼叫网桥组中已有空间的参与者

在本示例中，由于端点1060@steven.lab被调入空间（如示例1所示），该空间在呼叫网桥组内已处于活动状态。

这种情况下有两种情况：

1.承载此空间的呼叫网桥的负载低于现有会议阈值，因此可以接受呼叫。

2.承载此空间的呼叫网桥的负载高于现有会议阈值，因此CMS尝试将呼叫替换到另一个呼叫网桥。

场景 1.活动空间和负载低于现有会议阈值(80%)

如果呼叫落到空间尚未激活的呼叫网桥上，则事件日志现在显示空间在名为cluster3的呼叫网桥上处于活动状态。由于该服务器上存在活动空间且负载低于现有阈值(负载级别：0),因此会替换该呼叫。

2018-12-29  11:48:17.419  Info     call 82: incoming SIP call from "sip:800999@steven.lab" to local URI "sip:stejanss.space@cluster.steven.lab"
2018-12-29  11:48:17.477  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster1' (priority: 1, load level: 0, conference is running: 0)
2018-12-29  11:48:17.607  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster2' (priority: 2, load level: 0, conference is running: 0)
2018-12-29  11:48:17.607  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster3' (priority: 0, load level: 0, conference is running: 1)
2018-12-29  11:48:17.607  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: using remote server 'cluster3' (priority: 0, load level: 0, conference is running: 1)
2018-12-29  11:48:17.607  Info     replacing call '4c28197eaebba178@10.10.2.250' to conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93 on server 'cluster3'

正在运行的会议首先优先于优先级，因此，如果存在多个负荷级别低于现有会议阈值的候选人，则会议会根据优先级值降到Call Bridge首选项。然而，这里的情况并非如此。

场景 2：活动空间和负载高于现有会议阈值(80%)

在这种情况下，呼叫不替换为该呼叫网桥，而是在该组内查找另一个仍有可用资源的呼叫网桥。首先，它会检查是否存在负载低于50%（新会议阈值）的呼叫网桥，并首先加载这些呼叫网桥。如果此阈值下没有任何可用会议，则检查是否存在低于80%（现有会议阈值）的可用会议。

如果在示例1和2（场景1）的调用之后检查呼叫网桥cluster3上的负载，则显示负载2000。

假设，该呼叫网桥集群3的loadLimit设置为2250（举个例子），则此呼叫网桥超过现有会议阈值，因为计算公式为0.80 * 2250 = 1800

在这种情况下，有两种情况仍有待区分。

案例1：组中的多台服务器的负载仍低于新的会议阈值(50%)

组中的其他两台服务器尚未处理任何呼叫，因此负载仍为0，因此它们都可以处理该呼叫。因此，最终决策基于此空间的呼叫网桥首选项。由于呼叫网桥cluster3已满，因此系统从cluster1和cluster2（本例中为cluster1）中选择最低优先级。

2018-12-29  12:11:03.211  Info     call 86: incoming encrypted SIP audio call from "sip:2001@steven.lab" to local URI "sip:stejanss.space@cluster.steven.lab"
2018-12-29  12:11:03.263  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster1' (priority: 1, load level: 0, conference is running: 0)
2018-12-29  12:11:03.405  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster2' (priority: 2, load level: 0, conference is running: 0)
2018-12-29  12:11:03.412  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster3' (priority: 0, load level: 2, conference is running: 1)
2018-12-29  12:11:03.412  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: using local server 'cluster1' (priority: 1, load level: 0, conference is running: 0)
2018-12-29  12:11:03.415  Info     call 86: setting up UDT RTP session for DTLS (combined media and control)
2018-12-29  12:11:03.434  Info     participant "2001@steven.lab" joined space bc218bfb-3bda-44f6-89a7-80d8dd616a80 (Steven Janssens's space)

请注意，load level:2 on the cluster3 Call Bridge表示它超过了现有会议阈值，因此即使该空间处于活动状态，呼叫也不会负载均衡到该服务器。相反，它会查看负载级别为0（表示低于50%的使用率）的其他呼叫网桥的最低空间优先级，在本例中为cluster1。

案例2：组中只有一个服务器的负载低于新的会议阈值(50%)或现有会议阈值(80%)

在最后一次呼叫（以及对cluster2的其他空间的呼叫）后，在呼叫网桥上看到所述负载：

• 集群1 - 1200
• 集群2 - 400
• 集群3 - 4000

假设现在在cluster1呼叫网桥上设置的loadLimit为1300，则此呼叫网桥超过新的会议阈值，因为计算值是0.50 * 1300 = 650，并且超过现有会议阈值0.80 * 1300 = 1040。

如果现在呼叫网桥集群3上针对同一空间有新的WebRTC呼叫，则空间在集群1和集群3上均处于活动状态，但两者均超过现有会议阈值，因此它会查找位于新会议阈值(50%)或现有会议阈值(80%)下的其他服务器。在这种情况下，只有cluster2仍将处于现有会议阈值之下，但由于对cluster2呼叫网桥上处理的另一个空间的另一个呼叫，它已超过新的会议阈值。

2018-12-29  12:45:33.162  Info     instantiating user "guest1685904798@cluster.steven.lab"
2018-12-29  12:45:33.162  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster3' (priority: 0, load level: 2, conference is running: 1)
2018-12-29  12:45:33.299  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster1' (priority: 1, load level: 2, conference is running: 1)
2018-12-29  12:45:33.299  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster2' (priority: 2, load level: 1, conference is running: 0)
2018-12-29  12:45:33.299  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: using remote server 'cluster2' (priority: 2, load level: 1, conference is running: 0)

Cluster2在此已设置loadLimit值为600。400作为新呼叫进入之前的当前负载，它超过了新的会议阈值0.5 * 600 = 300，但它仍然低于现有会议限制0.8 * 600 = 480。因此，在替换查询中，这显示为负载级别：1（当呼叫网桥超过80%阈值时，而不是2）。

示例3：在现有会议阈值之上的呼叫网桥上登陆

在这种情况下，负载均衡算法不会发生，因为最好向呼叫控制设备发送488响应，然后该设备可以决定尝试将呼叫路由到组内的不同呼叫网桥（可能在80%限制之下），或者甚至当当前组资源耗尽时将其路由到不同的呼叫网桥组（作为回退选项）。

事件日志不会明确显示此部分的详细信息，因为它只是报告超出容量限制：

2018-12-29  12:49:13.352  Info     call 88: incoming encrypted SIP call from "sip:2020@steven.lab" to local URI "sip:stejanss.space@cluster.steven.lab"
2018-12-29  12:49:13.399  Info     call 88: ending; local teardown, system participant limit reached - not connected after 0:00

一旦呼叫被发送到可以处理负载的不同呼叫网桥（例如cluster2），系统将显示相同的负载均衡算法：

2018-12-29  12:49:13.434  Info     call 624: incoming encrypted SIP call from "sip:2020@steven.lab" to local URI "sip:stejanss.space@cluster.steven.lab"
2018-12-29  12:49:13.475  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster2' (priority: 2, load level: 1, conference is running: 0)
2018-12-29  12:49:13.614  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster3' (priority: 0, load level: 2, conference is running: 1)
2018-12-29  12:49:13.614  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: using local server 'cluster2' (priority: 2, load level: 1, conference is running: 0)
2018-12-29  12:49:13.618  Info     call 624: setting up UDT RTP session for DTLS (combined media and control)
2018-12-29  12:49:13.621  Info     call 624: starting DTLS UDT media negotiation (as initiator)
2018-12-29  12:49:13.640  Info     participant "2020@steven.lab" joined space bc218bfb-3bda-44f6-89a7-80d8dd616a80 (Steven Janssens's space)

注：对于网关呼叫，CMS将返回486 SIP错误消息。默认情况下，CUCM会根据在用户忙标志上停止路由的服务参数停止路由，因此您可能要更改此设置以允许回退到其他呼叫桥的网关呼叫。