F5針對 SIP應用的負載均衡的一次測試過程

junger

簡介： F5針對 SIP應用的負載均衡 一、 SIP應用負載均衡的背景和功能 SIP( 會話初始協議)的開發(fā)目的是用來幫助提供跨越因特網的高級電話業(yè)務。因特網電話（IP電話）正在向一種正式的商業(yè)電話模式演進，SIP就是用來確保這種 ...
F5針對 SIP應用的負載均衡

一、    SIP應用負載均衡的背景和功能
SIP( 會話初始協議)的開發(fā)目的是用來幫助提供跨越因特網的高級電話業(yè)務。因特網電話（IP電話）正在向一種正式的商業(yè)電話模式演進，SIP就是用來確保這種演進實現而需要的NGN（下一代網絡）系列協議中重要的一員。
SIP是IETF標準進程的一部分，它是在諸如SMTP（簡單郵件傳送協議）和HTTP（超文本傳送協議）基礎之上建立起來的。它用來建立，改變和終止基于IP網絡的用戶間的呼叫。為了提供電話業(yè)務它還需要結合不同的標準和協議：特別是需要確保傳輸（RTP），與當前電話網絡的信令互連，能夠確保語音質量（RSVP），能夠提供目錄（LDAP），能夠鑒權用戶（RADIUS）等等。
SIP被描述為用來生成，修改和終結一個或多個參與者之間的會話。這些會話包括因特網多媒體會議，因特網（或任何IP網絡）電話呼叫和多媒體發(fā)布。會話中的成員能夠通過多播或單播聯系的網絡來通信。SIP支持會話描述，它允許參與者在一組兼容媒體類型上達成一致。它同時通過代理和重定向請求到用戶當前位置來支持用戶移動性。SIP不與任何特定的會議控制協議捆綁。
SIP中有兩個要素：SIP用戶代理（user agent）和SIP網絡服務器（proxy server）。用戶代理是呼叫的終端系統元素，而SIP服務器是處理與多個呼叫相關聯信令的網絡設備。
現有的負載均衡設備通過記憶SIP協議的CALL-ID來區(qū)分進入服務器的SIP訪問，從而實現對SIP用戶代理類的服務器負載均衡。這時，所有的用戶請求均終結在SIP服務器，服務器并不主動對外發(fā)起請求。對于負載均衡設備而言，該種SIP服務器的負載均衡最易實現。本功能在F5公司的BIG-IP 4.5版本就已經實現，且用戶只要簡單的選取SIP 作為persistant持續(xù)性方式就可以實現。
但是， SIP網絡服務器（proxy server）在SIP網絡中卻占絕大多數，且是真正承載網絡負載壓力的服務器，是必須采用服務器集群技術的關鍵要素。而由于SIP proxy server不但要接受用戶請求，同時也會發(fā)起請求，此種雙向數據流的應用幾乎所有的負載均衡設備均無法實現。F5公司考慮到這類雙向數據流的應用的普遍性，在BIG-IP V9版本中提供了超級靈活的iRule（規(guī)則定制）可以比較簡單的實現對SIP網絡服務器（proxy server）的負載均衡，并且可以靈活的支持今后SIP的各類呼叫信息。這也是中外各個移動運營商采用F5公司的BIG-IP作為負載均衡設備的唯一選擇的重要原因。
二、    SIP proxy server的負載均衡
首先，讓我們來看看proxy server在整個傳輸過程中的作用：

如圖所示，PA和PB是SIP網絡中的網絡服務器（proxy server），A和B是兩個終端用戶代理（user agent）�？梢钥闯霎擯A接受來自A的SIP請求后，會再主動發(fā)起向PB的一個SIP請求,該請求得到響應后，PA再回復A的SIP請求。Proxy server PA同時成為SIP服務器端和客戶端。
我們將整個傳送過程按步驟編號如下：



  其中，包含了兩大部分：
1>  作為服務器端，proxy server 響應用戶ewa@id.ethz.ch的請求，步驟1、步驟7和步驟8;
2>  作為客戶端，proxy server 發(fā)起的到sna@ksy112的請求，步驟4、步驟6、步驟9；
其中，步驟1、步驟7和步驟8具有同一個SIP CALL-ID，而步驟4、步驟6、步驟9具有另一個SIP CALL-ID。在單臺proxy server的時候，這兩部分的綁定是不成問題的，但是當中間的proxy是proxy server 集群時，如何保證數據包發(fā)送到同一服務器就成為是否能夠完成proxy server的負載均衡的關鍵了。而其中的關鍵就是負載均衡設備能夠依據CALL-ID，將用戶請求1和遠端服務器響應6區(qū)分開，前者進行必要的負載均衡，而后者必須轉發(fā)到發(fā)出請求4的服務器上。
如圖，是我們此次的測試網絡結構：


為此，我們采用構筑inbound和outbound兩個虛擬服務器分別對應SIP用戶發(fā)起的請求和SIP proxy服務器發(fā)起的請求。
virtual inbound_sip_vs {
   destination 192.168.9.250:5060
   ip protocol udp
   profile my_udp_profile
   pool sip_pool
   rule sipclient
}
這個虛擬服務器對應用戶SIP請求


virtual outbound_sip_vs {
   destination any:5060
   ip protocol udp
   translate service disable
   profile my_udp_profile
   rule sipserver
}
這個虛擬服務器對應proxy server外出的請求


profile udp my_udp_profile {
   defaults from udp
   datagram lb enable
}
pool sip_pool {
   member 10.40.90.234:5060
   member 10.40.90.235:5060
}

UDP數據包采用每個數據包單獨處理的datagram lb負載均衡方式
對于out_sip_vs，我們采用sipserver 規(guī)則來記憶外出的SIP請求③的CALL-ID，這樣當響應返回⑤時，系統將不會進行負載均衡而直接轉發(fā)到原始服務器上。
rule sipserver {
   when CLIENT_DATA {
            if {[scan [UDP::payload] "%s%s" method uri] == 2} {
# 確認獲取SIP協議數據包
                if {[regexp {Call-ID:\s*([^\r\n]+)[\r\n]+} [UDP::payload] -> callid] == 1} {
                        # 截獲SIP數據包內的Call-ID
                        set lll [list $callid any]
                        # 將SIP數據包內的Call-ID賦值給lll
                        set sss [session lookup uie $lll]
            # 查詢服務器外出會話表中是否已有該Call-ID對應的服務器，將其賦于sss
                        if {$sss == ""}  {
                        # 確認服務器外出會話表中無該Call-ID即是新的外出會話
                            session add uie $lll [format "%s:%s" [IP::remote_addr] 5060]
                        # 在服務器外出會話表中添加一行記錄Call-ID和對應的發(fā)起服務器
                        }
                }
            }
         forward
         # 對于服務器外出請求采用路由方式實現轉發(fā)
    }
}

對于inbound_sip_vs，我們采用sipclient規(guī)則來區(qū)分是用戶請求①，還是返回的響應⑤。對于前者我們將采用負載均衡將用戶請求分配到不同的服務器并記憶Call-ID作為persistant持續(xù)性依據保證后續(xù)的請求包被送到同一服務器。而對于前者，我們則直接從服務器外出請求列表中取出原有的發(fā)起服務器，并將數據包直接轉發(fā)到發(fā)起服務器，從而跳過負載均衡。
rule sipclient {
   when CLIENT_DATA {
            if {[scan [UDP::payload] "%s%s" method uri] == 2} {
               # 確認獲取SIP協議數據包
                if {[regexp {Call-ID:\s*([^\r\n]+)[\r\n]+} [UDP::payload] -> callid] == 1} {
                        # 截獲SIP數據包內的Call-ID
                        set lll [list $callid any]
                        # 將SIP數據包內的Call-ID賦值給lll
                        set sss [session lookup uie $lll]
                        # 查詢服務器外出會話表中是否已有該Call-ID對應的服務器
                        set ppp [persist lookup uie $lll]
                        # 查詢持續(xù)性表中是否已有該Call-ID對應的服務器
                        if {$sss != "" && $ppp == ""} {
                            # 發(fā)現是已有的服務器外出會話
                      use pool sip_pool member $sss
                            # 將數據轉發(fā)到發(fā)出請求的服務器上
                        } else {
                      # 確認非服務器主動發(fā)出的外出請求
                            persist uie $callid
                      # 重置計算持續(xù)性時間，采用服務器負載均衡
                        }
                }
            }
    }
}

可以看出，由于iRules具有超強的靈活性，可以完全安裝用戶需求，依據數據包內的任意標識字段進行相應的處理，從而不但可以解決眼前的SIP proxy server的負載均衡問題，也為今后移動應用的特殊需求提供了實現的可能。
在此次SIP測試中，F5的BIG-IP 3400完全滿足了用戶的要求，實現了SIP proxy server集群，為今后提升SIP服務的處理能力提供了可靠的保證。


本文來自ChinaUnix博客，如果查看原文請點：http://blog.chinaunix.net/u1/36243/showart_396181.html

beyond_wyc

可以使用LVS來代替嗎?