LVS類型及其調度算法

LVS類型：
    NAT：-->(DNAT) (多目標的DNAT)
    DR：
    TUN：
    FULLNAT：

LVS NAT的特性
    1.RS的應該使用私有地址
    2.RS的網關必須指向DIP
    3.RIP和DIP必須在同一網段內
    4.請求和響應的報文都得經過Director,在高負載場景中,Director很可能成為性能瓶頸
    5.支持端口映射
    6.RS可以使用任意支持集群服務的OS

LVS DR類型
    1.讓前段路由將請求發往VIP時，只能是Dirctor上的VIP
        解決方案
        1.靜態地址綁定
            未必有路由器的配置權限
            Director高可用時靜態地址綁定將難以適用
        2.arptables(命令行工具):相當于iptables，限制ARP通告和應答
        3.修改linux內核參數,將RS上的VIP配置在lo接口的別名上,限制linux僅對對應接口的ARP請求做響應

    負載均衡器如何轉發:
        如果修改目標IP為RIP,則響應時源IP為RIP,此時客戶端并沒有請求RIP,所以不能使用RIP響應
        此時,負載均衡器中有規則;定義那個是集群服務器,其下有哪些real server;
        RIP1:MAC1
        RIP2:MAC2
        RIP3:MAC3
        此時,轉發時,會修改目標MAC地址

LVS DR類型的特性
    1.RS可以使用私有地址,還可以使用公網地址,此時可以直接通過互聯網連入RS,以實現配置,監控等
    2.RS的網關一定不能指向DIP(負載均衡器不負責響應報文的轉發)
    3.RS跟Dirctory(DIP)要在同一物理網絡內(基于MAC地址通信),(不能有路由器分隔)
    4.請求報文經過Directory,但響應報文一定不經過Director
    5.不支持端口映射
    6.RS可以使用大多數的操作系統

LVS TUN類型：IP隧道(IP報文中,還存在IP)(容災)
    1.RIP、DIP、VIP都得是公網地址
    2.RS的網關不會指向也不可能指向DIP
    3.請求報文經過Directory,但響應報文一定不經過Director
    4.不支持端口映射
    5.RS的OS必須得支持隧道功能

rs server 同樣有vip
用于響應(此時客戶端請求的vip,所以響應報文的源地址一定是vip)

LNS-FULLNAT類型：
    (需要向內核打補丁才可以使用)
    NAT模型缺陷:所有的real server和DIP必須在同一個網段內(real server的網關要指向DIP)
    DR模型缺陷:所有的real server直接暴露在互聯網上、各主機要位于同一物理網絡中
    fullnat:可以跨VLAN(網段),基于NAT實現

LVS的調度方法：10種
    靜態方法:僅根據算法本身進行調度
        rr：Round Robin 輪詢
        wrr：Weighted RR 權重輪詢(根據后端服務器的承載能力,性能)
        sh：source hashing   源地址hash(可以實現session綁定;背后仍是rr,wrr算法) (hash會話表)
            能夠將同一個IP地址的訪問,定向至同一個RS
        dh：destination hashing 目標地址hash(背后仍是rr,wrr算法)
                將發往同一個目標地址的請求始終轉發至第一次挑中的RS
                后端為緩存服務器(提高命中率)
            前端有多個防火墻時,為了保證從某一個防火墻進入,一定可以從該臺防火墻出去
     動態方法：根據算法及RS當前的負載狀況
         lc：Least Connection 最少連接(-c)
            計算當前的負載Overhead=Active*256+Inactive來實現
            TCP其中兩種狀態,活動連接和非活動連接
            活動連接占用資源多
            非活動連接占用資源少
         wlc：Weighted LC
            Overhead=(Active*256+Inactive)/weight(權重)
                        剛開始時默認為第一個提供服務
         sed：Shortest Expect Delay  最短期望延遲
            Overhead=(Active+1)*256/weight      
             nq：Nerver Queus： 永不排隊
                第一次請求給權重最大的
                第二次請求給權重第二的
                第三次請求給權重第三的
                ..
                然后使用sed算法(增強改進的sed算法)
         lblc：Locality-based least connection 基于本地的最少連接
                 相當于dh+lc
         Lblcr：基于復制的基于本地的最少連接 Replicated and Locality-based least connection (lblc with replication)
                   適用于后端是緩存服務器的場景
                       緩存多的服務器復制一部分緩存給另一個緩存少的服務器