LVS 三種模型集羣

時間 2020-02-16

原文原文鏈接

LVS的IP負載均衡前端

前言簡介web

可伸縮網絡服務的幾種結構，它們都須要一個前端的負載調度器（或者多個進行主從備份）。咱們先分析實現虛擬網絡服務的主要技術，指出IP負載均衡技術是在負載調度器的實現技術中效率最高的。在已有的IP負載均衡技術中，主要有經過網絡地址轉換（Network Address Translation）將一組服務器構成一個高性能的、高可用的虛擬服務器，咱們稱之爲VS/NAT技術（Virtual Server via Network Address Translation）。在分析VS/NAT的缺點和網絡服務的非對稱性的基礎上，咱們提出了經過IP隧道實現虛擬服務器的方法VS/TUN （Virtual Server via IP Tunneling），和經過直接路由實現虛擬服務器的方法VS/DR（Virtual Server via Direct Routing），它們能夠極大地提升系統的伸縮性。VS/NAT、VS/TUN和VS/DR技術是LVS集羣中實現的三種IP負載均衡技術。算法

1、LVS-NATvim

客戶經過Virtual IP Address（虛擬服務的IP地址）訪問網絡服務時，請求報文到達調度器，調度器根據鏈接調度算法從一組真實服務器中選出一臺服務器，將報文的目標地址Virtual IP Address改寫成選定服務器的地址，報文的目標端口改寫成選定服務器的相應端口，最後將修改後的報文發送給選出的服務器。同時，調度器在鏈接Hash 表中記錄這個鏈接，當這個鏈接的下一個報文到達時，從鏈接Hash表中能夠獲得原選定服務器的地址和端口，進行一樣的改寫操做，並將報文傳給原選定的服務器。當來自真實服務器的響應報文通過調度器時，調度器將報文的源地址和源端口改成Virtual IP Address和相應的端口，再把報文發給用戶。這樣，客戶所看到的只是在Virtual IP Address上提供的服務，而服務器集羣的結構對用戶是透明的。對改寫後的報文，應用增量調整Checksum的算法調整TCP Checksum的值，避免了掃描整個報文來計算Checksum的開銷。後端

VS/NAT的體系結構如圖所示。服務器

2、LVS-DR網絡

跟VS/TUN 方法相同，VS/DR利用大多數Internet服務的非對稱特色，負載調度器中只負責調度請求，而服務器直接將響應返回給客戶，能夠極大地提升整個集羣系統的吞吐量。VS/DR的體系結構如圖所示：調度器和服務器組都必須在物理上有一個網卡經過不分斷的局域網相連，如經過高速的交換機或者HUB相連。VIP地址爲調度器和服務器組共享，調度器配置的VIP地址是對外可見的，用於接收虛擬服務的請求報文；全部的服務器把VIP地址配置在各自的Non-ARP網絡設備上，它對外面是不可見的，只是用於處理目標地址爲VIP的網絡請求。負載均衡

3、LVS-TUNide

在VS/NAT 的集羣系統中，請求和響應的數據報文都須要經過負載調度器，當真實服務器的數目在10臺和20臺之間時，負載調度器將成爲整個集羣系統的新瓶頸。大多數Internet服務都有這樣的特色：請求報文較短而響應報文每每包含大量的數據。若是能將請求和響應分開處理，即在負載調度器中只負責調度請求而響應直接返回給客戶，將極大地提升整個集羣系統的吞吐量。函數

IP隧道（IP tunneling）是將一個IP報文封裝在另外一個IP報文的技術，這可使得目標爲一個IP地址的數據報文能被封裝和轉發到另外一個IP地址。IP隧道技術亦稱爲IP封裝技術（IP encapsulation）。IP隧道主要用於移動主機和虛擬私有網絡（Virtual Private Network），在其中隧道都是靜態創建的，隧道一端有一個IP地址，另外一端也有惟一的IP地址。

咱們利用IP隧道技術將請求報文封裝轉發給後端服務器，響應報文能從後端服務器直接返回給客戶。但在這裏，後端服務器有一組而非一個，因此咱們不可能靜態地創建一一對應的隧道，而是動態地選擇一臺服務器，將請求報文封裝和轉發給選出的服務器。這樣，咱們能夠利用IP隧道的原理將一組服務器上的網絡服務組成在一個IP地址上的虛擬網絡服務。VS/TUN的體系結構如圖所示，各個服務器將VIP地址配置在本身的IP隧道設備上。

4、LVS的負載調度

在內核中的鏈接調度算法上，IPVS已實現瞭如下八種調度算法：

輪叫調度（Round-Robin Scheduling）

輪叫調度（Round Robin Scheduling）算法就是以輪叫的方式依次將請求調度不一樣的服務器，即每次調度執行i = (i + 1) mod n，並選出第i臺服務器。算法的優勢是其簡潔性，它無需記錄當前全部鏈接的狀態，因此它是一種無狀態調度。

加權輪叫調度（Weighted Round-Robin Scheduling）

加權輪叫調度（Weighted Round-Robin Scheduling）算法能夠解決服務器間性能不一的狀況，它用相應的權值表示服務器的處理性能，服務器的缺省權值爲1。假設服務器A的權值爲1，B的權值爲2，則表示服務器B的處理性能是A的兩倍。加權輪叫調度算法是按權值的高低和輪叫方式分配請求到各服務器。權值高的服務器先收到的鏈接，權值高的服務器比權值低的服務器處理更多的鏈接，相同權值的服務器處理相同數目的鏈接數。

最小鏈接調度（Least-Connection Scheduling）

最小鏈接調度（Least-Connection Scheduling）算法是把新的鏈接請求分配到當前鏈接數最小的服務器。最小鏈接調度是一種動態調度算法，它經過服務器當前所活躍的鏈接數來估計服務器的負載狀況。調度器須要記錄各個服務器已創建鏈接的數目，當一個請求被調度到某臺服務器，其鏈接數加1；當鏈接停止或超時，其鏈接數減一。

加權最小鏈接調度（Weighted Least-Connection Scheduling）

加權最小鏈接調度（Weighted Least-Connection Scheduling）算法是最小鏈接調度的超集，各個服務器用相應的權值表示其處理性能。服務器的缺省權值爲1，系統管理員能夠動態地設置服務器的權值。加權最小鏈接調度在調度新鏈接時儘量使服務器的已創建鏈接數和其權值成比例。

基於局部性的最少連接（Locality-Based Least Connections Scheduling）

基於局部性的最少連接調度（Locality-Based Least Connections Scheduling，如下簡稱爲LBLC）算法是針對請求報文的目標IP地址的負載均衡調度，目前主要用於Cache集羣系統，由於在Cache集羣中客戶請求報文的目標IP地址是變化的。這裏假設任何後端服務器均可以處理任一請求，算法的設計目標是在服務器的負載基本平衡狀況下，將相同目標IP地址的請求調度到同一臺服務器，來提升各臺服務器的訪問局部性和主存Cache命中率，從而整個集羣系統的處理能力。LBLC調度算法先根據請求的目標IP地址找出該目標IP地址最近使用的服務器，若該服務器是可用的且沒有超載，將請求發送到該服務器；若服務器不存在，或者該服務器超載且有服務器處於其一半的工做負載，則用「最少連接」的原則選出一個可用的服務器，將請求發送到該服務器。

帶複製的基於局部性最少連接（Locality-Based Least Connections with Replication Scheduling）

帶複製的基於局部性最少連接調度（Locality-Based Least Connections with Replication Scheduling，如下簡稱爲LBLCR）算法也是針對目標IP地址的負載均衡，目前主要用於Cache集羣系統。它與LBLC算法的不一樣之處是它要維護從一個目標IP地址到一組服務器的映射，而LBLC算法維護從一個目標IP地址到一臺服務器的映射。對於一個「熱門」站點的服務請求，一臺Cache 服務器可能會忙不過來處理這些請求。這時，LBLC調度算法會從全部的Cache服務器中按「最小鏈接」原則選出一臺Cache服務器，映射該「熱門」站點到這臺Cache服務器，很快這臺Cache服務器也會超載，就會重複上述過程選出新的Cache服務器。這樣，可能會致使該「熱門」站點的映像會出如今全部的Cache服務器上，下降了Cache服務器的使用效率。LBLCR調度算法將「熱門」站點映射到一組Cache服務器（服務器集合），當該「熱門」站點的請求負載增長時，會增長集合裏的Cache服務器，來處理不斷增加的負載；當該「熱門」站點的請求負載下降時，會減小集合裏的Cache服務器數目。這樣，該「熱門」站點的映像不太可能出如今全部的Cache服務器上，從而提供Cache集羣系統的使用效率。LBLCR算法先根據請求的目標IP地址找出該目標IP地址對應的服務器組；按「最小鏈接」原則從該服務器組中選出一臺服務器，若服務器沒有超載，將請求發送到該服務器；若服務器超載；則按「最小鏈接」原則從整個集羣中選出一臺服務器，將該服務器加入到服務器組中，將請求發送到該服務器。同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以下降複製的程度。

目標地址散列調度（Destination Hashing Scheduling）

目標地址散列調度（Destination Hashing Scheduling）算法也是針對目標IP地址的負載均衡，但它是一種靜態映射算法，經過一個散列（Hash）函數將一個目標IP地址映射到一臺服務器。目標地址散列調度算法先根據請求的目標IP地址，做爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，不然返回空。

源地址散列調度（Source Hashing Scheduling）

源地址散列調度（Source Hashing Scheduling）算法正好與目標地址散列調度算法相反，它根據請求的源IP地址，做爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，不然返回空。它採用的散列函數與目標地址散列調度算法的相同。它的算法流程與目標地址散列調度算法的基本類似，除了將請求的目標IP地址換成請求的源IP地址，因此這裏不一一敘述。在實際應用中，源地址散列調度和目標地址散列調度能夠結合使用在防火牆集羣中，它們能夠保證整個系統的惟一出入口。

=======================================================================

5、構建LVS三種模型集羣

1、構建LVS-NAT模型

NAT模型:

目標地址轉換全部客戶端的請求都被Director 根據訪問請求和算法被定向到後臺的Real Server 上。

數據包地址轉換過程：

S:CIP D:VIP------->Director------>S:CIP D:RIP------>Real Server------>

----->S:RIP D:CIP----->Director----->S:VIP D:CIP

Director 和Real Server 必須在同一個網段中；

RIP是通常來講是私有地址，僅集羣內部節點間通訊；

Director同時處理入站和出站鏈接，會響應全部的請求在客戶端和Real Server 之間，所承擔的負載較大；

Real server的網關要指向DIP，以響應客戶端請求；

Director 能夠映射網絡端口，即前端使用標準端口，後端可使用非標準端口；

Real server能夠是任意的操做系統；

Director很容易成爲系統瓶頸；

以web服務爲例

NAT模型實現：

須要三臺虛擬機，一臺Director須要有兩塊網卡，一塊網卡網橋模式，另外一塊網卡僅主機模式，兩臺Real server各一塊網卡都是僅主機模式；

=================================================================

Director操做：

# grep -i "ipvs" /boot/config-2.6.18-164.el5

查看Director主機內核是否支持ipvs

#yum install ipvsadm #安裝ipvs軟件包

#rpm -ql ipvsadm #查看安裝軟件生成那些文件

#man ipvsadm #查看幫助文檔

----------------------------------------------------------------------

ipvsadm

定義集羣服務，VIP，TCP，PORT

向集羣服務添加RS服務

-A 定義新的集羣服務

-E 修改或者編輯已有的集羣服務

-D 刪除某集羣服務

-C 清空全部規則

添加RS完整用法：

ipvsadm -A|E -t|u|f VIP:PORT [-s scheduler] [-p timeout] [-M netmask]

添加real server用法：

ipvsadm -A|E -t|u|f VIP:PORT -r real_server_address [-g|i|m ] [-w weight]

-g gateway DR模型(默認模型)

-i TUN

-m NAT

ipvsadm -R = ipvsadm-restore

ipvsadm -S = ipvsadm-save

ipvsadm -Z = ipvsadm-zero

ipvsadm --stats 顯示統計信息

ipvsadm --rate 顯示速度統計

ipvsadm -n 以數字number的形式顯示

ipvsadm -Lcn 查看鏈接相關屬性

----------------------------------------------------------------------

#配置Director兩塊網卡地址爲要求的地址，一塊爲外網地址172.16.33.1，一塊爲內網地址192.168.10.1，內網地址要和real server的地址在同一網段；

#配置real server 的兩快網卡地址分別爲192.168.10.10 和192.168.10.11

#把192.168.10.10 和192.168.10.11的網關指向Director 的內部地址(DIP僅主機)

# echo 1 > /proc/sys/net/ipv4/ip_forward 或者vim /etc/sysctl net.ipv4.ip_forward = 1#開啓路由轉發功能

#在兩個real server主機中添加網頁，理論上咱們應該添加相同的網頁來測試集羣性能，可是這裏咱們爲了區分效果，故意創建兩個不一樣的網頁測試！

# ipvsadm -A -t 192.168.10.12:80（VIP網橋）-s rr

# ipvsadm -a -t 192.168.10.12:80（VIP網橋）-r 192.168.10.10（RIP）-m

# ipvsadm -a -t 192.168.10.12:80（VIP網橋）-r 192.168.10.11（RIP）-m

# ipvsadm -L -n 查看當前的規則

# ipvsadm -L --rate 統計數據的速率

# ipvsadm -L --stats 統計數據總和

# 而後就能夠測試網頁了

# service ipvsadm save 保存規則

=================================================================

[root@station71 ~]# ipvsadm -L -n

IP Virtual Server version 1.2.1 (size=4096)

Prot LocalAddress:Port Scheduler Flags

-> RemoteAddress:Port Forward Weight ActiveConn InActConn

TCP 192.168.0.71:80 rr

-> 192.168.168.129:80 Masq 1 0 0

-> 192.168.168.128:80 Masq 1 0 0

[root@station71 ~]# ipvsadm -L --stats

IP Virtual Server version 1.2.1 (size=4096)

Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes

-> RemoteAddress:Port

TCP station71.example.com:http 5 310 300 130375 114034

-> 192.168.168.129:http 3 141 136 58410 53745

-> 192.168.168.128:http 2 169 164 71965 60289

[root@station71 ~]# ipvsadm -L --rate

IP Virtual Server version 1.2.1 (size=4096)

Prot LocalAddress:Port CPS InPPS OutPPS InBPS OutBPS

-> RemoteAddress:Port

TCP station71.example.com:http 0 0 0 0 0

-> 192.168.168.129:http 0 0 0 0 0

-> 192.168.168.128:http 0 0 0 0 0

2、構建LVS模型-DR模型：

直接路由客戶端請求通過Director，Real Server 直接回應客戶端

數據包地址轉換過程：

S:CIP D:VIP----->Director--->S:CIP D:RIP -----> Real Server---> S:VIP D:CIP

Real Server 上必須配置VIP 切須要隱藏起來，只有在響應客戶端請求時才使用VIP 做爲源地址，除此以外並不使用此VIP。

集羣節點和Director 必須在同一個網絡中；

RIP 不要求爲私有地址，可使用公網地址；

Director 僅處理全部進來的入站請求；

Real Server 不能以DIP 做爲網關，而是以公網上的某臺路由器做爲網關；

Director 不能再使用端口映射；

大多數操做系統能夠被用來做爲Real Server，只要有兩個功能：隔離arp廣播，能在同一塊網卡上配置多個ip地址，就能夠做爲real server；

LVS-DR 模式能夠處理比LVS-NAT 更多的請求。

實際生產環境中最經常使用的一種方式，優勢:

RIP 爲公網地址，管理員能夠遠程鏈接Real Server 來查看工做狀態；

一旦Director 宕機，能夠經過修改DNS 記錄將A 記錄指向RIP 繼續向外提供服務；

=======================================================================

PS:Director 分發到Real Server 的過程當中，數據包的源地址和目標地址都沒有發生改變，Director 僅僅是將目標mac 地

址轉換成某臺Real Server 的mac 地址，源mac 地址改成Director 內網網卡的mac 地址。

兩個技術難題

1 Real Server 要避免對客戶端發來的對VIP 的arp 地址解析請求；

解決方法

1) 修改內核的兩個參數：arp_announce, arp_ignore。

arp_announce ：通告，定義不一樣級別：當ARP 請求經過某個端口進來是否利用這個接口來回應。

定義在響應ARP 請求時所使用的模型：

0 - (default) Use any local address, configured on any interface.

利用本地的任何地址，無論配置在哪一個接口上去響應ARP 請求；

1 - Try to avoid local addresses that are not in the target's subnet for this interface.

當本臺主機上有多個ip地址時，迴應時僅迴應跟源ip地址在同一網段的地址迴應，避免使用另一個接口上的mac 地址去響應ARP 請求；

2 - Always use the best local address for this target.

儘量使用可以匹配到ARP 請求的最佳地址。

arp_ignore：當發過來後發現本身正是請求的地址是否響應；

0 - (default): reply for any local target IP address, configured on any interface

利用本地的任何地址，無論配置在哪一個接口上去響應ARP 請求；

1 - reply only if the target IP address is local address configured on the incoming interface.

哪一個接口上接受ARP 請求，就從哪一個端口上回應。

2 - reply for any local target IP address, configured on any interface ,,reply only if the target IP address is local address configured on the incoming interface and both with sender's ip address

3 - do not reply for local address

4 - 7 reserved

8 - do not reply for all local addresses

=======================================================================

DR模型

兩個Real server網卡配置爲橋接模式也須要配置公網IP，Director也須要配置公網ip，且須要跟RIP 在同一網段中；

Director配置：

# ifdown eth1 若是有兩塊網卡，先關閉一塊網卡

# ifconfig eth0:1 172.16.100.1 broadcast 172.16.100.1 netmask 255.255.255.255

爲Director配置別名

# route add -host 172.16.100.1 dev eth0:1 添加路由

# route -n 查看路由信息