LVS 學習

參考網站:http://www.linuxvirtualserver.orghtml

一,部分概念

服務器集羣系統:前端

經過高性能網絡或局域網互聯的服務器集羣正成爲實現高可伸縮的、高可用網絡服務的有效結構,這種鬆耦合結構的服務器集羣系統有下列優勢:linux

  • 性能 網絡服務的工做負載一般是大量相互獨立的任務,經過一組服務器分而治之,能夠得到很高的總體性能。算法

  • 性能/價格比 組成集羣系統的PC服務器或RISC服務器和標準網絡設備由於大規模生產下降成本,價格低,具備最高的性能/價格比。若總體性能隨着結點數的增加而接近線性增長,該系統的性能/價格比接近於PC服務器。因此,這種鬆耦合結構比緊耦合的多處理器系統具備更好的性能/價格比。編程

  • 可伸縮性 集羣系統中的結點數目能夠增加到幾千個,乃至上萬個,其伸縮性遠超過單臺超級計算機。後端

  • 高可用性 在硬件和軟件上都有冗餘,經過檢測軟硬件的故障,將故障屏蔽,由存活結點提供服務,可實現高可用性bash

用服務器集羣系統實現可伸縮網絡服務也存在不少挑戰性的工做:服務器

  • 透明性(Transparency) 如何高效地使得由多個獨立計算機組成的鬆藕合的集羣系統構成一個虛擬服務器;客戶端應用程序與集羣系統交互時,就像與一臺高性能、高可用的服務器交互同樣,客戶端無須做任何修改。部分服務器的切入和切出不會中斷服務,這對用戶也是透明的。網絡

  • 性能(Performance) 性能要接近線性加速,這須要設計很好的軟硬件的體系結構,消除系統可能存在的瓶頸。將負載較均衡地調度到各臺服務器上。併發

  • 高可用性(Availability) 須要設計和實現很好的系統資源和故障的監測和處理系統。當發現一個模塊失敗時,要這模塊上提供的服務遷移到其餘模塊上。在理想情況下,這種遷移是即時的、自動的。

  • 可管理性(Manageability) 要使集羣系統變得易管理,就像管理一個單一映像系統同樣。在理想情況下,軟硬件模塊的插入能作到即插即用(Plug & Play)。

  • 可編程性(Programmability) 在集羣系統上,容易開發應用程序

二,linux virtual server

lvs:基於IP層和基於內容請求分發的負載平衡調度解決方法,並在Linux內核中實現了這些方法,將一組服務器構成一個實現可伸縮的、高可用網絡服務的虛擬服務器.

體系結構:

一組服務器經過高速的局域網或者地理分佈的廣域網相互鏈接,在它們的前端有一個負載調度器(Load Balancer)。負載調度器能無縫地將網絡請求調度到真實服務器上,從而使得服務器集羣的結構對客戶是透明的,客戶訪問集羣系統提供的網絡服務就像訪 問一臺高性能、高可用的服務器同樣。客戶程序不受服務器集羣的影響不需做任何修改。系統的伸縮性經過在服務機羣中透明地加入和刪除一個節點來達到,經過檢 測節點或服務進程故障和正確地重置系統達到高可用性。因爲咱們的負載調度技術是在Linux內核中實現的,咱們稱之爲Linux虛擬服務器(Linux Virtual Server)。

1,IP虛擬服務器軟件IPVS

在調度器的實現技術中,IP負載均衡技術是效率最高的.

IPVS 實現三種負載均衡技術:

  1. Virtual Server via Network Address Translation(VS/NAT) 經過網絡地址轉換,調度器重寫請求報文的目標地址,根據預設的調度算法,將請求分派給後端的真實服務器;真實服務器的響應報文經過調度器時,報文的源地址被重寫,再返回給客戶,完成整個負載調度過程。

  2. Virtual Server via IP Tunneling(VS/TUN) 採用NAT技術時,因爲請求和響應報文都必須通過調度器地址重寫,當客戶請求愈來愈多時,調度器的處理能力將成爲瓶頸。爲了解決這個問題,調度器把請求報 文經過IP隧道轉發至真實服務器,而真實服務器將響應直接返回給客戶,因此調度器只處理請求報文。因爲通常網絡服務應答比請求報文大許多,採用 VS/TUN技術後,集羣系統的最大吞吐量能夠提升10倍。

  3. Virtual Server via Direct Routing(VS/DR) VS/DR經過改寫請求報文的MAC地址,將請求發送到真實服務器,而真實服務器將響應直接返回給客戶。同VS/TUN技術同樣,VS/DR技術可極大地 提升集羣系統的伸縮性。這種方法沒有IP隧道的開銷,對集羣中的真實服務器也沒有必須支持IP隧道協議的要求,可是要求調度器與真實服務器都有一塊網卡連 在同一物理網段上。

調度算法:
  1. 輪叫(Round Robin) rr    調度器經過"輪叫"調度算法將外部請求按順序輪流分配到集羣中的真實服務器上,它均等地對待每一臺服務器,而無論服務器上實際的鏈接數和系統負載。

  2. 加權輪叫(Weighted Round Robin) wrr    調度器經過"加權輪叫"調度算法根據真實服務器的不一樣處理能力來調度訪問請求。這樣能夠保證處理能力強的服務器處理更多的訪問流量。調度器能夠自動問詢真實服務器的負載狀況,並動態地調整其權值。

  3. 最少連接(Least Connections) lc     調度器經過"最少鏈接"調度算法動態地將網絡請求調度到已創建的連接數最少的服務器上。若是集羣系統的真實服務器具備相近的系統性能,採用"最小鏈接"調度算法能夠較好地均衡負載。

  4. 加權最少連接(Weighted Least Connections) wlc    在集羣系統中的服務器性能差別較大的狀況下,調度器採用"加權最少連接"調度算法優化負載均衡性能,具備較高權值的服務器將承受較大比例的活動鏈接負載。調度器能夠自動問詢真實服務器的負載狀況,並動態地調整其權值。

  5. 基於局部性的最少連接(Locality-Based Least Connections)lblc    "基於局部性的最少連接" 調度算法是針對目標IP地址的負載均衡,目前主要用於Cache集羣系統。該算法根據請求的目標IP地址找出該目標IP地址最近使用的服務器,若該服務器 是可用的且沒有超載,將請求發送到該服務器;若服務器不存在,或者該服務器超載且有服務器處於一半的工做負載,則用"最少連接"的原則選出一個可用的服務 器,將請求發送到該服務器。

  6. 帶複製的基於局部性最少連接(Locality-Based Least Connections with Replication)lblcr     "帶複製的基於局部性最少連接"調度算法也是針對目標IP地址的負載均衡,目前主要用於Cache集羣系統。它與LBLC算法的不一樣之處是它要維護從一個 目標IP地址到一組服務器的映射,而LBLC算法維護從一個目標IP地址到一臺服務器的映射。該算法根據請求的目標IP地址找出該目標IP地址對應的服務 器組,按"最小鏈接"原則從服務器組中選出一臺服務器,若服務器沒有超載,將請求發送到該服務器,若服務器超載;則按"最小鏈接"原則從這個集羣中選出一 臺服務器,將該服務器加入到服務器組中,將請求發送到該服務器。同時,當該服務器組有一段時間沒有被修改,將最忙的服務器從服務器組中刪除,以下降複製的 程度。

  7. 目標地址散列(Destination Hashing)dh     "目標地址散列"調度算法根據請求的目標IP地址,做爲散列鍵(Hash Key)從靜態分配的散列表找出對應的服務器,若該服務器是可用的且未超載,將請求發送到該服務器,不然返回空。

  8. 源地址散列(Source Hashing)sh       "源地址散列"調度算法根據請求的源IP地址,做爲散列鍵(Hash Key)從靜態分配的散列表找出對應的服務器,若該服務器是可用的且未超載,將請求發送到該服務器,不然返回空。

2,體系結構

採用三層結構:

  • 負載調度器(load balancer),它是整個集羣對外面的前端機,負責將客戶的請求發送到一組服務器上執行,而客戶認爲服務是來自一個IP地址(咱們可稱之爲虛擬IP地址)上的。

當主調度器失效時,主調度器上全部已創建鏈接的狀態信息將丟失,已有的鏈接會中斷。客戶須要向從新鏈接,從調度器纔會將新鏈接調 度到各個服務器上,這對客戶會形成必定的不便。

爲此,IPVS調度器在Linux 內核中實現一種高效狀態同步機制,將主調度器的狀態信息及時地同步到從調度器。當從調度器接管時,絕大部分已創建的鏈接會持續下去。

  • 服務器池(server pool),是一組真正執行客戶請求的服務器,執行的服務有WEB、MAIL、FTP和DNS等。

  • 共享存儲(shared storage),它爲服務器池提供一個共享的存儲區,這樣很容易使得服務器池擁有相同的內容,提供相同的服務。

3,負載均衡技術

基於RR-DNS

基於IP層負載均衡調度

NAT實現虛擬服務器(VS/NAT)

NAT的工做原理是報文頭(目標地址、源地址和端口等)被正確改寫後,客戶相信 它們鏈接一個IP地址,而不一樣IP地址的服務器組也認爲它們是與客戶直接相連的。由此,能夠用NAT方法將不一樣IP地址的並行網絡服務變成在一個IP地址 上的一個虛擬服務(內部網絡地址訪問Internet 或被Internet訪問)

經過IP隧道實現虛擬服務器(VS/TUN)

IP隧道(IP tunneling)是將一個IP報文封裝在另外一個IP報文的技術,這可使得目標爲一個IP地址的數據報文能被封裝和轉發到另外一個IP地址。IP隧道技 術亦稱爲IP封裝技術(IP encapsulation)。IP隧道主要用於移動主機和虛擬私有網絡(Virtual Private Network),在其中隧道都是靜態創建的,隧道一端有一個IP地址,另外一端也有惟一的IP地址。

VS/TUN 的工做流程:它的鏈接調度和管理與VS/NAT中的同樣,只是它的報文轉發方法不一樣。調度器根據各個服務器的負載狀況,動態地選擇一臺服務器, 將請求報文封裝在另外一個IP報文中,再將封裝後的IP報文轉發給選出的服務器;服務器收到報文後,先將報文解封得到原來目標地址爲VIP的報文,服務器發 現VIP地址被配置在本地的IP隧道設備上,因此就處理這個請求,而後根據路由表將響應報文直接返回給客戶。

根據缺省的TCP/IP協議棧處理,請求報文的目標地址爲VIP,響應報文的源地址確定也爲VIP,因此響應報文不須要做任何修改,能夠直接返回給客戶,客戶認爲獲得正常的服務,而不會知道到底是哪一臺服務器處理的。

直接路由實現虛擬服務器(VS/DR)

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,因此響應報文不須要做任何修改,能夠直接返回給客戶,客戶認爲獲得正常的服務,而不會知道是哪一臺服務器處理的。

VS/DR負載調度器跟VS/TUN同樣只處於從客戶到服務器的半鏈接中,按照半鏈接的TCP有限狀態機進行狀態遷移

三種方法優缺點:

Virtual Server via NAT

優勢:運行在任何tcp/ip 系統,服務器可使用私有ip地址。

缺點:伸縮能力有限,負載調度器自己會成爲系統瓶頸,

解決方法:

混合方法、VS/TUN和 VS/DR。在DNS混合集羣系統中,有若干個VS/NAT負載調度器,每一個負載調度器帶本身的服務器集羣,同時這些負載調度器又經過RR-DNS組成簡 單的域名。但VS/TUN和VS/DR是提升系統吞吐量的更好方法。

NAT模式:

集羣節點跟Direcator 必須在同一個IP網絡中;

RIP一般是私有地址,僅僅用於個集羣之間通訊;

director位於Client和real server之間,並負責處理進出的全部通訊; realservet必須將網關指向DIP,同時也支持端口影射; Realserver可使用任意OS; 在較大應用規模當中,單個Director會出現瓶頸; 大概能夠帶10個左右的SERVER就會出現瓶頸

 

Virtual Server via IP Tunneling

只會處理大量請求,不會成爲系統瓶頸,極大增長負載調度器調度的服務器數量。

要求:服務器支持「IP tunneling」或「IP encapsulation」

Virtual Server via Direct Routing

VS/DR調度器只處理客戶到服務器端的鏈接,響應數據能夠直接從獨立的網絡路由返回給客戶。這能夠極大地提升LVS集羣系統的伸縮性。

跟VS/TUN相比,這種方法沒有IP隧道的開銷,可是要求負載調度器與實際服務器都有一塊網卡連在同一物理網段上,服務器網絡設備(或者設備別名)不做ARP響應,或者能將報文重定向(Redirect)到本地的Socket端口上

工做模式:

NAT和TUN種模式基本上都是工做在網絡層上(三層),直接路由模式則應該是工做在數據鏈路

原理 :DR和REALSERVER都使用同一個IP對外服務。但只有DR對ARP請求進行響應,全部REALSERVER對自己這個IP的ARP請求保持靜 默,網關會把對這個服務IP的請求所有定向給DR,而DR收到數據包後根據調度算法,找出對應的REALSERVER,把目的MAC地址改成 REALSERVER的MAC併發給這臺REALSERVER,REALSERVER收到這個數據包,則等於直接從客戶端收到這個數據包無異,處理後 直接返回給客戶端。DR要對二層包頭進行改換,因此DR和REALSERVER之間必須在一個廣播域

 

4,持久鏈接

參考博客

持久鏈接是指不管使用什麼算法,LVS持久都能實如今必定時間內,未來自同一個客戶端請求派發至此前選定的RS。

當使用LVS持久性的時候,Director在內部使用一個鏈接根據記錄稱之爲「持久鏈接模板」來確保全部來自同一個客戶端的請求被分發到同一臺Real Server上。

說明:持久鏈接模板是指每個客戶端 及分配給它的RS的映射關係;

 

1)PPC(Persistent Port Connections)未來自於同一個客戶端對同一個集羣服務的請求,始終定向至此前選定的RS;(持久端口鏈接)

client---->LVS(80)---->RS1 或 client---->LVS(23)---->RS2

缺陷:指望訪問不一樣的端口到同一臺RS上,沒法實現。

配置:

ipvsadm -A -t 172.16.100.1:80 -s rr -p 3600
ipvsadm -a -t 172.16.100.1:80 -r 172.16.100.10 -g -w 2
ipvsadm -a -t 172.16.100.1:80 -r 172.16.100.11 -g -w 2

2)PCC(Persistent Client Connections):未來自於同一個客戶端對全部端口的請求,始終定向至此前選定的RS;(持久客戶端鏈接)

說明:PCC是一個虛擬服務沒有端口號(或者端口號爲0),以"-p" 來標識服務。

缺陷:定向全部服務,指望訪問不一樣的Real Server沒法實現。

配置:

ipvsadm -A -t 172.16.100.1:0 -s rr -p 3600
ipvsadm -a -t 172.16.100.1:0 -r 172.16.100.10 -g -w 2
ipvsadm -a -t 172.16.100.1:0 -r 172.16.100.11 -g -w 2

3)PNMPP(Persistent Netfilter Marked Packet Persistence):持久防火牆標記鏈接,根據iptables 的規則,將對於某類服務幾個不一樣端口的訪問定義爲一類。

先對某一特定類型的數據包打上標記,而後再將基於某一類標記的服務送到後臺的Real Server上去,後臺的Real Server 並不識別這些標記。將持久和防火牆標記結合起來就可以實現端口姻親功能,只要是來自某一客戶端的對某一特定服務(須要不一樣的端口)的訪問都定義到同一臺 Real Server上去。

案例:一個用戶在訪問購物網站時同時使用HTTP(80)和HTTPS(443)兩種協議,咱們須要將其定義到同一臺Real Server上,而其餘的服務不受限制。

配置:

iptables -t mangle -A PREROUTING -d 172.16.100.1 -i eth0 -p tcp --dport 80 -j MARK --set-mark 8
iptables -t mangle -A PREROUTING -d 172.16.100.1 -i eth0 -p tcp --dport 443 -j MARK --set-mark 8
ipvsadm -A -f 8 -s rr -p 600
ipvsadm -a -f 8 -r 172.16.100.10 -g -w 2
ipvsadm -a -f 8 -r 172.16.100.11 -g -w 1

三,知識點

1,考察點

lvs-nat 與lvs-fullnat :請求和響應報文都經由Director

lvs-nat :RIP 的網關要指向DIP

lvs-fullnat :RIP 和DIP 未必在同一IP 網絡,但要能通訊

lvs-dr 與lvs-tun :請求報文要經由Director,但響應報文由RS直接發往Client

lvs-dr :經過封裝新的MAC 首部實現,經過MAC 網絡轉發

lvs-tun :經過在原IP 報文外封裝新IP頭實現轉發,支持遠距離通訊

lvs-nat :修改請求報文的目標IP, 多目標IP的DNAT(目標地址轉換)

lvs-dr :操縱封裝新的MAC地址 lvs-tun :在原請求IP報文以外新加一個IP首部

lvs-fullnat :修改請求報文的源和目標IP

lvs-nat

1)RIP 和DIP能夠在也能夠不在同一個IP網絡,且應該使用私網地址,RS的網關要指向DIP

2)請求報文和響應報文都必須經由Director 轉發,Director易於成爲系統瓶頸

3)支持端口映射,可修改請求報文的目標PORT

4)VS 必須是Linux系統,RS能夠是任意OS

5)nat工做模式的Director有兩個ip是vip和dip,vip用戶客戶端通訊提供服務,dip用於真實服務器通訊。

lvs-tun

轉發方式: 不修改請求報文的IP首部(源IP爲CIP,目標IP爲VIP),而在源IP報文以外再封裝一個IP首部(源IP是DIP,目標IP是RIP),將報文發往挑選出的目標RS ,RS直接響應給客戶端(源IP是VIP ,目標IP是CIP)

1)DIP, VIP, RIP 都應該是公網地址

2)RS的網關不能也不可能指向DIP

3)請求報文要經由Director ,但響應不能經由Director

4)不支持端口映射

5)RS的OS須支持隧道功能

lvs-dr

lvs-dr

注意: Director和各RS都配置有VIP

1)確保前端路由器將目標IP 爲VIP 的請求報文發往Director

在前端網關作靜態綁定VIP 和Director的MAC 地址

在RS上使用arptables工具

arptables -A IN -d $VIP -j DROP

arptables -A OUT -s $VIP -j mangle --mangle-ip-s $RIP

在RS上修改內核參數以限制arp通告及應答級別

arp_announce

arp_ignore

2)RS的RIP可使用私網地址,也能夠是公網地址,RIP與DIP在同一IP網絡,RIP的網關不能指向DIP,以確保響應報文不會經由Director

3)RS和Director要在同一個物理網絡

4)請求報文要經由Director,但響應報文不經由Director,而由RS直接發往Client

5)不支持端口映射(端口不能修敗)

6)RS可以使用大多數OS

 

負載均衡實現:

負載均衡集羣設計時要注意的問題

(1)是否須要會話保持

(2)是否須要共享存儲

共享存儲:NAS,SAN,DS (分佈式存儲)

數據同步:

lvs-nat:

設計要點:

(1) RIP 與DIP 在同一IP 網絡, RIP 的網關要指向DIP

(2) 支持端口映射

(3) Director要打開核心轉發功能

lvs-dr:

dr模型中,各主機上均須要配置VIP,解決地址衝突的方式有三種:

(1)在前端網關作靜態綁定

(2)在各RS 使用arptables

(3)在各RS 修改內核參數,來限制arp響應和通告的級別

三種方法中只有第三種方法修改RS的內核參數最實用

限制響應級別:arp_ignore

0:默認值,表示可以使用本地任意接口上配置的任意地址進行響應

1: 僅在請求的目標IP 配置在本地主機的接收到請求報文的接口上時,纔給予響應

限制通告級別:arp_announce

0 :默認值,把本機全部接口的全部信息向每一個接口的網絡進行通告

1 :儘可能避免將接口信息向非直接鏈接網絡進行通告

2 :必須避免將接口信息向非本網絡進行通告

實現LVS-DR的配置腳本(未測試)
RS 的預配置腳本
#!/bin/bash
vip=192.168.0.100
mask='255.255.255.255‘
dev=lo:1
case $1 in
start)
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
ifconfig $dev $vip netmask $mask broadcast $vip up
route add -host $vip dev $dev
;;
stop)
ifconfig $dev down
echo 0 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 0 > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo 0 > /proc/sys/net/ipv4/conf/all/arp_announce
echo 0 > /proc/sys/net/ipv4/conf/lo/arp_announce
;;
*)
echo "Usage: $(basename $0) start|stop"
exit 1
;;
esac
VS的配置腳本
#!/bin/bash
vip='192.168.0.100'
iface='eth0:1'
mask='255.255.255.255'
port='80'
rs1='192.168.0.101'
rs2='192.168.0.102'
scheduler='wrr'
type='-g'
case $1 in
start)
ifconfig $iface $vip netmask $mask broadcast $vip up
iptables -F
ipvsadm -A -t ${vip}:${port} -s $scheduler
ipvsadm -a -t ${vip}:${port} -r ${rs1} $type -w 1
ipvsadm -a -t ${vip}:${port} -r ${rs2} $type -w 1
;;
stop)
ipvsadm -C
ifconfig $iface down
;;
*)
echo "Usage $(basename $0) start|stop「;exit 1
;;
esac

 

2,安裝

是否支持ipvs

modprobe -l | grep ipvs 或 lsmod | grep ipvs

安裝

yum -y install ipvsadm

命令

ipvs -A -t|u|f service-address [-s scheduler]

-t: TCP協議的集羣 -u: UDP協議的集羣 service-address: IP:PORT -f: FWM: 防火牆標記 service-address: Mark Number

例: ipvsadm -A -t 172.16.1.253:80 -s wlc

修改集羣

ipvs -E -t|u|f service-address [-s scheduler]

例:ipvsadm -E -t 172.16.1.253:80 -s wrr

刪除集羣:

ipvsadm -D -t|u|f service-address

例: ipvsadm -D -t 172.16.1.253:80

管理集羣中RealServer

添加RS :ipvsadm -a -t|u|f service-address -r server-address [-g|i|m] [-w weight]

-t|u|f service-address:事先定義好的某集羣服務 -r server-address: 某RS的地址,在NAT模型中,可以使用IP:PORT實現端口映射;

-g: DR ​ -i: TUN ​ -m: NAT

例:

[root@lvs ~]# ipvsadm -a -t 172.16.1.253:80 -r 172.16.1.101 –g -w 5

[root@lvs ~]# ipvsadm -a -t 172.16.1.253:80 -r 172.16.1.102 –g -w 10

修改RS:

ipvsadm -e -t|u|f service-address -r server-address [-g|i|m] [-w weight]

例:

ipvsadm -e -t 172.16.1.253:80 -r 172.16.1.101 –g -w 3

刪除:

ipvsadm -d -t|u|f service-address -r server-address

例:

ipvsadm -d -t 172.16.1.253:80 -r 172.16.1.101

查看: ipvsadm -L|l [options]

-n: 數字格式顯示主機地址和端口 --stats:統計數據 --rate: 速率 --timeout: 顯示tcp、tcpfin和udp的會話超時時長 -c: 顯示當前的ipvs鏈接情況

刪除全部集羣服務: ipvsadm -C

保存規則至默認配置文件:service ipvsadm save

至指定文件:ipvsadm -S > /path/to/somefile

載入保存的文件: ipvsadm -R < /path/form/somefile

注意項:

關於時間同步:各節點間的時間誤差不大於1s,建議使用統一的ntp服務器進行更新時間

DR模型中的VIP的MAC廣播問題:

在DR模型中,因爲每一個節點均要配置VIP,所以存在VIP的MAC廣播問題,在如今的linux內核中,都提供了相應kernel 參數對MAC廣播進行管理,具體以下:

arp_ignore: 定義接收到ARP請求時的響應級別;
   0:只要本地配置的有相應地址,就給予響應;
   1:僅在請求的目標地址配置在到達的接口上的時候,纔給予響應;DR模型使用

arp_announce:定義將本身地址向外通告時的通告級別;
   0:將本地任何接口上的任何地址向外通告;
   1:試圖僅向目標網絡通告與其網絡匹配的地址;
   2:僅向與本地接口上地址匹配的網絡進行通告;DR模型使用

四,配置測試

1,LVS-NAT

  • DS配置:

VIP: 172.22.144.164

DIP: 192.168.36.74

1,開啓路由轉發功能,清除全部的iptables限制

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -F

2,配置ipvsadm

ipvsadm -A -t 172.22.144.164:80 -s rr

ipvsadm -a -t 172.22.144.164:80 -r 192.168.36.72 -m

ipvsadm -a -t 172.22.144.164:80 -r 192.168.36.73 -m

# ipvsadm -L -n

IP Virtual Server version 1.2.1 (size=4096)

Prot LocalAddress:Port Scheduler Flags

-> RemoteAddress:Port Forward Weight ActiveConn InActConn

TCP 172.22.144.164:80 rr

-> 192.168.36.72:80 Masq 1 0 0

-> 192.168.36.73:80 Masq 1 0 0

  • RS配置:

RIP1:192.168.36.72

RIP2:192.168.36.73

1,配置RS的網關指向DS的DIP

[root@test73 ~] $ route -n

Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface

0.0.0.0 192.168.36.74 0.0.0.0 UG 100 0 0 eth1

2,配置httpd,並生成網頁

  • 測試(必定要檢測是否iptables限制了訪問):

[root@74 ~] $ curl http://172.22.144.164/index.html

test72.example.com

[root@74 ~] $ curl http://172.22.144.164/index.html

test73.example.com

 操,複製過來亂碼了

相關文章
相關標籤/搜索