應用負載平衡之LVS(一)：基本概念和三種模式，負載平衡lvs

應用負載平衡之LVS(一)：基本概念和三種模式，負載平衡lvs

本文目錄：
1. LVS簡介
2. LVS-ipvs三種模式的工作原理
　2.1 VS/NAT模式
　2.2 VS/TUN模式
　2.3 VS/DR模式
　2.4 lvs-ipvs的三種模式比較
3. VS/TUN和VS/DR模式中的ARP問題
4. LVS負載平衡的調度演算法

網站架構中，負載平衡技術是實現網站架構伸縮性的主要手段之一。所謂"伸縮性"，是指可以不斷向叢集中添加新的伺服器來提升效能、緩解不斷增加的並發使用者訪問壓力。通俗地講，就是一頭牛拉不動時，就用兩頭、三頭、更多頭牛來拉。

負載平衡有好幾種方式：http URL重新導向、DNS的A記錄負載平衡、反向 Proxy負載平衡、IP負載平衡和鏈路層負載。本文所述為LVS，它的VS/NAT和VS/TUN模式是IP負載平衡的優秀代表，而它的VS/DR模式則是鏈路層負載平衡的優秀代表。

1.LVS簡介

LVS中文官方手冊：http://www.linuxvirtualserver.org/zh/index.html。這個手冊對於瞭解lvs的背景知識很有協助。

LVS英文官方手冊：http://www.linuxvirtualserver.org/Documents.html。這個手冊比較全面，對於瞭解和學習lvs的原理、配置很有協助。

LVS是章文嵩開發的一個國產開源負載平衡軟體。LVS最初是他在大學期間的玩具，隨著後來使用的使用者越來越多，LVS也越來越完善，最終整合到了Linux的核心中。有不少開源牛人都為LVS開發過協助工具輔助和輔助組件，最出名的就是Alexandre為LVS編寫的Keepalived，它最初專門用於監控LVS，後來加入了通過VRRP實現高可用的功能。

LVS的全稱是Linux virtual server，即Linux虛擬伺服器。之所以是虛擬伺服器，是因為LVS自身是個負載平衡器(director)，不直接處理請求，而是將請求轉寄至位於它後端真正的伺服器realserver上。

LVS是四層(傳輸層tcp/udp)、七層(應用程式層)的負載平衡工具，只不過福士一般都使用它的四層負載平衡功能ipvs，而七層的內容分發負載工具ktcpvs(kernel tcp virtual server)不怎麼完善，使用的人並不多。

ipvs是整合在核心中的架構，可以通過使用者空間的程式ipvsadm工具來管理，該工具可以定義一些規則來管理核心中的ipvs。就像iptables和netfilter的關係一樣。

2.LVS-ipvs三種模式的工作原理

首先要解釋的是LVS相關的幾種IP：

• VIP:virtual IP，LVS伺服器上接收外網資料報文的網卡IP地址。
• DIP:director，LVS伺服器上發送資料報文到realserver的網卡IP地址。
• RIP:realserver(常簡稱為RS)上的IP，即提供服務的伺服器IP。
• CIP:用戶端的IP。

2.1 VS/NAT模式

用戶端發送的請求到達Director後，Director根據負載平衡演算法改寫目標地址為後端某個RIP(web伺服器集區中主機之一)並轉寄給該後端主機，就像NAT一樣。當後端主機處理完請求後，後端主機將響應資料交給Director，並由director改寫源地址為VIP後傳輸給用戶端。大多數商品化的IP負載平衡硬體都是使用此方法，如Cisco的LocalDirector、F5的Big/IP。

2.2 VS/TUN模式

採用NAT技術時，由於請求和響應報文都必須經過調度器地址修正，當客戶請求越來越多時，調度器的處理能力將成為瓶頸。為瞭解決這個問題，調度器把請求報文通過IP隧道轉寄至真實伺服器，而真實伺服器將響應直接返回給客戶，所以調度器只處理請求報文。由於一般網路服務響應報文比請求報文大許多，採用VS/TUN技術後，調度器得到極大的解放，叢集系統的最大輸送量可以提高10倍。

2.3 VS/DR模式

VS/TUN模式下，調度器對資料包的處理是使用IP隧道技術進行二次封裝。VS/DR模式和VS/TUN模式很類似，只不過調度器對資料包的處理是改寫資料幀的目標MAC地址，通過鏈路層來負載平衡。

VS/DR通過改寫請求報文的目標MAC地址，將請求發送到真實伺服器，而真實伺服器將響應直接返回給客戶。同VS/TUN技術一樣，VS/DR技術可極大地提高叢集系統的伸縮性。這種方法沒有IP隧道的開銷，對叢集中的真實伺服器也沒有必須支援IP隧道協議的要求，但是要求調度器與真實伺服器都有一塊網卡連在同一物理網段上，以便使用MAC地址通訊轉寄資料包。

VS/DR模式的工作原理：

• (1)用戶端發送的請求被director接收後，director根據負載平衡演算法，改寫資料幀的目標MAC地址為後端某RS的MAC地址，並將該資料包轉寄給該RS(實際上是往整個區域網路發送，但只有該MAC地址的RS才不會丟棄)。
• (2)RS接收到資料包後，探索資料包的目標IP地址為VIP，而RS本身已經將VIP配置在了某個介面上，因此RS會接收下這個資料包並進行處理。
• (3)處理完畢後，RS直接將響應報文響應給用戶端。在返回給用戶端的時候，由於實用的是普通網卡介面，根據一般的路由條目，源IP地址將是該網卡介面上的地址，例如RIP。因此，要讓響應資料包的源IP為VIP，需要添加一條特殊的路由條目，明確指定該路由的源地址為VIP。

也就是說，用戶端請求發送到LB上，源和目標IP為CIP:VIP，LB上有VIP和DIP，重新改寫MAC地址後通過DIP發送給某個realserver，如RS1，此時源和目標IP還是CIP:VIP，但是目標MAC地址改寫為RIP1所在網卡的MAC地址"RS1_MAC"，RS1發現自身有VIP地址，所以收下此資料報文(所以在RS上必須配置VIP)。返回時，RS1根據路由表直接返回給用戶端，此時，源和目標IP是VIP:CIP。

2.4 lvs-ipvs的三種模式比較

三種模式的比較：

3.VS/TUN和VS/DR模式中的ARP問題

在【【VS/TUN和VS/DR的arp問題】】中非常詳細地分析了ARP、arp_ignore和arp_announce相關原理和設定方法。此處簡單說明為何需要設定arp抑制以及設定arp抑制的方法。

當一個目標IP地址為VIP的資料包進入Director前端的路由器時，路由器會向區域網路內發送ARP廣播，以找出VIP地址的MAC地址在哪台主機上。

echo 1 >/proc/sys/net/ipv4/conf/all/arp_ignoreecho 2 >/proc/sys/net/ipv4/conf/all/arp_announce

或者

sysctl -w net.ipv4.conf.all.arp_ignore=1sysctl -w net.ipv4.conf.all.arp_announce=2

或者將arp參數設定到核心參數設定檔中以讓其永久生效。

echo "net.ipv4.conf.all.arp_ignore=1" >>/etc/sysctl.confecho "net.ipv4.conf.all.arp_announce=2" >>/etc/sysctl.confsysctl -p

在網上幾乎所有文章還設定了lo介面上的arp參數：

echo 1 >/proc/sys/net/ipv4/conf/lo/arp_ignoreecho 2 >/proc/sys/net/ipv4/conf/lo/arp_announce

但這沒有任何意義，因為從lo介面不受arp參數的影響。

應該在配置VIP之前就設定arp參數，以防止配置VIP後、設定arp抑制之前被外界主機發現。

4.LVS負載平衡的調度演算法

LVS的調度演算法，詳細內容見官方手冊：http://www.linuxvirtualserver.org/zh/lvs4.html 。

IPVS在核心中的負載平衡調度是以串連為粒度的。在HTTP協議（非持久）中，每次從WEB伺服器上擷取資源都需要建立一個TCP串連，同一使用者的不同請求會被調度到不同的伺服器上，所以這種細粒度的調度在一定程度上可以避免單個使用者訪問的突發性引起伺服器間的負載不平衡。

LVS分為兩種調度方式：靜態調度和動態反饋調度。

靜態調度方式是指不管RS的繁忙程度，根據調度演算法計算後輪到誰就調度誰。例如兩台realserver，一開始雙方都在處理500個串連，下一個請求到來前，server1隻斷開了10個，而server2斷開了490個，但是此時輪到了server1，就會調度server1而不管繁忙的程度。

動態調度方式是指根據RS的繁忙程度反饋，計算出下一個串連應該調度誰(動態反饋負載平衡演算法考慮伺服器的即時負載和響應情況，不斷調整伺服器間處理請求的比例，來避免有些伺服器超載時依然收到大量請求，從而提高整個系統的吞吐率)。

在核心中的串連調度演算法上，IPVS已實現了以下八種調度演算法：預設的演算法為wlc。

• 靜態調度：
  • 輪叫調度（Round-Robin Scheduling,rr）
  • 加權輪叫調度（Weighted Round-Robin Scheduling,wrr），按照權重比例作為輪詢標準
  • 目標地址散列調度（Destination Hashing Scheduling,dh），目標地址雜湊，對於同一目標IP的請求總是發往同一伺服器
  • 源地址散列調度（Source Hashing Scheduling,sh），源地址雜湊，在一定時間內，只要是來自同一個用戶端的請求，就發送至同一個realserver
• 動態反饋調度：
  • 最小串連調度（Least-Connection Scheduling,lc），調度器需要記錄各個伺服器已建立串連的數目，當一個請求被調度到某伺服器，其串連數加1；當串連中止或逾時，其串連數減1。當各個伺服器的處理能力不同時，該演算法不理想。
  • 加權最小串連調度（Weighted Least-Connection Scheduling,wlc）
  • 基於本地的最少串連（Locality-Based Least Connections Scheduling,lblc），目前該演算法主要用於cache叢集系統。
  • 帶複製的基於局部性最少串連（Locality-Based Least Connections with Replication Scheduling,lblcr），目前主要用於Cache叢集系統。

 

回到Linux系列文章大綱：http://www.cnblogs.com/f-ck-need-u/p/7048359.html
回到網站架構系列文章大綱：http://www.cnblogs.com/f-ck-need-u/p/7576137.html
回到資料庫系列文章大綱：http://www.cnblogs.com/f-ck-need-u/p/7586194.html
轉載請註明出處：http://www.cnblogs.com/f-ck-need-u/p/8451982.html

註：若您覺得這篇文章還不錯請點擊右下角推薦，您的支援能激發作者更大的寫作熱情，非常感謝！