LVS：三種模式的原理、調度算法、及應用介紹

LVS三種模式原理(nat/dr/tun)

LVS/NAT：

  如上圖，客戶通過virtual IP （虛擬服務的IP地址，公網地址），訪問網絡服務時，請求報文到達調度器，調度器根據連接調度算法從一組真實服務器中選出一臺服務器，將報文的目標地址VIP，改寫成選定服務器的地址（RIP），報文的目標端口改寫成選定服務器的相應端口，最后將修改后的報文發送給選出的服務器。

  同時，調度器在連接Hash表中記錄這個連接，當這個連接的下一個報文到達時，從連接Hash表中可以得到原選定服務器的地址和端口，進行同樣的改寫操作，并將報文傳給原選定的服務器。當來自真實服務器(Real server)的響應報文經過調度器時，調度器將報文的源地址和源端口改為VIP和相應的端口，再把報文發給用戶。

  我們在連接上引入一個狀態機，不同的報文會使得連接處于不同的狀態，不同的狀態有不同的超時值。在TCP連接中，根據標準的TCP有限狀態機進行狀態遷移；在UDP中，我們只設置一個UDP狀態。不同狀態的超時值是可以設置的，在缺省情況下，SYN狀態的超時為1分鐘，ESTABLISHED狀態的超時為15分鐘，FIN狀態的超時為1分鐘；UDP狀態的超時為5分鐘。當連接終止或超時，調度器將這個連接從連接Hash表中刪除。

   小結：

    1、對外界可視的只有director，后端的真實服務器（real server）是不可見的；

    2、所有響應報文從real server發出后，必須再經由director才能轉發到客戶端

    3、director與real server，必須在同一IP網絡內，且應該是私網內，real server的網關必須指向director，有測試報告顯示，當后端real server在10到20臺之間的時候，director容易成為整個集群系統的瓶頸，因此對大型站點來講該方法并非最佳的負載均衡方法

    4、支持端口映射，可修改請求報文的目標PORT；

    5、vs必須是Linux系統，rs可以是任意系統；

LVS/DR：

   如上圖，（備調用器zuhi，）在VS/DR中，調度器根據各個服務器的負載情況，動態地選擇一臺服務器，不修改也不封裝IP報文，而是將數據幀的MAC地址改為選出服務器的MAC地址，再將修改后的數據幀在與服務器組的局域網上發送。

  因為數據幀的MAC地址是選出的服務器，所以服務器肯定可以收到這個數據幀，從中可以獲得該IP報文。當服務器發現報文的目標地址VIP是在本地的網絡設備上（將VIP設置在回環地址上Lo），服務器處理這個報文，然后根據路由表將響應報文直接返回給客戶。由于是real server直接將相應報文經由回環地址發給客戶端的，所以客戶端既不知道real server的存在，也可以將nat模式中director瓶頸隱患處理了，適用范圍較廣

  小結：

    1、確保前端路由器將目標IP為VIP的請求報文發往Director：

        (a) 在前端網關做靜態綁定；

        (b) 在RS上使用arptables；

        (c) 在RS上修改內核參數以限制arp通告及應答級別；

            arp_announce

            arp_ignore

    2、RS的RIP可以使用私網地址，也可以是公網地址；RIP與DIP在同一IP網絡；RIP的網關不能指向DIP，以確保響應報文不會經由Director；

    3、RS跟Director要在同一個物理網絡；

    4、請求報文要經由Director，但響應不能經由Director，而是由RS直接發往Client；

    5、不支持端口映射；

   但是很多人都想，假如用real server直接將相應報文發給客戶端，那么VIP與DIP和RIP需要在同一網段，這樣的話就需要大量的公網地址IP了，大大增加了額外的開銷，可否將VIP于DIP和RIP分別設置在兩個網段中，VIP用公網地址，而DIP和RIP用私網地址？答案是可以的。

   假如將VIP與DIP和RIP設置在兩個IP網絡中，那么Real server就要將網關指向通往公網的IP，絕對不能指向director（指向director的話與lvs/net模式還有由什么區別？）

LVS/TUN(通過IP隧道實現虛擬服務器)

   IP隧道（IP tunneling）是將一個IP報文封裝在另一個IP報文的技術，這可以使得目標為一個IP地址的數據報文能被封裝和轉發到另一個IP地址。IP隧道技術亦稱為IP封裝技術（IP encapsulation）。IP隧道主要用于移動主機和虛擬私有網絡（Virtual Private Network），在其中隧道都是靜態建立的，隧道一端有一個IP地址，另一端也有唯一的IP地址。

  如下圖：

    它的連接調度和管理與VS/NAT中的一樣，只是它的報文轉發方法不同。調度器根據各個服務器的負載情況，動態地選擇一臺服務器，將請求報文封裝在另一個IP報文中，再將封裝后的IP報文轉發給選出的服務器；服務器收到報文后，先將報文解封獲得原來目標地址為VIP的報文，服務器發現VIP地址被配置在本地的IP隧道設備上，所以就處理這個請求，然后根據路由表將響應報文直接返回給客戶。

   在這里，請求報文的目標地址為VIP，響應報文的源地址也為VIP，所以響應報文不需要作任何修改，可以直接返回給客戶，客戶認為得到正常的服務，而不會知道是哪一臺服務器處理的。

  小結：

    1、DIP, VIP, RIP都只能是公網地址；

    2、RS的網關不能，也不可能指向DIP；

    3、請求報文要經由Director，但響應不能經由Director，而是real server直接用VIP響應客戶端；

    4、不支持端口映射；

    5、RS的OS得支持隧道功能；

三種方法的優缺點比較：

三種IP負載均衡技術的優缺點歸納在下表中：

         注：以上三種方法所能支持最大服務器數目的估計是假設調度器使用100M網卡，調度器的硬件配置與后端服務器的硬件配置相同，而且是對一般Web服務。使用更高的硬件配置（如千兆網卡和更快的處理器）作為調度器，調度器所能調度的服務器數量會相應增加。當應用不同時，服務器的數目也會相應地改變。所以，以上數據估計主要是為三種方法的伸縮性進行量化比較。

大多數Internet服務都有這樣的特點：

  請求報文較短而響應報文往往包含大量的數據。如果能將請求和響應分開處理，即在負載調度器中只負責調度請求而響應直接返回給客戶，將極大地提高整個集群系統的吞吐量。

  所以適當的將請求報文與響應報文發散處理，是一種很好的集群對外服務性能向往擴展的思路

==================================================分界線========================================================================

LVS之調度算法

根據其調度時是否考慮各RS當前的負載狀態，可分為靜態方法和動態方法兩種：

  靜態方法：僅根據算法本身進行調度；

     RR：roundrobin，輪詢，將外部的請求報文輪流分配到集群服務中的每一臺Real server中（每一臺是只要定義在集群中的Real server，不論是否活動還是非活動，主要是因為lvs無法對后端服務器的健康狀態做檢查），主要強調的是公平調度

     WRR：Weighted RR，加權輪詢；調度器通過“加權輪叫”調度算法根據真實服務器的不同處理能力來調度訪問請求。這樣可以保證處理能力強的服務器能處理更多的訪問流量。調度器可以自動問詢真實服務器的負載情況，并動態地調整其權值。

    如：RS1–>weight 1

        RS2–>weight 2

       那么我們可以理解為后端一共有三臺RS，分別是RS1，和兩臺RS2

     SH：Source Hashing，實現session sticy，將報文的源IP地址當做key，做一張hash表；將來自于同一個IP地址的請求始終發往第一次挑中的RS，從而實現會話綁定；

    DH：Destination Hashing；請求的目標地址當做key，做一張hash表，將發往同一個目標地址的請求始終轉發至第一次挑中的RS，常用于緩存服務器；

   動態方法：主要根據每RS當前的負載狀態及調度算法進行調度；

      LC：least connections，調度器通過“最少連接”調度算法動態地將網絡請求調度到已建立的鏈接數最少的服務器上。如果集群系統的真實服務器具有相近的系統性能，采用“最小連接”調度算法可以較好地均衡負載。（其算法為：Overhead=activeconns*256+inactiveconns）

      WLC：Weighted LC，在集群系統中的服務器性能差異較大的情況下，調度器采用“加權最少鏈接”調度算法優化負載均衡性能，具有較高權值的服務器將承受較大比例的活動連接負載。調度器可以自動問詢真實服務器的負載情況，并動態地調整其權值。(其算法為：Overhead=(activeconns*256+inactiveconns)/weight

若會話值一致 , 從上而下搜索第一臺服務器作響應)

      SED：Shortest Expection Delay，基于wlc算法。這個必須舉例來說了：
          ABC三臺機器分別權重123 ，連接數也分別是123。那么如果使用WLC算法的話一個新請求進入時它可能會分給ABC中的任意一個。使用sed算法后會進行這樣一個運算
        A(1+1)/1
        B(1+2)/2
        C(1+3)/3
        根據運算結果，把連接交給C 。

       NQ：Never Queue，無需隊列。如果有臺 realserver的連接數＝0就直接分配過去，不需要在進行sed運算

      LBLC：Locality-Based LC，“基于局部性的最少鏈接”調度算法是針對目標IP地址的負載均衡，目前主要用于Cache集群系統。

      該算法根據請求的目標IP地址找出該目標IP地址最近使用的服務器，若該服務器是可用的且沒有超載，將請求發送到該服務器；若服務器不存在，或者該服務器超載且有服務器處于一半的工作負載，則用“最少鏈接” 的原則選出一個可用的服務器，將請求發送到該服務器。

      LBLCR：LBLC with Replication，“帶復制的基于局部性最少鏈接”調度算法也是針對目標IP地址的負載均衡，目前主要用于Cache集群系統。它與LBLC算法的不同之處是它要維護從一個目標 IP地址到一組服務器的映射，而LBLC算法維護從一個目標IP地址到一臺服務器的映射。

                  該算法根據請求的目標IP地址找出該目標IP地址對應的服務器組，按“最小連接”原則從服務器組中選出一臺服務器，若服務器沒有超載，將請求發送到該服務器；若服務器超載，則按“最小連接”原則從這個集群中選出一臺服務器，將該服務器加入到服務器組中，將請求發送到該服務器。同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以降低復制的程度。

還有另外一種，但是不屬于ipvs cluster算法：FWM，FireWall Mark

   這一種發放時利用iptables，在PREROUTING鏈上，將規劃好的，哪種協議，發往哪個IP，哪個端口的報文，全都打上標記，當ipvs cluster收到報文的時候，查看到報文上有Firewall mask，將事先定義好的Firewall mask同類發往符合規則的后端集群Real server進行報文處理。   

   此種方法時借助于防火墻標記來分類報文，而后基于標記定義集群服務；可將多個不同的應用使用同一個集群服務進行調度。