目录

 一、主配置文件

二、配置文件分析

三、副节点配置

四、概念讲解

五、当Master服务器发生故障时，Keepalived会如何处理？

六、当Master服务器故障时，Backup服务器如何判断故障发生？

七、Backup服务器如何监听Master服务器的心跳通告？

---

 一、主配置文件

[root@node01 ~]# cat /etc/keepalived/keepalived.conf
! Configuration File for keepalivedglobal_defs {
notification_email {
test@qq.com
}
notification_email_from system_error@qq.com
smtp_server imap.exmail.qq.com
smtp_connect_timeout 30
router_id lb01 # keepalived 节点的唯一标识,建议设置为当前主机名
}vrrp_script chk_nginx {
script "/etc/keepalived/chk_nginx.sh"
interval 2
weight 0
}
vrrp_script chk_keepalived {
script "/etc/keepalived/chk_keepalived.sh"
interval 1
weight 0
}
vrrp_instance VI_1 {
state BACKUP # 当前角色，两台机器都是BACKUP，主机器priority可以设置的高一点
#interface eth0
interface eno1
virtual_router_id 50
priority 80 # 优先级
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
track_script {
#chk_mysql
#chk_nginx
}
nopreempt
notify_stop /etc/keepalived/notify_stop.sh
notify_master /etc/keepalived/notify_master.sh
notify_backup /etc/keepalived/notify_backup.sh
virtual_ipaddress {
192.168.0.54
}
}

二、配置文件分析

这个Keepalived配置文件定义了如何在一组服务器之间设置高可用性（HA）和故障转移。Keepalived通常用于管理虚拟IP地址（VIP），使得一些服务，如web或数据库服务可以在多台服务器间实现高可用性。配置文件部分和对应的解释如下：

1. **全局设置 (global_defs)**：

   • notification_email：
     当服务状态有变化时，Keepalived将发送通知到这个邮箱地址。
   • notification_email_from：
     发送通知邮件所使用的发件人邮箱地址。
   • smtp_server：
     发送通知邮件所用到的SMTP服务器。
   • smtp_connect_timeout：
     SMTP连接超时设置。
   • router_id：
     这是Keepalived节点的唯一标识，通常设置为主机名，这里是lb01。

2. **VRRP脚本 (vrrp_script)**：

   • chk_nginx：
     定义了一个用于检测nginx状态的脚本chk_nginx.sh，每2秒执行一次。
   • chk_keepalived：
     定义了一个用于检测Keepalived状态的脚本chk_keepalived.sh，每1秒执行一次。

3. **VRRP实例 (vrrp_instance VI_1)**：

   • state：
     指定Keepalived的初始角色，这里配置为BACKUP，表示非主节点。

   • interface：
     指定Keepalived用于VRRP通信的网络接口，这里是eno1。

   • virtual_router_id：
     虚拟路由标识符，用于区分不同的VRRP实例，这里是50。

   • priority：
     优先级，用于选举主节点，数值越高，成为主节点（MASTER）的几率越大。

   • advert_int：
     Advertisements广播的间隔秒数，在这个间隔内各节点会相互通告各自的优先级（用于选举谁是MASTER）。

   • authentication：
     VRRP认证设置，确保同一个VRRP实例中的通信安全。

     • auth_type：认证类型，这里使用了简单的密码认证。
     • auth_pass：认证密码，这里设置为1111。

   • track_script：
     定义了此VRRP实例应该跟踪的脚本，如果其中一个脚本检测到服务不正常，可以影响节点的优先级。

   • notify_stop、notify_master、notify_backup：
     这些是不同事件触发时应该执行的通知脚本，例如切换到备用节点、成为主节点等。

   • virtual_ipaddress：
     虚拟IP地址清单，切换时会被移至不同的节点上。

还有几个关键点需要注意：

• 由于两个选项#chk_mysql和#chk_nginx前面有井号（#），它表示这些行是注释了的，Keepalived将不会检查mysql和nginx服务。
• 选项nopreempt表示备用节点不会主动抢占主节点的地位，即使其优先级更高，这有利于维护目前的主节点不轻易被替换，除非主节点确实出现了故障。
• priority设置为80，如果有多台服务器用相同的配置文件，想要指定一台服务器为默认的主节点，需要给它的配置文件的priority指定一个更高的数值。

这几行配置在vrrp_instance块中指定了在不同事件发生时Keepalived将执行的通知脚本的路径：

1. notify_stop：
   当Keepalived停止时，将执行指定的脚本/etc/keepalived/notify_stop.sh。这可用于清理操作，例如当Keepalived服务停止时撤销一些设置，或者发送通知告诉管理员服务已经停止。

2. notify_master：
   当这个Keepalived实例成为主节点（MASTER）时，将执行该指定脚本/etc/keepalived/notify_master.sh。通常会在此脚本中执行一些成为主节点后需要运行的命令，比如更改路由配置，发送通知给管理员，或者触发其他系统的某些行为。

3. notify_backup：
   当这个Keepalived实例成为备用节点（BACKUP）时，将执行该指定脚本/etc/keepalived/notify_backup.sh。这可以用来执行失去主节点身份时所需要进行的操作，例如告知相关人员节点当前状态的改变，或者修改系统设置以优化为备用节点的运行状况。

这些脚本非常有用，因为它们能让系统管理员在Keepalived状态变化时进行自定义的操作，有效地管理系统的高可用性环境。脚本通常需要有适当的权限来执行必要的命令，并且一定会在系统安全的前提下进行操作。在实际使用之前，这些脚本应由系统管理员根据实际需要创建和测试。

请根据你的具体环境调整配置文件来匹配你的网络情况和高可用性需求。在将配置投入生产环境之前，确保对Keepalived配置文件有充分的理解，并进行充要的测试。

三、副节点配置

通常情况下，备份节点的配置文件类似于主节点的配置文件，但是会有一些关键的区别，主要是在priority设置上（备份节点的优先级应该比主节点的低），以及router_id可能会不同，来标识不同的节点。

以下是备份节点的Keepalived配置文件示例，假设该备份节点的优先级设置为70（比主节点的80低），并将router_id修改为lb02：

shell

! Configuration File for keepalivedglobal_defs {notification_email {test@qq.com}notification_email_from system_error@sense.com.cnsmtp_server imap.exmail.qq.comsmtp_connect_timeout 30router_id lb02 # 为备份节点设置不同的router_id
}vrrp_script chk_nginx {script "/etc/keepalived/chk_nginx.sh" # 保持检测nginx状态的脚本不变interval 2weight -5 # 通常，备份服务器的权重会设置得稍微负一点以保证主节点有更高的优先级
}vrrp_script chk_keepalived {script "/etc/keepalived/chk_keepalived.sh" # 保持检测keepalived状态的脚本不变interval 1weight -5
}vrrp_instance VI_1 {state BACKUP # 保持状态为BACKUP#interface eth0 # 确保使用和主节点相同的网络接口interface eno1virtual_router_id 50 # 保持与主节点相同的virtual_router_idpriority 70 # 优先级要低于主节点来保证主节点的主导地位advert_int 1authentication {auth_type PASSauth_pass 1111 # 保持与主节点相同的认证信息}track_script {#chk_mysqlchk_nginx}nopreempt # 通常保持这个设置以防备份节点抢占主节点地位notify_stop "/etc/keepalived/notify_stop.sh"notify_master "/etc/keepalived/notify_master.sh"notify_backup "/etc/keepalived/notify_backup.sh"virtual_ipaddress {192.168.0.54 # 虚拟IP地址应该与主节点保持一致}
}

请注意以下更改：

• 我调整了router_id为lb02，这表示这是第二个节点。
• priority被设置为70，比主节点设置的80要低。
• 在track_script部分，我取消了对chk_mysql的注释，并经权重weight设置为-5，这是根据负载情况进行的假设性设置，如果备份节点检测到主节点nginx服务不可用，它将减少优先级（增加故障转移的概率）。

记得在启用这个配置文件之前，首先要适当调整chk_nginx.sh和chk_keepalived.sh脚本确保它们符合备份节点的环境。

这就是为备份节点生成的Keepalived配置文件，根据您实际的服务器布局和需要进行适当的调整。在部署到生产环境前，充分测试你的配置以确保它能如你所愿地工作。

四、概念讲解

Keepalived是一种用于提高Linux系统下服务可用性的软件。它基于VRRP（虚拟路由冗余协议）实现了高可用性，通过在多个服务器之间虚拟出一个“主”服务器来处理客户端请求。当这个虚拟的主服务器发生故障时，Keepalived会自动将请求重定向到另一个服务器上，从而确保服务的连续性和可用性。

Keepalived主要有两个组件：

1. Keepalived VRRP：用于实现高可用性的核心组件，可以管理和监视虚拟路由器的状态，并在多个服务器间进行故障切换。
2. 健康检查（Health-checking）：用于监视应用服务（如HTTP、MySQL等）的健康状态，并在服务发生故障时触发VRRP故障转移。

下面是一个简化的Keepalived的高可用架构图和基础解说：

plaintext

     |<---- Virtual IP ---->||                      |
Clients                   Switch|                      |+------ Server 1 (Master)|            |         ||          VRRP        ||            |         |+------ Server 2 (Backup)

在上面的架构中：

• 有两台服务器：Server 1和Server 2。
• Server 1是配置为VRRP主节点（Master），而Server 2是备用节点（Backup）。
• 两台服务器都配置有Keepalived及VRRP实例，共同参与管理一个虚拟IP地址。
• 客户端向这个虚拟IP发送请求，这个IP实际上是由Master服务器提供服务的。
• 如果Master服务器发生故障，Keepalived会使用VRRP协议将Backup节点晋升为新的Master节点，并让其接管虚拟IP地址，确保客户端访问的连续性。
• 健康检查组件运行在两台服务器上，监控服务（如Web服务）的健康状态，如果检测到故障，通知VRRP组件进行主备切换。

为了维护服务器的高可用性，Keepalived做以下几件事：

1. IP地址管理：通过VRRP在多台服务器之间共享一个虚拟IP，这个IP被配置在网络上作为节点的共同身份。
2. 故障检测：定期检查服务的健康状态，例如通过发送HTTP请求或者检查进程是否运行。如果Master节点上的服务出现问题，Keepalived会触发故障转移。
3. 故障转移：当Master节点故障时，备份节点通过VRRP协议接管虚拟IP，成为新的Master节点。
4. 动态权重调整：根据系统和服务的实时健康状态，动态调整节点的权重，影响VRRP选举结果。

Keepalived配置需要在参与的所有服务器上进行设置，保持虚拟路由器ID、虚拟IP等关键配置一致，同时根据不同角色设定好不同的权重和优先级。

请注意，此解说主要侧重于Keepalived的概念性介绍。实际操作时，你需要根据特定的硬件、网络环境和服务需求来具体配置和调优Keepalived和相关服务。由于这里无法展示图形化内容，以上架构图仅作为文字描述用途，实际架构会更复杂，包括网络设备和多个服务层次。

五、当Master服务器发生故障时，Keepalived会如何处理？

当Master服务器发生故障时，Keepalived会根据预先配置好的VRRP协议及健康检查机制来处理故障和执行故障恢复。下面是Keepalived故障处理的步骤：

1. 故障检测：
   Keepalived的健康检查机制会持续监控Master服务器上的关键服务。这些检查可以是简单的进程检查、使用脚本执行复杂的逻辑，或通过配置的track_script来识别服务是否响应（例如，检查Web服务器是否返回200状态码）。

2. Master确定：
   如果检测到Master服务器的关键服务或系统出现故障，Keepalived将会触发预定义的故障动作。Master服务器上的Keepalived服务将失去响应能力，停止发送VRRP通告消息到网络，因此不会再声明自己是活跃的Master节点。

3. 故障通告：
   若已配置了相应的通知脚本，则在检测到故障后，Keepalived会执行故障通知脚本，邮件或者通过其他方式通知系统管理员。

4. 权力转移：
   Backup服务器配置了较低的优先级，它周期性地监听网络中的VRRP通告。如果Backup服务器在预定的时间间隔内没有收到来自Master服务器的VRRP通告，它会认为Master遇到了故障。

5. 预备转为主：
   当Backup服务器认定Master不再发送通告消息时，它会开始自动的故障转移过程。Backup服务器提升自己的状态，成为新的Master节点。

6. 接管虚拟IP：
   新晋升的Master节点（原Backup节点）会接管虚拟IP（VIP）。它在其网络接口上配置这个VIP，并开始向网络发送VRRP通告，声明自己现在是新的Master节点。

7. 服务继续：
   客户端将不会察觉到Master节点的改变，因为它们访问的是保持不变的虚拟IP。新的Master节点保证了服务的连续可用性。

8. 故障修复和恢复：
   当原始的Master节点故障修复并重新上线后，它会以一个优先级较低的Backup节点的身份进入集群。根据配置的预选（preemption）设置，它可能会在之后重新成为Master节点，或者保持在Backup状态直到下一个故障发生。

通过这一系列的步骤，Keepalived保证服务的高可用性，即便在单个节点故障的情况下，也能最大程度地减少服务中断的时间。这对于那些需求严苛的生产环境来说是关键，比如网页服务器集群和数据库集群。

六、当Master服务器故障时，Backup服务器如何判断故障发生？

Backup服务器判断Master服务器故障主要依赖于VRRP（Virtual Router Redundancy Protocol）协议的机制。VRRP的主要作用是在参与的节点间进行主节点的选举，并在主节点故障时提供快速的故障切换。其工作流程大致如下：

1. 心跳通告：
   在正常运行的情况下，主节点（Master）会定期向所有Backup节点发送心跳信号，这些信号被称为VRRP通告（advertisements）。这些通告包含了主节点的优先级和健康状态信息。

2. 超时机制：
   所有Backup节点监听这些来自Master服务器的心跳通告。VRRP协议规定了一个超时时间，如果在这一预定时间段内Backup没有收到任何心跳通告，那么Backup会假定Master已经发生了故障。

3. 启动预选程序：
   当Backup认为Master发生了故障，根据预选策略，它会尝试接管虚拟IP（VIP），以便自己成为新的Master节点。如果配置了预选（preemption），即使是在原Master恢复后，高优先级的服务器也可再次取回Master角色。

4. 新Master声明：
   成为新Master的Backup节点会开始在网络中发送VRRP通告，宣布自己现在是Master节点，其他所有节点（包括故障修复后的原Master节点）应听从这一新声明。

5. 接管虚拟IP：
   新的Master节点将抢占虚拟IP地址，并开始响应发送到该地址的所有请求，从而确保了服务的连续性。

这个过程依赖于Backup服务器对心跳通告的监听，以及对Master状态的定期检测。通过这种方式，Keepalived能够实现对Master故障情况的快速检测和响应。此外，Keepalived也可以配置更复杂的健康检查机制和通知脚本，以对不同类型的服务故障作出反应。

七、Backup服务器如何监听Master服务器的心跳通告？

Backup服务器监听Master服务器的心跳通告依赖于VRRP协议。VRRP通告是使用IP协议发送的，具体来说，通过网络上的多播或广播消息进行。下面是监听心跳通告的过程的详细说明：

1. 使用IP多播：
   VRRP通告通常是通过IP多播地址发送的。对IPv4来说，这个地址一般是224.0.0.18，所有参与VRRP的设备都会监听这个多播地址。对于IPv6，相应的多播地址是ff02::12。

2. 设定VRRP实例：
   在配置Keepalived时，您需要设置VRRP实例并在实例中定义虚拟路由器的标识符（VRID）。所有配置了相同VRID和多播地址的设备将属于同一个VRRP组。

3. 定期发送通告：
   Keepalived配置在Master服务器上将周期性地通过网络接口发送VRRP通告消息到多播地址。这些通告包含了VRRP实例的状态信息和Master的优先级。

4. 监听和处理通告：
   Backup服务器的Keepalived实例同样监听这个多播地址以接收通告。它们通过这些通告来评估网络中的VRRP Master状态。

5. 检查和确认：
   如果Backup在配置的时间阈值内没有收到任何来自当前Master的VRRP通告，它将假定Master已经宕机或其他原因无法履行其职责。

6. 协议工作：
   根据VRRP协议，如果Backup认为Master宕机了，它会根据自己的优先级和预选设置来决定是否接管Master的角色，包括抢占VIP等。

这个监听和通告的过程是VRRP高可用性策略的核心。它确保了当Master服务器因任何原因失去其功能时，Backup服务器能够迅速和有效地判断情况并采取适当的行动以提供服务。此外，Keepalived也提供了权重和优先级的配置，让您可以根据服务器的能力和需求来调整响应和故障转移的策略。