負載均衡叢集

1、叢集是什麼？

1 叢集（cluster）技術是一種較新的技術，通過叢集技術，可以在付出較低成本的情況下獲得在效能、可靠性、靈活性方面的相對較高的收益，其任務排程則是叢集系統中的核心技術。

2 叢集組成後，可以利用多個計算機和組合進行海量請求處理（負載均衡），從而獲得很高的處理效率，也可以用多個計算機做備份（高可用），使得任何一個機器壞了整個系統還是能正常執行。

2、負載均衡叢集技術

① 負載均衡（Load Balance）：負載均衡叢集為企業需求提供了可解決容量問題的有效方案。負載均衡叢集使負載可以在計算機叢集中儘可能平均地分攤處理。

② 負載通常包括應用程式處理負載和網路流量負載,每個節點都可以承擔一定的處理負載，並且可以實現處理負載在節點之間的動態分配，以實現負載均衡。

3、負載均衡叢集技術的實現

負載均衡（Load Balance）

負載均衡技術型別：基於 4 層負載均衡技術和基於 7 層負載均衡技術

負載均衡實現方式：硬體負載均衡裝置或者軟體負載均衡

硬體負載均衡產品：F5 、深信服 、Radware

軟體負載均衡產品： LVS（Linux Virtual Server）、 Haproxy、Nginx、Ats（apache traffic server）

4、實現效果如圖

5、負載均衡分類

負載均衡根據所採用的裝置物件（軟/硬體負載均衡），應用的OSI網路層次（網路層次上的負載均衡）等來分類。下面著重介紹的是根據應用的 OSI 網路層次來分類的兩個負載均衡型別。

負載均衡可以大概分為以下幾類：

• 二層負載均衡（mac）
  一般是用虛擬mac地址方式，外部對虛擬MAC地址請求，負載均衡接收後分配後端實際的MAC地址響應。
• 三層負載均衡（ip）
  一般採用虛擬IP地址方式，外部對虛擬的ip地址請求，負載均衡接收後分配後端實際的IP地址響應。
• 四層負載均衡（tcp）
  在三層負載均衡的基礎上，用ip+port接收請求，再轉發到對應的機器。
• 七層負載均衡（http）
  根據虛擬的url或IP，主機名接收請求，再轉向相應的處理伺服器。

在實際應用中，比較常見的就是四層負載及七層負載。這裡也重點說下這兩種負載。

6、四層負載均衡（基於IP+埠的負載均衡）

實現四層負載均衡的軟體有：

• F5：硬體負載均衡器，功能很好，但是成本很高。
• lvs：重量級的四層負載軟體
• nginx：輕量級的四層負載軟體，帶快取功能，正規表示式較靈活
• haproxy：模擬四層轉發，較靈活

7、七層的負載均衡（基於虛擬的URL或主機IP的負載均衡)

1. 在四層負載均衡的基礎上（沒有四層是絕對不可能有七層的），再考慮應用層的特徵，比如同一個Web伺服器的負載均衡，除了根據VIP加80埠辨別是否需要處理的流量，還可根據七層的URL、瀏覽器類別來決定是否要進行負載均衡。
2. 實現七層負載均衡的軟體有：

• haproxy：天生負載均衡技能，全面支援七層代理，會話保持，標記，路徑轉移；
• nginx：只在http協議和mail協議上功能比較好，效能與haproxy差不多；
• apache：功能較差
• Mysql proxy：功能尚可。

 

8、四層負載與七層負載的區別

 |          | 四層負載均衡              | 七層負載均衡                               |
 +----------+-------------------------+----------------------------------------------+
 | 基於      | 基於IP+Port的           | 基於虛擬的URL或主機IP等。                        |
 +----------+-------------------------+----------------------------------------------+
 | 類似於    | 路由器                   | 代理伺服器                                     |
 +----------+-------------------------+----------------------------------------------+
 | 複雜度    | 低                      | 高                                           |
 +----------+-------------------------+----------------------------------------------+
 | 效能     | 高；無需解析內容           | 中；需要演算法識別 URL，HTTP head 等資訊 |
 +----------+-------------------------+----------------------------------------------+
 | 安全性   | 低，                      | 高，                                        |
 +----------+-------------------------+----------------------------------------------+
 | 額外功能  | 無                       | 會話保持，圖片壓縮，等                     |

總結：從上面的對比看來四層負載與七層負載最大的區別就是效率與功能的區別。四層負載架構設計比較簡單，無需解析具體的訊息內容，在網路吞吐量及處理能力上會相對比較高，而七層負載均衡的優勢則體現在功能多，控制靈活強大。在具體業務架構設計時，使用七層負載或者四層負載還得根據具體的情況綜合考慮。

9、LVS 實現四層負載均衡專案實戰

1、LVS 介紹

（1）LVS 是Linux Virtual Server的簡稱，也就是 Linux 虛擬伺服器, 是一個由章文嵩博士發起的自由軟體專案，它的官方站點是www.linuxvirtualserver.org。現在LVS已經是 Linux標準核心的一部分，因此效能較高。

（2）LVS軟體作用：通過LVS提供的負載均衡技術和Linux作業系統實現一個高效能、高可用的伺服器群集，它具有良好可靠性、可擴充套件性和可操作性。從而以低廉的成本實現最優的服務效能。

2、LVS 優勢與不足

1、優勢

高併發連線：LVS基於核心網路層面工作，有超強的承載能力和併發處理能力。單臺LVS負載均衡器，可支援上萬併發連線。

穩定性強：是工作在網路4層之上僅作分發之用，這個特點也決定了它在負載均衡軟體裡的效能最強，穩定性最好，對記憶體和cpu資源消耗極低。

成本低廉：硬體負載均衡器少則十幾萬，多則幾十萬上百萬，LVS只需一臺伺服器和就能免費部署使用，價效比極高。

配置簡單：LVS配置非常簡單，僅需幾行命令即可完成配置，也可寫成指令碼進行管理。

支援多種演算法：支援多種論調演算法，可根據業務場景靈活調配進行使用

支援多種工作模型：可根據業務場景，使用不同的工作模式來解決生產環境請求處理問題。

應用範圍廣：因為LVS工作在4層，所以它幾乎可以對所有應用做負載均衡，包括http、資料庫、DNS、ftp服務等等

3、不足

工作在4層，不支援7層規則修改，不適合小規模應用。

4、LVS 核心元件和專業術語

1、核心元件

LVS的管理工具和核心模組 ipvsadm/ipvs

ipvsadm：使用者空間的命令列工具，用於管理叢集服務及叢集服務上的RS等；

ipvs：工作於核心上的程式，可根據使用者定義的叢集實現請求轉發；

2、專業術語

VS：Virtual Server #虛擬服務

Director, Balancer #負載均衡器、分發器

RS：Real Server #後端請求處理伺服器

CIP: Client IP #使用者端IP

VIP：Director Virtual IP #負載均衡器虛擬IP

DIP：Director IP #負載均衡器IP

RIP：Real Server IP #後端請求處理伺服器IP

3、具體圖解

4、LVS負載均衡工作模式

 LVS/NAT：網路地址轉換模式，進站/出站的資料流量經過分發器(IP負載均衡，他修改的是IP地址)  --利用三層功能
 LVS/DR  ：直接路由模式，只有進站的資料流量經過分發器(資料鏈路層負載均衡，因為他修改的是目的mac地址)--利用二層功能mac地址
 LVS/TUN： 隧道模式，只有進站的資料流量經過分發器

5、LVS 四種工作模式原理、以及優缺點比較

1、NAT模式（VS-NAT） 原理：就是把客戶端發來的資料包的IP頭的目的地址，在負載均衡器上換成其中一臺RS的IP地址，併發至此RS來處理,RS處理完成後把資料交給經過負載均衡器,負載均衡器再把資料包的原IP地址改為自己的IP，將目的地址改為客戶端IP地址即可｡期間,無論是進來的流量,還是出去的流量,都必須經過負載均衡器｡ 優點：叢集中的物理伺服器可以使用任何支援TCP/IP作業系統，只有負載均衡器需要一個合法的IP地址。 缺點：擴充套件性有限。當伺服器節點（普通PC伺服器）增長過多時,負載均衡器將成為整個系統的瓶頸，因為所有的請求包和應答包的流向都經過負載均衡器。當伺服器節點過多時，大量的資料包都交匯在負載均衡器那，速度就會變慢！

2、直接路由(Direct routing)模式（VS-DR） 原理：負載均衡器和RS都使用同一個IP對外服務｡但只有DR對ARP請求進行響應,所有RS對本身這個IP的ARP請求保持靜默｡也就是說,閘道器會把對這個服務IP的請求全部定向給DR,而DR收到資料包後根據排程演算法,找出對應的RS,把目的MAC地址改為RS的MAC（因為IP一致）並將請求分發給這臺RS｡這時RS收到這個資料包,處理完成之後，由於IP一致，可以直接將資料返給客戶，則等於直接從客戶端收到這個資料包無異,處理後直接返回給客戶端｡ 優點：和TUN（隧道模式）一樣，負載均衡器也只是分發請求，應答包通過單獨的路由方法返回給客戶端。與VS-TUN相比，VS-DR這種實現方式不需要隧道結構，因此可以使用大多數作業系統做為物理伺服器。 缺點：（不能說缺點，只能說是不足）要求負載均衡器的網路卡必須與物理網路卡在一個物理段上。

3、IP隧道(Tunnel)模式（VS-TUN）

原理：網際網路上的大多Internet服務的請求包很短小，而應答包通常很大。那麼隧道模式就是，把客戶端發來的資料包，封裝一個新的IP頭標記(僅目的IP)發給RS,RS收到後,先把資料包的頭解開,還原資料包,處理後,直接返回給客戶端,不需要再經過負載均衡器｡注意,由於RS需要對負載均衡器發過來的資料包進行還原,所以說必須支援IPTUNNEL協議｡所以,在RS的核心中,必須編譯支援IPTUNNEL這個選項 ​ 優點：負載均衡器只負責將請求包分發給後端節點伺服器，而RS將應答包直接發給使用者。所以，減少了負載均衡器的大量資料流動，負載均衡器不再是系統的瓶頸，就能處理很巨大的請求量，這種方式，一臺負載均衡器能夠為很多RS進行分發。而且跑在公網上就能進行不同地域的分發。 ​ 缺點：隧道模式的RS節點需要合法IP，這種方式需要所有的伺服器支援”IP Tunneling”(IP Encapsulation)協議。

4、FULL-NAT模式原理:客戶端對VIP發起請求，Director接過請求發現是請求後端服務。Direcrot對請求報文做full-nat，把源ip改為Dip，把目標ip轉換為任意後端RS的rip，然後發往後端，rs接到請求後，進行響應，相應源ip為Rip目標ip還是DIP，又內部路由路由到Director,Director接到響應報文，進行full-nat。將源地址為VIP，目標地址改為CIP

請求使用DNAT，響應使用SNAT

6、四者的區別

lvs-nat與lvs-fullnat：請求和響應報文都經由Director

　　lvs-nat：RIP的閘道器要指向DIP

　　 lvs-fullnat：RIP和DIP未必在同一IP網路，但要能通訊

lvs-dr與lvs-tun：請求報文要經由Director，但響應報文由RS直接發往Client

　　 lvs-dr：通過封裝新的MAC首部實現，通過MAC網路轉發

　　 lvs-tun：通過在原IP報文外封裝新IP頭實現轉發，支援遠距離通訊

6、LVS ipvsadm 命令的使用

1、LVS-server安裝lvs管理軟體

 yum -y install ipvsadm

程式包：ipvsadm（LVS管理工具）

主程式：/usr/sbin/ipvsadm

規則儲存工具：/usr/sbin/ipvsadm-save > /path/to/file

配置檔案：/etc/sysconfig/ipvsadm-config

2、命令選項

 -A --add-service #在伺服器列表中新新增一條新的虛擬伺服器記錄
 -t #表示為tcp服務
 -s --scheduler #使用的排程演算法， rr | wrr | lc | wlc | lblb | lblcr | dh | sh | sed | nq 預設排程演算法是 wlc
 固定排程演算法：rr，wrr，dh，sh
 動態排程演算法：wlc，lc，sed，nq，lblc，lblcr
 ​
 -a --add-server  #在伺服器表中新增一條新的真實主機記錄
 -t --tcp-service #說明虛擬伺服器提供tcp服務
 -u --udp-service #說明虛擬伺服器提供udp服務
 -r --real-server #真實伺服器地址
 -m --masquerading #指定LVS工作模式為NAT模式
 -w --weight #真實伺服器的權值
 -g --gatewaying #指定LVS工作模式為直接路由器模式（也是LVS預設的模式）
 -i --ip #指定LVS的工作模式為隧道模式
 ​
 -C -clear #清除核心虛擬伺服器表中的所有記錄。
 -R -restore #恢復虛擬伺服器規則
 -S -save #儲存虛擬伺服器規則到標準輸出，輸出為-R 選項可讀的格式
 -d -delete-server #刪除一條虛擬伺服器記錄中的某條真實伺服器記錄
 -L|-l –list #顯示核心虛擬伺服器表
 --numeric, -n：#以數字形式輸出地址和埠號

7、LVS 負載均衡叢集企業級應用實戰

2、環境準備

1、準備虛擬機器

準備 3 臺純淨的虛擬機器，兩臺 web 伺服器

2、LVS-server 安裝lvs管理軟體

 [root@lvs-server ~]# yum -y install ipvsadm

程式包：ipvsadm（LVS管理工具）

主程式：/usr/sbin/ipvsadm

規則儲存工具：/usr/sbin/ipvsadm-save > /path/to/file

配置檔案：/etc/sysconfig/ipvsadm-config

3、LVS/DR 模式

實驗說明： 1.網路使用NAT模式 2.DR模式要求Director DIP 和 所有RealServer RIP必須在同一個網段及廣播域 3.所有節點閘道器均指定真實閘道器

2、LVS/DR模式實施

1、準備工作（叢集中所有主機）關閉防火牆和selinux

 [root@lvs-server ~]# cat /etc/hosts
 127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
 ::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
 192.168.246.166 lvs-server
 192.168.246.161 real-server1
 192.168.246.162 real-server2

2、Director分發器配置

配置VIP

 [root@lvs-server ~]# ip addr add dev ens33 192.168.246.160/32 #設定VIP
 [root@lvs-server ~]# yum install -y ipvsadm   #RHEL確保LoadBalancer倉庫可用
 [root@lvs-server ~]# service ipvsadm start  #啟動
 注意:啟動如果報錯: /bin/bash: /etc/sysconfig/ipvsadm: 沒有那個檔案或目錄
 需要手動生成檔案
 [root@lvs-server ~]# ipvsadm --save > /etc/sysconfig/ipvsadm

定義LVS分發策略

 -A：新增VIP
 -t：用的是tcp協議
 -a：新增的是lo的vip地址
 -r：轉發到real-serve rip
 -s：演算法
 -L|-l –list #顯示核心虛擬伺服器表
 --numeric, -n：#以數字形式輸出地址和埠號
 -g --gatewaying #指定LVS工作模式為直接路由器模式（也是LVS預設的模式）
 -S -save #儲存虛擬伺服器規則到標準輸出，輸出為-R 選項可讀的格式
 rr：輪循
 如果新增ip錯了，刪除命令如下:
 # ip addr del 192.168.246.193 dev ens33
 [root@lvs-server ~]# ipvsadm -C  #清除核心虛擬伺服器表中的所有記錄。
 [root@lvs-server ~]# ipvsadm -A -t 192.168.246.160:80 -s rr 
 [root@lvs-server ~]# ipvsadm -a -t 192.168.246.160:80 -r 192.168.246.161 -g 
 [root@lvs-server ~]# ipvsadm -a -t 192.168.246.160:80 -r 192.168.246.162 -g  
 [root@lvs-server ~]# service ipvsadm save #儲存方式一，使用下面的儲存方式，版本7已經不支援了
 [root@lvs-server ~]# ipvsadm -S > /etc/sysconfig/ipvsadm  #儲存方式二，儲存到一個檔案中
 [root@lvs-server ~]# ipvsadm -ln
 IP Virtual Server version 1.2.1 (size=4096)
 Prot LocalAddress:Port Scheduler Flags
   -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
 TCP  192.168.246.160:80 rr
   -> 192.168.246.161:80           Route   1      0          0         
   -> 192.168.246.162:80           Route   1      0          0         
 [root@lvs-server ~]# ipvsadm -L -n       
 [root@lvs-server ~]# ipvsadm -L -n --stats    #顯示統計資訊
 1. Conns    (connections scheduled)  已經轉發過的連線數
 2. InPkts   (incoming packets)       入包個數
 3. OutPkts  (outgoing packets)       出包個數
 4. InBytes  (incoming bytes)         入流量（位元組）  
 5. OutBytes (outgoing bytes)         出流量（位元組）
 [root@lvs-server ~]# ipvsadm -L -n --rate   #看速率
 1. CPS      (current connection rate)   每秒連線數
 2. InPPS    (current in packet rate)    每秒的入包個數
 3. OutPPS   (current out packet rate)   每秒的出包個數
 4. InBPS    (current in byte rate)      每秒入流量（位元組）
 5. OutBPS   (current out byte rate)      每秒出流量（位元組）

3、所有RS配置

配置好網站伺服器，測試所有RS #為了測試效果，提供不同的頁面（以下兩臺real-server都操作）

 [root@real-server1 ~]# yum install -y nginx
 [root@real-server1 ~]# echo "real-server1" >> /usr/share/nginx/html/index.html
 兩臺機器都安裝，按順序新增不同的主機名以示區分
 [root@real-server1 ~]# ip addr add dev lo 192.168.246.160/32   #在lo介面上繫結VIP
 [root@real-server1 ~]# echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore  #忽略arp廣播
 [root@real-server1 ~]# echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce #匹配精確ip地址回包
 [root@real-server1 ~]# systemctl start nginx 
 [root@real-server1 ~]# systemctl enable  nginx 
 =============================================================================
 因為：realServer的vip有了，接著就是同一個網段中擁有兩個vip, 客戶端在閘道器傳送arp廣播需找vip時需要讓realServer不接受響應.  
 解決：
 echo 1 >/proc/sys/net/ipv4/conf/eth0/arp_ignore 
 arp_ignore 設定為1，意味著當別人的arp請求過來的時候，如果接收的裝置沒有這個ip，就不做出響應(這個ip在lo上，lo不是接收裝置的進口)
 echo 2 >/proc/sys/net/ipv4/conf/eth0/arp_announce   
 使用最好的ip來回應，什麼是最好的ip？同一個網段內子網掩碼最長的

4、測試

 [root@client ~]# elinks -dump http://192.168.246.160
 -dump:非互動式模式

8、LVS的排程演算法

LVS的排程演算法分為靜態與動態兩類。

1、靜態演算法（4種）

只根據演算法進行排程 而不考慮後端伺服器的實際連線情況和負載情況

①.RR：輪叫排程（Round Robin）

　 排程器通過”輪叫”排程演算法將外部請求按順序輪流分配到叢集中的真實伺服器上，它均等地對待每一臺伺服器，而不管伺服器上實際的連線數和系統負載｡

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

　 排程器通過“加權輪叫”排程演算法根據真實伺服器的不同處理能力來排程訪問請求。這樣可以保證處理能力強的伺服器處理更多的訪問流量。排程器可以自動問詢真實伺服器的負載情況,並動態地調整其權值。

③.DH：目標地址雜湊排程（Destination Hash ）

　 根據請求的目標IP地址，作為雜湊鍵(HashKey)從靜態分配的雜湊表找出對應的伺服器，若該伺服器是可用的且未超載，將請求傳送到該伺服器，否則返回空。

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

　 源地址雜湊”排程演算法根據請求的源IP地址，作為雜湊鍵(HashKey)從靜態分配的雜湊表找出對應的伺服器，若該伺服器是可用的且未超載，將請求傳送到該伺服器，否則返回空｡

2、動態演算法（6種）

前端的排程器會根據後端真實伺服器的實際連線情況來分配請求

①.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就直接分配過去，保證不會有一個主機很空間。

⑤.LBLC：基於區域性性的最少連結（locality-Based Least Connections）

　 基於區域性性的最少連結”排程演算法是針對目標IP地址的負載均衡，目前主要用於Cache叢集系統｡該演算法根據請求的目標IP地址找出該目標IP地址最近使用的伺服器，若該伺服器是可用的且沒有超載，將請求傳送到該伺服器;若伺服器不存在，或者該伺服器超載且有伺服器處於一半的工作負載，則用“最少連結”的原則選出一個可用的伺服器，將請求傳送到該伺服器｡

⑥. LBLCR：帶複製的基於區域性性最少連線（Locality-Based Least Connections with Replication）

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