LVS专题
為什么80%的碼農都做不了架構師？>>> ??
轉載自 http://atong.blog.51cto.com/?的博客（謝謝作者） ?
-------------------轉載 LVS專題------------------------
LVS原理詳解及部署之一：ARP原理準備
LVS原理詳解及部署之二：LVS原理詳解（3種工作方式8種調度算法）
LVS原理詳解及部署之三：手動部署LVS
LVS原理詳解及部署之四：keepalived介紹
LVS原理詳解及部署之五：LVS+keepalived實現負載均衡&高可用
-------------------------------------------------
一、集群簡介
什么是集群
計算機集群簡稱集群是一種計算機系統，它通過一組松散集成的計算機軟件和/或硬件連接起來高度緊密地協作完成計算工作。在某種意義上，他們可以被看作是一臺計算機。集群系統中的單個計算機通常稱為節點，通常通過局域網連接，但也有其它的可能連接方式。集群計算機通常用來改進單個計算機的計算速度和/或可靠性。一般情況下集群計算機比單個計算機，比如工作站或超級計算機性能價格比要高得多。
集群就是一組獨立的計算機，通過網絡連接組合成一個組合來共同完一個任務
LVS在企業架構中的位置：
以上的架構只是眾多企業里面的一種而已。綠色的線就是用戶訪問請求的數據流向。用戶-->LVS負載均衡服務器--->apahce服務器--->mysql服務器&memcache服務器&共享存儲服務器。并且我們的mysql、共享存儲也能夠使用LVS再進行負載均衡。
---------------小結-------------------------
集群：就是一組相互獨立的計算機，通過高速的網絡組成一個計算機系統，每個集群節點都是運行其自己進程的一個獨立服務器。對網絡用戶來講，網站后端就是一個單一的系統，協同起來向用戶提供系統資源，系統服務。
-------------------------------------------
為什么要使用集群
集群的特點
1）高性能performance。一些需要很強的運算處理能力比如天氣預報，核試驗等。這就不是幾臺計算機能夠搞定的。這需要上千臺一起來完成這個工作的。
2）價格有效性
通常一套系統集群架構，只需要幾臺或數十臺服務器主機即可，與動則上百王的專用超級計算機具有更高的性價比。
3）可伸縮性
當服務器負載壓力增長的時候，系統能夠擴展來滿足需求，且不降低服務質量。
4）高可用性
盡管部分硬件和軟件發生故障，整個系統的服務必須是7*24小時運行的。
集群的優勢
1）透明性
如果一部分服務器宕機了業務不受影響，一般耦合度沒有那么高，依賴關系沒有那么高。比如NFS服務器宕機了其他就掛載不了了，這樣依賴性太強。
2）高性能
訪問量增加，能夠輕松擴展。
3）可管理性
整個系統可能在物理上很大，但很容易管理。
4）可編程性
在集群系統上，容易開發應用程序，門戶網站會要求這個。
集群分類及不同分類的特點
計算機集群架構按照功能和結構一般分成以下幾類：
1）負載均衡集群（Loadbalancingclusters）簡稱LBC
2）高可用性集群（High-availabilityclusters）簡稱HAC
3）高性能計算集群（High-perfomanceclusters）簡稱HPC
4）網格計算（Gridcomputing）
網絡上面一般認為是有三個，負載均衡和高可用集群式我們互聯網行業常用的集群架構。
（1）負載均衡集群
? ?負載均衡集群為企業提供了更為實用，性價比更高的系統架構解決方案。負載均衡集群把很多客戶集中訪問的請求負載壓力可能盡可能平均的分攤到計算機集群中處理。客戶請求負載通常包括應用程度處理負載和網絡流量負載。這樣的系統非常適合向使用同一組應用程序為大量用戶提供服務。每個節點都可以承擔一定的訪問請求負載壓力，并且可以實現訪問請求在各節點之間動態分配，以實現負載均衡。
? ?負載均衡運行時，一般通過一個或多個前端負載均衡器將客戶訪問請求分發到后端一組服務器上，從而達到整個系統的高性能和高可用性。這樣計算機集群有時也被稱為服務器群。一般高可用性集群和負載均衡集群會使用類似的技術，或同時具有高可用性與負載均衡的特點。
負載均衡集群的作用
1）分擔訪問流量（負載均衡）
2）保持業務的連續性（高可用）
（2）高可用性集群
一般是指當集群中的任意一個節點失效的情況下，節點上的所有任務自動轉移到其他正常的節點上，并且此過程不影響整個集群的運行，不影響業務的提供。
? ?類似是集群中運行著兩個或兩個以上的一樣的節點，當某個主節點出現故障的時候，那么其他作為從 節點的節點就會接替主節點上面的任務。從節點可以接管主節點的資源（IP地址，架構身份等），此時用戶不會發現提供服務的對象從主節點轉移到從節點。
? ?高可用性集群的作用：當一個機器宕機另一臺進行接管。比較常用的高可用集群開源軟件有：keepalive，heardbeat。
（3）高性能計算集群
?高性能計算集群采用將計算任務分配到集群的不同計算節點兒提高計算能力，因而主要應用在科學計算領域。比較流行的HPC采用Linux操作系統和其它一些免費軟件來完成并行運算。這一集群配置通常被稱為Beowulf集群。這類集群通常運行特定的程序以發揮HPCcluster的并行能力。這類程序一般應用特定的運行庫, 比如專為科學計算設計的MPI庫。
? ?HPC集群特別適合于在計算中各計算節點之間發生大量數據通訊的計算作業，比如一個節點的中間結果或影響到其它節點計算結果的情況。
常用集群軟硬件
常用開源集群軟件有：lvs，keepalived，haproxy，nginx，apache，heartbeat
常用商業集群硬件有：F5,Netscaler，Radware，A10等
?
二、LVS負載均衡集群介紹
負載均衡集群的作用：提供一種廉價、有效、透明的方法，來擴展網絡設備和服務器的負載帶寬、增加吞吐量，加強網絡數據處理能力、提高網絡的靈活性和可用性。
1）把單臺計算機無法承受的大規模的并發訪問或數據流量分擔到多臺節點設備上分別處理，減少用戶等待響應的時間，提升用戶體驗。
2）單個重負載的運算分擔到多臺節點設備上做并行處理，每個節點設備處理結束后，將結果匯總，返回給用戶，系統處理能力得到大幅度提高。
3）7*24小時的服務保證，任意一個或多個設備節點設備宕機，不能影響到業務。在負載均衡集群中，所有計算機節點都應該提供相同的服務，集群負載均衡獲取所有對該服務的如站請求。
LVS介紹
LVS是linux virtual server的簡寫linux虛擬服務器，是一個虛擬的服務器集群系統，可以再unix/linux平臺下實現負載均衡集群功能。該項目在1998年5月由章文嵩博士組織成立。
以下是LVS官網提供的4篇文章：（非常詳細，我覺得有興趣還是看官方文檔比較正宗吧！！）
http://www.linuxvirtualserver.org/zh/lvs1.html
http://www.linuxvirtualserver.org/zh/lvs2.html
http://www.linuxvirtualserver.org/zh/lvs3.html
http://www.linuxvirtualserver.org/zh/lvs4.html
IPVS發展史
早在2.2內核時，IPVS就已經以內核補丁的形式出現。
從2.4.23版本開始ipvs軟件就是合并到linux內核的常用版本的內核補丁的集合。
從2.4.24以后IPVS已經成為linux官方標準內核的一部分
? ?從上圖可以看出lpvs是工作在內核層，我們不能夠直接操作ipvs，vs負載均衡調度技術是在linux內核中實現的。因此，被稱之為linux虛擬服務器。我們使用該軟件配置lvs的時候，不能直接配置內核中的ipvs，而需要使用ipvs的管理工具ipvsadm進行管理。通過keepalived也可以管理LVS。
LVS體系結構與工作原理簡單描述
LVS集群負載均衡器接受服務的所有入展客戶端的請求，然后根據調度算法決定哪個集群節點來處理回復客戶端的請求。
LVS虛擬服務器的體系如下圖所示，一組服務器通過高速的局域網或者地理分布的廣域網相互連接，在這組服務器之前有一個負載調度器（load balance）。負載調度器負責將客戶的請求調度到真實服務器上。這樣這組服務器集群的結構對用戶來說就是透明的。客戶訪問集群系統就如只是訪問一臺高性能，高可用的服務器一樣。客戶程序不受服務器集群的影響，不做任何修改。
就比如說：我們去飯店吃飯點菜，客戶只要跟服務員點菜就行。并不需要知道具體他們是怎么分配工作的，所以他們內部對于我們來說是透明的。此時這個服務員就會按照一定的規則把他手上的活，分配到其他人員上去。這個服務員就是負載均衡器（LB）而后面這些真正做事的就是服務器集群。
底下是官網提供的結構圖：
LVS的基本工作過程
客戶請發送向負載均衡服務器發送請求。負載均衡器接受客戶的請求，然后先是根據LVS的調度算法（8種）來決定要將這個請求發送給哪個節點服務器。然后依據自己的工作模式（3種）來看應該如何把這些客戶的請求如何發送給節點服務器，節點服務器又應該如何來把響應數據包發回給客戶端。
恩，那這樣我們就只要接下來搞懂LVS的3中工作模式，8種調度算法就可以了。
?
LVS的三種工作模式：
1）VS/NAT模式（Network address translation）
2）VS/TUN模式（tunneling）
3）DR模式（Direct routing）
?
1、NAT模式-網絡地址轉換
? ? ? ? Virtualserver via Network address translation(VS/NAT)
這個是通過網絡地址轉換的方法來實現調度的。首先調度器(LB)接收到客戶的請求數據包時（請求的目的IP為VIP），根據調度算法決定將請求發送給哪個后端的真實服務器（RS）。然后調度就把客戶端發送的請求數據包的目標IP地址及端口改成后端真實服務器的IP地址（RIP）,這樣真實服務器（RS）就能夠接收到客戶的請求數據包了。真實服務器響應完請求后，查看默認路由（NAT模式下我們需要把RS的默認路由設置為LB服務器。）把響應后的數據包發送給LB,LB再接收到響應包后，把包的源地址改成虛擬地址（VIP）然后發送回給客戶端。
調度過程IP包詳細圖：
原理圖簡述：
1)客戶端請求數據，目標IP為VIP
2)請求數據到達LB服務器，LB根據調度算法將目的地址修改為RIP地址及對應端口（此RIP地址是根據調度算法得出的。）并在連接HASH表中記錄下這個連接。
3)數據包從LB服務器到達RS服務器webserver，然后webserver進行響應。Webserver的網關必須是LB，然后將數據返回給LB服務器。
4)收到RS的返回后的數據，根據連接HASH表修改源地址VIP&目標地址CIP，及對應端口80.然后數據就從LB出發到達客戶端。
5)客戶端收到的就只能看到VIP\DIP信息。
NAT模式優缺點：
1、NAT技術將請求的報文和響應的報文都需要通過LB進行地址改寫，因此網站訪問量比較大的時候LB負載均衡調度器有比較大的瓶頸，一般要求最多之能10-20臺節點
2、只需要在LB上配置一個公網IP地址就可以了。
3、每臺內部的節點服務器的網關地址必須是調度器LB的內網地址。
4、NAT模式支持對IP地址和端口進行轉換。即用戶請求的端口和真實服務器的端口可以不一致。
?
2、TUN模式
virtual server via ip tunneling模式:采用NAT模式時，由于請求和響應的報文必須通過調度器地址重寫，當客戶請求越來越多時，調度器處理能力將成為瓶頸。為了解決這個問題，調度器把請求的報文通過IP隧道轉發到真實的服務器。真實的服務器將響應處理后的數據直接返回給客戶端。這樣調度器就只處理請求入站報文，由于一般網絡服務應答數據比請求報文大很多，采用VS/TUN模式后，集群系統的最大吞吐量可以提高10倍。
VS/TUN的工作流程圖如下所示，它和NAT模式不同的是，它在LB和RS之間的傳輸不用改寫IP地址。而是把客戶請求包封裝在一個IP tunnel里面，然后發送給RS節點服務器，節點服務器接收到之后解開IP tunnel后，進行響應處理。并且直接把包通過自己的外網地址發送給客戶不用經過LB服務器。
Tunnel原理流程圖:
原理圖過程簡述：
1）客戶請求數據包，目標地址VIP發送到LB上。
2）LB接收到客戶請求包，進行IP Tunnel封裝。即在原有的包頭加上IP Tunnel的包頭。然后發送出去。
3）RS節點服務器根據IP Tunnel包頭信息（此時就又一種邏輯上的隱形隧道，只有LB和RS之間懂）收到請求包，然后解開IP Tunnel包頭信息，得到客戶的請求包并進行響應處理。
4）響應處理完畢之后，RS服務器使用自己的出公網的線路，將這個響應數據包發送給客戶端。源IP地址還是VIP地址。（RS節點服務器需要在本地回環接口配置VIP，后續會講）
?
3、DR模式（直接路由模式）
Virtual server via direct routing (vs/dr)
DR模式是通過改寫請求報文的目標MAC地址，將請求發給真實服務器的，而真實服務器響應后的處理結果直接返回給客戶端用戶。同TUN模式一樣，DR模式可以極大的提高集群系統的伸縮性。而且DR模式沒有IP隧道的開銷，對集群中的真實服務器也沒有必要必須支持IP隧道協議的要求。但是要求調度器LB與真實服務器RS都有一塊網卡連接到同一物理網段上，必須在同一個局域網環境。
DR模式是互聯網使用比較多的一種模式。
DR模式原理圖：
DR模式原理過程簡述：
VS/DR模式的工作流程圖如上圖所示，它的連接調度和管理與NAT和TUN中的一樣，它的報文轉發方法和前兩種不同。DR模式將報文直接路由給目標真實服務器。在DR模式中，調度器根據各個真實服務器的負載情況，連接數多少等，動態地選擇一臺服務器，不修改目標IP地址和目標端口，也不封裝IP報文，而是將請求報文的數據幀的目標MAC地址改為真實服務器的MAC地址。然后再將修改的數據幀在服務器組的局域網上發送。因為數據幀的MAC地址是真實服務器的MAC地址，并且又在同一個局域網。那么根據局域網的通訊原理，真實復位是一定能夠收到由LB發出的數據包。真實服務器接收到請求數據包的時候，解開IP包頭查看到的目標IP是VIP。（此時只有自己的IP符合目標IP才會接收進來，所以我們需要在本地的回環借口上面配置VIP。另：由于網絡接口都會進行ARP廣播響應，但集群的其他機器都有這個VIP的lo接口，都響應就會沖突。所以我們需要把真實服務器的lo接口的ARP響應關閉掉。）然后真實服務器做成請求響應，之后根據自己的路由信息將這個響應數據包發送回給客戶，并且源IP地址還是VIP。
DR模式小結：
1、通過在調度器LB上修改數據包的目的MAC地址實現轉發。注意源地址仍然是CIP，目的地址仍然是VIP地址。
2、請求的報文經過調度器，而RS響應處理后的報文無需經過調度器LB，因此并發訪問量大時使用效率很高（和NAT模式比）
3、因為DR模式是通過MAC地址改寫機制實現轉發，因此所有RS節點和調度器LB只能在一個局域網里面
4、RS主機需要綁定VIP地址在LO接口上，并且需要配置ARP抑制。
5、RS節點的默認網關不需要配置成LB，而是直接配置為上級路由的網關，能讓RS直接出網就可以。
6、由于DR模式的調度器僅做MAC地址的改寫，所以調度器LB就不能改寫目標端口，那么RS服務器就得使用和VIP相同的端口提供服務。
官方三種負載均衡技術比較總結表：
工作模式 | VS/NAT | VS/TUN | VS/DR |
Real ?server （節點服務器） | Config dr gw | Tunneling | Non-arp device/tie vip |
Server Network | Private | LAN/WAN | LAN |
Server number （節點數量） | Low 10-20 | High 100 | High 100 |
Real server gateway | Load balance | Own router | Own router |
優點 | 地址和端口轉換 | Wan環境加密數據 | 性能最高 |
缺點 | 效率低 | 需要隧道支持 | 不能跨域LAN |
LVS調度算法
最好參考此文章：http://www.linuxvirtualserver.org/zh/lvs4.html
Lvs的調度算法決定了如何在集群節點之間分布工作負荷。當director調度器收到來自客戶端訪問VIP的上的集群服務的入站請求時，director調度器必須決定哪個集群節點應該處理請求。Director調度器用的調度方法基本分為兩類：
固定調度算法：rr，wrr，dh，sh
動態調度算法：wlc，lc，lblc，lblcr
?
算法 | 說明 |
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，并以它作為下一次分配的首先考慮。 |
LVS調度算法的生產環境選型：
1、一般的網絡服務，如http，mail，mysql等常用的LVS調度算法為：
a.基本輪詢調度rr
b.加權最小連接調度wlc
c.加權輪詢調度wrc
2、基于局部性的最小連接lblc和帶復制的給予局部性最小連接lblcr主要適用于web cache和DB cache
3、源地址散列調度SH和目標地址散列調度DH可以結合使用在防火墻集群中，可以保證整個系統的出入口唯一。
實際適用中這些算法的適用范圍很多，工作中最好參考內核中的連接調度算法的實現原理，然后根據具體的業務需求合理的選型。
?
-----------------后續自我小結--------------------------------------------------
基本上lvs的原理部分就到這里，個人還是覺得像要對LVS有一個比較全面的認識，還是需要去將官方文檔認真的看過一遍。主要部分還是在于3種工作方式和8種調度算法。以及實際工作種什么樣的生產環境適用哪種調度算法。
-------------------------------------------------------------------------------
?
轉載于:https://my.oschina.net/denglz/blog/416168
總結
- 上一篇： 关于后缀自动机的总结
- 下一篇： Postgres 9.5的特性及未来发展