Author : 岑文初
Email: wenchu.cenwc@alibaba-inc.com
Blog: http://blog.csdn.net/cenwenchu79
Date: 2009-5-26
目錄
需求轉而學習
“軟”負載均衡
LVS （Linux Virtual Server）
Virtual Server三種模式介紹
Virtual Server三種模式的比較
Virtual Server三種模式實踐
三種模式下的簡單壓力測試
HA-Proxy
HA-Proxy安裝和使用
HA-Proxy的壓力測試結果
“軟”負載學習心得
需求轉而學習
很多時候不少做開發的同學都認為技術更新的快，新技術、新概念層出不窮，大家樂此不疲的去跟隨著所謂的“技術趨勢”走在風頭浪尖上，但其實往往忘記了一個最重要的問題“滿足客戶需求”。其實技術就是為滿足需求服務的，用最小的代價來滿足用戶的需求，以最簡單高效的方式來達到目標，就是每個開發者應該追求的。（不要因為自己的架構很簡單就臉紅拿不出手，只要你在滿足用戶當前需求的基礎上對未來有所考慮，那么化繁為簡就是一種能力的表現）
SIP（服務集成平臺）5.7版本中對于未來多個服務提供商，多種類型的服務，在每日幾億的調用壓力下，需要找到一個解決方案：可以分流不同服務提供商的服務，分流不同類型的服務，服務隔離化來減少服務相互之間影響以及服務提供商之間的影響。
當前SIP的前端是通過硬件F5作負載均衡，因此是無狀態無差別的服務負載，這也使得無法區分不同的服務提供商的服務請求和不同類型的服務請求，導致服務提供商之間的服務會產生相互影響（旺旺即時通信類API在峰值占用了大部分的服務處理資源，淘寶寶貝上傳類API占用了大量的帶寬）。近期還有更大的兩類API將會接入，因此尋找一個服務可分流的方案勢在必行。（當然過去也考慮通過三級域名配置在負載均衡上來解決這些問題，但是這樣首先對于開發者來說不透明，其次也是一種比較僵化的設計方案，擴展和維護也有一定的難度）
在過去也嘗試過Apache等Web容器自己的一些load balance特性，當然效果不是很好，和硬件基本無法比擬，而一些專有的“軟”負載均衡方案和開源項目也沒有深入的去了解，因此借著這次機會，好好深入的挖一挖“軟”負載均衡。
“軟”負載均衡
作為互聯網應用，隨時都需要做好用戶量突然增大，訪問量突然上升的準備。今年熱門的詞匯“云”我就不多說了，這里就簡單說說服務器的橫向擴展。其實和DB，文件系統等一樣，當資源成為瓶頸的時候，就需要考慮如何通過擴展或者提升資源能力來滿足用戶的需求，這就是我們常說的橫向擴展和縱向擴展。（對于橫向擴展和縱向擴展的優劣大家應該都很清楚了，這里也不做贅述）橫向擴展中就會要求使用負載均衡的能力，如何根據資源能力不同以及資源在運行期負荷動態變化將負載合理分配是判斷負載均衡優劣的標準。
軟件負載均衡一般通過兩種方式來實現：基于操作系統的軟負載實現和基于第三方應用的軟負載實現。LVS就是基于Linux操作系統實現的一種軟負載，HA Proxy就是基于第三應用實現的軟負載。（后面會詳細介紹這兩種方式的使用）
最早期也是最原始的軟負載均衡：“Round Robin DNS”，通過輪詢方式在DNS綁定多個IP的情況下，將用戶對于同一個域名的請求分配到后端不同的服務節點。這種方案的優點：配置簡單，負載分配效率高。缺點：無法知曉后端服務節點服務情況（是否已經停止服務），無法保證在一個Session中多次請求由一個服務節點服務，每一個節點都要求有一個外網IP。
另一種較為常見的就是基于分發器的Load balance。服務使用者通過向分發器發起請求獲得服務，分發器將請求分發給后端實際服務處理的節點，給客戶提供服務，最常說的反向代理模式就是典型的分發器Load Balance。這類負載均衡處理可以基于應用級轉發，也可以基于IP級別轉發，當然基于應用轉發效率和損耗比較大，同時分發器本身也會成為瓶頸。
LVS （Linux Virtual Server）
LVS是在Linux操作系統基礎上建立虛擬服務器，實現服務節點之間的負載均衡。LVS主要是處理OSI模型中的4層消息包，根據一定的規則將請求直接轉發到后端的服務處理節點，有較高轉發效率。
Virtual Server是Load Balancer和一組服務器的邏輯組合統稱，使用服務者只需要與Virtual Server進行交互就可以獲得高效的服務。真實服務器和Load Balancer通過高速ＬＡＮ進行交互。Load Balancer能夠將請求分發到不同的服務端，在一個虛擬IP下并行處理多個請求。
Virtual Server三種模式介紹
Virtual Server有三種基于IP級別的負載均衡實現方式：IP address translation（NAT）、Direct routing、IP Tunneling。
NAT(Network address translation)：由于IPV4的某些缺陷和安全原因，某些網段例如（10.0.0.0/255.0.0.0, 172.16.0.0/255.240.0.0 and 192.168.0.0/255.255.0.0）不能被用于互聯網，因此常常被用作內部局域網，通過網絡地址翻譯的方式可以讓這些網段的服務器訪問互聯網或者被互聯網訪問。網絡地址翻譯主要作用就是將一組ip地址映射到其他的一組ip地址，當映射比例為1:1的時候通常稱作靜態映射，而當映射地址為M:N(M>N)的時候（M為被映射地址數量，通常是內部ip），則成為動態映射。而對于Virtual Server的NAT模式來說，就是利用了NAT的特性，將內部的一組服務器通過映射到一個虛擬的IP，然后以一個外網虛擬服務節點的身份對外提供服務。
上圖是一個實際的NAT范例，對外的服務IP為202.103.106.5，內部建立了虛擬IP為172.16.0.1，然后將內部其他兩臺實際服務的服務器172.16.0.2，172.16.0.3映射到172.16.0.1這個虛擬IP。客戶端向202.103.106.5發起請求服務，Load Balancer查看請求數據包，如果是請求目標地址是注冊的虛擬IP及監聽端口的時候，那么通過NAT按照一定算法選擇某一臺實體服務器，再重寫報文目標地址，轉發請求到實際的目標服務器，當目標服務器處理完畢以后，將處理結果返回給Load Balancer，由Load Balancer修改源地址，返回給客戶端。
IP Tunneling：IP管道技術是在IP報文上再次封裝IP報文協議的一種技術。允許將一個目標為A的IP數據報文封裝成為目標為B的IP數據報文，在特定的IP 管道中傳輸。
上圖就是IP Tunneling模式的運作原理。首先客戶端還是通過訪問對外的一個服務IP請求服務，當Load Balancer接受到請求以后，檢查VIP注冊信息，然后根據算法選擇實際的一臺后臺服務器，通過IP管道封裝技術對IP報文再次封裝，然后將消息通過IP管道轉發到實際的服務器，實際的服務器通過解包處理請求，然后根據包體內實際的服務請求地址，將處理結果直接返回給客戶端。
Direct routing：利用Load Balancer和實際服務器共享同一VIP，簡單的通過修改消息報體目標MAC地址，轉發請求，然后再通過實際服務器配置VIP為本地回環，直接處理消息報文，而不再轉發，當處理完以后，直接將處理結果返回給客戶端。
上圖就是Direct Routing的運作流程，當外部請求到Load Balancer時，通過查找VIP注冊信息，直接選擇一臺后端服務器作為新的目標地址，修改消息報文中的目標地址Mac地址，轉發到目標服務器，目標服務器由于配置VIP在本地網卡回路中，因此直接處理消息，將處理完的結果直接返回給客戶端。
Virtual Server三種模式的比較
下表是官方整理出的關于Virtual Server三種不同模式的區別：
|
NAT
|
TUNNEL
|
DR
|
|
服務器要求
|
無要求
|
需要支持IP管道
|
無 arp組件（當前也有補丁）
|
|
網絡要求
|
Private
|
LAN/WAN
|
LAN
|
|
可支持后端服務器節點數
|
較少（10-20）
|
較多
|
較多
|
|
服務網關
|
Load Balancer
|
本身
|
本身
|
NAT：根據其實現原理，可以知道這種模式對于操作系統，網絡都沒有太多的要求和約束，但是由于消息需要打解包，同時消息的響應都必須經過Load Balancer，因此Load Balancer自身成為了瓶頸，這樣一個Load Balancer能夠支持的后端服務節點數量就有限了。當然可以采用混合模式來解決這個問題，也就是通過TUNNEL或者DR模式作為前端模式串聯起多個NAT模式Balancer。
TUNNEL：這種模式要求操作系統支持IP Tunnel，通過對IP報文再次封裝轉發，達到負載均衡的目的。設計這種模式的初衷是考慮，對于互聯網很多服務來說，服務請求數據量和返回數據量是不對稱的，返回的數據往往要遠遠大于請求的數據量，因此如果請求和返回都走Load Balancer會大量占用帶寬，影響處理能力。IP Tunnel設計中請求是通過Load Balancer，但是返回是直接返回到客戶端的，因此節省了返回的帶寬，提高了請求處理的能力。
DR：這種模式要求Load Balancer和后端服務器處于同一個局域網段。DR模式處理消耗最小，消息轉發和回復基本沒有損耗，因此效率應該是最高的，但是約束是相對來說最多的。