一 前言
作為一名具備多年經驗的老運維，LVS 的名聲可謂如雷貫耳，一直都在尋找一個機會系統化地收集整理相關資料。時至今日，終於有時間詳細地學習和了解 LVS 相關的知識。
LVS 是linux virtual server的簡寫，意為：Linux虛擬服務器，這是一個由章文嵩博士在1998年5月發起的一個自由軟件項目。Linux 2.4 以後的內核版本，已經集成了 LVS 的各個功能模塊，我們可以直接使用LVS提供的各種功能。
二 認識 LVS
LVS集群的特點可以歸結如下：
- 功能
有實現三種IP負載均衡技術和八種連接調度算法的IPVS軟件。在IPVS內部實現上，採用了高效的Hash函數和垃圾回收機制，能正確處理所調度報文相關的ICMP消息（有些商品化的系統反而不能）。虛擬服務的設置數目沒有限制，每個虛擬服務有自己的服務器集。它支持持久的虛擬服務（如HTTP Cookie和HTTPS等需要該功能的支持），並提供詳盡的統計數據，如連接的處理速率和報文的流量等。針對大規模拒絕服務（Deny of Service）攻擊，實現了三種防衛策略。
有基於內容請求分發的應用層交換軟件KTCPVS，它也是在Linux內核中實現。有相關的集群管理軟件對資源進行監測，能及時將故障屏蔽，實現系統的高可用性。主、從調度器能週期性地進行狀態同步，從而實現更高的可用性。
- 適用性
後端服務器可運行任何支持TCP/IP的操作系統，包括Linux，各種Unix（如FreeBSD、Sun Solaris、HP Unix等），Mac/OS和Windows NT/2000等。
負載調度器能夠支持絕大多數的TCP和UDP協議：
無需對客戶機和服務器作任何修改，可適用大多數Internet服務。
- 性能
LVS服務器集群系統具有良好的伸縮性，可支持幾百萬個併發連接。配置100M網卡，採用VS/TUN或VS/DR調度技術，集群系統的吞吐量可高達1Gbits/s；如配置千兆網卡，則系統的最大吞吐量可接近10Gbits/s。
- 可靠性
LVS服務器集群軟件已經在很多大型的、關鍵性的站點得到很好的應用，所以它的可靠性在真實應用得到很好的證實。有很多調度器運行一年多，未作一次重啟動。
- 軟件許可證
LVS集群軟件是按GPL（GNU Public License）許可證發行的自由軟件，這意味著你可以得到軟件的源代碼，有權對其進行修改，但必須保證你的修改也是以GPL方式發行。
根據 LVS 工作模式的不同，LVS 工作模式分為三種：NAT 模式、TUN 模式、DR模式。
三 瞭解三種模式
3.1 Virtual Server via Network Address Translation（VS/NAT）
通過網絡地址轉換，調度器重寫請求報文的目標地址，根據預設的調度算法，將請求分派給後端的真實服務器；真實服務器的響應報文通過調度器時，報文的源地址被重寫，再返回給客戶，完成整個負載調度過程。架構參考下圖：
3.2 Virtual Server via IP Tunneling（VS/TUN）
採用NAT技術時，由於請求和響應報文都必須經過調度器地址重寫，當客戶請求越來越多時，調度器的處理能力將成為瓶頸。為了解決這個問題，調度器把請求報文通過IP隧道轉發至真實服務器，而真實服務器將響應直接返回給客戶，所以調度器只處理請求報文。由於一般網絡服務應答比請求報文大許多，採用 VS/TUN技術後，集群系統的最大吞吐量可以提高10倍。架構參考下圖：
3.3 Virtual Server via Direct Routing（VS/DR）
VS/DR通過改寫請求報文的MAC地址，將請求發送到真實服務器，而真實服務器將響應直接返回給客戶。同VS/TUN技術一樣，VS/DR技術可極大地 提高集群系統的伸縮性。這種方法沒有IP隧道的開銷，對集群中的真實服務器也沒有必須支持IP隧道協議的要求，但是要求調度器與真實服務器都有一塊網卡連在同一物理網段上。架構參考下圖：
四 每種模式的優缺點
4.1 NAT 模式
優點：
- 服務器可以運行任何支持TCP/IP的操作系統，它只需要一個IP地址配置在調度器上，服務器組可以用私有的IP地址。
- 採用內部 IP，服務節點隱蔽，安全性較好。
- 原理、配置簡單，容易理解。
缺點：
- 伸縮能力有限， 當服務器結點數目升到20時，調度器本身有可能成為系統的新瓶頸，因為在NAT中請求和響應報文都需要通過負載調度器。
4.2 TUN 模式
優點：
- 可以調度百臺以上的服務器（同等規模的服務器），而它不會成為系統的瓶頸。可以用來構建高性能的超級服務器。
- 原理、配置簡單，容易理解。
缺點：
- TUN技術對服務器有要求，即所有的服務器必須支持“IP Tunneling”或者“IP Encapsulation”協議。
- 節點暴露，安全性不如 NAT 模式。
4.3 DR 模式
優點：
- 可以調度百臺以上的服務器（同等規模的服務器），而它不會成為系統的瓶頸。可以用來構建高性能的超級服務器。
- 跟 TUN 模式相比，這種方法沒有IP隧道的開銷。
缺點：
- 要求負載調度器與實際服務器都有一塊網卡連在同一物理網段上，服務器網絡設備（或者設備別名）不作ARP響應，或者能將報文重定向（Redirect）到本地的Socket端口上。
- 節點暴露，安全性不如 NAT 模式。
整合一下，得到下表：
五 八種負載調度算法
針對不同的網絡服務需求和服務器配置，IPVS調度器實現瞭如下八種負載調度算法：
- 輪詢（Round Robin）
調度器通過"輪詢"調度算法將外部請求按順序輪流分配到集群中的真實服務器上，它均等地對待每一臺服務器，而不管服務器上實際的連接數和系統負載。
- 加權輪詢（Weighted Round Robin）
調度器通過"加權輪詢"調度算法根據真實服務器的不同處理能力來調度訪問請求。這樣可以保證處理能力強的服務器處理更多的訪問流量。調度器可以自動問詢真實服務器的負載情況，並動態地調整其權值。
- 最少鏈接（Least Connections）
調度器通過"最少連接"調度算法動態地將網絡請求調度到已建立的鏈接數最少的服務器上。如果集群系統的真實服務器具有相近的系統性能，採用"最小連接"調度算法可以較好地均衡負載。
- 加權最少鏈接（Weighted Least Connections）
在集群系統中的服務器性能差異較大的情況下，調度器採用"加權最少鏈接"調度算法優化負載均衡性能，具有較高權值的服務器將承受較大比例的活動連接負載。調度器可以自動問詢真實服務器的負載情況，並動態地調整其權值。
- 基於局部性的最少鏈接（Locality-Based Least Connections）
“基於局部性的最少鏈接” 調度算法是針對目標IP地址的負載均衡，目前主要用於 Cache 集群系統。該算法根據請求的目標IP地址找出該目標IP地址最近使用的服務器，若該服務器是可用的且沒有超載，將請求發送到該服務器；若服務器不存在，或者該服務器超載且有服務器處於一半的工作負載，則用"最少鏈接"的原則選出一個可用的服務器，將請求發送到該服務器。
- 帶複製的基於局部性最少鏈接（Locality-Based Least Connections with Replication）
"帶複製的基於局部性最少鏈接"調度算法也是針對目標IP地址的負載均衡，目前主要用於 Cache 集群系統。它與 LBLC 算法的不同之處是它要維護從一個 目標 IP 地址到一組服務器的映射，而 LBLC 算法維護從一個目標 IP 地址到一臺服務器的映射。該算法根據請求的目標 IP 地址找出該目標 IP 地址對應的服務器組，按"最小連接"原則從服務器組中選出一臺服務器，若服務器沒有超載，將請求發送到該服務器，若服務器超載；則按"最小連接"原則從這個集群中選出一臺服務器，將該服務器加入到服務器組中，將請求發送到該服務器。同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以降低複製的程度。
- 目標地址散列（Destination Hashing）
"目標地址散列"調度算法根據請求的目標IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。
- 源地址散列（Source Hashing）
"源地址散列"調度算法根據請求的源 IP 地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。
六 總結
本文大量引用了章博士原文，並在此基礎之上作了一些延申與總結，旨在學習、交流，也為將來自己查閱資料時節約時間。由於時間倉促，難免疏漏，望諸位多多指教。更佳的閱讀體驗，請轉至本人同名CSDN博客。
七 參考資料
7.1 Linux服務器集群系統（一）
7.2 Linux服務器集群系統（二）
7.3 Linux服務器集群系統（三）
7.4 Linux服務器集群系統（四）
