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的安装略
配置
dr
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
[[email protected] ~]# 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
[[email protected] ~]# 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定义用于"打标"的规则
[[email protected]~]#iptables -t mangle -A PREROUTING -d $vip -p $protocol --dport $port -j MARK--set-mark #
$vip:VIP地址
$protocol:协议
$port:协议端口
(2)基于FWM定义集群服务:
[[email protected]~]#ipvsadm -A -f # -s scheduler
3.实例演示
[[email protected]~]# iptables -t mangle -A PREROUTING -d 172.16.22.219 -p tcp --dport 80 -j MARK--set-mark 5
[[email protected]~]# ipvsadm -A -f 5 -s rr
[[email protected]~]# ipvsadm -a -f 5 -r 172.16.22.221 -g
[[email protected]~]# 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服务
[[email protected]~]# iptables -t mangle -A PREROUTING -d 172.16.22.220 -p tcp --dport 80 -j MARK--set-mark 99
[[email protected]~]# iptables -t mangle -A PREROUTING -d 172.16.22.220 -p tcp --dport 443 -j MARK--set-mark 99
[[email protected]~]# ipvsadm -A -f 99 -s rr -p
[[email protected]~]# ipvsadm -a -f 99 -r 172.16.22.221 -g
[[email protected]~]# 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的规则
[[email protected] ~]# ipvsadm -C
[[email protected] ~]# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
[[email protected] ~]#
清除之前配置的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
[[email protected] ~]# systemctl stop nginx
[[email protected] ~]# ps aux |grep nginx
root 4956 0.0 0.0 112680 980 pts/0 S+ 23:59 0:00 grep --color=auto nginx
[[email protected] ~]#
[[email protected] ~]# 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
[[email protected] ~]# vim /etc/keepalived/keepalived.conf
开启keepalived 服务,看看进程
[[email protected] ~]# systemctl start keepalived
[[email protected] ~]#
[[email protected] ~]# 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
[[email protected] ~]#
看下ip
[[email protected] ~]# 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
[[email protected] ~]#
查看下启动后的规则
[[email protected] ~]# 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
[[email protected] ~]#
停掉keepalived服务 再看下就没有规则了
[[email protected] ~]# systemctl stop keepalived
[[email protected] ~]# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
[[email protected] ~]#
再启动keepalived 再看就有了
[[email protected] ~]# systemctl start keepalived
[[email protected] ~]# 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
[[email protected] ~]#
同时还需要做两点
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简介
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"
就写到这里了,希望有同样需求的朋友能看到我的这篇文章
原文地址:http://blog.51cto.com/235571/2135280