LVS的詳細應用

LVS是Linux Virtual Server的簡寫, 意思是Linux虛擬服務器, 是一個虛擬的服務器集群系統.

LVS的宗旨:

   1. 使用集群技術和Linux操作系統實現一個高性能, 高可用的服務器;

   2. 很好的可伸縮性(Scalability);

   3. 很好的可靠性(Reliability);

   4. 很好的可管理性(Manageability).

LVS的集群組成

   LVS采用三層結構, 主要組成部分有:

        (1) 負載調度器(load balancer), 它是整個集群對外的前端機, 負責將客戶的請求發送到一組服務器上執行, 而客戶端認為服務使來自一個IP地址上的. 負責調度器有許多稱呼, 例如Virtual Server, Director, Dispatcher, Balancer等.

        (2) 服務器池(server pool), 是一組真正執行客戶請求的服務器, 執行的服務有WEB,MAIL,FTP和DNS等.

        (3) 共享存儲(shared storage), 它為服務器池提供一個共享存儲區, 這樣很容易使得服務器池擁有相同的內容, 提供相同的服務.

lvs集群的類型

    1. lvs-nat: 

    多目標IP的DNAT, 通過將請求報文中的目標地址和目標端口修改為某挑選出的RS的RID和PORT實現轉發.

    要點:

        (1) RIP和DIP必須在同一個IP網絡, 且應該使用私網地址; RS的網關要指向DIP;

        (2) 請求報文和響應報文都必須經由Director轉發; Director易于成為系統瓶頸;

        (3) 支持端口映射, 可修改請求報文的目標PORT;

        (4) vs必須是linux系統, rs可以是任意系統;

    2. lvs-dr: 

    通過為請求報文重新封裝一個MAC首部進行轉發, 源MAC是DIP所在的接口的MAC, 目標MAC是某挑選出的RS的RIP所在接口的MAC地址; 源IP/PORT以及目標IP/PORT均保持不變; 并且Director和各RS都要配置使用VIP

    要點:

        (1) 確保前段路由器將目標IP為VIP的請求報文發往Director;

               解決方法:

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

                   (b) 在RS上使用arptables;

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

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

        (3) RS跟Director要在同一個物理網絡;

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

        (5) 不支持端口映射;

    3. lvs-tun: 

    轉發方式: 不修改請求報文的IP首部(源IP為CIP, 目標IP為VIP), 而在源IP報文之外再封裝一個IP首部(源IP是DIP, 目標IP是RIP), 將報文發往挑選出的目標RS;

    要點:

    (1) DIP, VIP, RIP都應該是公網地址;

    (2) RS的網關不能, 也不可能指向DIP;

    (3) 請求報文要經由Director, 但響應不能經由Director;

    (4) 不支持端口映射;

    (5) RS的OS得支持隧道功能;

    4. lvs-fullnat:

    通過同時修改請求報文的源IP地址和目標IP地址進行轉發;

    要點:

        (1) VIP是公網地址，RIP和DIP是私網地址，且通常不在同一IP網絡；因此，RIP的網關一般不會指向DIP；

        (2) RS收到的請求報文源地址是DIP，因此，只需響應給DIP；但Director還要將其發往Client；

        (3) 請求和響應報文都經由Director；

        (4) 支持端口映射；

ipvs scheduler,調度方法

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

    1. 靜態方法: 僅根據算法本身進行調度;

        RR: 輪詢調度;

        輪詢調度算法的原理是每一次把來自用戶的請求輪流分配內部中的服務器, 從1開始, 直到N(內部服務器個數), 然后重新開始循環. 算法的優點是其簡潔性, 它無需記錄當前所有連接的狀態, 所以是一種無狀態調度.

        WRR: weight RR,加權輪詢, 以權重之間的比例實現各主機之間進行調度.

        由于每臺服務器的配置, 安裝的也業務應用等不同, 其處理能力會不一樣. 所以, 我們根據服務器的不同處理能力, 給每個服務器分配不同的權值, 使其能夠接受相應權值數的服務請求.

        SH: source hashing, 源地址散列. 主要實現session sticky(會話綁定)

        源地址散列調度算法正好與目標地址散列調度算法相反, 它根據請求的源IP地址, 作為散列鍵(Hash Key)從靜態分配的散列表找出對應的服務器, 若該服務器是可用的并且沒有超負荷, 將請求發送到該服務器, 否則返回空. 它采用的散列函數與目標地址散列調度算法的相同. 它的算法流程與目標地址散列調度算法的基本相似, 除了將請求的目標IP地址換成請求的源IP地址.

        DH: Destination Hashing, 目標地址散列,把同一個IP地址的請求, 發送給同一個server.

        源地址散列調度算法是針對目標IP地址的負載均衡, 它是一種靜態映射算法, 通過一個散列(hash)函數將一個目標IP地址映射到一臺服務器. 目標地址散列調度算法先根據請求的目標IP地址, 所謂散列鍵(Hash Key)從靜態分配的散列表找出對應的服務器, 若該服務器是可用的且未超載, 將請求發送到該服務器, 否則返回空.

    2. 動態算法

        LC: Least Connection, 最少連接

        最少連接調度算法是把新的連接請求分配到當前連接數最小的服務器, 最小連接調度是一種動態調度短算法, 它通過服務器當前所活躍的連接數來估計服務器的負載均衡, 調度器需要記錄各個服務器已建立連接的數目, 當一個請求調度到某臺服務器, 其連接數加1, 當連接中止或超時, 其連接數減一, 在系統實現時, 我們也引入當服務器的權值為0時, 表示該服務器不可用而不被調度.

        算法 Overhead=activeconns*256+inactiveconns, 挑小的調度

        WLC: Weight LC, 加權最小連接

        加權最小連接調度算法時最小連接調度的超集, 各個服務器用相應權值表示其處理性能. 服務器的缺省權值為1, 系統管理員可以動態的設置服務器的權值, WLC在調度新的連接時可能使服務器的已建立連接數和其權值成比例.

        算法: overhead=(activeconns*256+inactiveconns)/weight, 挑選小的調度.

        SED: Shortest Expected Delay, 最短期望延遲

        基于WLC的算法

        算法: overhead=(activeconns+1+*256/weight, 挑選小的調度.

        NQ: never queue, 永不排隊, 改進的sed

        無須隊列, 如果有臺real server的連接數=0, 就直接分配過去, 不需要進行sed運算.

        LBLC: (Locality-Based Least Connections with Replication), 帶復制的基于局部性最少鏈接.

        帶復制的基于局部性最少鏈接調度算法也是針對目標IP地址的負載均衡, 該算法根據請求的目標IP地址找出該目標IP地址對應的服務器組, 按"最小連接"原則從服務器組中選出一臺服務器, 若服務器沒有超載, 將請求發送到該服務器; 若服務器超載, 則按"最小連接"原則從這個集群中選出一臺服務器, 將該服務器加入到服務器組中, 將請求發送到該服務器. 同時, 當該服務器組有一段時間沒有被修改, 將最忙的服務器從服務器組中刪除, 以降低復制的程度.

ipvsadm常用命令

總覽:

ipvsadm -A|E -t|u|f service-address [-s scheduler] [-p [timeout]] [-M netmask] [–pe persistence_engine] [-b sched-flags]

ipvsadm -D -t|u|f service-address

ipvsadm -C

ipvsadm -R

ipvsadm -S [-n]

ipvsadm -a|e -t|u|f service-address -r server-address [options]

ipvsadm -d -t|u|f service-address -r server-address

ipvsadm -L|l [options]

ipvsadm -Z [-t|u|f service-address]

    1. 集群管理服務

       添加:

       ipvsadm -A  -t|u|f service-address [-s scheduler] [-p [timeout]] 

       -t : tcp協議的集群服務

       -u : udp協議的集群服務

       -f : FWM防火墻標記

       [-s scheduler] : 指定集群的調度算法, 默認wlc

       修改

       ipvsadm -E -t|u|f service-address [-s scheduler] [-p [timeout]]

       刪除

       ipvsadm -D -t|u|f  service-address

    2. 管理集群上的RS

           增加, 修改           

           ipvsadm -a|e -t|u|f service-address -r server-address [-g|i|m] [-w weight]

           刪除

           ipvsadm -d -t|u|f service-address -r server-address

           service-address : rip:port

           lvs類型:

               -g : gateway, dr類型

               -i : ipip, tun類型

               -m : masquerade, nat類型

               -w weight : 權重

    3. 清空定義的所有內容

        ipvsadm -C

    4. 查看

        ipvsadm -L|l [options]

        –numeric, -n：numeric output of addresses and ports 

        –exact：expand numbers (display exact values)

        –connection， -c：output of current IPVS connections

        –stats：output of statistics information

        –rate ：output of rate information

FWM : 

    Firewall Mark, 借助防火墻標記來分類報文, 而后基于標記定義集群服務, 可將多個不同的應用使用同一個集群服務進行調度.

    打標記方法（在Director主機）：

        iptables -t mangle -A PREROUTING -d $vip -p $proto –dport $port -j MARK –set-mark NUMBER 

    基于標記定義集群服務：

        ipvsadm -A -f NUMBER [options]

lvs persistence：持久連接

    持久連接模板：實現無論使用任何算法，在一段時間內，實現將來自同一個地址的請求始終發往同一個RS；

        ipvsadm -A|E -t|u|f service-address [-s scheduler] [-p [timeout]]

    port Affinity：

        每端口持久：每集群服務單獨定義，并定義其持久性；

        每防火墻標記持久：基于防火墻標記定義持久的集群服務；可實現將多個端口上的應用統一調度，即所謂的port Affinity；

        每客戶端持久：基于0端口定義集群服務，即將客戶端對所有應用的請求統統調度至后端主機，而且可使用持久連接進行綁定；

lvs-nat和lvs-dr模型的詳細闡述

1. lvs-nat模型

客戶端的地址為CIP, Director的外網地址為VIP, 內網地址為DIP, RS的地址為RIP

流程: 客戶端發送請求報文, 報文首部的目標地址為VIP, 源地址為CIP, 請求報文地址指向VIP; 當報文到達Director后,  經過算法選擇出RS, 將請求報文首部的目標地址重新封裝為RIP, 經由DIP轉發給RS. 當RS生成響應報文的時, 報文的首部封裝的源地址為RIP, 目標地址為CIP, 將響應報文發送給Director, 經過DIP之后, 將響應報文的源地址更改為VIP后, 發送給VIP, 完成一次負載均衡.

2. lvs-dr模型

客戶端地址為CIP, Director地址為VIP, RS地址為RIP; 

流程:

    (1) 客戶端通過路由交換的公網與Director和RS相連接, 并且Director和RS連接在同一個交換機上. 當客戶端發送給Director請求報文之后, Director通過算法選擇出RS, 將請求報文發送給挑選出的RS, RS生成響應報文之后, 直接將響應報文發送給客戶端, 不再經過Director, 從而降低了Director的負載, 提高了負載均衡的能力.

    (2) 那么, 問題來了, Director和RS都在同一個網絡, 怎么保證, 客戶端發送的請求報文發給Director, 不會發給RS呢, 并且所有的RS生成的響應報文能直接發送給客戶端呢? 

    一般將Director的網卡上綁定兩個IP, 一個VIP, 用以接收客戶端的請求報文; 一個DIP, 用以向RS轉發報文; 在RS的外網網卡上綁定RIP, 用以接收轉發報文, 同時在loopback網卡上綁定VIP, 用以發送響應報文時封裝報文首部的源地址使用, 那么, 怎么保證, Director和RS的VIP不會產生網絡沖突呢, 并且客戶端發送的響應報文不會發送給RS呢? 一般有三種方式解決:

        (I) 在前端網關做靜態綁定;

        (II) 在RS上使用arp-tables, 配合(I) 使用;

        (III) 在RS上修改內核參數, 以限制arp的響應和應答級別.

    一般使用第三種方式.

    限制響應級別: arp_ignore

        0 : 默認值, 表示可使用本地任意接口上配置的任意地址進行響應

        1 : 僅在請求的目標IP配置在本地主機的接口收到請求報文接口上時, 才給與響應; 1是我們的期望值;

    限制通告級別: arp_announce

        0 : 默認值, 把本機上的所有接口的所有信息向每個接口上的網絡進行通告;

        1 : 盡量避免向非直接連接網絡進行通告;

        2 : 期望值; 盡量避免向非本網絡通告;