負載均衡叢集（LB）

負載均衡叢集工作原理

當用戶傳送請求時，該請求不是立即傳送給後端的真實伺服器（realservers），而是先發送給排程器或者分發器（director），到達Director的資料包首先會經過PREROUTING，而後經過路由發現其目標地址為本地某介面的地址，因此，接著就會將資料包發往INPUT(LOCAL_IN HOOK)。此時，正在執行核心中的ipvs（始終監控著LOCAL_IN HOOK）程序會發現此資料包請求的是一個叢集服務，因為其目標地址是VIP。於是，此資料包本來到達本機(Director)的目標行程被改變為經由POSTROUTING HOOK發往RealServer伺服器處理，處理請求完成後，再響應給客戶端。這種改變資料包正常行程的過程是根據IPVS表(由管理員通過ipvsadm定義)來實現的。

負載均衡裝置

剛剛所說的排程器或者分發器是一種負載均衡裝置，這種裝置有硬體和軟體之分：

常見的硬體負載均衡裝置：

1、F5 BIG-IP

2、Citrix NetScale

3、A10

常見的軟體負載均衡軟體

四層負載均衡軟體：

LVS：全稱Linux Virtual Server，LVS是由電子科技大學的章文嵩博士創立的基於LINUX核心的負載均衡技術。。LVS可以相容目前大多數的網路服務，具備高可用性和高伸縮性的特徵，易於管理。LVS應用非常廣泛。

haproxy也可以用於4層負載均衡。

七層負載均衡軟體：

nginx、haproxy。一般用在反向代理功能。

LVS負載均衡型別

由於LVS在開源界使用比較廣泛，因此本文主要使用的LVS這種負載均衡裝置，來實現負載均衡功能。

實現LVS負載均衡叢集方式有三種：

一、網路地址轉換（NAT）

其工作模型如下：

這種方式的工作原理和DNAT的工作原理非常相似。首先，當客戶端傳送的報文請求到達排程器director時，排程器director根據連線排程演算法從一組真實的伺服器組中選擇一個真實伺服器進行響應，並將其報文的目標ip由VIP改為RIP，報文的目標埠，改為伺服器的目標埠。當後端的真實伺服器響應報文時，將其報文的源ip由RIP改為VIP，其報文的源埠也改為相應的埠。最後由排程器director將響應報文返回給客戶端。整個過程對於使用者來說，只知道排程器對外的VIP，其後端的真實伺服器地址是不知道，因此，對於使用者來說，整個集群系統是透明的。這種地址轉換類似於iptables的DNAT。LVS的NAT模型主要用於隱藏real server的ip場景。

該方式下的資料報文流向為:

CIP→VIP→DIP→RIP→DIP→VIP→CIP

基於NAT實現叢集功能具有如下特性：

1、real server必須和DIP在同一個IP網路中

2、由於資料包達到director是要修改資料包的目標地址和目標埠（做類似於iptables的DNAT），因此RIP通常是私有IP。

3、director位於client和real server之間，負責所處理進出的所有通訊。

4、real server必須將閘道器指向DIP

5、支援埠對映

6、real server可以使用任意OS

7、高負載場景中，由於director處理所有的通訊，承載壓力較大，因此，director易成為系統瓶頸。

二、直接路由DR

在NAT模型中，由於director處理所有的通訊，即接受請求還要處理響應。因此，承載壓力比較大。在DR模型中，director只負責處理請求，而不負責響應。響應報文直接由後端的real server直接返回。

該方式是實現LVS負載均衡叢集最廣泛的方式，其工作模型如下：

其工作原理為：首先客戶端傳送的請求會達到排程器director時，director根據各伺服器的負載能力，動態的選擇後端一臺真實伺服器進行響應，排程器既不修改報文ip，也不封裝ip，而是修改報文的目標MAC地址，並將剛剛選擇的那臺伺服器的MAC地址作為目標MAC地址，然後在區域網中傳輸。因此，各個伺服器節點與director必須在同一個物理網段中。當後端的真實伺服器響應報文請求時，使用該伺服器隱藏的VIP作為源ip，CIP作為目標ip，直接響應給客戶端。因此，在後端的每一個伺服器上面都有一個VIP，這個VIP不接受任何請求，僅僅只是在響應報文時，作為源IP響應客戶端而已,因此，需要特定的機制將RS上的VIP其隱藏起來。

該方式下的資料報文流向為:

CIP→VIP→DIP→RIP→CIP

這種方式實現的叢集具有如下特性：

1、各個伺服器節點和director必須在同一個物理網段中。可以和VIP不在同一個物理網段內。

2、RIP可以是私網地址，也可以是公網地址，從而便捷的遠端管理和監控。

3、director僅僅負責處理入站請求報文，響應報文由real server直接返回給客戶端。

4、real server不能將閘道器指向DIP。而是指向前端路由器地址，該路由器可以連線外網。

5、real server上需要配置VIP地址，並且禁止響應前端路由器傳送的ARP廣播。

6、不支援埠對映。

7、RS可以使用大多數的作業系統。

三、TUN，IP隧道方式

實現這種方式的叢集，各個伺服器必須處於不同的網段中，這是一種擴充套件的DR模型。

其工作模型如下：

工作原理是：首先，客戶端傳送的請求會到達排程器director，然後排程器會動態的選擇一臺後端伺服器進行響應。然後排程器與該伺服器動態的建立隧道（不是靜態的建立），並且此時排程器會重新封裝該報文請求（即有2個ip首部）。當伺服器收到請求後，拆去外層封裝，並對該報文進行響應，響應報文直接由real server返回給客戶端。響應時源ip為VIP，目標ip為CIP。因此，此時各個伺服器上面必須要有隱藏的VIP。

該方式下的資料報文流向為:

CIP→VIP→DIP→RIP→CIP

這種方式實現的叢集具有如下特性：

1、叢集節點可以跨越Internet

2、RIP必須是公網ip

3、director僅負責處理入站請求報文，響應報文由real server直接返回給客戶端

4、real server不能將閘道器指向DIP

5、只有支援隧道功能的OS才可以當做real server

6、不支援埠對映

排程演算法

上面每一種方式實現的叢集功能，請求報文都要傳送到排程器director，那麼排程器又是根據什麼條件來選擇相應的後端真實伺服器來響應請求報文的呢？這就要根據排程器director選擇的排程演算法來選擇了。

排程演算法一共有10種。其中有4種為靜態排程演算法，有6種為動態排程演算法

4種靜態排程演算法：

1、迴圈排程：Round-Robin Scheduling，簡稱RR

這種排程演算法是將請求報文按照順序傳送給後端真實的伺服器進行處理，它不考慮伺服器的處理能力，均等的對待每一個伺服器。這種排程模型和迴圈 DNS相似，但是它更粗糙些，因為它是基於網路連線的而不是基於主機的。這種演算法簡潔，排程器不需要記錄所有的連線狀態，是一種無狀態排程。

2、加權迴圈排程：Weight Round-Robin Scheduling，簡稱WRR

這種排程演算法也是將請求按照順序傳送給後端的真實伺服器進行響應處理。但是每個伺服器的響應能力由所佔權重的比例來決定的，我們根據伺服器的不同處理能力，給它分配一個不同的權重，使其接受相應權重所佔比例的服務請求。適用於各個叢集節點的處理能力大相徑庭的場景。如有3太伺服器，其權重為3,2,1。那麼前3個請求由第一臺伺服器處理。接著後2個請求由第二臺伺服器處理。最後1個請求由第三臺伺服器進行處理。

3、源雜湊排程：Source Hash Scheduling，簡稱SH

這種排程演算法主要實現session繫結，保留該使用者之前訪問的session資訊。是根據請求報文的源ip，作為雜湊鍵（Hash Key），從靜態分配的散列表中找出相應的伺服器地址，若該伺服器是可用的且未超出負載，則將該請求傳送給該伺服器進行處理，否則返回空。可以將同一個使用者的請求始終定向到同一臺伺服器進行響應。這種排程演算法違反了負載均衡原則。

4、目標雜湊排程：Destination Hash Scheduling，簡稱DH

這種排程演算法和源雜湊排程演算法大致相同。將請求報文的目標ip地址作為雜湊鍵，從靜態分配的散列表中找出相應的伺服器地址。若該伺服器是可用的且未超出負載，則將該請求交給該伺服器進行處理，否則返回空。

6種動態排程演算法：

1、最少連線：Least-Connection，簡稱LC

這種排程演算法是根據伺服器中的連線數來決定伺服器的負載能力的。最少連線排程演算法會將下一次新的請求轉發給最少連線數的伺服器進行處理。因此，director需要記錄各個伺服器已建立的連線數。當一個新的請求排程到某臺伺服器上時，則該伺服器的連線數加1,當某個連線超時或斷開，則該伺服器的連線數減1,。如果某臺伺服器的權重為0,表示該伺服器不可使用而不被排程。計演算法則為active*256+inactive。其中active為活躍的連線數，inactive為非活躍的連線數。通常而言，活動連線佔用系統資源比非活動連線佔用系統資源要多得多。因此，這種排程演算法也並非最合理。該排程演算法適用於各個叢集節點的處理能力大致相同。

2、加權最少連線法：Weight Least-Connections，簡稱WLC

這種排程演算法是根據伺服器的連線數和他們的權重比值來決定將請求傳送給哪臺伺服器來進行響應的。計演算法則為(active*256+inactive)/weight,哪個伺服器的該值最小，則有那臺伺服器進行響應。

3、基於本地的最少連線排程：Locally-Base Leaset-Connection Scheduling,簡稱LBLC

這種排程演算法主要是根據報文的目標ip進行負載均衡的。主要用於cache叢集。由於報文的目標ip地址是經常變化的，假設當後端的任意real server都能夠進行處理時，那麼每臺real server都保留當時訪問的cache。並且每臺保留的cache還都不一樣。這樣將會導致客戶在訪問同一頁面時，得到的結果可能不一樣。這種排程演算法的設計目標是將相同目標ip的報文交給同一個real server進行處理。這樣當用戶訪問同一個資源時，得到的結果一定是一樣的。這樣大大提高了cache命中率和集群系統的處理能力。

該演算法根據請求報文的目標ip找出最近一次該目標ip使用的的realsever。如果該real server是可用的，則將該請求轉發給該伺服器進行處理；如果該伺服器是不可用的或者工作負載超過了一半，則會根據“最少連線演算法”，選擇一個可用的伺服器進行處理。

4、帶有複製排程的基於本地的最少連線排程：Locally-Base Leaset-Connection Scheduling with Replication Scheduling，簡稱LBLCR

該排程演算法也是基於目標ip來說實現負載均衡的，它與 LBLC演算法不同之處在於，它是將同一個ip對映到多臺real server中，這樣不管報文由哪臺伺服器進行處理，得到的結果都是一樣的。因此，這樣的real server彼此之間能夠相互訪問且彼此之間的cache能夠相互複製，僅僅是複製自己沒有的那一部分。

該演算法根據請求的目標IP地址找出該目標IP地址對應的伺服器組，按“最小連線”原則從伺服器組中選出一臺伺服器，若伺服器沒有超載，將請求傳送到該伺服器；若伺服器超載，則按“最小連線”原則從這個叢集中選出一臺伺服器，將該伺服器加入到伺服器組中，將請求傳送到該伺服器。同時，當該伺服器組有一段時間沒有被修改，將最忙的伺服器從伺服器組中刪除，以降低複製的程度。

5、最短的期望的延遲：Shortest Expected Delay Scheduling,簡稱SED

這種演算法是基於WLC演算法的。排程器將新的請求轉發給（active+1)*256/weight的值最小的伺服器進行處理。該排程演算法忽略了非活躍的連線數。

6、永不排隊：Never Queue Scheduling，簡稱NQ

這種排程演算法是改進的SED演算法。當新的請求到來時，如果某臺real server處於空閒狀態或者連線數=0，則director會將請求轉發給該real server進行處理。因此不需要排隊（佇列）等待。

靜態排程演算法和動態排程演算法的區別

就個人理解，靜態排程演算法不能夠動態察覺到伺服器的負載能力，而動態排程演算法就可以根據伺服器的負載能力，相應的選擇real server進行響應。雖然靜態排程演算法中可以根據權重來分擔不同的請求處理能力，但是使用這種排程演算法的叢集，其伺服器效能卻大相徑庭。

ipvs規則管理工具ipvsadm

ipvsadm是運行於使用者空間，用來與ipvs進行互動的命令列工具。而真正實現功能的是工作在核心中的ipvs這個框架。這有點類似於iptables/netfilter的架構思想。

ipvsadm主要作用表現在：

1、定義director是誰，以及在director上哪些real server用來提供此服務

2、可以為每一臺提供某一種相同服務的伺服器設定權重（即根據伺服器的效能來確定其承擔負載的能力）

注意：權重用整數來表示，有時候也可以將其設定為atomic_t；其有效表示值範圍為24bit整數空間，即（2^24-1）；

根據不同的功能，ipvsadm的使用語法格式也不同，這些功能包括如下：

1、使用ipvsadm來管理叢集服務（即定義、修改、刪除director）

格式為：ipvsadm {-A|-E|-D} {-t|-u|-f} service-address [-s scheduler]

-A:表示新增一個叢集

-E:表示修改某個叢集

-D:表示刪除某個叢集

-t:表示tcp叢集

-u:表示udp叢集

-f:用來做防火牆標記

service-address:director的VIP地址和埠號，即格式為：VIP:PORT

-s scheduler：表示該叢集服務使用哪種排程演算法

-p: timeout persistent connection 持久連線

2、使用ipvsadm來管理叢集中的real server

格式為：ipvsadm {-a|-e|-d} {-t|-u|-f} service-address -r real-server-address [-g|-i|-m] [-w weight]

-a:表示新增一個real server

-e:表示修改某個real server

-d:表示刪除某個real server

server-address：為事先定義好的director上的VIP和PORT

real-server-address:即提供某種服務的real server的ip（或ip:port）

-g:表示使用DR這種方式來實現LVS負載均衡

-i:表示使用TUN這種方式來實現LVS負載均衡

-m:表示使用NAT這種方式來實現LVS負載均衡

3、使用ipvsadm來檢視叢集服務

格式為：ipvsadm {-L|-l} {option}

-L、-l：顯示核心中的虛擬伺服器規則列表。它後面還可以接許多子選項，包括：

-n：以數字的方式來顯示主機地址和埠

--stats:顯示統計資訊

--rate：顯示速率資訊

--timeout:顯示tcp、tcpfin和udp的會話超時時長

-c: 顯示當前的ipvs連線狀況

--deamon:顯示同步守護程序的狀態

--sort：對VIP和real server的ip進行排序輸出

--exact：精確顯示，不做單位換算

4、刪除所有叢集服務

格式：ipvsadm -C 清空所有ipvs規則

5、儲存所有規則

格式：ipvsadm -S > /path/to/somefile

或者ipvsadm-save > /path/to/somefile

6、載入之前儲存的規則

格式：ipvsadm -R < /path/to/somefile

或者ipvsadm-restore < /path/to/somefile

7、顯示ipvs和ipvsadm的版本號

格式：

ipvsadm:不接任何選項，用來顯示ipvs的版本號

ipvsadm --version:表示顯示ipvsadm的版本號

8、計數器清零

ipvsadm -Z

session持久機制

在某些應用場景中，通常需要保持session的永續性。如在電商架構中，某個使用者買到的商品加入到購物車中後，此時一重新整理，剛剛買到的商品在購物車中就沒有了，那麼該使用者的體驗就非常不好了，感覺這個網站很詭異似的。我們知道當頁面重新整理後，該請求被定向到其他伺服器去了，而這臺伺服器根本就沒有這個使用者的session資訊，於是一重新整理後，購物車上的商品就沒有了。但是對於使用者來說，他們根本就不知道發生了什麼問題，只是感覺網站有問題而已，對於這樣的場景，不管使用者如何重新整理頁面，都需要保持此前的的資訊要存在，也就說此前的session資訊必須存在，不能因為頁面一重新整理session資訊就丟失了。保持session資訊永續性有3種方式：

1、session繫結，即將同一個請求者的連線始終定向到同一臺伺服器上（第一次請求時仍然由排程器決定）。不過這種方式沒有容錯能力，即當這臺伺服器掛了之後，其session資訊也會丟失。有損負載均衡效果。

2、session複製或session叢集。即在所有的real sever之間同步session，是的所有的real sever都有相同的session資訊。不過此種方式並不適應於大伺服器叢集環境。

3、session伺服器，即將一臺共享伺服器作為session伺服器，所有的叢集節點當需要載入session資訊，直接到後端的session伺服器載入即可。

ipvsadm使用中注意的問題

預設情況下，ipvsadm在輸出主機資訊時使用其主機名而非IP地址，因此，Director需要使用名稱解析服務。如果沒有設定名稱解析服務、服務不可用或設定錯誤，ipvsadm將會一直等到名稱解析超時後才返回。當然，ipvsadm需要解析的名稱僅限於RealServer，考慮到DNS提供名稱解析服務效率不高的情況，建議將所有RealServer的名稱解析通過/etc/hosts檔案來實現；

注意：在做叢集服務時，各節點之間的時間偏差不應該超出1秒鐘；可以使用NTP服務來進行時間同步

NTP：Network Time Protocol

轉載於:https://blog.51cto.com/xslwahaha/1587182