Linux自学笔记——keepalived
本文部分参考博客：http://blog.运维网.com/1992tao/1869869一、 VRRP协议
1. 技术优点；
VRRP是一种容错协议，它保证当主机的下一跳路由器出现故障时，由另一台路由器来代替出现故障的路由器进行工作，从而保持网络通信的连续性和可靠性。
VRRP具有如下优点：
1) 简化网络管理。在具有多播或广播能力的局域网（如以太网）中，借助VRRP能在某台设备出现故障时仍然提供高可靠的缺省链路，有效避免单一链路发生故障后网络中断的问题，而无需修改动态路由协议、路由发现协议等配置信息，也无需修改主机的默认网关配置。
2) 适应性强。VRRP报文封装在IP报文中，支持各种上层协议。
3) 网络开销小。VRRP只定义了一种报文——VRRP通告报文，并且只有处于Master状态的路由器可以发送VRRP报文。
2. 相关术语
1) 虚拟路由器：有一个Master路由器和多个Backup路由器组成。主机将虚拟路由器当做默认网关。
2) VRID：虚拟路由器的标识。有相同VRID的一组路由器构成一个虚拟路由器。
3) Master路由器：虚拟路由器中承担报文转发任务的路由器；
4) Backup路由器：Master路由器出现故障时，能够代替Master路由器工作的路由器。
5) 虚拟IP地址：虚拟路由器的IP地址。一个虚拟路由器可以拥有一个或多个IP地址。
6) IP地址拥有者：接口IP地址与虚拟IP地址相同的路由器被称为IP地址拥有者；
7) 虚拟MAC地址：一个虚拟路由器拥有一个虚拟MAC地址。虚拟MAC地址的格式为00-00-5E-00-01-{VRID}。通常情况下，虚拟路由器回应ARP请求使用的是虚拟MAC地址，只有虚拟路由器做特殊配置的时候，才回应接口的真实MAC地址；
8) 优先级：VRRP根据优先级来确定虚拟路由器中每台路由器的地位。
9) 非抢占方式：如果Backup路由器工作在非抢占方式下，则只要Master路由器没有出现故障，Backup路由器即是随后被配置了更高的优先级也不会称为Master路由器；
10)抢占方式：如果Backup路由器工作在抢占方式下，当它收到VRRP报文后，会将自己的优先级与通告报文中的优先级进行比较。如果自己的优先级比当前的Master路由器优先级高，就会主动抢占成为Master路由器；否则，保持Backup状态。
3. VRRP工作过程
虚拟路由器示意图：
http://s1.运维网.com/images/20180202/1517558570854723.png
VRRP工作过程为：
1) 虚拟路由器中的路由器根据优先级选举出Master。Master路由器通过发送免费ARP报文，将自己的虚拟MAC地址通知给与它连接的设备或者主机，从而承担报文转发任务；
2) Master路由器周期性发送VRRP报文，以公布其配置信息（优先级等）和工作状况；
3) 如果Master路由器出现故障，虚拟路由器中的Backup路由器将根据优先级重新选举新的Master；
4) 虚拟路由器状态发生切换时，Master路由器由一台设备切换为另一台设备，新的Master路由器只是简单的发送一个携带虚拟路由器的MAC地址和虚拟IP地址信息的免费ARP报文，这样就可以更新与它连接的主机或设备中的ARP相关信息。网络中的主机感知不到Master路由器已经切换为另外一台设备。
5) Backup路由器的优先级高于Master路由器时，由Backup路由器的工作方式决定是否重新选举Master。
由此可见，为了保证Master路由器和Backup路由器能够协调工作，VRRP需要实现以下功能：
Master路由器的选举；
Master路由器状态的通告；
同时，为了提高安全性，VRRP还提供了认证功能；
4. Master路由器的选举
VRRP根据优先级来确定虚拟路由器中的每台路由器的角色（Master路由器或者Backup路由器）。优先级越高，则越有可能称为Master路由器。
初始化创建路由器工作在Backup状态，通过VRRP报文的交互获知虚拟路由器中其他成员的优先级；
1) 如果VRRP报文中Master路由器的优先级高于自己的优先级，则路由器保持在Backup状态；
2) 如果VRRP报文中Master路由器的优先级低于自己的优先级，采用抢占工作方式的路由器将抢占称为Master状态，周期性发送VRRP报文，采用非抢占工作方式的路由器仍保持Backup状态；
3) 如果在一定时间内没有收到VRRP报文，则路由器切换为Master状态。
VRRP优先级的取值范围为0-255（数值越大表明优先级越高），可配置的范围是1-254，优先级0为系统保留给路由器放弃Master位置时候使用，255则是系统保留给ip地址拥有者使用。当路由为IP地址拥有者时，其优先级始终为255.因此，当虚拟路由器内存在IP地址拥有者时，只要其工作正常，则为Master路由器。
5. Master路由器的状态的通告。
Master路由器周期性地发送VRRP报文，在虚拟路由器中公布其配置信息（优先级等）和工作状况。Backup路由器通过接收到VRRP报文的情况来判断Master路由器是否工作正常。
Master路由器主动放弃Master地位（如Master路由器退出虚拟路由器）时，会发送优先级为0的VRRP报文，致使Backup路由器快速切换变成Master路由器。这个切换的时间称为Skew time，计算方式为：（256－Backup路由器的优先级）/256，单位为秒。
当Master路由器发生网络故障而不能发送VRRP报文的时候，Backup路由器并不能立即知道其工作状况。Backup路由器等待一段时间之后，如果还没有接收到VRRP报文，那么会认为Master路由器无法正常工作，而把自己升级为Master路由器，周期性发送VRRP报文。如果此时多个Backup路由器竞争Master路由器的位置，将通过优先级来选举Master路由器。Backup路由器默认等待的时间称为Master_Down_Interval，取值为：（3×VRRP报文的发送时间间隔）＋Skew time，单位为秒。
在 性 能 不 够稳定的网络中， Backup 路由器可能因为网络堵塞而在Master_Down_Interval期间没有收到Master路由器的报文，而主动抢占为Master位置，如果此时原Master路由器的报文又到达了，就会出现虚拟路由器的成员频繁的进行Master抢占现象。为了缓解这种现象的发生，特制定了延迟等待定时器。它可以使得Backup路由器在等待了Master_Down_Interval后，再等待延迟等待时间。如在此期间仍然没有收到VRRP报文，则此Backup路由器才会切换为Master路由器，对外发送VRRP报文。
6. 认证方式
VRRP提供了三种认证方式：
1) 无认证：不进行任何VRRP报文的合法性认证，不提供安全性保障。
2) 简单字符认证：在一个有可能收到安全威胁的网络中，可以将认证方式设置为简单字符认证。发送VRRP报文的路由器将认证字填入到VRRP报文中，而收到VRRP报文的路由器会将收到的VRRP报文中的认证字和本地配置的认证字进行比较。如果认证字相同，则认为接收到的报文是合法的VRRP报文；否则认为接收到的报文是一个非法报文。
3) MD5认证：在一个非常不安全的网络中，可以将认证方式设置为MD5认证。发送VRRP报文的路由器利用认证字和MD5算法对VRRP报文进行加密，加密后的报文保存在Authentication Header（认证头）中。收到的VRRP报文的路由器会利用认证字解密报文，检查改报文的合法性。
二、 Keepalived
1. keepalived简介；
1) keepalived是VRRP协议在linux主机上以守护进程方式的实现；
2) 能够根据配置文件自动生成ipvs规则；
3) 对个RS做健康状态监测；
2. 组件
vrrpstack
checkers
ipvs wrapper-- > ipvs
3. 配置文件的组成部分；
GLOBAL CONFIGURATION
VRRPD CONFIGURATION
vrrp instance
vrrp synchronization group
LVS CONFIGURATION
4. HA Cluster的配置前提；
1) 本机的主机名，要于hostname（uname -n）获得名称保持一致；
Centos 6：/etc/sysconfig/network
Centos 7：hostnamectlset-hostnameHOSTNAME
2) 各节点时间同步；
3) 确保iptables及selinux不会成为服务阻碍；
5. 配置格式；
virtual_ipaddress {
/ brddevscopelabel
192.168.200.17/24 dev eth1
192.168.200.18/24 dev eth2 label eth2:1
}
nopreempt：非抢占模式；默认为抢占模式；
vrrp_sync_group VG_1 {
group {
VI_1 # name of vrrp_instance (below)
VI_2# One for each moveable IP.
}
}
vrrp_instance VI_1 {
eth0
vip
}
vrrp_instance VI_2 {
eth1
dip
}
示例1：单主模型配置keepalived实现高可用
1. 配置环境准备；
两台主机，这里选择的两台centos7的主机，主机名分别为node1，node2，ip地址分别为192.168.19.141, 192.168.19.142；
为了两台主机通信的方便，首先配置两个节点通过主机名并基于密钥认证的ssh服务完成通信；
1) 在两台节点主机上分别在hosts文件中添加名称解析；
http://s1.运维网.com/images/20180202/1517558705991223.png
2) 通过ssh生成密钥对；
http://s1.运维网.com/images/20180202/1517558715272677.png
3) 复制公钥文件至node2；
http://s1.运维网.com/images/20180202/1517558727437700.png
4) 再次尝试远程node2无需密码；
http://s1.运维网.com/images/20180202/1517558738848883.png
在配置前还需达到以下几点要求：
1) 本机的主机名，要于hostname（uname -n）获得名称保持一致；
Centos 7：hostnamectlset-hostnameHOSTNAME
2) 各节点时间同步；
http://s1.运维网.com/images/20180202/1517558761486013.png
3) 确保iptables及selinux不会成为服务阻碍；
2. 安装keepalived，编辑node1的配置文件；
http://s1.运维网.com/images/20180202/1517558773818214.png
Note：编辑配置文件前记得先备份，再编辑，便于恢复；
3. 将node1编辑好的配置文件复制给node2，再次编辑node2的配置文件；
http://s1.运维网.com/images/20180202/1517558786374868.png
Note：主要修改以上内容，修改状态为备用节点，和优先级为99
4. 测试；
1) 启动节点1上的keepalived；利用systemctl status keepalived查看日志；
http://s1.运维网.com/images/20180202/1517558823923317.png
查看node1的ip地址，地址已经在使用；
http://s1.运维网.com/images/20180202/1517558836792551.png
2) 启动node2节点的keepalived，观察日志；
http://s1.运维网.com/images/20180202/1517558854966260.png
查看node2的ip地址：
http://s1.运维网.com/images/20180202/1517558865874776.png
3) 现在我们手动down掉node1的keepalived服务，可以发现配置的虚拟ip地址被移除；
http://s1.运维网.com/images/20180202/1517558875574990.png
查看node2的日志和ip地址，可以发现地址被成功配置在node2上：
http://s1.运维网.com/images/20180202/1517558888522502.png
4) 我们再次手动启动node1的keepalived服务，观察node1日志和地址转移情况，可以发现地址再次转移到node1上；
http://s1.运维网.com/images/20180202/1517558903822803.png
观察node2的日志和地址转移情况：可以发现地址再次被移除；
http://s1.运维网.com/images/20180202/1517558921404718.png
示例2 ：双主模型配置keepalived实现高可用；
1. 在上面的基础上编辑node1的配置文件，添加一个虚拟路由器；
http://s1.运维网.com/images/20180202/1517558935266102.png
2. 配置node2的配置文件；
http://s1.运维网.com/images/20180202/1517558945181145.png
3. 测试
1) 重启两个节点的keepalived服务，观察日志文件，及地址转移情况；
Node1的日志和地址转移情况：获得地址192.168.19.160；
http://s1.运维网.com/images/20180202/1517558967365696.png
Node2的日志和地址转移情况：获得地址192.168.19.161；
http://s1.运维网.com/images/20180202/1517558983161046.png
2) 跟上面一样，我们手动关闭node1的keepalived服务，观察日志和地址转移情况；
Node1的日志和地址转移情况：ip地址被移除；
http://s1.运维网.com/images/20180202/1517558995591981.png
Node2的日志和地址转移情况：两个虚拟地址都转到了node2节点上；
http://s1.运维网.com/images/20180202/1517559007931050.png
3) 再次启动node1的keepalived服务，测试观察；
Node1节点再次获得192.168.19.160地址；
http://s1.运维网.com/images/20180202/1517559027797958.png
Node2节点上192.168.19.160这个地址被移除，只剩192.168.19.161这个地址：
http://s1.运维网.com/images/20180202/1517559040581146.png
在vi中的主机状态发生改变生发送通知：
# notify scripts, alert as above
notify_master |
notify_backup |
notify_fault |
notify |
smtp_alert
示例3：编辑通知脚本使其在主备节点发生转换时发送邮件；
1. 编辑脚本文件，并赋予脚本执行权限；
http://s1.运维网.com/images/20180202/1517559059543428.png
2. 编辑配置文件定义通知脚本；
http://s1.运维网.com/images/20180202/1517559081347525.png
3. 重启node1，查看邮件；
http://s1.运维网.com/images/20180202/1517559108432196.png
示例4：Keepalived实现优先级动态调整；
Keepalived可以调用外部脚本进行资源监控，并根据监控结果实现优先级动态调整；
http://s1.运维网.com/images/20180202/1517559125914637.png
1. 在node1上定义脚本，如果在/etc/keepalived/目录下存在down文件，将节点的优先级减10，编辑配置文件；然后也同时把编辑的内容添加到node2的配置文件中；
http://s1.运维网.com/images/20180202/1517559137662549.png
2. 在两个节点的/etc/keepalived目录下新建脚本文件，内容如下。并赋予执行权限；
http://s1.运维网.com/images/20180202/1517559150401045.png
3. 测试；
1) 在node1的/etc/keepalived/目录下新建一个down文件，观察地址转移情况；
Node1失去了地址：
http://s1.运维网.com/images/20180202/1517559182856501.png
Node2获得地址：
http://s1.运维网.com/images/20180202/1517559234346571.png
2) 删除down文件；node1重新获得了地址
http://s1.运维网.com/images/20180202/1517559485545773.png
三、 配置keepalived高可用ipvs和nginx服务
具体用法可以使用man keepalived.conf命令查看。
示例1：配置单主模型keepalived高可用ipvs-dr集群
1. 准备实验环境
四台虚拟机，两台作为director，两台作为real server，在director上配置keepalived+lvs-dr实现高可用；
实验拓扑图如下：
http://s1.运维网.com/images/20180202/1517559505279231.png
两台director的vip为192.168.19.160（即虚拟ip地址），两台real server的vip也为192.168.19.160，RS1的rip为192.168.19.134，RS2的rip为192.168.19.143
1) 配置RS1主机的vip地址及内核参数，在这里可编写一个脚本；
http://s1.运维网.com/images/20180202/1517559516809981.png
给脚本赋予执行权限，执行脚本，查看IP地址，路由以及内核参数；
http://s1.运维网.com/images/20180202/1517559529810610.png
2) 将RS1的配置脚本发送给RS2，并执行脚本查看；
http://s1.运维网.com/images/20180202/1517559541249301.png
3) 给RS1和RS2提供网页测试文件（一般centos6主机httpd默认已安装）；
RS1网页测试文件：
http://s1.运维网.com/images/20180202/1517559557571399.png
RS2网页测试文件：
http://s1.运维网.com/images/20180202/1517559565954608.png
2. 配置node1（director1）上的keepalived，使其自动生成ipvsadm定义的规则；
1) 配置node1上的keepalived配置文件；
http://s1.运维网.com/images/20180202/1517559588131078.png
2) 配置node2节点上的keepalived配置文件；
http://s1.运维网.com/images/20180202/1517559595221981.png
3) 启动两台rs server的web服务，和启动两台director的keepalived服务；
Note：保证四台主机的iptables和selinux不会影响演示。
3. 测试；
1) 查看node1的keepalived日志等信息，自动生成了ipvs规则；
http://s1.运维网.com/images/20180202/1517559657461981.png
2) 查看node2上的keepalived服务日志等信息，发现自动生成了ipvs规则，但没有获取到虚拟ip地址；
http://s1.运维网.com/images/20180202/1517559666908096.png
3) 用客户端访问测试；
http://s1.运维网.com/images/20180202/1517559675568858.png
4) 手动关闭RS1的web服务，再次测试；
Node上的ipvs规则定义的后端主机只剩一个；
http://s1.运维网.com/images/20180202/1517559681947764.png
客户端测试：
http://s1.运维网.com/images/20180202/1517559689249208.png
5) 重启RS1上的web服务，手动关闭node1的keepalived服务；
Node2获取到ip地址，集群规则为两台RS：
http://s1.运维网.com/images/20180202/1517559699360560.png
客户端测试：依旧能负载均衡后端rs server
http://s1.运维网.com/images/20180202/1517559704467025.png
6) 如果后端的两台RS同时down掉，我们可以在director上定义一个sorry_server，用来提醒用户，集群服务出现故障。在上面的配置文件中，我们已经定义好了sorry server，现在提供sorry server网页文件和开启两台node的web服务。
http://s1.运维网.com/images/20180202/1517559710455346.png
7) Down掉两台RS的web服务，再次测试；
http://s1.运维网.com/images/20180202/1517559716354389.png
再Down掉node1的keepalived服务；
http://s1.运维网.com/images/20180202/1517559723826183.png
8) 再次启动node1的keepalived，和RS1;
http://s1.运维网.com/images/20180202/1517559732792837.png
只要有一个rs启动，sorry server就会下线。
示例2：keepalived高可用nginx服务
1. 实验环境
四台虚拟主机，两台upstream server，两台nginx服务器作为反向代理调度器，并配置keepalived实现高可用nginx；
upstream server1：192.168.19.143；
upstream server2：192.168.19.134；
node1：192.168.19.141
node2:192.168.19.142
虚拟ip（vip）：192.168.19.160
2. 两台node节点服务器配置；
1) 在/etc/nginx/nginx.conf文件中，两台nginx服务器配置upstream模块，定义后端web服务器组并定义反向代理；（两台nginx配置相同）
http://s1.运维网.com/images/20180202/1517559789429657.png
2) 配置keepalived服务，在这里因为nginx的原因，所以无需再配置virtual server去定义后端主机；
Node1节点：
http://s1.运维网.com/images/20180202/1517559798126318.png
Node2节点：
http://s1.运维网.com/images/20180202/1517559810527360.png
3. 测试；
1) 开启node1，node2节点上的nginx和keepalived服务；
Node1：成功获取到地址；
http://s1.运维网.com/images/20180202/1517559827154077.png
Node2：
http://s1.运维网.com/images/20180202/1517560024915536.png
2) 开启两台upstream server的web服务，用客户端测试；
http://s1.运维网.com/images/20180202/1517560032572771.png
3) Down掉node1的keepalived服务，重新访问测试；
Node1丢失ip地址：
http://s1.运维网.com/images/20180202/1517560038515169.png
客户端访问，服务不收影响；
http://s1.运维网.com/images/20180202/1517560044485013.png
4. 如果是nginx服务出现故障而不是keepalived服务故障，这时IP地址不会出现转移，我们需要一个外部脚本监控nginx服务，一旦出现nginx服务故障，立即调用脚本，降低优先级转移ip地址；
1) Node1：编写监控nginx服务运行状况脚本；
http://s1.运维网.com/images/20180202/1517560064870395.png
Node1：编辑keepalived配置文件：
http://s1.运维网.com/images/20180202/1517560078603568.png
2) 将脚本文件复制给node2下的/etc/keepalived/目录下，并编辑node2的keepalived配置文件；
http://s1.运维网.com/images/20180202/1517560110443951.png
3) 重启keepalived服务，手动kill掉node1上的nginx服务，ip地址丢失；
http://s1.运维网.com/images/20180202/1517560120485524.png
观察node2获取到了ip地址；
http://s1.运维网.com/images/20180202/1517560130139270.png
客户端测试，依旧可以访问；
http://s1.运维网.com/images/20180202/1517560136926506.png
4) 当nginx服务出现故障时，我们一种方法就是立即去手动修复或重启服务，如果不想手动去操作，可以编辑通知脚本，在主节点变为MASTER和BACKUP时，都重启nginx服务；
http://s1.运维网.com/images/20180202/1517560153740302.png
手动杀掉nginx进程，node1丢失地址，过了一会，又重新抢占了地址；
http://s1.运维网.com/images/20180202/1517560162801694.png
页:
[1]