LVS 介紹以及配置應用

 

1、負載均衡集羣介紹

1.1、什麼是負載均衡集羣

負載均衡集羣提供了一種廉價、有效、透明的方法，來擴展網絡設備和服務器的負載、帶寬、增長吞吐量、增強網絡數據的處理能力、提升網絡的靈活性和可用性

搭建負載均衡器的需求：

1）把單臺計算機沒法承受的大規模的併發訪問或數據流量分擔到多臺節點設備上分別處理，減小用戶等待時間，提高用戶體驗

2）單個重負載的運算分擔到多臺節點設備上作並行處理，每一個節點設備處理結束後，將結果彙總，返回給用戶，系統處理能力獲得大幅度的提升。

3）7*24的服務保證，任意一個或多個有限後面節點設備宕機，要求不能影響業務。

在負載均衡器集羣中，全部的計算節點都應該提供相同的服務。集羣負載均衡獲取全部對該服務的入站要求，而後將這些請求儘量的平均分配在全部集羣節點上。

1.2、常見的負載均衡器

a 根據工做在的協議層劃分可劃分爲：

1.四層負載均衡（位於內核層）：根據請求報文中的目標地址和端口進行調度

2.七層負載均衡（位於應用層）：根據請求報文的內容進行調度，這種調度屬於「代理」的方式

b 根據軟硬件劃分：

硬件負載均衡：

1.F5 的 BIG-IP

2.Citrix 的 NetScaler

3.這類硬件負載均衡器一般能同時提供四層和七層負載均衡，但同時也價格不菲

軟件負載均衡：

1.TCP 層：LVS，HaProxy，Nginx

2.基於 HTTP 協議：Haproxy，Nginx，ATS（Apache Traffic Server），squid，varnish

3.基於 MySQL 協議：mysql-proxy

 

2、LVS（Linux Virtual Server）介紹

　Internet的快速增加使多媒體網絡服務器面對的訪問數量快速增長，服務器須要具有提供大量併發訪問服務的能力，所以對於大負載的服務器來說， CPU、I/O處理能力很快會成爲瓶頸。因爲單臺服務器的性能老是有限的，簡單的提升硬件性能並不能真正解決這個問題。爲此，必須採用多服務器和負載均衡技術才能知足大量併發訪問的須要。Linux 虛擬服務器(Linux Virtual Servers,LVS) 使用負載均衡技術將多臺服務器組成一個虛擬服務器。它爲適應快速增加的網絡訪問需求提供了一個負載能力易於擴展，而價格低廉的解決方案。

LVS (Linux Virtual Server)實際上是一種集羣(Cluster)技術，採用IP負載均衡技術（LVS 的 IP 負載均衡技術是經過 IPVS 模塊來實現的，linux內核2.6版本以上是默認安裝IPVS的）和基於內容請求分發技術。調度器具備很好的吞吐率，將請求均衡地轉移到不一樣的服務器上執行，且調度器自動屏蔽掉服務器的故障，從而將一組服務器構成一個高性能的、高可用的虛擬服務器。整個服務器集羣的結構對客戶是透明的，並且無需修改客戶端和服務器端的程序。

LVS負載均衡調度技術是在LINUX內核中實現的，所以被稱之爲LINUX虛擬服務器。咱們使用該軟件配置LVS時候，不能直接配置內核中的IPVS，而須要使用IPVS的管理工具ipvsadm進行管理，固然咱們也能夠經過keepalived軟件直接管理IPVS，並非經過ipvsadm來管理ipvs。

LVS項目介紹

http://www.linuxvirtualserver.org/zh/lvs1.html 

LVS集羣的體系結構

http://www.linuxvirtualserver.org/zh/lvs2.html 

LVS集羣中的IP負載均衡技術 http://www.linuxvirtualserver.org/zh/lvs3.html
LVS集羣的負載調度

http://www.linuxvirtualserver.org/zh/lvs4.html 

 

LVS技術點小結：

一、真正實現調度的工具是IPVS，工做在LINUX內核層面。

二、LVS自帶的IPVS管理工具是ipvsadm。

三、keepalived實現管理IPVS及負載均衡器的高可用。

四、Red hat 工具Piranha WEB管理實現調度的工具IPVS（不經常使用）。

3、LVS集羣的結構

LVS由前端的負載均衡器(Load Balancer，LB)和後端的真實服務器(Real Server，RS)羣組成。RS間可經過局域網或廣域網鏈接。LVS的這種結構對用戶是透明的，用戶只能看見一臺做爲LB的虛擬服務器(Virtual Server)，而看不到提供服務的RS羣。當用戶的請求發往虛擬服務器，LB根據設定的包轉發策略和負載均衡調度算法將用戶請求轉發給RS。RS再將用戶請求結果返回給用戶。 　

Ø  負載調度器(load balancer/ Director)，它是整個集羣對外面的前端機，負責將客戶的請求發送到一組服務器上執行，而客戶認爲服務是來自一個IP地址(咱們可稱之爲虛擬IP地址)上的。

Ø  服務器池(server pool/ Realserver)，是一組真正執行客戶請求的服務器，執行的服務通常有WEB、MAIL、FTP和DNS等。

Ø  共享存儲(shared storage)，它爲服務器池提供一個共享的存儲區，這樣很容易使得服務器池擁有相同的內容，提供相同的服務。

　

4、LVS內核模型

1.當客戶端的請求到達負載均衡器的內核空間時，首先會到達PREROUTING鏈。

2.當內核發現請求數據包的目的地址是本機時，將數據包送往INPUT鏈。

3.LVS由用戶空間的ipvsadm和內核空間的IPVS組成，ipvsadm用來定義規則，IPVS利用ipvsadm定義的規則工做，IPVS工做在INPUT鏈上,當數據包到達INPUT鏈時，首先會被IPVS檢查，若是數據包裏面的目的地址及端口沒有在規則裏面，那麼這條數據包將被放行至用戶空間。

4.若是數據包裏面的目的地址及端口在規則裏面，那麼這條數據報文將被修改目的地址爲事先定義好的後端服務器，並送往POSTROUTING鏈。

5.最後經由POSTROUTING鏈發日後端服務器。

5、LVS的工做模式（包轉發模型）

負載均衡技術有不少實現方案，有基於 DNS 域名輪流解析的方法、有基於客戶端調度訪問的方法、有基於應用層系統負載的調度方法，還有基於 IP 地址的調度方法，在這些負載調度算法中，執行效率最高的是IP 負載均衡技術。

LVS 的 IP 負載均衡技術是經過 IPVS 模塊來實現的，IPVS 是 LVS集羣系統的核心軟件，它的主要做用是：安裝在 Director Server 上，同時在 Director Server上虛擬出一個 IP 地址，用戶必須經過這個虛擬的 IP 地址訪問服務器。這個虛擬 IP 通常稱爲 LVS 的VIP，即 Virtual IP。訪問的請求首先通過 VIP 到達負載調度器，而後由負載調度器從 Real  Server 列表中選取一個服務節點響應用戶的請求。 在用戶的請求到達負載調度器後，調度器如何將請求發送到提供服務的 Real Server 節點，而 Real Server節點如何返回數據給用戶，是 IPVS 實現的重點技術。

爲了更好的理解LVS工做模式，咱們能夠約定一些名詞

其中DR模式中重點。其餘瞭解便可。

5.1、NAT模型

a 原理圖

①.客戶端將請求發往前端的負載均衡器，請求報文源地址是CIP(客戶端IP),後面統稱爲CIP)，目標地址爲VIP(負載均衡器前端地址，後面統稱爲VIP)。

②.負載均衡器收到報文後，發現請求的是在規則裏面存在的地址，那麼它將客戶端請求報文的目標地址改成了後端服務器的RIP地址並將報文根據算法發送出去。

③.報文送到Real Server後，因爲報文的目標地址是本身，因此會響應該請求，並將響應報文返還給LVS。

④.而後lvs將此報文的源地址修改成本機併發送給客戶端。

注意：在NAT模式中，Real Server的網關必須指向LVS，不然報文沒法送達客戶端。

b IP包調度過程圖

c 小結

1、NAT 技術將請求的報文和響應的報文都須要經過 LB 進行地址改寫，所以網站訪問量比較大的時候 LB 負載均衡調度器有比較大的瓶頸，通常要求最多之能 10-20 臺節點

2、只須要在 LB 上配置一個公網 IP 地址就能夠了。

3、每臺內部的 realserver 服務器的網關地址必須是調度器 LB 的內網地址。

4、NAT 模式支持對 IP 地址和端口進行轉換。即用戶請求的端口和真實服務器的端口能夠不一致。

d 優缺點

優勢：集羣中的物理服務器可使用任何支持TCP/IP操做系統，只有負載均衡器須要一個合法的IP地址。

缺點：擴展性有限。當服務器節點（普通PC服務器）增加過多時,負載均衡器將成爲整個系統的瓶頸，由於全部的請求包和應答包的流向都通過負載均衡器。當服務器節點過多時，大量的數據包都交匯在負載均衡器那，速度就會變慢！

5.2、DR模型

a 原理圖

①.客戶端將請求發往前端的負載均衡器，請求報文源地址是CIP，目標地址爲VIP。

②.負載均衡器收到報文後，發現請求的是在規則裏面存在的地址，那麼它將客戶端請求報文的源MAC地址改成本身DIP的MAC地址，目標MAC改成了RIP的MAC地址，並將此包發送給RS。

③.RS發現請求報文中的目的MAC是本身，就會將次報文接收下來，處理完請求報文後，將響應報文經過lo接口送給eth0網卡直接發送給客戶端。

注意：須要設置lo接口的VIP不能響應本地網絡內的arp請求。

b IP 包調度過程圖

c 小結

1、經過在調度器 LB 上修改數據包的目的 MAC 地址實現轉發。注意源地址仍然是 CIP，目的地址仍然是 VIP 地址。

2、請求的報文通過調度器，而 RS 響應處理後的報文無需通過調度器 LB，所以併發訪問量大時使用效率很高（和 NAT 模式比）

3、由於 DR 模式是經過 MAC 地址改寫機制實現轉發，所以全部 RS 節點和調度器 LB 只能在一個局域網裏面

4、RS 主機須要綁定 VIP 地址在 LO 接口（掩碼32 位）上，而且須要配置 ARP 抑制。

5、RS 節點的默認網關不須要配置成 LB，而是直接配置爲上級路由的網關，能讓 RS 直接出網就能夠。

6、因爲 DR 模式的調度器僅作 MAC 地址的改寫，因此調度器 LB 就不能改寫目標端口，那麼 RS 服務器就得使用和 VIP 相同的端口提供服務。

7、直接對外的業務好比WEB等，RS 的IP最好是使用公網IP。對外的服務，好比數據庫等最好使用內網IP。

d 優缺點

優勢：和TUN（隧道模式）同樣，負載均衡器也只是分發請求，應答包經過單獨的路由方法返回給客戶端。與VS-TUN相比，VS-DR這種實現方式不須要隧道結構，所以可使用大多數操做系統作爲物理服務器。

DR模式的效率很高，可是配置稍微複雜一點，所以對於訪問量不是特別大的公司能夠用haproxy/nginx取代。日1000-2000W PV或者併發請求1萬一下均可以考慮用haproxy/nginx。

缺點：全部 RS 節點和調度器 LB 只能在一個局域網裏面。

5.3、TUN模型

a 原理圖

①.客戶端將請求發往前端的負載均衡器，請求報文源地址是CIP，目標地址爲VIP。

②.負載均衡器收到報文後，發現請求的是在規則裏面存在的地址，那麼它將在客戶端請求報文的首部再封裝一層IP報文,將源地址改成DIP，目標地址改成RIP,並將此包發送給RS。

③.RS收到請求報文後，會首先拆開第一層封裝,而後發現裏面還有一層IP首部的目標地址是本身lo接口上的VIP，因此會處理次請求報文，並將響應報文經過lo接口送給eth0網卡直接發送給客戶端。

注意：須要設置lo接口的VIP不能在共網上出現。

b IP包調度過程圖

c 小結

1.TUNNEL 模式必須在全部的 realserver 機器上面綁定 VIP 的 IP 地址

2.TUNNEL 模式的 vip ------>realserver 的包通訊經過 TUNNEL 模式，無論是內網和外網都能通訊，因此不須要 lvs vip 跟 realserver 在同一個網段內

3.TUNNEL 模式 realserver 會把 packet 直接發給 client 不會給 lvs 了

4.TUNNEL 模式走的隧道模式，因此運維起來比較難，因此通常不用。

d 優缺點

優勢：負載均衡器只負責將請求包分發給後端節點服務器，而RS將應答包直接發給用戶。因此，減小了負載均衡器的大量數據流動，負載均衡器再也不是系統的瓶頸，就能處理很巨大的請求量，這種方式，一臺負載均衡器可以爲不少RS進行分發。並且跑在公網上就能進行不一樣地域的分發。

缺點：隧道模式的RS節點須要合法IP，這種方式須要全部的服務器支持」IP Tunneling」(IP Encapsulation)協議，服務器可能只侷限在部分Linux系統上。

5.4、FULLNAT模型

（Full Network Address Translation）

a 原理圖

不管是 DR 仍是 NAT 模式，不可避免的都有一個問題：LVS 和 RS 必須在同一個 VLAN 下，不然 LVS 沒法做爲 RS 的網關。

這引起的兩個問題是：

1、同一個 VLAN 的限制致使運維不方便，跨 VLAN 的 RS 沒法接入。

2、LVS 的水平擴展受到制約。當 RS 水平擴容時，總有一天其上的單點 LVS 會成爲瓶頸。

Full-NAT 由此而生，解決的是 LVS 和 RS 跨 VLAN 的問題，而跨 VLAN 問題解決後，LVS 和 RS 再也不存在 VLAN 上的從屬關係，能夠作到多個 LVS 對應多個 RS，解決水平擴容的問題。

Full-NAT 相比 NAT 的主要改進是，在 SNAT/DNAT 的基礎上，加上另外一種轉換，轉換過程以下：

在包從 LVS 轉到 RS 的過程當中，源地址從客戶端 IP 被替換成了 LVS 的內網 IP。

內網 IP 之間能夠經過多個交換機跨 VLAN 通訊。

當 RS 處理完接受到的包，返回時，會將這個包返回給 LVS 的內網 IP，這一步也不受限於 VLAN。

LVS 收到包後，在 NAT 模式修改源地址的基礎上，再把 RS 發來的包中的目標地址從 LVS 內網 IP 改成客戶端的 IP。

Full-NAT 主要的思想是把網關和其下機器的通訊，改成了普通的網絡通訊，從而解決了跨 VLAN 的問題。採用這種方式，LVS 和 RS 的部署在 VLAN 上將再也不有任何限制，大大提升了運維部署的便利性。

b IP包調度過程圖

c 小結

1.FULL NAT 模式也不須要 LBIP 和 realserver ip 在同一個網段； full nat 跟 nat 相比的優勢是：保證 RS 回包必定可以回到 LVS；由於源地址就是 LVS--> 不肯定

2.full nat  由於要更新 sorce ip 因此性能正常比 nat 模式降低 10%

5.5、四種模式對比總結

性能：DR> TUN > NAT > FULL NAT

因爲每一個模式的功能不同，因此具體的選擇仍是要根據公司業務的選擇，實際環境來決定。

 

6、四層負載均衡LVS

LVS 是四層負載均衡，也就是說創建在 OSI 模型的第四層——傳輸層之上，傳輸層上有咱們熟悉的 TCP/UDP，LVS 支持 TCP/UDP 的負載均衡。

LVS 的轉發主要經過修改 IP 地址（NAT 模式，分爲源地址修改 SNAT 和目標地址修改 DNAT）、修改目標 MAC（DR 模式）來實現。

 

那麼爲何 LVS 是在第四層作負載均衡？

首先 LVS 不像 HAProxy 等七層軟負載面向的是 HTTP 包，因此七層負載能夠作的 URL 解析等工做，LVS 沒法完成。其次，某次用戶訪問是與服務端創建鏈接後交換數據包實現的，若是在第三層網絡層作負載均衡，那麼將失去「鏈接」的語義。軟負載面向的對象應該是一個已經創建鏈接的用戶，而不是一個孤零零的 IP 包。後面會看到，實際上 LVS 的機器代替真實的服務器與用戶經過 TCP 三次握手創建了鏈接，因此 LVS 是須要關心「鏈接」級別的狀態的

 

7、四層負載均衡和七層的區別

7.1. 四層負責均衡：

是經過報文中的目標地址和端口，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器與請求客戶端創建TCP鏈接，而後發送Client請求的數據。

由上圖可知：在四層負載設備中，把client發送的報文目標地址(原來是負載均衡設備的IP地址)，根據均衡設備設置的選擇web服務器的規則選擇對應的web服務器IP地址，這樣client就能夠直接跟此服務器創建TCP鏈接併發送數據。

 

7.2. 七層負載均衡設備

也稱內容交換，也就是主要經過報文中的真正有意義的應用層內容，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的服務器。

由上圖可知，其實七層負載均衡服務器起了一個代理服務器的做用，咱們知道創建一次TCP鏈接要三次握手；而client要訪問webserver要先與七層負載設備進行三次握手後創建TCP鏈接，把要訪問的報文信息發送給七層負載均衡；而後七層負載均衡再根據設置的均衡規則選擇特定的webserver，而後經過三次握手與此臺webserver創建TCP鏈接，而後webserver把須要的數據發送給七層負載均衡設備，負載均衡設備再把數據發送給client；因此，七層負載均衡設備起到了代理服務器的做用。

 

7.3. 七層的負責均衡設備的優勢

  (1) 使整個網絡更「智能化」，能把對圖片類的請求轉發到圖片服務器，對文字的請求轉發到文字服務器

  (2) 能夠有效防止 SYN Flood攻擊，是網站更安全

 

7.4. 七層負載均衡設備的缺點

  由於七層負載均衡設備實際上是一個代理服務器，則對此設備的要求也很高。

8、LVS的調度算法

Lvs的調度算法決定了如何在集羣節點之間分佈工做負荷。當director調度器收到來自客戶端訪問VIP的上的集羣服務的入站請求時，director調度器必須決定哪一個集羣節點應該處理請求。

Director調度器用的調度方法基本分爲兩類：

固定調度算法：rr，wrr，dh，sh 動態調度算法：wlc，lc，lblc，lblcr，seq，nq。

對於這些算法咱們只要知道經常使用的，其餘瞭解便可，不須要深刻其中的細節。

一、   靜態算法（4種）：

只根據算法進行調度 而不考慮後端服務器的實際鏈接狀況和負載狀況

①.RR：輪叫調度（Round Robin）

　 調度器經過」輪叫」調度算法將外部請求按順序輪流分配到集羣中的真實服務器上，它均等地對待每一臺服務器，而無論服務器上實際的鏈接數和系統負載｡

②.WRR：加權輪叫（Weight RR）

　 調度器經過「加權輪叫」調度算法根據真實服務器的不一樣處理能力來調度訪問請求。這樣能夠保證處理能力強的服務器處理更多的訪問流量。調度器能夠自動問詢真實服務器的負載狀況,並動態地調整其權值。

③.DH：目標地址散列調度（Destination Hash ）

　  根據請求的目標IP地址，做爲散列鍵(HashKey)從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，不然返回空。

④.SH：源地址 hash（Source Hash）

　 源地址散列」調度算法根據請求的源IP地址，做爲散列鍵(HashKey)從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，不然返回空｡

二、   動態算法（6種）：

前端的調度器會根據後端真實服務器的實際鏈接狀況來分配請求,Realserver 的負載狀態一般由活動連接（active），非活動連接（inactive）和權重來計算。

①.LC：最少連接（Least Connections）

　 調度器經過」最少鏈接」調度算法動態地將網絡請求調度到已創建的連接數最少的服務器上。若是集羣系統的真實服務器具備相近的系統性能，採用」最小鏈接」調度算法能夠較好地均衡負載。

②.WLC：加權最少鏈接(默認採用的就是這種)（Weighted Least Connections）

　 在集羣系統中的服務器性能差別較大的狀況下，調度器採用「加權最少連接」調度算法優化負載均衡性能，具備較高權值的服務器將承受較大比例的活動鏈接負載｡調度器能夠自動問詢真實服務器的負載狀況,並動態地調整其權值。

③.SED：最短延遲調度（Shortest Expected Delay ）

　 在WLC基礎上改進，Overhead = （ACTIVE+1）*256/加權，再也不考慮非活動狀態，把當前處於活動狀態的數目+1來實現，數目最小的，接受下次請求，+1的目的是爲了考慮加權的時候，非活動鏈接過多缺陷：當權限過大的時候，會倒置空閒服務器一直處於無鏈接狀態。

④.NQ永不排隊/最少隊列調度（Never Queue Scheduling NQ）

　 無需隊列。若是有臺 realserver的鏈接數＝0就直接分配過去，不須要再進行sed運算，保證不會有一個主機很空間。在SED基礎上不管+幾，第二次必定給下一個，保證不會有一個主機不會很空閒着，不考慮非活動鏈接，才用NQ，SED要考慮活動狀態鏈接，對於DNS的UDP不須要考慮非活動鏈接，而httpd的處於保持狀態的服務就須要考慮非活動鏈接給服務器的壓力。

⑤.LBLC：基於局部性的最少連接（locality-Based Least Connections）

　 基於局部性的最少連接」調度算法是針對目標IP地址的負載均衡，目前主要用於Cache集羣系統｡該算法根據請求的目標IP地址找出該目標IP地址最近使用的服務器，若該服務器是可用的且沒有超載，將請求發送到該服務器;若服務器不存在，或者該服務器超載且有服務器處於一半的工做負載，則用「最少連接」的原則選出一個可用的服務器，將請求發送到該服務器｡

⑥. LBLCR：帶複製的基於局部性最少鏈接（Locality-Based Least Connections with Replication）

　 帶複製的基於局部性最少連接」調度算法也是針對目標IP地址的負載均衡，目前主要用於Cache集羣系統｡它與LBLC算法的不一樣之處是它要維護從一個目標IP地址到一組服務器的映射，而LBLC算法維護從一個目標IP地址到一臺服務器的映射｡該算法根據請求的目標IP地址找出該目標IP地址對應的服務器組，按」最小鏈接」原則從服務器組中選出一臺服務器，若服務器沒有超載，將請求發送到該服務器；若服務器超載，則按「最小鏈接」原則從這個集羣中選出一臺服務器，將該服務器加入到服務器組中，將請求發送到該服務器｡同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以下降複製的程度。

3、算法總結

算法	說明
rr	輪詢算法，它將請求依次分配給不一樣的rs節點，也就是RS節點中均攤分配。這種算法簡單，但只適合於RS節點處理性能差很少的狀況
wrr	加權輪訓調度，它將依據不一樣RS的權值分配任務。權值較高的RS將優先得到任務，而且分配到的鏈接數將比權值低的RS更多。相同權值的RS獲得相同數目的鏈接數。
Wlc	加權最小鏈接數調度，假設各臺RS的全職依次爲Wi，當前tcp鏈接數依次爲Ti，依次去Ti/Wi爲最小的RS做爲下一個分配的RS 。
Dh	目的地址哈希調度（destination hashing）以目的地址爲關鍵字查找一個靜態hash表來得到須要的RS 。
SH	源地址哈希調度（source hashing）以源地址爲關鍵字查找一個靜態hash表來得到須要的RS。
Lc	最小鏈接數調度（least-connection）,IPVS表存儲了全部活動的鏈接。LB會比較將鏈接請求發送到當前鏈接最少的RS。
Lblc	基於地址的最小鏈接數調度（locality-based least-connection）：未來自同一個目的地址的請求分配給同一臺RS，此時這臺服務器是還沒有滿負荷的。不然就將這個請求分配給鏈接數最小的RS，並以它做爲下一次分配的首先考慮。
Lblcr	基於本地的帶複製功能的最少鏈接，與 LBLC 不一樣的是 LVS 將請求 IP 映射至一個服務池中，使用 dh 算法調度請求至對應的服務池中，使用 lc 算法選擇服務池中的節點，當服務池中的全部節點超載，使用 lc 算法從全部後端 Realserver 中選擇一個添加至服務吃中。
Seq	最短時間望延遲，它不對 inactive 狀態的鏈接進行計算，根據 overhead = (active+1)*256/weight 計算服務器負載，選擇 overhead 最小的服務器進行調度
Nq	當有空閒服務器時，直接調度至空閒服務器，當沒有空閒服務器時，使用 SED 算法進行調度

 

4、生產環境算法的選擇

1、通常的網絡服務，如 www，mail，mysql 等經常使用的 LVS 調度算法爲：

一、基本輪詢調度 rr

二、加權最小鏈接調度 wlc

三、加權輪詢調度 wrr

2、基於局部性的最小鏈接 lblc 和帶複製的給予局部性最小鏈接 lblcr 主要適用於 web cache 和 DB cache ，通常不這麼用。

3、源地址散列調度 SH 和目標地址散列調度 DH 能夠結合使用在防火牆集羣中，能夠保證整個系統的出入口惟一。

實際適用中這些算法的適用範圍不少，工做中最好參考內核中的鏈接調度算法的實現原理，而後根據具體的業務需求合理的選型。

rr，wrr，wlc是經常使用的。

9、Lvs安裝與配置

1、主機準備

略

2、開始安裝LVS

安裝lvs

[root@lb01 application]# yum install ipvsadm –y

#YUM安裝 LVS

[root@lb02 application]# ln -s /usr/src/kernels/`uname -r`/usr/src/linux

[root@lb01 application]# ipvsadm    #<=管理lvs的工具

IP Virtual Server version 1.2.1 (size=4096)

Prot LocalAddress:Port Scheduler Flags

  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn

[root@lb01 application]# lsmod |grep ip_vs   #查看IPVS加載到內核沒有   

ip_vs                 126534  0

libcrc32c               1246  1 ip_vs

ipv6                  335589  265 ip_vs

 

LVS安裝提示：

一、CENTOS 5上安裝LVS，使用1.24版本。不要用1.26。

二、CENTOS 6.4安裝LVS，使用1.26版本 yum install libnl* popt* -y。

三、安裝LVS後，要執行ipvsadm（modprobe ip_vs）把ip_vs模塊加載到內核。

3、在LB上綁定VIP

命令行添加網卡：

ip addr add 10.0.0.3/24 dev eth0 label eth0:1

 

在LB上配置LVS

 [root@lb01 application]# ipvsadm -C     #<=清空整個表

[root@lb01 application]# ipvsadm --set 30 5 60

#<=修改LVS的超時參數

[root@lb01 application]# ipvsadm -A -t 10.0.0.4:80 -s wrr -p 1 

#<=指定虛擬主機

[root@lb01 application]# ipvsadm –Ln

#<=列出LVS表

IP Virtual Server version 1.2.1 (size=4096)

Prot LocalAddress:Port Scheduler Flags

  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn

TCP  10.0.0.4:80 wrr persistent 1

[root@lb01 application]# ipvsadm -a -t 10.0.0.4:80 -r 10.0.0.7 –g

#<=添加後端真實服務節點

[root@lb01 application]# ipvsadm -a -t 10.0.0.4:80 -r 10.0.0.8 -g

[root@lb01 application]# ipvsadm -Ln

IP Virtual Server version 1.2.1 (size=4096)

Prot LocalAddress:Port Scheduler Flags

  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn

TCP  10.0.0.4:80 wrr persistent 1

  -> 10.0.0.7:80                  Route   10          0        

  -> 10.0.0.8:80                  Route   10          0  

 

附：

ipvsadm

【功能說明】：

ipvs直接調用的命令

【語法格式】：

ipsadm  [選型]

【選項參數】：

-C     清空整個表 

-A     經過選型，添加虛擬主機

-t     添加tcp虛擬主機的地址 格式爲：host[:port]

-d     添加dcp虛擬主機的地址 格式爲：host[:port]

-s     指定輪詢算法[rr|wrr|lc|wlc|lblc|lblcr]

-L     列出整個表

-n     以數字的形式輸出地址和端口

-a經過選型，添加真實主機【RS】

-r     真實主機的IP地址   host (and port)

-g    經過直接路由模式，及DR模式

-d     刪除真實主機

ipvsadm -d -t 10.0.0.4:80 -r 10.0.0.7:80   

#<=刪除指定的虛擬主機

-p [timeot]會話保持的功能 [會話保持的做用：例如ipvsadm -A -t 10.0.0.4:80 -s rr -p 300  這個時間段內，全部的請求都會找一臺機器，可是會致使負載不均]

 

4、手動在RS上綁定VIP

在web服務器上執行：

[root@web01 ~]# ip addr add 10.0.0.4/32  dev lo label lo:1   #<=臨時生效

[root@web01 ~]# route add -host 10.0.0.4 dev lo 

 #添加主機路由，爲了回覆數據包的時候通過l0網卡，是數據包的源IP是VIP，不是必須的操做。   

[root@web01 ~]# route -n

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

10.0.0.4        0.0.0.0         255.255.255.255 UH    00        0 lo

5、抑制arp

在LVS DR模式當中，LB和後端的RS共用一個VIP（對外提供服務），爲了保證客戶端在請求VIP能獲得LB的MAC地址，咱們須要在後端的RS上配置ARP抑制。

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

arp_ignore = 1即不迴應不是目標IP是物理網絡IP的ARP請求。確保了客戶端請求VIP的時候只會獲得LB的MAC地址。

arp_announce = 2即RS在回覆客戶端的時候，發送的ARP請求不以本身的VIP的爲源IP，確保了不會更新上端路由的ARP緩存，從而保證之後客戶端請求VIP的時候讀取路由器ARP緩存會獲得LB的MAC地址。

說明：

arp_ignore-INTEGE：

定義目標地址爲本地IP的ARP詢問不一樣的應答模式

0-（默認值）：迴應任何網絡接口上對本地IP地址的arp查詢請求

1-只回答目標IP地址是來訪問網絡接口本地地址的ARP查詢請求

2-  只回答目標IP地址是來訪網絡接口本地地址的ARP查詢請求，且來自網絡接口的子網的內。

3-  不迴應網絡界面的ARP請求，並且只對設置的惟一和鏈接地址作出迴應。

4-7- 保留未使用

8-不迴應全部（本地地址）的ARP查詢

 

arp_announce-INTEGER：

「0″表明是用ip包的源地址來設置ARP請求的源地址。

「1″表明不使用ip包的源地址來設置ARP請求的源地址，若是ip包的源地址是和該端口的IP地址相同的子網，那麼用ip包的源地址，來設置ARP請求的源地址，不然使用」2″的設置。

「2″表明不使用ip包的源地址來設置ARP請求的源地址，而由系統來選擇最好的接口來發送

當內網的機器要發送一個到外部的ip包，那麼它就會請求路由器的Mac地址，發送一個arp請求，這個arp請求裏面包括了本身的ip地址和Mac地址，而linux默認是使用ip的源ip地址做爲arp裏面的源ip地址，而不是使用發送設備上面的 ，這樣在lvs這樣的架構下，全部發送包都是同一個VIP地址，那麼arp請求就會包括VIP地址和設備 Mac，而路由器收到這個arp請求就會更新本身的arp緩存，這樣就會形成ip欺騙了，VIP被搶奪，因此就會有問題。

6、編寫腳本實現

以上的手動操做咱們能夠經過腳本去實現。

ipvs server啓動腳本

[root@LB01 scripts]# cat ipvs.server.sh 

#!/bin/sh

. /etc/init.d/functions

 

VIP=10.0.0.29

PORT=80

RIP=(

10.0.0.8

10.0.0.7

)

start(){

   ifconfig eth2:0 $VIP/24 up

   route add -host $VIP dev eth2

   ipvsadm -C

   ipvsadm --set 30 5 60   30 

   ipvsadm -A -t $VIP:$PORT -s rr -p 20 

  for ((i=0;i<${#RIP[*]};i++))

  do

    ipvsadm -a -t $VIP:$PORT -r ${RIP[$i]} -g -w 1

  done

}

 

stop(){

    ipvsadm -C

    ifconfig eth2:0 down

    route del -host $VIP dev eth0

}

case "$1" in

        start)

                start

                echo "IPVS is started"

                ;;

        stop)

                stop

                echo "IPVS is stopped"

                ;;

        restart)

                stop

                sleep 2

                start

                echo "IPVS is restarted"

                ;;

        *)

                echo "USAGE:$0 {start|stop|restart}"

esac

7、關於在虛擬機上測試LVS負載均衡

因爲咱們在電腦上裝的虛擬機上測試。

因此虛擬出來的路由以及LINUX客戶端

可能不支持echo "2" >/proc/sys/net/ipv4/conf/lo/arp_announce這個參數，因此就會有ARP緩存的問題。

那麼咱們在瀏覽器訪問的時候能夠在每次訪問後，清空arp緩存（arp –d ）。就會出現1比1的負載均衡。

若是是LINUX上咱們能夠

[root@lb01 ~]# arp -d 10.0.0.3 ; curl 10.0.0.3

yyyy

[root@lb01 ~]# arp -d 10.0.0.3 ; curl 10.0.0.3

yangliheng

10、LVS各個模型的實現

10.1、LVS NAT模型的實現

1. 集羣環境：一臺Director, 兩臺後端Real Server RS1，RS2

    Director:兩網卡   

 

eth1:192.168.0.33/24

eth2:172.16.12.1/24

eth1:1:192.168.0.200/24做爲VIP地址

    

    RS1:

eth1:172.16.12.11

    

    RS2:

eth1:172.16.12.12

 

   Director的eth0爲橋接，eth1和RS1,RS2的eth0使用僅主機模式。在RS1和RS2上使用僅主機模式前先分別安裝好LAMP的環境，並設置好測試頁面。

2，配置網絡

配置RS1：

 

[root@localhost html]# ifconfig eth1 172.16.12.11/24

[root@localhost html]# route add default gw 172.16.12.1

 

配置RS2：

 

[root@localhost html]# ifconfig eth1 172.16.12.12/24

[root@localhost html]# route add default gw 172.16.12.1

 

在Director上的配置：

[root@localhost ~]# yum install ipvsadm -y    #安裝客戶端工具

[root@localhost ~]# ifconfig eth2 172.16.12.1/24

[root@localhost ~]# ifconfig eth1:1 192.168.0.200  #添加VIP

[root@localhost ~]# iptables -F

[root@localhost ~]# iptables -t filter -F

[root@localhost ~]# iptables -L -n

Chain INPUT (policy ACCEPT)

targetprot opt sourcedestination        

 

Chain FORWARD (policy ACCEPT)

targetprot opt sourcedestination        

 

Chain OUTPUT (policy ACCEPT)

targetprot opt sourcedestination 

[root@localhost ~]# service iptables  save

iptables:Saving firewall rules to /etc/sysconfig/iptables:[  OK  ]

3. 修改內核參數，開啓轉發功能

[root@localhost ~]# vim /etc/sysctl.conf   #打開轉發功能

net.ipv4.ip_forward =1

 

[root@localhost ~]# sysctl -p    #使其生效

4. 驗證RS1和RS2上面建立的測試頁

[root@localhost ~]# curl 172.16.12.11    

web1 172.16.12.11

[root@localhost ~]# curl 172.16.12.12

web2 172.16.12.12

5. 在Director上添加集羣服務

[root@localhost ~]# ipvsadm -A -t 192.168.0.200:80 -s rr    #建立一個集羣服務

[root@localhost ~]# ipvsadm -L -n

IP VirtualServer version 1.2.1(size=4096)

ProtLocalAddress:PortSchedulerFlags

  ->RemoteAddress:Port           ForwardWeightActiveConnInActConn

TCP  192.168.0.35:80 rr

 

[root@localhost ~]# ipvsadm -a -t 192.168.0.200:80 -r 172.16.12.11 -m#-m類型，默認wlc

[root@localhost ~]# ipvsadm -a -t 192.168.0.200:80 -r 172.16.12.12 -m

[root@localhost ~]# ipvsadm -L -n

IP VirtualServer version 1.2.1(size=4096)

ProtLocalAddress:PortSchedulerFlags

  ->RemoteAddress:Port           ForwardWeightActiveConnInActConn

TCP  192.168.0.200:80 rr

  ->172.16.12.11:80Masq    1      08        

  ->172.16.12.12:80Masq    1      08  

 

好了，LVS的NAT模型就這樣配置完成了，而後到瀏覽器中進行訪問：

10.2、LVS DR模型的實現

1. 集羣環境：一臺Director, 兩臺Real Server RS1，RS2，這次使用較簡單的配置方法，三個主機都使用橋接模式

    Director:兩網卡   

 

eth1:192.168.0.33/24

eth1:0:192.168.0.200/24   做爲VIP地址，能夠進行浮動

    

    RS1：

eth1:192.168.0.23

    

    RS2：

eth1:192.168.0.24

2，配置網絡

配置Dircector

 

[root@localhost ~]# ifconfig eth1:0 192.168.0.200  up      #配置VIP

[root@localhost ~]# route add -host 192.168.0.200 dev eth1:0  

 

配置RS1，修改內核參數，關閉lo的arp通告和lo的arp響應，並配置隱藏地址，而且保證其發出報文通過eth1以前，還要先通過lo:1 VIP,使得源地址成爲VIP

 

[root@localhost ~]# echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore

[root@localhost ~]# echo 1 > /proc/sys/net/ipv4/conf/eth1/arp_ignore

[root@localhost ~]# echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

[root@localhost ~]# echo 2 > /proc/sys/net/ipv4/conf/eth1/arp_announce

 

[root@localhost ~]# ifconfig lo:0 192.168.0.200 netmask 255.255.255.255 broadcast 192.168.0.200 up

[root@localhost ~]# route add -host 192.168.0.200 dev lo:0

 

配置RS2：

 

[root@localhost ~]# echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore

[root@localhost ~]# echo 1 > /proc/sys/net/ipv4/conf/eth1/arp_ignore

[root@localhost ~]# echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

[root@localhost ~]# echo 2 > /proc/sys/net/ipv4/conf/eth1/arp_announce

[root@localhost ~]# ifconfig lo:0 192.168.0.200 netmask 255.255.255.255 broadcast 192.168.0.200 up  #只廣播本身

[root@localhost ~]# route add -host 192.168.0.200 dev lo:0     #目標是192.168.0.200時通過設備lo:0

3，在Director上添加集羣服務

[root@localhost ~]# ipvsadm -A -t 192.168.0.200:80 -s rr

[root@localhost ~]# ipvsadm -a -t 192.168.0.200:80 -r 192.168.0.23 -g -w 1#使用權重1

[root@localhost ~]# ipvsadm -a -t 192.168.0.200:80 -r 192.168.0.24 -g -w 3#使用權重3

4，在瀏覽器中進行測試，可是此配置中爲RS1和RS2設置了權重，因此轉發到後的RS時，響應的次數爲3:1。

11、LVS Session持久機制

1、session綁定：始終將同一個請求者的鏈接定向至同一個RS（第一次請求時仍由調度方法選擇）；沒有容錯能力，有損均衡效果；

2、session複製：在RS之間同步session，所以，每一個RS持集羣中全部的session；對於大規模集羣環境不適用；

3、session服務器：利用單獨部署的服務器來統一管理session;

 

12、LVS持久鏈接

12.1、持久鏈接的實現機制

不管使用什麼算法，LVS持久鏈接都能實如今一點時間內，未來自於同一個客戶端請求派發至此前選定的realserver,DH調度算法自己依賴於TCP會話超時時間等其餘計時器，而持久鏈接依賴於持久鏈接模板， 每一個新的鏈接請求，不管客戶端的鏈接狀態不管是否斷開，只要客戶端曾經訪問過，LVS就會在持久鏈接模板中記錄信息， 持久鏈接模板(內存緩衝區):記錄每個客戶端及分配的realserver的映射關係。

常常用於SSL,創建一個SSL鏈接，須要交換SSL密鑰，當啓用持久性鏈接時，只須要作一次驗證便可。

12.2、PPC 持久端口鏈接 基於端口 

來自於同一個客戶端對同一個服務的請求，始終定向至此前選定的realserver。 

ipvsadm -A -t 192.168.1.200:23 -s rr-p 3600

ipvsadm -a -t 192.168.1.200:23 -r 192.168.1.10 -g -w 2

ipvsadm -a -t 192.168.1.200:23 -r 192.168.1.20 -g -w 1

12.3、PCC 持久客戶端鏈接 基於全部端口 

來自於同一個客戶端對全部服務的請求，始終定向至此前選定的realserver

ipvsadm -A -t 192.168.1.200:0 -s rr -p 600

ipvsadm -a -t 192.168.1.200:0 -r 192.168.1.10 -g -w 2

ipvsadm -a -t 192.168.1.200:0 -r 192.168.1.20 -g -w 1

12.4、PNMPP 持久防火牆標記鏈接 

來自於同一客戶端對指定服務的請求，始終定向至此算定的realserver基於指定的端口，它能夠 將兩個絕不相干的端口定義爲一個集羣服務， 例如：合併http telnet爲同一個集羣服務。

##PNMPP是經過路由前給數據包打標記來實現的

iptables -t mangle -A PREROUTING -d 192.168.1.200 -eth0 -p tcp --dport 80 -j MARK --set-mark 3

iptables -t mangle -A PREROUTING -d 192.168.1.200 -eth0 -p tcp --dport 23 -j MARK --set-mark 3

ipvsadm -A -f 3 -s rr -p 600

ipvsadm -a -f 3 -r 192.168.1.10 -g -w 2

ipvsadm -a -f 3 -r 192.168.1.20 -g -w 2

 

注意:以上三種持久鏈接均使用了"-p" 選項 ，它保證了持久性，默認爲300秒

警告:Director沒有定義用戶請求的集羣服務，將試圖本身響應客戶端請求。

 

 

13、常見的lvs高可用方案

lvs兩大弱點：1、手動配置 2、健康檢查

不能檢測後端服務器的健康情況，老是發送鏈接到後端

 

13.1、經過redhat提供的工具piranha來配置LVS

The Piranha Solution

http://www.linuxvirtualserver.org/docs/ha/piranha.html

不推薦。

13.2、keepalived+LVS方案

這個方案符合簡單、易用、高效的運維原則，也是接下來重點講解的負載均衡及高可用解決方案。

The Keepalived Solution  

http://www.linuxvirtualserver.org/docs/ha/keepalived.html

keepalived的做用

1、管理LVS負載均衡軟件

2、使配置LVS更加自動化

3）實現LVS主被服務器高可用

14、LVS負載不均衡的解決思路

生產案例：

生產環境中ipvsadm –L –n 發現兩臺RS的負載不均衡，一臺有不少請求，一臺米有。而且沒有請求的那臺RS經測試服務正常，lo:VIP也有。可是就是沒有請求。

TCP  172.168.1.50:3307 wrr persistent 10

  -> 172.168.1.51:3307                Route   10        0

  -> 172.168.1.52:3307                Route   18        12758  

問題緣由：

persistent 10的緣由，persistent會話保持，當clientA訪問網站的時候，LVS把請求分發給了52，那麼之後client A再點擊的其餘操做其餘請求，也會發送給52臺機器。

解決辦法：

到keepalived中註釋掉persistent 10 而後/etc/init.d/keepalived reload而後能夠看到之後負載均衡兩邊都請求均衡了。

 

那麼致使負載不均衡的緣由有：

一、LVS滋生的會話保持參數設置（-p 300 ,persistent 300）。優化：大公司儘可能用cookies替代session。

二、LVS調度算法設置，例如:rr，wrr，wlc，lc算法。

三、後端RS節點的會話保持參數。

四、訪問量較少的時候，不均衡比較明顯。

五、用戶發送的請求時間長短，和請求資源多少大小。

 

實現會話保持的方案：
http://oldboy.blog.51cto.com/2561410/1331316
http://oldboy.blog.51cto.com/2561410/1323468 

15、LVS排錯

排錯大致的思路就是，要熟悉LVS的工做原理過程，而後根據原理過程來排重，例如：

一、調度器上LVS調度規則及IP的正確性。

二、RS節點上VIP綁定和arp抑制的檢查。

生產處理思路：

對RS綁定的VIP作實時監控，出問題報警或者自動處理後報警。

把RS綁定的VIP作成配置文件，例如：vi /etc/sysconfig/network-scripts/lo:0

ARP抑制的配置思路：

當RS端有多個VIP綁定，即便中止了一個VIP也不要修改ARP抑制。

三、RS節點上自身提供服務的檢查。

四、輔助排查工具備tepdump，ping等。

五、負載均衡以及反向代理集羣的三角形排查理論：

16、突破LVS瓶頸

LVS的併發是十萬級別的，那麼如何突破這個瓶頸呢

1、突破LVS瓶頸，LVS Cluster部署（OSPF + LVS）

http://my.oschina.net/lxcong/blog/143904?fromerr=wW5KTv1c

2、智能DNS

在機房的前端增長DNS輪詢。

實現的軟件有dnspod,

17、LVS代碼平滑上線發佈思路

在生產環境中咱們發佈代碼通常要平滑上線以及灰度發佈。發佈代碼的時候要遵循必定的過程：

開發人員本地測試—辦公室內部測試—SVN（配置管理員）--IDC機房測試環境—正式服務器

 

當咱們要在正式服務器上線代碼的時候必定要遵循平滑發佈的思路即不能讓客戶感受到網站在更新：

關於代碼的上線更新通常分爲2個種類：

一、PHP這類不須要重啓服務的代碼。咱們上線的時候不要直接從本地上傳服務器去覆蓋。而是應該先拷貝到服務器上的臨時目錄後，再去覆蓋代碼。固然咱們也能夠給代碼作軟連接，這樣咱們上線的時候，只須要刪除、再創建軟連接就能夠了。

二、java這類須要重啓服務的代碼，咱們上線的時候能夠利用LVS負載來進行平滑上線。假設咱們的real server節點有N個，那麼咱們須要在LVS上踢掉一半的節點，在這些被踢掉的節點上更新代碼，同時在測試LVS集羣上測試代碼的可靠性。若是沒問題，咱們再將這些節點加入LVS，同時踢掉另外一半的real server，在另外一半的real server上也上線代碼。測試沒問題後，再加入到正式的LVS集羣當中。這就是利用LVS的負載均衡作的平滑上線代碼的思路。

18、LVS總結

一、arp協議的介紹及實現原理。（這部分是爲了理解LVS DR模式的原理。）

二、LVS集羣的原理，安裝以及手工開發腳本配置實現多種模式的負載均衡。

 

三、keepalived軟件的介紹及高可用應用

1）httpd（nginx或者apache）服務的高可用

2）MYSQL服務的高可用

3）反向代理的高可用

keepalived+nginx代理，也能夠實現nginx的高可用性集羣，而nginx自己還有負載均衡集羣的功能。

keepalived+haproxy代理，也能夠實現haproxy的高可用性集羣，而haproxy自己還有負載均衡集羣的功能。

4、lvs+keepalived實現負載均衡及高可用性。

 

 

 

來自爲知筆記(Wiz)