負載均衡之-LVS

負載均衡用的不少,這裏對負載均衡作一個總結吧,總共包含下面幾片博文。html

  • LVS負載均衡
  • keepalived負載均衡+高可用
  • haproxy負載均衡
  • nginx負載均衡

LVS負載均衡

LVS是章文嵩博士開發的一個基於linux內核的項目,國內有着比較清晰中文描述http://www.linuxvirtualserver.org/zh/lvs1.html ,在這裏只是對這個項目作一些概述,方便查看!前端

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

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

Linux Virtual Server項目的目標 :使用集羣技術和Linux操做系統實現一個高性能、高可用的服務器,它具備很好的可伸縮性(Scalability)、可靠性(Reliability)和可管理性(Manageability)。web

在LVS框架中,提供了含有三種IP負載均衡技術的IP虛擬服務器軟件IPVS、基於內容請求分發的內核Layer-7交 換機KTCPVS和集羣管理軟件。可是咱們主要說明基於ip虛擬服務器軟件IPVS的實現!算法

ip虛擬服務器軟件ipvs有三種方式8中調度算法來實現負載均衡數據庫

LVS集羣通用體系結構

直白一點,負載均衡就是把原來一個機器乾和活,按照必定的規則分配給多個機器一塊兒工做!【單臺機器提供的計算能力是有限的】後端

在一個框架中,加入了負載均衡以後,會是怎麼樣的?bash

用戶的請求經過網絡鏈接到虛擬ip(virtual ip addresss),而後經過調度器(load balancer)把用戶的請求轉發到後端真實的服務器(real server)!整個在後端轉發的過程對用戶來講是不可見的,用戶沒必要要關心後端的轉發,只須要把請求發往對應的VIP便可!服務器

LVS的三層結構以下:

  1. 調度器,主要用來處理用戶的請求,把用戶的請求發送給後面的真實服務器!
  2. 服務器池,真實的服務器,接收來自調度器轉發的用戶請求。
  3. 共享存儲,它爲服務器池提供一個共享的存儲區,這樣很容易使得服務器池擁有相同的內容,提供相同的服務。

調度器是服務器集羣系統的惟一入口點(Single Entry Point),它能夠採用IP負載均衡技術、基於內容請求分發技術或者二者相結合。在IP負載均衡技術中,須要服務器池擁有相同的內容提供相同的服務。當 客戶請求到達時,調度器只根據服務器負載狀況和設定的調度算法從服務器池中選出一個服務器,將該請求轉發到選出的服務器,並記錄這個調度;當這個請求的其 他報文到達,也會被轉發到前面選出的服務器。在基於內容請求分發技術中,服務器能夠提供不一樣的服務,當客戶請求到達時,調度器可根據請求的內容選擇服務器 執行請求。由於全部的操做都是在Linux操做系統核心空間中將完成的,它的調度開銷很小,因此它具備很高的吞吐率。可是通常選擇的是基於IP的負載均衡技術。

服務器池的結點數目是可變的。當整個系統收到的負載超過目前全部結點的處理能力時,能夠在服務器池中增長服務器來知足不斷增加的請求負載。對大多數 網絡服務來講,請求間不存在很強的相關性,請求能夠在不一樣的結點上並行執行,因此整個系統的性能基本上能夠隨着服務器池的結點數目增長而線性增加。

共享存儲一般是數據庫、網絡文件系統或者分佈式文件系統。

LVS負載集羣中的IP負載均衡技術

ip負載均衡技術的實現主要有三種方式:

  • 經過網絡地址轉換的VS/NAT方式
  • 經過直接路由實現的VS/DR方法。
  • 經過IP隧道技術實現的VS/TUN方式

這片博客中對LVS的三種方式作了詳細的說明

VS/NAT:

就是網絡地址翻譯技術實現虛擬服務器,當用戶請求到達調度器時,調度器將請求報文的目標地址改寫成選定的real server地址,同時將報文的目標端口也改爲選定的real server的相應的端口,最後將報文請求發送到選定的real server。在服務器端獲得數據後,real server將數據返回給客戶時,須要再次通過負載調度器將報文的源地址和源端口改爲虛擬ip地址和相應的端口,而後把數據發送給用戶,完成整個負載調度過程。在整個過程當中,對用戶來講就是虛擬IP在對外提供服務,後端的轉發是不可見的!在NAT的方式下,用戶請求和響應報文都必須通過director地址重寫,當用戶請求愈來愈多時,調度器的處理能力將稱爲瓶頸!

 

VS/TUN:

在VS/NAT 的集羣系統中,請求和響應的數據報文都須要經過負載調度器,當真實服務器的數目在10臺和20臺之間時,負載調度器將成爲整個集羣系統的新瓶頸。大多數 Internet服務都有這樣的特色:請求報文較短而響應報文每每包含大量的數據。若是能將請求和響應分開處理,即在負載調度器中只負責調度請求而響應直 接返回給客戶,將極大地提升整個集羣系統的吞吐量。

IP隧道(IP tunneling)是將一個IP報文封裝在另外一個IP報文的技術,這可使得目標爲一個IP地址的數據報文能被封裝和轉發到另外一個IP地址。IP隧道技 術亦稱爲IP封裝技術(IP encapsulation)。【把用戶請求的ip報文封裝成svip報文,發給real server,而後real server直接發送響應給用戶】。

這裏請求和響應只通過了一次調度器!

 

VS/DR:

也就是用直接路由技術實現虛擬服務器。這種方式的鏈接調度和管理與前兩種同樣,但它的報文的轉發方法有所不一樣,VS/DR經過改寫請求報文的mac地址,將請求發送到real server,而real server將響應直接返回客戶端。這是三種調度算法中性能最好的,可是要求director server與real server必須由一塊網卡連在同一物理網段上。

以上是IPVS中的三種處理請求和響應的技術,上面提到,調度器利用這三種技術中的某一個把請求發送到後方的real server。那麼調度器是使用什麼樣的方式來選擇後面的real server的?總共有8種調度算法!

  1. 輪叫調度:也叫1:1調度,調度器經過輪叫調度算法將外部用戶請求順序按1:1地分配到集羣種每一個real sever種。這種算法平等地對待每一臺real server,而無論服務器上實際的負載情況和鏈接情況。
  2. 加權輪叫調度:加權輪叫調度算法根據real server的不一樣處理能力來調度訪問請求。能夠對每臺real server設置不一樣的調度權值,對性能相對較好的real server能夠設置較高的權重,而對處理能力較弱的real server,能夠設置較低的權重。這樣保證了處理能力強的服務器處理更多的訪問流量,充分合理地利用了服務器資源。同時,調度器還能夠自動查詢real server的負載狀況,並動態地調整其權值。
  3. 最少鏈接調度:調度算法動態的將網絡請求調度到已創建的鏈接數最少的服務器上。若是集羣系統的真實服務器具備相近的系統性能,採用「最少鏈接」調度算法能夠較好的均衡負載。
  4. 加權最少鏈接調度:加權最少鏈接調度,是最少鏈接調度的超集每一個服務節點能夠用相應的權重表示其處理能力,而系統管理員能夠動態地設置相應的權值,默認權值爲1.加權最小鏈接調度在分配新鏈接請求時儘量使服務節點已創建的鏈接數和其權值成正比。
  5. 基於局部性的最少連接調度(Locality-Based Least Connections Scheduling,如下簡稱爲LBLC)算法是針對請求報文的目標IP地址的負載均衡調度,目前主要用於Cache集羣系統,由於在Cache集羣中 客戶請求報文的目標IP地址是變化的。這裏假設任何後端服務器均可以處理任一請求,算法的設計目標是在服務器的負載基本平衡狀況下,將相同目標IP地址的 請求調度到同一臺服務器,來提升各臺服務器的訪問局部性和主存Cache命中率,從而整個集羣系統的處理能力。LBLC調度算法先根據請求的目標IP地址找出該目標IP地址最近使用的服務器,若該服務器是可用的且沒有超載,將請求發送到該服務器;若服務器不 存在,或者該服務器超載且有服務器處於其一半的工做負載,則用「最少連接」的原則選出一個可用的服務器,將請求發送到該服務器。
  6. 帶複製的基於局部性最少連接調度(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地址對應的服務器組;按「最小鏈接」原則從該服務器組中選出一臺服務器,若服務器沒有超載, 將請求發送到該服務器;若服務器超載;則按「最小鏈接」原則從整個集羣中選出一臺服務器,將該服務器加入到服務器組中,將請求發送到該服務器。同時,當該 服務器組有一段時間沒有被修改,將最忙的服務器從服務器組中刪除,以下降複製的程度。
  7. 目標地址散列調度(Destination Hashing Scheduling)算法也是針對目標IP地址的負載均衡,但它是一種靜態映射算法,經過一個散列(Hash)函數將一個目標IP地址映射到一臺服務器。

    目標地址散列調度算法先根據請求的目標IP地址,做爲散列鍵(Hash Key)從靜態分配的散列表找出對應的服務器,若該服務器是可用的且未超載,將請求發送到該服務器,不然返回空。
  8. 源地址散列調度(Source Hashing Scheduling)算法正好與目標地址散列調度算法相反,它根據請求的源IP地址,做爲散列鍵(Hash Key)從靜態分配的散列表找出對應的服務器,若該服務器是可用的且未超載,將請求發送到該服務器,不然返回空。它採用的散列函數與目標地址散列調度算法 的相同。

測試LVS

 後端的真實服務器咱們準備兩臺web服務以下:

#一個顯示IP地址,一個顯示主機名
[root@test1 ~]# curl 10.0.102.214 The hosname is test3 [root@test1 ~]# curl 10.0.102.204 The host ip is 10.0.102.204

在找一臺服務器做爲調度器,ip爲10.0.102.179!

須要在調度器上安裝lvs的核心模塊IPVS:

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

Ipvsadm經常使用的語法和格式以下:
ipvsadm -A|E -t|u|f virutal-service-address:port [-s scheduler] [-p [timeout]] [-M netmask]
ipvsadm -D -t|u|f virtual-service-address
ipvsadm -C
ipvsadm -R
ipvsadm -S [-n]
ipvsadm -a|e -t|u|f virtual-service-address:port -r real-server-address:port
[-g|i|m] [-w weight]
ipvsadm -d -t|u|f virtual-service-address -r real-server-address
ipvsadm -L|l [options]
ipvsadm -Z [-t|u|f virtual-service-address]
ipvsadm --set tcp tcpfin udp
ipvsadm –h
其中:
? virtual-service-address:是指虛擬服務器的IP地址,本文是192.168.60.200
? real-service-address:是指Real Server的IP地址,本文是192.168.60.132/144
? scheduler:指定調度算法
ipvsadm命令選項詳細含義以下所示:
-A (--add-service) 在內核的虛擬服務器列表中添加一條新的虛擬IP記錄。也就是增長一臺新的虛擬服務器。虛擬IP也就是虛擬服務器的IP地址。
-E (--edit-service) 編輯內核虛擬服務器列表中的一條虛擬服務器記錄
-D (--delete-service) 刪除內核虛擬服務器列表中的一條虛擬服務器記錄
-C (--clear) 清除內核虛擬服務器列表中的全部記錄
-R (--restore) 恢復虛擬服務器規則
-S (--save) 保存虛擬服務器規則,輸出爲-R 選項可讀的格式
-a (--add-server) 在內核虛擬服務器列表的一條記錄裏添加一條新的Real Server記錄。也就是在一個虛擬服務器中增長一臺新的Real Server
-e (--edit-server) 編輯一條虛擬服務器記錄中的某條Real Server記錄
-d (--delete-server) 刪除一條虛擬服務器記錄中的某條Real Server記錄
-L|-l –list 顯示內核中虛擬服務器列表
-Z (--zero) 虛擬服務器列表計數器清零(清空當前的鏈接數量等)
--set tcp tcpfin udp 設置鏈接超時值
-t 說明虛擬服務器提供的是tcp服務,此選項後面跟以下格式:
[virtual-service-address:port] or [real-server-ip:port]
-u 說明虛擬服務器提供的是udp服務,此選項後面跟以下格式:
[virtual-service-address:port] or [real-server-ip:port]
-f  fwmark 說明是通過iptables標記過的服務類型
-s   此選項後面跟LVS使用的調度算法
有這樣幾個選項: rr|wrr|lc|wlc|lblc|lblcr|dh|sh
默認的調度算法是: wlc
-p  [timeout] 在某個Real Server上持續的服務時間。也就是說來自同一個用戶的屢次請求,將被同一個Real Server處理。此參數通常用於有動態請求的操做中,timeout 的默認值爲300 秒。例如:-p 600,表示持續服務時間爲600秒。
-r 指定Real Server的IP地址,此選項後面跟以下格式:
 [real-server-ip:port]
-g (--gatewaying) 指定LVS 的工做模式爲直接路由模式(此模式是LVS 默認工做模式)
-i (-ipip) 指定LVS 的工做模式爲隧道模式
-m (--masquerading) 指定LVS 的工做模式爲NAT模式
-w (--weight) weight 指定Real Server的權值
-c (--connection) 顯示LVS目前的鏈接信息 如:ipvsadm -L -c
-L --timeout 顯示「tcp tcpfin udp」的timeout值,如:ipvsadm -L --timeout
-L --daemon 顯示同步守護進程狀態,例如:ipvsadm -L –daemon
-L  --stats 顯示統計信息,例如:ipvsadm -L –stats
-L  --rate 顯示速率信息,例如:ipvsadm -L  --rate
-L  --sort 對虛擬服務器和真實服務器排序輸出,例如:ipvsadm -L --sor

DR:直接路由調度算法

上面提到過DR的性能是最好的,首先測試DR調度算法。

在調度器上配置DR模式

首先選擇一個虛擬ip,這裏選擇爲10.0.102.110!而後再調度器上執行以下腳本:

#!/bin/bash
#開啓調度器的ip轉發功能
echo 1 >/proc/sys/net/ipv4/ip_forward ipv=/sbin/ipvsadm vip=10.0.102.110 rs1=10.0.102.214 rs2=10.0.102.204
#在eth0:0上綁定虛擬ip
ifconfig eth0:0 $vip broadcast $vip netmask 255.255.255.255 up
#添加路由規則,指定虛擬ip指向的網卡 route add
-host $vip dev eth0:0 $ipv -C $ipv -A -t $vip:80 -s rr $ipv -a -t $vip:80 -r $rs1 -g -w 1 $ipv -a -t $vip:80 -r $rs2 -g -w 1

 

執行完成以後查看內核中的虛擬地址:

#查看虛擬ip
[root@test1 ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether fa:bc:66:8d:2e:00 brd ff:ff:ff:ff:ff:ff
    inet 10.0.102.179/22 brd 10.0.103.255 scope global eth0
    inet 10.0.102.110/32 brd 10.0.102.110 scope global eth0:0
    inet6 fe80::f8bc:66ff:fe8d:2e00/64 scope link
       valid_lft forever preferred_lft forever

#查看內核中的地址列表
[root@test1 ~]# ipvsadm -L IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 10.0.102.110:http rr -> test2:http Route 1 0 0 -> test3:http Route 1 0 0

而後再後端的real server上執行以下腳本:

#!/bin/bash
vip=10.0.102.110
ifconfig lo:0 $vip broadcast $vip netmask 255.255.255.255 up
route add -host $vip lo:0
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

#這裏幾個內核參數的修改,推薦博文:https://www.cnblogs.com/lipengxiang2009/p/7451050.htm
arp_ignore和arp_announce參數都和ARP協議相關,主要用於控制系統返回arp響應和發送arp請求時的動做。這兩個參數很重要,特別是在LVS的DR場景下,它們的配置直接影響到DR轉發是否正常。
arp_ignore參數的做用是控制系統在收到外部的arp請求時,是否要返回arp響應。
  arp_ignore參數經常使用的取值主要有0,123~8較少用到:
0:響應任意網卡上接收到的對本機IP地址的arp請求(包括環回網卡上的地址),而無論該目的IP是否在接收網卡上。
1:只響應目的IP地址爲接收網卡上的本地地址的arp請求。
2:只響應目的IP地址爲接收網卡上的本地地址的arp請求,而且arp請求的源IP必須和接收網卡同網段。
3:若是ARP請求數據包所請求的IP地址對應的本地地址其做用域(scope)爲主機(host),則不迴應ARP響應數據包,若是做用域爲全局(global)或鏈路(link),則迴應ARP響應數據包。
4~7:保留未使用
8:不迴應全部的arp請求

arp_announce的做用是控制系統在對外發送arp請求時,如何選擇arp請求數據包的源IP地址。(好比系統準備經過網卡發送一個數據包a,這時數據包a的源IP和目的IP通常都是知道的,而根據目的IP查詢路由表,發送網卡也是肯定的,故源MAC地址也是知道的,這時就差肯定目的MAC地址了。而想要獲取目的IP對應的目的MAC地址,就須要發送arp請求。arp請求的目的IP天然就是想要獲取其MAC地址的IP,而arp請求的源IP是什麼呢? 可能第一反應會覺得確定是數據包a的源IP地址,可是這個也不是必定的,arp請求的源IP是能夠選擇的,控制這個地址如何選擇就是arp_announce的做用)
  arp_announce參數經常使用的取值有0,120:容許使用任意網卡上的IP地址做爲arp請求的源IP,一般就是使用數據包a的源IP。
1:儘可能避免使用不屬於該發送網卡子網的本地地址做爲發送arp請求的源IP地址。
2:忽略IP數據包的源IP地址,選擇該發送網卡上最合適的本地地址做爲arp請求的源IP地址。
  sysctl.conf中包含all和eth/lo(具體網卡)的arp_ignore參數,取其中較大的值生效。
arp兩個參數說明

在另一臺服務器測試:【由於是輪叫調度,因此會依次出現】

[root@mgt01 ~]# curl 10.0.102.110
The host ip is 10.0.102.204
[root@mgt01 ~]# curl 10.0.102.110
The hosname is test3
[root@mgt01 ~]# curl 10.0.102.110
The host ip is 10.0.102.204
[root@mgt01 ~]# curl 10.0.102.110
The hosname is test3

 這裏對兩個real server的權重設置都爲1!能夠在命令更改!

強烈建議手動使用下這個ipvsadm命令,有點意思!上面默認調度算法爲rr,咱們修改默認調度算法爲WRR,而後更改204的權重爲3!

[root@test1 ~]# ipvsadm -E -t 10.0.102.110:80 -s wrr              #修改調度算法爲wrr
[root@test1 ~]# ipvsadm -e -t 10.0.102.110:80  -r 10.0.102.204:80 -g -w 3       #修改204的權重爲3
[root@test1 ~]# ipvsadm -L
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.0.102.110:http wrr
  -> test2:http                   Route   3      0          5         
  -> test3:http                   Route   1      0          5         
[root@test1 ~]#

測試:

[root@mgt01 ~]# curl 10.0.102.110
The host ip is 10.0.102.204
[root@mgt01 ~]# curl 10.0.102.110
The host ip is 10.0.102.204
[root@mgt01 ~]# curl 10.0.102.110
The host ip is 10.0.102.204
[root@mgt01 ~]# curl 10.0.102.110
The hosname is test3
[root@mgt01 ~]# curl 10.0.102.110
The host ip is 10.0.102.204
[root@mgt01 ~]# curl 10.0.102.110
The host ip is 10.0.102.204
[root@mgt01 ~]# curl 10.0.102.110
The host ip is 10.0.102.204
[root@mgt01 ~]# curl 10.0.102.110
The hosname is test3

LVS的NAT方式

準備環境:調度器上須要兩個網卡,一個內網網址10.0.102.179,一個外網的ip(10.0.102.110須要對外通訊)。

    兩個real server: 10.0.102.204, 10.0.102.214.

    切記須要把real server的網關設置爲調度器的內網IP。

在調度器作以下設置:

#!/bin/bash
#director服務器上開啓路由轉發功能
echo 1 >/proc/sys/net/ipv4/ip_forward

#關閉icmp重定向
echo 0 >/proc/sys/net/ipv4/conf/all/send_redirects
echo 0 >/proc/sys/net/ipv4/conf/default/send_redirects
echo 0 >/proc/sys/net/ipv4/conf/eth0/send_redirects
#echo 0 >/proc/sys/net/ipv4/conf/eth1/send_redirects

#設置nat防火牆
iptables -t nat -F
iptables -t nat -X
iptables -t nat -A POSTROUTING -s 10.0.100.0/26 -j MASQUERADE
#注意這裏防火牆規則源ip設置
#director設置ipvsadm
IPVSADM='/sbin/ipvsadm'
$IPVSADM -C
$IPVSADM -A -t 10.0.102.110:80 -s wrr 
$IPVSADM -a -t 10.0.102.110:80 -r 10.0.102.204:80 -m -w 3
$IPVSADM -a -t 10.0.102.110:80 -r 10.0.102.214:80 -m -w 2

設置完成以後進行測試!

nat模式沒有配通,網絡方面不太懂哎,可是以前配經過一次!

線上的環境大多使用的DR模式!

keepalive配置

在上面DR模式中,若是調度器換掉,那麼整個集羣就會宕掉,所以咱們須要對調度器作高可用。在這裏咱們選擇使用keepalive作高可用!

在作高可用的時候,還會用到另一個HA軟件heartbeat,這兩個軟件雖然有不少類似之處,可是也有些不一樣!

heartbeat與keepalive的異同:

Keepalived使用的vrrp協議方式,虛擬路由冗餘協議 (Virtual Router Redundancy Protocol,簡稱VRRP);

Heartbeat是基於主機或網絡的服務的高可用方式;

keepalived的目的是模擬路由器的雙機

heartbeat的目的是用戶service的雙機

lvs的高可用建議用keepavlived

業務的高可用用heartbeat

keepalived工做原理

keepalived是以VRRP協議爲實現基礎的,VRRP全稱Virtual Router Redundancy Protocol,即虛擬路由冗餘協議

虛擬路由冗餘協議,能夠認爲是實現路由器高可用的協議,即將N臺提供相同功能的路由器組成一個路由器組,這個組裏面有一個master和多個backup,master上面有一個對外提供服務的vip(該路由器所在局域網內其餘機器的默認路由爲該vip),master會發組播,當backup收不到vrrp包時就認爲master宕掉了,這時就須要根據VRRP的優先級選舉一個backup當master。這樣的話就能夠保證路由器的高可用了。

keepalived主要有三個模塊,分別是core、check和vrrp。core模塊爲keepalived的核心,負責主進程的啓動、維護以及全局配置文件的加載和解析。check負責健康檢查,包括常見的各類檢查方式。vrrp模塊是來實現VRRP協議的。

配置keepalived的高可用

後臺真實的服務器地址爲: 10.0.102.204和10.0.102.214

兩臺作高可用的服務器爲:10.0.102.179和10.0.102.221

在LVS架構中,就是對調度器作高可用,在兩臺調度器上面安裝keepalived!

yum install -y keepalived

分析一個keepalived的配置文件:

1:有一個全局配置部分

! Configuration File for keepalived

global_defs {
   notification_email {            #故障發生時經過email發給誰
     acassen@firewall.loc
     failover@firewall.loc
     sysadmin@firewall.loc
   }
   notification_email_from Alexandre.Cassen@firewall.loc  #發郵件時候,發件地址
   smtp_server 192.168.200.1                              #smtp服務器地址
   smtp_connect_timeout 30                                #smtp鏈接超時時間設置
   router_id LVS_DEVEL                                    #標識做用,發郵件時會用到
}

虛擬路由冗餘協議配置部分:

vrrp_instance VI_1 {
    state MASTER                     #當前服務器的角色,master或者backup
    interface eth0                   #網卡
    virtual_router_id 51             #虛擬路由id
    priority 100                     #權重
    advert_int 1
    authentication {                #一些認證信息
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {             #虛擬ip的信息
        192.168.200.16
        192.168.200.17
        192.168.200.18
    }
}

虛擬IP對應的真實服務器信息:

virtual_server 172.16.100.196 80 {        #虛擬ip
    delay_loop 6
    lb_algo rr                           #調度算法
    lb_kind DR                           #轉發方式
    persistence_timeout 0
    protocol TCP

    real_server 172.16.100.190 80 {
        weight 100
    TCP_CHECK {
        connect_timeout 10
        nb_get_retry 3
        delay_before_retry 3
        connect_port 80
    }
    }
   real_server 172.16.100.191 80 {
        weight 100
        TCP_CHECK {
                connect_timeout 10
        nb_get_retry 3
        delay_before_retry 3
        connetc_port 80
        }
    }
}

修改keepalived的配置文件,以下!

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 59
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        10.0.102.110
    }
}

virtual_server 10.0.102.110 80 {
    delay_loop 6
    lb_algo rr
    lb_kind DR
    persistence_timeout 0
    protocol TCP

    real_server 10.0.102.214 80 {
        weight 100
    TCP_CHECK {
        connect_timeout 10
        nb_get_retry 3
        delay_before_retry 3
        connect_port 80
    }
    }
   real_server 10.0.102.204 80 {
        weight 100
        TCP_CHECK {
                connect_timeout 10
        nb_get_retry 3
        delay_before_retry 3
        connetc_port 80
        }
    }
}

而後把配置文件拷貝到從上,作以下修改!
state MASTER  #在從上把master修改成BACKUP
priority 100  #把從上的權重設置的低於主,這裏也就是設置的低於100

而後開啓端口轉發功能!
 echo 1 > /proc/sys/net/ipv4/ip_forward
 #主從上都要執行!

在real server上執行以下腳本,腳本內容和上面作LVS時的內容是同樣的!

#!/bin/bash
vip=10.0.102.110
ifconfig lo:0 $vip broadcast $vip netmask 255.255.255.255 up
route add -host $vip lo:0
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

而後就能夠模仿當前的master掛掉,測試是否能夠訪問後面的真實server!

使用keepalive測的時候,一個客戶端的訪問會重定向到某一個real server,以下這個服務器訪問一直都是同一個服務器。

[root@test3 ~]# curl 10.0.102.110
The hosname is test3
[root@test3 ~]# curl 10.0.102.110
The hosname is test3
[root@test3 ~]# curl 10.0.102.110
The hosname is test3
[root@test3 ~]# curl 10.0.102.110
The hosname is test3
[root@test3 ~]# curl 10.0.102.110
The hosname is test3
[root@test3 ~]# curl 10.0.102.110
The hosname is test3
[root@test3 ~]# curl 10.0.102.110
The hosname is test3
[root@test3 ~]# curl 10.0.102.110
The hosname is test3
[root@test3 ~]# curl 10.0.102.110
The hosname is test3
[root@test3 ~]# curl 10.0.102.110
The hosname is test3

換一臺服務器訪問:

[root@test2 ~]# curl 10.0.102.110
The host ip is 10.0.102.204
[root@test2 ~]# curl 10.0.102.110
The host ip is 10.0.102.204
[root@test2 ~]# curl 10.0.102.110
The host ip is 10.0.102.204
[root@test2 ~]# curl 10.0.102.110
The host ip is 10.0.102.204
[root@test2 ~]# curl 10.0.102.110
The host ip is 10.0.102.204
[root@test2 ~]# curl 10.0.102.110
The host ip is 10.0.102.204
[root@test2 ~]# curl 10.0.102.110
The host ip is 10.0.102.204
[root@test2 ~]# curl 10.0.102.110
The host ip is 10.0.102.204

貌似是作了hash同樣!

 

最後須要說的是,keepalived調用了內核中的LVS功能,所以能夠作負載均衡,而keepalived自己是做爲高可用使用的;在MHA集羣作VIP漂移時,咱們測試了僅使用keepalived做爲高可用軟件!http://www.javashuo.com/article/p-hkzjkgni-m.html

相關文章
相關標籤/搜索