一.LVS主從工作原理和網站架構
LVS在基本的生產環境中,都會同時運行在二臺硬件相近的服務器上：LVS Router（主 LVS ）,一個作爲備份LVS（備份 LVS ）.
主 LVS 服務器在網站的前端起二個作用：
(1. 均衡負載壓力到真實服務器(如apache)上.
(2. 檢查後面真實服務器提供的服務是否正常.
備份LVS 用來監控主LVS和備份主服務器,在當故障出現時主LVS 死機 fail 掉了以後,就會啓動自己來接管主 LVS 的工作.
基中有一個叫 Pulse (心跳服務) 運行在主LVS和備份LVS上.在備份 LVS 上,每秒 pulse 發送一個心跳(heartbeat)到主LVS的外網接口檢查主LVS的服務是否正常.當然在主LVS上,也有pulse服務,它主要是響應備份LVS的心跳.
LVS進程調用 ipvsadm工具(RedHat開發)去配置和維護 IPVS 路由表,它會爲每一個在真實服務器上的虛擬服務啓動一個nanny進程.每一個nanny進程去檢查真實服務器上的服務狀態,如果有異常.就會將故障情況通知LVS進程.當故障時,LVS進程通知 ipvsadm 在 IPVS 路由表中將此節點刪除.當然,它發現故障的機器恢復時也能自動的加入到服務中來.
如果備份LVS未收到來自於主LVS的響應,它將調用send_arp將虛擬IP地址再分配到備份LVS的公網接口上.並在公網接口和局域網接口上分別發送一個命令去關掉主LVS上的LVS進程.同時啓動自己的LVS進程來調度客戶端請求.
下面是一個大中型網站 LVS 架構的服務器：
象平時在大中型網站的服務器架構,基本就象上面一樣.上面是一個服務器組提供同一種服務,如image的服務.
如上所示,最前面是一組主備LVS服務器,他們由心跳聯繫在一起 .接下來是一組功能相同的Real server服務器.有可能是Apache,nginx, squid之類的服務器.在接下來是一組應用服務器,應用服務器用的 Redhat Cluster 組成.最後,給所有的網站將數據放到一個網絡文件系統NFS AND 分佈文件系統GFS上做Shared Storage,用來提供所有的Real Server同時讀寫.當然,你也可以用SAN的存儲服務器.
二. IP 負載均衡技術
在LVS上調度器的實現技術中,由VS/NAT、VS/TUN和VS/DR這三種方法來實現使用負載均衡. IP 負載均衡技術是效率最高的.在已有的 IP 負載均衡技術中有通過網絡地址轉換（Network Address Translation）將一組服務器構成一個高性能的、高可用的虛擬服務器,我們稱之爲VS/NAT技術（Virtual Server via Network Address Translation）,大多數商品化的IP負載均衡調度器產品都是使用此方法,如 Cisco 的 LocalDirector、F5 的 Big/IP 和 Alteon的ACEDirector.當然在分析 VS/NAT 的缺點和網絡服務的非對稱性的基礎上,LVS 的作者提出通過 IP 隧道實現虛擬服務器的方法 VS/TUN （Virtual Server via IP Tunneling）,和通過直接路由實現虛擬服務器的方法 VS/DR（Virtual Server via Direct Routing）,它們可以極大地提高系統的伸縮性.
下面分別來介紹一下這三種方法.
1. 使用VS/NAT方法
客戶通過Virtual IP Address（虛擬服務的IP地址）訪問網絡服務時,請求報文到達調度器,調度器根據連接調度算法(下面會提到)從一組真實服務器中選出一臺服務器,將報文的目標地址 Virtual IP Address 改寫成選定服務器的地址,報文的目標端口改寫成選定服務器的相應端口,最後將修改後的報文發送給選出的服務器.同時,調度器在連接 Hash 表中記錄這個連接,當這個連接的下一個報文到達時,從連接Hash表中可以得到原選定服務器的地址和端口,進行同樣的改寫操作,並將報文傳給原選定的服務 器.當來自真實服務器的響應報文經過調度器時,調度器將報文的源地址和源端口改爲Virtual IP Address和相應的端口,再把報文發給用戶.
當使用VS/NAT方法時,如果有大量的響應數據經過調度器,調度器將成爲整個集羣的瓶頸.
這個很象 Nginx 的 7 層調度,所以大約能支持的後端機器只有 10 臺的樣子.因爲這臺調度器就成了瓶頸.
2. 使用VS/TUN方法
VS/TUN 的連接調度和管理與 VS/NAT 中的一樣,只是它的報文轉發方法不同.調度器根據各個服務器的負載情況,動態地選擇一 臺服務器,將請求報文封裝在另一個IP報文中,再將封裝後的IP報文轉發給選出的服務器；服務器收到報文後,先將報文解封獲得原來目標地址爲VIP的報 文,服務器發現VIP地址被配置在本地的IP隧道設備上,所以就處理這個請求,然後根據路由表將響應報文直接返回給客戶.
3. 使用VS/DR方法
調度器和服務器組都必須在物理上有一個網卡通過不分斷的局域網相連,如通過交換機或者高速的HUB相連.VIP地址爲調度器和服務器 組共享,調度器配置的VIP地址是對外可見的,用於接收虛擬服務的請求報文；所有的服務器把VIP地址配置在各自的Non-ARP網絡設備上,它對外面是 不可見的,只是用於處理目標地址爲VIP的網絡請求.在VS/DR中,調度器根據各個服務器的負載情況,動態地選擇一臺服務器,不修改也不封裝IP報文, 而是將數據幀的MAC地址改爲選出服務器的MAC地址,再將修改後的數據幀在與服務器組的局域網上發送.因爲數據幀的MAC地址是選出的服務器,所以服務 器肯定可以收到這個數據幀,從中可以獲得該IP報文.當服務器發現報文的目標地址VIP是在本地的網絡設備上,服務器處理這個報文,然後根據路由表將響應 報文直接返回給客戶.
VS/TUN相比,這種方法沒有IP隧道的開銷,但是要求負載調度器與實際服務器都有一塊網卡連在同一物理網段上,服務器網絡設備（或者設備別名）不作ARP響應,或者能將報文重定向（Redirect）到本地的Socket端口上.
三.負載調度算法
針對不同的網絡服務需求和服務器配置,IPVS調度器實現瞭如下八種負載調度算法：
1. 輪調（Round Robin）
調度器通過"輪叫"調度算法將外部請求按順序輪流分配到集羣中的真實服務器上,它均等地對待每一臺服務器,而不管服務器上實際的連接數和系統負載.
2.加權輪叫（Weighted Round Robin）
調度器通過"加權輪叫"調度算法根據真實服務器的不同處理能力來調度訪問請求.這樣可以保證處理能力強的服務器處理更多的訪問流量.調度器可以自動問詢真實服務器的負載情況,並動態地調整其權值. 3.最少鏈接（Least Connections）
調度器通過"最少連接"調度算法動態地將網絡請求調度到已建立的鏈接數最少的服務器上.如果集羣系統的真實服務器具有相近的系統性能,採用"最小連接"調度算法可以較好地均衡負載.
4.加權最少鏈接（Weighted Least Connections）
在集羣系統中的服務器性能差異較大的情況下,調度器採用"加權最少鏈接"調度算法優化負載均衡性能,具有較高權值的服務器將承受較大比例的活動連接負載.調度器可以自動問詢真實服務器的負載情況,並動態地調整其權值.
5.基於局部性的最少鏈接（Locality-Based Least Connections）
"基於局部性的最少鏈接" 調度算法是針對目標IP地址的負載均衡,目前主要用於Cache集羣系統.該算法根據請求的目標IP地址找出該目標IP地址最近使用的服務器,若該服務器是可用的且沒有超載,將請求發送到該服務器；若服務器不存在,或者該服務器超載且有服務器處於一半的工作負載,則用"最少鏈接"的原則選出一個可用的服務器,將請求發送到該服務器.
6.帶複製的基於局部性最少鏈接（Locality-Based Least Connections with Replication）
"帶複製的基於局部性最少鏈接"調度算法也是針對目標IP地址的負載均衡,目前主要用於Cache集羣系統.它與LBLC算法的不同之處是它要維護從一個目標IP地址到一組服務器的映射,而LBLC算法維護從一個目標IP地址到一臺服務器的映射.該算法根據請求的目標IP地址找出該目標IP地址對應的服務器組,按"最小連接"原則從服務器組中選出一臺服務器,若服務器沒有超載,將請求發送到該服務器,若服務器超載；則按"最小連接"原則從這個集羣中選出一臺服務器,將該服務器加入到服務器組中,將請求發送到該服務器.同時,當該服務器組有一段時間沒有被修改,將最忙的服務器從服務器組中刪除,以降低複製的程度. 7.目標地址散列（Destination Hashing）
"目標地址散列"調度算法根據請求的目標IP地址,作爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器,若該服務器是可用的且未超載,將請求發送到該服務器,否則返回空.
8.源地址散列（Source Hashing）
"源地址散列"調度算法根據請求的源IP地址,作爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器,若該服務器是可用的且未超載,將請求發送到該服務器,否則返回空.
總結
根據上面的分析,我們知道,在lvs中有VS/NAT、VS/TUN和VS/DR這三種方法來實現使用負載均衡,和8種調度的算法.下面我來針對不同的服務的實現方法如你是使用Web服務一般採用普通IP負載均衡技術,流媒體服務使用IPVS負載調度器一般使用直接路由方法（即VS/DR方法),對Cache服務如CDN之類技術的應用中一般使用IP隧道方法（即VS/TUN方法).
本文轉自： 扶凱 http://www.php-oa.com/