Keepalive 基础概要及简单示例
来源:互联网 发布:图文直播系统源码 编辑:程序博客网 时间:2024/05/17 03:16
keepalive简介
keepalive的目标是为Linux系统和基于Linux的基础设施提供简单而强大的负载平衡和高可用性保障。负载平衡框架依赖于众所周知的广泛使用的Linux虚拟服务器(IPVS) 内核模块,提供Layer4负载平衡。Keealived动态的管理负债均衡的服务器群,实现服务器的健康检测。而了解keepalive,就不得不了解VRRP协议,keepalived正是以vrrp的工作逻辑来工作的,那么我们就先了解VRRP协议是什么样的协议,再了解keepalived。
keepalived是lvs的扩展项目,因此它们之间具备良好的兼容性。通过对服务器池对象的健康检查,实现对失效机器/服务的故障隔离。负载均衡器之间的失败切换failover,是通过VRRPv2(Virtual Router Redundancy Protocol)stack实现的 。
VRRP 协议
VRRP协议概述
随着Internet的发展,人们对网络的可靠性的要求越来越高。对于局域网用户来说,能够时刻与外部网络保持联系是非常重要的。
通常情况下,内部网络中的所有主机都设置一条相同的缺省路由,指向出口网关(即图1中的路由器RouterA),实现主机与外部网络的通信。当出口网关发生故障时,主机与外部网络的通信就会中断。
配置多个出口网关是提高系统可靠性的常见方法,但局域网内的主机设备通常不支持动态路由协议,如何在多个出口网关之间进行选路是个问题。
IETF(Internet Engineering Task Force,因特网工程任务组)推出了VRRP(Virtual Router Redundancy Protocol)虚拟路由冗余协议,来解决局域网主机访问外部网络的可靠性问题。
VRRP是一种容错协议,它通过把几台路由设备联合组成一台虚拟的路由设备,并通过一定的机制来保证当主机的下一跳设备出现故障时,可以及时将业务切换到其它设备,从而保持通讯的连续性和可靠性。
使用VRRP的优势在于:既不需要改变组网情况,也不需要在主机上配置任何动态路由或者路由发现协议,就可以获得更高可靠性的缺省路由。
VRRP的基本概念
VRRP的工作原理
VRRP将局域网的一组路由器构成一个备份组,相当于一台虚拟路由器。局域网内的主机只需要知道这个虚拟路由器的IP地址,并不需知道具体某台设备的IP地址,将网络内主机的缺省网关设置为该虚拟路由器的IP地址,主机就可以利用该虚拟网关与外部网络进行通信。
VRRP将该虚拟路由器动态关联到承担传输业务的物理路由器上,当该物理路由器出现故障时,再次选择新路由器来接替业务传输工作,整个过程对用户完全透明,实现了内部网络和外部网络不间断通信。
如上图所示,虚拟路由器的组网环境如下:
RouterA、RouterB和RouterC属于同一个VRRP组,组成一个虚拟路由器,这个虚拟路由器有自己的IP地址172.18.14.1。虚拟IP地址可以直接指定,也可以借用该VRRP组所包含的路由器上某接口地址。
物理路由器RouterA、RouterB和RouterC的实际IP地址分别是172.18.14.10、172.18.14.11、172.18.14.12
局域网内的主机只需要将缺省路由设为172.18.14.1即可,无需知道具体路由器上的接口地址。
主机利用该虚拟网关与外部网络通信。路由器工作机制如下:
- 根据优先级的大小挑选Master设备。Master的选举有两种方法:
- 比较优先级的大小,优先级高者当选为Master。
- 当两台优先级相同的路由器同时竞争Master时,比较接口IP地址大小。接口地址大者当选为Master。
- 其它路由器作为备份路由器,随时监听Master的状态。
- 当主路由器正常工作时,它会每隔一段时间(Advertisement_Interval)发送一个VRRP组播报文,以通知组内的备份路由器,主路由器处于正常工作状态。
- 当组内的备份路由器一段时间(Master_Down_Interval)内没有接收到来自主路由器的报文,则将自己转为主路由器。一个VRRP组里有多台备份路由器时,短时间内可能产生多个Master,此时,路由器将会将收到的VRRP报文中的优先级与本地优先级做比较。从而选取优先级高的设备做Master。
VRRP的状态机
VRRP协议中定义了三种状态机:初始状态(Initialize)、活动状态(Master)、备份状态(Backup)。其中,只有处于活动状态的设备才可以转发那些发送到虚拟IP地址的报文。
Initialize
- 设备启动时进入此状态,当收到接口Startup的消息,将转入Backup或Master状态(IP地址拥有者的接口优先级为255,直接转为Master)。在此状态时,不会对VRRP报文做任何处理。
Master 当路由器处于Master状态时,它将会做下列工作:
- 定期发送VRRP报文。
- 以虚拟MAC地址响应对虚拟IP地址的ARP请求。
- 转发目的MAC地址为虚拟MAC地址的IP报文。
- 如果它是这个虚拟IP地址的拥有者,则接收目的IP地址为这个虚拟IP地址的IP报文。否则,丢弃这个IP报文。
- 如果收到比自己优先级大的报文则转为Backup状态。
- 如果收到优先级和自己相同的报文,并且发送端的主IP地址比自己的主IP地址大,则转为Backup状态。
- 当接收到接口的Shutdown事件时,转为Initialize。
Backup 当路由器处于Backup状态时,它将会做下列工作:
- 接收Master发送的VRRP报文,判断Master的状态是否正常。
- 对虚拟IP地址的ARP请求,不做响应。
- 丢弃目的MAC地址为虚拟MAC地址的IP报文。
- 丢弃目的IP地址为虚拟IP地址的IP报文。
- Backup状态下如果收到比自己优先级小的报文时,丢弃报文,不重置定时器;如果收到优先级和自己相同的报文,则重置定时器,不进一步比较IP地址。
- 当Backup接收到MASTER_DOWN_TIMER定时器超时的事件时,才会转为Master。
- 当接收到接口的Shutdown事件时,转为Initialize。
负载分担
现在允许一台路由器为多个作备份。通过多虚拟路由器设置可以实现负载分担。
负载分担方式是指多台路由器同时承担业务,因此需要建立两个或更多的备份组。
负载分担方式具有以下特点:
- 每个备份组都包括一个Master设备和若干Backup设备。
- 各备份组的Master可以不同。
同一台路由器可以加入多个备份组,在不同备份组中有不同的优先级。
!如图所示:配置两个备份组:组1和组2;
RouterB在备份组1中作为Master,在备份组2中作为Backup;
RouterC在备份组1和2中都作为Backup;
RouterA在备份组2中作为Master,在备份组1中作为Backup。
一部分主机使用备份组1作网关,另一部分主机使用备份组2作为网关。
这样,以达到分担数据流,而又相互备份的目的。
Kepalive基础
Keepalive体系结构
- Keepalived 大致分两层结构:用户空间 user space和内核空间 kernel space
在这个结构图里,处于下端的是内核空间,它包括IPVS和NETLINK两个部分。netlink提供高级路由及其他相关的网络功能,如果在负载均衡器上启用netfilter/iptable,将会直接影响它的性能。处于图形上方的组件为用户空间,由它来实现具体的功能,下面选取几个重要的来做说明:
- WatchDog 负责监控checkers和VRRP进程的状况;
- Checkers 负责真实服务器的健康检查healthchecking,是keepalived最主要的功能;
- VRRP Stack负责负载均衡器之间的失败切换FailOver;
- IPVS wrapper 用来发送设定的规则到内核ipvs代码;Netlink Reflector 用来设定 vrrp 的vip地址等。
- 在Linux主机上,以daemon(守护进程)方式实现了vrrp协议,并提供了完成配置ipvs规则及实现相应real server状态检测能力。
- 能调用外部脚本
- 轻量灵活,不能解决脑裂问题(需要依靠其他措施来解决)
Keepalived正常运行时,会启动3个进程,分别是core、check和vrrp:
- vrrp模块是来实现VRRP协议的;
- check负责健康检查,包括常见的各种检查方式;
- core模块为keepalived的核心,负责主进程的启动、维护以及全局配置文件的加载和解析。
注意:
- keepalived的启动过程并不会对配置文件进行语法检查,就算没有配置文件,keepalived的守护进程照样能够被运行起来。在不指定配置文件位置的状态下—keepalived默认先查找文件
- /etc/keepalived/keepalived.conf ,可以手动创建这个文件,然后在这个文件里书写规则,来达到控制keepalived运行的目的。
keepalived特性:
- vrrp协议的软件实现,原生设计的目的为了高可用ipvs服务:
- vrrp协议完成地址流动;
- 为vip地址所在的节点生成ipvs规则(在配置文件中预先定义);
- 为ipvs集群的各RS做健康状态检测;
- 基于脚本调用接口通过执行脚本完成脚本中定义的功能,进而影响集群事务;
KeepAlive的配置文件解释:
- 全局定义块,必须存在:
global_defs { notification_email { a@abc.com b@abc.com ##故障发生时给谁发邮件通知 } notification_email_from c@abc.com ##通知邮件从哪个地址发出 smtp_server 172.18.14.168 ##通知邮件的smtp地址 smtp_connect_timeout 30 ## 连接smtp服务器的超时时间 router_id LVS_DEVEL ##标识本节点的字条串,故障发生时,邮件通知会用到}
- vrrp_script区域主要用来做健康检查的,当时检查失败时会将vrrp_instance的priority减少相应的值。(自定义脚本)
vrrp_script chk_http_port { script "path to scirpts " :检测脚本 interval 1 :检测周期 weight -10 :当发生检测失败事件,权重较低多少}
- VRRP实例定义块主要用来定义对外提供服务的VIP区域及其相关属性:
vrrp_instance VI_1 { state MASTER ##可以是MASTER或BACKUP,不过当其他节点keepalived启动时会将priority比较大的节点选举为MASTER interface IFACE_NAME ##绑定为当前虚拟路由器使用的物理接口; priority 100 ## 当前主机在此虚拟路径器中的优先级;范围1-254; virtual_router_id 1 ## 取值在0-255之间,用来区分多个instance的VRRP组播, 同一网段中该值不能重复,并且同一个vrrp实例使用唯一的标识,即虚拟路由器id advert_int 1 ##发VRRP包的时间间隔,即多久进行一次master选举,可以认为是健康查检时间间隔,单位为秒 authentication { auth_type PASS ##认证类型有PASS和AH(IPSEC),通常使用的类型为PASS,同一vrrp实例MASTER与BACKUP 使用相同的密码才能正常通信 auth_pass 12345678 virtual_ipaddress { ##可以有多个VIP(虚拟路由器)地址,每个地址占一行,不需要指定子网掩码,必须与RealServer上设定的VIP相一致 #指明虚拟ip地址,配置在哪个网卡/网卡别名 <IPADDR>/<MASK> brd <IPADDR> dev <STRING> scope <SCOPE> label <LABEL> 172.18.14.1 } track_script { #调用自定义脚本 即vrrp_script区域的脚本 chk_http_port #要调用的自定义名称} track_interface { #跟踪监视机制一旦接口出现故障,则转为FAULT状态 eth0 eth1 }nopreempt:#定义工作模式为非抢占模式;(如果不加,就默认抢占模式)preempt_delay 300:#抢占式模式下,节点上线后触发新选举操作的 notify_master <STRING>|<QUOTED-STRING>:当前节点成为主节点时(master状态)触发的通知脚本; notify_backup <STRING>|<QUOTED-STRING> #切换为备用(backup)时的通知脚本 notify_fault <STRING>|<QUOTED-STRING> #出错时(faulty状态)的通知脚本 notify <STRING>|<QUOTED-STRING> #表示任何状态都会触发的通知脚本,并且该脚本在以上三个脚本执行完成之后进行调用,keepalived会自动传递三个参数:($1 = "GROUP"|"INSTANCE",$2 = name of group or instance,$3 = target state of transition(MASTER/BACKUP/FAULT))1}}
- 虚拟服务器定义块
virtual_server 172.18.14.1 80 { ##定义RealServer对应的VIP及服务端口,必须与RealServer上设定的VIP相一致 delay_loop 6 ##延迟轮询时间(单位秒) lb_algo rr ## 后端调试算法(load balancing algorithm ) lb_kind NAT ##LVS调度类型NAT/DR/TUN nat_mask 255.255.0.0 persistence_timeout 50 ##持久连接超时时间 protocol TCP ##转发协议protocol.一般有TCP和UDP两种 sorry_server ##当所有RealServer宕机时,sorry server顶替 real_server 192.168.200.100 80 { ##RealServer的IP和端口号,改组可在下面定义多个 weight 1 HTTP_GET { url { path / ##请求Real Serserver上的路径 digest ff20ad2481f97b1754ef3e12ecd3a9cc status_code 200 ##用genhash算出的结果和http状态码 } connect_timeout 3 ##超时时长 nb_get_retry 3 ##重试次数 delay_before_retry 3 ##下次重试的时间延迟 } }}
虚拟服务器的常用参数: delay_loop <INT>:#服务轮询的时间间隔; lb_algo rr|wrr|lc|wlc|lblc|sh|dh:#定义调度方法; lb_kind NAT|DR|TUN:#集群的类型; persistence_timeout <INT>:#持久连接时长; protocol TCP:#服务协议,仅支持TCP; sorry_server <IPADDR> <PORT> ##备用服务器地址; real_server <IPADDR> <PORT> { weight <INT> notify_up <STRING>|<QUOTED-STRING> notify_down <STRING>|<QUOTED-STRING> HTTP_GET|SSL_GET|TCP_CHECK|SMTP_CHECK|MISC_CHECK { ... }:##定义当前主机的健康状态检测方法; } HTTP_GET|SSL_GET:#应用层检测 HTTP_GET|SSL_GET { url { path <URL_PATH>:#定义要监控的URL; status_code <INT>:#判断上述检测机制为健康状态的响应码; digest <STRING>:#判断上述检测机制为健康状态的响应的内容的校验码; } nb_get_retry <INT>:#重试次数; delay_before_retry <INT>:#重试之前的延迟时长; connect_ip <IP ADDRESS>:#向当前RS的哪个IP地址发起健康状态检测请求 connect_port <PORT>:#向当前RS的哪个PORT发起健康状态检测请求 bindto <IP ADDRESS>:#发出健康状态检测请求时使用的源地址; bind_port <PORT>:#发出健康状态检测请求时使用的源端口; connect_timeout <INTEGER>:#连接请求的超时时长; } TCP_CHECK { connect_ip <IP ADDRESS>:#向当前RS的哪个IP地址发起健康状态检测请求 connect_port <PORT>:#向当前RS的哪个PORT发起健康状态检测请求 bindto <IP ADDRESS>:#发出健康状态检测请求时使用的源地址; bind_port <PORT>:#发出健康状态检测请求时使用的源端口; connect_timeout <INTEGER>:#连接请求的超时时长; }
Keepalive示例
简易keepalive
node1配置:/etc/keepalived/keepalived.conf
node2配置:/etc/keepalived/keepalived.conf
接着在两台节点都重启keepalived服务(节点1为master,节点2为backup),节点1,注意观察标记部分,进入了master 模式, 并获取的虚拟路由器ip.
节点2,注意标记部分,收到了高优先级虚拟路由器通告,进入backup模式,主动释放虚拟路由器iP(VIP)
接着人为的把节点1keepalived模式关闭,然后观察节点2 keepalived 状态,可以发现节点2收不到master的通告,由backup模式转入master模式,并获取VIP 地址。
双主模型
双主模型:简单来说,就是在VRRP2中,Router A 是Master状态,router B 是Backup状态;而在VRRP1中,Router A 是 Backup状态,router B 是Master状态。
下面请看配置示例:
节点A:
节点2配置:
之后再重启,验证方法不再复述,自行回去复习哦。
探测网卡,查看arp广播发送情况 。
[root@localhost ~]# tcpdump -i eno16777736 -nn host 224.0.14.14
通知脚本的使用方式(示例):
1、编写通知脚本,节点A,B都一样:由于截图关系导致截图补全(最上面是shell脚本的shellbang,#!/bin/bash)
2、修改/etc/keepalived/keepalived.conf配置文件:
关闭、重启两个节点的keepalived服务,查看邮件是否发送
高可用LVS 集群:
一、单主配置模式(一主一备),采用lvs-dir模型,采用五台主机,两个DS,两台RS,一台client测试机
1、对2台RS主机分别安装httpd服务,编辑配置文件,以示区分。
RS1
RS2
2、分别对2台RS,配置vip,开启 arp_ignore,arp_announce选项,配置主机路由,这里采用脚本的形式:
对RS1进行lvs-dir相关操作:
编写脚本,再执行脚本
[root@localhost scripts]# cat rs.sh #!/bin/bash#iface=eth0case $1 instart) echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore echo 1 > /proc/sys/net/ipv4/conf/${iface}/arp_ignore echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce echo 2 > /proc/sys/net/ipv4/conf/${iface}/arp_announce ;;stop) echo 0 > /proc/sys/net/ipv4/conf/all/arp_ignore echo 0 > /proc/sys/net/ipv4/conf/${iface}/arp_ignore echo 0 > /proc/sys/net/ipv4/conf/all/arp_announce echo 0 > /proc/sys/net/ipv4/conf/${iface}/arp_announce ;;*) echo "usage $(basename $0) start|stop" exit 1 ;;esac
RS1添加vip ,添加主机路由:
RS2:操作方式和RS1一样,不在复述。
对DS1 keepalive的配置文件进行修改:
对DS2 keepalive的配置文件进行修改:
重启各个DS的keepalive ,在客户机测试结果:
测试keepalive健康状态检测:(蓄意关闭RS1的httpd)
[root@localhost scripts]# service httpd stopStopping httpd: [ OK ]
在DS1进行lvs集群信息查看:(已有一台RS自动被移除。)
测试DS的sorry server功能:
再将另一台RS关闭(模拟故障) [root@bnpanda script]#systemctl stop httpd
在DS1查看集群信息:已成功转入DS1的错误server
在客户端进行验证:(错误页正常显示)
再将DS1认为关闭,模拟故障:
到DS2查看ip信息,虚拟ip(172.18.14.1)已转到DS2:
客户端测试:(DS2 sorry server发挥作用)
双主模型
基本原则和单主模型一致,需要注意的是,双主模式,存在两个VIP,RS1,RS2需要配置两个VIP,都需要配置两个主机路由,DS1,DS2,keepalive 的/etc/keepalived/keepalived.conf配置文件需要配置两个虚拟路由器,两个虚拟服务器:
DS1配置文件:
[root@localhost keepalived]# cat keepalived.conf! Configuration File for keepalivedglobal_defs { notification_email { root@localhost } notification_email_from keepalived@localhost smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id node1 vrrp_mcast_group4 224.0.14.14}vrrp_instance myr1 { state MASTER interface eno16777736 virtual_router_id 78 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 172.18.14.1/16 dev eno16777736 } notify_master "/etc/keepalived/notify.sh master" notify_backup "/etc/keepalived/notify.sh backup" notify_fault "/etc/keepalived/notify.sh fault"}vrrp_instance myr2 { state BACKUP interface eno16777736 virtual_router_id 79 priority 98 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 172.18.14.2/16 dev eno16777736 }}virtual_server 172.18.14.1 80 { delay_loop 3 lb_algo rr lb_kind DR protocol TCP sorry_server 127.0.0.1 80 real_server 172.18.14.197 80 { weight 1 HTTP_GET { url { path / status_code 200 } connect_timeout 3 nb_get_retry 3 delay_before_retry 3 } } real_server 172.18.14.16 80 { weight 1 HTTP_GET { url { path / status_code 200 } connect_timeout 3 nb_get_retry 3 delay_before_retry 3 } }}virtual_server 172.18.14.2 80 { delay_loop 3 lb_algo rr lb_kind DR protocol TCP sorry_server 127.0.0.1 80 real_server 172.18.14.197 80 { weight 1 HTTP_GET { url { path / status_code 200 } connect_timeout 3 nb_get_retry 3 delay_before_retry 3 } } real_server 172.18.14.16 80 { weight 1 HTTP_GET { url { path / status_code 200 } connect_timeout 3 nb_get_retry 3 delay_before_retry 3 } }}
DS2配置文件:
[root@localhost keepalived]# cat keepalived.conf! Configuration File for keepalivedglobal_defs { notification_email { root@localhost } notification_email_from keepalived@localhost smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id node1 vrrp_mcast_group4 224.0.14.14}vrrp_instance myr1 { state BACKUP interface eno16777736 virtual_router_id 78 priority 96 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 172.18.14.1/16 dev eno16777736 } notify_master "/etc/keepalived/notify.sh master" notify_backup "/etc/keepalived/notify.sh backup" notify_default "/etc/keepalived/notify.sh default"}vrrp_instance myr2{ state MASTER interface eno16777736 virtual_router_id 79 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 172.18.14.2/16 dev eno16777736 } notify_master "/etc/keepalived/notify.sh master" notify_backup "/etc/keepalived/notify.sh backup" notify_default "/etc/keepalived/notify.sh default"}virtual_server 172.18.14.1 80 { delay_loop 3 lb_algo rr lb_kind DR protocol TCP sorry_server 127.0.0.1 80 real_server 172.18.14.197 80 { weight 1 HTTP_GET { url { path / status_code 200 } connect_timeout 3 nb_get_retry 3 delay_before_retry 3 } } real_server 172.18.14.16 80 { weight 1 HTTP_GET { url { path / status_code 200 } connect_timeout 3 nb_get_retry 3 delay_before_retry 3 } }}virtual_server 172.18.14.2 80 { delay_loop 3 lb_algo rr lb_kind DR protocol TCP sorry_server 127.0.0.1 80 real_server 172.18.14.197 80 { weight 1 HTTP_GET { url { path / status_code 200 } connect_timeout 3 nb_get_retry 3 delay_before_retry 3 } } real_server 172.18.14.16 80 { weight 1 HTTP_GET { url { path / status_code 200 } connect_timeout 3 nb_get_retry 3 delay_before_retry 3 } }}
RS1添加VIP:(基于单主模型环境做的修改,额外添加一个vip)
#ifconfig lo:1 172.18.14.2 netmask 255.255.255.255 broadcast 172.18.14.2#route add -host 172.18.14.2 dev lo:1
RS2添加VIP:(基于单主模型环境做的修改,额外添加一个vip)
#ifconfig lo:1 172.18.14.2 netmask 255.255.255.255 broadcast 172.18.14.2#route add -host 172.18.14.2 dev lo:1
最后重启DS1,DS2,的keepalive
客户机测试:两个地址均能正常访问。
双主模型的高可用nginx proxy服务
采用DIR的模式,在两台RS上分别取消arp应答与通告
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore;echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore;echo 2 >/proc/sys/net/ipv4/conf/all/arp_anonouce;echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce;
两台主机添加两个VIP,启用两个主机路由(VIP的主机路由)
RS1: ifconfig lo:0 172.18.14.1 netmask 255.255.255.255 broadcast 172.18.14.1 uproute add -host 172.18.14.1 dev lo:0RS1: ifconfig lo:1 172.18.14.2 netmask 255.255.255.255 broadcast 172.18.14.2 uproute add -host 172.18.14.2 dev lo:1
RS2: ifconfig lo:0 172.18.14.1 netmask 255.255.255.255 broadcast 172.18.14.1 uproute add -host 172.18.14.1 dev lo:0RS2: ifconfig lo:1 172.18.14.2 netmask 255.255.255.255 broadcast 172.18.14.2 uproute add -host 172.18.14.1 dev lo:1
1、在两台代理上安装好nginx :
DS 1:
配置/etc/nginx/nginx.conf:
在http上下文内部定义一个 upstream:
[root@localhost keepalived]# vim /etc/nginx/conf.d/default.conf 在默认的location内部直接添加 proxy_pass http://websrv
DS2的nginx配置和DS1基本一致
2配置keepalived
DS1: [root@localhost keepalived]# vim keepalived.conf
(/etc/keepalived/keepalived.conf)
解释一下:
vrrp_script ngxstatus { #此处为ngx状态检测脚本: script 'killall -0 nginx && exit 0 || exit 1' interval 1 #探测间隔 weight -5 #如果探测到nginx未启动,权重下降度5 } track_script {#调用自定义脚本 ngxstatus #(调用之前定义的status脚本) }
注意:自定义脚本请先定义,再调用,且在虚拟路由器实体中调用
此处自定义脚本的作用:当探测到本机nginx服务没有启动,就自动的把权重减5.使其从master变为backup,实现了主nginx故障的时候,业务能更换到备nginx上。即实现了nginx的双机备份。
DS2方式和DS1 类似 注意vrrp master,priority即可
3、重启nginx和keealive 两台都要操作(建议systemctl stop keepalive和systemctl startt keepalive):避免操作失效
4到客户端测试:
5、人为关闭DNS1的keepalive,到DNS2观察 VIP是否已经获取到了。
6、重启DNS1 的keepalive,观察是否获取
7、DS1 关闭nginx,保持keepalived开启,查看DNS2是否获取vip,是否实现了nginx的故障切换,实现nginx高可用集群。
8、DNS1,重新启动nginx,查看是否重新获取ip,
附加测试:问:ipvs使用持久连接时,故障切换后,同一个客户端是否依然能关联至此前绑定的RS?
DS两台,RS两台,client一台
1、ipvs使用持久连接:
采用DIR模式:
RS1,RS2
采用DIR的模式,在两台RS上分别取消arp应答和通告:
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore;echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore;echo 2 >/proc/sys/net/ipv4/conf/all/arp_anonouce;echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce;
两台主机添加两个VIP,启用两个主机路由(VIP的主机路由)
RS1: ifconfig lo:0 172.18.14.1 netmask 255.255.255.255 broadcast 172.18.14.1 uproute add -host 172.18.14.1 dev lo:0RS2: ifconfig lo:0 172.18.14.1 netmask 255.255.255.255 broadcast 172.18.14.1 uproute add -host 172.18.14.1 dev lo:0
DS1 keepalived 配置 /etc/keepalived/keepalived.conf
DS2:配置 /etc/keepalived/keepalived.conf
在客户端测试:(因为持久连接的缘故,所以都是同一个页面)
现在,把RS1的 httpd关闭:
再次测试:业务成功转移到RS2
再次回复RS1 的httpd
关闭DS1 的keepalived
再次测试:访问的依旧是原来的页面
附加测试:问:ipvs使用sh算法时,故障切换后,同一个客户端是否依然能关联至此前绑定的RS?
基础配置和上述的基本一致,主要就是设定算法的地方有所区别:
DS1
DS2
经过测试:
第一次访问
关闭DS1 的keepalive
再次测试:(业务成功迁移)
保证DS1 和DS2 的keepalived服务开启,将RS1的httpd关闭,即使在SH算法下,业务也能够正常迁移
问:nginx使用ip_hash算法时,故障切换后,同一个客户端是否依然能关联至此前绑定的upstream server?
本次实验采用的单主模式:(双主模式请到前文去找了啦)
IP_hash 算法:
1、准备nginx的负载均衡配置:
DS1:
安装nginx:
修改/etc/nginx/nginx.conf,在http上下文中增加 upstram
注:server 172.18.14.197:80 表示的是RS1,server 172.18.14.33:80表示的RS2,可以根据实际修改配置,而127.0.0.1:8080是本机的sorry server(这里选用的是http,已更改监听端口为8080,可根据实际需要修改)
修改/etc/nginx/conf.d/default.conf,直接在location内添加代理语句:(proxy_pass http://websrv)
上图使用的是ip_hash算法
DS2:
安装方法,和配置方式和DS1基本一致哦,除了sorry sever需要写自己本机的地址(或者写其他sorry server的ip地址也没问题啦。看个人想法)
2、准备 keepalived 配置 (编辑自定义脚本,使用killall时,确保系统安装了 psmisc 程序包 啊!)
DS1配置文件:
DS2配置文件:
(改配置前文有类似的实验,具体验证方法前文也有说明,此处不再负叙述,已经过验证,当DS1 nginx服务down掉,ip是能够转移到DS2上的)
测试:在所有业务都正常开启的时候 ,由于ip_hash算法,都被定位到RS2 上
故障测试:将RS2 web服务(httpd)关闭,再从客户端浏览访问:,此次业务并未终端,成功迁移到RS1上。
问:nginx使用hash
DS1:
/etc/nginx/nginx.conf
DS2 nginx配置文件:
所有服务均正常的情况(keepalive ,nginx,httpd开启):
将RS2 web服务关闭:
将所有服务恢复:访问测试
A、关闭 DS1 的nginx:再进行访问测试:
B、 启动 DS1 的nginx:再进行访问测试:
- Keepalive 基础概要及简单示例
- 并行编程OpenMP基础及简单示例
- Android应用程序基础及原理概要
- Android-应用程序基础及原理概要
- PhantomJS基础及示例
- nginx基础概念-keepalive
- 基础概要
- LINQ基础_简单示例
- Log4J基础详解及示例
- Log4J基础详解及示例
- Json基础及常用示例
- log4j基础详解及示例
- Docker基础入门及示例
- Docker基础入门及示例
- Docker基础入门及示例
- Docker基础入门及示例
- RMI简介及简单示例
- iBATIS介绍及简单示例
- Ubuntu 删除安装软件
- 《java设计模式》:装饰者模式
- SAP HANA XS ODATA使用参数展示数据结构
- 动态规划测试test20170511
- QStringList用法总结
- Keepalive 基础概要及简单示例
- JavaSwing中itemStateChanged事件执行两次
- 目标检测的图像特征提取之(四)OpenCV中BLOB特征提取与几何形状分类
- Android--自定义控件(组合系统控件)
- [设计模式]策略模式(strategy)---算术运算
- 【BZOJ】4034 [HAOI2015]树上操作 树链剖分
- Angular-cli的安装(首先你一定要先安装node.js)
- JavaScript笔记
- SAP ODATA官网提供测试内容