LVS負載均衡技術
之前我們講述了可伸縮網路服務的幾種結構，它們都需要一個前端排程器。在排程器的實現技術中，IP 負載均衡技術是效率最高的。下面將描述三種 IP 負載均衡技術VS/NAT、VS/DR和VS/TUN的工作原理，以及它們的優缺點。
- VS/NAT
- 通過網路地址轉換實現虛擬伺服器的方法，將一組伺服器構成一個高效能的、高可用的虛擬伺服器
- 大多數商品化的 IP 負載均衡排程器產品都是使用此方法，如
Cisco的LocalDirector、F5的Big/IP
- VS/DR：
- 通過直接路由實現虛擬伺服器的方法，將一組伺服器構成一個高效能的、高可用的虛擬伺服器
- VS/TUN：
- 通過IP 隧道實現虛擬伺服器的方法，將一組伺服器構成一個高效能的、高可用的虛擬伺服器
1. 實現框架
系統實現的若干問題可以檢視官方文件的說明。
在Linux核心2.0和核心2.2的版本中，通過修改了TCP/IP協議棧，在IP層擷取和改寫/轉發IP報文，實現了三種IP 負載均衡技術，並提供了一個ipvsadm程式進行虛擬伺服器的配置和管理。而在Linux核心2.4和2.6中，把它實現為NetFilter的一個模組，很多程式碼作了改寫和進一步優化，已經較穩定。
系統的主要功能模組如上圖所示，“VS Schedule & Control Module”是虛擬伺服器的主控模組，它掛接在IP報文遍歷的LOCAL_IN
IP_FORWARD鏈兩處，用於擷取/改寫 IP 報文；“VS Rules Table”用於存放虛擬伺服器的規則，“Connections Hash Table”表是用於記錄當前連線的Hash表；“Stale Connection Collector”模組用於回收已經過時的連線；“Statistics Data”表記錄IPVS的統計資訊。使用者空間的ipvsadm管理程式通過setsockopt()函式將虛擬伺服器的規則寫入“VS Rules Table”表中，通過/proc檔案系統把“VS Rules Table”表中的規則讀出。
當一個IP報文到達時，若報文的目標地址是本地的IP地址，IP
LOCAL_IN鏈上，否則轉到IP_FORWARD鏈上。IPVS模組主要掛接在LOCAL_IN鏈和IP_FORWARD鏈兩處。當一個目標地址為Virtual IP Address的報文到達時，該報文會被掛接在LOCAL_IN鏈上的IPVS程式捕獲，若該報文屬於在連線Hash表中一個已建立的連線，則根據連線的資訊將該報文傳送到目標伺服器，否則該報文為SYN時，根據連線排程演算法從一組真實伺服器中選出一臺伺服器，根據 IP 負載排程設定的規則將報文傳送給選出的伺服器，並在連線 Hash 表中記錄這個連線。掛接在IP_FORWARD鏈上的IPVS程式是改寫VS/NAT中伺服器響應報文的地址。
連線的Hash 表可以容納幾百萬個併發連線，在Linux核心2.2和核心2.4的IP虛擬伺服器版本中每個連線只佔用128Bytes有效記憶體，例如一個有256M可用記憶體的排程器就可排程兩百萬個併發連線。連線Hash表的桶個數可以由使用者根據實際應用來設定，來降低Hash的衝突率。
在每個連線的結構中有連線的報文傳送方式、狀態和超時等。報文傳送方式有VS/NAT、VS/TUN、VS/DR和本地結點，報文會被以連線中設定的方式傳送到目標伺服器。這意味著在一個伺服器叢集中，我們可以用不同的方式來排程不同的伺服器。連線的狀態和超時用於記錄連線當前所在的狀態，如SYN_REC、ESTABLISHED和FIN_WAIT等，不同的狀態有不同的超時值。
IP 虛擬伺服器具有以下特點：
- 三種 IP 負載均衡技術，在一個伺服器叢集中，不同的伺服器可以使用不同的
IP負載均衡技術。 - 可裝卸連線排程模組，共有五種連線排程演算法。
- 高效的
Hash函式 - 高效的垃圾回收機制
- 虛擬服務的數目沒有限制，每個虛擬服務有自己的伺服器集。
- 支援持久的虛擬服務
- 正確的
ICMP處理 - 擁有本地結點功能
- 提供系統使用的統計資料
- 針對大規模
DoS攻擊的三種防衛策略
通過IP虛擬伺服器軟體和叢集管理工具可以將一組伺服器組成一個高效能、高可用的網路服務。該系統具有良好的伸縮性，支援幾百萬個併發連線。無需對客戶機和伺服器作任何修改，可適用任何Internet站點。該系統已經在很多大型的站點得到很好的應用。
2. VS/NAT
由於IPv4中IP地址空間的日益緊張和安全方面的原因，很多網路使用保留IP地址專門為內部網路使用，如10.0.0.0/255.0.0.0、172.16.0.0/255.128.0.0和192.168.0.0/255.255.0.0。當內部網路中的主機要訪問Internet或被Internet訪問時，就需要採用網路地址轉換(NAT)，將內部地址轉化為Internets上可用的外部地址。NAT的工作原理是報文頭(目標地址、源地址和埠等)被正確改寫後，客戶相信它們連線一個IP地址，而不同IP地址的伺服器組也認為它們是與客戶直接相連的。由此，可以用NAT方法將不同IP地址的並行網路服務變成在一個IP地址上的一個虛擬服務。
VS/NAT的體系結構如下圖所示。在一組伺服器前有一個排程器，它們是通過Switch/HUB相連線的。這些伺服器提供相同的網路服務、相同的內容，即不管請求被髮送到哪一臺伺服器，執行結果是一樣的。服務的內容可以複製到每臺伺服器的本地硬碟上，可以通過網路檔案系統(如NFS檔案系統)共享，也可以通過一個分散式檔案系統來提供。
客戶通過虛擬服務的 IP 地址(Virtual IP Address)訪問網路服務時，請求報文到達排程器，排程器根據連線排程演算法從一組真實伺服器中選出一臺伺服器，將報文的目標地址Virtual IP Address改寫成選定伺服器的地址，報文的目標埠改寫成選定伺服器的相應埠，最後將修改後的報文傳送給選出的伺服器。同時，排程器在連線Hash表中記錄這個連線，當這個連線的下一個報文到達時，從連線Hash表中可以得到原選定伺服器的地址和埠，進行同樣的改寫操作，並將報文傳給原選定的伺服器。當來自真實伺服器的響應報文經過排程器時，排程器將報文的源地址和源埠改為Virtual IP Address和相應的埠，再把報文發給使用者。我們在連線上引入一個狀態機，不同的報文會使得連線處於不同的狀態，不同的狀態有不同的超時值。在TCP連線中，根據標準的TCP有限狀態機進行狀態遷移；在UDP中，我們只設置一個UDP狀態。不同狀態的超時值是可以設定的，在預設情況下，SYN狀態的超時為1分鐘，ESTABLISHED狀態的超時為15分鐘，FIN狀態的超時為1分鐘；UDP狀態的超時為5分鐘。當連線終止或超時，排程器將這個連線從連線Hash表中刪除。
這樣，客戶所看到的只是在Virtual IP Address上提供的服務，而伺服器叢集的結構對使用者是透明的。對改寫後的報文，應用增量調整Checksum的演算法調整TCP Checksum的值，避免了掃描整個報文來計算Checksum的開銷。
在一些網路服務中，它們將 IP 地址或者埠號在報文的資料中傳送，若我們只對報文頭的 IP 地址和埠號作轉換，這樣就會出現不一致性，服務會中斷。所以，針對這些服務，需要編寫相應的應用模組來轉換報文資料中的 IP 地址或者埠號。我們所知道有這個問題的網路服務有FTP、IRC、RSTP、PPTP等。
下面，舉個例子來進一步說明VS/NAT，如下圖所示：
VS/NAT的配置如下表所示，所有到IP地址為202.103.106.5和埠為80的流量都被負載均衡地排程的真實伺服器172.16.0.2:80和172.16.0.3:8000上。目標地址為202.103.106.5:21的報文被轉移到172.16.0.3:21上。而到其他埠的報文將被拒絕。
從以下的例子中，我們可以更詳細地瞭解報文改寫的流程。
訪問Web服務的報文可能有以下的源地址和目標地址：
排程器從排程列表中選出一臺伺服器，例如是172.16.0.3:8000。該報文會被改寫為如下地址，並將它傳送給選出的伺服器。
從伺服器返回到排程器的響應報文如下：
LVS服務之IP負載均衡技術響應報文的源地址會被改寫為虛擬服務的地址，再將報文傳送給客戶：
LVS服務之IP負載均衡技術這樣，客戶認為是從202.103.106.5:80服務得到正確的響應，而不會知道該請求是伺服器172.16.0.2還是伺服器172.16.0.3處理的。
3. VS/TUN
在VS/NAT的集群系統中，請求和響應的資料報文都需要通過負載排程器，當真實伺服器的數目在10臺和20臺之間時，負載排程器將成為整個集群系統的新瓶頸。大多數Internet服務都有這樣的特點：請求報文較短而響應報文往往包含大量的資料。如果能將請求和響應分開處理，即在負載排程器中只負責排程請求而響應直接返回給客戶，將極大地提高整個集群系統的吞吐量。
IP 隧道(IP tunneling)是將一個IP報文封裝在另一個IP報文的技術，這可以使得目標為一個IP地址的資料報文能被封裝和轉發到另一個IP地址。IP隧道技術亦稱為IP封裝技術。IP隧道主要用於移動主機和虛擬私有網路，在其中隧道都是靜態建立的，隧道一端有一個IP地址，另一端也有唯一的IP地址。
我們利用IP隧道技術將請求報文封裝轉發給後端伺服器，響應報文能從後端伺服器直接返回給客戶。但在這裡，後端伺服器有一組而非一個，所以我們不可能靜態地建立一一對應的隧道，而是動態地選擇一臺伺服器，將請求報文封裝和轉發給選出的伺服器。這樣，我們可以利用IP隧道的原理將一組伺服器上的網路服務組成在一個IP地址上的虛擬網路服務。VS/TUN的體系結構如下圖所示，各個伺服器將VIP地址配置在自己的IP隧道裝置上。
VS/TUN的工作流程如下圖所示：它的連線排程和管理與VS/NAT中的一樣，只是它的報文轉發方法不同。排程器根據各個伺服器的負載情況，動態地選擇一臺伺服器，將請求報文封裝在另一個IP報文中，再將封裝後的IP報文轉發給選出的伺服器；伺服器收到報文後，先將報文解封獲得原來目標地址為VIP的報文，伺服器發現VIP地址被配置在本地的IP隧道裝置上，所以就處理這個請求，然後根據路由表將響應報文直接返回給客戶。
在這裡，請求報文的目標地址為VIP，響應報文的源地址也為VIP，所以響應報文不需要作任何修改，可以直接返回給客戶，客戶認為得到正常的服務，而不會知道是哪一臺伺服器處理的。
在VS/TUN中，響應報文根據伺服器的路由表直接返回給客戶，而不經過負載排程器，所以負載排程器只處於從客戶到伺服器的半連線中，VS/TUN的TCP狀態遷移與VS/NAT的不同。我們給出半連線的TCP有限狀態機，如下圖所示，圈表示狀態，箭頭表示狀態間的轉換，箭頭上的標識表示在當前狀態上收到該標識的輸入，遷移到下一個狀態。VS/TUN的TCP狀態遷移是按照半連線的TCP有限狀態機進行的。
即在負載排程器中只負責排程請求，而響應由真實伺服器直接返回給客戶。
4. VS/DR
跟VS/TUN方法相同，VS/DR利用大多數Internet服務的非對稱特點，負載排程器中只負責排程請求，而伺服器直接將響應返回給客戶，可以極大地提高整個集群系統的吞吐量。該方法與IBM的NetDispatcher產品中使用的方法類似，但IBM的NetDispatcher是非常昂貴的商品化產品。
VS/DR的體系結構如下圖所示：排程器和伺服器組都必須在物理上有一個網絡卡通過不分段的區域網相連，即通過交換機或者高速的HUB相連，中間沒有隔有路由器。VIP地址為排程器和伺服器組共享，排程器配置的VIP地址是對外可見的，用於接收虛擬服務的請求報文；所有的伺服器把VIP地址配置在各自的Non-ARP網路裝置上，它對外面是不可見的，只是用於處理目標地址為VIP的網路請求。
VS/DR的工作流程如下圖所示：它的連線排程和管理與VS/NAT和VS/TUN中的一樣，它的報文轉發方法又有不同，將報文直接路由給目標伺服器。在VS/DR中，排程器根據各個伺服器的負載情況，動態地選擇一臺伺服器，不修改也不封裝IP報文，而是將資料幀的MAC地址改為選出伺服器的MAC地址，再將修改後的資料幀在與伺服器組的區域網上傳送。因為資料幀的MAC地址是選出的伺服器，所以伺服器肯定可以收到這個資料幀，從中可以獲得該 IP 報文。當伺服器發現報文的目標地址VIP是在本地的網路裝置上，伺服器處理這個報文，然後根據路由表將響應報文直接返回給客戶。
在VS/DR中，請求報文的目標地址為VIP，響應報文的源地址也為VIP，所以響應報文不需要作任何修改，可以直接返回給客戶，客戶認為得到正常的服務，而不會知道是哪一臺伺服器處理的。
VS/DR負載排程器也只處於從客戶到伺服器的半連線中，按照半連線的 TCP 有限狀態機進行狀態遷移。
5. 優缺點比較
三種 IP 負載均衡技術的優缺點歸納在下表中：
LVS服務之IP負載均衡技術注：以上三種方法所能支援最大伺服器數目的估計是假設排程器使用 100M 網絡卡，排程器的硬體配置與後端伺服器的硬體配置相同，而且是對一般 Web 服務。使用更高的硬體配置（如千兆網絡卡和更快的處理器）作為排程器，排程器所能排程的伺服器數量會相應增加。當應用不同時，伺服器的數目也會相應地改變。所以，以上資料估計主要是為三種方法的伸縮性進行量化比較。