相關概念html
Virtual Server via Network Address Translation(VS/NAT)
經過網絡地址轉換,調度器重寫請求報文的目標地址,根據預設的調度算法,將請求分派給後端的真實服務器;真實服務器的響應報文經過調度器時,報文的源地址被重寫,再返回給客戶,完成整個負載調度過程。前端
Virtual Server via IP Tunneling(VS/TUN)
採用NAT技術時,因爲請求和響應報文都必須通過調度器地址重寫,當客戶請求愈來愈多時,調度器的處理能力將成爲瓶頸。爲了解決這個問題,調度器把請求報 文經過IP隧道轉發至真實服務器,而真實服務器將響應直接返回給客戶,因此調度器只處理請求報文。因爲通常網絡服務應答比請求報文大許多,採用 VS/TUN技術後,集羣系統的最大吞吐量能夠提升10倍。linux
Virtual Server via Direct Routing(VS/DR)
VS/DR經過改寫請求報文的MAC地址,將請求發送到真實服務器,而真實服務器將響應直接返回給客戶。同VS/TUN技術同樣,VS/DR技術可極大地 提升集羣系統的伸縮性。這種方法沒有IP隧道的開銷,對集羣中的真實服務器也沒有必須支持IP隧道協議的要求,可是要求調度器與真實服務器都有一塊網卡連 在同一物理網段上。算法
三種IP負載均衡技術的優缺點概括在下表中:服務器
_ | VS/NAT | VS/TUN | VS/DR |
Server | any | Tunneling | Non-arp device |
server network | private | LAN/WAN | LAN |
server number | low (10~20) | High (100) | High (100) |
server gateway | load balancer | own router | Own router |
注: 以上三種方法所能支持最大服務器數目的估計是假設調度器使用100M網卡,調度器的硬件配置與後端服務器的硬件配置相同,並且是對通常Web服務。使用更 高的硬件配置(如千兆網卡和更快的處理器)做爲調度器,調度器所能調度的服務器數量會相應增長。當應用不一樣時,服務器的數目也會相應地改變。因此,以上數 據估計主要是爲三種方法的伸縮性進行量化比較。網絡
NAT模式詳解:負載均衡
VS/NAT的體系結構如圖所示。在一組服務器前有一個調度器,它們是經過Switch/HUB相鏈接的。這些服務器 提供相同的網絡服務、相同的內容,即無論請求被髮送到哪一臺服務器,執行結果是同樣的。服務的內容能夠複製到每臺服務器的本地硬盤上,能夠經過網絡文件系 統(如NFS)共享,也能夠經過一個分佈式文件系統來提供。less
客 戶經過Virtual IP Address(虛擬服務的IP地址)訪問網絡服務時,請求報文到達調度器,調度器根據鏈接調度算法從一組真實服務器中選出一臺服務器,將報文的目標地址 Virtual IP Address改寫成選定服務器的地址,報文的目標端口改寫成選定服務器的相應端口,最後將修改後的報文發送給選出的服務器。同時,調度器在鏈接Hash 表中記錄這個鏈接,當這個鏈接的下一個報文到達時,從鏈接Hash表中能夠獲得原選定服務器的地址和端口,進行一樣的改寫操做,並將報文傳給原選定的服務 器。當來自真實服務器的響應報文通過調度器時,調度器將報文的源地址和源端口改成Virtual IP Address和相應的端口,再把報文發給用戶。咱們在鏈接上引入一個狀態機,不一樣的報文會使得鏈接處於不一樣的狀態,不一樣的狀態有不一樣的超時值。在TCP 鏈接中,根據標準的TCP有限狀態機進行狀態遷移,這裏咱們不一一敘述,請參見W. Richard Stevens的《TCP/IP Illustrated Volume I》;在UDP中,咱們只設置一個UDP狀態。不一樣狀態的超時值是能夠設置的,在缺省狀況下,SYN狀態的超時爲1分鐘,ESTABLISHED狀態的超 時爲15分鐘,FIN狀態的超時爲1分鐘;UDP狀態的超時爲5分鐘。當鏈接終止或超時,調度器將這個鏈接從鏈接Hash表中刪除。tcp
這樣,客戶所看到的只是在Virtual IP Address上提供的服務,而服務器集羣的結構對用戶是透明的。對改寫後的報文,應用增量調整Checksum的算法調整TCP Checksum的值,避免了掃描整個報文來計算Checksum的開銷。
在 一些網絡服務中,它們將IP地址或者端口號在報文的數據中傳送,若咱們只對報文頭的IP地址和端口號做轉換,這樣就會出現不一致性,服務會中斷。因此,針 對這些服務,須要編寫相應的應用模塊來轉換報文數據中的IP地址或者端口號。咱們所知道有這個問題的網絡服務有FTP、IRC、H.32三、 CUSeeMe、Real Audio、Real Video、Vxtreme / Vosiac、VDOLive、VIVOActive、True Speech、RSTP、PPTP、StreamWorks、NTT AudioLink、NTT SoftwareVision、Yamaha MIDPlug、iChat Pager、Quake和Diablo。
下面,舉個例子來進一步說明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上。而到其餘端口的報文將被拒 絕。
Protocol | Virtual IP Address | Port | Real IP Address | Port | Weight |
TCP | 202.103.106.5 | 80 | 172.16.0.2 | 80 | 1 |
172.16.0.3 | 8000 | 2 | |||
TCP | 202.103.106.5 | 21 | 172.16.0.3 | 21 | 1 |
從如下的例子中,咱們能夠更詳細地瞭解報文改寫的流程。
訪問Web服務的報文可能有如下的源地址和目標地址:
SOURCE | 202.100.1.2:3456 | DEST | 202.103.106.5:80 |
調度器從調度列表中選出一臺服務器,例如是172.16.0.3:8000。該報文會被改寫爲以下地址,並將它發送給選出的服務器。
SOURCE | 202.100.1.2:3456 | DEST | 172.16.0.3:8000 |
從服務器返回到調度器的響應報文以下:
SOURCE | 172.16.0.3:8000 | DEST | 202.100.1.2:3456 |
響應報文的源地址會被改寫爲虛擬服務的地址,再將報文發送給客戶:
SOURCE | 202.103.106.5:80 | DEST | 202.100.1.2:3456 |
這樣,客戶認爲是從202.103.106.5:80服務獲得正確的響應,而不會知道該請求是服務器172.16.0.2仍是服務器172.16.0.3處理的。
優缺點:
TUN模式詳解
在VS/NAT 的集羣系統中,請求和響應的數據報文都須要經過負載調度器,當真實服務器的數目在10臺和20臺之間時,負載調度器將成爲整個集羣系統的新瓶頸。大多數 Internet服務都有這樣的特色:請求報文較短而響應報文每每包含大量的數據。若是能將請求和響應分開處理,即在負載調度器中只負責調度請求而響應直 接返回給客戶,將極大地提升整個集羣系統的吞吐量。
IP隧道(IP tunneling)是將一個IP報文封裝在另外一個IP報文的技術,這可使得目標爲一個IP地址的數據報文能被封裝和轉發到另外一個IP地址。IP隧道技 術亦稱爲IP封裝技術(IP encapsulation)。IP隧道主要用於移動主機和虛擬私有網絡(Virtual Private Network),在其中隧道都是靜態創建的,隧道一端有一個IP地址,另外一端也有惟一的IP地址。
咱們利用IP隧道技術將請求報文封裝轉 發給後端服務器,響應報文能從後端服務器直接返回給客戶。但在這裏,後端服務器有一組而非一個,因此咱們不可能靜態地創建一一對應的隧道,而是動態地選擇 一臺服務器,將請求報文封裝和轉發給選出的服務器。這樣,咱們能夠利用IP隧道的原理將一組服務器上的網絡服務組成在一個IP地址上的虛擬網絡服務。 VS/TUN的體系結構如圖4所示,各個服務器將VIP地址配置在本身的IP隧道設備上。
VS/TUN 的工做流程如圖所示:它的鏈接調度和管理與VS/NAT中的同樣,只是它的報文轉發方法不一樣。調度器根據各個服務器的負載狀況,動態地選擇一臺服務器, 將請求報文封裝在另外一個IP報文中,再將封裝後的IP報文轉發給選出的服務器;服務器收到報文後,先將報文解封得到原來目標地址爲VIP的報文,服務器發 現VIP地址被配置在本地的IP隧道設備上,因此就處理這個請求,而後根據路由表將響應報文直接返回給客戶。
在這裏須要指出,根據缺省的TCP/IP協議棧處理,請求報文的目標地址爲VIP,響應報文的源地址確定也爲VIP,因此響應報文不須要做任何修改,能夠直接返回給客戶,客戶認爲獲得正常的服務,而不會知道到底是哪一臺服務器處理的
DR模式詳解
跟VS/TUN 方法相同,VS/DR利用大多數Internet服務的非對稱特色,負載調度器中只負責調度請求,而服務器直接將響應返回給客戶,能夠極大地提升整個集羣 系統的吞吐量。該方法與IBM的NetDispatcher產品中使用的方法相似(其中服務器上的IP地址配置方法是類似的),但IBM的 NetDispatcher是很是昂貴的商品化產品,咱們也不知道它內部所使用的機制,其中有些是IBM的專利。
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中,根據缺省的TCP/IP協議棧處理,請求報文的目標地址爲VIP,響應報文的源地址確定也爲VIP,因此響應報文不須要做任何修改,能夠直接返回給客戶,客戶認爲獲得正常的服務,而不會知道是哪一臺服務器處理的。
DR模式的優缺點:
ipvsadm的功能
添加:-A|E -t|u|f service-address [-s scheduler]
[-p [timeout]] [-M netmask]
-t tcp協議集羣
-u udp協議集羣
-f 防火牆標記 service-adress=Mark Number
service-address: ip:port -s (能夠省略,默認爲wlc)
輪叫調度 rr (Round Robin)
加權輪叫調度 wrr(Weighted Round Robin)
最少連接調度 lc(Least Connections)
加權最少連接調度 wlc(Weighted Least Connections)
$ipvsadm -A -t 192.168.1.114:80 -s rr
修改: -E
刪除: —D
添加: ipvsadm -a|e -t|u|f service-address -r server-address [-g|i|m] [-w weight] [-x upper] [-y lower]
-t|u|f service-address:事先定義好的某集羣服務
[-g|i|m]: LVS的類型
-g: DR (Direct Routing)默認
-i: TUN (Tunneling)
-m: NAT (Network Address Translation)
[-w weight]: 定義服務器權重
ipvsadm -a -t 192.168.1.114:80 -r 192.168.11.129 -m -w 1
ipvsadm -a -t 192.168.1.114:80 -r 192.168.11.132 -m -w 3
修改: -e
刪除: -d
-L|l
-n :數字格式顯示主機地址和端口
--stats:統計數據
--rate: 速率
--timeout:顯示tcp,tcpfin,udp的會話超時時長
-c:顯示當前的ipvs的鏈接情況
刪除全部集羣服務
-C:清空ipvs的規則
保存規則
-S
#ipvsadm -S >/path/to/somefile
載入此前規則
-R
#ipvsadm -R >/path/to/somefile(默認:/etc/sysconfig/ipvsadm)
NAT模型:
Linux系統默認是禁止數據包轉發的。所謂轉發即當主機擁有多於一塊的網卡時,其中一塊收到數據包,根據數據包的目的ip地址將包發往本機另外一網卡,該網卡根據路由表繼續發送數據包。這一般就是路由器所要實現的功能。
NAT模型
$ipvsadm -A -t 192.168.1.114:80 -s wrr
$ipvsadm -a -t 192.168.1.114:80 -r 192.168.11.129 -m -w 1
$ipvsadm -a -t 192.168.1.114:80 -r 192.168.11.132 -m -w 3
echo "1" > /proc/sys/net/ipv4/ip_forward
192.168.11.129/132指向192.168.11.131
官方參考資料:
http://www.linuxvirtualserver.org/zh/lvs1.html
http://www.linuxvirtualserver.org/zh/lvs2.html