YASKAWA服务器显示E72,思科会议服务器上的负载均衡逻辑

简介

本文档介绍Cisco Meeting Server(CMS)(以前称为Acano产品)的负载均衡逻辑，该逻辑在“负载均衡”白皮书中介绍。本文档在流程图中显示此过程，并对选择算法进行更详细的说明。

先决条件

要求

Cisco 建议您了解以下主题：

思科会议服务器呼叫网桥组件(及其集群)

思科会议服务器API配置

使用的组件

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

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

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

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

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

注意：负载均衡逻辑仅适用于到CMS空间的呼叫，因此此时不适用于网关呼叫(P2P呼叫)或双归属呼叫。

负载均衡过程在白皮书的“负载均衡如何使用配置呼叫网桥下的设置来对传入呼叫进行负载均衡”部分中突出显示。它以文本格式显示，并在流程图(下载)中可视化。

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

CB =呼叫网桥

ExistingConferenceLoadLimit = existingConferenceLoadLimitBasisPoints * loadLimit

(默认情况下，existingConferenceLoadLimitBasisPoints等于8000，对应80%)

NewConferenceLoadLimit = newConferenceLoadLimitBasisPoints * loadLimit

(默认情况下，newConferenceLoadLimitBasisPoints等于5000，即50%)

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

如果您的呼叫在最右下方的框中结束，它会将呼叫重定向到优先级最高的服务器。这可以是呼叫网桥服务器本身，也可以是呼叫所在呼叫网桥组中的另一台服务器。如果没有根据负载以及呼叫桥上的空间是否处于活动状态做出任何决定，则会与多个呼叫桥关联。在这种情况下，最终决策基于分配给每个空间的默认呼叫网桥首选项。此呼叫网桥首选项在创建空间时自动分配，并且不可配置，因为它基于多个属性的哈希值。这会导致所有呼叫网桥上不同空间的均匀(随机)分布。

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

负载均衡算法示例

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

对于这些示例，实验设置与由三个呼叫网桥组成的呼叫网桥组配合使用。现有ConferenceLoadLimitBasisPoints和newConferenceLoadLimitBasisPoints配置已设置为其默认值，分别对应于loadLimit值的80%和50%。

要检查特定呼叫网桥上的当前MediaProcessingLoad，可浏览到https://:/api/v1/system/load，并使用图片中显示的API或管理员帐户登录。

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

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

当您向其中一个呼叫网桥(此处为cluster1)发出呼叫时(在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

在中，您可以看到呼叫桥组中每个呼叫桥的替换查询行，这些查询行显示了负载均衡算法，该算法分为三个部分：

priority — 该空间的呼叫网桥首选项

负载级别 — 该呼叫网桥在此时的负载级别

会议正在运行 — 该呼叫网桥上的空间是否处于活动状态的布尔值

由于当时没有呼叫进入系统，因此任何系统(全部为0)都没有负载，并且会议不在任何位置(全部为0)运行。 因此，最终决定是根据空间的呼叫网桥偏好做出的。优先级较低，因此此处将呼叫替换为名为cluster3的呼叫网桥，如替换呼叫线路所示。

在呼叫网桥集群3上，您可以看到指示此替换呼叫的事件日志行(以及它来自哪个呼叫网桥(此处为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'

会议正在运行，首先优先于优先级，因此，如果存在多个候选者的负载级别低于现有会议阈值，则根据优先级值，它将降至呼叫网桥优先级。然而，情况并非如此。

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

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

如果在调用示例1和2(场景1)后检查了呼叫网桥集群3的负载，则显示负载为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)

请注意，负载级别：2在cluster3呼叫网桥上表示它已超过现有会议阈值，因此即使空间处于活动状态，呼叫也未均衡到该服务器。相反，它会查看负载级别为：0(表示低于50%的使用率)，在本例中为cluster1。

第 2 种情况：组中只有一台服务器的负载低于新会议阈值(50%)或现有会议阈值(80%)

在上次呼叫(以及呼叫集群2的其他空间)后，在呼叫网桥上看到描述的负载：

集群1 - 1200

集群2 - 400

集群3 - 4000

现在假设集群1呼叫网桥上设置的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会根据Stop Routing on User Busy Flag的Service Parameter停止路由，因此您可能希望更改此设置，以允许将网关呼叫回退到其他呼叫网桥。