
此圖例及以下圖例均來自于互聯(lián)網資源
作為運營商級通信系統(tǒng)或者企業(yè)級的通信系統(tǒng),OpenSIPS和Kamailio在市場上有很多的部署案例。它們可以作為媒體服務器的前端服務器實現很多的信令和會話路由功能。均衡負載是它們其中一個重要的功能。今天,筆者針對基于以上兩種開源SIP軟交換通過SIP信令方面的均衡負載以及其新的三種算法優(yōu)化做一些分享。
大家可能知道,因為這些開源項目本身不是B2BUA,即使OpenSIPS的B2BUA模塊也僅能實現基礎的RTP媒體處理,這些開源的SIP服務器可以作為一個簡單的SBC。因為它們缺乏媒體服務器的支持能力,需要借助第三方來構建RTP媒體處理能力來實現SBC的“部分功能”。但是,如果用戶真正完全實現商業(yè)化部署仍然需要一個完整的SBC解決方案來,SBC還需要強大的媒體處理能力滿足現在實時語音通信的要求。因此,SBC除了實現SIP呼叫信令本身的均衡負載,還要支持很多用戶需要的通過語音質量分析QoS/MOS/PDD實現的智能語音路由功能。最終,一個完整的均衡負載機制,不僅僅支持對呼叫本身的均衡負載處理,而且結合RTP媒體語音智能路由才能實現一個全功能完整的基于SIP均衡負載解決方案。
筆者在以下章節(jié)中將重點介紹基于開源SIP服務器Kamailio/OpenSIPS的均衡負載的默認輪詢算法和其局限性,并且分享研究人員發(fā)表的關于均衡負載三種新算法(Call-Join-Shortest-Queue,Transaction-Join-Shortest-Queue 和Transaction-Least-Work-Left )的優(yōu)缺點以及其測試結果分享,最后分享關于SBC均衡負載解決方案中使用SIP呼叫信令均衡負載結合語音分析智能路由的思路。
1關于均衡負載的基本說明
這里,筆者首先介紹一些關于均衡負載的早期算法和一些基于業(yè)務層面的負載的說明,使讀者能夠了解其他后續(xù)章節(jié)的討論。從一般意義來說,均衡負載主要是針對呼叫數量做均衡處理,確保呼叫發(fā)起方和呼叫接收方之間的呼叫能夠通過不同負載服務器之間的資源平衡,保證平臺負荷在一個合理的承受范圍之內,維持呼叫和平臺的穩(wěn)定性。SIP均衡負載包括開源SIP軟交換基本上使用以下四種均衡負載的處理方式:
- Hash 和 FNVHash-通過hash的靜態(tài)處理方式對Call-ID進行存儲,對新事務綁定的Call-ID進行計算然后進行均衡負載處理。早期的OpenSER采用的這種算法。
- Round Robin(輪詢)-通過hash算法對呼叫進行均衡負載的話,很難保證同樣數量的呼叫那個路由到相關的服務器端。輪詢方式基本上可以實現對呼叫進行輪詢路由的均衡處理。第一個呼叫路由到第一個服務器節(jié)點,第二個呼叫會路由到下一個節(jié)點服務器,上一個呼叫和下一個呼叫不會同時出現在同一服務器,基本上保證了負載的均衡處理。
- 峰值路由方式-此算法是一種靜態(tài)的算法,根據系統(tǒng)資源和負載的設置策略,設定一個閥值,如果超過閥值則路由到其他的服務器。目前,OpenSIPS也可以實現類似的設置。
- Response-time Weighted Moving Average(RWMA),此算法和前面的處理方式完全不同,它是一種動態(tài)的算法。RWMA算法是根據服務器端收到的響應時間,然后根據平均響應時間進行加權處理,基本上保證每個服務器的負載均衡。
在實際應用場景中,SIP服務器的均衡負載可能需要承擔更多的業(yè)務層面的均衡負載能力。SIP服務器均衡負載能力可以支持:
- 根據呼叫業(yè)務實現負載實現緊急呼叫,電話會議,視頻會議還是一般呼叫的負載路由
- 根據媒體類型不同實現負載支持是否需要媒體轉碼,落地,根據QoS路由負載等
- 根據路由策略實現負載支持國際/國內,計費閥值,VIP線路,系統(tǒng)資源閥值等
基于以上業(yè)務層面的均衡負載的實踐,關于基本的開源SIP服務器中均衡負載的概念和配置方式,讀者可以參考:
OpenSIPS學習筆記-負載均衡模塊概要,示例配置,會議服務器部署面對的挑戰(zhàn),LB選擇資源的4個邏輯流程詳解
OpenSIPS學習筆記-dispatcher調度模塊概要-失效呼叫處理邏輯及示例演示
在基于SIP服務器端使用均衡負載模塊處理SIP請求時,一般用戶都使用默認的服務器本身的模塊來處理,也有一些非常專業(yè)的用戶需要對服務器進行更多優(yōu)化以達到更高的性能來滿足業(yè)務需求。所以,他們可能對某些算法進行優(yōu)化。在SIP均衡負載的處理中,均衡負載策略算法是一個非常核心的處理流程,它的算法是否能夠應對非常靈活的處理環(huán)境是決定SIP服務器性能的一個重要指標。
開源SIP服務器Kamalio或者OpenSIPS的官方說明中,它們一般使用吞吐量來說明其執(zhí)行性能,例如CPS等。除了CPS以外,響應時間也是非常重要的性能指標,響應時間也可以作為衡量性能的技術指標。運營商級客戶對各種響應時間有專門的KPI指標考核參數。關于各種響應時間的討論讀者可以參考:
完整RFC6076-端對端SIP網絡九大性能評價指標(KPI)概論和時延產生其他因素的相關性討論
在關于吞吐量處理方面,除了數據庫存儲,系統(tǒng)物理資源和模塊設置優(yōu)化以外,均衡負載的算法也決定著吞吐量的指標。在接下來,筆者會根據一些研究人員針對開源SIP服務器的均衡負載算法的優(yōu)化和改進對吞吐量和響應時間的測試結果做更多分享。
2基于開源SIP軟交換的均衡負載算法討論
如果我們要討論SIP呼叫的均衡負載,我們首先需要了解SIP呼叫的相關基本概念。讀者可能都知道,SIP呼叫是基于會話處理流程的。一個整個完整的呼叫是通過INVITE發(fā)起,呼叫需要經過多種流程進行處理,包括認證簽權,查詢,更新定時器等,然后通過BYE來拆線,最后結束呼叫。在一個完整的正常呼叫中,INVITE事務和BYE事務是兩個最重要的事務。另外,因為發(fā)起一個INVITE呼叫流程,其處理過程會占用上面所說的很多資源。因此,INVITE事務和BYE的事務類型所消耗的資源是完全不同的。在整個呼叫的資源占用比中,INVITE事務處理所需要的資源占比超過了70%, BYE事務占比則很少。研究人員的基本原則是優(yōu)化一個正常的SIP呼叫中的事務流程,主要針對INVITE事務和BYE事務處理的流程進行均衡負載優(yōu)化。在具體的算法優(yōu)化討論中,一個SIP呼叫需要針對call,dialog,會話和事務等方面的優(yōu)化處理。因此,SIP均衡負載算法優(yōu)化的基本設計原則就是通過優(yōu)化INVITE事務的處理流程,增加系統(tǒng)的吞吐量,并且盡可能地降低響應時間,以達到系統(tǒng)的最佳處理能力。必須說明,在討論這些新的算法之前,讀者必須對我們討論的問題做基本了解,包括call,dialog,會話和事務概念等。如果讀者需要了解更多關于call,dialog和Transaction的詳解的話,可以參考以下文章:
再論SIP呼叫中的Call,Dialog和Transaction

針對SIP服務器的均衡負載策略或者算法來說,目前使用比較多的包括Round Robin-RR, Call-Join-Shortest-Queue(CJSQ),Transaction-Join-Shortest-Queue (TJSQ)和Transaction-Least-Work-Left (TLWL)。在以上算法中,第一種是kamailio和OpenSIPS默認支持的算法,以上后三種算法是Hongbo Jiang 針對Kamailio默認算法基礎上中提出三種新的算法。這里補充說明,因為早期的Kamailio還是OpenSIPS,它們的均衡負載的處理機制基本上相同,因此,筆者在本文章的后續(xù)章節(jié)中不再區(qū)分Kamailio還是OpenSIPS環(huán)境下的LB均衡負載模塊。
在針對開源SIP服務器的LB模塊的優(yōu)化方面,最近幾年OpenSIPS做了相對比較多的優(yōu)化和更新,增加了很多動態(tài)實時的處理流程,整體處理性能可能有比較大的提升。關于OpenSIPS最新的處理流程的介紹,建議讀者參考以上鏈接或者參考官方文檔。這里,我們主要針對Hongbo Jiang和IBM研究院研究人員針對均衡負載中算法策略的優(yōu)化進行討論。以下圖例是研究人員的算法框架。

SIP服務器均衡負載算法架構
基于開源SIP軟交換中,SIP均衡負載的四種算法的具體定義和各自的特點包括:
Round Robin-RR,按照輪詢方式對新呼叫進行分配。Kamailio或OpenSIPS默認支持的輪詢方式。筆者建議讀者參考官方文檔獲得更多關于RR算法和使用方式的說明。
Call-Join-Shortest-Queue(CJSQ),記錄跟蹤所有呼叫(call或者session),分配所有呼叫到每個后臺服務器,并且路由新呼叫到最少活動呼叫的節(jié)點服務器。此算法僅關注到了call或session級別的數據優(yōu)化,它本身無法對一個呼叫的transaction 事務進行更多細節(jié)處理。
Transaction-Join-Shortest-Queue (TJSQ),路由新呼叫到SIP服務器,并且此服務器目前具有最少活動事務(Transaction),而不是最少呼叫(call/session)。此算法就是對CJSQ算法的提升優(yōu)化,通過對一個SIP呼叫的INVITE事務和BYE事務進行分解,結合各種呼叫變量進一步優(yōu)化其均衡負載算法。它仍然有其缺點。因為INVITE事務進入狀態(tài)機的處理流程和非INVITE事務進入狀態(tài)機的流程的復雜程度不同,所以它們所消耗的資源也完全不同,缺乏對資源比例消耗的進一步控制和處理。關于事務處理的流程和非INVITE狀態(tài)機等處理策略,讀者參考RFC3261-17。
Transaction-Least-Work-Left (TLWL),此算法路由新的SIP呼叫到一個服務器,此SIP服務器目前承擔最小工作負載,此負載是基于相關事務交互成本計算的結果,通過此結果進行呼叫路由。此說法利用了INVITE事務比BYE事務處理成本相對比較高的基本原理,進行資源分配就是而來。在此研究報告中,INVITE事務和BYE事務之間的成本比例是1.75:1時, 這樣會取得服務器性能的最佳峰值。以下是研究人員的技術架構實例圖和相關系統(tǒng)軟硬件配置。

測試環(huán)境配置

研究人員在2012年發(fā)布的論文中,使用開源壓力測試工具SIPp和通過對開源SIP服務器OpenSER(Kamailio和OpenSIPS的早期版本)添加了三種算法功能,使用硬件設備,通過配置集群服務器方式針對四種均衡負載算法進行了針對SIP均衡負載吞吐量(CPS)和響應時間的測試。在其測試結果中,無論從SIP服務器的吞吐量,響應時間和相關網絡,CPU資源消耗來說,TLWL的算法無疑是幾種算法中的一種最佳的算法。

各種算法測試中的峰值吞吐量結果

各種算法中針對INVITE事務處理的平均響應時間結果

各種算法中針對BYE事務處理的平均響應時間結果
Abdullah Akbar也進行了同樣的研究測試,他/她使用Kamailio對以上算法進行了測試對比試驗。其基礎平臺使用Kamailio,并且對dispatcher 調度模塊進行了修改,使用以上算法結合SIPp壓力測試工具進行了測試。測試架構和其使用的硬件環(huán)境包括:


各種算法環(huán)境中的SIP服務器的吞吐量對比,TLWL結果最高。

各種算法環(huán)境下的BYE消息響應時間對比中,TLWL響應時間最低。

通過以上兩個研究團隊針對開源SIP軟交換的測試結果來看,TLWL的均衡負載結果對比其他負載算法來說,整體測試性能是最好的。這里我們需要說明,雖然當時兩個研究團隊在測試部署時使用的環(huán)境包括硬件環(huán)境和今天相比已經有很大變化,網絡環(huán)境和云計算的網絡功能虛擬化也不斷應用在SIP網絡的場景中,很多集群部署的優(yōu)化和網絡優(yōu)化可以幫助提升SIP均衡負載的處理能力,但是對SIP呼叫中的會話,事務等基本要素的優(yōu)化確實為我們提供了非常有價值的參考,為大家提供了更多的關于SIP軟交換性能處理的新的思路。關于三種算法的具體介紹和研究手段等論文細節(jié),讀者可以查看參考資料的說明。
不過,隨著更多網絡技術的不斷發(fā)展,業(yè)務系統(tǒng)的需求和場景不斷發(fā)生變化,在SIP均衡負載的各種方案中,越來越多的用戶希望通過SBC來實現均衡負載來滿足不同業(yè)務,靈活語音編碼和邏輯處理的需求。在下一個章節(jié),我們簡單介紹如何通過SBC實現均衡負載,實現真正的商業(yè)場景的部署。
3基于云計算和SBC的均衡負載擴展能力示例說明
在以上的討論中,研究人員更多關注的是基于SIP 軟交換信令級均衡負載的算法優(yōu)化,也僅限于傳統(tǒng)CTI環(huán)境和硬件網絡環(huán)境。在現在實際應用場景中,無論是運營商級用戶還是企業(yè)終端用戶,大家都在考慮通過云計算和網絡虛擬化的方式實現更多更靈活的分布式網絡架構,并且需要滿足用戶更多終端和不同編碼設備的支持。在基于SIP軟交換的均衡負載的部署環(huán)境中,除了我們需要關心SIP軟交換的吞吐量和響應時間以外,我們還要注冊請求的均衡負載,安全加密處理,還要關注其他媒體方面的用戶體驗,例如語音質量,時延等問題。如果我們僅僅考慮基于SIP軟交換信令點均衡負載的話,均衡負載的功能支持就會遇到很大限制,不能滿足很多實時的業(yè)務場景。
比較幸運的是,云計算時代,很多技術已經彌補了以前的一些系統(tǒng)資源的制約,可以通過SD-WAN,網絡功能虛擬化部署,云實例部署和彈性網絡資源等方式來實現。具體關于針對SIP網絡的技術架構的變革,讀者可以閱讀歷史文章:
SBC的核心功能之一就是實現SIP媒體服務器的均衡負載處理。一些SBC廠家的SBC均衡負載功能已經非常成熟。Ribbon/Sonus的SBC 均衡負載服務能力提供了非常專業(yè)的運營商級功能,可以通過SIP呼叫和DNS(參考RFC3263)服務方式實現均衡負載,并且它可以通過云平臺的各種功能模塊,實現SBC 均衡負載集群組。

在SBC均衡負載集群的處理方式中,除了針對CPS進行動態(tài)路由以外,它本身也可以實現靈活動態(tài)加載各個節(jié)點服務器,對所有節(jié)點SBC實例實現分布式部署響應,并且可以針對重新加入的INVITE或者注冊請求路由到未使用的SBC節(jié)點。
除了針對SIP呼叫信令級的均衡負載的管理以外,SBC仍然需要針對媒體級的核心數據實時進行檢測和管理,保證用戶呼叫的語音質量達到最佳質量。通過SBC實現QoS/MOS的智能路由也是SBC部署時的一個特別需要考慮的問題。筆者以前針對QoS的策略管理有非常詳細說明,讀者可以閱讀此文章:

在運營商級和高級的企業(yè)級SIP呼叫均衡負載的解決方案中,除了對CPS和響應時間進行管理以外,SBC的均衡負載功能還需要結合實時語音質量分析的參數來實現更完善的路由處理。SBC需要非常智能化地分析RTP語音流的修改數據,通過QoS這里保障,語音質量評價值和呼叫延遲,抖動等相關數據及時通知SBC路由模塊,保障其均衡負載能力能夠路由到一個資源消耗狀態(tài)正常的媒體服務器上。如果缺乏以上分析數據的支持,均衡負載處理機制仍然會路由到一個語音質量差的呼叫節(jié)點上,最終用戶呼叫體驗肯定也非常差,降低了呼叫的成功率和呼叫體驗。Ribbon SBC通過語音智能語音分析模塊,結合實時數據統(tǒng)計面板對智能路由做了非常專業(yè)的實時管理,可以極大提高均衡負載以及智能路由的更強大的功能。PSX是核心的路由策略模塊,可以支持本地路由,全球路由管理,trunk管理,安全保護數據,DID管理,分析軟件依賴于大數據,AI和行為學習和機器學習來快速分析數據支持均衡負載能力。
4總結
在本文章中,筆者首先介紹了關于均衡負載的基本要求和基于業(yè)務層面均衡負載的處理機制。開源SIP軟交換Kamailio和OpenSIPS,包括早期的OpenSER在這方面也有著非常好的表現,它們可以作為SIP軟交換的均衡負載服務器來使用。在傳統(tǒng)的均衡負載的RR模塊中,均衡負載僅針對呼叫或者會話來進行處理,沒有再深入到呼叫事務的優(yōu)化,特別是針對兩個重要的INVITE事務和BYE事務的優(yōu)化。一些研究人員針對兩種事務進行了優(yōu)化處理,并且提供了三種優(yōu)化算法,通過不同優(yōu)化算法,研究人員經過對吞吐量和響應時間的測試發(fā)現TLWL算法是執(zhí)行性能最好的算法。這些新優(yōu)化的算法為大家在未來的基于SIP服務器進行優(yōu)化提供了非常有深度的技術模型。
但是,隨著技術不斷發(fā)展,用戶需求不斷增加,這些均衡負載的部署方式如果部署在目前商業(yè)環(huán)境的話,仍然缺乏很多其他業(yè)務方面的支持,仍然需要一些專業(yè)的SBC做均衡負載,以及均衡負載集群組來實現,并且需要結合用戶迫切需要的實時語音檢測機制進行更智能化路由。筆者在后續(xù)章節(jié)介紹了Ribbon SBC在建議SIP信令層面的均衡負載機制路由以外,和讀者分享了基于RTP語音流的智能路由功能,通過QoS,MOS和PDD等比較重要的參數數值,通過語音分析模塊實時對呼叫進行路由設置。
隨著系統(tǒng)不斷擴容,SIP服務器的均衡負載機制和算法也不斷需要更新來滿足最新的業(yè)務需求。其他的算法或者均衡負載機制也可能可以實現某種用戶場景,比如,利用云平臺技術,HAProxy或DNS SRV等相關技術來實現不同的需求均衡負載或者HA解決方案,因為篇幅關系,筆者沒有涉及這方面的討論。筆者希望從單純的SIP技術方面,結合所討論的這些結果對讀者將來部署SIP均衡負載解決方案有所幫助,獲得更穩(wěn)定專業(yè)的均衡負載解決方案。
參考資料:
- https://support.sonus.net/display/SBXDOC62/Load+Balancing+Service
- www.rbbn.cn
- www.hiastar.com
Hongbo Jiang,Design, Implementation, and Performance of A Load Balancer for SIP Server Clusters
Abdullah Akbar,A Comparative Study on Load Balancing Algorithms for SIP Servers
Georgios,Towards effective SIP load Balancing
- https://datatracker.ietf.org/doc/html/rfc3263
- https://www.opensips.org/Documentation/Tutorials-LoadBalancing
- https://kamailio.org/docs/modules/4.3.x/modules/dispatcher.html