LVS類型詳解及其調度方法

1.LVS簡介

    LVS 是 Linux  Virtual Server ，Linux 虛擬服務器。能夠實現LINUX平臺下的簡單負載均衡。通常來講，LVS採用三層結構：負載調度器、服務器池、共享存儲。工做在TCP/IP協議的四層，其轉發是依賴於四層協議的特徵進行轉發的，因爲其轉發要 依賴於協議的特徵進行轉發，所以須要在內核的TCP/IP協議棧進行過濾篩選，可想而知，這就須要在內核的模塊來完成，而這樣的過濾轉發規則又是由管理員 進行定義的，因此，LVS就是兩段式的架構設計，在內核空間中工做的是"ipvs"，而在用戶空間中工做的，用來定義集羣服務規則的 是"ipvsadm"。與iptables相似，其工做在INPUT鏈上，因爲與iptables有衝突，不能同時使用。

2.LVS類型

1).NAT模型

    這個是經過網絡地址轉換的方法來實現調度的。首先調度器(director)接收到客戶的請求數據包時(請求的目的IP爲VIP)，根據調度算法決定將請求發送給哪一個後端的真實服務器(RS)。而後調度器就把客戶端發送的請求數據包的目標IP地址及端口改爲後端真實服務器的IP地址(RIP)，這樣真實服務器(RS)就可以接收到客戶的請求數據包了。真實服務器響應完請求後，查看默認路由(NAT模式下咱們須要把RS的默認路由設置爲director服務器。)把響應後的數據包發送給director,director再接收到響應包後，把包的源地址改爲虛擬地址(VIP)而後發送回給客戶端。

    NAT模式特性：

        集羣節點跟director必須在同一個IP網絡中；
        RIP一般是私有地址，僅用於各集羣節點間的通訊；
        director位於client和real server之間，並負責處理進出的全部通訊；
        realserver必須將網關指向DIP；
        支持端口映射；
        realserver可使用任意OS；
        較大規模應該場景中，director易成爲系統瓶頸；

2).DR模型

    DR模式是經過改寫請求報文的目標MAC地址，將請求發給真實服務器的，而真實服務器響應後的處理結果直接返回給客戶端用戶。同TUN模式同樣，DR模式能夠極大的提升集羣系統的伸縮性。並且DR模式沒有IP隧道的開銷，對集羣中的真實服務器也沒有必要必須支持IP隧道協議的要求。可是要求調度器LB與真實服務器RS都有一塊網卡鏈接到同一物理網段上，必須在同一個局域網環境。

    DR模型特性：

        集羣節點跟director必須在同一個物理網絡中；
        RIP可使用公網地址，實現便捷的遠程管理和監控；
        director僅負責處理入站請求，響應報文則由realserver直接發往客戶端；
        realserver不能將網關指向DIP；
        不支持端口映射；

3).TUN模型

    採用NAT模式時，因爲請求和響應的報文必須經過調度器地址重寫，當客戶請求愈來愈多時，調度器處理能力將成爲瓶頸。爲了解決這個問題，調度器把請求的報文經過IP隧道轉發到真實的服務器。真實的服務器將響應處理後的數據直接返回給客戶端。這樣調度器就只處理請求入站報文，因爲通常網絡服務應答數據比請求報文大不少，採用VS/TUN模式後，集羣系統的最大吞吐量能夠提升10倍。

    TUN模型特性：

        集羣節點能夠跨越Internet；
        RIP必須是公網地址；
        director僅負責處理入站請求，響應報文則由realserver直接發往客戶端；
        realserver網關不能指向director；
        只有支持隧道功能的OS才能用於realserver；
        不支持端口映射；

3.LVS調度方法

    LVS調度方法分爲靜態調度方法和動態調度方法兩類。

    靜態調度方法：

        rr：調度器經過「輪叫」調度算法將外部請求按順序輪流分配到集羣中的真實服務器上，它均等地對待每一臺服務器，而無論服務器上實際的鏈接數和系統負載。

        wrr：加權輪叫調度算法是按權值的高低和輪叫方式分配請求到各服務器。權值高的服務器先收到的鏈接，權值高的服務器比權值低的服務器處理更多的鏈接，相同權值的服務器處理相同數目的鏈接數。

        dh：目標地址散列調度算法先根據請求的目標IP地址，做爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，不然返回空，主要應用於緩存服務器。

        sh：源地址散列調度算法正好與目標地址散列調度算法相反，它根據請求的源IP地址，做爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，不然返回空。主要用於session會話綁定。

    動態調度方法：

        lc：最少連接，簡稱LC。該調度是把新的鏈接請求分配到當前鏈接數最小的服務器。最小鏈接調度是一種動態調度算法，它經過服務器當前所活躍的鏈接數來估計服務器的負載狀況。計算當前realserver 的負載狀況計算方法：active*256+inactive。

        wlc：加權最少連接，簡稱WLC。加權最小鏈接調度是最小鏈接調度的超集，各個服務器用相應的權值表示其處理性能。計算當前realserver 的負載狀況計算方法：(active*256+inactive)/weight。
        sed：最短的指望的延遲,簡稱SED。分配一個接踵而來的請求以最短的指望的延遲方式到服務器。計算當前realserver 的負載狀況計算方法：(active+1)*256/weight。
        nq：無需隊列。若是有臺 realserver的鏈接數＝0就直接分配過去，不須要在進行sed運算。

        LBLC：」基於局部性的最少連接「調度算法是針對目標IP地址的負載均衡，目前主要用於Cache集羣系統。該算法根據請求的目標IP地址找出該目標IP地址最近 使用的服務器，若該服務器是可用的且沒有超載，將請求發送到該服務器；若服務器不存在，或者該服務器超載且有服務器處於一半的工做負載，則用「最少連接」 的原則選出一個可用的服務器，將請求發送到該服務器。
        LBLCR：「帶複製的基於局部性最少連接」調度算法也是針對目標IP地址的負載均衡，目前主要用於Cache集羣系統。它與LBLC算法的不一樣之處是它要維護從一個 目標 IP地址到一組服務器的映射，而LBLC算法維護從一個目標IP地址到一臺服務器的映射。該算法根據請求的目標IP地址找出該目標IP地址對應的服務器 組，按「最小鏈接」原則從服務器組中選出一臺服務器，若服務器沒有超載，將請求發送到該服務器；若服務器超載，則按「最小鏈接」原則從這個集羣中選出一臺 服務器，將該服務器加入到服務器組中，將請求發送到該服務器。同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以下降複製的程度。

注：active：活動鏈接，表示已經創建的鏈接並正在進行數據傳輸。inactive：非活動鏈接，表示已經創建的鏈接但沒有在進行數據傳輸。

參考資料：

LVS原理詳解：http://atong.blog.51cto.com/2393905/1348602

LVS工做模式及原理：http://blog.csdn.net/caoshuming_500/article/details/8291940

LVS工做模式及調度算法介紹：http://www.xmydlinux.org/201102/331.html