【面試虐菜】—— LVS負載均衡

Load Balancer(負載均衡器)：

Load Balancer是整個集羣系統的前端，負責把客戶請求轉發到Real Server上。Load Balancer經過Ldirectord監測各Real Server的健康情況。在Real Server不可用時把它從羣中剔除，恢復時從新加入。
Backup是備份Load Balancer，當Load Balancer不可用時接替它，成爲實際的Load Balancer。

Server Array(服務器羣)：

Server Array是一組運行實際應用服務的機器，好比WEB, Mail, FTP, DNS, Media等等。在實際應用中，Load Balancer和Backup也能夠兼任Real Server的角色。如下的測試就是一臺服務器既擔任了LVSserver,同時也是realserver節點.

Shared Storage(共享存儲)：

Shared Storage爲全部Real Server提供共享存儲空間和一致的數據內容。
Director: 前端負載均衡器即運行LVS服務能夠針對web、ftp、cache、mms甚至mysql等服務作load balances。
RealServer: 後端須要負載均衡的服務器，能夠爲各種系統，Linux、Solaris、Aix、BSD、Windows均可，甚至Director自己也能夠做爲 RealServer使用.

LVS( Linux Virtual Server),Linux下的負載均衡器，支持LVS-NAT、 LVS-DR、LVS-TUNL三種不一樣的方式

　　nat用的不是不少，主要用的是DR、TUNL方式。

　　DR方式適合全部的RealServer同一網段下，即接在同一個交換機上.

　　TUNL方式就對於RealServer的位置能夠任意了，徹底能夠跨地域、空間，只要系統支持Tunnel就能夠,方便之後擴充的話直接Tunl方式便可

 

基礎知識介紹

 

一、LVS基礎及介紹

LVS是Linux Virtual Server的簡寫，意即Linux虛擬服務器，是一個虛擬的服務器集羣系統。本項目在1998年5月由章文嵩（目前就任於阿里）博士成立，是中國國內最先出現的自由軟件項目之一。
目前有三種IP負載均衡技術（VS/NAT、VS/TUN和VS/DR）；

十種調度算法（rrr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq）
【參考資料:】
1)官方中文參考資料: http://www.linuxvirtualserver.org/zh/index.html

2)LinuxTone 相關LVS技術檔彙總: http://bbs.linuxtone.org/thread-1191-1-1.html

二、 LVS 三種IP負載均衡技術對比

三種IP負載均衡技術的優缺點概括在下表中：

	VS/NAT	VS/TUN	VS/DR
Server	any	Tunneling	Non-arp device
server network	private	LAN/WAN	LAN
server number	low (10~20)	High (100)	High (100)
server gateway	load balancer	own router	Own router

【注】 以上三種方法所能支持最大服務器數目的估計是假設調度器使用100M網卡，調度器的硬件配置與後端服務器的硬件配置相同，並且是對通常Web服務。使用更 高的硬件配置（如千兆網卡和更快的處理器）做爲調度器，調度器所能調度的服務器數量會相應增長。當應用不一樣時，服務器的數目也會相應地改變。因此，以上數 據估計主要是爲三種方法的伸縮性進行量化比較。

三、LVS目前實現的幾種調度算法

IPVS在內核中的負載均衡調度是以鏈接爲粒度的。在HTTP協議（非持久）中，每一個對象從WEB服務器上獲取都須要創建一個TCP鏈接，同一用戶的不一樣請求會被調度到不一樣的服務器上，因此這種細粒度的調度在必定程度上能夠避免單個用戶訪問的突發性引發服務器間的負載不平衡。
在內核中的鏈接調度算法上，IPVS已實現瞭如下十種調度算法：
* 輪叫調度（Round-Robin Scheduling）
* 加權輪叫調度（Weighted Round-Robin Scheduling）
* 最小鏈接調度（Least-Connection Scheduling）
* 加權最小鏈接調度（Weighted Least-Connection Scheduling）
* 基於局部性的最少連接（Locality-Based Least Connections Scheduling）
* 帶複製的基於局部性最少連接（Locality-Based Least Connections with Replication Scheduling）
* 目標地址散列調度（Destination Hashing Scheduling）
* 源地址散列調度（Source Hashing Scheduling）
* 最短預期延時調度（Shortest Expected Delay Scheduling）
* 不排隊調度（Never Queue Scheduling）
對應: rr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq,


Ldirecotrd配置選項及ipvsadm使用參數.

ldirectord配置選項	ipvsadm使用的參數	ipvsadm -L的輸出	LVS轉發方法
gate	-g	Route	LVS-DR
ipip	-i	Tunnel	LVS-TUN
masq	-m	Masq	LVS-NAT

四、集羣架構時咱們應該採用什麼樣的調度算法?

在通常的網絡服務（如HTTP和Mail Service等）調度中，我會使用加權最小鏈接調度wlc或者加權輪叫調度wrr算法。
基於局部性的最少連接LBLC和帶複製的基於局部性最少連接LBLCR主要適用於Web Cache集羣。
目標地址散列調度和源地址散列調度是用靜態映射方法，可能主要適合防火牆調度。
最短預期延時調度SED和不排隊調度NQ主要是對處理時間相對比較長的網絡服務。
其實，它們的適用範圍不限於這些。我想最好參考內核中的鏈接調度算法的實現原理，看看那種調度方法適合你的應用。

五、LVS的ARP問題
2.4.x kernels:
Hidden Patch
arptable
iptables

2.6.x kernels: （關閉arp查詢響應請求）
net.ipv4.conf.eth0.arp_ignore = 1
net.ipv4.conf.eth0.arp_announce = 2
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
arping tools

 

2、基礎知識及一些要點

一、InActConn並不表明錯誤鏈接，它是指不活躍鏈接(Inactive Connections)，
咱們將處於TCP ESTABLISH狀態之外的鏈接都稱爲不活躍鏈接，例如處於SYN_RECV狀態的鏈接，處於TIME_WAIT狀態的鏈接等。

二、用四個參數來關閉arp查詢響應請求：
echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

三、ipvsadm -L -n --stats
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
鏈接數 輸入包 輸出包 輸入流量 輸出流量

四、注意事項:
1）在LVS方案中，虛擬ip地址與普通網絡接口大大不一樣，這點須要特別注意。
虛擬ip地址的廣播地址是它自己，子網掩碼是255.255.255.255。 爲何要這樣呢？由於有若干機器要使用同一個ip地址，
用自己作廣播地址和把子網掩碼設成4個255就不會形成ip地址衝突了,不然lvs將不能正常轉發訪問請求。

2）假如兩臺VS之間使用的互備關係，那麼當一臺VS接管LVS服務時，可能會網絡不通，這時由於路由器的MAC緩存表裏關於vip這個地址的MAC地 址仍是被替換的VS的MAC，有兩種解決方法，一種是修改新VS的MAC地址，另外一種是使用send_arp 命令（piranha軟件包裏帶的一個小工具） 格式以下：
send_arp:
send_arp [-i dev] src_ip_addr src_hw_addr targ_ip_addr tar_hw_addr
這個命令不必定非要在VS上執行，只+要在同一VLAN便可。
/sbin/arping -f -q -c 5 -w 5 -I eth0 -s $WEB_VIP -U $GW

5.Virtual Server via Direct Routing（VS/DR）
VS/DR經過改寫請求報文的MAC地址，將請求發送到真實服務器，而真實服務器將響應直接返回給客戶。同VS/TUN技術同樣，VS/DR技術可極大地提升集羣系統的伸縮性。這種方法沒有IP隧道的開銷，對集羣中的真實服務器也沒有必須支持IP隧道協議的要求，可是要求調度器與真實服務器都有一塊網卡連在同一物理網段上。

6. LVS 經驗:
1). LVS調度的最小單位是「鏈接」。
2). 當apache的KeepAlive被設置成Off時，「鏈接」才能被較均衡的調度。
3). 在不指定-p參數時，LVS才真正以「鏈接」爲單位按「權值」調度流量。
4). 在指定了-p參數時，則一個client在必定時間內，將會被調度到同一臺RS。
5). 能夠經過」ipvsadm ?set tcp tcpfin udp」來調整TCP和UDP的超時，讓鏈接淘汰得快一些。
6). 在NAT模式時，RS的PORT參數纔有意義。
7). DR和TUN模式時，InActConn 是沒有意義的(Thus the count in the InActConn column for LVS-DR, LVS-Tun is
inferred rather than real.)
/sbin/arping -f -q -c 5 -w 5 -I eth0 -s $WEB_VIP -U $GW

3、LVS 性能調優

Least services in System or Compile kernel.

Performace Tuning base LVS:
LVS self tuning( ipvsadm Timeout (tcp tcpfin udp)).
ipvsadm -Ln --timeout
Timeout (tcp tcpfin udp): 900 120 300
ipvsadm --set tcp tcpfin udp


Improving TCP/IP performance
net.ipv4.tcp_tw_recyle=1
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_max_syn_backlog=8192
net.ipv4.tcp_keepalive_time=1800
net.ipv4.tcp_fin_timeout=30
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_wmem=4096 65536 16777216
net.core.netdev_max_backlog=3000

 

1 經過NAT實現虛擬服務器（VS/NAT）

 

　　NAT的工做原理是報文頭（目標地址、源地址和端口等）被正確改寫後，客戶相信它們鏈接一個IP地址，而不一樣IP地址的服務器組也認爲它們是與客戶直接相連的。

　　能夠用NAT方法將不一樣IP地址的並行網絡服務變成在一個IP地址上的一個虛擬服務。

　　客戶經過Virtual IP Address（虛擬服務的IP地址）訪問網絡服務時，請求報文到達調度器，調度器根據鏈接調度算法從一組真實服務器中選出一臺服務器，將報文的目標地址Virtual IP Address改寫成選定服務器的地址，報文的目標端口改寫成選定服務器的相應端口，最後將修改後的報文發送給選出的服務器。同時，調度器在鏈接Hash表中記錄這個鏈接，當這個鏈接的下一個報文到達時，從鏈接Hash表中能夠獲得原選定服務器的地址和端口，進行一樣的改寫操做，並將報文傳給原選定的服務器。當來自真實服務器的響應報文通過調度器時，調度器將報文的源地址和源端口改成Virtual IP Address和相應的端口，再把報文發給用戶。

　　在鏈接上引入一個狀態機，不一樣的報文會使得鏈接處於不一樣的狀態，不一樣的狀態有不一樣的超時值。在TCP鏈接中，根據標準的TCP有限狀態機進行狀態遷移；在UDP中，咱們只設置一個UDP狀態。不一樣狀態的超時值是能夠設置的，在缺省狀況下，SYN狀態的超時爲1分鐘，ESTABLISHED狀態的超時爲15分鐘，FIN狀態的超時爲1分鐘；UDP狀態的超時爲5分鐘。當鏈接終止或超時，調度器將這個鏈接從鏈接Hash表中刪除。

 

2 經過IP隧道實現虛擬服務器（VS/TUN）

 

　　大多數Internet服務都有這樣的特色：請求報文較短而響應報文每每包含大量的數據。若是能將請求和響應分開處理，即在負載調度器中只負責調度請求而響應直接返回給客戶，將極大地提升整個集羣系統的吞吐量。

　　調度器根據各個服務器的負載狀況，動態地選擇一臺服務器，將請求報文封裝在另外一個IP報文中，再將封裝後的IP報文轉發給選出的服務器；服務器收到報文後，先將報文解封得到原來目標地址爲VIP的報文，服務器發現VIP地址被配置在本地的IP隧道設備上，因此就處理這個請求，而後根據路由表將響應報文直接返回給客戶。

　　響應報文根據服務器的路由表直接返回給客戶，而不通過負載調度器，因此負載調度器只處於從客戶到服務器的半鏈接中

 

3 經過直接路由實現虛擬服務器（VS/DR）

 

　　VS/DR利用大多數Internet服務的非對稱特色，負載調度器中只負責調度請求，而服務器直接將響應返回給客戶，能夠極大地提升整個集羣系統的吞吐量

　　在VS/DR中，調度器根據各個服務器的負載狀況，動態地選擇一臺服務器，不修改也不封裝IP報文，而是將數據幀的MAC地址改成選出服務器的MAC地址，再將修改後的數據幀在與服務器組的局域網上發送。由於數據幀的MAC地址是選出的服務器，因此服務器確定能夠收到這個數據幀，從中能夠得到該IP報文。當服務器發現報文的目標地址VIP是在本地的網絡設備上，服務器處理這個報文，而後根據路由表將響應報文直接返回給客戶。

	VS/NAT	VS/TUN	VS/DR
Server	any	Tuneling	Non-arp device
server number	low10-20	high100	high100
server gateway	loadbalancer	own router	own router
server network	private	lan/wan	lan

 

---

 

NAT 

    當服務器數目變多時，調度器成爲瓶頸

IP Tuneling 

    術對服務器有要求，即全部的服務器必須支持「IP Tunneling」者「IPEncapsulation 」協議

DR 

    跟VS/TUN相比，這種方法沒有IP隧道的開銷，可是要求負載調度器與實際服務器都有一塊網卡連在同一物理網段上，服務器網絡設備（或者設備別名）不做ARP響應，或者能將報文重定向（Redirect）到本地的Socket端口上。