服务高可用之Keepalived使用详解

冷不防 2021-09-24 10:38 3386阅读 0赞

> `创作不易，如果觉得这篇文章对你有帮助，欢迎各位老铁点个赞呗，您的支持是我创作的最大动力！`

### 文章目录 ###

*  1 前言
 *  2 什么是keepalived
 *   *  2.1 keepalived定义
     *  2.2 自由软件的定义
 *  3 什么是高可用（HA）
 *  4 keepalived的运行环境
 *  5 keepalived的工作原理
 *   *  5.1 VRRP协议与工作原理
     *   *  5.1.1 VRRP协议与工作原理
         *  5.1.2 VRRP选举机制
     *  5.2 keepalived故障转移实现高可用
     *  5.3 keepalived故障转移工作机制
     *  5.4 keepalived的单播、多播和广播
     *  5.5 Heartbeat、Corosync、Keepalived集群组件的选择
     *  5.6 keepalived的作用
 *  6 keepalived实现Nginx服务的高可用
 *   *  6.1 Keepalived配置文件
     *   *  6.1.1 MASTER节点配置文件（192.168.10.10）
         *  6.1.2 BACKUP节点配置文件（192.168.10.11）
     *  6.2 Keepalived非抢占模式
 *  7 Nginx监控脚本
 *   *  7.1 VRIP切换及恢复
     *  7.2 Nginx监控脚本
     *  7.3 keepalived配置文件修改
 *  8 总结

# 1 前言 #

在实际开发中，通常情况下，都会有类似集群的操作（比如：redis集群、业务服务集群等），来`保证服务的高可用`。如果没有集群，只有一台web服务器，只要宕机，或者服务工作时出现了故障，就会导致服务不可用。所以，为了`解决单点故障问题，需要配置多个服务`，也就是使用集群的方式，来保证服务的高可用性。

为了使对外的服务能够支撑高并发访问量，通常情况下，会使用Nginx作为web服务器。那么，如何保证nginx服务的高可用呢？

下面，就来给老铁们介绍一个高可用软件`keepalived`，使用`keepalived`就能保证nginx服务的高可用，从而提供系统服务的稳定性。

# 2 什么是keepalived #

**keepalived官网：** [https://www.keepalived.org][https_www.keepalived.org]  
**Github源码：** [https://github.com/acassen/keepalived][https_github.com_acassen_keepalived]

## 2.1 keepalived定义 ##

keepalived是一个类似于layer3, 4 & 5交换机制的软件，也就是我们平时说的第3层、第4层和第5层交换。Keepalived是自动完成，不需人工干涉。

**官网说明如下：**  
**What is Keepalived ?**  
Keepalived is a routing software written in C. The main goal of this project is to provide simple and robust facilities for loadbalancing and high-availability to Linux system and Linux based infrastructures. Loadbalancing framework relies on well-known and widely used Linux Virtual Server (IPVS) kernel module providing Layer4 loadbalancing. Keepalived implements a set of checkers to dynamically and adaptively maintain and manage loadbalanced server pool according their health. On the other hand high-availability is achieved by VRRP protocol. VRRP is a fundamental brick for router failover. In addition, Keepalived implements a set of hooks to the VRRP finite state machine providing low-level and high-speed protocol interactions. In order to offer fastest network failure detection, Keepalived implements BFD protocol. VRRP state transition can take into account BFD hint to drive fast state transition. Keepalived frameworks can be used independently or all together to provide resilient infrastructures.

Keepalived is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

**简单翻译如下：**  
Keepalived是一个用`C语言编写`的`路由软件`，Keepalived的主要目标是为`Linux系统`和`基于Linux的基础设施提供简单、健壮的负载均衡和高可用性的工具`。Loadbalance framework依赖于著名且广泛使用的Linux虚拟服务器（IPVS）内核模块提供Layer4负载均衡。`Keepalived实现了一组检查程序，以便根据运行状况动态地、自适应地维护和管理负载均衡的服务器池`。另一方面`利用VRRP协议实现了高可用性`。**VRRP是路由器故障转移的基础模块**。此外，Keepalived实现了一组连接到VRRP有限状态机的钩子，提供低层和高速的协议交互。为了提供最快的网络故障检测，Keepalived实现了`BFD`协议。VRRP状态转换可以依赖BFD提示来驱动，达到快速的状态转换。Keepalived框架可以独立使用，也可以一起使用，以提供弹性基础设施。

Keepalived的作者：法国巴黎`Alexandre Cassen`（acassen），Keepalived是`自由软件`，您可以根据自由软件基金会（`free software Foundation`）发布的GNU通用公共许可证（GNU General Public License）的条款重新分发和/或修改它，许可证的版本2，或（由您选择）任何更高版本。

## 2.2 自由软件的定义 ##

根据自由软件基金会的定义，“自由软件”（`Free Software`）表示的是那些赋予用户运行、复制、分发、学习、修改并改进软件这些自由的软件。

**自由软件的意义：** 是为了使得用户（包括个体和团体）可以控制程序为己所用。当用户无法控制程序时，这样的软件就是“非自由”（Nonfree）或“专有”（Proprietary）的程序。 \[1\]  
自由软件使成千上万的人的日常工作更加便利，为了满足用户的各种应用需要，它以一种不可思议的速度发展。自由软件是信息社会下以开放创新、共同创新为特点的创新2.0模式在软件开发与应用领域的典型体现。主要分类有Copyleft（左版/版责）许可证和非Copyleft许可证两种。 \[2\]（[百度百科][Link 1]）

# 3 什么是高可用（HA） #

*  高可用性H.A.（`High Availability`）指的是通过尽量缩短因日常维护操作（计划）和突发的系统崩溃（非计划）所导致的停机时间，以提高系统和应用的可用性。它与被认为是不间断操作的容错技术有所不同。HA系统是企业防止核心计算机系统因故障停机的最有效手段。（[百度百科][Link 2]）
 *  HA（High Available），高可用性是通过系统的`可靠性（reliability`）和`可维护性（maintainability）`来度量的。  
    在实际应用中，通常用`平均无故障时间（Mean Time to First Failure (reliability)，简称MTFF）`来度量系统的`可靠性`，用`平均维护时间（MTTR）`1来度量系统的`可维护性`。于是高可用性被定义为：`HA=MTFF/(MTFF+MTTR)`（平均无故障时间/总时间，`总时间=平均无故障时间+平均维护时间`），比较好的情况是宕机时间不超过6分钟。

*  **具体HA(可用性)衡量标准：**  
    99%可用性，则一年宕机时间不超过4天  
    99.9%可用性，则一年宕机时间不超过10小时  
    99.99%可用性，则一年宕机时间不超过1小时  
    99.999%可用性，则一年宕机时间不超过6分钟（很难达到这个级别的高可用性）

# 4 keepalived的运行环境 #

安装keepalived环境之前，也安装下nginx吧，因为笔者这里演示的是`keepalived+nginx实现的高可用`。  
没有nginx环境的可以参考笔者另一篇博文：[https://blog.csdn.net/smilehappiness/article/details/106663758][https_blog.csdn.net_smilehappiness_article_details_106663758]）

使用keepalived，那肯定需要配置keepalived的运行环境。具体的运行环境搭建过程，可以参考博主的另一篇博文：[Linux下搭建高可用Keepalived运行环境][Linux_Keepalived]

# 5 keepalived的工作原理 #

## 5.1 VRRP协议与工作原理 ##

### 5.1.1 VRRP协议与工作原理 ###

在现实的网络环境中。主机之间的通信都是通过配置静态路由或者(默认网关)来完成的，而主机之间的路由器一旦发生故障，通信就会失效，因此这种通信模式当中，路由器就成了一个单点瓶颈，为了解决这个问题，就引入了VRRP协议。

熟悉网络的童鞋们对`VRRP协议`应该不陌生，它`是一种主备模式的协议，通过VRRP可以在网络发生故障时透明的进行设备切换，而不影响主机之间的数据通信`，VRRP可以将两台或者多台物理路由器设备虚拟成一个虚拟路由，这个虚拟路由器通过虚拟IP（一个或者多个)对外提供服务，

每个`虚拟路由器都有一个唯一的标识号`，`称为VRID`，一个VRID与一组IP地址构成一个虚拟路由器，在VRRP协议中，所有的报文都是通过IP多播方式发送的，而在一个虚拟路由器中，只有处于`Master角色`的路由器会一直`发送VRRP数据包`，处于`BACKUP角色`的路由器`只会接受Master角色发送过来的报文信息`，用来监控Master运行状态，`一般不会发生BACKUP抢占的情况`，除非它的优先级更高，而当MASTER不可用时，BACKUP也就无法收到Master发过来的信息，于是就认定Master出现故障，接着多台BAKCUP就会进行选举，优先级最高的BACKUP将成为新的MASTER，这种选举角色切换非常之快（一秒就可以完成主备切换），因而保证了服务的持续可用性。

**涉及到的概念：**

*  **虚拟路由器：** 虚拟路由器是VRRP备份组中所有路由器的集合，它是一个逻辑概念，并不是正真存在的。从备份组外面看备份组中的路由器，感觉组中的所有路由器就像一个 一样，可以理解为在一个组中： `主路由器+所有备份路由器=虚拟路由器`。虚拟路由器有一个虚拟的IP地址和MAC地址。主机将虚拟路由器当作默认网关。虚拟MAC地址的格式为00-00-5E-00-01-\{VRID\}。通常情况下，虚拟路由器回应ARP请求使用的是虚拟MAC地址，只有虚拟路由器做特殊配置的时候，才回应接口的真实MAC地址。
 *  **主路由器（MASTER）：** 虚拟路由器通过虚拟IP对外提供服务，而在虚拟路由器内部同一时间只有一台物理路由器对外提供服务，这台提供服务的物理路由器被称为主路由器。一般情况下Master是由选举算法产生，它拥有对外服务的虚拟IP，提供各种网络功能，如：ARP请求，ICMP数据转发等。
 *  **备份路由器（BACKUP）：** 虚拟路由器中的其他物理路由器不拥有对外的虚拟IP，也不对外提供网络功能，仅接受MASTER的VRRP状态通告信息，这些路由器被称为备份路由器。当主路由器失败时，处于BACKUP角色的备份路由器将重新进行选举，产生一个新的主路由器进入MASTER角色，继续提供对外服务，整个切换对用户来说是完全透明的。

### 5.1.2 VRRP选举机制 ###

**VRRP路由器在运行过程中有三种状态：**

*  Initialize状态： 系统启动后就进入Initialize，此状态下路由器不对VRRP报文做任何处理；
 *  Master状态；
 *  Backup状态；  
    一般主路由器处于Master状态，备份路由器处于Backup状态。

**VRRP使用选举机制来确定路由器的状态，优先级选举：**  
1.VRRP组中IP拥有者。如果虚拟IP地址与VRRP组中的某台VRRP路由器IP地址相同，则此路由器为IP地址拥有者，这台路由器将被定位主路由器。  
2.比较优先级。如果没有IP地址拥有者，则比较路由器的优先级，优先级的范围是0~255，优先级大的作为主路由器  
3.比较IP地址。在没有Ip地址拥有者和优先级相同的情况下，IP地址大的作为主路由器。

如下图所示，虚拟IP为10.1.1.254，在VRRP组中没有IP地址拥有者，则比较优先级，很明显RB和RA的优先级要大于RC，则比较RA和RB的IP地址，RB的IP地址大。所以RB为组中的主路由器。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NtaWxlaGFwcGluZXNz_size_16_color_FFFFFF_t_70]

路由器使用VRRP功能后，会根据优先级确定自己在备份组中的角色。优先级高的路由器成为Master路由器，优先级低的成为Backup路由器。Master拥有对外服务的虚拟IP，提供各种网络功能，并定期发送VRRP报文，通知备份组内的其他设备自己工作正常；Backup路由器只接收Master发来的报文信息，用来监控Master的运行状态。当Master失效时，Backup路由器进行选举，优先级高的Backup节点将成为新的Master 。

在抢占方式下，当Backup路由器收到VRRP报文后，会将自己的优先级与报文中的优先级进行比较。如果大于通告报文中的优先级，则成为Master路由器，否则将保持Backup状态；

在非抢占方式下，只要Master 路由器没有出现故障，备份组中的路由器始终保持Master或Backup状态，Backup路由器即使随后被配置了更高的优先级也不会成为Master路由器；

如果Backup 路由器的定时器超时后仍未收到Master路由器发送来的VRRP报文，则认为Master路由器已经无法正常工作，此时Backup路由器会认为自己是Master路由器，并对外发送VRRP报文。备份组内的路由器根据优先级选举出Master路由 器，承担报文的转发功能。

## 5.2 keepalived故障转移实现高可用 ##

Keepalived软件起初是专为LVS负载均衡软件设计的（`Keepalived+LVS`天作之合），用来管理并监控LVS集群系统中各个服务节点的状态。后来又加入了可以实现高可用的`VRRP (Virtual Router Redundancy Protocol 虚拟路由器冗余协议）`功能，因此Keepalived除了能够管理LVS软件外，还可以作为其他服务（例如：Nginx、Haproxy、MySQL等）的高可用解决方案。

Keepalived高可用服务之间的故障转移是通过`VRRP`实现的。`VRRP协议`即 `Virtual Router Redundancy Protocol`，`虚拟路由器冗余协议, 为了解决局域网内默认网关单点故障的问题`。

新版本的redis使用哨兵模式保证redis服务的高可用，老版本，还是使用的keepalived+redis实现的高可用。所以说，Keepalived可以结合redis实现redis的高可用。

## 5.3 keepalived故障转移工作机制 ##

**Keepalived对服务器运行状态和故障隔离的工作原理：**  
Keepalived作为一个高性能集群软件，它还能实现对集群中服务器运行状态的监控以及故障隔离。

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

*  **在网络层：**  
    我们知道运行这4个重要的协议，互联网络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将把对应的服务器从服务器集群中剔除。

**keepalived工作原理总结：**

*  在 Keepalived服务正常工作时，主 Master节点会不断地向备Backup节点发送（组播/多播的方式）心跳消息，用以告诉备Backup节点自己还活着，当主 Master节点发生故障时，就无法发送心跳消息，备节点也就因此无法继续检测到来自主 Master节点的心跳了，于是备Backup节点调用自身的接管程序，接管主Master节点的IP资源及服务，而当主 Master节点恢复服务时，备Backup节点又会释放主节点故障时自身接管的IP资源及服务，恢复到原来的备Backup角色。
 *  Keepalived主节点一般会选择一台性能比较好的机器，Keepalived备节点可以部署多个；
 *  keepalived的主从切换和redis的主从切换是不一样的，keepalived的主节点挂了以后，从节点变为主节点，之前的主节点恢复以后继续做主节点，redis的主节点挂了以后，重新恢复以后变为从节点。

## 5.4 keepalived的单播、多播和广播 ##

单播（Unicast）、多播（Multicast 或者组播）和 广播（Broadcast）这是`用来描叙网络节点之间通讯方式的术语`。除了`keepalived`，还可以使用`Heartbeat`或`Corosync`实现高可用。

## 5.5 Heartbeat、Corosync、Keepalived集群组件的选择 ##

Heartbeat、Corosync、Keepalived这三个集群组件我们到底选哪个好，Heartbeat、Corosync是属于同一类型，Keepalived与Heartbeat、Corosync，根本不是同一类型的。`Keepalived使用的VRRP虚拟路由冗余协议方式`。`Heartbeat或Corosync是基于主机或网络服务的高可用方式`。简单的说就是，`Keepalived的目的是模拟路由器的高可用，Heartbeat或Corosync的目的是实现Service的高可用`。  
　　  
所以`Keepalived一般是实现前端高可用`，常用的前端高可用的组合有：  
就是我们常见的`LVS+Keepalived`、`Nginx+Keepalived`、`HAproxy+Keepalived`

而`Heartbeat或Corosync是实现服务的高可用`，常见的组合有：  
`Heartbeat v3(Corosync)+Pacemaker+NFS+Httpd`实现Web服务器的高可用、`Heartbeat v3(Corosync)+Pacemaker+NFS+MySQL`实现MySQL服务器的高可用。

**总结：**  
Keepalived中实现轻量级的高可用，一般用于前端高可用，且不需要共享存储，一般常用于两个节点的高可用。而Heartbeat(或Corosync)一般用于服务的高可用，且需要共享存储，一般用于多节点的高可用。

## 5.6 keepalived的作用 ##

Keepalived的作用是检测服务器的状态，如果有一台web服务器宕机，或工作出现故障，Keepalived将检测到，并将有故障的服务器从系统中剔除，同时使用其他服务器代替该服务器的工作，当服务器工作正常后Keepalived自动将服务器加入到服务器群中，这些工作全部自动完成，不需要人工干涉，需要人工做的只是修复故障的服务器。（[百度百科][Link 3]）

**Layer3,4,5工作在IP/TCP协议栈的IP层，TCP层，及应用层，原理分别如下：**

*  **Layer3：**  
    Keepalived使用Layer3的方式工作式时，Keepalived会定期向服务器群中的服务器发送一个ICMP的数据包（既我们平时用的Ping程序），如果发现某台服务的IP地址没有激活，Keepalived便报告这台服务器失效，并将它从服务器群中剔除，这种情况的典型例子是某台服务器被非法关机。Layer3的方式是以服务器的IP地址是否有效作为服务器工作正常与否的标准。
 *  **Layer4：**  
    如果您理解了Layer3的方式，Layer4就容易了。`Layer4主要以TCP端口的状态来决定服务器工作正常与否`。如web server的服务端口一般是80，如果Keepalived检测到80端口没有启动，则Keepalived将把这台服务器从服务器群中剔除。
 *  **Layer5：**  
    Layer5对指定的URL执行HTTP GET，然后使用MD5算法对HTTP GET结果进行求和。如果这个总数与预期值不符，那么测试是错误的，服务器将从服务器池中移除。该模块对同一服务实施多URL获取检查。  
    如果您使用承载多个应用程序服务器的服务器，则此功能很有用。此功能使您能够检查应用程序服务器是否正常工作。MD5摘要是使用genhash实用程序（包含在keepalived软件包中）生成的。  
    SSL\_GET与HTTP\_GET相同，但使用SSL连接到远程Web服务器。
    
    **MISC\_CHECK：** 此检查允许用户定义的脚本作为运行状况检查程序运行。结果必须是0或1.该脚本在导演盒上运行，这是测试内部应用程序的理想方式。可以使用完整路径（即/path\_to\_script/script.sh）调用可以不带参数运行的脚本。那些需要参数的需要用双引号括起来（即“/path\_to\_script/script.sh arg 1 … arg n”）

# 6 keepalived实现Nginx服务的高可用 #

## 6.1 Keepalived配置文件 ##

**keepalived配置分为三个部分：**

*  全局配置(Global Configuration)
 *  VRRP配置（vrrp高可用配置，定义虚拟路由）
 *  LVS配置（结合LVS实现负载均衡配置）

**先来一个总体设计图：**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NtaWxlaGFwcGluZXNz_size_16_color_FFFFFF_t_70 1]

### 6.1.1 MASTER节点配置文件（192.168.10.10） ###

**查看绑定虚拟IP的网络接口名称：**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NtaWxlaGFwcGluZXNz_size_16_color_FFFFFF_t_70 2]

**配置文件内容如下：**

! Configuration File for keepalived
    
    # 全局配置
    global_defs { 
       # keepalived自带的邮件提醒需要开启sendmail 服务，建议用独立的监控或第三方SMTP
       notification_email { 
         12345678@qq.com
       }
    
       notification_email_from keepalived
       smtp_server smtp.qq.com
       smtp_connect_timeout 60
       router_id LVS_DEVEL_aly # 标识本节点的字条串，通常为hostname，这里要唯一，主备不一样
       vrrp_skip_check_adv_addr
       #vrrp_strict 如果ping不通vip地址，把这个注释掉，建议直接注释掉，否则容易产生ip无法ping通的问题
       vrrp_garp_interval 0
       vrrp_gna_interval 0
    }
    
    # vrrp高可用配置，定义虚拟路由，VI_1为虚拟路由的标示符，可自己定义名称
    vrrp_instance MyHA { 
        state MASTER #是主节点还是备节点，取值：MASTER或者BACKUP
        interface eth0 # 绑定虚拟IP的网络接口，与本机IP地址所在的网络接口相同，我的是 eth0
        virtual_router_id 88 # 虚拟路由的ID号，两个节点（主备）设置必须一样，可选IP最后一段使用, 相同的VRID为一个组，他将决定多播的MAC地址
        priority 100 # 节点优先级，值范围 0-254，MASTER要比BACKUP高。当主节点故障时，备节点选举时，优先级越高，优先成为主节点，官方建议，备节点的优先级的值相差50
        #nopreempt ## 优先级高的设置 nopreempt 解决异常恢复后再次抢占的问题
        advert_int 1 ## 组播信息发送间隔，两个节点设置必须一样，默认1s（一般情况下，当主节点故障时，keepalived一秒就可以完成主备的切换）
        ## 设置验证信息，两个节点必须一致
        authentication { 
            auth_type PASS
            auth_pass mypassword # 用于通信的密码，这里根据实际情况设置即可
        }
    
        # 设置虚拟ip池，两个节点设置必须一样
        virtual_ipaddress { 
    		# 用户真正访问的就是该ip（这里的虚拟ip没那么容易，因为现在主流的服务器都是一个公网ip，需要使用第三方软件虚拟出来一个ip，比如说腾讯云的灰度HAVIP）
            192.168.10.200 # 虚拟ip，可以定义多个，注意：这里的虚拟ip要和机器的ip在同一个网段
        }
    }
    
    # 结合LVS实现负载均衡配置
    #virtual_server 192.168.200.100 443 { 
    # delay_loop 6
    # lb_algo rr
    # lb_kind NAT
    # persistence_timeout 50
    # protocol TCP
    #
    # real_server 192.168.201.100 443 { 
    # weight 1
    # SSL_GET { 
    # url { 
    # path /
    # digest ff20ad2481f97b1754ef3e12ecd3a9cc
    # }
    # url { 
    # path /mrtg/
    # digest 9b3a0c85a887a256d6939da88aabd8cd
    # }
    # connect_timeout 3
    # retry 3
    # delay_before_retry 3
    # }
    # }
    #}

### 6.1.2 BACKUP节点配置文件（192.168.10.11） ###

使用以下命令，把192.168.10.10上配置好的keepalived.conf，复制到192.168.10.11机器上，当然也可以直接rz命令上传，这里博主偷懒，使用以下命令拷贝配置文件：  
`scp /usr/local/keepalived/etc/keepalived/keepalived.conf root@ip:/usr/local/keepalived/etc/keepalived/`  
![在这里插入图片描述][20200614175154437.png]  
**修改后的内容如下：**

! Configuration File for keepalived
    
    # 全局配置
    global_defs { 
       # keepalived自带的邮件提醒需要开启sendmail 服务，建议用独立的监控或第三方SMTP
       notification_email { 
         12345678@qq.com
       }
    
       notification_email_from keepalived
       smtp_server smtp.qq.com
       smtp_connect_timeout 60
       router_id LVS_DEVEL_txy # 标识本节点的字条串，通常为hostname，这里要唯一，主备不一样
       vrrp_skip_check_adv_addr
       #vrrp_strict 如果ping不通vip地址，把这个注释掉，建议直接注释掉，否则容易产生ip无法ping通的问题
       vrrp_garp_interval 0
       vrrp_gna_interval 0
    }
    
    # vrrp高可用配置，定义虚拟路由，VI_1为虚拟路由的标示符，可自己定义名称
    vrrp_instance MyHA { 
        state BACKUP #是主节点还是备节点，取值：MASTER或者BACKUP
        interface eth0 # 绑定虚拟IP的网络接口，与本机IP地址所在的网络接口相同，我的是 eth0
        virtual_router_id 88 # 虚拟路由的ID号，两个节点（主备）设置必须一样，可选IP最后一段使用, 相同的VRID为一个组，他将决定多播的MAC地址
        priority 50 # 节点优先级，值范围 0-254，MASTER要比BACKUP高。当主节点故障时，备节点选举时，优先级越高，优先成为主节点，官方建议，备节点的优先级的值相差50
        #nopreempt ## 优先级高的设置 nopreempt 解决异常恢复后再次抢占的问题
        advert_int 1 ## 组播信息发送间隔，两个节点设置必须一样，默认1s（一般情况下，当主节点故障时，keepalived一秒就可以完成主备的切换）
        ## 设置验证信息，两个节点必须一致
        authentication { 
            auth_type PASS
            auth_pass mypassword # 用于通信的密码，这里根据实际情况设置即可
        }
    
        # 设置虚拟ip池，两个节点设置必须一样
        virtual_ipaddress { 
    		# 用户真正访问的就是该ip（这里的虚拟ip没那么容易，因为现在主流的服务器都是一个公网ip，需要使用第三方软件虚拟出来一个ip，比如说腾讯云的灰度HAVIP）
            192.168.10.200 # 虚拟ip，可以定义多个，注意：这里的虚拟ip要和机器的ip在同一个网段
        }
    }
    
    # 结合LVS实现负载均衡配置
    #virtual_server 192.168.200.100 443 { 
    # delay_loop 6
    # lb_algo rr
    # lb_kind NAT
    # persistence_timeout 50
    # protocol TCP
    #
    # real_server 192.168.201.100 443 { 
    # weight 1
    # SSL_GET { 
    # url { 
    # path /
    # digest ff20ad2481f97b1754ef3e12ecd3a9cc
    # }
    # url { 
    # path /mrtg/
    # digest 9b3a0c85a887a256d6939da88aabd8cd
    # }
    # connect_timeout 3
    # retry 3
    # delay_before_retry 3
    # }
    # }
    #}

这样就实现了基础的高可用，192.168.10.10是主节点，通过虚拟ip 192.168.10.200或者192.168.10.10都可以访问到对应的nginx服务器的资源。

当主节点192.168.10.10服务器宕机了，这时候keepalived会自动切换到另一台备用服务192.168.10.11，占用虚拟ip，成为主节点，从而实现故障转移，访问虚拟ip 192.168.10.200，其实访问的是192.168.10.11这台备用机器上的nginx的资源。当主节点192.168.10.10恢复后，192.168.10.11又会编程back备用节点。

## 6.2 Keepalived非抢占模式 ##

keepalived做HA时，经常会遇到抢占式的master和backup之间的切换。通常如果master服务宕机后backup备节点会变成master主节点，但是当master服务又好了的时候master此时会抢占VRIP，这样就会发生两次切换，这对于业务繁忙的网站来说是不好的。所以我们要在配置文件`加入nopreempt非抢占`，但是`这个参数只能用于state为backup的备节点`，所以，我们在用HA的时候最好master和backup的state都设置成backup，让其通过priority权重来竞争主节点。

keepalived的切换可以是自动的，但是却做不到毫秒级别，他怎么都需要一两秒钟的时间进行切换，  
这就有一个问题，虽然在主节点出现问题我们转向备份节点时，这个`延时无可避免`，但是`在我们修复主节点后，实际上并没有必要再马上做一次切换`，所以`Keepalived提供了一种非抢占模式`，来满足这个要求。

**此模式下keepalived 的配置：**

**这种非抢占式，跟上面的配置文件相比，就是开启了非抢占式，其他没有变化，内容如下：**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NtaWxlaGFwcGluZXNz_size_16_color_FFFFFF_t_70 3]  
注意：这样配置后，我们`要注意启动keepalived服务的顺序`，假设我想让A服务成为backup备节点，那就不能先启动A服务的keepalived服务。

# 7 Nginx监控脚本 #

通常情况下，服务的运行状态有很多可能性，所以，上面的方案还不是很完善，keepalived服务有以下几种情况：

*  主节点服务机器宕机，导致备节点直接抢占VRIP虚拟ip，提供nginx服务
 *  主节点keepalived服务宕机了，此时备节点可以抢占VRIP，提供nginx服务
 *  主节点keepalived服务正常，nginx服务故障了，此时还是访问的主节点，这时候就会出现访问故障

针对以上的第三种情况，keepalived也提供了脚本的方式，去监控服务的运行状态。

## 7.1 VRIP切换及恢复 ##

切换：master服务器的nginx服务停止，则master上的keepalived服务要么通过脚本自杀（停止keepalived服务），要么重新启动nginx服务，如果是自杀则vip漂移到backup服务器。

恢复：分别启动nginx和keepalived，master服务器修复恢复后，则vip会自动漂移到master服务器。

**运行原理：**  
keepalived 通过选举（看服务器设置的优先级）挑选出一台热备服务器做 MASTER 机器，MASTER 机器会被分配到一个指定的虚拟 ip，即VRIP，外部程序可通过该 VRIP 访问这台服务器，如果这台服务器出现故障（断网，重启，或者本机器上的 keepalived crash 等），keepalived 会从其他的备份机器上重选（还是看服务器设置的优先级）一台机器做MASTER 并分配同样的虚拟 IP，充当前一台 MASTER的角色，优先级越高，备用机器被拉起来的机会就越大。

## 7.2 Nginx监控脚本 ##

#!/bin/sh
    count=`ps -ef | grep nginx | grep -v grep | wc -l`
    #count=`ps -C nginx --no-header | wc -l` 这种方式也是可以的
    if [ $count -eq 0 ]
    then
    	# 重启nginx服务
    　　echo "nginx is not running....., starting nginx...."
    　　`/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf`
    sleep 2
    
    # 如果nginx服务还启动失败，那么就kill主节点，使用备节点（升级为主节点）提供对外服务
    count=`ps -ef | grep nginx | grep -v grep | wc -l`
    if [ $count -eq 0 ]
    then
       killall keepalived
    fi
    else
    　　echo "nginx is running...."
    fi

**参数说明：** `-v`表示过滤掉grep数据，`wc -l`表示获取行数

## 7.3 keepalived配置文件修改 ##

**修改后的内容如下：**

! Configuration File for keepalived
    
    # 全局配置
    global_defs { 
       # keepalived自带的邮件提醒需要开启sendmail 服务，建议用独立的监控或第三方SMTP
       notification_email { 
         12345678@qq.com
       }
    
       notification_email_from keepalived
       smtp_server smtp.qq.com
       smtp_connect_timeout 60
       router_id LVS_DEVEL_aly # 标识本节点的字条串，通常为hostname，这里要唯一，主备不一样
       vrrp_skip_check_adv_addr
       #vrrp_strict 如果ping不通vip地址，把这个注释掉，建议直接注释掉，否则容易产生ip无法ping通的问题
       vrrp_garp_interval 0
       vrrp_gna_interval 0
       script_user root #shell脚本用哪个用户执行
       enable_script_security #运行shell脚本执行
    }
    
    ## keepalived 会定时执行脚本并对脚本执行的结果进行分析，动态调整 vrrp_instance的优先级。如果脚本执行结果为0，并且weight配置的值大于0，则优先级相应的增加。如果脚本执行结果非0，并且weight配置的值小于 0，则优先级相应的减少。其他情况，维持原本配置的优先级，即配置文件中priority对应的值。
    vrrp_script check_nginx { 
    	script "/usr/local/keepalived/nginx_check.sh" ## 检测nginx服务运行状态的脚本路径
    	interval 2 ## 检测时间间隔
    	weight -20 ## 如果条件成立，权重-20
    }
    
    # vrrp高可用配置，定义虚拟路由，VI_1为虚拟路由的标示符，可自己定义名称
    vrrp_instance MyHA { 
        state BACKUP #是主节点还是备节点，取值：MASTER或者BACKUP
        interface eth0 # 绑定虚拟IP的网络接口，与本机IP地址所在的网络接口相同，我的是 eth0
        virtual_router_id 88 # 虚拟路由的ID号，两个节点（主备）设置必须一样，可选IP最后一段使用, 相同的VRID为一个组，他将决定多播的MAC地址
        priority 50 # 节点优先级，值范围 0-254，MASTER要比BACKUP高。当主节点故障时，备节点选举时，优先级越高，优先成为主节点，官方建议，备节点的优先级的值相差50
        #nopreempt ## 优先级高的设置 nopreempt 解决异常恢复后再次抢占的问题
        advert_int 1 ## 组播信息发送间隔，两个节点设置必须一样，默认1s（一般情况下，当主节点故障时，keepalived一秒就可以完成主备的切换）
        ## 设置验证信息，两个节点必须一致
        authentication { 
            auth_type PASS
            auth_pass mypassword # 用于通信的密码，这里根据实际情况设置即可
        }
    
    	## 将track_script块加入instance配置块,跟踪执行Nginx监控的脚本
    	track_script { 
    		check_nginx ## 执行Nginx监控的服务
    	} #
    
        # 设置虚拟ip池，两个节点设置必须一样
        virtual_ipaddress { 
    	# 用户真正访问的就是该ip
            192.168.10.200 # 虚拟ip，可以定义多个，注意：这里的虚拟ip要和机器的ip在同一个网段
        }
    }
    
    # 结合LVS实现负载均衡配置
    #virtual_server 192.168.200.100 443 { 
    # delay_loop 6
    # lb_algo rr
    # lb_kind NAT
    # persistence_timeout 50
    # protocol TCP
    #
    # real_server 192.168.201.100 443 { 
    # weight 1
    # SSL_GET { 
    # url { 
    # path /
    # digest ff20ad2481f97b1754ef3e12ecd3a9cc
    # }
    # url { 
    # path /mrtg/
    # digest 9b3a0c85a887a256d6939da88aabd8cd
    # }
    # connect_timeout 3
    # retry 3
    # delay_before_retry 3
    # }
    # }
    #}

# 8 总结 #

*  Keepalived是一个用C语言编写的开源的路由软件；
 *  基于Linux虚拟服务器（IPVS）提供负载均衡（结合LVS一起）
 *  基于VRRP协议实现了高可用

**本文说明：** `本文主要是自己的理解，以及其他网上资源的整合，里面部分内容引用了以下链接中的部分资源，如有侵权，请评论联系，我会做出内容的调整。`

**本文参考资料：**  
[https://blog.csdn.net/l1028386804/article/details/72801492][https_blog.csdn.net_l1028386804_article_details_72801492]  
[https://blog.csdn.net/qq\_24336773/article/details/82143367][https_blog.csdn.net_qq_24336773_article_details_82143367]  
[https://baijiahao.baidu.com/s?id=1640091002910074654&wfr=spider&for=pc][https_baijiahao.baidu.com_s_id_1640091002910074654_wfr_spider_for_pc]

> 写博客是为了记住自己容易忘记的东西，另外也是对自己工作的总结，希望尽自己的努力，做到更好，大家一起努力进步！  
>   
> 如果有什么问题，欢迎大家评论，一起探讨，代码如有问题，欢迎各位大神指正！  
>   
> 给自己的梦想添加一双翅膀，让它可以在天空中自由自在的飞翔！

--------------------

1.  平均修复时间（Mean time to repair，MTTR），是描述产品由故障状态转为工作状态时修理时间的平均值。产品的特性决定了平均值的长短，例如：硬盘错误的自动修复机制，又或整个机场的电脑系统发生故障。在工程学，“平均修复时间”是衡量产品维修性的值。因此，这个值在维护合约里很常见，并以之作为服务收费的准则。 ↩︎

[https_www.keepalived.org]: https://www.keepalived.org
[https_github.com_acassen_keepalived]: https://github.com/acassen/keepalived
[Link 1]: https://baike.baidu.com/item/%E8%87%AA%E7%94%B1%E8%BD%AF%E4%BB%B6/405190?fr=aladdin
[Link 2]: https://baike.baidu.com/item/%E9%AB%98%E5%8F%AF%E7%94%A8%E6%80%A7%28HA%29/2355576
[https_blog.csdn.net_smilehappiness_article_details_106663758]: https://blog.csdn.net/smilehappiness/article/details/106663758
[Linux_Keepalived]: https://blog.csdn.net/smilehappiness/article/details/106741982
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NtaWxlaGFwcGluZXNz_size_16_color_FFFFFF_t_70]: /images/20210923/6c2397c80f61498fb7dade865b72b12d.png
[Link 3]: https://baike.baidu.com/item/Keepalived/10346758?fr=aladdin
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NtaWxlaGFwcGluZXNz_size_16_color_FFFFFF_t_70 1]: /images/20210923/728989a0fb3e42478d1e708fc9514ff1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NtaWxlaGFwcGluZXNz_size_16_color_FFFFFF_t_70 2]: /images/20210923/458537b94c4443caa76f2569939e5d45.png
[20200614175154437.png]: /images/20210923/5d21ff7adffe49ec8eef225eb14da010.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NtaWxlaGFwcGluZXNz_size_16_color_FFFFFF_t_70 3]: /images/20210923/ba89555c89e346f6a5739e90ceef794b.png
[https_blog.csdn.net_l1028386804_article_details_72801492]: https://blog.csdn.net/l1028386804/article/details/72801492
[https_blog.csdn.net_qq_24336773_article_details_82143367]: https://blog.csdn.net/qq_24336773/article/details/82143367
[https_baijiahao.baidu.com_s_id_1640091002910074654_wfr_spider_for_pc]: https://baijiahao.baidu.com/s?id=1640091002910074654&wfr=spider&for=pc