思科會議伺服器上的負載平衡邏輯

簡介

本文檔介紹負載均衡白皮書中介紹的思科會議伺服器(CMS)(以前稱為Acano產品)的負載均衡邏輯。本文檔在流程圖中演示此過程，並詳細介紹選擇演算法。

必要條件

需求

思科建議您瞭解以下主題：

• Cisco Meeting Server Call Bridge元件（及其集群）
• Cisco Meeting Server API配置

採用元件

本檔案中的資訊是根據思科會議伺服器2.4.x版。

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。

什麼是CMS的負載均衡演算法？

為了有效利用會議資源，CMS的2.1版引入了負載平衡。它嘗試最小化承載相同空間的呼叫網橋之間的分佈呼叫數量。此機制基於會話發起協定(SIP)中的Replaces報頭，思科統一通訊管理器(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

其中可以看到呼叫網橋組中每個呼叫網橋的替換查詢行，這些查詢行向我們顯示了分為三個部分的負載均衡演算法：

• priority — 該空間的呼叫網橋首選項
• load level — 此時呼叫網橋的負載級別
• 會議正在運行 — 布林值，表示該呼叫網橋上的空間是否處於活動狀態

由於當時沒有呼叫進入系統，因此任何系統都沒有負載（全部為0），並且會議沒有在任何地方運行（全部為0）。在這個方面，最終決定是根據空間的呼叫網橋偏好做出的。優先使用較低優先順序，因此將呼叫替換到名為cluster3的呼叫網橋，如更換呼叫線路所示。

在Call Bridge 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:Call Bridge組中的空間中已有的參與者

在此示例中，空間在呼叫網橋組內已處於活動狀態，因為終結點1060@steven.lab已呼叫到空間，如示例1所示。

此案例中有兩種情況：

1.承載此空間的呼叫網橋的負載低於現有會議閾值，因此能夠接受呼叫。

2.託管此空間的呼叫網橋的負載高於現有會議閾值，因此CMS嘗試將呼叫替換到另一個呼叫網橋。

案例 1.活動空間和負載低於現有會議閾值(80%)

如果呼叫在空間尚未啟用的呼叫網橋上落地，則事件日誌現在顯示空間在名為cluster3的呼叫網橋上處於活動狀態。由於該處的空間處於活動狀態，且該伺服器上的負載低於現有閾值(load level: 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）的呼叫之後檢查了Call Bridge cluster3上的負載，則顯示負載為2000。

假設該呼叫網橋集群3的loadLimit設定為2250（舉個例子），則此呼叫網橋超過現有會議閾值，因為計算公式為0.80 * 2250 = 1800

在這種情況下還有兩種情況需要加以區分。

案例1：組中的多台伺服器的負載仍低於新的會議閾值(50%)

組中的其他兩台伺服器尚未處理任何呼叫，因此負載仍為0，因此它們都可以處理該呼叫。因此，最終決策取決於此空間的呼叫網橋首選項。由於呼叫網橋集群3已滿，因此系統從集群1和集群2（本例中為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)

注意，cluster3 Call Bridge上的負載級別：2表示它超過了現有的會議閾值，因此，即使該空間處於活動狀態，該呼叫也沒有負載均衡到該服務器。相反，它會檢視負載級別為0（表示低於50%的使用率）的其他呼叫網橋的最低空間優先順序，在本例中為cluster1。

案例2：組中只有一個伺服器的負載低於新的會議閾值(50%)或現有會議閾值(80%)

在最後一次呼叫（以及對cluster2的其他空間的呼叫）之後，在呼叫網橋上看到所述負載：

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

現在假設在cluster1呼叫網橋上設定的loadLimit為1300，則此呼叫網橋會超過新的會議閾值，因為計算公式為0.50 * 1300 = 650，並且超過現有會議閾值0.80 * 1300 = 1040。

如果對於同一空間，呼叫網橋cluster3上現在有新的WebRTC呼叫，則該空間在cluster1和cluster3上均處於活動狀態，但兩者都超過了現有的會議閾值，因此它會查詢在新的會議閾值(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會根據在使用者忙線標誌上停止路由的服務引數來停止路由，因此您可能需要更改此設定以允許回退到其他呼叫橋的網關呼叫。