**keepalived是高可用集群的解决方案 HA cluster
实现思路与开源中主流的corovs和heatbeat有所不同
keepalived根本上是VRRP协议的实现,而VRRP协议无非就是在路由器上实现地址流动,地址 floating,floating IP
而VRRP,是虚拟冗余路由协议 Virtual Router Redundancy Protocol
在keepalive中,vrrp协议只要靠vrrp_instance实例来作为一个虚拟路由器,
一个虚拟路由器通常由多个物理路由器组成(把物理服务器的相关网卡或者接口组织起来作为一个虚拟理由)
多个路由 绑定在一起就需要一个组VRID: virtual router id
就分成两种角色,一种是主路由器 master ,一种是备路由器backup
在一个虚拟路由器中,要么事一主一备,要么是一主多备
主服务就是通过不断在多播域中通告自己的优先级,RID,DOWN来实现所谓的心跳信息传递
到底谁是主谁是备就由优先级 priority 来判定(配置的时候应该是主的优先级高,备的优先级低)
工作模型,有两种,抢占模式和非抢占模式,
当主节点通告,备用节点发现其实自己优先级高,进而触发重新选举,进而变成主节点
非抢占模式,无论通告的对方,优先级高低,备用节点都无法抢占,只有等对方故障,或者不再通告时,才进行抢占,称为主节点
**
对于高可用集群来讲,心跳信息船体,如果是一主多备,需要把心跳信息传递给多个节点,这种传递方式在传统集群环境中,有单播,多播,和广播,一般都是用多播或组播域,组播就需要用到IPV4的D类地址。
keepalived识别成员关系的方法非常简单,在同一个组播域内就认为是集群的成员,因此这样的环节,是非常容易被滥竽充数,为了避免这种问题,需要在组播域中加消息验证,可以认为每个消息是加了签名信息的,如果对方没有一个签名信息,就解密不了这些消息,因此对方是看不到这个集群,也不允许加入集群中来的。
因此对于验证是非常重要的。
地址流动以后,备用节点其实在客户端一侧,它的mac地址是没有映射的,因此每一个节点在完成所谓的地址抢占(地址转移),就需要发送一个ARP,自问自答,来通告本地局域网当中的设备,都来更新自己的arp地址解析缓存,从而使得以后用指定的ip与之匹配的mac地址和当前真正的活动节点完成通讯
**keepalived除了 VRRP的inpretation协议以外
还有ipvs 的 wrapper 通过ipvs的wrapper 来调取内核中的IO/
从而实现对RS的修改,增加删除变动
IPVS wrapper的变动是参考checkers的检测的信息
checkers是对各VS的各RS的做健康检测
只要有应用层检测 HTTP——GET,ssl_get,smtp_check
也可以做传输层检测,TCP_check
自定义检测:MISC_check(比如高可用是一个ipvs服务器,ipvs反向代理调度的时候mysql应用,mysql如何做检测,很显然之前应用层的check方法做不到,tcp_check只能检测3306端口
所以就可以自定义脚本misc_check,可以让mysql服务器show databases,如果能看到某一个关心的数据库就认为是正确的,否则就认为错误,主要是根据脚本的返回值来决定是否成功
IPVS的DR模型虽然承载能力强大,但是配置起来比较麻烦,如果要构建双主模型,就不得不要使用两个VIP,每个RS都要使用几个VIP,还需要建立多个集群,可以使用fwmark 防火墙标记,把ip地址+端口,定义成同一个集群,
可以把不同地址+端口 第一成一个FWMARK
把fwmark做为集群就可以了,但是即便如此,后端的RS服务器上还是需要配置多个VIP地址,这是不可避免的
haproxy有一个web接口。可以直接看到图形状态接口 **
haproxy和nginx是代理模式,对于后端服务器来讲,收到的请求不是来自CIP还是前端的对应的代理服务器内网网卡地址
在代理服务器上是不要给内网上面配置多个节点的
链接数量的有限,主要是套接字有限,可以使用长连接,使用长链接以后,可以在一个端口上和套接字上,发送N次请求,
因此这样可以突破套接字限制,但是具体突破多少个,还需要解决非活动的链接
如果压力真的非常大,可以两级调度,前面LVS,后面NGINX,再把请求调度到真正的服务器上去(有可能是三级,因为nginx和后端RS可能有一个缓存层)
这样看来高可用nginx确实比高可用lvs好一些,简单很多
下面实现高可用nginx可以反代前端的请求
nginx代理的时候,一般RS是在内网中的私网地址,,nginx应该有两个接口,一个面向外网,一个内网,
用keepalived就需要在nginx的外网地址做高可用,基于VRRP协议流动一个IP地址,这个地址在哪个节点上,哪个节点就帮你转发请求,
如果可以,可以在外网网卡上做两个虚拟路由器,两个VIP,vip1上面为主下面为备,vip2上面为备下面为主,
DNS服务器将一个域名解析为两条A记录,所以用户请求可以有的分到vip1,可以分到vip2
可以把后端的RS做一个物理主机上搭建两个虚拟主机
先同步时间
nginx2服务器修改下hosts文件
nginx1服务器修改下hosts文件
nginx2配置临时地址
ping内网就可以了
现在指定内网服务器信息
无非就是配置几个地址,和搭建几个虚拟主机
配置多个地址成功
创建虚拟主机
目录不存在
创建目录
编辑主页
第二个第三个同理
启动服务
ping成功
keeapalived要想调用nginx服务,就需要用外部的辅助脚本来完成,
只要确定两个nginx的服务正在启动
1,想办法让地址移动到节点的时候,把nginx服务启动起来(所以keepalived就需要调用这样的脚本,用这个脚本来完成一些辅助的功能,
还可以用这个脚本来完成一些web监控,nginx是不是一直在运行着,当进程出现故障时,不管启动不启动,就需要把地址转移出去,降低当前节点的priority)
script 脚本名或者脚本路径
interval +每隔多长时间监控执行一次
weight—— 万一失败,当前节点的权重要减去多少,应该小于备用节点
调用脚本如何进行地址转移
**killall -0代表查询这个进程是否在,这条命令能不能执行,但是只是测试执行,
如果nginx进程在就代表这条命令可以正常执行,如果不在不可用执行
如果成功反回0 ,失败返回1(降权,失败一次认为失败就不太好,fall 2 代表失败两次,才认为是真的失败,
如果成功rise 1 成功就加上权限)
**
定义好脚本,在某个VRRP实例中用track _script来调用脚本
如果想在这个keepalived临时降权进行修复,只需要在这个文件里写上一个文件就可以了,如不降权,就把文件删除就可以了
现在用两个nginx服务器,做一个简单的高可用集群
安装以后复制之前的配置过来
把文件复制过去,做一些简单修改
修改一个虚拟地址
把内容整个复制一下,贴到另外的nginx服务器上
修改nginx2服务器配置文件
1,$d第一行到最后一行都删除需要修改这几项
加之前还需要复制脚本到nginx两个服务器,notify。sh
确保有执行权限
现在准备好了keepalived,如果期望用脚本来进行地址转移,可以加一个定义好的
vrrp_script_chk_down
现在可以先去编辑nginx一方的配置文件,定义一个脚本
如果这个文件就错误退出,如果不存在就正确
如果一旦脚本失败就降权 -10 (小于备用节点的96即可)
每隔多长时间执行 1s
fall 1 失败1次才认为错误退出
rise 1 成功一次就认为成功
还需要在后面定义调用这个脚本来实现地址转移的
在nginx2服务器上也这么定义
x现在就可以启动服务; 了
显示读取了这个文件,然后自己进入主节点状态,因为现在就一个节点启动
现在另外一个节点就会收到通告,现在启动另外一个服务器
现在两个节点都有两个网卡,理由信息主要关心哪块网卡,如果有必要可以选择只监控一块网卡
track interface 监控网卡工作状态
现在创建一个down文件
现在来使用status来查看
一旦失败下面就降了10个优先级,就收到了另外服务器优先级96的通告,地址就被移除了
现在nginx2服务器上就有地址了
现在这个广播域就是通告为96
现在删除down文件
地址就转义过去了
所以web脚本的执行状态就可以这么实现,因此就可以让它来监控nginx了,不仅可以监控nginx,还可以作为通知脚本(一旦当前主机发生状态,就可以被通知到,收到邮件)
一旦节点为主,就把nginx启动起来
一旦节点为备,就把nginx关闭
先安装nginx
nginx节点主要作为反代服务
修改配置文件
把这个配置文件给另外个nginx服务器也一份
先测一下语法
启动服务
客户端访问两个nginx服务器没有问题
现在修改文件,测试看看nginx服务是否进行正常
先写监控脚本,再去调用,(监控脚本就是用nginx服务决定优先级的一个因素)
一旦节点为主,就把nginx启动起来
一旦节点为备,就把nginx关闭
先把服务停了
修改脚本
另外一个服务器也需要这样的操作
现在两边都没有运行
现在创建一个down文件
node2现在变成了主节点
根据脚本nginx进程就启动了
删除down文件,备就会成主,就会启动nginx服务
node2现在就没有nginx进程了
但是不应该让备节点停止nginx,否则主节点变为备,备节点没有nginx进程
想要出现故障就重启或者启动nginx
‘
另外一个也修改一下’
再touch一个down文件
现在就nginx进程会保留下来了
另外一个节点就变成正常的了
现在客户端访问没有问题
现在把down文件删除了
对客户端来讲受影响的
node2虽然地址没了,但是进程还在
如果在nginx服务器上做监控该如何做
现在修改配置文件,来添加脚本
判断nginx进程是否存在,如果存在就成功,否则就失败
定义脚本
现在就需要监控脚本
另外的nginx节点也需要这样的内容
重启keepalived服务,生效
然后启动2节点上的服务
拿到地址了
变成主节点了
先是启用备用节点状态,然后启动nginx,发现自己优先级最高,成为主节点
现在访问没有任何问题
现在把主节点启动起来,地址加过来了没有问题
现在一样没有什么问题
**现在吧nginx进程关掉,看能否转移出去
**
修改配置文件,多检查几次
另外的节点也是一样的情况
现在重启服务
地址有了就可以进行访问了
现在启动主节点
地址应该已经 过来了
安装httpd
把nginxkill掉,然后立即把httpd服务开启
检查到nginx死了
nginx死掉以后地址就没有了
节点2地址就过去了
如果把httpd服务停止了,nginx会否启动起来
经过三次检查才能变成正常的,但是已经变成备用节点了,nginx启动失败,需要手动起来
手动起来检查就成功了
继续试验,这次 用删除down文件的办法
地址又转移了
节点2地址就加进来了
节点2上创建down文件
节点1停止httpd服务,由于节点2,down了,优先级比节点1低,所以节点1再次触发start
即使把down,地址也不会回来了
对nginx来做双主模型
复制内容进行修改成第二个虚拟路由
falt要删除,因为有两个虚拟路由,1出错了,不代表2出错,不能关掉
修改节点2
重启服务生效
节点1拿到77地址,节点2拿到78地址
访问77,78都没有问题
现在只要在互联网上把dns主机域名解析成2个地址
在生产中有可能还需要监控网卡,两个节点都需要加
现在来试试对于后端的健康性测试
现在把某个对应的80端口地址拒绝访问
现在就没有host2了
把规则去掉,host2就能恢复访问了