LVS（一）：基本概念和三種模式

網站架構中，負載均衡技術是實現網站架構伸縮性的主要手段之一。所謂"伸縮性"，是指能夠不斷向集羣中添加新的服務器來提高性能、緩解不斷增長的併發用戶訪問壓力。

負載均衡有好幾種方式：http URL重定向、DNS的A記錄負載均衡、反向代理負載均衡、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：

1. VIP：virtual IP，LVS服務器上接收外網數據包的網卡IP地址。
2. DIP：director IP，LVS服務器上轉發數據包到realserver的網卡IP地址。
3. RIP：realserver(常簡稱爲RS)上接收Director轉發數據包的IP，即提供服務的服務器IP。
4. CIP：客戶端的IP。

LVS的三種工做模式：經過網絡地址轉換(NAT)將一組服務器構成一個高性能的、高可用的虛擬服務器，是VS/NAT技術。在分析VS/NAT的缺點和網絡服務的非對稱性的基礎上，提出了經過IP隧道實現虛擬服務器的方法VS/TUN（Virtual Server via IP Tunneling），和經過直接路由實現虛擬服務器的方法VS/DR（Virtual Server via Direct Routing），它們能夠極大地提升系統的伸縮性。

2.1 VS/NAT模式

客戶端發送的請求到達Director後，Director根據負載均衡算法改寫目標地址爲後端某個RIP(web服務器池中主機之一)並轉發給該後端主機，就像NAT同樣。當後端主機處理完請求後，因爲RealServer和CIP不在同一網段，沒法直接通訊。RealServer將響應數據交給本身的網關，這時網關必須設置在director上。並由director改寫源地址爲VIP後傳輸給客戶端。大多數商品化的IP負載均衡硬件都是使用此方法，如Cisco的LocalDirector、F5的Big/IP。

這種模式下的優缺點：

1. RIP和DIP通常處於同一私有網段中。但並不是必須，只要它們能通訊便可。
2. 各RealServer的網關指向DIP，這樣能保證將響應數據交給Director。
3. VS/NAT模式的最大缺點是Director負責全部進出數據：不只處理客戶端發起的請求，還負責將響應傳輸給客戶端。而響應數據通常比請求數據大得多，調度器Director容易出現瓶頸。(也就是像7層負載的處理方式同樣，但卻沒有7層負載那麼"多功能")
4. 這種模式配置起來最簡單。

2.2 VS/TUN模式

採用NAT技術時，因爲請求和響應報文都必須通過調度器地址重寫，當客戶請求愈來愈多時，調度器的處理能力將成爲瓶頸。爲了解決這個問題，調度器把請求報文經過IP隧道轉發至真實服務器，而真實服務器將響應直接返回給客戶，因此調度器只處理請求報文。因爲通常網絡服務響應報文比請求報文大許多，採用VS/TUN技術後，調度器獲得極大的解放，集羣系統的最大吞吐量能夠提升10倍。

VS/TUN模式的工做原理：

• (1)IP隧道技術又稱爲IP封裝技術，它能夠將帶有源和目標IP地址的數據報文使用新的源和目標IP進行第二次封裝，這樣這個報文就能夠發送到一個指定的目標主機上；
• (2)VS/TUN模式下，調度器和後端服務器組之間使用IP隧道技術。當客戶端發送的請求(CIP-->VIP)被director接收後，director修改該報文，加上IP隧道兩端的IP地址做爲新的源和目標地址，並將請求轉發給後端被選中的一個目標；
• (3)當後端服務器接收到報文後，首先解封報文獲得原有的CIP-->VIP，該後端服務器發現自身的tun接口上配置了VIP，所以接受該數據包。
• (4)當請求處理完成後，結果將不會從新交給director，而是直接返回給客戶端。此時響應數據包的源IP爲VIP，目標IP爲CIP。

採用VS/TUN模式時的基本屬性和要求：

1. RealServer的RIP和director的DIP不用處於同一物理網絡中，且RIP必須能夠和公網通訊。也就是說集羣節點能夠跨互聯網實現。
2. realserver的tun接口上須要配置VIP地址，以便接收director轉發過來的數據包，以及做爲響應報文的源IP。
3. realserver必須設置arp抑制。
4. director給realserver時須要藉助隧道，隧道外層的IP頭部的源IP是DIP，目標IP是RIP。而realsever響應給客戶端的IP頭部是根據隧道內層的IP頭分析獲得的，源IP是VIP，目標IP是CIP。這樣客戶端就沒法區分這個VIP究竟是director的仍是服務器組中的。
5. director只處理入站請求，響應請求由realserver完成。

通常來講，VS/TUN模式會用來負載調度緩存服務器組，這些緩存服務器通常放置在不一樣網絡環境，能夠就近返回數據給客戶端。在請求對象不能在Cache服務器本地命中的狀況下，Cache服務器要向源服務器發請求，將結果取回，最後將結果返回給客戶。

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配置在了lo接口上，所以RS會接收下這個數據包並進行處理。
• (3)處理完畢後，RS直接將響應報文響應給客戶端。此時數據包源IP爲VIP，目標IP爲CIP。

也就是說，客戶端請求發送到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。但因爲流出接口爲RIP所在網卡接口，所以源MAC地址爲RIP所在接口的MAC地址。這一細節在考慮CIP、RIP不一樣網段時的配置時很重要。

採用VS/DR模式時的基本屬性和要求：

1. RealServer的RIP和director的DIP必須處於同一網段中，以便使用MAC地址進行通訊。
2. realserver上必須配置VIP地址，以便接收director轉發過來的數據包，以及做爲響應報文的源IP。
3. realserver必須設置arp抑制。
4. realsever響應給客戶端的數據包的源和目標IP爲VIP-->CIP。
5. director只處理入站請求，響應請求由realserver完成。

2.4 lvs-ipvs的三種模式比較

在性能上，VS/DR和VS/TUN遠高於VS/NAT，由於調度器只處於從客戶到服務器的半鏈接中，按照半鏈接的TCP有限狀態機進行狀態遷移，極大程度上減輕了調度器的壓力(真正創建TCP鏈接的是RS和Client)。VS/DR性能又稍高於VS/TUN，由於少了隧道的開銷。可是，VS/DR和VS/TUN的主要區別是VS/TUN能夠跨網絡實現後端服務器負載均衡(也能夠局域網內)，而VS/DR只能和director在局域網內進行負載均衡。

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

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

Director和各RS都配置了VIP。當路由器發送ARP廣播後，Director和RS都會收到這個廣播包，且都認爲這個廣播包找的就是本身，因而都回應給路由器，這樣路由器上的ARP緩存表中的條目VIP<-->vip_MAC就不斷被覆蓋直到最後一個迴應。這樣一來，路由器將把客戶端的數據包發送給最後一個迴應的主機，這臺主機的VIP多是Director上的，也多是某個RS上的。在必定時間內，路由器收到目標IP爲VIP的數據包都會發送給該主機。但路由器會定時發送ARP廣播包，這樣一來ARP緩存表中的VIP對應的MAC地址可能會換成另外一臺主機。

所以，必需要保證路由器只保存Director上VIP對應的MAC地址，即只容許Director纔對路由器的ARP廣播進行迴應。也就是說，全部RS上的VIP必須隱藏起來。

通常經過將Real Server上的VIP設置在lo接口的別名接口上(如lo:0)，並設置arp_ignore=1和arp_announce=2的方式來隱藏RS上的VIP。

在網上幾乎全部文章還設置了lo接口上的arp參數：

echo 1 >/proc/sys/net/ipv4/conf/lo/arp_ignore echo 1 >/proc/sys/net/ipv4/conf/all/arp_ignore echo 2 >/proc/sys/net/ipv4/conf/lo/arp_announce echo 2 >/proc/sys/net/ipv4/conf/all/arp_announceecho

但這沒有任何意義，由於從lo接口不受arp參數的影響。儘管對lo接口設置arp參數沒有意義，但爲了保證lo和普通網卡、隧道設置方法的統一性，以及將來的內核可能對此作出改變，本文以及網上的文章仍是對它進行了一樣的設置。

應該在配置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集羣系統。

文本參考https://www.cnblogs.com/f-ck-need-u/p/8451982.html並加入了我的的觀念及總結於其中。