負載均衡

LVS

一、LVS簡介

LVS（Linux Virtual Server）即Linux虛擬伺服器，是由章文嵩博士主導的開源負載均衡專案，目前LVS已經被整合到Linux核心模組中。該專案在Linux核心中實現了基於IP的資料請求負載均衡排程方案，其體系結構如圖1所示，終端網際網路使用者從外部訪問公司的外部負載均衡伺服器，終端使用者的Web請求會發送給LVS排程器，排程器根據自己預設的演算法決定將該請求傳送給後端的某臺Web伺服器，比如，輪詢演算法可以將外部的請求平均分發給後端的所有伺服器，終端使用者訪問LVS排程器雖然會被轉發到後端真實的伺服器，但如果真實伺服器連線的是相同的儲存，提供的服務也是相同的服務，終端使用者不管是訪問哪臺真實伺服器，得到的服務內容都是一樣的，整個叢集對使用者而言都是透明的。最後根據LVS工作模式的不同，真實伺服器會選擇不同的方式將使用者需要的資料傳送到終端使用者，LVS工作模式分為NAT模式、TUN模式、以及DR模式。

二、三種工作模式的解析。

1、基於NAT的LVS模式負載均衡

NAT（Network Address Translation）即網路地址轉換，其作用是通過資料報頭的修改，使得位於企業內部的私有IP地址可以訪問外網，以及外部用使用者可以訪問位於公司內部的私有IP主機。VS/NAT工作模式拓撲結構如圖2所示，LVS負載排程器可以使用兩塊網絡卡配置不同的IP地址，eth0設定為私鑰IP與內部網路通過交換裝置相互連線，eth1裝置為外網IP與外部網路聯通。

第一步，使用者通過網際網路DNS伺服器解析到公司負載均衡裝置上面的外網地址，相對於真實伺服器而言，LVS外網IP又稱VIP（Virtual IP Address），使用者通過訪問VIP，即可連線後端的真實伺服器（Real Server），而這一切對使用者而言都是透明的，使用者以為自己訪問的就是真實伺服器，但他並不知道自己訪問的VIP僅僅是一個排程器，也不清楚後端的真實伺服器到底在哪裡、有多少真實伺服器。

第二步，使用者將請求傳送至124.126.147.168，此時LVS將根據預設的演算法選擇後端的一臺真實伺服器（192.168.0.1~192.168.0.3），將資料請求包轉發給真實伺服器，並且在轉發之前LVS會修改資料包中的目標地址以及目標埠，目標地址與目標埠將被修改為選出的真實伺服器IP地址以及相應的埠。

第三步，真實的伺服器將響應資料包返回給LVS排程器，排程器在得到響應的資料包後會將源地址和源埠修改為VIP及排程器相應的埠，修改完成後，由排程器將響應資料包傳送回終端使用者，另外，由於LVS排程器有一個連線Hash表，該表中會記錄連線請求及轉發資訊，當同一個連線的下一個資料包傳送給排程器時，從該Hash表中可以直接找到之前的連線記錄，並根據記錄資訊選出相同的真實伺服器及埠資訊。

2、基於TUN的LVS負載均衡

在LVS（NAT）模式的叢集環境中，由於所有的資料請求及響應的資料包都需要經過LVS排程器轉發，如果後端伺服器的數量大於10臺，則排程器就會成為整個叢集環境的瓶頸。我們知道，資料請求包往往遠小於響應資料包的大小。因為響應資料包中包含有客戶需要的具體資料，所以LVS（TUN）的思路就是將請求與響應資料分離，讓排程器僅處理資料請求，而讓真實伺服器響應資料包直接返回給客戶端。VS/TUN工作模式拓撲結構如圖3所示。其中，IP隧道（IP tunning）是一種資料包封裝技術，它可以將原始資料包封裝並新增新的包頭（內容包括新的源地址及埠、目標地址及埠），從而實現將一個目標為排程器的VIP地址的資料包封裝，通過隧道轉發給後端的真實伺服器（Real Server），通過將客戶端發往排程器的原始資料包封裝，並在其基礎上新增新的資料包頭（修改目標地址為排程器選擇出來的真實伺服器的IP地址及對應埠），LVS（TUN）模式要求真實伺服器可以直接與外部網路連線，真實伺服器在收到請求資料包後直接給客戶端主機響應資料。

3、基於DR的LVS負載均衡

在LVS（TUN）模式下，由於需要在LVS排程器與真實伺服器之間建立隧道連線，這同樣會增加伺服器的負擔。與LVS（TUN）類似，DR模式也叫直接路由模式，其體系結構如圖4所示，該模式中LVS依然僅承擔資料的入站請求以及根據演算法選出合理的真實伺服器，最終由後端真實伺服器負責將響應資料包傳送返回給客戶端。與隧道模式不同的是，直接路由模式（DR模式）要求排程器與後端伺服器必須在同一個區域網內，VIP地址需要在排程器與後端所有的伺服器間共享，因為最終的真實伺服器給客戶端迴應資料包時需要設定源IP為VIP地址，目標IP為客戶端IP，這樣客戶端訪問的是排程器的VIP地址，迴應的源地址也依然是該VIP地址（真實伺服器上的VIP），客戶端是感覺不到後端伺服器存在的。由於多臺計算機都設定了同樣一個VIP地址，所以在直接路由模式中要求排程器的VIP地址是對外可見的，客戶端需要將請求資料包傳送到排程器主機，而所有的真實伺服器的VIP地址必須配置在Non-ARP的網路裝置上，也就是該網路裝置並不會向外廣播自己的MAC及對應的IP地址，真實伺服器的VIP對外界是不可見的，但真實伺服器卻可以接受目標地址VIP的網路請求，並在迴應資料包時將源地址設定為該VIP地址。排程器根據演算法在選出真實伺服器後，在不修改資料報文的情況下，將資料幀的MAC地址修改為選出的真實伺服器的MAC地址，通過交換機將該資料幀發給真實伺服器。整個過程中，真實伺服器的VIP不需要對外界可見。

三、LVS負載均衡排程演算法

根據前面的介紹，我們瞭解了LVS的三種工作模式，但不管實際環境中採用的是哪種模式，排程演算法進行排程的策略與演算法都是LVS的核心技術，LVS在核心中主要實現了一下十種排程演算法。

1.輪詢排程

輪詢排程（Round Robin 簡稱'RR'）演算法就是按依次迴圈的方式將請求排程到不同的伺服器上，該演算法最大的特點就是實現簡單。輪詢演算法假設所有的伺服器處理請求的能力都一樣的，排程器會將所有的請求平均分配給每個真實伺服器。

2.加權輪詢排程

加權輪詢（Weight Round Robin 簡稱'WRR'）演算法主要是對輪詢演算法的一種優化與補充，LVS會考慮每臺伺服器的效能，並給每臺伺服器新增一個權值，如果伺服器A的權值為1，伺服器B的權值為2，則排程器排程到伺服器B的請求會是伺服器A的兩倍。權值越高的伺服器，處理的請求越多。

3.最小連線排程

最小連線排程（Least Connections 簡稱'LC'）演算法是把新的連線請求分配到當前連線數最小的伺服器。最小連線排程是一種動態的排程演算法，它通過伺服器當前活躍的連線數來估計伺服器的情況。排程器需要記錄各個伺服器已建立連線的數目，當一個請求被排程到某臺伺服器，其連線數加1；當連線中斷或者超時，其連線數減1。

（集群系統的真實伺服器具有相近的系統性能，採用最小連線排程演算法可以比較好地均衡負載。)

4.加權最小連線排程

加權最少連線（Weight Least Connections 簡稱'WLC'）演算法是最小連線排程的超集，各個伺服器相應的權值表示其處理效能。伺服器的預設權值為1，系統管理員可以動態地設定伺服器的權值。加權最小連線排程在排程新連線時儘可能使伺服器的已建立連線數和其權值成比例。排程器可以自動問詢真實伺服器的負載情況，並動態地調整其權值。

5.基於區域性的最少連線

基於區域性的最少連線排程（Locality-Based Least Connections 簡稱'LBLC'）演算法是針對請求報文的目標IP地址的 負載均衡排程，目前主要用於Cache集群系統，因為在Cache叢集客戶請求報文的目標IP地址是變化的。這裡假設任何後端伺服器都可以處理任一請求，演算法的設計目標是在伺服器的負載基本平衡情況下，將相同目標IP地址的請求排程到同一臺伺服器，來提高各臺伺服器的訪問區域性性和Cache命中率，從而提升整個集群系統的處理能力。LBLC排程演算法先根據請求的目標IP地址找出該目標IP地址最近使用的伺服器，若該伺服器是可用的且沒有超載，將請求傳送到該伺服器；若伺服器不存在，或者該伺服器超載且有伺服器處於一半的工作負載，則使用'最少連線'的原則選出一個可用的伺服器，將請求傳送到伺服器。

6.帶複製的基於區域性性的最少連線

帶複製的基於區域性性的最少連線（Locality-Based Least Connections with Replication 簡稱'LBLCR'）演算法也是針對目標IP地址的負載均衡，目前主要用於Cache集群系統，它與LBLC演算法不同之處是它要維護從一個目標IP地址到一組伺服器的對映，而LBLC演算法維護從一個目標IP地址到一臺伺服器的對映。按'最小連線'原則從該伺服器組中選出一一臺伺服器，若伺服器沒有超載，將請求傳送到該伺服器；若伺服器超載，則按'最小連線'原則從整個叢集中選出一臺伺服器，將該伺服器加入到這個伺服器組中，將請求傳送到該伺服器。同時，當該伺服器組有一段時間沒有被修改，將最忙的伺服器從伺服器組中刪除，以降低複製的程度。

7.目標地址雜湊排程

目標地址雜湊排程（Destination Hashing 簡稱'DH'）演算法先根據請求的目標IP地址，作為雜湊鍵（Hash Key）從靜態分配的散列表找出對應的伺服器，若該伺服器是可用的且並未超載，將請求傳送到該伺服器，否則返回空。

8.源地址雜湊排程U

源地址雜湊排程（Source Hashing 簡稱'SH'）演算法先根據請求的源IP地址，作為雜湊鍵（Hash Key）從靜態分配的散列表找出對應的伺服器，若該伺服器是可用的且並未超載，將請求傳送到該伺服器，否則返回空。它採用的雜湊函式與目標地址雜湊排程演算法的相同，它的演算法流程與目標地址雜湊排程演算法的基本相似。

9.最短的期望的延遲

最短的期望的延遲排程（Shortest Expected Delay 簡稱'SED'）演算法基於WLC演算法。舉個例子吧，ABC三臺伺服器的權重分別為1、2、3 。那麼如果使用WLC演算法的話一個新請求進入時它可能會分給ABC中的任意一個。使用SED演算法後會進行一個運算

A：（1+1）/1=2 B：（1+2）/2=3/2 C：（1+3）/3=4/3 就把請求交給得出運算結果最小的伺服器。

10.最少佇列排程

最少佇列排程（Never Queue 簡稱'NQ'）演算法，無需佇列。如果有realserver的連線數等於0就直接分配過去，不需要在進行SED運算。

高可用

Keepalived

keepalived的高可用，分為搶佔模式和非搶佔模式。

搶佔模式是當master從故障中恢復後，會將VIP從BACKUP中搶過來。

非搶佔模式是master恢復後不搶佔backup升級為master後的vip。

1、Keepalived簡介

Keepalived是什麼？

keepalived是叢集管理中保證叢集高可用的一個服務軟體，其功能類似於heartbeat，用來防止單點故障。

VRRP協議與工作原理

VRRP協議是一種容錯的主備模式的協議，保證當主機的下一跳路由出現故障時，由另一臺路由器來代替出現故障的路由器進行工作，通過VRRP可以在網路發生故障時透明的進行裝置切換而不影響主機之間的資料通訊。

虛擬路由器：虛擬路由器是VRRP備份組中所有路由器的集合，它是一個邏輯概念，並不是正真存在的。從備份組外面看備份組中的路由器，感覺組中的所有路由器就像一個 一樣，可以理解為在一個組中： 主路由器+所有備份路由器=虛擬路由器。虛擬路由器有一個虛擬的IP地址和MAC地址。主機將虛擬路由器當作預設閘道器。虛擬MAC地址的格式為00-00-5E-00-01-{VRID}。通常情況下，虛擬路由器迴應ARP請求使用的是虛擬MAC地址，只有虛擬路由器做特殊配置的時候，才回應介面的真實MAC地址。

VRRP選舉機制
VRRP路由器在執行過程中有三種狀態：

1. Initialize狀態： 系統啟動後就進入Initialize，此狀態下路由器不對VRRP報文做任何處理；

2. Master狀態；

3. Backup狀態；

一般主路由器處於Master狀態，備份路由器處於Backup狀態。

VRRP使用選舉機制來確定路由器的狀態，優先順序選舉：
1.VRRP組中IP擁有者。如果虛擬IP地址與VRRP組中的某臺VRRP路由器IP地址相同，則此路由器為IP地址擁有者，這臺路由器將被定位主路由器。
2.比較優先順序。如果沒有IP地址擁有者，則比較路由器的優先順序，優先順序的範圍是0~255，優先順序大的作為主路由器
3.比較IP地址。在沒有Ip地址擁有者和優先順序相同的情況下，IP地址大的作為主路由器。

VRRP工作原理

路由器使用VRRP 功能後，會根據優先順序確定自己在組中的角色。優先順序高的路由器成為Master 路由器，優先順序低的成為Backup 路由器。Master 擁有對外服務的虛擬IP，提供各種網路功能，並定期傳送VRRP 報文，通知備份組內的其他裝置自己工作正常；Backup 路由器只接收Master 發來的報文資訊，用來監控Master 的執行狀態。當Master 失效時，Backup 路由器進行選舉，優先順序高的Backup 將成為新的Master 。

在搶佔方式下，當Backup 路由器收到VRRP 報文後，會將自己的優先順序與報文中的優先順序進行比較。如果大於通告報文中的優先順序，則成為Master 路由器；否則將保持Backup狀態；

在非搶佔方式下，只要Master 路由器沒有出現故障，備份組中的路由器始終保持Master 或Backup 狀態，Backup 路由器即使隨後被配置了更高的優先順序也不會成為Master 路由器；

如果Backup 路由器的定時器超時後仍未收到Master 路由器傳送來的VRRP報文，則認為Master 路由器已經無法正常工作，此時Backup 路由器會認為自己是Master 路由器，並對外發送VRRP報文。備份組內的路由器根據優先順序選舉出Master 路由 器，承擔報文的轉發功能。

2、Keepalvied的工作原理

Keepalived高可用服務之間的故障切換轉移，是通過VRRP（Virtual Router Redundancy Protocol，虛擬路由器冗餘協議）來實現的。在Keepalived服務正常工作時，主Master節點會不斷地向備節點發送（多播的方式）心跳訊息，用以告訴備Backup節點自己還活著，當主Master節點發生故障時，就無法傳送心跳訊息，備節點也就因此無法繼續檢測到來自主Master節點的心跳了，於是呼叫自身的接管程式，接管主Master節點的IP資源及服務。而當主Master節點恢復時，備Backup節點又會釋放主節點故障時自身接管的IP資源及服務，恢復到原來的備用角色。

keepalived執行時，會啟動3個程序，分別為：core(核心程序)，check和vrrp

• core：負責主程序的啟動，維護和全域性配置檔案的載入；
• check：負責健康檢查
• vrrp：用來實現vrrp協議

一般Keepalived是實現前端高可用，常用的前端高可用的組合有，就是我們常見的LVS+Keepalived、Nginx+Keepalived、HAproxy+Keepalived。而Heartbeat或Corosync是實現服務的高可用，常見的組合有Heartbeat v3(Corosync)+Pacemaker+NFS+Httpd 實現Web伺服器的高可用、Heartbeat v3(Corosync)+Pacemaker+NFS+MySQL 實現MySQL伺服器的高可用。總結一下，Keepalived中實現輕量級的高可用，一般用於前端高可用，且不需要共享儲存，一般常用於兩個節點的高可用。而Heartbeat(或Corosync)一般用於服務的高可用，且需要共享儲存，一般用於多節點的高可用。

LVS、Nginx和HAProxy區別

LVS優缺點

LVS的優點：

1、抗負載能力強、工作在第4層僅作分發之用，沒有流量的產生，這個特點也決定了它在負載均衡軟體裡的效能最強的；無流量，同時保證了均衡器IO的效能不會受到大流量的影響；
2、工作穩定，自身有完整的雙機熱備方案，如LVS+Keepalived和LVS+Heartbeat；
3、應用範圍比較廣，可以對所有應用做負載均衡；
4、配置性比較低，這是一個缺點也是一個優點，因為沒有可太多配置的東西，所以並不需要太多接觸，大大減少了人為出錯的機率；

LVS的缺點：

1、軟體本身不支援正則處理，不能做動靜分離，這就凸顯了Nginx/HAProxy+Keepalived的優勢。
2、如果網站應用比較龐大，LVS/DR+Keepalived就比較複雜了，特別是後面有Windows Server應用的機器，實施及配置還有維護過程就比較麻煩，相對而言，Nginx/HAProxy+Keepalived就簡單多了。

Nginx優缺點

Nginx的優點：

1、工作在OSI第7層，可以針對http應用做一些分流的策略。比如針對域名、目錄結構。它的正則比HAProxy更為強大和靈活；
2、Nginx對網路的依賴非常小，理論上能ping通就就能進行負載功能，這個也是它的優勢所在；
3、Nginx安裝和配置比較簡單，測試起來比較方便；
4、可以承擔高的負載壓力且穩定，一般能支撐超過幾萬次的併發量；
5、Nginx可以通過埠檢測到伺服器內部的故障，比如根據伺服器處理網頁返回的狀態碼、超時等等，並且會把返回錯誤的請求重新提交到另一個節點；
6、Nginx不僅僅是一款優秀的負載均衡器/反向代理軟體，它同時也是功能強大的Web應用伺服器。LNMP現在也是非常流行的web環境，大有和LAMP環境分庭抗禮之勢，Nginx在處理靜態頁面、特別是抗高併發方面相對apache有優勢；
7、Nginx現在作為Web反向加速快取越來越成熟了，速度比傳統的Squid伺服器更快，有需求的朋友可以考慮用其作為反向代理加速器；

Nginx的缺點：

1、Nginx不支援url來檢測。
2、Nginx僅能支援http和Email，這個它的弱勢。
3、Nginx的Session的保持，Cookie的引導能力相對欠缺。

HAProxy優缺點

HAProxy的優點：

1、HAProxy是支援虛擬主機的，可以工作在4、7層(支援多網段)；
2、能夠補充Nginx的一些缺點比如Session的保持，Cookie的引導等工作；
3、支援url檢測後端的伺服器；
4、它跟LVS一樣，本身僅僅就只是一款負載均衡軟體；單純從效率上來講HAProxy更會比Nginx有更出色的負載均衡速度，在併發處理上也是優於Nginx的；
5、HAProxy可以對Mysql讀進行負載均衡，對後端的MySQL節點進行檢測和負載均衡，不過在後端的MySQL slaves數量超過10臺時效能不如LVS；
6、HAProxy的演算法較多，達到8種；

三者對比：

LVS： 是基於四層的轉發
HAproxy： 是基於四層和七層的轉發，是專業的代理伺服器
Nginx： 是WEB伺服器，快取伺服器，又是反向代理伺服器，可以做七層的轉發

區別： LVS由於是基於四層的轉發所以只能做埠的轉發
而基於URL的、基於目錄的這種轉發LVS就做不了

工作選擇：

HAproxy和Nginx由於可以做七層的轉發，所以URL和目錄的轉發都可以做
在很大併發量的時候我們就要選擇LVS，像中小型公司的話併發量沒那麼大
選擇HAproxy或者Nginx足已，由於HAproxy由是專業的代理伺服器
配置簡單，所以中小型企業推薦使用HAproxy