專利名稱：一種服務器負載均衡方法、裝置及系統的制作方法
—種服務器負載均衡方法、裝置及系統技術領域
本申請涉及負載均衡技術，特別是涉及一種服務器負載均衡方法、裝置及系統。
背景技術：
在互聯網應用技術中，負載均衡一直是熱門話題，LVS負載均衡是其中的一種負載均衡技術。LVS的英文全稱是Linux Virtual Server,即Linux虛擬服務器。LVS主要用于多服務器的負載均衡，工作在網絡層，可以實現高性能、高可用的服務器集群技術。
LVS負載均衡的系統結構如圖1所示，主要包括客戶端(Client)、虛擬服務器 (LVS)和真實服務器(Real Server，簡稱RS)。其中，LVS最主要的功能是提供包轉發和負載均衡，LVS通過虛擬一個對外訪問的IP(Vip)，當用戶訪問vip時到達LVS，LVS根據一定的規則選擇一個RS，RS處理完成后返回給客戶端數據。
LVS目前支持VS/DR、VS/ΝΑΤ和VS/TUN三種工作模式。
VS/DR (Virtual Server via Direct Routing),即通過直接路由技術實現虛擬服務器。VS/DR通過改寫請求報文的MAC地址，將請求發送到RS，而RS將響應直接返回給客戶。
VS/NAT (Virtual Server via Network Address Translation),即通過網絡地址轉換技術實現虛擬服務器。當請求來到時，VS/ΝΑΤ將數據報文中的目標地址(即虛擬IP地址vip)改成具體的某臺RS，端口也改成RS的端口，然后把報文發給RS。RS處理完數據后， 需要返回給VS/NAT，然后VS/ΝΑΤ將數據包中的源地址和源端口改成vip的地址和端口，最后把數據發送出去。
VS/TUN (Virtual Server via IP Tunneling),即通過 IP 隧道技術實現虛擬服務器。是將一個IP報文封裝在另一個IP報文的技術，這可以使得目標為一個IP地址的數據報文能被封裝和轉發到另一個IP地址。它跟VS/ΝΑΤ基本一樣，但是RS是直接返回數據給客戶端，不需要經過VS/TUN。
在上述三種工作模式下，LVS與后端的RS均需要兩層互聯，即LVS與RS處在同一個網段中并使用兩層協議通信，由此帶來的問題是限制了 LVS和RS的部署和級聯方式， LVS不能為跨網段的RS提供服務，只能使用較為扁平的網絡拓撲，從而大大局限了網絡拓撲。
為了能為多個網段的RS服務，現有的技術提出一種在VS/DR和VS/ΝΑΤ工作模式下的實現方法，該方法通過在LVS網卡上打tag來實現。
通常，服務器的網卡通過網線與路由器/交換機端口相連以連通網絡。交換機端口一般有兩種工作模式，一種是access模式,一種是trunk模式。在access模式下，交換機端口只能屬于一個vlan (Virtual Local Area Network,虛擬局域網)，對應的服務器網卡就配置一個網段的ip ;在trunk模式下，交換機端口可以屬于多個vlan，因此，對應的服務器網卡就可以配置多個網段的ip，為了在網卡上配置多個網段，就需要對網卡打tag，每個tag對應著一個網段。
對應到LVS的VS/DR和VS/ΝΑΤ模式，一般情況下LVS需要和后端的RS位于同一個網段，但是如果后端RS位于多個網段，就需要把LVS網卡的上聯端口設置為trunk模式， 并且在LVS的網卡上打上多個tag，然后在每個tag上配置不同的網段來實現。
這種在LVS網卡上打tag的方式可以使LVS服務于多個網段的RS，但是同一個路由器/交換機上的端口比較有限，限制了 LVS上能夠提供服務的RS數目。而且，LVS和RS 之間仍是兩層互聯，并沒有實現真正意義上的跨網段服務。
因此，需要實現一種全新的跨網段技術，使LVS能為更多不同網段的RS提供服務， 在真正意義上擴展網絡拓撲。發明內容
本申請提供了一種服務器負載均衡方法、裝置及系統，以使LVS實現跨網段的負載均衡。
為了解決上述問題，本申請公開了一種服務器負載均衡方法，包括
配置第一虛擬地址及其端口，和，第二虛擬地址及其端口，其中第一虛擬地址及其端口用于與客戶端建立連接，第二虛擬地址及其端口用于與真實服務器建立連接；
當接收客戶端發來的數據包時，將該數據包中的源地址及源端口轉換為第二虛擬地址及其端口，將該數據包的目的地址及目的端口轉換為真實服務器的地址及其端口，然后將轉換后的數據包轉發給真實服務器；
當接收真實服務器發來的數據包時，將該數據包中的源地址及源端口轉換為第一虛擬地址及其端口，將該數據包的目的地址及目的端口轉換為客戶端的真實地址及其端口，然后將轉換后的數據包轉發給客戶端。
優選的，所述將轉換后的數據包轉發給真實服務器之前，還包括在所述轉換后的數據包中添加客戶端的真實 地址及其端口。
優選的，還包括真實服務器收到所述轉換后的數據包，通過解析獲取客戶端的真實地址及其端口。
優選的，還包括判斷接收到的數據包的目的地址或目的端口，如果目的地址為所述第一虛擬地址，或者，目的端口為所述第一虛擬地址的端口，則所述數據包是客戶端發來的數據包；否則，是真實服務器發來的數據包。
優選的，當接收客戶端發來的數據包時，所述轉換之前還包括根據數據包的源地址、源端口、目的地址和目的端口查詢對應的session，如果查詢到，則進行所述的轉換；其中，所述源地址和源端口為客戶端真實的地址和端口，所述目的地址和目的端口為所述第一虛擬地址及其端口。
優選的，如果未查詢到，還包括判斷是否需要新建連接，如果是，則選擇建立連接的真實服務器，并選擇用于與所述真實服務器建立連接的第二虛擬地址及其端口，創建 session，然后進行所述的轉換；如果否，則退出。
優選的，當接收真實服務器發來的數據包時，所述轉換之前還包括根據數據包的源地址、源端口、目的地址和目的端口查詢對應的session，如果查詢到，則進行所述的轉換；如果未查詢到，則退出；其中，所述源地址和源端口為真實服務器的地址和端口，所述目的地址和目的端口為所述第二虛擬地址及其端口。
本申請還提供了一種服務器負載均衡裝置，包括
虛擬配置單元，用于配置第一虛擬地址及其端口，和，第二虛擬地址及其端口，其中第一虛擬地址及其端口用于與客戶端建立連接，第二虛擬地址及其端口用于與真實服務器建立連接；
第一地址轉換單元，用于當接收客戶端發來的數據包時，將該數據包中的源地址及源端口轉換為第二虛擬地址及其端口，將該數據包的目的地址及目的端口轉換為真實服務器的地址及其端口，然后將轉換后的數據包轉發給真實服務器；
第二地址轉換單元，用于當接收真實服務器發來的數據包時，將該數據包中的源地址及源端口轉換為第一虛擬地址及其端口，將該數據包的目的地址及目的端口轉換為客戶端的真實地址及其端口，然后將轉換后的數據包轉發給客戶端。
優選的，所述裝置還包括地址添加單元，用于在所述第一地址轉換單元將轉換后的數據包轉發給真實服務器之前，在所述轉換后的數據包中添加客戶端的真實地址及其端□。
優選的，所述裝置還包括數據包判斷單元，用于判斷接收到的數據包的目的地址或目的端口，如果目的地址為所述第一虛擬地址，或者，目的端口為所述第一虛擬地址的端口，則所述數據包是客戶端發來的數據包；否則，是真實服務器發來的數據包。
優選的，所述裝置還包括第一查詢單元，用 于根據客戶端發來的數據包的源地址、源端口、目的地址和目的端口查詢對應的session，如果查詢到，則觸發所述第一地址轉換單元；其中，所述源地址和源端口為客戶端真實的地址和端口，所述目的地址和目的端口為所述第一虛擬地址及其端口。
優選的，如果未查詢到，所述裝置還包括連接建立單元，用于判斷是否需要新建連接，如果是，則選擇建立連接的真實服務器，并選擇用于與所述真實服務器建立連接的第二虛擬地址及其端口，創建session，然后觸發所述第一地址轉換單元；如果否，則退出。
優選的，所述裝置還包括第二查詢單元，用于根據真實服務器發來的數據包的源地址、源端口、目的地址和目的端口查詢對應的session，如果查詢到，則觸發所述第二地址轉換單元；如果未查詢到，則退出；其中，所述源地址和源端口為真實服務器的地址和端口，所述目的地址和目的端口為所述第二虛擬地址及其端口。
優選的，所述裝置還包括地址解析單元，設在真實服務器上，用于真實服務器收到所述轉換后的數據包后，通過解析獲取客戶端的真實地址及其端口。
本申請還提供了一種服務器負載均衡系統，包括虛擬服務器和與之相連的真實服務器，所述虛擬服務器包括如上述的服務器負載均衡裝置。
優選的，所述真實服務器還包括地址解析單元，用于收到所述轉換后的數據包后，通過解析獲取客戶端的真實地址及其端口。
與現有技術相比，本申請包括以下優點
首先，本申請基于原VS/ΝΑΤ工作模式，在LVS和RS之間采用三層互聯，并對LVS 從客戶端和真實服務器接收的數據包都進行源地址和目的地址的轉換，從而使LVS能為更多個不同網段的RS服務。這種三層互聯的方式實現了真正意義上的跨網段負載均衡，LVS 上能夠提供服務的RS數目不再受限制，因此可以擴展出層次化的網絡拓撲。
其次，本申請簡化了 LVS和RS的配置和運營維護，原因如下
第一，LVS和RS只需要三層互通，大大簡化了前端部署的難度，并有利于層次化地網絡拓撲；
第二，RS在接入LVS時只需要加載一個用于解析客戶端真實地址和端口的內核模塊，不需要做其他任何修改；不需要為vip添加額外配置，只需要和LVS三層互通，易于部署和維護；
第三，LVS不需要配置任何tag信息，簡化了運營維護的復雜度。
當然，實施本申請的任一產品不一定需要同時達到以上所述的所有優點。
圖1是現有技術中LVS負載均衡的系統結構圖2是現有技術中原VS/ΝΑΤ工作模式下的TCP交互流程示意圖3是本申請實施例所述跨網段的LVS負載均衡工作模式示意圖4是圖3所示工作模式下跨網段的TCP交互流程示意圖5是本申請實施例所述一種服務器負載均衡方法的流程圖6是圖5的詳細實現流程圖7是本申請實施例中ipv4_specific. syn_recv_sock的Hook函數處理流程圖
圖8是本申請實施例中inet_stream_ops. getname Hook函數的處理流程圖9是本申請實施例所述一種服務器負載均衡裝置的結構圖。
具體實施方式
為使本申請的上述目的、特征和優點能夠更加明顯易懂，下面結合附圖和具體實施方式
對本申請作進一步詳細的說明。
本申請實現了一種跨網段的LVS負載均衡。本申請在LVS和RS之間采用三層互聯，并對LVS從客戶端和真實服務器接收的數據包都進行源地址和目的地址的轉換，從而使LVS能為更多個不同網段的RS服務。
本申請基于原VS/ΝΑΤ工作模式，下面首先介紹原VS/ΝΑΤ工作模式下的TCP交互流程。
參照圖2，是現有技術中原VS/ΝΑΤ工作模式下的TCP交互流程示意圖。
其中，Client表不客戶端，LVS表不虛擬服務器，RS表不真實服務器；
cip Client ip,客戶端的 ip 地址;
cport Client port,客戶端上為cip提供服務的端口 ；
vip virtual ip, LVS上綁定的虛擬ip，供用戶客戶端訪問；
vport virtual port, LVS 上為 vip 提供服務的端口 ；
rip Real Server ip,后端真實服務器的ip地址；
rport Real Server port,后端真實服務器為rip提供服務的端口。
原VS/ΝΑΤ工作模式下，LVS與后端的RS是兩層互聯，即LVS與RS處在同一個網段中并使用兩層協議通信，相應的TCP交互流程如下
I) Client 端與 LVS 提供的 vip、vport 建立 TCP 連接；
2) LVS 收到 Client 端發來的數據包后，進行 DNAT (Destination Network AddressTranslation,目的網絡地址轉換)，把vip、vport轉換為RS的rip和rport,然后轉發給 RS ；Client端發來的數據包中，源地址為cip,源端口為cport,目的地址為vip,目的端口為vport。經DNAT轉換后的數據包為源地址cip,源端口 cport,目的地址rip,目的端口 rport ο
3) RS處理收到的報文，然后回復數據，數據包的源ip和port是RS的rip和 rport,目的ip和port是Client的cip和cport ;由于RS的默認路由設置為LVS的ip,所以RS發向Client的報文會被路由到LVS ；
4)LVS 收到 RS 發給 Client 的報文后，進行 SNAT(Source Network Address Translation,源網絡地址轉換),把RS的rip和rport轉換為LVS的vip和vport,然后發送給Client端。
基于圖2所示的原VS/ΝΑΤ工作模式，本申請所述的跨網段的LVS負載均衡工作模式如圖3所示，其中
Client表示客戶端，LVS表示虛擬服務器，RS表示真實服務器，cip、cport、vip、 vport、rip、rport的含義與圖1和圖2也相同。不同的是，圖3中在LVS上還設定了 bip 和bport,含義如下
bip backend ip, LVS機器網卡上綁定的ip地址，用來與后端RS建立連接。
bport backend port, backend ip 可以使用的端口。
圖3所示工作模式的基本工作原理是LVS提供vip和vport供Client連接,連接成功后，LVS會使用bip和bport去和后端的RS建立連接，在后續的包交互過程中，LVS 主要完成以下兩個功能
第一，session的維護session中存放著vip、vport、bip和bport,分別用來關聯 LVS與Client之間的連接、LVS與RS之間的連接；
第二，在包轉發的過程中進行SNAT和DNAT，以便發向Client和RS的數據包都有正確的源和目的ip、源和目的端口。
在圖3所示工作模式下，本申請中跨網段的TCP交互流程如圖4所示，與原VS/NAT 工作模式下的TCP交互流程存在以下區別
I) LVS在處理從Client發向RS的報文時，不只進行DNAT，還需要進行SNAT，把源 ip和port修改為LVS上配置的bip和bport ；
2) LVS在處理從RS發向Client的報文時，不只進行SNAT，還需要進行DNAT，把bip 和 bport 修改為 Client 的 cip 和 cport ；
3)在發給RS的報文中添加一個自定義的tcp_option,在option中放置真實的客戶端 ip 和 port (cip、cport)；
4) RS端加載自定義的TCP協議Hook模塊,該模塊會獲取報文tcp_option中的客戶端真實ip和port,以便返回給用戶程序真實的Client ip和port。
上述區別中的3)和4)并不是實現本申請必須的，是一個可選步驟，如果無需向用戶程序或其他調用程序返回客戶端真實的ip和port，則無需進行3)和4)的處理。
綜上所述，由上述內容可以看出，本申請可通過以下方法實現跨網段的LVS負載均衡。
參照圖5，是本申請實施例所述一種服務器負載均衡方法的流程圖。
LVS進行以下處理
步驟501，配置第一虛擬地址及其端口，和，第二虛擬地址及其端口，其中第一虛擬地址及其端口用于與客戶端建立連接，第二虛擬地址及其端口用于與真實服務器建立連接；
其中，第一虛擬地址及其端口如上述的vip和vport，第二虛擬地址及其端口如上述的bip和bport。
步驟502，當接收客戶端發來的數據包時，將該數據包中的源地址及源端口轉換為第二虛擬地址及其端口，將該數據包的目的地址及目的端口轉換為真實服務器的地址及其端口，然后將轉換后的數據包轉發給真實服務器；
其中，客戶端發來的數據包的源地址及源端口為cip和cport，將其轉換為bip和 bport ；目的地址及目的端P為vip和vport,將其轉換為rip和rport。
步驟503，當接收真實服務器發來的數據包時，將該數據包中的源地址及源端口轉換為第一虛擬地址及其端口，將該數據包的目的地址及目的端口轉換為客戶端的真實地址及其端口，然后將轉換后的數據包轉發給客戶端。
其中，真實服務器發來的數據包的源地址及源端口為rip和rport，將其轉換為 vip和vport· ；目的地址及目的端口為bip和bport,將其轉換為cip和cport。
需要說明的是，上述步驟502和503沒有先后順序的限制。
基于圖5，詳細的實現流程如圖6所示，具體如下
本實施例的實現流程均在NetfiIter (包過濾系統)的IP_L0CAL_INH00K點，因為從Client發來的報文目的ip是vip，會走到IP_L0CAL_IN點，從RS發來的報文目的ip是 bip,也會走到IP_L0CAL_IN。此時就可以根據目的ip是否為vip來區分是Out-1n (處理從 Client發向RS的報文)還是In-Out (處理從RS發向Client的報文)。
步驟S10，報文進入到LVS的IP_L0CAL_IN Η00Κ點進行處理；
步驟S11，判斷接收到的數據包的目的ip是否為vip ；
如果是,則為Out-1n,轉入步驟S12 ;如果否,則目的ip是bip,為In-Out,轉入步驟 S13 ；
同理，也可以判斷接收到的數據包的目的端口，如果目的端口為所述第一虛擬地址的端口 vport，則所述數據包是客戶端發來的數據包；否則，目的端口為bport，是真實服務器發來的數據包。
以下S12 至 S26 是 Out-Ιη 流程
步驟S12,根據 cip、cport、vip 和 vport 查詢 session ；
如果查詢到與所述四元組(cip、cport、vip和vport)對應的session,表示 Client與對應的RS之間已經建立連接，轉入步驟S22 ;如果未查詢到，表示Client與對應的RS之間未建立連接，本次傳輸是該Client第一次與對應的RS建立連接，轉入步驟S14。
其中，所述cip、cport是數據包的源地址、源端口，vip、vport是數據包的目的地址和目的端口。
步驟S14，判斷是否需要新建連接；
一般的標準是檢查是否是SYN包，如果是，轉入步驟S16 ;如果否，返回NF_ACCEPT，退出處理。
步驟S16，選擇 RS;
即根據預定義的負載均衡策略選擇一個與當前Client建立連接的RS，所述負載均衡策略可選用現有技術中的任何一種策略。選擇成功后，轉入步驟S18。
步驟S18，選擇 backend ip 和 port ;
所述bip和bport用于LVS與S16選擇的RS建立連接。本實施例中，backend ip 是用戶態的工具釆用setsockopt的方式發送到內核中的，LVS會利用輪詢的方式來選擇 backend ip 和 port。
步驟S20，創建 session ；
步驟S22，DNAT :將 vip、vport 轉換為 rip、rport ；
步驟S24，SNAT :將 cip、cport 轉換為 bip、bport ；
步驟S26，插入 tcp—option，option 中存放客戶端的真實 ip 和 port (cip、cport)， 進入 IP—LOCAL—OUT 點。
本步驟是可選步驟。
以下S13 至 S17 是 In-Out 流程
步驟S13，根據 bip、bport、rip 和 rport 查詢 session ；
如果查詢到與所述四元組(bip、bport、rip和rport)對應的session，表示RS與對應的Client之間已經建立連接，轉入步驟S15 ;如果未查詢到，表示RS與對應的Client 之間未建立連接，返回NF—ACCEPT，退出處理。
步驟S15，SNAT :將 rip、rport 轉換為 vip、vport ；
步驟S17，DNAT :將 bip、bport 轉換為 cip、cport，進入 IP—LOCAL—OUT 點。
上述流程中，如果選擇執行步驟S26，則對應的RS中還需配置加載一個內核模塊， 在TCP協議中所述內核模塊為Hook模塊，用于在RS收到所述轉換后的數據包后，通過解析獲取客戶端的真實ip及port。
在TCP 協議中，Hook 模塊是通過 Hook inet—stream—ops. getname 與 ipv4— specific. syn_recv_sock 這兩個函數實現。其中，通過 Hookipv4_specific. syn_recv_ sock 函數，解析出 Client ip 與 port 并存入 socket 的 sk—user—data 中；通過 Hook inet— stream—ops. getname 函數，在應用層調用 accet()、getpeername ()時，返回 sk—user—data 中保存的Client ip與port。
參照圖7，ipv4—specif ic. syn—recv—sock 的 Hook 函數處理流程如下
步驟701，調用原有的 tcp—V4—syn—recv—sock 函數創建 sock ；
步驟702，判斷sock是否創建成功，并且sk—user—data是否為空；
如果是，則轉入步驟703 ;如果否，則返回錯誤；
步驟703，解析報文中的tcp—option，解析出cip和cport，并放入sk—user—data 中；
步驟704，返回 socket。
相比于原有流程，只是添加了自定義tcp—option的解析。
參照圖8，inet—stream—ops. getname Hook函數的處理流程如下
步驟801，調用原有的inet—getname函數解析socket的相關信息；
步驟802,判斷所述函數是否正常返回并且sk_user_data是否存在cip和cport信息；
如果是，則轉入步驟803 ;如果否，則返回錯誤；
步驟803,從sk_user_data中解析出cip和cport信息，并更新上述調用的socket 信息；
步驟804，返回調用結果。
相比于原有流程,只是添加了從sk_user_data中解析cip和cport的操作。
需要說明的是，對于前述的各方法實施例，為了簡單描述，故將其都表述為一系列的動作組合，但是本領域技術人員應該知悉，本申請并不受所描述的動作順序的限制，因為依據本申請，某些步驟可以采用其他順序或者同時進行。其次，本領域技術人員也應該知悉，說明書中所描述的實施例均屬于優選實施例，所涉及的動作并不一定是本申請所必須的。
綜上所述，本申請實施例提供的LVS負載均衡方法在LVS和RS之間采用三層互聯，進而為實現三層互聯對LVS從客戶端和真實服務器接收的數據包都進行源地址和目的地址的轉換，從而使LVS能為更多個不同網段的RS服務。這種三層互聯的方式實現了真正意義上的跨網段負載均衡，LVS上能夠提供服務的RS數目不再受限制，因此可以擴展出層次化的網絡拓撲。
更進一步分析，現有的DR模式是通過修改MAC的方式把數據包轉發給RS，所以 LVS工作在鏈路層，所以無法進行跨網段。原有的NAT模式僅僅修改Out-1n報文的目的 IP，并且RS回復的報文必須經過LVS以便進行地址轉換，所以RS必須把默認網關指向LVS， 而RS與默認網關必須在同一網段，此時LVS的角色類似RS上聯的出口路由器，所以限制了 LVS和RS必須在同一網段。而本申請提出的方式在Out-1n時同時修改了源 和目的IP，此時為了使RS回復的報文能經過LVS，只需要新的源IP和RS在內網中是三層互通的，這樣 RS回復的報文(目的IP是LVS的第二虛擬IP)就可以回到LVS以便進行地址轉換，此時 LVS的角色類似7層的負載均衡軟件(HAPiOxy等)，只不過是工作在內核中而已，因此可以實現跨網段的功能。
而且，本申請實施例所述方法還大大簡化了 LVS和RS的配置和運營維護，下面通過與其他方式相比較進行說明。
第一，背景技術中提到，在LVS的VS/DR和VS/ΝΑΤ工作模式下，通過在LVS網卡上打tag的方式可以使LVS服務于多個網段的RS，但是這種方式的配置和運營維護十分復雜， 這種復雜性體現在如下方面
I)更改交換機端口工作模式的工作較為危險，容易導致網卡連接不上，增加運營維護成本默認情況下，交換機端口工作在access模式，當需要更改為trunk模式時,需要首先修改服務器上的配置然后重啟網絡，再由運維部門同事修改端口工作模式。如果服務器上的配置修改有誤，則工作模式修改后會導致網絡無法連接，即使修改回原來的工作模式也不能正常連接，只能去現場操作，增加了運營維護的成本。
2)需要跨部門合作，步驟比較繁瑣首先要和業務部門同事確認后端RS所處的網段，再和運維部門同事確認該網段所處于的vlan，然后為每個vlan號配置網卡的tag設置。
3)后期的維護較為復雜如果后端的RS由于機器搬遷或者其他原因更換了網段，需要重新確認vlan號,再重新設置網卡的tag設置。
第二，在原有的VS/TUN工作模式的基礎上，LVS與后端RS經改造后也可以實現三層互聯(跨多個網段)的功能，但是在該模式下，RS的配置較為復雜，體現在如下方面
I)RS上需要建立tunnel設備,tunnel設備依賴于ipip模塊(IPIP隧道協議是使用在兩個路由器間對IP數據包進行封裝的簡單協議)，因此需要為內核添加ipip模塊的支持，另外RS的穩定性也會依賴于ipip的穩定性；
2)RS上需要為每個vip建立一個tunnel設備，同時配置tunnel設備的arp_ annouce和arp_ignore選項，當vip較多時配置會較為繁瑣，并且容易出錯；
3)在修改vip時,容易出現忘記刪除原tunnel設備及vip等問題,導致配置出錯。
相比于上述兩種方式，本申請不僅能夠實現三層互聯(跨多個網段)的功能，其配置和運營維護的簡化性體現在以下方面
1)LVS和RS只需要三層互通，大大簡化了前端部署的難度，并有利于層次化地網絡拓撲；
2) RS在接入LVS時只需要加載一個內核模塊(Hook)，不需要做其他任何修改；不需要為vip添加額外配置，只需要和LVS三層互通，易于部署和維護；
3) LVS不需要配置任何tag信息，簡化了運營維護的復雜度。
基于上述方法實施例的說明，本申請還提供了相應的裝置和系統實施例。
參照圖9，是本申請實施例所述一種服務器負載均衡裝置的結構圖。
所述服務器負載均衡裝置可設在LVS上運行，具體包括虛擬配置單元10、第一地址轉換單元20和第二地址轉換單元30，其中，
虛擬配置單元10，用于配置第一虛擬地址及其端口，和，第二虛擬地址及其端口， 其中第一虛擬地址及其端口用于與客戶端建立連接，第二虛擬地址及其端口用于與真實服務器建立連接；
第一地址轉換單元20，用于當接收客戶端發來的數據包時，將該數據包中的源地址及源端口轉換為第二虛擬地址及其端口，將該數據包的目的地址及目的端口轉換為真實服務器的地址及其端口，然后將轉換后的數據包轉發給真實服務器；
第二地址轉換單元30，用于當接收真實服務器發來的數據包時，將該數據包中的源地址及源端口轉換為第一虛擬地址及其端口，將該數據包的目的地址及目的端口轉換為客戶端的真實地址及其端口，然后將轉換后的數據包轉發給客戶端。
可選的，所述服務器負載均衡裝置還可以包括
地址添加單元40，用于在所述第一地址轉換單元20將轉換后的數據包轉發給真實服務器之前，在所述轉換后的數據包中添加客戶端的真實地址及其端口。
可選的，如果設置地址添加單元40，則所述服務器負載均衡裝置還可以包括
地址解析單元50，設在真實服務器上，用于真實服務器收到所述轉換后的數據包后，通過解析獲取客戶端的真實地址及其端口。
優選的，所述服務器負載均衡裝置還可以包括
數據包判斷單元60，用于判斷接收到的數據包的目的地址或目的端口，如果目的地址為所述第一虛擬地址，或者，目的端口為所述第一虛擬地址的端口，則所述數據包是客戶端發來的數據包；否則，是真實服務器發來的數據包。
優選的，所述服務器負載均衡裝置還可以包括
第一查詢單元70，用于根據客戶端發來的數據包的源地址、源端口、目的地址和目的端口查詢對應的session，如果查詢到，則觸發所述第一地址轉換單元20 ;其中，所述源地址和源端口為客戶端真實的地址和端口，所述目的地址和目的端口為所述第一虛擬地址及其端口。
優選的，如果未查詢到，所述服務器負載均衡裝置還可以包括
連接建立單元80，用于判斷是否需要新建連接，如果是，則選擇建立連接的真實服務器，并選擇用于與所述真實服務器建立連接的第二虛擬地址及其端口，創建session，然后觸發所述第一地址轉換單元20 ;如果否，則退出。
優選的，所述服務器負載均衡裝置還可以包括
第二查詢單元90，用于根據真實服務器發來的數據包的源地址、源端口、目的地址和目的端口查詢對應的session，如果查詢到，則觸發所述第二地址轉換單元30 ;如果未查詢到，則退出；其中，所述源地址和源端口為真實服務器的地址和端口，所述目的地址和目的端口為所述第二虛擬地址及其端口。
對于上述裝置實施例而言，由于其與方法實施例基本相似，所以描述的比較簡單， 相關之處參見方法實施例的部分說明即可。
基于圖9所示的服務器負載均衡裝置，本申請實施例還提供了一種服務器負載均衡系統。所述服務器負載均衡系統主要包括虛擬服務器和與所述虛擬服務器相連的跨網段的多個真實服務器，其中所述虛擬服務器上可以設置上述虛擬配置單元10、第一地址轉換單元20、第二地址轉換單元30、地址添加單元40、數據包判斷單元60、第一查詢單元70、連接建立單元80、第二查詢單元90，所述真實服務器上可以設置上述地址解析單元50。
上述服務器負載均衡裝置及服務器負載均衡系統實現了一種全新的跨網段技術， 可以使網絡拓撲得到很大的改進，并簡化了 LVS和RS的配置，減少了運維的成本。
本說明書中的各個實施例均采用遞進的方式描述，每個實施例重點說明的都是與其他實施例的不同之處，各個實施例之間相同相似的部分互相參見即可。
最后，還需要說明的是，在本文中，諸如第一和第二等之類的關系術語僅僅用來將一個實體或者操作與另一個實體或操作區分開來，而不一定要求或者暗示這些實體或操作之間存在任何這種實際的關系或者順序。
而且，上文中的“和/或”表示本文既包含了 “和”的關系，也包含了 “或”的關系， 其中如果方案A與方案B是“和”的關系，則表示某實施例中可以同時包括方案A和方案 B ;如果方案A與方案B是“或”的關系，則表示某實施例中可以單獨包括方案A，或者單獨包括方案B。
以上對本申請所提供的一種服務器負載均衡方法、裝置及系統，進行了詳細介紹， 本文中應用了具體個例對本申請的原理及實施方式進行了闡述，以上實施例的說明只是用于幫助理解本申請的方法及其核心思想；同時，對于本領域的一般技術人員，依據本申請的思想，在具體實施方式
及應用范圍上均會有改變之處，綜上所述，本說明書內容不應理解為對本申請的限制。
權利要求
1.一種服務器負載均衡方法，其特征在于，包括配置第一虛擬地址及其端口，和，第二虛擬地址及其端口，其中第一虛擬地址及其端口用于與客戶端建立連接，第二虛擬地址及其端口用于與真實服務器建立連接；當接收客戶端發來的數據包時，將該數據包中的源地址及源端口轉換為第二虛擬地址及其端口，將該數據包的目的地址及目的端口轉換為真實服務器的地址及其端口，然后將轉換后的數據包轉發給真實服務器；當接收真實服務器發來的數據包時，將該數據包中的源地址及源端口轉換為第一虛擬地址及其端口，將該數據包的目的地址及目的端口轉換為客戶端的真實地址及其端口，然后將轉換后的數據包轉發給客戶端。
2.根據權利要求1所述的方法，其特征在于，所述將轉換后的數據包轉發給真實服務器之前，還包括在所述轉換后的數據包中添加客戶端的真實地址及其端口。
3.根據權利要求2所述的方法，其特征在于，還包括真實服務器收到所述轉換后的數據包，通過解析獲取客戶端的真實地址及其端口。
4.根據權利要求1至3任一所述的方法，其特征在于，還包括判斷接收到的數據包的目的地址或目的端口，如果目的地址為所述第一虛擬地址，或者，目的端口為所述第一虛擬地址的端口，則所述數據包是客戶端發來的數據包；否則，是真實服務器發來的數據包。
5.根據權利要求4所述的方法，其特征在于，當接收客戶端發來的數據包時，所述轉換之前還包括根據數據包的源地址、源端口、目的地址和目的端口查詢對應的session，如果查詢到，則進行所述的轉換；其中，所述源地址和源端口為客戶端真實的地址和端口，所述目的地址和目的端口為所述第一虛擬地址及其端口。
6.根據權利要求5所述的方法，其特征在于，如果未查詢到，還包括判斷是否需要新建連接，如果是，則選擇建立連接的真實服務器，并選擇用于與所述真實服務器建立連接的第二虛擬地址及其端口，創建session，然后進行所述的轉換；如果否，則退出。
7.根據權利要求4所述的方法，其特征在于，當接收真實服務器發來的數據包時，所述轉換之前還包括根據數據包的源地址、源端口、目的地址和目的端口查詢對應的session，如果查詢到，則進行所述的轉換；如果未查詢到，則退出；其中，所述源地址和源端口為真實服務器的地址和端口，所述目的地址和目的端口為所述第二虛擬地址及其端口。
8.一種服務器負載均衡裝置，其特征在于，包括虛擬配置單元，用于配置第一虛擬地址及其端口，和，第二虛擬地址及其端口，其中第一虛擬地址及其端口用于與客戶端建立連接，第二虛擬地址及其端口用于與真實服務器建立連接；第一地址轉換單元，用于當接收客戶端發來的數據包時，將該數據包中的源地址及源端口轉換為第二虛擬地址及其端口，將該數據包的目的地址及目的端口轉換為真實服務器的地址及其端口，然后將轉換后的數據包轉發給真實服務器；第二地址轉換單元，用于當接收真實服務器發來的數據包時，將該數據包中的源地址及源端口轉換為第一虛擬地址及其端口，將該數據包的目的地址及目的端口轉換為客戶端的真實地址及其端口，然后將轉換后的數據包轉發給客戶端。
9.根據權利要求8所述的裝置，其特征在于，還包括地址添加單元，用于在所述第一地址轉換單元將轉換后的數據包轉發給真實服務器之前，在所述轉換后的數據包中添加客戶端的真實地址及其端口。
10.根據權利要求8或9所述的裝置，其特征在于，還包括數據包判斷單元，用于判斷接收到的數據包的目的地址或目的端口，如果目的地址為所述第一虛擬地址，或者，目的端口為所述第一虛擬地址的端口，則所述數據包是客戶端發來的數據包；否則，是真實服務器發來的數據包。
11.根據權利要求10所述的裝置，其特征在于，還包括第一查詢單元，用于根據客戶端發來的數據包的源地址、源端口、目的地址和目的端口查詢對應的session,如果查詢到,則觸發所述第一地址轉換單元；其中，所述源地址和源端口為客戶端真實的地址和端口，所述目的地址和目的端口為所述第一虛擬地址及其端口。
12.根據權利要求11所述的裝置，其特征在于，如果未查詢到，還包括連接建立單元，用于判斷是否需要新建連接，如果是，則選擇建立連接的真實服務器，并選擇用于與所述真實服務器建立連接的第二虛擬地址及其端口，創建session，然后觸發所述第一地址轉換單元；如果否，則退出。
13.根據權利要求10所述的裝置，其特征在于，還包括第二查詢單元，用于根據真實服務器發來的數據包的源地址、源端口、目的地址和目的端口查詢對應的session，如果查詢到，則觸發所述第二地址轉換單元；如果未查詢到，則退出；其中，所述源地址和源端口為真實服務器的地址和端口，所述目的地址和目的端口為所述第二虛擬地址及其端口。
14.根據權利要求9所述的裝置，其特征在于，還包括地址解析單元，設在真實服務器上，用于真實服務器收到所述轉換后的數據包后，通過解析獲取客戶端的真實地址及其端口。
15.一種服務器負載均衡系統，其特征在于，包括虛擬服務器和與之相連的真實服務器，所述虛擬服務器包括如上述權利要求8至13任一權利要求所述的服務器負載均衡裝置。
16.根據權利要求15所述的系統，其特征在于，所述真實服務器還包括地址解析單元，用于收到所述轉換后的數據包后，通過解析獲取客戶端的真實地址及其端口。
全文摘要
本申請提供了一種服務器負載均衡方法、裝置及系統，以使LVS實現跨網段的負載均衡。在LVS和RS之間采用三層互聯，并對LVS從客戶端和真實服務器接收的數據包都進行源地址和目的地址的轉換，從而使LVS能為更多個不同網段的RS服務。這種三層互聯的方式實現了真正意義上的跨網段負載均衡，LVS上能夠提供服務的RS數目不再受限制，因此可以擴展出層次化的網絡拓撲。而且，簡化了LVS和RS的配置和運營維護。
文檔編號H04L29/08GK103023942SQ201110295820
公開日2013年4月3日 申請日期2011年9月27日 優先權日2011年9月27日
發明者陳建, 唐會軍 申請人:奇智軟件(北京)有限公司