贵州省住房和城乡建设厅网站首页,上海材料网站建设,谷歌代运营,太仓做企业网站目录 一、主配置文件
二、配置文件分析
三、副节点配置
四、概念讲解
五、当Master服务器发生故障时#xff0c;Keepalived会如何处理#xff1f;
六、当Master服务器故障时#xff0c;Backup服务器如何判断故障发生#xff1f;
七、Backup服务器如何监听Master服务器…
目录 一、主配置文件
二、配置文件分析
三、副节点配置
四、概念讲解
五、当Master服务器发生故障时Keepalived会如何处理
六、当Master服务器故障时Backup服务器如何判断故障发生
七、Backup服务器如何监听Master服务器的心跳通告 一、主配置文件
[rootnode01 ~]# cat /etc/keepalived/keepalived.conf
! Configuration File for keepalivedglobal_defs {
notification_email {
testqq.com
}
notification_email_from system_errorqq.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或数据库服务可以在多台服务器间实现高可用性。配置文件部分和对应的解释如下 **全局设置 (global_defs)** notification_email 当服务状态有变化时Keepalived将发送通知到这个邮箱地址。notification_email_from 发送通知邮件所使用的发件人邮箱地址。smtp_server 发送通知邮件所用到的SMTP服务器。smtp_connect_timeout SMTP连接超时设置。router_id 这是Keepalived节点的唯一标识通常设置为主机名这里是lb01。 **VRRP脚本 (vrrp_script)** chk_nginx 定义了一个用于检测nginx状态的脚本chk_nginx.sh每2秒执行一次。chk_keepalived 定义了一个用于检测Keepalived状态的脚本chk_keepalived.sh每1秒执行一次。 **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将执行的通知脚本的路径 notify_stop 当Keepalived停止时将执行指定的脚本/etc/keepalived/notify_stop.sh。这可用于清理操作例如当Keepalived服务停止时撤销一些设置或者发送通知告诉管理员服务已经停止。 notify_master 当这个Keepalived实例成为主节点MASTER时将执行该指定脚本/etc/keepalived/notify_master.sh。通常会在此脚本中执行一些成为主节点后需要运行的命令比如更改路由配置发送通知给管理员或者触发其他系统的某些行为。 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 {testqq.com}notification_email_from system_errorsense.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.shnotify_master /etc/keepalived/notify_master.shnotify_backup /etc/keepalived/notify_backup.shvirtual_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主要有两个组件 Keepalived VRRP用于实现高可用性的核心组件可以管理和监视虚拟路由器的状态并在多个服务器间进行故障切换。健康检查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做以下几件事 IP地址管理通过VRRP在多台服务器之间共享一个虚拟IP这个IP被配置在网络上作为节点的共同身份。故障检测定期检查服务的健康状态例如通过发送HTTP请求或者检查进程是否运行。如果Master节点上的服务出现问题Keepalived会触发故障转移。故障转移当Master节点故障时备份节点通过VRRP协议接管虚拟IP成为新的Master节点。动态权重调整根据系统和服务的实时健康状态动态调整节点的权重影响VRRP选举结果。 Keepalived配置需要在参与的所有服务器上进行设置保持虚拟路由器ID、虚拟IP等关键配置一致同时根据不同角色设定好不同的权重和优先级。 请注意此解说主要侧重于Keepalived的概念性介绍。实际操作时你需要根据特定的硬件、网络环境和服务需求来具体配置和调优Keepalived和相关服务。由于这里无法展示图形化内容以上架构图仅作为文字描述用途实际架构会更复杂包括网络设备和多个服务层次。
五、当Master服务器发生故障时Keepalived会如何处理
当Master服务器发生故障时Keepalived会根据预先配置好的VRRP协议及健康检查机制来处理故障和执行故障恢复。下面是Keepalived故障处理的步骤 故障检测 Keepalived的健康检查机制会持续监控Master服务器上的关键服务。这些检查可以是简单的进程检查、使用脚本执行复杂的逻辑或通过配置的track_script来识别服务是否响应例如检查Web服务器是否返回200状态码。 Master确定 如果检测到Master服务器的关键服务或系统出现故障Keepalived将会触发预定义的故障动作。Master服务器上的Keepalived服务将失去响应能力停止发送VRRP通告消息到网络因此不会再声明自己是活跃的Master节点。 故障通告 若已配置了相应的通知脚本则在检测到故障后Keepalived会执行故障通知脚本邮件或者通过其他方式通知系统管理员。 权力转移 Backup服务器配置了较低的优先级它周期性地监听网络中的VRRP通告。如果Backup服务器在预定的时间间隔内没有收到来自Master服务器的VRRP通告它会认为Master遇到了故障。 预备转为主 当Backup服务器认定Master不再发送通告消息时它会开始自动的故障转移过程。Backup服务器提升自己的状态成为新的Master节点。 接管虚拟IP 新晋升的Master节点原Backup节点会接管虚拟IPVIP。它在其网络接口上配置这个VIP并开始向网络发送VRRP通告声明自己现在是新的Master节点。 服务继续 客户端将不会察觉到Master节点的改变因为它们访问的是保持不变的虚拟IP。新的Master节点保证了服务的连续可用性。 故障修复和恢复 当原始的Master节点故障修复并重新上线后它会以一个优先级较低的Backup节点的身份进入集群。根据配置的预选preemption设置它可能会在之后重新成为Master节点或者保持在Backup状态直到下一个故障发生。 通过这一系列的步骤Keepalived保证服务的高可用性即便在单个节点故障的情况下也能最大程度地减少服务中断的时间。这对于那些需求严苛的生产环境来说是关键比如网页服务器集群和数据库集群。
六、当Master服务器故障时Backup服务器如何判断故障发生
Backup服务器判断Master服务器故障主要依赖于VRRPVirtual Router Redundancy Protocol协议的机制。VRRP的主要作用是在参与的节点间进行主节点的选举并在主节点故障时提供快速的故障切换。其工作流程大致如下 心跳通告 在正常运行的情况下主节点Master会定期向所有Backup节点发送心跳信号这些信号被称为VRRP通告advertisements。这些通告包含了主节点的优先级和健康状态信息。 超时机制 所有Backup节点监听这些来自Master服务器的心跳通告。VRRP协议规定了一个超时时间如果在这一预定时间段内Backup没有收到任何心跳通告那么Backup会假定Master已经发生了故障。 启动预选程序 当Backup认为Master发生了故障根据预选策略它会尝试接管虚拟IPVIP以便自己成为新的Master节点。如果配置了预选preemption即使是在原Master恢复后高优先级的服务器也可再次取回Master角色。 新Master声明 成为新Master的Backup节点会开始在网络中发送VRRP通告宣布自己现在是Master节点其他所有节点包括故障修复后的原Master节点应听从这一新声明。 接管虚拟IP 新的Master节点将抢占虚拟IP地址并开始响应发送到该地址的所有请求从而确保了服务的连续性。 这个过程依赖于Backup服务器对心跳通告的监听以及对Master状态的定期检测。通过这种方式Keepalived能够实现对Master故障情况的快速检测和响应。此外Keepalived也可以配置更复杂的健康检查机制和通知脚本以对不同类型的服务故障作出反应。
七、Backup服务器如何监听Master服务器的心跳通告 Backup服务器监听Master服务器的心跳通告依赖于VRRP协议。VRRP通告是使用IP协议发送的具体来说通过网络上的多播或广播消息进行。下面是监听心跳通告的过程的详细说明 使用IP多播 VRRP通告通常是通过IP多播地址发送的。对IPv4来说这个地址一般是224.0.0.18所有参与VRRP的设备都会监听这个多播地址。对于IPv6相应的多播地址是ff02::12。 设定VRRP实例 在配置Keepalived时您需要设置VRRP实例并在实例中定义虚拟路由器的标识符VRID。所有配置了相同VRID和多播地址的设备将属于同一个VRRP组。 定期发送通告 Keepalived配置在Master服务器上将周期性地通过网络接口发送VRRP通告消息到多播地址。这些通告包含了VRRP实例的状态信息和Master的优先级。 监听和处理通告 Backup服务器的Keepalived实例同样监听这个多播地址以接收通告。它们通过这些通告来评估网络中的VRRP Master状态。 检查和确认 如果Backup在配置的时间阈值内没有收到任何来自当前Master的VRRP通告它将假定Master已经宕机或其他原因无法履行其职责。 协议工作 根据VRRP协议如果Backup认为Master宕机了它会根据自己的优先级和预选设置来决定是否接管Master的角色包括抢占VIP等。 这个监听和通告的过程是VRRP高可用性策略的核心。它确保了当Master服务器因任何原因失去其功能时Backup服务器能够迅速和有效地判断情况并采取适当的行动以提供服务。此外Keepalived也提供了权重和优先级的配置让您可以根据服务器的能力和需求来调整响应和故障转移的策略。
