18.11 LVS DR模式搭建

<table>
<tr>
<th></th>
<th>名稱</th>
<th>IP</th>
<th>系統</th>
</tr>
<tr>
<td rowspan="4">三臺主機</td>
<td>分發器/dr</td>
<td>172.16.22.220</td>
<td rowspan="4">centos7.3</td>
</tr>
<tr>
<td>rs1</td>
<td>172.16.22.221</td>
</tr>
<tr>
<td>rs2</td>
<td>172.16.22.222</td>
</tr>
<tr>
<td>rs3</td>
<td>172.16.22.223</td>
</tr>
</table>
ipvsadm的安裝略

配置

vim /usr/local/sbin/lvs_dr.sh

#!/bin/bash
echo 1 > /proc/sys/net/ipv4/ip_forward
ipv=/usr/sbin/ipvsadm
vip=172.16.22.219
rs1=172.16.22.221
rs2=172.16.22.222
#注意這裏的網卡名字
ifconfig eth0:2 $vip broadcast $vip netmask 255.255.255.255 up
route add -host $vip dev eth0:2
$ipv -C
$ipv -A -t $vip:80 -s wrr
$ipv -a -t $vip:80 -r $rs1:80 -g -w 1
$ipv -a -t $vip:80 -r $rs2:80 -g -w 1

chmod +x !$  #對腳本添加執行權限
!$  #運行腳本

(1)ARP響應行爲和ARP解析行爲內核參數：
1)arp_annouce定義通告級別
0：默認級別，將本地的任何接口上的配置的地址都在網絡中通告
1：儘量避免向本主機上的其他網卡進行網絡通信，特殊情況下其他接口也可以
2：總是使用最佳網絡地址接口(僅使用定義的網卡接口在同網絡通信)
2)arp_ignore定義響應級別(0-8九個級別)，響應時忽略方式
0：都全都響應
1：只對從本接口進入的請求響應，且本接口地址是個網絡地址
… …
註釋：一般使用arp_annouce=2，arp_ignore=1

rs1、rs2腳本

vim /usr/local/sbin/lvs_rs.sh

#!/bin/bash
vip=172.16.22.219
#把vip綁定在lo上，是爲了實現rs直接把結果返回給客戶端
ifconfig lo:0 $vip broadcast $vip netmask 255.255.255.255 up
route add -host $vip lo:0
#以下操作爲更改arp內核參數，目的是爲了讓rs順利發送mac地址給客戶端
#參考文檔www.cnblogs.com/lgfeng/archive/2012/10/16/2726308.html
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

chmod +x !$  #對腳本添加執行權限

!$ #運行腳本
運行剛纔建立的shell腳本，dr,rs1,rs2都要運行各自的腳步

測試：

curl -I 172.16.22.219

~ Aiker$ curl -I 172.16.22.219
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 28 Mar 2018 14:42:09 GMT
Content-Type: text/html
Content-Length: 1326
Last-Modified: Wed, 26 Apr 2017 08:03:46 GMT
Connection: keep-alive
Vary: Accept-Encoding
ETag: "59005462-52e"
Accept-Ranges: bytes

~ Aiker$ curl -I 172.16.22.219
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Wed, 28 Mar 2018 14:42:14 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
X-Powered-By: PHP/5.6.34
location: forum.php

[root@test220 ~]# 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.16.22.219:80 wrr
  -> 172.16.22.221:80             Route   1      2          0         
  -> 172.16.22.222:80             Route   1      2          0         
[root@test220 ~]# 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.16.22.219:80 wrr
  -> 172.16.22.221:80             Route   1      5          0         
  -> 172.16.22.222:80             Route   1      6          0

通過防火牆標記來定義lvs
1.FWM防火牆標記功能
防火牆標記可以實現多個集羣服務綁定爲同一個，實現統一調度；將共享一組RS的集羣服務統一進行定義
FWM基於iptables的mangle表實現防護牆標記功能，定義標記做策略路由

2.FWM定義集羣的方式
(1)在director上netfilter的mangle表的PREROUTING定義用於"打標"的規則

[root@test220~]#iptables -t mangle -A PREROUTING -d $vip -p $protocol --dport $port -j MARK--set-mark #

$vip:VIP地址
$protocol：協議
$port:協議端口

(2)基於FWM定義集羣服務：

[root@test220~]#ipvsadm -A -f # -s scheduler

3.實例演示

[root@test220~]# iptables -t mangle -A PREROUTING -d 172.16.22.219 -p tcp --dport 80 -j MARK--set-mark 5
[root@test220~]# ipvsadm -A -f 5 -s rr
[root@test220~]# ipvsadm -a -f 5 -r 172.16.22.221 -g
[root@test220~]# ipvsadm -a -f 5 -r 172.16.22.222 -g

LVS持久連接功能：lvs persistence

1.lvs persistence功能
無論ipvs使用何種scheduler，其都能夠實現在指定時間範圍內始終將來自同一個ip地址的請求發往同一個RS；實現方式和lvs調度的十種算法無關，通過lvs持久連接模板(hash表)實現，當超過自定義的可持節連接時長候再根據LVS算法本身進行調度。
ipvsadm命令中-p選項實現，在-p後不指定具體數字(單位:秒)，默認爲300，到時候會自動延長2分鐘，對於web本身就是15秒

2.模式
(1)每端口持久(PPC)
客戶端對同一服務端口發起請求，會基於該服務的端口實現請求在一段時間內對同一RS服務器持久連接；
例如：有兩臺主機做爲RS服務器做http和hssh的兩種服務的集羣，僅http做每端口持久，Client請求會實現綁定在，但是22號端口請求不會綁定在同一臺RS
(2)每客戶端持久(PCC)：定義tcp或udp協議的0號端口爲集羣服務端口
director會將用戶的任何請求都識別爲集羣服務，並向RS進行調度；同一客戶端的請求任何端口都發往同一臺第一次選定的RS服務器
(3)每防火牆標記持久(PFWMC)
將兩個或兩個以上服務通過防火牆打標綁定在一起，這些服務的請求實現同時定向與同一臺RS服務器，服務綁定同一RS

實例：

lvs-dr模式下以rr算法綁定http和https服務

[root@test220~]# iptables -t mangle -A PREROUTING -d 172.16.22.220 -p tcp --dport 80 -j MARK--set-mark 99
[root@test220~]# iptables -t mangle -A PREROUTING -d 172.16.22.220 -p tcp --dport 443 -j MARK--set-mark 99
[root@test220~]# ipvsadm -A -f 99 -s rr -p
[root@test220~]# ipvsadm -a -f 99 -r 172.16.22.221 -g
[root@test220~]# ipvsadm -a -f 99 -r 172.16.22.222 -g

附錄：LVS-DR類型RS腳本示例

#!/bin/bash
vip=172.16.22.219
interface="lo:0"
case$1 in
start)
echo1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo2 > /proc/sys/net/ipv4/conf/all/arp_announce
echo2 > /proc/sys/net/ipv4/conf/lo/arp_announce
ifconfig$interface $vip broadcast $vip netmask 255.255.255.255 up
routeadd -host $vip dev $interface
;;
stop)
echo0 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo0 > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo0 > /proc/sys/net/ipv4/conf/all/arp_announce
echo0 > /proc/sys/net/ipv4/conf/lo/arp_announce
ifconfig$interface down
;;
status)
ififconfig lo:0 |grep $vip &> /dev/null; then
echo"ipvs is running."
else
echo"ipvs is stopped."
fi
;;
*)
echo"Usage: `basename $0` {start|stop|status}"
exit1
esac

18.12 keepalived + LVS

完整架構需要兩臺服務器（角色爲dir）分別安裝keepalived軟件，目的是實現高可用，但keepalived本身也有負載均衡的功能，所以本次實驗可以只安裝一臺keepalived

爲什麼需要把keepalived 加到lvs 中的目的是什麼
第一個原因：lvs有個分發器角色，如果宕掉以後，後端的rs就沒有辦法繼續使用，所以需要用keepalived做一個高可用，
第二個原因：在使用lvs的時候，當後端有一臺rs機器宕機時，lvs照樣會分發數據到這臺宕機機器，這是就會出現訪問無效的情況，說明lvs並不聰明；這時使用keepalived，就可以保證集羣中其中一臺rs宕機了，web還能正常提供，不會出現用戶訪問時無效鏈接的結果；一般這種架構，肯定是2臺keepalived；

因爲keepalived內置了ipvsadm的功能，所以不再需要安裝ipvsadm的包，也不用再編寫和執行.sh腳本準備工作三臺機器分別爲：	主機	IP
dir（安裝keepalived）	172.16.22.200
rs1	172.16.22.221
rs2	172.16.22.222
vip	172.16.22.219

卸載掉ipvmsamd 清空ipvsadm規則
ipvsadm -C
查看一下ipvsadm的規則

[root@test01 ~]# ipvsadm -C

[root@test01 ~]# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
[root@test01 ~]#

清除之前配置的IP
sytemctl restart network

編輯keepalived配置文件 vim /etc/keepalived/keepalived.conf
參考配置：

vrrp_instance VI_1 {
    #備用服務器上爲 BACKUP
    state MASTER
    #綁定vip的網卡爲eth0，你的網卡可能不一樣，這裏需要你改一下
    interface eth0
    virtual_router_id 51
    #備用服務器上爲90
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass test123
    }
    virtual_ipaddress {
        172.16.22.219
    }
}
virtual_server 172.16.22.219 80 {
    #(每隔10秒查詢realserver狀態)
    delay_loop 10
    #(lvs 算法)
    lb_algo wlc
    #(DR模式)
    lb_kind DR
    #(同一IP的連接60秒內被分配到同一臺realserver)
    persistence_timeout 60
    #(用TCP協議檢查realserver狀態)
    protocol TCP

    real_server 172.16.22.221 80 {
        #(權重)
        weight 100
        TCP_CHECK {
        #(10秒無響應超時)
        connect_timeout 10
        nb_get_retry 3
        delay_before_retry 3
        connect_port 80
        }
    }
    real_server 172.16.22.222 80 {
        weight 100
        TCP_CHECK {
        connect_timeout 10
        nb_get_retry 3
        delay_before_retry 3
        connect_port 80
        }
     }
}

需要更改裏面的ip信息
先嚐試關閉rs2 test03的 nginx

[root@test03 ~]# systemctl stop nginx
[root@test03 ~]# ps aux |grep nginx
root       4956  0.0  0.0 112680   980 pts/0    S+   23:59   0:00 grep --color=auto nginx
[root@test03 ~]#

[root@test01 ~]# vim /etc/keepalived/keepalived.conf

vrrp_instance VI_1 {
    #備用服務器上爲 BACKUP
    interface eth0 
    virtual_router_id 51
    priority 100 
    advert_int 1 
    authentication {
        auth_type PASS
        172.16.22.219
    virtual_router_id 51
    #備用服務器上爲90
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass test123
    }
    virtual_ipaddress {
        172.16.22.219
    }   
}   
virtual_server 172.16.22.219 80 {
    #(每隔10秒查詢realserver狀態) 
    delay_loop 10 
    #(lvs 算法)
    lb_algo wlc
    #(DR模式)
    lb_kind DR
    #(同一IP的連接60秒內被分配到同一臺realserver)
    persistence_timeout 0 
    #(用TCP協議檢查realserver狀態)
    protocol TCP 
    real_server 172.16.22.221 80 {
        #(權重) 
        weight 100
        TCP_CHECK {
        #(10秒無響應超時)
        connect_timeout 10
        nb_get_retry 3
        delay_before_retry 3
        connect_port 80
        }
    }   
    real_server 172.16.22.222 80 {
        weight 100
        TCP_CHECK {
        connect_timeout 10
        nb_get_retry 3
        delay_before_retry 3
        connect_port 80
        }
     }
}

:wq   
[root@test01 ~]# vim /etc/keepalived/keepalived.conf

開啓keepalived 服務,看看進程

[root@test01 ~]# systemctl start keepalived
[root@test01 ~]# 
[root@test01 ~]# ps aux |grep keep
root      25759  0.0  0.0 112680   980 pts/2    R+   23:47   0:00 grep --color=auto keep
root     124427  0.0  0.1 120720  1400 ?        Ss   20:01   0:01 /usr/sbin/keepalived -D
root     124428  0.0  0.2 120720  2756 ?        S    20:01   0:01 /usr/sbin/keepalived -D
root     124429  0.0  0.2 124976  2760 ?        S    20:01   0:10 /usr/sbin/keepalived -D
[root@test01 ~]#

看下ip

[root@test01 ~]# ip add
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    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 00:0c:59:4f:28:e2 brd ff:ff:ff:ff:ff:ff
    inet 172.16.22.200/22 brd 172.16.23.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 172.16.22.219/32 brd 172.16.22.219 scope global eth0:2
       valid_lft forever preferred_lft forever
    inet 172.16.22.223/22 brd 172.16.23.255 scope global secondary eth0:0
       valid_lft forever preferred_lft forever

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:0c:59:4f:28:ec brd ff:ff:ff:ff:ff:ff
    inet 192.168.133.147/24 brd 192.168.133.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet 192.168.133.128/24 brd 192.168.133.255 scope global secondary dynamic eth1
       valid_lft 1433sec preferred_lft 1433sec

[root@test01 ~]#

查看下啓動後的規則

[root@test01 ~]# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  172.16.22.219:80 wlc
  -> 172.16.22.221:80           Route   100    0          0         
  -> 172.16.22.222:80           Route   100    0          0         
[root@test01 ~]#

停掉keepalived服務再看下就沒有規則了

[root@test01 ~]# systemctl stop keepalived
[root@test01 ~]# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
[root@test01 ~]#

再啓動keepalived 再看就有了

[root@test01 ~]# systemctl start keepalived
[root@test01 ~]# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  172.16.22.219:80 wlc
  -> 172.16.22.221:80           Route   100    0          0         
  -> 172.16.22.222:80           Route   100    0          0         
[root@test01 ~]#

同時還需要做兩點
1.打開dir機器的端口轉發

echo 1 > /proc/sys/net/ipv4/ip_forward   //打開端口轉發
2.運行前一章在rs機器上創建的lvs_rs.sh腳本 
#把vip綁定在lo上，是爲了實現rs直接把結果返回給客戶端
ifconfig lo:0 $vip broadcast $vip netmask 255.255.255.255 up
route add -host $vip lo:0
#以下操作爲更改arp內核參數，目的是爲了讓rs順利發送mac地址給客戶端
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

總結：
keepalived 有一個比較好的功能，可以在一臺rs宕機的時候，及時把他踢出 ipvsadm 集羣，將不再發送數據包給，也就很好的避免的訪問無連接的情況發送

擴展

haproxy+keepalived

http://blog.csdn.net/xrt95050/article/details/40926255
軟件負載均衡一般通過兩種方式來實現：基於操作系統的軟負載實現和基於第三方應用的軟負載實現。LVS就是基於Linux操作系統實現的一種軟負載，HAProxy就是開源的並且基於第三應用實現的軟負載。

HAProxy相比LVS的使用要簡單很多，功能方面也很豐富。當前，HAProxy支持兩種主要的代理模式:"tcp"也即4層（大多用於郵件服務器、內部協議通信服務器等），和7層（HTTP）。在4層模式下，HAProxy僅在客戶端和服務器之間轉發雙向流量。7層模式下，HAProxy會分析協議，並且能通過允許、拒絕、交換、增加、修改或者刪除請求 (request)或者回應(response)裏指定內容來控制協議，這種操作要基於特定規則。

我現在用HAProxy主要在於它有以下優點，這裏我總結下：

一、免費開源，穩定性也是非常好，這個可通過我做的一些小項目可以看出來，單Haproxy也跑得不錯，穩定性可以與LVS相媲美；

二、根據官方文檔，HAProxy可以跑滿10Gbps-New benchmark of HAProxy at 10 Gbps using Myricom's 10GbE NICs (Myri-10G PCI-Express)，這個作爲軟件級負載均衡，也是比較驚人的；

三、HAProxy可以作爲MySQL、郵件或其它的非web的負載均衡，我們常用於它作爲MySQL(讀)負載均衡；

四、自帶強大的監控服務器狀態的頁面，實際環境中我們結合Nagios進行郵件或短信報警，這個也是我非常喜歡它的原因之一；

五、HAProxy支持虛擬主機。

===================================================================================

在做反向代理服務器的負載均衡時，我們通常會使用nginx的均衡配置。其實，haproxy的負載均衡也是屬於這一類的。那麼關於這方面的配置過程我們現在來進行一下講解。首先，對haproxy進行一個簡單的介紹，之後就是安裝和配置環節了。

HAProxy介紹

反向代理服務器,支持雙機熱備支持虛擬主機,但其配置簡單,擁有非常不錯的服務器健康檢查功能,當其代理的後端服務器出現故障, HAProxy會自動將該服務器摘除,故障恢復後再自動將該服務器加入｡新的1.3引入了frontend,backend；frontend根據任意 HTTP請求頭內容做規則匹配,然後把請求定向到相關的backend.

http://blog.liuts.com/post/223/ （搭建四層負載均衡器）

http://rfyimcool.blog.51cto.com/1030776/413187 （搭建七層負載均衡器）

===================================================================================

keepalived簡介　　

http://www.keepalived.org

keepalived是一個類似於layer3, 4 & 5交換機制的軟件，也就是我們平時說的第3層、第4層和第5層交換。Keepalived的作用是檢測web服務器的狀態，如果有一臺web服務器死機，或工作出現故障，Keepalived將檢測到，並將有故障的web服務器從系統中剔除，當web服務器工作正常後Keepalived自動將web服務器加入到服務器羣中，這些工作全部自動完成，不需要人工干涉，需要人工做的只是修復故障的web服務器。

類似的HA工具還有heatbeat、drbd等，heatbeat、drbd配置都較爲複雜。

keepalived理論工作原理

keepalived可提供vrrp以及health-check功能，可以只用它提供雙機浮動的vip（vrrp虛擬路由功能），這樣可以簡單實現一個雙機熱備高可用功能。

keepalived是一個類似於layer3, 4 & 5交換機制的軟件，也就是我們平時說的第3層、第4層和第5層交換。Keepalived的作用是檢測web 服務器的狀態。 Layer3,4&5工作在IP/TCP協議棧的IP層，TCP層，及應用層,原理分別如下：

　　Layer3：Keepalived使用Layer3的方式工作式時，Keepalived會定期向服務器羣中的服務器

　　發送一個ICMP的數據包（既我們平時用的Ping程序）,如果發現某臺服務的IP地址沒有激活，Keepalived便報告這臺服務器失效，並將它從服務器羣中剔除，這種情況的典型例子是某臺服務器被非法關機。Layer3的方式是以服務器的IP地址是否有效作爲服務器工作正常與否的標準。在本文中將採用這種方式。

　　Layer4:如果您理解了Layer3的方式，Layer4就容易了。Layer4主要以TCP端口的狀態來決定服務器工作正常與否。如web server的服務端口一般是80，如果Keepalived檢測到80端口沒有啓動，則Keepalived將把這臺服務器從服務器羣中剔除。

　　Layer5：Layer5就是工作在具體的應用層了，比Layer3,Layer4要複雜一點，在網絡上佔用的帶寬也要大一些。Keepalived將根據用戶的設定檢查服務器程序的運行是否正常，如果與用戶的設定不相符，則Keepalived將把服務器從服務器羣中剔除。

vip即虛擬ip，是附在主機網卡上的，即對主機網卡進行虛擬，此IP仍然是佔用了此網段的某個IP。

keepalived作用

　　隨着你的網站業務量的增長你網站的服務器壓力越來越大？需要負載均衡方案！商業的硬件如F5又太貴，你們又是創業型互聯公司如何有效節約成本，節省不必要的浪費？同時實現商業硬件一樣的高性能高可用的功能？有什麼好的負載均衡可伸張可擴展的方案嗎？答案是肯定的！有！我們利用 LVS+Keepalived基於完整開源軟件的架構可以爲你提供一個負載均衡及高可用的服務器。

　　LVS+Keepalived 介紹

　　LVS

　　LVS是Linux Virtual Server的簡寫，意即Linux虛擬服務器，是一個虛擬的服務器集羣系統。本項目在1998年5月由章文嵩博士成立，是中國國內最早出現的自由軟件項目之一.目前有三種IP負載均衡技術（VS/NAT、VS/TUN和VS/DR）八種調度算法（rr,wrr,lc,wlc,lblc,lblcr,dh,sh）。

　　Keepalvied

　　Keepalived在這裏主要用作RealServer的健康狀態檢查以及LoadBalance主機和BackUP主機之間failover的實現。keepalived簡介　　keepalived是一個類似於layer3, 4 & 5交換機制的軟件，也就是我們平時說的第3層、第4層和第5層交換。Keepalived的作用是檢測web服務器的狀態，如果有一臺web服務器死機，或工作出現故障，Keepalived將檢測到，並將有故障的web服務器從系統中剔除，當web服務器工作正常後Keepalived自動將web服務器加入到服務器羣中，這些工作全部自動完成，不需要人工干涉，需要人工做的只是修復故障的web服務器。

===================================================================================

Keepalived介紹

Keepalived是一個基於VRRP協議來實現的WEB 服務高可用方案，可以利用其來避免單點故障。一個WEB服務至少會有2臺服務器運行Keepalived，一臺爲主服務器（MASTER），一臺爲備份服務器（BACKUP），但是對外表現爲一個虛擬IP，主服務器會發送特定的消息給備份服務器，當備份服務器收不到這個消息的時候，即主服務器宕機的時候，備份服務器就會接管虛擬IP，繼續提供服務，從而保證了高可用性。

+-------------	VIP(192.168.0.7)	------------------+
server(MASTER)	<----keepalived---->	server(BACKUP)
(192.168.0.1)		(192.168.0.2)

keepalived是VRRP的完美實現，因此在介紹keepalived之前，先介紹一下VRRP的原理。

VRRP協議簡介

在現實的網絡環境中，兩臺需要通信的主機大多數情況下並沒有直接的物理連接。對於這樣的情況，它們之間路由怎樣選擇？主機如何選定到達目的主機的下一跳路由，這個問題通常的解決方法有二種：

· 在主機上使用動態路由協議(RIP、OSPF等)

· 在主機上配置靜態路由

很明顯，在主機上配置路態路由是非常不切實際的，因爲管理、維護成本以及是否支持等諸多問題。配置靜態路由就變得十分流行，但路由器(或者說默認網關default gateway)卻經常成爲單點。

VRRP的目的就是爲了解決靜態路由單點故障問題。

VRRP通過一競選(election)協議來動態的將路由任務交給LAN中虛擬路由器中的某臺VRRP路由器。

工作機制

在一個VRRP虛擬路由器中，有多臺物理的VRRP路由器，但是這多臺的物理的機器並不能同時工作，而是由一臺稱爲MASTER的負責路由工作，其它的都是BACKUP，MASTER並非一成不變，VRRP讓每個VRRP路由器參與競選，最終獲勝的就是MASTER。MASTER擁有一些特權，比如擁有虛擬路由器的IP地址，我們的主機就是用這個IP地址作爲靜態路由的。擁有特權的MASTER要負責轉發發送給網關地址的包和響應ARP請求。

VRRP通過競選協議來實現虛擬路由器的功能，所有的協議報文都是通過IP多播(multicast)包(多播地址 224.0.0.18)形式發送的。虛擬路由器由VRID(範圍0-255)和一組IP地址組成，對外表現爲一個周知的MAC地址。所以，在一個虛擬路由器中，不管誰是MASTER，對外都是相同的MAC和IP(稱之爲VIP)。客戶端主機並不需要因爲MASTER的改變而修改自己的路由配置，對他們來說，這種主從的切換是透明的。

在一個虛擬路由器中，只有作爲MASTER的VRRP路由器會一直髮送VRRP廣告包(VRRPAdvertisement message)，BACKUP不會搶佔MASTER，除非它的優先級(priority)更高。當MASTER不可用時(BACKUP收不到廣告包)，多臺BACKUP中優先級最高的這臺會被搶佔爲MASTER。這種搶佔是非常快速的(<1s)，以保證服務的連續性。

由於安全性考慮，VRRP包使用了加密協議進行加密。

==========================================

vrrp簡介
隨着Internet的迅猛發展，基於網絡的應用逐漸增多。這就對網絡的可靠性提出了越來越高的要求。斥資對所有網絡設備進行更新當然是一種很好的可靠性解決方案；但本着保護現有投資的角度考慮，可以採用廉價冗餘的思路，在可靠性和經濟性方面找到平衡點。

虛擬路由冗餘協議就是一種很好的解決方案。在該協議中，對共享多存取訪問介質（如以太網）上終端IP設備的默認網關(Default Gateway)進行冗餘備份，從而在其中一臺路由設備宕機時，備份路由設備及時接管轉發工作，向用戶提供透明的切換，提高了網絡服務質量。

一、協議概述

在基於TCP/IP協議的網絡中，爲了保證不直接物理連接的設備之間的通信，必須指定路由。目前常用的指定路由的方法有兩種：一種是通過路由協議（比如：內部路由協議RIP和OSPF）動態學習；另一種是靜態配置。在每一個終端都運行動態路由協議是不現實的，大多客戶端操作系統平臺都不支持動態路由協議，即使支持也受到管理開銷、收斂度、安全性等許多問題的限制。因此普遍採用對終端IP設備靜態路由配置，一般是給終端設備指定一個或者多個默認網關(Default Gateway)。靜態路由的方法簡化了網絡管理的複雜度和減輕了終端設備的通信開銷，但是它仍然有一個缺點：如果作爲默認網關的路由器損壞，所有使用該網關爲下一跳主機的通信必然要中斷。即便配置了多個默認網關，如不重新啓動終端設備，也不能切換到新的網關。採用虛擬路由冗餘協議 (Virtual Router Redundancy Protocol，簡稱VRRP)可以很好的避免靜態指定網關的缺陷。

在VRRP協議中，有兩組重要的概念：VRRP路由器和虛擬路由器，主控路由器和備份路由器。VRRP路由器是指運行VRRP的路由器，是物理實體，虛擬路由器是指VRRP協議創建的，是邏輯概念。一組VRRP路由器協同工作，共同構成一臺虛擬路由器。該虛擬路由器對外表現爲一個具有唯一固定IP地址和MAC地址的邏輯路由器。處於同一個VRRP組中的路由器具有兩種互斥的角色：主控路由器和備份路由器，一個VRRP組中有且只有一臺處於主控角色的路由器，可以有一個或者多個處於備份角色的路由器。VRRP協議使用選擇策略從路由器組中選出一臺作爲主控，負責ARP相應和轉發IP數據包，組中的其它路由器作爲備份的角色處於待命狀態。當由於某種原因主控路由器發生故障時，備份路由器能在幾秒鐘的時延後升級爲主路由器。由於此切換非常迅速而且不用改變IP地址和MAC地址，故對終端使用者系統是透明的。

二、工作原理

一個VRRP路由器有唯一的標識：VRID，範圍爲0—255。該路由器對外表現爲唯一的虛擬MAC地址，地址的格式爲00-00-5E-00-01-[VRID]。主控路由器負責對ARP請求用該MAC地址做應答。這樣，無論如何切換，保證給終端設備的是唯一一致的IP和MAC地址，減少了切換對終端設備的影響。

VRRP控制報文只有一種：VRRP通告(advertisement)。它使用IP多播數據包進行封裝，組地址爲224.0.0.18，發佈範圍只限於同一局域網內。這保證了VRID在不同網絡中可以重複使用。爲了減少網絡帶寬消耗只有主控路由器纔可以週期性的發送VRRP通告報文。備份路由器在連續三個通告間隔內收不到VRRP或收到優先級爲0的通告後啓動新的一輪VRRP選舉。

在VRRP路由器組中，按優先級選舉主控路由器，VRRP協議中優先級範圍是0—255。若VRRP路由器的IP地址和虛擬路由器的接口IP地址相同，則稱該虛擬路由器作VRRP組中的IP地址所有者；IP地址所有者自動具有最高優先級：255。優先級0一般用在IP地址所有者主動放棄主控者角色時使用。可配置的優先級範圍爲1—254。優先級的配置原則可以依據鏈路的速度和成本、路由器性能和可靠性以及其它管理策略設定。主控路由器的選舉中，高優先級的虛擬路由器獲勝，因此，如果在VRRP組中有IP地址所有者，則它總是作爲主控路由的角色出現。對於相同優先級的候選路由器，按照IP地址大小順序選舉。VRRP還提供了優先級搶佔策略，如果配置了該策略，高優先級的備份路由器便會剝奪當前低優先級的主控路由器而成爲新的主控路由器。

爲了保證VRRP協議的安全性，提供了兩種安全認證措施：明文認證和IP頭認證。明文認證方式要求：在加入一個VRRP路由器組時，必須同時提供相同的VRID和明文密碼。適合於避免在局域網內的配置錯誤，但不能防止通過網絡監聽方式獲得密碼。IP頭認證的方式提供了更高的安全性，能夠防止報文重放和修改等×××。

三、應用實例

最典型的VRRP應用：RTA、RTB組成一個VRRP路由器組，假設RTB的處理能力高於RTA，則將RTB配置成IP地址所有者，H1、H2、H3的默認網關設定爲RTB。則RTB成爲主控路由器，負責ICMP重定向、ARP應答和IP報文的轉發；一旦RTB失敗，RTA立即啓動切換，成爲主控，從而保證了對客戶透明的安全切換。

在VRRP應用中，RTA在線時RTB只是作爲後備，不參與轉發工作，閒置了路由器RTA和鏈路L1。通過合理的網絡設計，可以到達備份和負載分擔雙重效果。讓RTA、RTB同時屬於互爲備份的兩個VRRP組：在組1中RTA爲IP地址所有者；組2中RTB爲IP地址所有者。將H1的默認網關設定爲RTA；H2、H3的默認網關設定爲RTB。這樣，既分擔了設備負載和網絡流量，又提高了網絡可靠性。

VRRP協議的工作機理與CISCO公司的HSRP（Hot Standby Routing Protocol）有許多相似之處。但二者主要的區別是在CISCO的HSRP中，需要單獨配置一個IP地址作爲虛擬路由器對外體現的地址，這個地址不能是組中任何一個成員的接口地址。

使用VRRP協議，不用改造目前的網絡結構，最大限度保護了當前投資，只需最少的管理費用，卻大大提升了網絡性能，具有重大的應用價值。

===================================================================================

keepalive的簡單應用——管理VIP的飄動

from:http://www.cnblogs.com/killkill/archive/2010/12/31/1922360.html

VIP的飄動可以爲我們解決很多問題，以前我試過使用ifup/ifdown的方式控制網卡的up/down來實現，這種方式有個小問題，就是每次VIP 飄動之後都要等上幾十秒才能生效，感覺時間比較長，而且還要配合一些邏輯腳本才能很好地工作，有沒有更好的方法呢？當然有，這就是本文的主角—— keepalived。

安裝很簡單：

tar zxvf keepalived-1.1.20.tar.gz  
cd keepalived-1.1.20
./configure --prefix=/
make
make install

修改一下 /etc/keepalived/keepalived.conf 這個配置文件就可以用了，以下是我的環境，192.168.10.141和192.168.10.142是兩個VIP，可以在兩臺服務器之間飄動：

主機的配置：

global_defs {

notification_email {

[email protected]

}

notification_email_from [email protected]

smtp_server 192.168.0.48

smtp_connect_timeout 10

router_id nginx

}

vrrp_instance VI_141 {

state BACKUP

interface eth0

virtual_router_id 141

priority 50

advert_int 1

authentication {

auth_type PASS

auth_pass 141

}

virtual_ipaddress {

192.168.10.141/26 dev eth0

}

}

vrrp_instance VI_142 {

state BACKUP

interface eth0

virtual_router_id 142

priority 100

advert_int 1

authentication {

auth_type PASS

auth_pass 142

}

virtual_ipaddress {

192.168.10.142/26 dev eth0

}

}

備機的配置：

global_defs {

notification_email {

[email protected]

}

notification_email_from [email protected]

smtp_server 10.168.0.48

smtp_connect_timeout 10

router_id nginx

}

vrrp_instance VI_141 {

state BACKUP

interface eth0

virtual_router_id 141

priority 100

advert_int 1

authentication {

auth_type PASS

auth_pass 141

}

virtual_ipaddress {

192.168.10.141/26 dev eth0

}

}

vrrp_instance VI_142 {

state BACKUP

interface eth0

virtual_router_id 142

priority 50

advert_int 1

authentication {

auth_type PASS

auth_pass 142

}

virtual_ipaddress {

192.168.10.142/26 dev eth0

}

}

乍一看，主機和備機的配置文件是一樣的，仔細看一下priority的值，使用以下命令即可將keepalived加入linux的服務中：
chkconfig --add keepalived ;

通過啓、停keepalived這個服務即可觀察到VIP的飄動，至於爲什麼VIP飄動後可以很快地生效，還有待研究。

===================================================================================

haproxy+keepalived實現高可用負載均衡

我的環境：
haproxy keepalived 主：192.168.1.192
haproxy keepalived 備：192.168.1.193
vip：192.168.1.200
web：192.168.1.187:80 192.168.1.187:8000

一：安裝過程，在192.168.1.192上：
keepalived的安裝:

#tar -zxvf keepalived-1.1.17.tar.gz  
#ln -s /usr/src/kernels/2.6.18-128.el5-i686/ /usr/src/linux  
#cd keepalived-1.1.17  
#./configure --prefix=/ --mandir=/usr/local/share/man/ --with-kernel-dir=/usr/src/kernels/2.6.18-128.el5-i686/  
#make && make install  
#cd /etc/keepalived/  
#mv keepalived.conf keepalived.conf.default  
#vi keepalived.conf  
! Configuration File for keepalived  

vrrp_script chk_http_port {  
script "/etc/keepalived/check_haproxy.sh"  
interval 2  
weight 2  

global_defs {  
router_id LVS_DEVEL  
}  
vrrp_instance VI_1 {  
state MASTER #192.168.1.193上改爲BACKUP  
interface eth0  
virtual_router_id 51  
priority 150 #192.168.1.193上改爲120  
advert_int 1  
authentication {  
auth_type PASS  
auth_pass 1111  
}  

track_script {  
chk_http_port  
}  

virtual_ipaddress {  
192.168.1.200  
}  
}  
}  

#vi /etc/keepalived/check_haproxy.sh  
#!/bin/bash  
A=`ps -C haproxy --no-header |wc -l`  
if [ $A -eq 0 ];then  
/usr/local/haproxy/sbin/haproxy -f /usr/local/haproxy/conf/haproxy.cfg  
sleep 3  
if [ `ps -C haproxy --no-header |wc -l` -eq 0 ];then  
/etc/init.d/keepalived stop  
fi  
fi  
#chmod 755 /etc/keepalived/check_haproxy.sh

haproxy的安裝(主備都一樣)：

#tar -zxvf haproxy-1.4.9.tar.gz  
#cd haproxy-1.4.9  
#make TARGET=linux26 PREFIX=/usr/local/haproxy install  
#cd /usr/local/haproxy/  
#mkdir conf logs  
#cd conf  
#vi haproxy.cfg  
global  
log 127.0.0.1 local3 info  
maxconn 4096  
user nobody  
group nobody  
daemon  
nbproc 1  
pidfile /usr/local/haproxy/logs/haproxy.pid  

defaults  
maxconn 2000  
contimeout 5000  
clitimeout 30000  
srvtimeout 30000  
mode http  
log global  
log 127.0.0.1 local3 info  
stats uri /admin?stats  
option forwardfor  

frontend http_server  
bind :80  
log global  
default_backend info_cache  
acl test hdr_dom(host) -i test.domain.com  
use_backend cache_test if test  

backend info_cache  
#balance roundrobin  
balance source  
option httpchk HEAD /haproxy.txt HTTP/1.1\r\nHost:192.168.1.187  
server inst2 192.168.1.187:80 check inter 5000 fall 3  

backend cache_test  
balance roundrobin  
#balance source  
option httpchk HEAD /haproxy.txt HTTP/1.1\r\nHost:test.domain.com  
server inst1 192.168.1.187:8000 check inter 5000 fall 3

二：再兩臺機器上都分別啓動：
/etc/init.d/keepalived start （這條命令會自動把haproxy啓動）

三：測試：
1.再兩臺機器上分別執行ip add
主:

eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000  
link/ether 00:0c:29:98:cd:c0 brd ff:ff:ff:ff:ff:ff  
inet 192.168.1.192/24 brd 192.168.1.255 scope global eth0  
inet 192.168.1.200/32 scope global eth0  
inet6 fe80::20c:29ff:fe98:cdc0/64 scope link  
valid_lft forever preferred_lft forever

備:

eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000  
link/ether 00:0c:29:a6:0c:7e brd ff:ff:ff:ff:ff:ff  
inet 192.168.1.193/24 brd 255.255.255.254 scope global eth0  
inet6 fe80::20c:29ff:fea6:c7e/64 scope link  
valid_lft forever preferred_lft forever

2.停掉主上的haproxy，3秒後keepalived會自動將其再次啓動
3.停掉主的keepalived，備機馬上接管服務
備:

eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000  
link/ether 00:0c:29:a6:0c:7e brd ff:ff:ff:ff:ff:ff  
inet 192.168.1.193/24 brd 255.255.255.254 scope global eth0  
inet 192.168.1.200/32 scope global eth0  
inet6 fe80::20c:29ff:fea6:c7e/64 scope link  
valid_lft forever preferred_lft forever

4.更改hosts

192.168.1.200 test.com  
192.168.1.200 test.domain.com

通過IE測試，可以發現
test.com的請求發向了192.168.1.187:80
test.domain.com的請求發向了192.168.1.187:8000

nginx、lvs、haproxy比較

http://www.csdn.net/article/2014-07-24/2820837
摘要：Nginx/LVS/HAProxy是目前使用最廣泛的三種負載均衡軟件，一般對負載均衡的使用是隨着網站規模的提升根據不同的階段來使用不同的技術，具體的應用需求還得具體分析，本文總結了三者之間的優缺點。

【編者按】負載均衡（Load Balancing）建立在現有網絡結構之上，它提供了一種廉價有效透明的方法擴展網絡設備和服務器的帶寬、增加吞吐量、加強網絡數據處理能力，同時能夠提高網絡的靈活性和可用性。目前使用最爲廣泛的負載均衡軟件是Nginx、LVS、HAProxy，本文作者結合自己的實踐經驗總結了三者各自的優缺點。文章來自ha97網。

以下爲原文：

Nginx/LVS/HAProxy是目前使用最廣泛的三種負載均衡軟件，本人都在多個項目中實施過，參考了一些資料，結合自己的一些使用經驗，總結一下。

一般對負載均衡的使用是隨着網站規模的提升根據不同的階段來使用不同的技術。具體的應用需求還得具體分析，如果是中小型的Web應用，比如日PV小於1000萬，用Nginx就完全可以了；如果機器不少，可以用DNS輪詢，LVS所耗費的機器還是比較多的；大型網站或重要的服務，且服務器比較多時，可以考慮用LVS。

一種是通過硬件來進行，常見的硬件有比較昂貴的F5和Array等商用的負載均衡器，它的優點就是有專業的維護團隊來對這些服務進行維護、缺點就是花銷太大，所以對於規模較小的網絡服務來說暫時還沒有需要使用；另外一種就是類似於Nginx/LVS/HAProxy的基於 Linux的開源免費的負載均衡軟件，這些都是通過軟件級別來實現，所以費用非常低廉。

目前關於網站架構一般比較合理流行的架構方案：Web前端採用Nginx/HAProxy+ Keepalived作負載均衡器；後端採用 MySQL數據庫一主多從和讀寫分離，採用LVS+Keepalived的架構。當然要根據項目具體需求制定方案。

下面說說各自的特點和適用場合。

Nginx的優點是：

工作在網絡的7層之上，可以針對http應用做一些分流的策略，比如針對域名、目錄結構，它的正則規則比HAProxy更爲強大和靈活，這也是它目前廣泛流行的主要原因之一，Nginx單憑這點可利用的場合就遠多於LVS了。
Nginx對網絡穩定性的依賴非常小，理論上能ping通就就能進行負載功能，這個也是它的優勢之一；相反LVS對網絡穩定性依賴比較大，這點本人深有體會；
Nginx安裝和配置比較簡單，測試起來比較方便，它基本能把錯誤用日誌打印出來。LVS的配置、測試就要花比較長的時間了，LVS對網絡依賴比較大。
可以承擔高負載壓力且穩定，在硬件不差的情況下一般能支撐幾萬次的併發量，負載度比LVS相對小些。
Nginx可以通過端口檢測到服務器內部的故障，比如根據服務器處理網頁返回的狀態碼、超時等等，並且會把返回錯誤的請求重新提交到另一個節點，不過其中缺點就是不支持url來檢測。比如用戶正在上傳一個文件，而處理該上傳的節點剛好在上傳過程中出現故障，Nginx會把上傳切到另一臺服務器重新處理，而LVS就直接斷掉了，如果是上傳一個很大的文件或者很重要的文件的話，用戶可能會因此而不滿。
Nginx不僅僅是一款優秀的負載均衡器/反向代理軟件，它同時也是功能強大的Web應用服務器。LNMP也是近幾年非常流行的web架構，在高流量的環境中穩定性也很好。
Nginx現在作爲Web反向加速緩存越來越成熟了，速度比傳統的Squid服務器更快，可以考慮用其作爲反向代理加速器。
Nginx可作爲中層反向代理使用，這一層面Nginx基本上無對手，唯一可以對比Nginx的就只有 lighttpd了，不過 lighttpd目前還沒有做到Nginx完全的功能，配置也不那麼清晰易讀，社區資料也遠遠沒Nginx活躍。
Nginx也可作爲靜態網頁和圖片服務器，這方面的性能也無對手。還有Nginx社區非常活躍，第三方模塊也很多。

Nginx的缺點是：

Nginx僅能支持http、https和Email協議，這樣就在適用範圍上面小些，這個是它的缺點。
對後端服務器的健康檢查，只支持通過端口來檢測，不支持通過url來檢測。不支持Session的直接保持，但能通過ip_hash來解決。

LVS：使用Linux內核集羣實現一個高性能、高可用的負載均衡服務器，它具有很好的可伸縮性（Scalability)、可靠性（Reliability)和可管理性（Manageability)。

LVS的優點是：

抗負載能力強、是工作在網絡4層之上僅作分發之用，沒有流量的產生，這個特點也決定了它在負載均衡軟件裏的性能最強的，對內存和cpu資源消耗比較低。
配置性比較低，這是一個缺點也是一個優點，因爲沒有可太多配置的東西，所以並不需要太多接觸，大大減少了人爲出錯的機率。
工作穩定，因爲其本身抗負載能力很強，自身有完整的雙機熱備方案，如LVS+Keepalived，不過我們在項目實施中用得最多的還是LVS/DR+Keepalived。
無流量，LVS只分發請求，而流量並不從它本身出去，這點保證了均衡器IO的性能不會受到大流量的影響。
應用範圍比較廣，因爲LVS工作在4層，所以它幾乎可以對所有應用做負載均衡，包括http、數據庫、在線聊天室等等。

LVS的缺點是：

軟件本身不支持正則表達式處理，不能做動靜分離；而現在許多網站在這方面都有較強的需求，這個是Nginx/HAProxy+Keepalived的優勢所在。
如果是網站應用比較龐大的話，LVS/DR+Keepalived實施起來就比較複雜了，特別後面有 Windows Server的機器的話，如果實施及配置還有維護過程就比較複雜了，相對而言，Nginx/HAProxy+Keepalived就簡單多了。

HAProxy的特點是：

HAProxy也是支持虛擬主機的。
HAProxy的優點能夠補充Nginx的一些缺點，比如支持Session的保持，Cookie的引導；同時支持通過獲取指定的url來檢測後端服務器的狀態。
HAProxy跟LVS類似，本身就只是一款負載均衡軟件；單純從效率上來講HAProxy會比Nginx有更出色的負載均衡速度，在併發處理上也是優於Nginx的。
HAProxy支持TCP協議的負載均衡轉發，可以對MySQL讀進行負載均衡，對後端的MySQL節點進行檢測和負載均衡，大家可以用LVS+Keepalived對MySQL主從做負載均衡。
HAProxy負載均衡策略非常多，HAProxy的負載均衡算法現在具體有如下8種：

① roundrobin，表示簡單的輪詢，這個不多說，這個是負載均衡基本都具備的；
② static-rr，表示根據權重，建議關注；
③ leastconn，表示最少連接者先處理，建議關注；
④ source，表示根據請求源IP，這個跟Nginx的IP_hash機制類似，我們用其作爲解決session問題的一種方法，建議關注；
⑤ ri，表示根據請求的URI；
⑥ rl_param，表示根據請求的URl參數’balance url_param’ requires an URL parameter name；
⑦ hdr(name)，表示根據HTTP請求頭來鎖定每一次HTTP請求；
⑧ rdp-cookie(name)，表示根據據cookie(name)來鎖定並哈希每一次TCP請求。

Nginx和LVS對比的總結：

Nginx工作在網絡的7層，所以它可以針對http應用本身來做分流策略，比如針對域名、目錄結構等，相比之下LVS並不具備這樣的功能，所以Nginx單憑這點可利用的場合就遠多於LVS了；但Nginx有用的這些功能使其可調整度要高於LVS，所以經常要去觸碰觸碰，觸碰多了，人爲出問題的機率也就會大。
Nginx對網絡穩定性的依賴較小，理論上只要ping得通，網頁訪問正常，Nginx就能連得通，這是Nginx的一大優勢！Nginx同時還能區分內外網，如果是同時擁有內外網的節點，就相當於單機擁有了備份線路；LVS就比較依賴於網絡環境，目前來看服務器在同一網段內並且LVS使用direct方式分流，效果較能得到保證。另外注意，LVS需要向託管商至少申請多一個ip來做Visual IP，貌似是不能用本身的IP來做VIP的。要做好LVS管理員，確實得跟進學習很多有關網絡通信方面的知識，就不再是一個HTTP那麼簡單了。
Nginx安裝和配置比較簡單，測試起來也很方便，因爲它基本能把錯誤用日誌打印出來。LVS的安裝和配置、測試就要花比較長的時間了；LVS對網絡依賴比較大，很多時候不能配置成功都是因爲網絡問題而不是配置問題，出了問題要解決也相應的會麻煩得多。
Nginx也同樣能承受很高負載且穩定，但負載度和穩定度差LVS還有幾個等級：Nginx處理所有流量所以受限於機器IO和配置；本身的bug也還是難以避免的。
Nginx可以檢測到服務器內部的故障，比如根據服務器處理網頁返回的狀態碼、超時等等，並且會把返回錯誤的請求重新提交到另一個節點。目前LVS中 ldirectd也能支持針對服務器內部的情況來監控，但LVS的原理使其不能重發請求。比如用戶正在上傳一個文件，而處理該上傳的節點剛好在上傳過程中出現故障，Nginx會把上傳切到另一臺服務器重新處理，而LVS就直接斷掉了，如果是上傳一個很大的文件或者很重要的文件的話，用戶可能會因此而惱火。
Nginx對請求的異步處理可以幫助節點服務器減輕負載，假如使用 apache直接對外服務，那麼出現很多的窄帶鏈接時apache服務器將會佔用大量內存而不能釋放，使用多一個Nginx做apache代理的話，這些窄帶鏈接會被Nginx擋住，apache上就不會堆積過多的請求，這樣就減少了相當多的資源佔用。這點使用squid也有相同的作用，即使squid本身配置爲不緩存，對apache還是有很大幫助的。
Nginx能支持http、https和email（email的功能比較少用），LVS所支持的應用在這點上會比Nginx更多。在使用上，一般最前端所採取的策略應是LVS，也就是DNS的指向應爲LVS均衡器，LVS的優點令它非常適合做這個任務。重要的ip地址，最好交由LVS託管，比如數據庫的 ip、webservice服務器的ip等等，這些ip地址隨着時間推移，使用面會越來越大，如果更換ip則故障會接踵而至。所以將這些重要ip交給 LVS託管是最爲穩妥的，這樣做的唯一缺點是需要的VIP數量會比較多。Nginx可作爲LVS節點機器使用，一是可以利用Nginx的功能，二是可以利用Nginx的性能。當然這一層面也可以直接使用squid，squid的功能方面就比Nginx弱不少了，性能上也有所遜色於Nginx。Nginx也可作爲中層代理使用，這一層面Nginx基本上無對手，唯一可以撼動Nginx的就只有lighttpd了，不過lighttpd目前還沒有能做到 Nginx完全的功能，配置也不那麼清晰易讀。另外，中層代理的IP也是重要的，所以中層代理也擁有一個VIP和LVS是最完美的方案了。具體的應用還得具體分析，如果是比較小的網站（日PV小於1000萬），用Nginx就完全可以了，如果機器也不少，可以用DNS輪詢，LVS所耗費的機器還是比較多的；大型網站或者重要的服務，機器不發愁的時候，要多多考慮利用LVS。

現在對網絡負載均衡的使用是隨着網站規模的提升根據不同的階段來使用不同的技術：

第一階段：利用Nginx或HAProxy進行單點的負載均衡，這一階段服務器規模剛脫離開單服務器、單數據庫的模式，需要一定的負載均衡，但是仍然規模較小沒有專業的維護團隊來進行維護，也沒有需要進行大規模的網站部署。這樣利用Nginx或HAproxy就是第一選擇，此時這些東西上手快，配置容易，在七層之上利用HTTP協議就可以。這時是第一選擇。

第二階段：隨着網絡服務進一步擴大，這時單點的Nginx已經不能滿足，這時使用LVS或者商用Array就是首要選擇，Nginx此時就作爲LVS或者Array的節點來使用，具體LVS或Array的是選擇是根據公司規模和預算來選擇，Array的應用交付功能非常強大，本人在某項目中使用過，性價比也遠高於F5，商用首選，但是一般來說這階段相關人才跟不上業務的提升，所以購買商業負載均衡已經成爲了必經之路。

第三階段：這時網絡服務已經成爲主流產品，此時隨着公司知名度也進一步擴展，相關人才的能力以及數量也隨之提升，這時無論從開發適合自身產品的定製，以及降低成本來講開源的LVS，已經成爲首選，這時LVS會成爲主流。

最終形成比較理想的基本架構爲：Array/LVS — Nginx/Haproxy — Squid/Varnish — AppServer。

keepalived中自定義腳本 vrrp_script

http://my.oschina.net/hncscwc/blog/158746
通常情況下，利用keepalived做熱備，其中一臺設置爲master，一臺設置爲backup。當master出現異常後，backup自動切換爲master。當backup成爲master後，master恢復正常後會再次搶佔成爲master，導致不必要的主備切換。因此可以將兩臺keepalived初始狀態均配置爲backup，設置不同的優先級，優先級高的設置nopreempt解決異常恢復後再次搶佔的問題。

然而keepalived只能做到對網絡故障和keepalived本身的監控，即當出現網絡故障或者keepalived本身出現問題時，進行切換。但是這些還不夠，我們還需要監控keepalived所在服務器上的其他業務進程，根據業務進程的運行狀態決定是否需要進行主備切換。這個時候，我們可以通過編寫腳本對業務進程進行檢測監控。

例如編寫個簡單腳本查看haproxy進程是否存活

#!/bin/bash
count = `ps aux | grep -v grep | grep haproxy | wc -l`
if [ $count > 0 ]; then
    exit 0
else
    exit 1
fi

在keepalived的配置文件中增加相應配置項

vrrp_script checkhaproxy
{
    script "/home/check.sh"
    interval 3
    weight -20
}

vrrp_instance test
{
    ...

    track_script
    {
        checkhaproxy
    }

    ...
}

keepalived會定時執行腳本並對腳本執行的結果進行分析，動態調整vrrp_instance的優先級。

如果腳本執行結果爲0，並且weight配置的值大於0，則優先級相應的增加

如果腳本執行結果非0，並且weight配置的值小於0，則優先級相應的減少

其他情況，維持原本配置的優先級，即配置文件中priority對應的值。

這裏需要注意的是：

1）優先級不會不斷的提高或者降低

2）可以編寫多個檢測腳本併爲每個檢測腳本設置不同的weight

3）不管提高優先級還是降低優先級，最終優先級的範圍是在[1,254]，不會出現優先級小於等於0或者優先級大於等於255的情況

這樣可以做到利用腳本檢測業務進程的狀態，並動態調整優先級從而實現主備切換。

但是利用該方式會存在一個問題，例如：A,B兩臺keepalived

A的配置大概爲：

vrrp_script checkhaproxy
{
    script "/etc/check.sh"
    interval 3
    weight -20

}

vrrp_instance test
{
    ....

    state backup
    priority 80
    nopreempt

    track_script
    {
        checkhaproxy
    }

    ....
}

B的配置大概爲：

vrrp_script checkhaproxy
{
    script "/etc/check.sh"
    interval 3
    weight -20
}

vrrp_instance test
{
    ....

    state backup
    priority 70

    track_script
    {
        checkhaproxy
    }

    ....
}

A,B同時啓動後，由於A的優先級較高，因此通過選舉會成爲master。當A上的業務進程出現問題時，優先級會降低到60。此時B收到優先級比自己低的vrrp廣播包時，將切換爲master狀態。那麼當B上的業務出現問題時，優先級降低到50，儘管A的優先級比B的要高，但是由於設置了nopreempt，A不會再搶佔成爲master狀態。

所以，可以在檢測腳本中增加殺掉keepalived進程（或者停用keepalived服務）的方式，做到業務進程出現問題時完成主備切換。

lvs dr模式只使用一個公網ip的實現方法

http://storysky.blog.51cto.com/628458/338726

使用一個公網IP地址來實現LVS的DR模式(外帶php session粘滯問題解決)
去年有朋友問我單個公網ip怎麼才能使用LVS的DR模式，我當時還不以爲然，覺得他們公司可真小氣，那麼吝嗇公網ip。結果這個問題今天也讓我遇到了。
倒不是因爲對方公司沒有公網IP，而是由於安全性的考慮不希望服務器都暴漏在外，人家又不想因爲這個小項目買防火牆，所以就提了這個要求。
我說用NAT方式不行嗎？可人家說做分發器的服務器要身兼多職，不能再給她增加負擔了......X﹏X

需求提出來了，那我就開始執行吧！不過這方面的資料很少，去章博士的網站裏面找到了一篇文章，上面只說可以做，單具體怎麼做卻沒有說，而且好像還要打上forward_shared包(⊙o⊙)…好麻煩啊~~~
怎麼樣才能實現呢？這時候田老師給我提了個醒，“說一個公網IP也可以做DR啊，前面加個路由器就可以了”不過他也沒試過，讓我自己測測就知道了，我一聽有戲，馬上就開始測試吧，呵呵
具體結構就想上面那個圖那樣，(隨便畫的大家湊合着看吧(^__^) 嘻嘻……)
原理就是讓路由器把所有的80端口請求都分給VIP，分發器再分給每個web服務器，而web服務器處理完請求後跟客戶連接就不走分發器了，直接通過路由器去外網了，這樣就實現了只用一個公網IP也能用DR模式，呵呵具體配置如下
先從內網找了三臺服務器分別是：
192.168.1.166 web1
192.168.1.167 web2
192.168.1.160 分發器
192.168.1.169 VIP
192.168.1.1 路由器內網ip(網關) 路由器是隨便找的一臺tplink adal路由器，湊合着測試用的
211.83.113.119 路由器的WAN口IP (隨便蒙的,重複莫怪)

先安裝ipvsadm 直接yum install ipvsadm就行了，不多說
我用的是keepalived，這個工具不錯，至於安裝我就不說了，請參考田老師寫的《keepalived手冊》我的博客裏有下載鏈接
我的博客裏也有他的測試
只把配置文件貼上來吧，以下是分發器上的設置
global_defs {
notification_email {
[email protected]
}

notification_email_from [email protected]
smtp_server smtp.qq.com
smtp_connect_timeout 30
router_id LVS_DEVEL
}

vrrp_sync_group VG1 {
group{
VI_1
}
}
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 100
advert_int 1

authentication {
auth_type PASS
auth_pass 33210
}

virtual_ipaddress {
192.168.1.169
}

virtual_server 192.168.1.169 80 {
delay_loop 6
lb_algo rr
lb_kind DR
protocol TCP

real_server 192.168.1.166 80 {
weight 1
inhibit_on_failure
TCP_CHECK {
connect_timeout 5
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
real_server 192.168.1.167 80 {
weight 1
inhibit_on_failure
TCP_CHECK {
connect_timeout 5
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
配置文件寫完了，然後就是
mkdir /etc/keepalived #系統默認會到這裏去找配置文件
cp /usr/local/keepalive/etc/keepalived/keepalived.conf /etc/keepalived/
cp /usr/local/keepalive/etc/rc.d/init.d/keepalived /etc/init.d/
cp /usr/local/keepalive/etc/sysconfig/keepalived /etc/sysconfig/
cp /usr/local/keepalive/sbin/keepalived /bin/ #將可執行程序放入sbin 或者 bin目錄裏

vim /etc/sysctl.conf
net.ipv4.ip_forward = 1
保存退出後執行sysctl -p
route add defaule gw 192.168.1.1 把路由內網地址添加爲默認網關
web服務器設置
兩臺web服務器也要修改 /etc/sysctl.conf 修改內容如下
vim /etc/sysctl.conf
LVS
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.lo.arp_ignore = 1
net.ipv4.conf.lo.arp_announce = 2
sysctl -p
之後還要增加vip
ifconfig lo:1 192.168.1.169 netmask 255.255.255.255 別忘了加到rc.local裏面
route add defaule gw 192.168.1.1 把路由內網地址添加爲默認網關

路由器設置
路由器的設置沒什麼好說的，除了上網設置以外還要做一個端口映射，就是把80端口映射到 vip上也就是192.168.1.169

現在啓動keepalived吧
/etc/init.d/keepalived start
開始的時候比較慢，大概1分鐘後系統日誌裏面出現下面這條記錄就OK了
avahi-daemon[3012]: Registering new address record for 192.168.1.169 on eth0

我們訪問一下 http://211.83.113.119
哈哈成功了，我把我們的應用程序放到了上面跑了一下，結果測試通過，而且比較快，呵呵測試成功
ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.1.169:80 rr
-> 192.168.1.166:80 Route 1 5 6
-> 192.168.1.167:80 Route 1 3 9

後來遇到了一個問題，由於這套應用處在一個大網站的後臺，所以大部分的請求都來自同一個IP地址，而有一部分程序需要給每個連接做session粘滯，
這樣我就不能用lvs 的-p參數來設置ip粘滯時間，如果用lvs的粘滯時間的話大部分的請求都將分給同一臺web服務器(注意：這裏是session粘滯而不是IP粘滯)，
lvs可做不到這點，怎麼辦呢？
在cu論壇上詢問後得知有很多朋友做過類似的項目，他們的解決辦法是將session共享，共享到什麼地方就有很多選擇了
我們是把所有web服務器的php session都給memcached ，這樣你不管分發器把 ip連接分給哪個web服務器都不會有問題了，配置方法很簡單，就在php的配置文件內
增加一條語句就可以了，不過前提你需要裝好memcache模塊
[Session]
; Handler used to store/retrieve data.
session.save_handler = memcache
session.save_path = "tcp://192.168.1.161:11213"

就寫到這裏了，希望有同樣需求的朋友能看到我的這篇文章

十五週三次課(7月5日)

18.11 LVS DR模式搭建

配置

rs1、rs2腳本

測試：

LVS持久連接功能：lvs persistence

實例：

18.12 keepalived + LVS

擴展

haproxy+keepalived

keepalived理論工作原理

keepalived作用

keepalive的簡單應用——管理VIP的飄動

haproxy+keepalived實現高可用負載均衡

nginx、lvs、haproxy比較

keepalived中自定義腳本 vrrp_script

lvs dr模式只使用一個公網ip的實現方法

通過HPA+CronHPA組合應對業務複雜彈性伸縮場景

十三週四次課(6月22日)

十三週二次課（6月20日）

十三週一次課（6月12日）

十二週三次課(6月13日)

十三週五次課（6月25日）

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結