LVS詳解

1、LVS介紹

簡介

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

通用體系結構

  LVS集羣採用IP負載均衡技術和基於內容請求分發技術。調度器具備很好的吞吐率,將請求均衡地轉移到不一樣的服務器上執行,且調度器自動屏蔽掉服 務器的故障,從而將一組服務器構成一個高性能的、高可用的虛擬服務器。整個服務器集羣的結構對客戶是透明的,並且無需修改客戶端和服務器端的程序,如下是體系結構圖(來源http://www.linuxvirtualserver.org/architecture.html):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鏈發日後端服務器。

2、負載均衡模式

LVS-NAT模式

簡介前端

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

具體工做流程:linux

說明:nginx

(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模式

簡介web

  全稱: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模式特色以及注意事項:centos

  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頭實現轉發,支持遠距離通訊

 

3、調度算法 

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那裏拿緩存,這是種緩存複製機制。

 

4、管理工具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)      每秒入流量(字節)

5、案例篇

環境

服務器系統:centos7.4
調度服務器DS:10.1.210.51
兩臺真實服務RS:10.1.210.5二、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

6、持久鏈接

什麼是持久鏈接

  在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
相關文章
相關標籤/搜索