lvs

lvs詳細介紹

LVS是Linux Virtual Server的簡寫，意即Linux虛擬服務器，是一個虛擬的服務器集羣系統。本項目在1998年5月成立，是中國國內最早出現的自由軟件項目之一。LVS採用IP負載均衡技術和基於內容請求分發技術。調度器具有很好的吞吐率，將請求均衡地轉移到不同的服務器上執行，且調度器自動屏蔽掉服務器的故障，從而將一組服務器構成一個高性能的、高可用的虛擬服務器。整個服務器集羣的結構對客戶是透明的，而且無需修改客戶端和服務器端的程序。

一、幾種集羣環境介紹

說lvs前先來說說集羣，根據所適用場景的不同，最常見的集羣有以下三種類型：負載均衡集羣（LB：Load Balance），高可用集羣（HA：High Availability），高性能集羣（HP：High Performance）。

1）LB集羣主要有應用層和傳輸層兩個層次上的實現，有硬件的實現，也有開源軟件的實現，硬件類型的LB設備主要有美國的F5的BIG/IP、思傑的NetScaler、A10、Array、RadWare，開源軟件的實現主要有LVS（工作在四層）、Haproxy(四層、七層都可實現，但主要是七層的實現)、nginx(應用層的實現)。

2）HA集羣中開源的解決方案主要有heartbeat、keepalived、corosync+pacemaker、cman+rgmanager、cman+pacemaker。

3）HP集羣使用在一些特殊的場景，爲高性能集羣。

4）DS：Distributed System，分佈式系統；hadoop，HDFS，GlusterFS，mogilefs

二、LVS各種類型介紹

常見的術語

vs：調試器，virtual server, Director, Dispatcher, Balancer

rs：後端服務器，real server, backend server, upstream server

CIP：Client IP，客戶端IP地址，即：請求發送方的IP地址；

VIP：Virtual Server IP，虛擬服務器的虛擬IP地址，客戶端訪問的目的地址；

DIP：Director IP，調度器IP地址，向後方Real Server轉發客戶端請求時使用的IP地址；

RIP：Real Server IP，後方真實服務器的IP地址；

LVS

LVS工作在OSI七層模型中的第四層，是四層交換技術，它是工作在內核中的一段代碼，根據目標地址和目標端口實現數據轉發，它並且是工作在netfiler框架上。LVS分爲兩個部份，一部份工作在內核，叫ipvs，另一部份工作在用戶空間，叫ipvsadmin，用此用戶空間工具編寫調度規則。

LVS的架構類型大體上分爲三種類型，一是VS/NAT，二是VS/DR，三是VS/TUN，四是lvs/fullnat。下邊分別對這幾種類型進行闡述。

1）lvs-nat

多目標IP地址的DNAT，通過將請求報文中的目標地址和目標端口修改爲某個利用調度算法挑選出來的後端RS的RIP和PORT的過程實現的轉發；

wKiom1nkqd3Tu8VzAAGp0krY9Mc499.png

調度的大致過程：

首先客戶端向director的vip發起服務請求，在netfiler框架上的INPUT鏈上ipvs發現客戶端請求的是自己定義好的集羣服務，那director採用靜態或動態算法從自己的規則中挑選出一個real server出來，再把客戶端請求報文做DNAT轉換，把請求報文的目的地址修改成已挑選出real server的ip地址，然後重新封裝報文發送給real server；而當real server收到director的請求報文後，就會分析此報文看對方請求的是什麼資源，再把資源準備好封裝成響應報文發送給director，director再做SNAT，把源地址修改成自己的vip地址後把報文發送給客戶端；在客戶端看來他是直接訪問的是director，而作出響應的也是director，其後端的real server對客戶端是不可見的，對用戶是透明的。

注意下列幾個問題：

1.RIP和DIP必須在同一網段，並且應該是私有IP地址；RS的網關應該指向DIP；

2.請求報文和響應報文都必須經過Director轉發，Director易於成爲系統性能瓶頸並引發單點故障；

3.可以實現端口重定向；CIP向VIP發送請求的端口號可以與後端的RIP所提供服務的服務端口不同；

4.VS必須是Linux系統，RS可以是任意操作系統；

2）lvs-dr：默認類型

dr：Direct Routing，直接路由；

通過爲請求報文重新封裝一個數據鏈路層首部(MAC地址)進行報文轉發；重新封裝之後的報文的源MAC地址是DIP所在網絡接口的MAC地址；目的MAC地址是某個利用調度算法挑選出來的後端RS的RIP所在接口的MAC地址；源IP地址和源PORT，以及目的IP地址和目的PORT，在整個報文轉發過程中保持不變；

wKioL1nkp4Dg8OowAAKu8Saz1dY125.png

調度大致過程：

客戶端請求報文到達director的vip後，director發現是請求是一個集羣服務，director採用靜態或動態算法挑選出一個real server，這時director不再像VS/NAT中會修改報文中ip首部的目標ip，而是把目標MAC修改成已挑選real server的rip的MAC地址，因dip與rip是在同一個二層網絡中，只需要MAC地址即可完成尋址，所以被修改了目的MAC的報文能成功送到real server，real server把報文拆開後發現目的MAC的確是rip上的MAC，所以它會處理這個報文，real server把客戶端要請求的資源準備好後，強行讓報文從“lo:0”這樣的子接口上送出去，這個接口配置了vip的地址，每個real server都會配置rip與vip的地址，所以爲了讓vip地址不會導致衝突，所以各real server都要採取一定的機制讓配置在"lo:0"上的vip地址不被網絡上的其他設備得知，這個地址只是用在響應報文中把響應報文的源地址封裝成vip的，這樣響應報文就可通過real server直接到達客戶端，而不必再通過director的再次轉發，這樣，接入的報文通過director，而響應報文則直接送到客戶端，而客戶端看到的報文也是從vip送回來的（其實是從real server來的），這種VS/DR模型讓director得到的解放，只處理接入報文，壓力也變得更小，能帶動的real server也更多，處理併發能力更強，但後端real server配置比較麻煩。

注意以下幾個問題：

1.確保前端路由器能夠將目標IP地址爲VIP的報文發往VS(Director)；

1) 在路由器上靜態綁定IP地址和MAC地址的映射關係；

2) 在RS上使用arptables；

3) 在RS上修改內核參數限制ARP的通告和對ARP請求的應答；

    arp_announce

    arp_ignore

2.RS的RIP可以是私有地址也可以是公有地址，RIP和DIP應該在同一邏輯網絡；

3.請求報文必須要經過Director，但是所有的響應報文不需要經過Director直接通過路由轉發給客戶端即可；

4.不支持端口重定向；

5.RS必須是Linux操作系統；

6.RS上必須配置RIP和VIP，並且VIP應該配置在lo接口的lable上；

3）lvs-tun：tunnel，隧道

不修改請求報文的IP首部(源IP爲CIP，目的IP爲VIP)，而是在原有的IP報文的封裝格式之外再次封裝一個IP首部(源IP爲DIP，目的IP爲RIP)，將重新封裝的報文發往使用調度算法挑選出的後端RS上；

wKiom1nkqn6DxPSjAAJ6cn9TrMQ891.png

調度的大致過程：

VS/TUN類型利用了IP隧道技術，把一個IP報文封裝了另一個IP報文，這可以使把目標爲一個IP的報文能封裝轉發到另一個IP地址。請求報文到達director後，director採用靜態或動態算法挑選一個在隧道上的real server地址，把原來的源地址爲cip，目標地址爲vip的ip報文又封裝在另一個IP報文上，把此IP報文送到隧道上轉以給real server，real server拆開報文看到目標地址是vip，而自己的“lo:0”接口上又配置了vip，所以能正常的處理此報文，將響應報文準備好後，又可直接送達到cip。

注意以下幾個問題：

1.CIP，VIP，DIP，RIP都應該是公有IP地址；

2.RS的網關無法指向DIP，因此響應報文不會經過Director轉發，而是直接發往CIP；

3.不支持端口重定向；

4.RS必須支持隧道協議；

5.RS上必須配置RIP和VIP；

4）lvs-fullnat

非標準類型；

通過同時修改請求報文的源IP地址和目的IP地址實現報文轉發；

    CIP --> DIP

    VIP --> RIP

注意以下幾個問題：

1.VIP是公有地址，DIP和RIP是私有地址，且DIP和RIP可以不在同一網段；

2.RS對收到的請求報文的響應報文的目的地址是DIP，所以請求報文和響應報文都必須經過Director；

3.支持端口重定向；

4.此類型默認不支持；

三、LVS各種調度算法介紹

根據lvs在調度時是否考慮各RS當前的負載狀態，可以將調度算法分爲兩類:

靜態調度算法:

僅根據調度算法本身進行調度。

1)rr：round robin(輪流，輪詢，輪叫)，這種算法是起點公平，但根據時間推移，各real server會產生負載不均衡的情況；

2)wrr：weighted round robin（加權的輪詢），用於real server服務器硬件性能不同時的場景；

3)sh：source hashing（源地址hash），表示來源於同一個cip的請求將始終被定向到同一個rs，使用在需要session保持的場景，但這種算法又打破了負載均衡的初衷；

4)dh：destination hashing(目標地址hash)，表示訪問同一地址的資源始終被定向到同一個real server，用在內部訪問外部網絡時有兩個出口（防火牆）時的特殊場景；

動態調度算法:

根據算法及各real server當前的負載狀況進行衡量計算後再進行調度。

1)lc：least connection(最少連接)，lc算法是把新的連接調度給當前連接數最小的real server；

Overhead(負載)=Active*256+Inactive，值越小，越先被調度到

2)wlc：weighted least connection（帶權重的最少連接）,此算法是lc算法的一個補充，各real server用一個權值來代表其處理能力，director儘可能使用其調度按照其權值的比例來調度，這是IPVS的默認算法；

Overhead(負載)=(Active*256+Inactive)/weighted，這種算法會導致一種現象，在集羣初始狀態時，各real server沒有活動連接，而在director的調度規則中把權重小的real server排在了前邊，那最開始director會調度到權重小的real server上，而在現實中我們希望是先調度到處理能力強的（權重大）real server上；

3)sed：shoutest expection delay(最短期望延遲)，表示讓在初始狀態時能讓director挑選到權重大的real server，即使是權重小的real server在director規則中的前邊，這種算法在各real server權重相差較大時會導致權重小的real server在一段時間內不會分配連接請求；

Overhead=(Active+1)*256/weight

4)nq：never queue(永不排隊)，表示在初始狀態時director會依據weight的大小至上而下的爲每一個RS分配一個連接，保證每一個real server都能在最短的時間內得到連接請求，解決了sed算法中real server有可能會在一段時間內不會分配到連接請求的問題；

5)lblc：Locality-Based Least Connection(基於局部性的最少連接)，此算法是針對請求報文的目標IP地址的負載均衡調度，目前主要用於Cache集羣系統；

6)lblcr：Replication lblc(帶複製功能的lblc)，此算法是針對請求報文的目標IP地址的負載均衡調度，目前主要用於Cache集羣系統。