keepalived
什么是高可用
1.什么事高可用
当两台机器上启动着相同的业务时候，当有一台机器出现故障了，另外一台机器能够快速的接管，让访问的用户感知不到异常
2.主要目的
减少系统不能提供服务的时间
3.高可用使用什么方式实现
keepalived
4.keepalived如何实现高可用
keepalived基于VRRP（虚拟路由冗余协议），高可用提 供一个虚拟IP地址漂移的技术，能够让虚拟IP地址在节点之间移动
5.高可用与集群的区别
高可用与集群不同之处在于，高可用的机器之间是有感知的，集群的机器之间是没有感知的
高可用，同一时间只有一台在机器在启用，在对外提供服务
集群，同一时间有多台机器在启用，对外提供服务
配置keepalived高可用
1.双方通过选举的方式，确定谁是主节点谁是备节点，优先级高的一方就是主节点
2.如果在主节点故障后，备节点进行接管，那么主节点恢复后，会抢回虚拟IP吗？
情况一：抢占式，主节点恢复后，虚拟IP会被主节点抢回
情况二：非抢占式，当备节点接管后，备节点就成为了主节点，主节点恢复后就成为备节点
3.如果双方都认为自己是主节点，会出现脑裂的情况，双方不知道对方的存在，但是并不影响网站的访问。
keepalived案例
１.部署keepalived
yum install keepalived -y
２.配置keepalived
master
1.主节点配置
vim /etc/keepalived/keepalived.conf
global_defs {
router_id lb01 #标识节点的名称
}
vrrp_instance VI_1 {
state MASTER
priority 200 #配置优先级
interface eth0 #虚拟IP绑在哪个网络接口上
virtual_router_id 50 #路由ID，相当于把两个节点加到一个组中
advert_int 1 #检查间隔，1秒钟检查一次，检查主节点是否存活
authentication {
auth_type PASS #认证的方式，密码的方式
auth_pass 1111 #认证的密码
}
virtual_ipaddress { #虚拟IP
192.168.51.166
}
}
2.重启keepalived
systemctl restart keepalived
backup
1.备节点配置
vim /etc/keepalived/keepalived.conf
global_defs {
router_id lb02 #标识节点的名称
}
vrrp_instance VI_1 {
state BACKUP
priority 190 #配置优先级
interface eth0 #虚拟IP绑在哪个网络接口上
virtual_router_id 50 #路由ID，相当于把两个节点加到一个组中
advert_int 1 #检查间隔，1秒钟检查一次，检查主节点是否存活
authentication {
auth_type PASS #认证的方式，密码的方式
auth_pass 1111 #认证的密码
}
virtual_ipaddress { #虚拟IP
192.168.51.166
}
}
2.重启keepalived
systemctl restart keepalived
３.验证keepalived的IP漂移
例如我们在客户端ping虚拟IP的时候，就会在arp缓存表中生成记录
记录中的MAC地址正是主节点网卡的MAC地址，说明现在虚拟IP正附着在主节点上
然后继续在客户端ping虚拟IP
同时我们将主节点的keepalived停掉
在停掉主节点的keepalived的时候，ping过程出现重定向的情况（或者丢包），然后恢复正常
此时查看客户端arp缓存表中生成的记录，
发现虚拟IP对应的MAC地址变成了备节点网卡的MAC地址
说明现在虚拟IP附着在备节点上
当我们把主节点的keepalived重新启动后，再查看arp缓存表，会发现虚拟IP对应的MAC地址又变成主几点网卡的MAC地址了，说明现在虚拟IP在主节点上，现在属于默认的抢占式。
在主节点上过滤虚拟IP也是能过滤到的，
抢占式与非抢占式
默认就是抢占式
抢占式的过程：
master故障--->backup接管--->master恢复--->虚拟IP会被master抢占走
但是会造成多次切换
如果两个节点的硬件配置不一样，master的高于backup，选抢占式
非抢占式的过程：
master故障--->backup接管--->master恢复--->虚拟IP还在backup上不会被抢走
除非backup故障了，地址才会漂移至之前的master上。
切换频次少
如果两个节点的硬件配置一样，master的等于backup，选非抢占式，减少切换次数
配置非抢占式
其他配置不变,只修改以下内容即可
#master上配置
vim /etc/keepalived/keepalived.conf
...
state BACKUP #将之前的MASTER改为BACKUP
priority 200
nopreempt #配置为非抢占式
...
#backup上配置
vim /etc/keepalived/keepalived.conf
...
state BACKUP
priority 190
nopreempt #配置为非抢占式
...
查看结果
在主节点可以过滤到虚拟IP，说明当前虚拟IP附着在主节点
把主节点的keepalived停掉
虚拟IP就会漂移到备节点
当我们把主节点的keepalived恢复正常后,过滤虚拟IP是过滤不到的
说明虚拟IP在主节点恢复正常后,并没有漂移回主节点
依然附着在备节点上
keepalived与nginx的关系(nginx高可用)
nginx与Keeplaived没有必然关系，只不过nginx需要借助Keeplaived地址漂移技术来实现高可用。
要想实现nginx的高可用？
1.确保通过192.168.51.163 访问没有问题。
2.确保通过192.168.51.164访问没有问题。拉取163一样的nginx配置
3.接入Keeplaived虚拟IP地址,在两台机器上配置好keepalived即可,192.168.51.166
4.将域名解析到192.168.51.166 ，由192.168.51.166 调度到192.168.51.163机器上访问
5.假设192.168.51.163机器故障，那么192.168.51.166会将地址漂移到192.168.51.164主机，然后由192.168.51.164提供服务，减少故障down机时间。
配置
1.163节点,nginx配置
vim /etc/nginx/conf.d/keepalived.conf
server {
listen 80;
server_name www.test.com;
root /html;
location / {
proxy_pass http://192.168.51.165;
proxy_set_header Host $http_host;
}
}
2.164节点,nginx配置
vim /etc/nginx/conf.d/keepalived.conf
server {
listen 80;
server_name www.test.com;
root /html;
location / {
proxy_pass http://192.168.51.165;
proxy_set_header Host $http_host;
}
}
3.后端节点配置
vim /etc/nginx/conf.d/test.com.conf
server {
listen 80;
server_name www.test.com;
root /html;
location / {
index index.html;
}
}
vim /html/index.html
<meta charset="utf-8">
<h1>www.test.com网站高可用测试</h1>
4.将原本解析到nginx代理节点的域名,重新解析到keepalived的虚拟IP
192.168.51.166 www.test.com
5.查看结果
可以看到,当前是由163节点在提供服务(虚拟IP166附着在163上)
把163节点的keepalived停掉,网站还是可以正常访问
原因是虚拟IP已经切换到了164节点上去了
高可用如何投产
云服务器环境高可用
以阿里云为例，阿里云并不用keepalived，它可支持直接做负载均衡的高可用
1.单CLB实例的高可用
阿里云负载均衡已在大部分地域部署了多可用区以实现同地域下的跨机房容灾。
当主可用区出现故障或不可用时，负载均衡有能力在非常短的时间内（约30秒）切换到备可用区并恢复服务；
当主可用区恢复时，负载均衡同样会自动切换到主可用区提供服务。
当主可用区整体不可用时，如机房整体断电或者机房出口光缆中断等，负载均衡的请求才会切换到备可用区。
而并非主可用区某个实例出现故障，就将请求切换到备可用区的实例。
实践：
建议在支持主备可用区的地域创建负载均衡实例，即在购买负载均衡实例时选择可用区类型为多可用区的地域。
选择CLB的主备可用区时，根据ECS实例在可用区分布情况进行选择。
大部分ECS实例位于哪个可用区，就将哪个可用区选择为CLB的主可用区，以获取最小的访问延迟。
但是并不建议将全部ECS实例都部署在一个可用区内，也需要在CLB的备可用区部署少量ECS实例，
以便在极端情况下（主可用区整体不可用时），切换到备可用区后仍旧可以正常处理负载均衡转发的请求。
云服务器高可用是怎么实现的呢
是在购买负载均衡的时候，阿里云会让我们选一个备可用区，选了备可用区后，备可用区上也会有一个负载均衡，主备可用区的负载均衡一致，当主可用区的负载均衡出现故障后，就会立即切换到备可用区的负载均衡上，继续提供服务
2.多CLB实例的高可用
如果对可用性的要求特别高，负载均衡实例自身的可用性保障机制可能无法满足您的需求。
例如当网络攻击或配置错误等情况导致负载均衡实例不可用时，由于未出现可用区级故障，不会触发负载均衡实例的可用区切换。
此时，可以创建多个CLB实例，通过云解析DNS对访问进行调度，或通过全球负载均衡解决方案实现跨地域容灾备份。
实践：
可以在一个地域内的多个可用区或多个地域内部署负载均衡实例和后端ECS实例，然后使用云解析DNS对访问进行调度。
物理服务器环境高可用
准备：
1.搭建好内网集群环境
2.部署好负载均衡高可用
3.配置路由器，做好端口映射 (80 端口要进行报备才能使用,不然运营商是不会给你使用的)
4.做DNS解析，将域名解析到路由器的公网IP
请求：
发起请求的时候,由于在内网做的负载均衡高可用等，是无法对外提供服务的,
要想对外提供服务肯定要求IP是个公网地址
所以要将域名解析到我们公网的出口IP地址
有公网的IP地址还是不行，因为路由器并不能提供服务，
所以路由器要通过NAT技术做数据包改写的操作，
就是将原本请求路由器80端口的，映射到虚拟IP对应的80端口，
这期间发生过一次DNAT目标地址转换，
将原本的目标地址，从路由器公网IP地址变成了内网的虚拟IP地址，
然后就可以将请求的数据包发送给虚拟IP对应的负载均衡，负载均衡代替用户去请求后端集群。
响应：
返回数据包的时候，由于是在内网，所以数据包要交给网关，10.0.0.254
此时源IP为虚拟IP，源端口为80,目标IP为客户端的IP,目标端口为客户端的端口4567
发给路由器后,路由器要做一个SNAT源地址转换的操作，
转换后的结果为,目标IP与目标端口保持不变,
源IP地址由内网的IP地址变成了公网的IP地址
最终完成了请求与响应的过程
注意:
直接将两台负载均衡服务器配置为公网IP,再使用一个公网IP做虚拟IP,来实现高可用,这种方式显然不现实.
nginx宕掉后,keepalived仍正常运行,如何强制VIP漂移
如果发生这种情况，地址是不会漂移的，因为keepalived与nginx没有什么关联,
keepalived能正常运行,虚拟IP就不会漂移,但是会对访问造成影响，
所以需要写一个检测脚本，监控Nginx的存活状态，
Nginx挂掉后起不来，也让Keepalived挂掉，实现VIP漂移。
1.检测nginx是否存活。
2.如果存活，则不处理，如果不存活，则尝试启动nginx服务，等待3s
3.如果还是不存活，则kill掉Keepalived这个服务、完成切换。
创建检测脚本,然后将脚本放在一个特定的位置
脚本执行过程：
获取nginx进程是否存活,
pidof nginx | wc -l 返回为1 的话,说明存在nginx进程,返回为0的话,说明nginx进程不存在了,
然以就进行启动nginx的操作,
接下来等待3秒钟,
pidof nginx | wc -l 再获取一次nginx进程,
如果nginx进程还不存在,
就停掉keepalived,让虚拟IP进行漂移.
主节点上配置
mkdir /server
vim /server/check_web.sh
----------------------------------------------------
#!/bin/bash
nginxpid=$(pidof nginx | wc -l) #1.判断Nginx是否存活,如果不存活则尝试启动Nginx
if [ $nginxpid -eq 0 ];then
systemctl start nginx
sleep 3 #2.等待3秒后再次获取一次Nginx状态
nginxpid=$(pidof nginx | wc -l ) #3.再次进行判断, 如Nginx还不存活则停止Keepalived,让地址进行漂移,并退出脚本
if [ $nginxpid -eq 0 ];then
systemctl stop keepalived
fi
fi
-------------------------------------------------------
chmod -R 777 /server
主节点keepalived上配置
vim /etc/keepalived/keepalived.conf
global_defs {
router_id lb01
}
#每5s执行一次脚本，脚本内容执行时间不能大于5s。否则脚本执行会被中断，又要重新开始执行脚本。
vrrp_script check_web {
script "/server/check_web.sh" #脚本存放路径
interval 5 #脚本执行间隔,多久执行一次脚本,取决于你的脚本要执行多长时间，
#一定要大于脚本执行的时间，否则脚本一直被中断就毫无意义了。
}
vrrp_instance VI_1 {
state BACKUP
priority 200
nopreempt
interface eth0
virtual_router_id 50
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.51.166
}
track_script { #调用脚本
check_web
}
}
查看测试结果
测试nginx是否会自动重启
停掉Nginx后，过几秒再看它的状态，它又恢复了正常
故意将Nginx配置错误
停掉后再查看它的状态
脚本检测到Nginx进程不存活的话，就会将keepalived也停掉，虚拟IP就漂移到备节点上去了
在备节点上查看，虚拟IP已经漂移过来了
就解决了nginx宕掉后,keepalived仍正常运行,VIP不漂移的问题
4462
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
