LVS詳解

一、LVS介紹

簡介

    LVS是Linux Virtual Server的簡稱，即Linux虛擬服務器，創始人前阿里雲首席科學家章文嵩博士(現已經在滴滴)，官方網站： www.linuxvirtualserver.org。從內核版本2.4開始，已經完全內置了LVS的各個功能模塊，無需給內核打任何補丁，可以直接使用LVS提供的各種功能。通過LVS提供的負載均衡技術和Linux操作系統可實現一個高性能、高可用的服務器群集，它具有良好可靠性、可擴展性和可操作性，以低廉的成本實現最優的服務性能。

 

通用體系結構

　　LVS集群采用IP負載均衡技術和基於內容請求分發技術。調度器具有很好的吞吐率，將請求均衡地轉移到不同的服務器上執行，且調度器自動屏蔽掉服 務器的故障，從而將一組服務器構成一個高性能的、高可用的虛擬服務器。整個服務器集群的結構對客戶是透明的，而且無需修改客戶端和服務器端的程序，以下是體系結構圖（來源http://www.linuxvirtualserver.org/architecture.html）：

 

• 負載調度器（load balancer），它是整個集群對外面的前端機，負責將客戶的請求發送到一組服務器上執行。
• 服務器池（server pool），是一組真正執行客戶請求的服務器，可以是WEB、MAIL、FTP和DNS服務器等。
• 共享存儲（shared storage），它為服務器池提供一個共享的存儲區，這樣很容易使得服務器池擁有相同的內容，提供相同的服務，例如數據庫、分布式文件系統、網絡存儲等。

 優缺點

• 高並發連接：LVS基於內核網絡層面工作，有超強的承載能力和並發處理能力。單台LVS負載均衡器，可支持上萬並發連接。穩定性強：是工作在網絡4層之上僅作分發之用，這個特點也決定了它在負載均衡軟件里的性能最強，穩定性最好，對內存和cpu資源消耗極低。
• 成本低廉：硬件負載均衡器少則十幾萬，多則幾十萬上百萬，LVS只需一台服務器和就能免費部署使用，性價比極高。
• 配置簡單：LVS配置非常簡單，僅需幾行命令即可完成配置，也可寫成腳本進行管理。
• 支持多種算法：支持8種負載均衡算法，可根據業務場景靈活調配進行使用。
• 支持多種工作模型：可根據業務場景，使用不同的工作模式來解決生產環境請求處理問題。
• 應用范圍廣：因為LVS工作在4層，所以它幾乎可以對所有應用做負載均衡，包括http、數據庫、DNS、ftp服務等等。
• 缺點：工作在4層，不支持7層規則修改，機制過於龐大，不適合小規模應用。

組件和專業術語

組件：

• ipvsadm：用戶空間的客戶端工具，用於管理集群服務及集群服務上的RS等；
• ipvs：工作於內核上的netfilter INPUT鈎子之上的程序，可根據用戶定義的集群實現請求轉發；

專業術語：

• VS：Virtual Server ，虛擬服務
• Director： Balancer ，也叫DS(Director Server)負載均衡器、分發器
• RS：Real Server ，后端請求處理服務器，真實服務器
• CIP: Client IP ，客戶端IP
• VIP：Director Virtual IP ，負載均衡器虛擬IP
• DIP：Director IP ，負載均衡器IP
• RIP：Real Server IP ，后端請求處理的服務器IP

工作模型　　

VS工作在內核空間，基於內核包處理框架Netfilter實現的一種負責均衡技術，其在工作模式如上圖,大致過程：

1. 當客戶端的請求到達負載均衡器的內核空間時，首先會到達PREROUTING鏈。
2. 當內核發現請求數據包的目的地址是本機時，將數據包送往INPUT鏈。
3. LVS由用戶空間的ipvsadm和內核空間的IPVS組成，ipvsadm用來定義規則，IPVS利用ipvsadm定義的規則工作，IPVS工作在INPUT鏈上,當數據包到達INPUT鏈時，首先會被IPVS檢查，如果數據包里面的目的地址及端口沒有在規則里面，那么這條數據包將被放行至用戶空間。
4. 如果數據包里面的目的地址及端口在規則里面，那么這條數據報文將被修改目的地址為事先定義好的后端服務器，並送往POSTROUTING鏈。
5. 最后經由POSTROUTING鏈發往后端服務器。

二、負載均衡模式

LVS-NAT模式

簡介

　　NAT模式稱為全稱Virtualserver via Network address translation(VS/NAT)，是通過網絡地址轉換的方法來實現調度的。首先調度器(Director)接收到客戶的請求數據包時（請求的目的IP為VIP），根據調度算法決定將請求發送給哪個后端的真實服務器（RS）。然后調度就把客戶端發送的請求數據包的目標IP地址及端口改成后端真實服務器的IP地址（RIP）,這樣真實服務器（RS）就能夠接收到客戶的請求數據包了。真實服務器響應完請求后，查看默認路由（NAT模式下我們需要把RS的默認路由設置為DS服務器。）把響應后的數據包發送給DS,DS再接收到響應包后，把包的源地址改成虛擬地址（VIP）然后發送回給客戶端。

具體工作流程：

說明：

(1)當用戶請求到達DirectorServer，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP為CIP，目標IP為VIP。

(2) PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈。

(3) IPVS比對數據包請求的服務是否為集群服務，若是，修改數據包的目標IP地址為后端服務器IP，然后將數據包發至POSTROUTING鏈。 此時報文的源IP為CIP，目標IP為RIP ，在這個過程完成了目標IP的轉換（DNAT）。

(4) POSTROUTING鏈通過選路，將數據包發送給Real Server。

(5) Real Server比對發現目標為自己的IP，開始構建響應報文發回給Director Server。 此時報文的源IP為RIP，目標IP為CIP 。

(6) Director Server在響應客戶端前，此時會將源IP地址修改為自己的VIP地址（SNAT），然后響應給客戶端。 此時報文的源IP為VIP，目標IP為CIP。 

 

NAT模式優缺點：

1. NAT技術將請求的報文和響應的報文都需要通過DS進行地址改寫，因此網站訪問量比較大的時候DS負載均衡調度器有比較大的瓶頸，一般要求最多之能10-20台節點。
2. 節省IP，只需要在DS上配置一個公網IP地址就可以了。
3. 每台內部的節點服務器的網關地址必須是調度器LB的內網地址。
4. NAT模式支持對IP地址和端口進行轉換。即用戶請求的端口和真實服務器的端口可以不一致。 

 

地址變化過程：

LVS-DR模式

簡介

　　全稱：Virtual Server via Direct Routing(VS-DR)，也叫直接路由模式，用直接路由技術實現虛擬服務器｡當參與集群的計算機和作為控制管理的計算機在同一個網段時可以用此方法,控制管理的計算機接收到請求包時直接送到參與集群的節點｡直接路由模式比較特別，很難說和什么方面相似，前種模式基本上都是工作在網絡層上（三層），而直接路由模式則應該是工作在數據鏈路層上（二層）。

 

 

工作原理 

　　DS和RS都使用同一個IP對外服務。但只有DS對ARP請求進行響應，所有RS對本身這個IP的ARP請求保持靜默（對ARP請求不做響應），也就是說，網關會把對這個服務IP的請求全部定向給DS，而DS收到數據包后根據調度算法，找出對應的 RS，把目的MAC地址改為RS的MAC並發給這台RS。這時RS收到這個數據包，則等於直接從客戶端收到這個數據包無異，處理后直接返回給客戶端。由於DS要對二層包頭進行改換，所以DS和RS之間必須在一個廣播域，也可以簡單的理解為在同一台交換機上。

 

工作流程

說明：

1. 當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP為CIP，目標IP為VIP；
2. PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈；
3. IPVS比對數據包請求的服務是否為集群服務，若是，將請求報文中的源MAC地址修改為DIP的MAC地址，將目標MAC地址修改RIP的MAC地址，然后將數據包發至POSTROUTING鏈。 此時的源IP和目的IP均未修改，僅修改了源MAC地址為DIP的MAC地址，目標MAC地址為RIP的MAC地址；
4. 由於DS和RS在同一個網絡中，所以是通過二層，數據鏈路層來傳輸。POSTROUTING鏈檢查目標MAC地址為RIP的MAC地址，那么此時數據包將會發至Real Server；
5. RS發現請求報文的MAC地址是自己的MAC地址，就接收此報文。處理完成之后，將響應報文通過lo接口傳送給eth0網卡然后向外發出。 此時的源IP地址為VIP，目標IP為CIP；
6. 響應報文最終送達至客戶端。

地址變化過程

 

   DR模式特點以及注意事項：

1. 在前端路由器做靜態地址路由綁定，將對於VIP的地址僅路由到Director Server
2. 在arp的層次上實現在ARP解析時做防火牆規則，過濾RS響應ARP請求。修改RS上內核參數（arp_ignore和arp_announce）將RS上的VIP配置在網卡接口的別名上，並限制其不能響應對VIP地址解析請求。
3. RS可以使用私有地址；但也可以使用公網地址，此時可以直接通過互聯網連入RS以實現配置、監控等；
4. RS的網關一定不能指向DIP；
5. 因為DR模式是通過MAC地址改寫機制實現轉發,RS跟Dirctory要在同一物理網絡內（不能由路由器分隔）；
6. 請求報文經過Directory，但響應報文一定不經過Director
7. 不支持端口映射；
8. RS可以使用大多數的操作系統；
9. RS上的lo接口配置VIP的IP地址; 

 

LVS-  UN模式

介紹

    在VS/NAT 的集群系統中，請求和響應的數據報文都需要通過負載調度器，當真實服務器的數目在10台和20台之間時，負載調度器將成為整個集群系統的新瓶頸。大多數 Internet服務都有這樣的特點：請求報文較短而響應報文往往包含大量的數據。如果能將請求和響應分開處理，即在負載調度器中只負責調度請求而響應直 接返回給客戶，將極大地提高整個集群系統的吞吐量。

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

    在TUN模式下，利用IP隧道技術將請求報文封裝轉發給后端服務器，響應報文能從后端服務器直接返回給客戶。但在這里，后端服務器有一組而非一個，所以我們不可能靜態地建立一一對應的隧道，而是動態地選擇 一台服務器，將請求報文封裝和轉發給選出的服務器。

 

工作流程

1. 客戶端將請求發往前端的負載均衡器，請求報文源地址是CIP，目標地址為VIP。
2. 負載均衡器收到報文后，發現請求的是在規則里面存在的地址，那么它將在客戶端請求報文的首部再封裝一層IP報文,將源地址改為DIP，目標地址改為RIP,並將此包發送給RS。
3. RS收到請求報文后，會首先拆開第一層封裝,然后發現里面還有一層IP首部的目標地址是自己lo接口上的VIP，所以會處理次請求報文，並將響應報文通過lo接口送給eth0網卡直接發送給客戶端。注意：需要設置lo接口的VIP不能在共網上出現

地址變化過程

 

 

FULL-NAT模式

　　

介紹

    FULL-NAT模式可以實際上是根據LVS-NAT模式的一種擴展。在NAT模式下DS需要先對請求進行目的地址轉換(DNAT)，然后對響應包進行源地址轉換（SNAT），先后進行兩次NAT，而 FULL-NAT則分別對請求進行和響應進行DNAT和SNAT，進行4次NAT，當然這樣多次數的NAT會對性能大大削減，但是由於對請求報文的目的地址和源地址都進行了轉換，后端的RS可以不在同一個VLAN下。 

 

工作流程

　　

 

說明：

1. 首先client 發送請求package給VIP;
2. VIP 收到package后，會根據LVS設置的LB算法選擇一個合適的RS，然后把package 的目地址修改為RS的ip地址，把源地址改成DS的ip地址；
3. RS收到這個package后發現目標地址是自己，就處理這個package ，處理完后把這個包發送給DS；
4. DS收到這個package 后把源地址改成VIP的IP，目的地址改成CIP(客戶端ip)，然后發送給客戶端；

優缺點：

1. RIP，DIP可以使用私有地址；
2. RIP和DIP可以不再同一個網絡中，且RIP的網關未必需要指向DIP；
3. 支持端口映射；
4. RS的OS可以使用任意類型；
5. 請求報文經由Director，響應報文也經由Director；
6. FULL-NAT因為要經過4次NAT，所以性能比NAT還要低；
7. 由於做了源地址轉換，RS無法獲取到客戶端的真實IP； 

 

各個模式的區別 

lvs-nat與lvs-fullnat：請求和響應報文都經由Director

   　　lvs-nat：RIP的網關要指向DIP

  　　 lvs-fullnat：RIP和DIP未必在同一IP網絡，但要能通信

lvs-dr與lvs-tun：請求報文要經由Director，但響應報文由RS直接發往Client

  　　 lvs-dr：通過封裝新的MAC首部實現，通過MAC網絡轉發

  　　 lvs-tun：通過在原IP報文外封裝新IP頭實現轉發，支持遠距離通信

 

三、調度算法 

LVS在內核中的負載均衡調度是以連接為粒度的。在HTTP協議（非持久）中，每個對象從WEB服務器上獲取都需要建立一個TCP連接，同一用戶 的不同請求會被調度到不同的服務器上，所以這種細粒度的調度在一定程度上可以避免單個用戶訪問的突發性引起服務器間的負載不平衡。在內核中的連接調度算法上，IPVS已實現了以下八種調度算法：

• 輪叫調度rr（Round-Robin Scheduling）
• 加權輪叫調度wrr（Weighted Round-Robin Scheduling）
• 最小連接調度lc（Least-Connection Scheduling）
• 加權最小連接調度wlc（Weighted Least-Connection Scheduling）
• 基於局部性的最少鏈接LBLC（Locality-Based Least Connections Scheduling）
• 帶復制的基於局部性最少鏈接LBLCR（Locality-Based Least Connections with Replication Scheduling）
• 目標地址散列調度DH（Destination Hashing Scheduling）
• 源地址散列調度SH（Source Hashing Scheduling）

rr（輪詢）

　　輪詢調度：這種是最簡單的調度算法，調度器把用戶請求按順序1:1的分配到集群中的每個Real Server上，這種算法平等地對待每一台Real Server，而不管服務器的壓力和負載狀況。

wrr（權重, 即加權輪詢）

    加權輪叫調度（Weighted Round-Robin Scheduling）算法可以解決服務器間性能不一的情況，它用相應的權值表示服務器的處理性能，服務器的缺省權值為1。假設服務器A的權值為1，B的 權值為2，則表示服務器B的處理性能是A的兩倍。加權輪叫調度算法是按權值的高低和輪叫方式分配請求到各服務器。權值高的服務器先收到的連接，權值高的服 務器比權值低的服務器處理更多的連接，相同權值的服務器處理相同數目的連接數

sh（源地址哈希）

　　源地址散列：主要是實現將此前的session（會話）綁定。將此前客戶的源地址作為散列鍵，從靜態的散列表中找出對應的服務器，只要目標服務器是沒有超負荷的就將請求發送過去。就是說某客戶訪問過A,現在這個客戶又來了，所以客戶請求會被發送到服務過他的A主機。

dh（目的地址哈希）

　　目標地址散列調度（Destination Hashing Scheduling）算法也是針對目標IP地址的負載均衡，但它是一種靜態映射算法，通過一個散列（Hash）函數將一個目標IP地址映射到一台服務器。

lc（最少鏈接）

　　最小連接調度（Least-Connection Scheduling）算法是把新的連接請求分配到當前連接數最小的服務器。最小連接調度是一種動態調度算法，它通過服務器當前所活躍的連接數來估計服務 器的負載情況。調度器需要記錄各個服務器已建立連接的數目，當一個請求被調度到某台服務器，其連接數加1；當連接中止或超時，其連接數減一。

wlc（加權最少鏈接）LVS的理想算法

    加權最小連接調度（Weighted Least-Connection Scheduling）算法是最小連接調度的超集，各個服務器用相應的權值表示其處理性能。服務器的缺省權值為1，系統管理員可以動態地設置服務器的權 值。加權最小連接調度在調度新連接時盡可能使服務器的已建立連接數和其權值成比例。 

LBLC（基於局部性的最少連接）

　　這個算法主要用於Cache集群系統，因為Cache集群的中客戶請求報文的目標IP地址的變化，將相同的目標URL地址請求調度到同一台服務器，來提高服務器的訪問的局部性和Cache命中率。從而調整整個集群的系統處理能力。但是，如果realserver的負載處於一半負載，就用最少鏈接算法，將請求發送給活動鏈接少的主機。 

LBLCR（帶復制的基於局部性的最少鏈接）

　　該算法首先是基於最少鏈接的，當一個新請求收到后，一定會將請求發給最少連接的那台主機的。但這樣又破壞了cache命中率。但這個算法中，集群服務是cache共享的，假設A的PHP跑了一遍，得到緩存。但其他realserver可以去A那里拿緩存，這是種緩存復制機制。

 

四、管理工具ipvsadm使用

　　 ipvsadm是LVS的管理工具，ipvsadm工作在用戶空間，用戶通過ipvsadm命令編寫負載均衡規則。

安裝

yum install ipvsadm -y 
###文件說明
Unit 文件: ipvsadm.service
主程序：/usr/sbin/ipvsadm
規則保存工具：/usr/sbin/ipvsadm-save
規則重載工具：/usr/sbin/ipvsadm-restore
配置文件：/etc/sysconfig/ipvsadm-config

用法以及參數

ipvsadm --help #查看使用方法及參數
命令：
-A, --add-service： #添加一個集群服務. 即為ipvs虛擬服務器添加一個虛擬服務，也就是添加一個需要被負載均衡的虛擬地址。虛擬地址需要是ip地址，端口號，協議的形式。
-E, --edit-service： #修改一個虛擬服務。
-D, --delete-service： #刪除一個虛擬服務。即刪除指定的集群服務;
-C, --clear： #清除所有虛擬服務。
-R, --restore： #從標准輸入獲取ipvsadm命令。一般結合下邊的-S使用。
-S, --save： #從標准輸出輸出虛擬服務器的規則。可以將虛擬服務器的規則保存，在以后通過-R直接讀入，以實現自動化配置。
-a, --add-server： #為虛擬服務添加一個real server（RS）
-e, --edit-server： #修改RS
-d, --delete-server： #刪除
-L, -l, --list： #列出虛擬服務表中的所有虛擬服務。可以指定地址。添加-c顯示連接表。
-Z, --zero： #將所有數據相關的記錄清零。這些記錄一般用於調度策略。
--set tcp tcpfin udp： #修改協議的超時時間。
--start-daemon state： #設置虛擬服務器的備服務器，用來實現主備服務器冗余。（注：該功能只支持ipv4）
--stop-daemon： #停止備服務器。

 
參數：
以下參數可以接在上邊的命令后邊。
-t, --tcp-service service-address： #指定虛擬服務為tcp服務。service-address要是host[:port]的形式。端口是0表示任意端口。如果需要將端口設置為0，還需要加上-p選項（持久連接）。
-u, --udp-service service-address： #使用udp服務，其他同上。
-f, --fwmark-service integer： #用firewall mark取代虛擬地址來指定要被負載均衡的數據包，可以通過這個命令實現把不同地址、端口的虛擬地址整合成一個虛擬服務，可以讓虛擬服務器同時截獲處理去往多個不同地址的數據包。fwmark可以通過iptables命令指定。如果用在ipv6需要加上-6。
-s, --scheduler scheduling-method： #指定調度算法,默認是wlc。調度算法可以指定以下8種：rr（輪詢），wrr（權重），lc（最后連接），wlc（權重），lblc（本地最后連接），lblcr（帶復制的本地最后連接），dh（目的地址哈希），sh（源地址哈希），sed（最小期望延遲），nq（永不排隊）
-p, --persistent [timeout]： #設置持久連接，這個模式可以使來自客戶的多個請求被送到同一個真實服務器，通常用於ftp或者ssl中。
-M, --netmask netmask： #指定客戶地址的子網掩碼。用於將同屬一個子網的客戶的請求轉發到相同服務器。
-r, --real-server server-address： #為虛擬服務指定數據可以轉發到的真實服務器的地址。可以添加端口號。如果沒有指定端口號，則等效於使用虛擬地址的端口號。
[packet-forwarding-method]： #此選項指定某個真實服務器所使用的數據轉發模式。需要對每個真實服務器分別指定模式。
-g, --gatewaying： #使用網關（即直接路由），此模式是默認模式。
-i, --ipip： #使用ipip隧道模式。
-m, --masquerading： #使用NAT模式。
-w, --weight weight:  #設置權重。權重是0~65535的整數。如果將某個真實服務器的權重設置為0，那么它不會收到新的連接，但是已有連接還會繼續維持（這點和直接把某個真實服務器刪除時不同的）。
-x, --u-threshold uthreshold： #設置一個服務器可以維持的連接上限。0~65535。設置為0表示沒有上限。
-y, --l-threshold lthreshold： #設置一個服務器的連接下限。當服務器的連接數低於此值的時候服務器才可以重新接收連接。如果此值未設置，則當服務器的連接數連續三次低於uthreshold時服務器才可以接收到新的連接。
--mcast-interface interface： #指定使用備服務器時候的廣播接口。
--syncid syncid：#指定syncid， 同樣用於主備服務器的同步。
 
#以下選項用於list(-l)命令：
-c, --connection： #列出當前的IPVS連接。
--timeout： #列出超時
--stats： #狀態信息
--rate： #傳輸速率
--thresholds： #列出閾值
--persistent-conn： #持久連接
--sor： #把列表排序
--nosort： #不排序
-n, --numeric： #不對ip地址進行dns查詢
--exact： #單位
-6： 如#果fwmark用的是ipv6地址需要指定此選項。    
     
#如果使用IPv6地址，需要在地址兩端加上"[]"。例如：ipvsadm -A -t [2001:db8::80]:80 -s rr

LVS集群管理示例

####管理LVS集群中的RealServer舉例
1) 添加RS : -a
# ipvsadm -a -t|u|f service-address -r server-address [-g|i|m] [-w weight]
  
#舉例1: 往VIP資源為10.1.210.58的集群服務里添加1個realserver
ipvsadm -a -t 10.1.210.58 -r 10.1.210.52 –g -w 5

  
2) 修改RS : -e
# ipvsadm -e -t|u|f service-address -r server-address [-g|i|m] [-w weight]
  
#舉例2: 修改10.1.210.58集群服務里10.1.210.52這個realserver的權重為3
ipvsadm -e -t 10.1.210.58:80 -r 10.1.210.52 –g -w 3
  
3) 刪除RS : -d
# ipvsadm -d -t|u|f service-address -r server-address
  
#舉例3: 刪除10.1.210.58集群服務里10.1.210.52這個realserver
ipvsadm -d -t 10.1.210.58:80 -r 10.1.210.52


4) 清除規則 (刪除所有集群服務), 該命令與iptables的-F功能類似，執行后會清除所有規則:
# ipvsadm -C
  
5) 保存及讀取規則：
# ipvsadm -S > /path/to/somefile
# ipvsadm-save > /path/to/somefile
# ipvsadm-restore < /path/to/somefile


####管理LVS集群服務的查看
# ipvsadm -L|l [options]
   options可以為：
   -n：數字格式顯示
   --stats 統計信息
   --rate：統計速率
   --timeout：顯示tcp、tcpinfo、udp的會話超時時長
   -c：連接客戶端數量
  
#查看lvs集群轉發情況
# ipvsadm -Ln

  
#查看lvs集群的連接狀態
# ipvsadm -l --stats

  
說明：
Conns    (connections scheduled)  已經轉發過的連接數
InPkts   (incoming packets)       入包個數
OutPkts  (outgoing packets)       出包個數
InBytes  (incoming bytes)         入流量（字節）
OutBytes (outgoing bytes)         出流量（字節）
  
#查看lvs集群的速率
ipvsadm -l --rate
  
說明：
CPS      (current connection rate)   每秒連接數
InPPS    (current in packet rate)    每秒的入包個數
OutPPS   (current out packet rate)   每秒的出包個數
InBPS    (current in byte rate)      每秒入流量（字節）
OutBPS   (current out byte rate)      每秒入流量（字節）

五、案例篇

環境

服務器系統：centos7.4

調度服務器DS：10.1.210.51

兩台真實服務RS：10.1.210.52、10.1.210.53

VIP:10.1.210.58 

LVS-DR模式案例

　　 centos7默認已經將ipvs編譯進內核模塊，名稱為ip_vs,使用時候需要先加載該內核模塊。

以下步驟需要在DS上進行：

1.加載ip_vs模塊

modprobe ip_vs #加載ip_vs模塊
cat /proc/net/ip_vs #查看是否加載成功
lsmod | grep ip_vs   #查看加載的模塊
yum install ipvsadm # 安裝管理工具

2.配置調度腳本dr.sh

#!/bin/bash

VIP=10.1.210.58  #虛擬IP
RIP1=10.1.210.52 #真實服務器IP1
RIP2=10.1.210.53 #真實服務器IP2
PORT=80 #端口
ifconfig ens192:1 $VIP broadcast $VIP netmask 255.255.255.255 up #添加VIP,注意網卡名稱
echo 1 > /proc/sys/net/ipv4/ip_forward    #開啟轉發
 route add -host $VIP dev ens192:1    #添加VIP路由
/sbin/ipvsadm -C      #清空ipvs中的規則
/sbin/ipvsadm -A -t $VIP:80 -s wrr  #添加調度器
/sbin/ipvsadm -a -t $VIP:80 -r $RIP1 -g -w 1 #添加RS
/sbin/ipvsadm -a -t $VIP:80 -r $RIP2 -g -w 1 #添加RS
/sbin/ipvsadm -ln  #查看規則

3.執行腳本

[root@app51 ~]# sh dr.sh
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.1.210.58:80 wrr
  -> 10.1.210.52:80               Route   1      0          0         
  -> 10.1.210.53:80               Route   1      0          0 

 

以下步驟需要在RS上執行：

1.真實服務RS配置腳本rs.sh

#!/bin/bash
VIP=10.1.210.58  #RS上VIP地址
#關閉內核arp響應，永久修改配置參數到/etc/sysctl.conf，目的是為了讓rs順利發送mac地址給客戶端
 echo "1" >/proc/sys/net/ipv4/conf/lo/arp_ignore     
 echo "2" >/proc/sys/net/ipv4/conf/lo/arp_announce
 echo "1" >/proc/sys/net/ipv4/conf/all/arp_ignore
 echo "2" >/proc/sys/net/ipv4/conf/all/arp_announce
ifconfig lo:0 $VIP broadcast $VIP netmask 255.255.255.255 up  #綁定VIP到RS服務器上
/sbin/route add -host $VIP dev lo:0  #添加VIP路由

2.執行腳本

sh rs.sh

3.配置測試web服務（以一台為示例）

systemctl stop firewalld  #關閉防火牆
systemctl disable firewalld #禁止開機啟動
yum install httpd #安裝httpd


###RS1虛擬主機配置
vi /etc/httpd/conf/httpd.conf
ServerName 10.1.210.52:80
echo "RS 10.1.210.52" > /var/www/html/index.html

###RS2虛擬主機配置

vi /etc/httpd/conf/httpd.conf
ServerName 10.1.210.53:80
echo "RS 10.1.210.53" > /var/www/html/index.html

#啟動httpd服務
systemctl start httpd

測試

調度算法是輪訓，所以結果是交替出現 。

[root@node1 ~]# for i in {1..10} ;do curl http://10.1.210.58 ;done
RS 10.1.210.53
RS 10.1.210.52
RS 10.1.210.53
RS 10.1.210.52
RS 10.1.210.53
RS 10.1.210.52
RS 10.1.210.53
RS 10.1.210.52
RS 10.1.210.53
RS 10.1.210.52

LVS-NAT案例

　　LVS-NAT模式和DR區別要做nat，並且請求和響應都要經過DS，所有需要將RS網關指向DS,由於之前測試過DR模式，在測試NAT模式時候需要將RS環境恢復，RS恢復步驟如下：

echo 0 >/proc/sys/net/ipv4/conf/lo/arp_ignore     
echo 0 >/proc/sys/net/ipv4/conf/lo/arp_announce
echo 0 >/proc/sys/net/ipv4/conf/all/arp_ignore
echo 0 >/proc/sys/net/ipv4/conf/all/arp_announce
ifconfig lo:0 down

調度服務DS配置

#!/bin/bash

VIP=10.1.210.58  #虛擬IP
RIP1=10.1.210.52 #真實服務器IP1
RIP2=10.1.210.53 #真實服務器IP2
PORT=80 #端口
ifconfig ens192:1 $VIP broadcast $VIP netmask 255.255.255.255 up #添加VIP
echo 1 > /proc/sys/net/ipv4/ip_forward    #開啟轉發
 route add -host $VIP dev ens192:1    #添加VIP路由
/sbin/ipvsadm -C      #清空ipvs中的規則
/sbin/ipvsadm -A -t $VIP:80 -s wlc  #添加調度器
/sbin/ipvsadm -a -t $VIP:80 -r $RIP1 -m -w 1 #添加RS
/sbin/ipvsadm -a -t $VIP:80 -r $RIP2 -m -w 1 #添加RS
/sbin/ipvsadm -ln  #查看規則

RS配置

　　nat模式RS配置很簡單，只需要將RS路由指向DS

vi /etc/sysconfig/network-scripts/ifcfg-ens192 
GATEWAY=10.1.210.58 #修改網關至RS地址
systemctl restart network #重啟網絡

測試

　　 由於這里的環境DS和RS在同一個網段下，NAT模式下如果客戶端是同網段情況下，RS響應的時候直接響應給同網段的服務器了並不經過DS，這樣就導致客戶端會丟棄該請求。如果想要同網段的想要訪問到DS則需要添加路由，這里需要RS在響應同網段服務器時候網關指向DS，這樣同網段就能訪問到DS了，示例：

route add -net 10.1.210.0/24 gw 10.1.210.58

測試結果：

[root@app36 ~]# for i in {1..10} ; do curl http://10.1.210.58 ;done
RS 10.1.210.53
RS 10.1.210.52
RS 10.1.210.53
RS 10.1.210.52
RS 10.1.210.53
RS 10.1.210.52
RS 10.1.210.53
RS 10.1.210.52
RS 10.1.210.53
RS 10.1.210.52

六、持久連接

什么是持久連接

　　在LVS中，持久連接是為了用來保證當來自同一個用戶的請求時能夠定位到同一台服務器，目的是為了會話保持，而通常使用的會話保持技術手段就是cookie與session。

cookie與session簡述

　　 在Web服務通信中，HTTP本身是無狀態協議，不能標識用戶來源，當用戶在訪問A網頁，再從A網頁訪問其他資源跳轉到了B網頁，這對於服務器來說又是一個新的請求，之前的登陸信息都沒有了，怎么辦？為了記錄用戶的身份信息，開發者在瀏覽器和服務器之間提供了cookie和session技術，簡單說來在你瀏覽網頁時候，服務器建立session用於保存你的身份信息，並將與之對應的cookie信息發送給瀏覽器，瀏覽器保存cookie，當你再次瀏覽該網頁時候，服務器檢查你的瀏覽器中的cookie並獲取與之對應的session數據，這樣一來你上次瀏覽網頁的數據依然存在。

4層均衡負載導致的問題

　　由於cookie和session技術是基於應用層（七層）,而LVS工作在4層，只能根據IP地址和端口進行轉發，不能根據應用層信息進行轉發，所以就存在了問題。比如LVS集群RS是三台，A用戶登陸后請求在由第一台處理，而A用戶跳轉到了另一個頁面請求經過DS轉發到第二台服務器，但是此時這台服務器上並沒有session，用戶的信息就沒有了，顯然這是不能接受的。為了避免上述的問題，一般的解決方案有三種：

1. 將來自於同一個用戶的請求發往同一個服務器(例如nginx的ip_hash算法)；
2. 將session信息在服務器集群內共享，每個服務器都保存整個集群的session信息；
3. 建立一個session存，所有session信息都保存到存儲池中 ；

LVS會話保持實現方式就是通過將來自於同一個用戶的請求發往同一個服務器，具體實現分為sh算法和持久連接：

sh算法：使用SH算法，SH算法在內核中會自動維護一個哈希表，此哈希表中用每一個請求的源IP地址經過哈希計算得出的值作為鍵，把請求所到達的RS的地址作為值。在后面的請求中，每一個請求會先經過此哈希表，如果請求在此哈希表中有鍵值，那么直接定向至特定RS，如沒有，則會新生成一個鍵值，以便后續請求的定向。但是此種方法在時間的記錄上比較模糊（依據TCP的連接時長計算），而且其是算法本身，所以無法與算法分離，並不是特別理想的方法。

 

  持久連接：此種方法實現了無論使用哪一種調度方法，持久連接功能都能保證在指定時間范圍之內，來自於同一個IP的請求將始終被定向至同一個RS，還可以把多種服務綁定后統一進行調度。 

　　詳細一點說來：當用戶請求到達director時。無論使用什么調度方法，都可以實現對同一個服務的請求在指定時間范圍內始終定向為同一個RS。在director內有一個LVS持久連接模板，模板中記錄了每一個請求的來源、調度至的RS、維護時長等等，所以，在新的請求進入時，首先在此模板中檢查是否有記錄（有內置的時間限制，比如限制是300秒，當在到達300秒時依然有用戶訪問，那么持久連接模板就會將時間增加兩分鍾，再計數，依次類推，每次只延長2分鍾），如果該記錄未超時，則使用該記錄所指向的RS，如果是超時記錄或者是新請求，則會根據調度算法先調度至特定RS，再將調度的記錄添加至此表中。這並不與SH算法沖突，lvs持久連接會在新請求達到時，檢查后端RS的負載狀況，這就是比較精細的調度和會話保持方法。

 

LVS的三種持久連接方式

PCC：每客戶端持久；將來自於同一個客戶端的所有請求統統定向至此前選定的RS；也就是只要IP相同，分配的服務器始終相同。

 

PPC：每端口持久；將來自於同一個客戶端對同一個服務(端口)的請求，始終定向至此前選定的RS。例如：來自同一個IP的用戶第一次訪問集群的80端口分配到A服務器，25號端口分配到B服務器。當之后這個用戶繼續訪問80端口仍然分配到A服務器，25號端口仍然分配到B服務器。

 

PFMC：持久防火牆標記連接；將來自於同一客戶端對指定服務(端口)的請求，始終定向至此選定的RS；不過它可以將兩個毫不相干的端口定義為一個集群服務，例如：合並http的80端口和https的443端口定義為同一個集群服務，當用戶第一次訪問80端口分配到A服務器，第二次訪問443端口時仍然分配到A服務器。 

示例

　　LVS的持久連接功能需要定義在集群服務上面，使用-p timeout選項。

PPC：

[root@localhost ~]# ipvsadm -At 10.1.210.58:80 -s rr -p 300
  #上面命令的意思是：添加一個集群服務為10.1.210.58:80，使用的調度算法為rr，持久連接的保持時間是300秒。當超過300秒都沒有請求時，則清空LVS的持久連接模板。

PCC：

# ipvsadm -A -t 10.1.210.58:0 -s rr -p 600
# ipvsadm -a -t 10.1.210.58:0 -r 10.1.210.52 -g -w 2
# ipvsadm -a -t 10.1.210.58:0 -r 0.1.210.53 -g -w 1

PFMC：

######PNMPP是通過路由前給數據包打標記來實現的
# iptables -t mangle -A PREROUTING -d 10.1.210.58 -ens192 -p tcp --dport 80 -j MARK --set-mark 3
# iptables -t mangle -A PREROUTING -d 10.1.210.58 -ens192 -p tcp --dport 443 -j MARK --set-mark 3
# ipvsadm -A -f 3 -s rr -p 600
# ipvsadm -a -f 3 -r 10.1.210.52 -g -w 2
# ipvsadm -a -f 3 -r 10.1.210.52 -g -w 2