漫谈基于 VRRP 协议的 Keepalived 高可用架构

看个例子，这是一个传统的负载均衡架构：

外网 → 负载均衡器 
       ├── 服务器A(192.168.1.10)
       └── 服务器B(192.168.1.11)

他有什么问题？问题就是，这个负载均衡器，它是会挂的，虽然网关这种基础设施一般不会挂，但它若是真挂了，那么外界访问当即就中断在此链路，你后端在做多少高可用都没有意义。

所以，在一个对系统稳定性有要求的系统里，最前端的负载均衡器我们也需要实现高可用，像是一些人为的升级、重启操作也不能影响整个系统运行。

知道这个背景后，我们再来谈 Keepalived 这个东西，以及其对应的架构原理，首先，让我来回答几个基础问题。

Keepalived 是什么？

• Keepalived 是一个专门用来做多机热备的软件，它能监控集群系统中各个服务节点的状态，实现 Failover (失败切换)功能。

为什么要用它？

• Keepalived 基于 VRRP 协议广播 ARP 响应和转发 IP 数据包实现虚拟IP漂移，操作系统内核级支持 + 网卡硬件级支持，故障转移通用解。

我们应该怎么用？

• 把它套在实际运行的服务上面，用来做HA（High Available 高可用），一般用来套在网关上，常见的比如服务器环境里的Nginx、家庭/企业网络中的软路由。

这里着重需要理解的是：

• Keepalived 不是路由器
• Keepalived 不接受流量转发数据包
• Keepalived 只会通过VRRP协议构造一个逻辑上的虚拟路由
• Keepalived 创建虚拟IP后，通过 ARP 协议广播出去供外界访问
• Keepalived 创建的虚拟IP由网卡支持，外界访问它和Keepalived本身没有关系。
• Keepalived 本身干的是故障检测和Master选举（虚拟IP漂移）的活儿。

看清楚我上面列的几个重点，你会对 Keepalived  有一个基本映像，不需要完全搞懂，你看完本篇文章后，回过头来再捋一遍上边的内容，自然就懂了。

现在，让我们在前头提到的传统架构之上附加 Keepalived ，OK，然后这个传统的架构就变成了这样：

外网 → 负载均衡器(Keepalived管理)
外网 → 负载均衡器(Keepalived管理) 
       ├── 服务器A(192.168.1.10)
       └── 服务器B(192.168.1.11)

加入了 Keepalived 后，我们的服务本质上没有任何变动。只是多了一台用来冗余的负载均衡器（backup），然后把这些负载均衡器纳入Keepalived的管辖范围而已，当Master挂了，Keepalived自动升级备用机为Master。

注意，这个负载均衡器和它路由到的下游服务器A、服务器B可以是同一个机子，像是服务器环境下，预算不多的，一台机子装好几个不同功能的服务很正常，如上述例子中的架构，可能总共只有2台服务器而不是4台。

由于Keepalived是基于 VRRP  协议实现，要理解它的原理，我们可以先看一下 VRRP  的 Wiki 百科：

以下是Wiki百科：

虚拟路由器冗余协议（英语：Virtual Router Redundancy Protocol，缩写为 VRRP ）是一种网络协议，可以为参与的路由器自动分配可用的 IP 地址。这个协议通过在子网中，自动选取默认网关，来增加路由的可用性和可靠性。

这个协议首先创建了一些虚拟路由器（这是对多个路由器的抽象），例如：主路由器、备路由器，这些路由器作为一个 group 协同工作。虚拟路由器被配置为默认网关，而不是物理路由器。当正在工作的物理路由器（代表着虚拟路由器）发生故障时，另一个物理路由器会自动被选举出来替代它。特定时间内正在转发数据包的物理路由器被称为主路由器。VRRP 提供了路由器状态的信息，而不是该路由器的数据包处理、交换的信息。每一个 VRRP 实例被限制到单一子网内。它不会参与子网外的 IP 路由，也不会以任何方式影响路由表。VRRP 可以通过 IPv4 或者 IPv6 （三层 IP 网），运行在 Ethernet （以太网）、MPLS 和令牌环网络（二层链路网）。

VRRP  协议很多硬件相关的网关都是自带的（比如F5），还有一些软路由它可能也集成了这个功能，没有的话（服务器环境大伙都用纯净系统，自然是什么都没有），我们就只能在上边自己实现了 —— 比如安装一个 Keepalived。

通俗的来讲，Keepalived 只负责两件事情

1、监控服务器状态

2、管理IP漂移

这个监控服务器状态呢，就是字面意思，Keepalived 自带心跳检测，假设我们有三台服务器，在这三台上搭建并配置好了 Keepalived ，那么当其中某一台挂掉后，心跳没了，剩下的两台自然就能即时发现。

而IP漂移，这个就有些概念上的信息需要你理解了，没事，我一点点来。

还是上边提到的架构，我们来使用Nginx作为网关，由Keepalived 进行管理。

外网 → 负载均衡器(Keepalived管理)
外网 → 负载均衡器(Keepalived管理) 
       ├── 服务器A(192.168.1.10)
       └── 服务器B(192.168.1.11)

以下是 192.168.1.10 这台服务器的配置，他作为主服务器。而 192.168.1.11 这台服务器B，就作为备用服务器，备用的配置文件在某几个字段上会有些差异，就不贴了。

# 服务器A(192.168.1.10) 主服务器配置 /etc/keepalived/keepalived.conf
global_defs {               
   router_id Nginx_01
}
vrrp_script check_nginx {
    # 这里是检查Nginx状态的脚本，当Nginx挂了，那么它会把 keepalived 的进程杀掉
    script "/etc/keepalived/check_nginx.sh" 
    interval 2
    weight -5
    fall 3
    rise 2
}
vrrp_instance VI_1 {
    state MASTER # 主服务器
    interface ens33
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 666
    }

    # 设置虚拟IP地址
    virtual_ipaddress {
     192.168.1.100
    }
    track_script {
    	check_nginx
    }
}

先看下这个 keepalived.conf 配置，然后再结合我们上面说的Keepalived实现，想象一下它到底在做些什么。

对于后端开发人员而言，像是主备切换，一般大家都不容易有疑问，什么redis哨兵、paxos/raft协议之类的玩意基本都有接触过，像是Nginx挂了，为什么要把 Keepalived 的进程杀掉？当然是因为要停掉本机的 Keepalived 心跳咯（和整个物理机一起挂掉的效果相同），因为 VRRP  协议是由Keepalived 维护的，当本机的 Keepalived 随着 Nginx 宕机同步下线后，其他机子就能及时知晓本机已经无法对外提供服务，自然就启动选举流程了，备用的 Nginx 随之上线提供服务。

而开发人员最容易遇到的疑问是：虚拟IP到底怎么访问？

这里我就要来继续解释一下VRRP 协议的工作形式，读者可以结合上面复制的wiki内容一起看，简单来说，在 VRRP 协议中，有两组重要的概念：

1、VRRP 路由器和虚拟路由器

2、主控路由器和备份路由器

VRRP 路由器是指运行 VRRP 的路由器（路由器这个名词在这里等于我们的服务器，脑子里对应上就行），是物理实体，虚拟路由器是指 VRRP 协议创建的路由器，是逻辑概念。一组 VRRP 路由器协同工作，共同构成一台虚拟路由器。该虚拟路由器对外表现为一个具有唯一固定 IP 地址和 MAC 地址的逻辑路由器。

如上面的 keepalived.conf  配置文件所示，在其中，我们设置了虚拟IP地址为192.168.1.100（AB两台的配置均是），于是乎，192.168.1.10、192.168.1.11这两台运行 VRRP （启动了Keepalived）的物理服务器，就共同通过VRRP组成了一个使用192.168.1.100作为IP的逻辑服务器。

我们访问192.168.1.100这个虚拟IP，和直接访问服务器A（Master IP 192.168.1.10）所产生的结果是一样的。

VRRP 协议使用选择策略从路由器组中选出一台作为主控路由器，即我们的服务器A，由它负责 ARP 响应和转发 IP 数据包，组中的其他路由器（服务器B 192.168.1.11）作为备份的角色处于待命状态。当由于某种原因主控路由器发生故障时，备份路由器能迅速升级为主控路由器，同时，这个虚拟IP也会由备机接管。结果就是，实际响应的物理机IP从 192.168.1.10 漂移到了 192.168.1.11。由于此切换非常迅速而且不用改变 IP 地址和 MAC 地址，故对终端使用者的系统来说是透明的。

基于这个工作形式，在内网中，我们在Nginx里配置的反向代理，就不能直接写服务器的内网IP了，而是需要写这个虚拟IP 192.168.1.100，至于访问这个虚拟IP到底访问谁，这不归Nginx管。

你只管访问，办法由物理网卡来想。

当发生IP漂移的时候，新的Master会负责广播 ARP 消息，告诉更上游的数据中心：现在这个IP是我用。

Keepalived 在做的，就是以上我说的这些行为。

咦，到这里，是不是还有一个问题，就是说，这个虚拟IP，为什么说能用就能用？这不是个内网IP么？外界要怎么访问这个内网IP？

你如果有这个想法，那么证明你肯定是个研发，而不是运维，运维都是网络懂哥。

怎么这么说呢？因为 Keepalived 起初是为LVS设计，它被使用在物理机房里面。运维都懂，这种物理机房自己有一个IP池子，想怎么切都行，它们会专门向IDC申请多一些冗余的额外IP，应对各种奇奇怪怪的需求，比如IP漂移。

底层的 VRRP 协议也是基于【子网】的，而不是内网，我上边写的192.168内网网段只是为了举例，毕竟内网也是一种子网嘛。

对物理机房来说，这所谓的虚拟IP，并不一定是一个假的IP，这虚拟IP他可能就是个能被正儿八经访问的公网IP，所以才既能接受外界请求，又能实现漂移无感。

而现在是什么时代？微服务！云原生！容器化！IasS！

我们压根就没有自己的物理IP，用都是云厂商的IP！

你在这个背景下，用基于 VRRP 协议的 Keepalived ，确实会有点摸不着头脑，所以，你才需要看这篇文章，好好捋一捋。

当代云厂商为了支持 VRRP ，他们肯定是有一个虚拟IP服务提供给你的，关于现代云服务上的虚拟IP，以阿里云举例，可以查看该官方文档、

使用高可用虚拟IP（HaVip）和Keepalived实现双机主备高可用_专有网络VPC(VPC)

你需要在云平台也设置一个虚拟IP，然后配置内网虚拟IP的时候等同于云平台的配置，云厂商就可以支撑你的虚拟IP服务。

我相信，你认真地读完本篇文章后，再看上面的云厂商文档，肯定没有任何理解压力。

那么本篇也就到此为止。

最后，再来个复制粘贴的资料作为结束，下面是我复制来的Keepalived的具体原理

Keepalived 工作在 TCP/IP 参考模型的第三、第四和第五层，也就是网络层、传输层和应用层。根据 TCP/IP 参考模型各层所能实现的功能，Keepalived运行机制如下：

• 在网络层

运行着四个重要的协议：互连网协议 IP、互连网控制报文协议 ICMP、地址转换协议 ARP 以及反向地址转换协议 RARP。

Keepalived 在网络层采用的最常见的工作方式是通过ICMP协议向服务器集群中的每个节点发送一个 ICMP 的数据包（类似于 ping 实现的功能），

如果某个节点没有返回响应数据包，那么 就认为此节点发生了故障，Keepalived 将报告此节点失效，并从服务器集群中剔除故障节点。

• 在传输层

提供了两个主要的协议：传输控制协议 TCP 和用户数据协议 UDP。传输控制协议 TCP 可以提供可靠的数据传输服务，IP 地址和端口，代表一个 TCP 连接的 一个连接端。

要获得 TCP 服务,须在发送机的一个端口上和接收机的一个端口上建立连接，而 Keepalived 在传输层就是利用 TCP 协议的端口连接和扫描技术来 判断集群节点是否正常的。

比如，对于常见的 Web 服务默认的 80 端口、SSH 服务默认的 22 端口等，Keepalived 一旦在传输层探测到这些端口没有响应数据返回， 就认为这些端口发生异常，然后强制将此端口对应的节点从服务器集群组中移除。

• 在应用层

可以运行 FTP、TELNET、SMTP、DNS 等各种不同类型的高层协议，Keepalived 的运行方式也更加全面化和复杂化，用户可以通过自定义 Keepalived 的工作方式，

例如用户可以通过编写程序来运行 Keepalived，而 Keepalived 将根据用户的设定检测各种程序或服务是否允许正常，如果 Keepalived 的检测结果 与用户设定不一致时，Keepalived 将把对应的服务从服务器中移除。