@cdmonkey
2018-04-02T14:13:55.000000Z
字数 10413
阅读 1740
网络服务
LVS
http://www.cnphp6.com/detail/35876
https://my.oschina.net/hncscwc/blog/158746
http://h11345.blog.51cto.com/780987/1570786
它起初是专门为“LVS”而设计,就是用来监控集群系统中的各个真实服务器节点之健康状态,后来又加入了虚拟路由冗余协议 VRRP
功能,因而除了配合集群服务外,也能够作为其他服务之高可用工具。因而,其一方面具有节点健康检查的功能,另外又具有调度器之失败接管(Failover)功能。
The two functions of Keepalived:Healthcheck & Failover
Official website:http://www.keepalived.org
即主机与备机之间的故障转移和自动切换。这是针对有两个负载均衡调度器同时工作(热备)而采取的故障转移措施。当主负载均衡器(MASTER)失效或出现故障时,备份负载均衡器(BACKUP)将自动接管主负载均衡器的所有工作(VIP资源及相应的服务)。一旦主负载均衡器故障修复,就会接管回它原来处理的工作,相应的。备份负载均衡器就会释放其接管的工作,此时两者恢复到最初各自的角色状态。当然另外一种策略就是,即使是主负载均衡器再次投入使用,也无法再次恢复为主,而是成为当前新的主负载均衡器的热备机。
Cluster double Master architecture:
高可用集群要求同一时刻同一资源只能运行于一个几点上。但是可以使不同的节点于同一时刻运行不同而服务,这样的话高可用集群就不再是单纯的主备模型,而是不同节点上的不同服务互为主备的模型,如图所示:
该架构中使用多实例,监听多个VIP
,每个业务使用独立的VIP
。注意:每个VIP
对应的是不同的服务,同一个服务不能在两个负载均衡器上跑。如果同一个服务(域名)要绑定两个VIP则还需要DNS轮询机制。
当虚拟服务器中的某一个甚至是几个真实服务器同时发生故障无法提供服务时,负载均衡器会自动将失效的RS节点清除出去,从而保证用户的访问不受影响。当故障的RS节点修复后,系统又会自动的把它们加入进来,分配访问请求以提供正常的服务。
对于健康检查的方式,可以是端口、可以是URL,工作中更多地使用端口。
Keepalived对负载均衡调度器(Director)之间的故障切换转移,是通过VRRP协议(虚拟路由冗余协议)来实现的。在Keepalived下的负载均衡器工作正常时,主负载均衡器节点会不断地向备节点广播心跳信息,用以通知备节点自己还活着。当主节点发生故障时,备节点就无法继续检测到主节点的心跳,进而调用自身的接管程序,接管主节点的VIP资源及服务。而当主节点故障恢复后,备节点会释放接管的工作,恢复到原来的备节点角色。
对于VRRP协议,请参见相关文档。
VRRP协议小结:
VRRP即虚拟路由器冗余协议,VRRP的出现就是为了解决静态路由的单点故障。
VRRP是通过一种竞选协议机制来将路由任务交给某台VRRP路由器。
VRRP的通信是通过IP多播的方式进行的。
主发包,备接收包,备接收不到包的时候,接管主的资源。备可以有多个,通过优先级进行竞选。
VRRP使用了加密协议。
[root@testnginx01 tools]# tar zxvf keepalived-1.3.6.tar.gz
[root@testnginx01 tools]# cd keepalived-1.3.6
# 先安装依赖包:
yum install -y libnl libnl-devel popt-devel libnfnetlink libnfnetlink-devel openssl*
-------------------
[root@testnginx01 keepalived-1.3.6]# ./configure --prefix=/usr/local/keepalived
# 具体配置信息:
Keepalived configuration
------------------------
Keepalived version : 1.3.6
Compiler : gcc
Preprocessor flags :
Compiler flags : -Wall -Wunused -Wstrict-prototypes -Wextra -g -O2
Linker flags :
Extra Lib : -lcrypto -lssl -lnl
Use IPVS Framework : Yes
IPVS use libnl : Yes
IPVS syncd attributes : No
IPVS 64 bit stats : No
fwmark socket support : Yes
Use VRRP Framework : Yes
Use VRRP VMAC : Yes
Use VRRP authentication : Yes
With ip rules/routes : Yes
SNMP vrrp support : No
SNMP checker support : No
SNMP RFCv2 support : No
SNMP RFCv3 support : No
DBUS support : No
SHA1 support : No
Use Debug flags : No
Stacktrace support : No
Memory alloc check : No
libnl version : 1
Use IPv4 devconf : No
Use libiptc : No
Use libipset : No
init type : upstart
Build genhash : Yes
Build documentation : No
# 如果没有任何警告及错误信息,就能进行编译安装了。
[root@testnginx01 keepalived-1.3.6]# make && make install
ln -s /usr/local/keepalived/sbin/keepalived /usr/local/sbin/keepalived
ln -s /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/keepalived
mkdir -pv /etc/keepalived
ln -s /usr/local/keepalived/etc/keepalived/keepalived.conf /etc/keepalived/keepalived.conf
# 拷贝服务启动脚本:
cp /root/tools/keepalived-1.3.6/keepalived/etc/init.d/keepalived /etc/init.d/
# 需要将启动脚本按照实际情况行进行修改:
[root@testnginx01 ~]# vim /etc/init.d/keepalived
daemon keepalived ${KEEPALIVED_OPTIONS} --> daemon /usr/local/sbin/keepalived ${KEEPALIVED_OPTIONS}
# 如果在停止守护进程之前看到了如下的三个进程信息,则表明安装完成。
[root@testnginx01 ~]# ps -ef|grep keep|grep -v grep
root 24296 1 0 14:09 ? 00:00:00 /usr/local/sbin/keepalived -D
root 24298 24296 0 14:09 ? 00:00:00 /usr/local/sbin/keepalived -D
root 24299 24296 0 14:09 ? 00:00:00 /usr/local/sbin/keepalived -D
在编译安装完成之后,我们一共拷贝了四个与Keepalived服务有关的文件:
文件 | 说明 |
---|---|
/etc/init.d/keepalived |
很明显,这是服务启动停止的控制脚本。 |
/etc/sysconfig/keepalived |
这个应该是Keepalived服务启动参数的配置文件。 |
/etc/keepalived/keepalived.conf |
Keepalived服务的主配置文件。 |
/usr/sbin/keepalived |
服务的启动与停止:
[root@LVS-A ~]# /etc/init.d/keepalived start
[root@LVS-A ~]# /etc/init.d/keepalived stop
什么是实例,其实就是一个虚拟出来的路由器,每个虚拟路由器对外提供指定的虚拟IP,而站点的域名就是要解析到虚拟IP上,对外提供访问。因此生产环境中往往一个服务(论坛、博客、主站等)就对应一个实例,而一个实例往往指定一个虚拟IP(当然也可以指定多个,这需要DNS轮询机制)。
Keepalived最多支持20个实例。
实例示意图:
[root@testnginx01 ~]# vim /etc/keepalived/keepalived.conf
! Configuration File for keepalived # 这一行为注释内容(使用叹号开头)
global_defs {
notification_email { # 对于通知邮件之设置完全可取消,因为生产中会用监控软件进行监控及报警。
wang_hz@suixingpay.com
}
notification_email_from Alexandre.Cassen@firewall.loc # 指定邮件之发件方。
smtp_server 10.1.1.225 # SMTP服务器
smtp_connect_timeout 30
router_id LVS_A # 路由器标识,这里可使用主机名。该路由器标识是对于真实服务器(自身)之标识。
vrrp_skip_check_adv_addr
vrrp_strict
vrrp_garp_interval 0
vrrp_gna_interval 0
}
# 下面部分就是一个实例(可理解为一个虚拟路由器)
vrrp_instance VI_1 { # 定义实例名。
state MASTER
interface eth0 # 虚拟IP地址绑定端口。
virtual_router_id 51 # 虚拟的路由器ID。注意:两个Keepalived之间必须一致,即表明它们组成了同一个虚拟路由器。
# 同一个实例(虚拟路由器),其虚拟路由器ID必须是相同的,即唯一的标识了一个实例。
priority 100 # 优先级值,数值越大优先级越高。对于是主还是备,这个值起着决定性作用。
# 官方建议优先级之间应该相差50。
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
}
}
对于相同实例中的主与备,其配置文件中的区别:
首先是设备标识
router_id
值不同,用于标识不同之物理主机。
其次状态是state
不同,只有一台为主机(MASTER),其他全为备(BACKUP)。
相应的,优先级priority
也不能相同。
但是,对于相同实例中的主节点与备节点,其实例名称 vrrp_instance
及 virtual_router_id
一定要相同,因为它们属于同一个实例,同一个虚拟路由器。
#更多关于Keepalived配置文件的信息,请查阅系统文档:
[root@LVS-A ~]# man keepalived.conf
在当前实验环境中,如果两台服务器(一主一备)上配置好了配置文件,那么启动keepalived
服务后就可以正式的投入使用了。注意:虚拟的IP地址无法通过ifconfig
指令获取到,需要使用下面的指令:
[root@LVS-A ~]# ip add
...
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:0c:29:4a:4a:c0 brd ff:ff:ff:ff:ff:ff
inet 172.16.1.25/24 brd 172.16.1.255 scope global eth0
inet 192.168.0.200/24 scope global eth0 #主节点上的虚拟IP已经绑定。
inet6 fe80::20c:29ff:fe4a:4ac0/64 scope link
最后的的实验结果不再进行说明,主节点宕机(或Keepalived服务停掉)后,虚拟IP自动被备节点接管。而当主节点恢复时,又会重新的接管虚拟IP。这就是Keepalived对于IP资源的高可用。
默认情况下,Keepalived的日志为/var/log/messages
:
...
Dec 12 10:37:02 LVS-A Keepalived_vrrp: VRRP_Instance(VI_1) Transition to MASTER STATE
Dec 12 10:37:03 LVS-A Keepalived_vrrp: VRRP_Instance(VI_1) Entering MASTER STATE
Dec 12 10:37:03 LVS-A Keepalived_vrrp: VRRP_Instance(VI_1) setting protocol VIPs.
Dec 12 10:37:03 LVS-A Keepalived_vrrp: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth1 for
192.168.10.10
Dec 12 10:37:03 LVS-A Keepalived_healthcheckers: Netlink reflector reports IP 192.168.10.10 added
Dec 12 10:37:08 LVS-A Keepalived_vrrp: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth1 for
192.168.10.10
在实际的生产环境中,我们的Keepalived日志有可能特别多,这样的话为方面查看就需要单独指定日志文件。
[root@LVS-A ~]# cat /etc/sysconfig/keepalived
# Options for keepalived. See `keepalived --help' output and keepalived(8) and
# keepalived.conf(5) man pages for a list of all options. Here are the most
# common ones :
#
# --vrrp -P Only run with VRRP subsystem.
# --check -C Only run with Health-checker subsystem.
# --dont-release-vrrp -V Dont remove VRRP VIPs & VROUTEs on daemon stop.
# --dont-release-ipvs -I Dont remove IPVS topology on daemon stop.
# --dump-conf -d Dump the configuration data.
# --log-detail -D Detailed log messages.
# --log-facility -S 0-7 Set local syslog facility (default=LOG_DAEMON)
#
KEEPALIVED_OPTIONS="-D"
#我们将上一行修改为:
KEEPALIVED_OPTIONS="-D -d -S 0"
-------------------------------
#接下来修改日志服务的配置文件,添加相应的配置内容:
[root@LVS-A ~]# vim /etc/rsyslog.conf
# keepalived log
local0.* /var/log/keepalived.log
#重启日志服务及Keepalived服务:
[root@LVS-A ~]# /etc/init.d/rsyslog restart
[root@LVS-A ~]# /etc/init.d/keepalived restart
首先我们在LVS调度器上查看都有哪些RS节点:
[root@LVS-A ~]# 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.1.26:80 rr persistent 20
-> 172.16.1.10:80 Route 1 0 0
-> 172.16.1.12:80 Route 1 0 0
Keepalived是对LVS的另外一种管理方式,但是它本身并不调用ipvsadm
指令,而是通过自己的接口对LVS进行管理。
#下面是LVS调度器主节点的完整配置文件:
! Configuration File for keepalived
global_defs {
notification_email {
49000448@qq.com
}
notification_email_from Alexandre.Cassen@firewall.loc
smtp_server 10.0.0.1
smtp_connect_timeout 30
router_id LVS-A
}
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 55
priority 150
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
172.16.1.26/24
}
}
virtual_server 172.16.1.26 80 { #上面的虚拟路由器IP就是这里虚拟服务器的IP地址。实际上这个完整的配置文件做了两个工作,首先定义了虚拟路由器,然后为这个虚拟的路由器添加真实服务器节点。
delay_loop 6
lb_algo wrr #定义LVS的调度算法。
lb_kind DR #定义LVS的工作模式。
nat_mask 255.255.255.0
persistence_timeout 300 #定义支持持久连接的时长。
protocol TCP
real_server 172.16.1.10 80 { #每一组都要用花括号定义自有的属性。
weight 1 #定义权重。
TCP_CHECK {
connect_timeout 8
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
real_server 172.16.1.12 80 {
weight 1
TCP_CHECK {
connect_timeout 8
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
}
#ipvsadm -a -t 10.0.0.29:80 -r 10.0.0.17:80 -g -w 1
#ipvsadm -a -t 10.0.0.29:80 -r 10.0.0.18:80 -g -w 1
注意:虽然借助Keepalived可以方便的管理LVS,但是RS节点VIP的绑定以及ARP的抑制还是要进行的,因为这时DR模式必须要进行的操作,Keepalived并不能帮我们完成这些工作。
参考资料:keepalived高级应用解析
这里犯了一个愚蠢的错误,明明Keepalived已经为主节点分配了VIP,还要去手动绑定VIP,结局就是由于在同一块网卡上绑定同一个IP地址,所以会导致下面的报错信息:
[root@LVS-A ~]# ifconfig eth0:0 172.16.1.26/24 up
SIOCGIFADDR: Cannot assign requested address
SIOCSIFBROADCAST: Cannot assign requested address
SIOCSIFFLAGS: Cannot assign requested address
SIOCSIFFLAGS: Cannot assign requested address
所以说,Keepalived已经在LVS调度器上接管了所有的管理任务,包括分配VIP以及添加相应的RS节点,我们需要做的就是把主配置文件配置好即可,剩下的工作就交给Keepalived吧。
#这里把主节点的Keepalived服务停掉,那么作为LVS调度器上的所有配置信息将一并消失。
[root@LVS-A ~]# /etc/init.d/keepalived stop
Stopping keepalived: [ OK ]
[root@LVS-A ~]# ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
另外,官方的说明建议打开转发功能,但是就目前为止,我们没有打开转发功能,但是也运转正常,但是如果是NAT模式就一定要打开转发功能。
[root@LVS-A ~]# sysctl -p
net.ipv4.ip_forward = 0 #这里显示没有打开转发功能。
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
...
#通过下面的操作打开转发功能:
[root@LVS-A ~]# vim /etc/sysctl.conf
net.ipv4.ip_forward = 1
[root@LVS-A ~]# echo "1" >/proc/sys/net/ipv4/ip_forward
[root@LVS-A ~]# ipvsadm -Ln --stats
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
-> RemoteAddress:Port
TCP 172.16.1.26:80 27 235 0 25439 0
-> 172.16.1.10:80 0 0 0 0 0
-> 172.16.1.12:80 8 56 0 5805 0
--------------------------------------------
[root@LVS-A ~]# ipvsadm -Lnc
IPVS connection entries
pro expire state source virtual destination
--------------------------------------------
[root@LVS-A ~]# ipvsadm -Ln --thresholds
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Uthreshold Lthreshold ActiveConn InActConn
-> RemoteAddress:Port
TCP 172.16.1.26:80 wrr persistent 300
-> 172.16.1.10:80 0 0 0 0
-> 172.16.1.12:80 0 0 0 0
--------------------------------------------
[root@LVS-A ~]# ipvsadm -Ln --timeout
Timeout (tcp tcpfin udp): 30 5 60
HTTP服务的高可用。
MySQL数据库服务的高可用。
反向代理得高可用(Keepalived+Nginx/HAProxy)。
95%的互联网企业会选择DR模式作为LVS集群的工作模式。当然也有可能不用LVS,而是直接使用Nginx和HAProxy。我们在IDC机房租用租用带宽托管服务器时,一般情况是从IDC的上级交换机或路由器接出来一根以太网网线,接到我们自己的交换机上就可以配置公网地址了。
在DR模式下。所有提供对外服务的RS节点最好是均配置有外网地址,当然也可以为所有的RS节点指定一个网关接口,但是很有可能这个网关又会成为业务的瓶颈。
对于LVS基本上不需要进行什么额外的优化,它就可以运行的很好,如果说有优化,就是对内核的优化。
在生产中很可能会有多实例互为主从的配置(这样的话就可以让互为主备的负载均衡器都能提供服务,而不是一个工作一个热备,这样也可以充分利用资源并减轻单个负载均衡器的压力)。其实就是两边都是多实例,但是同一个VIP在同一时间内只能在一边提供服务。每个实例一般就是一个业务服务,一组LVS的全部实例可能多达几十或上百个。
有些公司还利用交换机的OSPF路由实现LVS多主的模式:http://my.oschina.net/lxcong/blog/143904