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技術點小結：
1、真正實現調度的工具是IPVS，工作在LINUX內核層面。
2、LVS自帶的IPVS管理工具是ipvsadm。
3、keepalived實現管理IPVS及負載均衡器的高可用。
4、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。
對於這些算法我們只要知道常用的，其他了解即可，不需要深入其中的細節。
1、 靜態算法（4種）：
只根據算法進行調度 而不考慮后端服務器的實際連接情況和負載情況
①.RR：輪叫調度（Round Robin）
調度器通過”輪叫”調度算法將外部請求按順序輪流分配到集群中的真實服務器上，它均等地對待每一台服務器，而不管服務器上實際的連接數和系統負載｡
②.WRR：加權輪叫（Weight RR）
調度器通過“加權輪叫”調度算法根據真實服務器的不同處理能力來調度訪問請求。這樣可以保證處理能力強的服務器處理更多的訪問流量。調度器可以自動問詢真實服務器的負載情況,並動態地調整其權值。
③.DH：目標地址散列調度（Destination Hash ）
根據請求的目標IP地址，作為散列鍵(HashKey)從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。
④.SH：源地址 hash（Source Hash）
源地址散列”調度算法根據請求的源IP地址，作為散列鍵(HashKey)從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空｡
2、 動態算法（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 調度算法為：
1、基本輪詢調度 rr
2、加權最小連接調度 wlc
3、加權輪詢調度 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安裝提示：
1、CENTOS 5上安裝LVS，使用1.24版本。不要用1.26。
2、CENTOS 6.4安裝LVS，使用1.26版本 yum install libnl* popt* -y。
3、安裝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然后可以看到以后負載均衡兩邊都請求均衡了。
那么導致負載不均衡的原因有：
1、LVS滋生的會話保持參數設置（-p 300 ,persistent 300）。優化：大公司盡量用cookies替代session。
2、LVS調度算法設置，例如:rr，wrr，wlc，lc算法。
3、后端RS節點的會話保持參數。
4、訪問量較少的時候，不均衡比較明顯。
5、用戶發送的請求時間長短，和請求資源多少大小。
實現會話保持的方案：
http://oldboy.blog.51cto.com/2561410/1331316
http://oldboy.blog.51cto.com/2561410/1323468
15、LVS排錯
排錯大體的思路就是，要熟悉LVS的工作原理過程，然后根據原理過程來排重，例如：
1、調度器上LVS調度規則及IP的正確性。
2、RS節點上VIP綁定和arp抑制的檢查。
生產處理思路：
對RS綁定的VIP做實時監控，出問題報警或者自動處理后報警。
把RS綁定的VIP做成配置文件，例如：vi /etc/sysconfig/network-scripts/lo:0
ARP抑制的配置思路：
當RS端有多個VIP綁定，即使停止了一個VIP也不要修改ARP抑制。
3、RS節點上自身提供服務的檢查。
4、輔助排查工具有tepdump，ping等。
5、負載均衡以及反向代理集群的三角形排查理論：
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個種類：
1、PHP這類不需要重啟服務的代碼。我們上線的時候不要直接從本地上傳服務器去覆蓋。而是應該先拷貝到服務器上的臨時目錄后，再去覆蓋代碼。當然我們也可以給代碼做軟鏈接，這樣我們上線的時候，只需要刪除、再建立軟鏈接就可以了。
2、java這類需要重啟服務的代碼，我們上線的時候可以利用LVS負載來進行平滑上線。假設我們的real server節點有N個，那么我們需要在LVS上踢掉一半的節點，在這些被踢掉的節點上更新代碼，同時在測試LVS集群上測試代碼的可靠性。如果沒問題，我們再將這些節點加入LVS，同時踢掉另一半的real server，在另一半的real server上也上線代碼。測試沒問題后，再加入到正式的LVS集群當中。這就是利用LVS的負載均衡做的平滑上線代碼的思路。
18、LVS總結
1、arp協議的介紹及實現原理。（這部分是為了理解LVS DR模式的原理。）
2、LVS集群的原理，安裝以及手工開發腳本配置實現多種模式的負載均衡。
3、keepalived軟件的介紹及高可用應用
1）httpd（nginx或者apache）服務的高可用
2）MYSQL服務的高可用
3）反向代理的高可用
keepalived+nginx代理，也可以實現nginx的高可用性集群，而nginx本身還有負載均衡集群的功能。
keepalived+haproxy代理，也可以實現haproxy的高可用性集群，而haproxy本身還有負載均衡集群的功能。
4、lvs+keepalived實現負載均衡及高可用性。
