Rhel6-lvs配置文檔

系統環境: rhel6 x86_64 iptables and selinux disabled

相關網址：http://zh.linuxvirtualserver.org/

yum倉庫配置:

[rhel-source]

name=Red Hat Enterprise Linux $releasever - $basearch - Source

baseurl=ftp://192.168.122.1/pub/yum

enabled=1

gpgcheck=1

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release

[HighAvailability]

name=Instructor Server Repository

baseurl=ftp://192.168.122.1/pub/yum/HighAvailability

gpgcheck=1

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release

enabled=1

[LoadBalancer]

name=Instructor Server Repository

baseurl=ftp://192.168.122.1/pub/yum/LoadBalancer

gpgcheck=1

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release

enabled=1

[ResilientStorage]

name=Instructor Server Repository

baseurl=ftp://192.168.122.1/pub/yum/ResilientStorage

gpgcheck=1

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release

enabled=1

[ScalableFileSystem]

name=Instructor Server Repository

baseurl=ftp://192.168.122.1/pub/yum/ScalableFileSystem

gpgcheck=1

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release

enabled=1

Load Balancer:

kernel 2.6.x 已內建 LVS 模組

kernel 2.4.x 或以前的內核版本需打補丁

rhel5 /rhel6 自帶 LVS 軟件包 安裝 ipvsadm 軟件包便可使用

三種 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服務。使用更高的硬件配置(如千兆網卡和更快的處理器)做爲調度器,調度器所能調度的服務器數量會相應增長。當應用不一樣時,服務器的數目也會相應地改變。因此,以上數據估計主要是爲三種方法的伸縮性進行量化比較。

IP負載均衡技術:

經過NAT實現虛擬服務器（VS/NAT）

因爲IPv4中IP地址空間的日益緊張和安全方面的緣由，不少網絡使用保留IP地址（10.0.0.0/255.0.0.0、172.16.0.0 /255.128.0.0和192.168.0.0/255.255.0.0）[64, 65, 66]。這些地址不在Internet上使用，而是專門爲內部網絡預留的。當內部網絡中的主機要訪問Internet或被Internet訪問時，就須要採用網絡地址轉換（Network Address Translation, 如下簡稱NAT），將內部地址轉化爲Internets上可用的外部地址。NAT的工做原理是報文頭（目標地址、源地址和端口等）被正確改寫後，客戶相信它們鏈接一個IP地址，而不一樣IP地址的服務器組也認爲它們是與客戶直接相連的。由此，能夠用NAT方法將不一樣IP地址的並行網絡服務變成在一個IP地址上的一個虛擬服務。

VS/NAT的體系結構下圖所示。在一組服務器前有一個調度器，它們是經過Switch/HUB相鏈接的。這些服務器提供相同的網絡服務、相同的內容，即無論請求被髮送到哪一臺服務器，執行結果是同樣的。服務的內容能夠複製到每臺服務器的本地硬盤上，能夠經過網絡文件系統（如NFS）共享，也能夠經過一個分佈式文件系統來提供。

客戶經過Virtual IP Address（虛擬服務的IP地址）訪問網絡服務時，請求報文到達調度器，調度器根據鏈接調度算法從一組真實服務器中選出一臺服務器，將報文的目標地址 Virtual IP Address改寫成選定服務器的地址，報文的目標端口改寫成選定服務器的相應端口，最後將修改後的報文發送給選出的服務器。同時，調度器在鏈接Hash 表中記錄這個鏈接，當這個鏈接的下一個報文到達時，從鏈接Hash表中能夠獲得原選定服務器的地址和端口，進行一樣的改寫操做，並將報文傳給原選定的服務 器。當來自真實服務器的響應報文通過調度器時，調度器將報文的源地址和源端口改成Virtual IP Address和相應的端口，再把報文發給用戶。咱們在鏈接上引入一個狀態機，不一樣的報文會使得鏈接處於不一樣的狀態，不一樣的狀態有不一樣的超時值。在TCP 鏈接中，根據標準的TCP有限狀態機進行狀態遷移；在UDP中，咱們只設置一個UDP狀態。不一樣狀態的超時值是能夠設置的，在缺省狀況下，SYN狀態的超 時爲1分鐘，ESTABLISHED狀態的超時爲15分鐘，FIN狀態的超時爲1分鐘；UDP狀態的超時爲5分鐘。當鏈接終止或超時，調度器將這個鏈接從 鏈接Hash表中刪除。

這樣，客戶所看到的只是在Virtual IP Address上提供的服務，而服務器集羣的結構對用戶是透明的。對改寫後的報文，應用增量調整Checksum的算法調整TCP Checksum的值，避免了掃描整個報文來計算Checksum的開銷。

在一些網絡服務中，它們將IP地址或者端口號在報文的數據中傳送，若咱們只對報文頭的IP地址和端口號做轉換，這樣就會出現不一致性，服務會中斷。 因此，針對這些服務，須要編寫相應的應用模塊來轉換報文數據中的IP地址或者端口號。咱們所知道有這個問題的網絡服務有FTP、IRC、H.323、 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處理的。

VS/NAT 的優勢是服務器能夠運行任何支持 TCP/IP 的操做系統,它只須要一個 IP 地址配置在調度器上, 服務器組能夠用私有的 IP 地址。缺點是它的伸縮能力有限, 當服務器結點數目升到 20 時,調度器自己 有可能成爲系統的新瓶頸,由於在 VS/NAT 中請求和響應報文都須要經過負載調度器。

Load Balance 雙網卡 192.168.122.163(外網) 192.168.1.163(內網)

若是隻有一塊網卡可用如下方式:

Load Balance 192.168.1.163 server63.example.com

Gateway 192.168.1.163 （注：Realserver的網關應設爲Load Balance的內網IP）

Realserver1 192.168.1.119 server19.example.com

Realserver2 192.168.1.25 server25.example.com

Virtual IP 192.168.122.163

如下步驟在server63上實施：

#開啓路由機制

[root@server63 ~]# vim /etc/sysctl.conf

net.ipv4.ip_forward = 1

[root@server63 ~]# sysctl -p

#加載nat模塊

[root@server63 ~]# modprobe iptable_nat

注:若是不加載此模塊,也能夠在第一次訪問時成功,可是會在再次訪問時出現延遲過長,或訪問超時現象

#加載rule

[root@server63 ~]# yum install ipvsadm -y

[root@server63 ~]# ipvsadm -C

[root@server63 ~]# ipvsadm -A -t 192.168.122.163:80 -s rr

[root@server63 ~]# ipvsadm -a -t 192.168.122.163:80 -r 192.168.1.119:80 -m

[root@server63 ~]# ipvsadm -a -t 192.168.122.163:80 -r 192.168.1.25:80 -m

#保存rule

[root@server63 ~]# /etc/init.d/ipvsadm save

 

#綁定vip

[root@server63 ~]# ifconfig eth0:0 192.168.122.163 netmask 255.255.255.0

或

[root@server63 ~]# ip addr add 192.168.122.163/24 dev eth0

注：可用ip addr show查看

如下步驟在server19和server25上實施：

[root@server63 ~]# yum install httpd -y

[root@server63 ~]# echo `hostname` > /var/www/html/index.html

[root@server63 ~]# /etc/init.d/httpd start

測試:

選擇一臺 192.168.122.0/24 網段主機訪問 http:// 192.168.122.163 反覆刷新網頁,每次出現的網頁不一樣 則表示成功。

 

 

經過IP隧道實現虛擬服務器（VS/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的體系結構如圖3.3所示，各個服務器將VIP地址配置在本身的IP隧道設備上。

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

在這裏，請求報文的目標地址爲VIP，響應報文的源地址也爲VIP，因此響應報文不須要做任何修改，能夠直接返回給客戶，客戶認爲獲得正常的服務，而不會知道是哪一臺服務器處理的。

在VS/TUN中，響應報文根據服務器的路由表直接返回給客戶，而不通過負載調度器，因此負載調度器只處於從客戶到服務器的半鏈接中，VS/TUN 的TCP狀態遷移與VS/NAT的不一樣。咱們給出半鏈接的TCP有限狀態機，如圖3.5所示，圈表示狀態，箭頭表示狀態間的轉換，箭頭上的標識表示在當前 狀態上收到該標識的輸入，遷移到下一個狀態。VS/TUN的TCP狀態遷移是按照半鏈接的TCP有限狀態機進行的。

Realserver 192.168.122.193 server93.example.com

Realserver 192.168.122.194 server94.example.com

Load Balance 192.168.122.13 server13.example.com

Gateway 192.168.122.13(LB的網關爲自身，Realserver的網關均爲LB)

Virtual IP 192.168.122.222

如下步驟在server13上實施:

#開啓路由機制

[root@server13 ~]# vim /etc/sysctl.conf

net.ipv4.ip_forward = 1

[root@server13 ~]# sysctl -p

#加載rule

[root@server13 ~]# yum install ipvsadm -y

[root@server13 ~]# ipvsadm -C

[root@server13 ~]# ipvsadm -A -t 192.168.122.222:80 -s rr

[root@server13 ~]# ipvsadm -a -t 192.168.122.222:80 -r 192.168.122.193:80 -i

[root@server13 ~]# ipvsadm -a -t 192.168.122.222:80 -r 192.168.122.194:80 -i

#保存rule

[root@server13 ~]# /etc/init.d/ipvsadm save

 

#綁定vip

[root@server13 ~]# ifconfig eth0:0 192.168.122.222 netmask 255.255.255.0

或

[root@server13 ~]# ip addr add 192.168.122.222/24 dev eth0

注：可用ip addr show查看

 

如下步驟在server93和server94上實施：

[root@server93 ~]# vim /etc/sysctl.conf

net.ipv4.ip_forward = 1

net.ipv4.conf.all.arp_ignore = 1

net.ipv4.conf.all.arp_announce = 2

[root@server93 ~]# sysctl -p

[root@server93 ~]# ifconfig tunl0 192.168.122.222 netmask 255.255.255.0 up

[root@server93 ~]# route add -host 192.168.122.222 dev tunl0

 

[root@server93 ~]# yum install httpd -y

[root@server93 ~]# echo `hostname` > /var/www/html/index.html

[root@server93 ~]# /etc/init.d/httpd start

測試:

選擇一臺 192.168.122.0/24 網段主機訪問 http:// 192.168.122.222 反覆刷新網頁,每次出現的網頁不一樣 則表示成功。

經過直接路由實現虛擬服務器（VS/DR）

跟VS/TUN方法相同，VS/DR利用大多數Internet服務的非對稱特色，負載調度器中只負責調度請求，而服務器直接將響應返回給客戶，可 以極大地提升整個集羣系統的吞吐量。該方法與IBM的NetDispatcher產品中使用的方法相似，但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中，請求報文的目標地址爲VIP，響應報文的源地址也爲VIP，因此響應報文不須要做任何修改，能夠直接返回給客戶，客戶認爲獲得正常的服務，而不會知道是哪一臺服務器處理的。

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

跟 VS/TUN 方法相同,負載調度器中只負責調度請求,而服務器直接將響應返回給客戶,能夠極大地提 高整個集羣系統的吞吐量。跟 VS/TUN 相比,這種方法沒有IP隧道的開銷,但調度器和服務器組都必 須在物理上有一個網卡經過不分斷的局域網相連,如經過交換機或者高速的HUB相連。VIP 地址爲調度器和服務器組共享,調度器配置的 VIP 地址是對外可見的,用於接收虛擬服務的請求報文;全部的服務器把VIP地址配置在各自的Non-ARP網絡設備上,它對外面是不可見的,只是用於處理目標地址爲 VIP 的網絡請求。

如下是 LVS-DR 的工做原理,包括數據包、數據幀的走向和轉換過程:

官方的原理說明:Director 接收用戶的請求,而後根據負載均衡算法選取一臺 realserver,將包轉發過去,最後由 realserver 直接回復給用戶。

實例場景設備清單:

說明:我這裏爲了方便,client 是與 vip 同一網段的機器。若是是外部的用戶訪問,將 client 替換成 gateway 便可,由於 IP 包頭是不變的,變的只是源 mac 地址。

1.client 向目標 vip 發出請求,Director 接收。此時 IP 包頭及數據幀頭信息以下:

2.VS 根據負載均衡算法選擇一臺active的realserver(假設192.168.57.122),將此 RIP 所在網 卡的mac地址做爲目標 mac 地址,發送到局域網裏.此時 IP 包頭及數據幀頭信息以下:

3.realserver(192.168.57.122)在局域網中收到這個幀,拆開後發現目標 IP(VIP)與本地匹配,因而 處理這個報文.隨後從新封裝報文,發送到局域網.此時 IP 包頭及數據幀頭信息以下:

4 若是client與VS同一網段,那麼client(192.168.57.135)將收到這個回覆報文.若是跨了網段, 那麼報文經過 gateway/路由器經由 Internet 返回給用戶.

 

Realserver 192.168.122.119 server19.example.com

Realserver 192.168.122.25 server25.example.com

Load Balance 192.168.122.163 server63.example.com

Virtual IP 192.168.122.178

 

如下步驟在server63上實施:

[root@server63 ~]# yum install ipvsadm -y

#加載rule

[root@server63 ~]# ipvsadm -C (清空ipvs轉發表 )

[root@server63 ~]# ipvsadm -A -t 192.168.122.178:80 -s rr (-A:添加一個虛擬服務; -t:tcp服務;-s 調度算法)

[root@server63 ~]# ipvsadm -a -t 192.168.122.178:80 -r 192.168.122.119:80 -g

[root@server63 ~]# ipvsadm -a -t 192.168.122.178:80 -r 192.168.122.25:80 -g

#保存rule

[root@server63 ~]# /etc/init.d/ipvsadm save

#綁定vip

[root@server63 ~]# ifconfig eth0:0 192.168.122.178 netmask 255.255.255.0

或

[root@server63 ~]# ip addr add 192.168.122.178/24 dev eth0

注：可用ip addr show查看

Realserver必須不支持arp

如下步驟在server19上實施:

#關閉arp

方法一

[root@server19 ~]# yum install arptables_jf -y

[root@server19 ~]# arptables -A IN -d 192.168.122.178 -j DROP

[root@server19 ~]# arptables -A OUT -s 192.168.122.178 -j mangle --mangle-ip-s 192.168.122.119

[root@server19 ~]# /etc/init.d/arptables_jf save

方法二

[root@server19 ~]# vim /etc/sysctl.conf

net.ipv4.conf.lo.arp_ignore = 1

net.ipv4.conf.lo.arp_announce = 2

net.ipv4.conf.all.arp_ignore = 1

net.ipv4.conf.all.arp_announce = 2

[root@server19 ~]# sysctl -p

[root@server19 ~]# ifconfig eth0:0 192.168.122.178 netmask 255.255.255.255

或

[root@server19 ~]# ip addr add 192.168.122.178 dev eth0

注：可用ip addr show查看

[root@server19 ~]# yum install httpd -y

[root@server19 ~]# echo `hostname` > /var/www/html/index.html

[root@server19 ~]# /etc/init.d/httpd start

如下步驟在server25上實施:

#關閉arp

方法一

[root@server25 ~]# yum install arptables_jf -y

[root@server25 ~]# arptables -A IN -d 192.168.122.178 -j DROP

[root@server25 ~]# arptables -A OUT -s 192.168.122.178 -j mangle --mangle-ip-s 192.168.122.25

[root@server25 ~]# /etc/init.d/arptables_jf save

方法二

[root@server25 ~]# vim /etc/sysctl.conf

net.ipv4.conf.lo.arp_ignore = 1

net.ipv4.conf.lo.arp_announce = 2

net.ipv4.conf.all.arp_ignore = 1

net.ipv4.conf.all.arp_announce = 2

[root@server25 ~]# sysctl -p

[root@server25 ~]# ifconfig eth0:0 192.168.122.178 netmask 255.255.255.255

或

[root@server25 ~]# ip addr add 192.168.122.178 dev eth0

注：可用ip addr show查看

[root@server25 ~]# yum install httpd -y

[root@server25 ~]# echo `hostname` > /var/www/html/index.html

[root@server25 ~]# /etc/init.d/httpd start

測試:

訪問192.168.122.178反覆刷新網頁,每次出現的網頁不一樣則表示配置成功。

LVS 常見問題:

1.LVS/DR 如何處理請求報文的,會修改 IP 包內容嗎?

1.1vs/dr 自己不會關心 IP 層以上的信息,即便是端口號也是 tcp/ip 協議棧去判斷是否正確,vs/dr 本 身主要作這麼幾個事:

1)接收 client 的請求,根據你設定的負載均衡算法選取一臺 realserver 的 ip;

2)以選取的這個 ip 對應的 mac 地址做爲目標 mac,而後從新將 IP 包封裝成幀轉發給這臺 RS;

3)在 hashtable 中記錄鏈接信息。

vs/dr 作的事情不多,也很簡單,因此它的效率很高,不比硬件負載均衡設備差多少。

數據包、數據幀的大體流向是這樣的:client --> VS --> RS --> client

1.2 前面已做了回答,vs/dr 不會修改 IP 包的內容.

2. RealServer 爲何要在 lo 接口上配置 VIP,在出口網卡上配置 VIP 能夠嗎?

2.1 既然要讓 RS 可以處理目標地址爲 vip 的 IP 包,首先必需要讓 RS 能接收到這個包。

在 lo 上配置 vip 可以完成接收包並將結果返回 client。

2.2 答案是不能夠將 VIP 設置在出口網卡上,不然會響應客戶端的 arp request,形成 client/gateway

arp table 紊亂,以致於整個 loadbalance 都不能正常工做。

3. RealServer 爲何要抑制 arp 幀?

這個問題在上一問題中已經做了說明,這裏結合實施命令進一步闡述。咱們在具體實施部署的時候都會 做以下調整:

echo "1" >/proc/sys/net/ipv4/conf/lo/arp_ignore

echo "2">/proc/sys/net/ipv4/conf/lo/arp_announce

echo "1">/proc/sys/net/ipv4/conf/all/arp_ignore

echo "2">/proc/sys/net/ipv4/conf/all/arp_announce

我相信不少人都不會弄懂它們的做用是什麼,只知道必定得有。我這裏也不打算拿出來詳細討論,只是 做幾點說明,就當是補充吧。

3.1

echo "1" >/proc/sys/net/ipv4/conf/lo/arp_ignore

echo "2" >/proc/sys/net/ipv4/conf/lo/arp_announce

這兩條是能夠不用的,由於 arp 對邏輯接口沒有意義。

3.2 若是你的 RS 的外部網絡接口是 eth0,那麼

echo "1">/proc/sys/net/ipv4/conf/all/arp_ignore

echo "2">/proc/sys/net/ipv4/conf/all/arp_announce

其實真正要執行的是:

echo "1">/proc/sys/net/ipv4/conf/eth0/arp_ignore

echo "2">/proc/sys/net/ipv4/conf/eth0/arp_announce

因此我我的建議把上面兩條也加到你的腳本里去,由於萬一系統裏上面兩條默認的值不是 0,那有可能 是會出問題滴。

4. LVS/DR loadbalancer(director)與 RS 爲何要在同一網段中?

從第一個問題中你們應該明白 vs/dr 是如何將請求轉發給 RS 的了吧?它是在數據鏈路層來實現的,所 以 director 必須和 RS 在同一網段裏面。

5. 爲何 director 上 eth0 接口除了 VIP 另外還要配一個 ip(即 DIP)?

5.1 若是是用了 keepalived 等工具作 HA 或者 LoadBalance,則在健康檢查時須要用到 DIP

5.2 沒有健康檢查機制的 HA 或者 Load Balance 則沒有存在的實際意義.

6. LVS/DRip_forward 須要開啓嗎?

不須要。由於 director 跟 realserver 是同一個網段,無需開啓轉發。

7. lvs/dr 裏,director 的 vip 的 netmask 不必設置爲255.255.255.255,也不須要再去 route add -host $VIP dev eth0:0

director 的 vip 原本就是要像正常的 ip 地址同樣對外通告的,不要搞得這麼特殊.

LVS 的負載調度算法 在內核中的鏈接調度算法上,IPVS 已實現瞭如下八種調度算法:

一 輪叫調度(Round-Robin Scheduling)

輪叫調度(Round Robin Scheduling)算法就是以輪叫的方式依次將請求調度不一樣的服務器, 即每次調度執行 i = (i + 1) mod n,並選出第 i 臺服務器。算法的優勢是其簡潔性,它無需記 錄當前全部鏈接的狀態,因此它是一種無狀態調度。

二 加權輪叫調度(Weighted Round-Robin Scheduling)

加權輪叫調度 (Weighted Round-Robin Scheduling)算法能夠解決服務器間性能不一的 狀況,它用相應的權值表示服務器的處理性能,服務器的缺省權值爲 1。假設服務器 A 的權值 爲 1,B 的 權值爲 2,則表示服務器 B 的處理性能是 A 的兩倍。加權輪叫調度算法是按權值的 高低和輪叫方式分配請求到各服務器。權值高的服務器先收到的鏈接,權值高的服 務器比權值 低的服務器處理更多的鏈接,相同權值的服務器處理相同數目的鏈接數。

三 最小鏈接調度(Least-Connection Scheduling)

最小鏈接調度(Least- Connection Scheduling)算法是把新的鏈接請求分配到當前鏈接數 最小的服務器。最小鏈接調度是一種動態調度算法,它經過服務器當前所活躍的鏈接數來估計 服務 器的負載狀況。調度器須要記錄各個服務器已創建鏈接的數目,當一個請求被調度到某臺 服務器,其鏈接數加 1;當鏈接停止或超時,其鏈接數減一。

四 加權最小鏈接調度(Weighted Least-Connection Scheduling)

加權最小鏈接調 度(Weighted Least-Connection Scheduling)算法是最小鏈接調度的超 集,各個服務器用相應的權值表示其處理性能。服務器的缺省權值爲 1,系統管理員能夠動態 地設置服務器的權 值。加權最小鏈接調度在調度新鏈接時儘量使服務器的已創建鏈接數和其 權值成比例。

五 基於局部性的最少連接(Locality-Based Least Connections Scheduling )

基於局部性的最少連接調度(Locality-Based Least Connections Scheduling,如下簡稱 爲 LBLC)算法是針對請求報文的目標 IP 地址的負載均衡調度,目前主要用於 Cache 集羣系統, 由於在 Cache 集羣中 客戶請求報文的目標 IP 地址是變化的。這裏假設任何後端服務器均可以 處理任一請求,算法的設計目標是在服務器的負載基本平衡狀況下,將相同目標 IP 地址的 請 求調度到同一臺服務器,來提升各臺服務器的訪問局部性和主存 Cache 命中率,從而整個集羣 系統的處理能力。LBLC 調度算法先根據請求的目標 IP 地址 找出該目標 IP 地址最近使用的服 務器,若該服務器是可用的且沒有超載,將請求發送到該服務器;若服務器不存在,或者該服 務器超載且有服務器處於其一半的工 做負載,則用「最少連接」的原則選出一個可用的服務器, 將請求發送到該服務器。

六 帶複製的基於局部性最少連接(Locality-Based Least Connections with Replication Scheduling)

帶複製的基於局部性最少連接調度(Locality-Based Least Connections with Replication Scheduling,如下簡稱爲 LBLCR)算法也是針對目標 IP 地址的負載均衡,目前主要用於 Cache 集羣系統。它與 LBLC 算法的不一樣之處是它要 維護從一個目標 IP 地址到一組服務器的 映射,而 LBLC 算法維護從一個目標 IP 地址到一臺服務器的映射。對於一個「熱門」站點的服務 請求,一臺 Cache 服務器可能會忙不過來處理這些請求。這時,LBLC 調度算法會從全部的

Cache 服務器中按「最小鏈接」原則選出一臺 Cache 服務器,映射該「熱門」站 點到這臺 Cache 服務器,很快這臺 Cache 服務器也會超載,就會重複上述過程選出新的 Cache 服務器。這樣, 可能會致使該「熱門」站點的映像會出現 在全部的 Cache 服務器上,下降了 Cache 服務器的使 用效率。LBLCR 調度算法將「熱門」站點映射到一組 Cache 服務器(服務器集合),當該「熱 門」站點的請求負載增長時,會增長集合裏的 Cache 服務器,來處理不斷增加的負載;當該「熱

門」站點的請求負載下降時,會減小集合裏的 Cache 服務器 數目。這樣,該「熱門」站點的映像 不太可能出如今全部的 Cache 服務器上,從而提供 Cache 集羣系統的使用效率。LBLCR 算法 先根據請求的目標 IP 地址找出該目標 IP 地址對應的服務器組;按「最小鏈接」原則從該服務器 組中選出一臺服務器,若服務器沒有超載,將請求發送到該服務器;若服務器超載;則按 「最 小鏈接」原則從整個集羣中選出一臺服務器,將該服務器加入到服務器組中,將請求發送到該服 務器。同時,當該服務器組有一段時間沒有被修改,將最忙的服 務器從服務器組中刪除,以降 低複製的程度。

七 目標地址散列調度(Destination Hashing Scheduling)

目標地址散列調度 (Destination Hashing Scheduling)算法也是針對目標 IP 地址的負載 均衡,但它是一種靜態映射算法,經過一個散列(Hash)函數將一個目標 IP 地址映射到一臺 服務器。目標地址散列調度算法先根據請求的目標 IP 地址,做爲散列鍵(Hash Key)從靜態 分配的散列表找出對應的服務器,若該服務器是可用的且未超載,將請求發送到該服務器,否 則返回空。

八 源地址散列調度(Source Hashing Scheduling)

源地址散列調度(Source Hashing Scheduling)算法正好與目標地址散列調度算法相反, 它根據請求的源 IP 地址,做爲散列鍵(Hash Key)從靜態分配的散列表找出對應的服務器, 若該服務器是可用的且未超載,將請求發送到該服務器,不然返回空。它採用的散列函數與目 標地址散列調度算法 的相同。它的算法流程與目標地址散列調度算法的基本類似,除了將請求 的目標 IP 地址換成請求的源 IP 地址,因此這裏不一一敘述。在實際應用中,源地址散列調度 和目標地址散列調度能夠結合使用在防火牆集羣中,它們能夠保證整個系統的惟一出入口。