这次，小编就先写一篇对Keepalived的配置，那么在学习之前，我们首先要了解Keepalived是什么，以及为什么要用Keepalived。
实际上，Keepalived不仅仅是实现HaProxy的高可用，小编这里只是拿HaProxy来做一个示例而已，根据这个示例，进行稍微的改动基本就可以实现其他服务的高可用。
在此之前，小编就先来说说为什么要用Keepalived来实现负载均衡器高可用，小编这里只拿HaProxy负载均衡器来进行说明：
对于所有懂运维的小伙伴来说，都应该知道，无论后端的服务器都强大，小编这里的后端服务器说的是真正提供服务的主机，负载均衡器后面有缓存服务器，缓存服务器后面才是真正提供服务的服务器。而这个服务器小编称它为"后端服务器"，而在这后端服务器后面是我们的数据缓存服务器，之后是数据库，也是整个企业的命脉。这整个架构是非常庞大的，其中的每一个角色都很重要而且必不可少，所以，这里的每一个角色都不可能只是一台服务器，它们会是多台服务器组成的集群，通过集群技术可以在付出较低成本的情况下获得在性能、可靠性、灵活性方面的相对较高的收益。
当集群组成之后，它们不可能一台一台的开放给用户，若真要这么做，那么每一台后端服务器都要配一个公网地址，并且拿web网站来说，用户访问网站要么是输入网站的域名跳转进来，要么就是通过点击其他页面中的内容跳转进来，而为每一台主机配置一个公网地址，要在DNS解析上把这些公网地址都配置成一个域名，这操作是非常非常可怕的，公网地址是有限的并且是收费的；我们且不谈DNS解析及公网地址费用，就拿某猫、某云来说，他们的后端服务器可不仅仅只有上万台，甚至多达千万台，这让每台提供服务的机器都有一个公网IP是不现实的。因此，在这种情况下，我们可以想象，若是能有一台服务器只负责转发用户的访问请求，而转发的时候通过一定的算法来判断用哪个后端server来提供服务，而后端的所有机器全部用私有IP，并且真正提供服务的后端机器只需要处理请求就可以，无需与用户直接交互，也减少了服务器的压力，一方面也能提升性能。那么这台服务器就是我们的负载均衡器。
而这个负载均衡器只需要负责接收请求并转发即可，所以，通常一个负载均衡器所能处理的并发请求已经足以满足绝大部分企业的要求。但是，若这个负载均衡器宕机了呢？即便负载均衡器后面的服务器再强大，缓存命中率再高，web服务器(就是小编说的后端服务器)处理能力再强、性能再好，数据缓存命中再高，数据库的读写、并发等...哪怕后面的服务器能上天都将无法继续提供服务。所以，基于这种问题，我们势必要对负载均衡器来做高可用。
那么小编说到这里，Keepalived是什么的问题也就迎刃而解了，没错，它就是用来实现高可用方案的一种。
什么是高可用呢？
它是通过系统可靠性和可维护性来度量的。通常是用平均无故障时间（MTTF）来度量系统的可靠性，用平均维护时间（MTTR）来度量系统的维护性。
因此，高可用性=MTTF/MTTF+MTTR*100%
高可用工作方式：
主从方式：有主服务器，有备份服务器
双机双工方式：说通俗一点，就是两个主服务器，这两个主服务器互为主又互为从。资源利用率较高，但这种方式在一些场景下会出现很多问题。拿数据库来 说，若使用两个主同时写入，而在互相同步数据的时候，表中都会有主键，既然数据库用双主，肯定是设置过插入时自增长ID的，但也经常会 出现数据不一致的情况。
集群工作方式：多服务互备方式，其方式典型的例子就是后端的web服务器，当后端的webserver宕机，负载均衡器会先将其下线，请求不会被分配给这个宕机 的服务器，但对正常的业务是不影响的。
小编刚才也说过，Keepalived只不过是解决高可用方案的一种，那么对于高可用的解决方案还有哪些呢？小编先列出以下几个：
Keepalived：通过实现VRRP协议来实现地址转移(这个小编这里不讲，只说实现HaProxy的高可用，在小编的《从零开始的Linux》讲到的时候会非常详细的讲解)
cman+rgmanager
corosync+pacemaker
......
基于小编上面的讲解，伙伴们也应该有所了解Keepalived是实现高可用的，HaProxy是实现负载均衡的。实际上Keepalived同样可以实现负载均衡，小编这里就不做什么过多的介绍了，既然已经了解，那么现在就开始着手配置吧~
小编这里不讲解也不会说明HaProxy的配置，因为要实现HaProxy的高可用，HaProxy是必须要有的，相信在此之前，伙伴们已经准备好了。
Keepalived服务的安装包的包名就叫 keepalived ，用yum安装即可。
安装完之后，用 rpm -ql keepalived 查看安装了哪些文件，找到其配置文件 /etc/keepalived/keepalived.conf
编辑配置文件，配置文件中会默认有一些配置，我们需要在其记住上改动一些即可，其中：
global_defs段的配置无需管，因为这是后端的webserver故障时设置的通知人的邮件，我们现在是要用其做高可用而非负载均衡，所以用不到。
vrrp_instance段才是核心的配置，在这段以下的全部内容，删除即可。接下来小编就来详细的讲解以下这段的配置：
state:该服务器的初始状态(MASTER|BACKUP)
见名知意，该段是说当前主机的初始状态是主还是备份？备份机用BACKUP。
interface 接口名称:要使用哪个网卡
virtual_router_id：配置虚拟路由的ID号，MASTER与BACKUP的编号必须相同，它们会识别该编号判断是否在同一组中。
priority：该主机的优先级，BACKUP备份机的优先级要比MASTER的优先级设置的低一点
advert_int：MASTER与BACKUP间隔多长时间检测一下对方是否正常，单位是秒
authentication：设置MASTER与BACKUP认证
auth_type PASS：认证方式为密码认证
auth_pass：设置认证的密码
virtual_ipaddress：该段也是核心段，配置要转移的IP，该IP一定要是一个公网IP，并且通过DNS解析出来的IP，用户通过这个IP来访问
小编简单修改了一下这一段的配置，现在启动服务应该就可以看到 virtual_ipaddress 中定义的一个IP(小编只是拿这个IP做示范)
可以看到，确实已经有了这个IP，对于出现故障会转移IP，小编就不再做示范了，小编这里指说一些关键内容。（虽然其中还有些重要的）
那么，基础的实现了，我们现在需要使其检测HaProxy这个服务，那么，怎么检测呢？这可能需要考虑。实际上很简单，小编的机器上已经有了一个HaProxy，现在将其启动，小编设置的监听端口是80端口。
伙伴们是否还记得 "killall -0 程序名" 可以探测服务是否可用
基于这个命令，我们可以让 keepalived 来探测 HaProxy 是否可用，不可用则转移IP。
keepalived刚好有这个功能，它内部可以自定义一个函数，这个函数中可以自定义命令，那么其配置怎么配呢？
vrrp_script 函数名 {
script "killall -0 haproxy"
interval 1 #每个多长时间探测一次
weight -5 #当检测到出有问题，则优先级减少5
fall 3 #当连续检测3次失败后，则进行切换IP
rise 5 #5次检测成功后将OK
}
以上定义的值小编只是给的参考值，该段的配置需要在 global_defs 段以及 vrrp_instance 段中间配置。配置完之后，需要在 vrrp_instance 段去调用这个定义的函数：
track_script {
函数名
}
以上定义完，启动服务即可，这是MASTER上的配置，而BACKUP上的配置只需变动一点：
state BUCKUP
priority:优先级比MASTER低
以上配置完即可实现HaProxy的高可用，这里，小编提供了示例图：
那么，到此为止，小编要说的内容已经结束了，虽然这类文章很多，小编还是期望自己的文章能对大家有所帮助~~