LVS-幾種負載方式的區別

LVS的原理很重要，很重要。每一個知識點都要做到熟記與腦，謹記于心，張口就來。

LVS是Linux Virtual Server的簡寫，意即Linux虛擬服務器，是一個虛擬的服務器集群系統。本項目在1998年5月由章文嵩博士成立，是中國國內最早出現的自由軟件項目之一。

很好的可管理性（Manageability）

………..

總之就是一個字–好（大拇指）

閑話不多講，先從lvs的模式開始–>

lvs四種類型：
1.lvs-nat

2.lvs-dr

3.lvs-tun

4.lvs-fullnat

前三個是標準類型  后一種后加入的  可能內核默認不支持 （不要問我為啥不支持，我現在不知道）

lvs-nat  ：修改請求報文的目標ip或者目標端口  多目標的DNAT。
為挑選出某些RS的RIP和PORT來實現
nat特點：
1、各RS的IP應該指向DIP（目標IP）
2、請求或者響應報文都要經由director（調度器）轉發；

3、支持端口映射
4、VS必須為linux系統 RS任意

這個模式存在一個問題：因為是請求和響應報文都要經由director，那么如果用戶的并發量超過了調度器負載性能，就會造成調度器陷入癱瘓，影響用戶體驗。
借圖一用–>

lvs-dr 
轉發方式：修改請求報文的MAC地址進行轉發；IP首部不會發生變化的
（源IP為CIP，目標IP始終為VIP）
dr特點：
  1、確保前端路由器將目標IP為VIP的請求報文一定會發送給dIRECTOR 
解決方案有三種：
       1）.在前端路由做靜態綁定：不好  影響后期高可用實現
       2）. iptables：定義規則
       3）. 禁止RS響應VIP的ARP的請求：
       用調度器 修改內核參數，把VIP配置在特定的接口上實現禁止其響應 （回環lo網卡）
   2、RS的RIP可以使用私有或者公有地址
   3、RS和director必須在同一物理網絡中 （比如都是網絡）
   4、請求報文必須由director調度，但是響應報文必須不能經由director
   5、不支持端口映射
   6、各RS可以使用大多的操作系統

   3.lvs-tun：ip隧道
   轉發方式：不修改請求報文的IP首部，而是在原有的IP首部外在次封裝一個IP首部；請求報文經由director；響應報文一定不能經由director
   注意：封裝了兩個IP首部的報文大小不要超過MTU:

   特點：
1、RIP,DIP，VIP全得是公網地址
2、RS的網關不能也不可能指向DIP；
3、不支持端口映射
4、請求報文經由director調度但響應報文將直接發給CIP
5、RS的操作系統必須支持IP隧道功能

4、lvs-fullnat
轉發方式：通過同時修改請求報文的源IP地址（CIP–>DIP）和目標IP地址（VIP–>RIP）實現轉發
特點：
1、VIP是公網地址，RIP，DIP是私網地址，且可以不在同一IP網絡中，但需要通過路由互相通信；
2、RS收到請求報文的源IP為DIP，因此其響應報文將發給DIP
3、請求報文和響應報文都必須經由direcr
4、支持端口映射
5、RS可使用任意操作系統

lvs調度算法一共有十種：
靜態算法：僅根據算法本身進行調度。
存在的無情問題-不考慮當前RS的負載性能強弱

1)RR–輪詢 （比如1.2.3.4–>1.2.3.4.）
2)WRR–加權輪詢  比權重  那個權重數高，負載性能好先用那個
3)SH–源地址哈希  實現session保持  存在的問題-調度力度太大，負載均衡的效果差
4）DH– 目標地址哈希  根據請求的目標ip實現定向轉發負載性能較差

  正向web代理，負載均衡內網用戶對互聯網的請求
  Cinent–>Director–>Web Cache Servers (正向代理)

動態算法：即根據算法又根據各RS當前的負載狀態進行調度；
 overhead  負載值；負載值一樣時自上而下輪詢
LC  

最少連接 
存在的問題也：就說調度器會首選選擇RS服務請求并發數最少的那個，即使它的性能很差
      算法：Overhead=Actice*256+Inatice
            負載值=活動鏈接*256+非活動連接
              RS1: 10, 1000
               RS2: 20, 10

WLC 

加權最少連接；
存在的問題：當orverload為0時可能會出現權重小的服務器響應新請求；
   overhead=(actice*256+Inactive)/weight
      RS1: 10, 100, 1
      RS2: 20, 10, 3

SED  

最短期望延遲  也就是WLC的算法改進版

存在的問題：當多個RS之間的權重比較大時會出現RS空閑的情況
   overhead=(Active+1)*256/weight
      RS1: 0,  9
      RS2: 0,  1

NQ:

NerverQueue:SED算法的改進，即當有用戶請求涌入時服務器根據服務器權重由大到小依次先分配1個請求而后再按照SED算法調度；

LBLC：

基于本地的最少連接；動態的DH算法，即考慮當前服務器負載狀態的DH算法，把新請求調度到負載少的服務器上，從而盡可能的實現服務器間負載的均衡；

存在的問題：當新請求很少而且客戶端重復大量訪問某個熱門服務時會出現嚴重負載不均衡的場景
   Client –> Director –> Web Cache Server(正向代理)

 LBLCR：帶復制功能的LBLC；
 通過服務器間緩存復制實現本應該從高負載的A緩存服務器回應某些客戶請求轉換為從低負載的B服務器回應他們請求，進而實現后續他們的請求都從B服務器而不從A服務器回應，最終實現負載均衡；

 ipvs集群服務工作機制：四層交換（四層路由，直接工作在內核上）
 ipvs支持基于TCP，UDP，SCTP，AH，ESP，AH_ESP等協議的眾多服務；
 1.一個ipvs主機可以同時定義多個集群服務；
 2.一個ipvs服務至少應該一個RS；
       通過防火墻標記可以實現把多個端口綁定在一起進而實現將多個集群服務定義為一個集群服務而應用同一個調度邏輯。

管理集群服務命令用法：
增、刪、改、查
ipvsadm -A|E -t|u|f service-address [-s scheduler] [-p [timeout]] [-Mnetmask] [-b sched-flags]
-A：添加一個集群服務
-E：修改已添加的集群服務
-t：TCP協議
-U: UDP協議
-f：防火墻標記
-s：調度方法，默認為WLC
-p: 持久連接
-D: 刪除服務

管理集群上的RS
-a：向指定的CS中添加RS
-e：修改RS
-r：只有支持端口映射的LVS類型才允許此處使用跟集群服務中不同的端口

指明LVS工作類型
-q: 即dr模式
-i：tun模式
-m：nat模式
-w：指定權重

查看
ipvsadm -L | 11 [options]
  -n,–numberic;數字格式顯示IP和PORT
    –exact:精確值
  -c，–connection;顯示IPVS連接
   -stats;統計數據
   -rate;速率

 清空
 ipvsadm -C 按下Enter鍵-非常自然

 清空計數器
 ipsadm -Z [-t|u|f service-address]

 存儲和重載
主程序：/usr/sbin/ipvsadm
主程序：/usr/sbin/ipvsadm
規則保存工具：/usr/sbin/ipvsadm-save
規則重載工具：/usr/sbin/ipvsadm-restore
配置文件：/etc/sysconfig/ipvsadm-config