LVS的DR模式中的負載均衡及高可用
**
一 LVS的三種IP負載均衡技術比較
** 我們先分析實現虛擬網路服務的主要技術，指出IP負載均衡技術是在負載排程器的實現技術中效率最高的。在已有的IP負載均衡技術中，主要有通過網路地址轉換（Network Address Translation）將一組伺服器構成一個高效能的、高可用的虛擬伺服器，我們稱之為VS/NAT技術（Virtual Server via Network Address Translation）。在分析VS/NAT的缺點和網路服務的非對稱性的基礎上，我們提出了通過IP隧道實現虛擬伺服器的方法VS/TUN （Virtual Server via IP Tunneling），和通過直接路由實現虛擬伺服器的方法VS/DR（Virtual Server via Direct Routing），它們可以極大地提高系統的伸縮性。VS/NAT、VS/TUN和VS/DR技術是LVS叢集中實現的三種IP負載均衡技術。 下面是這三種IP負載均衡技術的優缺點
注:以上三種方法所能支援最大伺服器數目的估計是假設排程器使用 100M 網絡卡,排程器的硬體配置與後端伺服器的硬體配置相同,而且是對一般 Web 服 務。使用更高的硬體配置(如千兆網絡卡和更快的處理器)作為排程器,排程器所能排程的伺服器數量會相應增加。當應用不同時,伺服器的數目也會相應地改變。所 以,以上資料估計主要是為三種方法的伸縮性進行量化比較。
VS/NAT VS/NAT 的優點是伺服器可以執行任何支援 TCP/IP 的作業系統,它只需要一個 IP 地址配置在排程器上, 伺服器組可以用私有的 IP 地址。缺點是它的伸縮能力有限, 當伺服器結點數目升到 20 時,排程器本身 有可能成為系統的新瓶頸,因為在 VS/NAT 中請求和響應報文都需要通過負載排程器。 VS/TUN VS/TUN 技術對伺服器有要求,即所有的伺服器必須支援 “ IP Tunneling” 或者 “ IPEncapsulation”協議。目前,VS/TUN 的後端伺服器主要執行 Linux 作業系統。在 VS/TUN 的集群系統中,負載排程器只將請求排程到不同的後端伺服器,後端伺服器將應答的資料直接返回給使用者。這樣,負載排程器就可以處理大量的請求,它甚至可以調 度百臺以上的伺服器(同等規模的伺服器),而它不會成為系統的瓶頸。即使負載排程器只有 100Mbps的全雙工網絡卡,整個系統的最大吞吐量可超過 1Gbps。所以,VS/TUN 可以極大地增加負載排程器排程的伺服器數量。VS/TUN 排程器可以排程上百臺伺服器,而它本身不會成為系統的瓶 頸,可以 用來構建高效能的超級伺服器。 VS/DR 跟 VS/TUN 方法相同,負載排程器中只負責排程請求,而伺服器直接將響應返回給客戶,可以極大地提 高整個集群系統的吞吐量。跟 VS/TUN 相比,這種方法沒有 IP 隧道的開銷,但排程器和伺服器組都必 須在物理上有一個網絡卡通過不分斷的區域網相連,如通過交換機或者高速的 HUB 相連。VIP 地址為調 度器和伺服器組共享,排程器配置的 VIP 地址是對外可見的,用於接收虛擬服務的請求報文;所有的服 務器把 VIP 地址配置在各自的 Non-ARP 網路裝置上,它對外面是不可見的,只是用於處 理目標地址為 VIP 的網路請求。
**
二 lvs的DR模式
**
下面用圖文的方式中介紹一下DR模式
1 client 向目標 vip 發出請求,Director 接收。
2 VS 根據負載均衡演算法選擇一臺 active 的 realserver(假設是 172.25.1.3),將此 RIP 所在網
卡的 mac 地址作為目標 mac 地址,傳送到局域網裡。
3 realserver(172.25.1.3)在區域網中收到這個幀,拆開後發現目標 IP(VIP)與本地匹配,於是
處理這個報文。隨後重新封裝報文,傳送到區域網。
4 注意的問題： vs/dr 本身不會關心 IP 層以上的資訊,即使是埠號也是 tcp/ip 協議棧去判斷是否正確,vs/dr 本 身主要做這麼幾個事: 1)接收 client 的請求,根據你設定的負載均衡演算法選取一臺 realserver 的 ip; 2)以選取的這個 ip 對應的 mac 地址作為目標 mac,然後重新將 IP 包封裝成幀轉發給這臺 RS; 3)在 hashtable 中記錄連線資訊。 vs/dr 做的事情很少,也很簡單,所以它的效率很高,不比硬體負載均衡裝置差多少。 資料包、資料幀的大致流向是這樣的:client –> VS –> RS –> client vs主要作為目標地址mac地址轉發而這一過程在資料鏈路層來實現的,所以 director 必須和 RS 在同一網段裡面。
2 實驗測試：
2.1 環境介紹
Load Balance:172.25.1.2
Virtual IP: 172.25.1.100
Realserver1: 172.25.1.3
Realserver1: 172.25.1.4
2.2實驗步驟
1）安裝ipvsadm
1 既然要讓 RS 能夠處理目標地址為 vip 的 IP 包,首先必須要讓 RS 能接收到這個包。
在 lo 上配置 vip 能夠完成接收包並將結果返回 client。
2 答案是不可以將 VIP 設定在出口網絡卡eth0上,否則會響應客戶端的 arp request,造成 client/gateway
arp table 紊亂,以至於整個 loadbalance 都不能正常工作。arptables -A IN -d 172.25.1.100 -j DROP 將所有訪問172.25.1.100的請求都丟棄
arptables -A OUT -s 172.25.1.100 -j mangle –mangle-ip-s 172.25.1.4 將172.25.1.100地址的轉為目標地址172.25.1.4向外發出
arptables -nL 輸出地址檢視策略
安裝httpd服務更好展現實驗效果
yum install httpd -y
編寫httpd釋出檔案
vim /var/www/html/index.html
virtual=172.25.1.100:80
real=172.25.1.3:80 gate
real=172.25.1.4:80 gate
fallback=127.0.0.1:80 gate
service=http
scheduler=rr
#persistent=600
#netmask=255.255.255.255
protocol=tcp
checktype=negotiate
checkport=80
request="index.html"
#receive="Test Page" #必須要註釋掉
#virtualhost=www.x.y.z
/etc/init.d/ldirectord reload /etc/init.d/ldirectord restart 5）為了看出ldirectord的工作模式，把rs上手動新增的vip手動去掉 ip addr del 172.25.1.100/32 dev lo 只要你重新啟動服務就可以看見ip會繼續出現lo介面上 6）這個時候假如你done掉rs一個web，你在排程器上檢視策略
! Configuration File for keepalived
global_defs {
notification_email {
root@localhost
}
notification_email_from keepalived@localhost
smtp_server 127.0.0.1 #設定 smtp server 地址
smtp_connect_timeout 30 #設定連線 smtp 伺服器超時時間
router_id LVS_DEVEL #load balancer 的標識 ID,用於 email 警報
vrrp_skip_check_adv_addr
#vrrp_strict
vrrp_garp_interval 0
vrrp_gna_interval 0
}
vrrp_instance VI_1 {
state MASTER #備機改為 BACKUP,此狀態是由 priority 的值來決定的,當前
#priority 的值小於備機的值,那麼將會失去 MASTER 狀態
interface eth0 #HA 監測網路介面
virtual_router_id 51 #主、備機的 virtual_router_id 必須相同,取值 0-255
priority 100 #主機的優先順序,備份機改為 50,主機優先順序一定要大於備機
advert_int 1 #主備之間的通告間隔秒數
authentication { #主備切換時的驗證
auth_type PASS #設定驗證型別,主要有 PASS 和 AH 兩種
auth_pass 1111 #設定驗證密碼,在一個 vrrp_instance 下,MASTER 與 BACKUP 必
#須使用相同的密碼才能正常通訊
}
virtual_ipaddress { #設定虛擬 IP 地址,可以設定多個虛擬 IP 地址,每行一個
172.25.1.100
}
}
virtual_server 172.25.1.100 80 { #定義虛擬伺服器
delay_loop 6 #每隔 6 秒查詢 realserver 狀態
lb_algo rr #lvs 排程演算法,這裡使用輪叫
lb_kind DR LVS 是用 DR 模式
#persistence_timeout 50 #會話保持時間,單位是秒,這個選項對於動態網頁是非常有
用的,為集群系統中 session 共享提供了一個很好的解決方案。有了這個會話保持功能,使用者的
請求會被一直分發到某個服務節點,直到超過這個會話保持時間。需要注意的是,這個會話保
持時間,是最大無響應超時時間,也就是說使用者在操作動態頁面時,如果在 50 秒內沒有執行任
何操作,那麼接下來的操作會被分發到另外節點,但是如果一直在操作動態頁面,則不受 50 秒
的時間限制。
protocol TCP #指定轉發協議型別,有 tcp 和 udp 兩種
real_server 172.25.1.3 80 { #配置服務節點
weight 1 #配置服務節點的權值,權值大小用數字表示,數字越大,權
值越高,設定權值的大小可以為不同效能的伺服器分配不同的負載,可以對效能高的伺服器設
置較高的權值,而對效能較低的伺服器設定相對較低的權值,這樣就合理的利用和分配了系統
資源
TCP_CHECK { #realserve 的狀態檢測設定部分,單位是秒
connect_timeout 3 #10 秒無響應超時
retry 3 #重試次數
delay_before_retry 3 #重試間隔
}
}
real_server 172.25.1.4 80 {
weight 1
TCP_CHECK {
connect_timeout 3
retry 3
delay_before_retry 3
}
}
}
3）增加一臺排程器伺服器作如下的配置
! Configuration File for keepalived
global_defs {
notification_email {
root@localhost
}
notification_email_from keepalived@localhost
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id LVS_DEVEL
vrrp_skip_check_adv_addr
#vrrp_strict
vrrp_garp_interval 0
vrrp_gna_interval 0
}
vrrp_instance VI_1 {
state BACKUP
interface eth0
virtual_router_id 51
priority 50
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
172.25.1.100
}
}
virtual_server 172.25.1.100 80 {
delay_loop 6
lb_algo rr
lb_kind DR
#persistence_timeout 50
protocol TCP
real_server 172.25.1.3 80 {
weight 1
TCP_CHECK {
connect_timeout 3
retry 3
delay_before_retry 3
}
}
real_server 172.25.1.4 80 {
weight 1
TCP_CHECK {
connect_timeout 3
retry 3
delay_before_retry 3
}
}
}
/etc/init.d/keepalived reload /etc/init.d/keepalived restart 4 )高可用測試:停止 master 上的 keepalived 服務,會發現客戶端仍然可以訪問。