未来暴富都在看的高可用集群keepalived详解及常见实验

高可用集群类型	特点	应用场景
主从式集群	存在主节点和从节点，主节点负责处理任务，从节点备份主节点数据。	适用于对数据一致性要求较高的场景，如数据库服务。
对称式集群	所有节点地位相同，共同处理任务和承担负载。	常用于 Web 服务器集群等需要均衡处理大量请求的场景。
分布式集群	节点分布在不同地理位置，通过网络协同工作。	适用于大规模、跨地域的服务部署，如云计算平台。
混合式集群	结合了多种集群类型的特点。	在复杂的业务环境中，根据不同需求灵活配置。

1.2. 系统可用性

系统可用性是用来衡量一个系统在一段时间内正常运行时间比例的指标，反映了系统的可靠性和稳定性。

系统可用性的计算方法通常使用以下公式：

可用性 = （系统正常运行时间 / （系统正常运行时间 + 系统故障停机时间））× 100%

例如，如果一个系统在一年（365 天）内正常运行了 360 天，故障停机了 5 天。

那么，系统正常运行时间为 360 天× 24 小时 = 8640 小时，系统故障停机时间为 5 天× 24 小时 = 120 小时。

可用性 = （8640 / （8640 + 120））× 100% ≈ 98.63%

一般来说，系统可用性越高，说明系统越稳定可靠，能够更好地满足用户的需求。常见的系统可用性等级包括：

99%的可用性，意味着每年系统停机时间约为 3.65 天。
99.9%的可用性，每年停机时间约为 8.76 小时。
99.99%的可用性，每年停机时间约为 52.6 分钟。
99.999%的可用性，每年停机时间约为 5.26 分钟。

高可用性对于关键业务系统（如金融交易系统、医疗急救系统等）至关重要，因为哪怕是短暂的停机都可能导致严重的后果。

1.3系统故障

硬件故障：设计缺陷、wear out（损耗）、非人为不可抗拒因素
软件故障：设计缺陷 bug

1.4实现高可用

提升系统高用性的解决方案：降低MTTR- Mean Time To Repair(平均故障时间)

解决方案：建立冗余机制

active/passive 主/备
active/active 双主
active --> HEARTBEAT --> passive
active HEARTBEAT active

HEARTBEAT 常见释义为“心跳”。

在计算机技术领域，“Heartbeat”通常指的是一种用于监测系统或网络组件是否正常运行的机制。

例如，在高可用集群中，节点之间会定期发送“心跳”信号来确认彼此的状态。如果某个节点在一段时间内未收到其他节点的“心跳”信号，就可能认为该节点出现故障，并采取相应的故障转移或恢复措施。

在网络通信中，“Heartbeat”也可以用于保持连接的活跃性，防止由于长时间无数据传输导致连接被中断。

此外，一些软件或服务也会使用“Heartbeat”来向监控系统报告其运行状态。

1.5 VRRP（Virtual Router Redundancy Protocol）

VRRP（Virtual Router Redundancy Protocol，虚拟路由器冗余协议） 是一种容错协议，用于解决局域网中静态网关单点故障导致网络中断的问题。

VRRP 允许一组路由器共同组成一个虚拟路由器，其中包括一个主路由器（Master）和多个备份路由器（Backup）。主路由器负责处理发往虚拟路由器的数据包转发工作，备份路由器处于监听状态。

当主路由器出现故障时，备份路由器中会通过选举产生新的主路由器，从而保证网络的不间断运行，提高网络的可靠性。

VRRP 的优点包括：

提高网络的可用性和可靠性，减少单点故障的影响。
配置相对简单，易于管理和维护

1.5.1VRRP 相关术语

虚拟路由器：Virtual Router
虚拟路由器标识：VRID(0-255)，唯一标识虚拟路由器
VIP：Virtual IP VMAC：Virutal MAC (00-00-5e-00-01-VRID)
物理路由器：

master：主设备
backup：备用设备
priority：优先级

1.5.2VRRP 相关技术

通告：心跳，优先级等；周期性

工作方式：抢占式，非抢占式

安全认证：

无认证
简单字符认证：预共享密钥
MD5

工作模式：

主/备：单虚拟路由器
主/主：主/备（虚拟路由器1），备/主（虚拟路由器2）

二、Keepalived 部署

2.1 keepalived 简介

官网：http://keepalived.org/http://keepalived.org/

Keepalived 是一个基于 VRRP 协议实现的高可用解决方案。

它主要用于解决单点故障问题，通过监控服务器或服务的状态，来实现故障自动切换和转移。

Keepalived 可以实现以下功能：

虚拟 IP 管理：可以为服务器配置一个虚拟 IP 地址，当主服务器出现故障时，虚拟 IP 会自动漂移到备份服务器上，保证服务的连续性。
健康检查：能够对服务器或服务进行多种方式的健康检查，如 TCP 连接检查、HTTP 请求检查等，以确定服务器或服务的运行状态。
高可用切换：当检测到主服务器故障时，自动将服务切换到备份服务器上，并更新路由信息。

2.2 keepalived的优点

1.高可用性

能够有效地监测服务器的状态，及时发现故障并进行切换，确保服务的连续性。
例如，在 Web 服务器集群中，当主服务器出现故障，Keepalived 能迅速将流量切换到备份服务器，用户几乎感受不到服务中断。

2.配置简单

其配置文件相对容易理解和编写，降低了配置的复杂性和出错的可能性。

3.快速切换

能够在短时间内完成服务器的切换，减少因故障导致的服务不可用时间。

4.健康检查机制

支持多种健康检查方式，如 TCP 连接检查、HTTP 请求检查等，确保服务器处于正常工作状态。
比如，可以定期发送 HTTP 请求到服务器的特定页面，以确认 Web 服务是否正常运行。

5.开源免费

作为开源软件，用户可以免费使用和修改，降低了成本。

6.跨平台支持

可以在多种操作系统上运行，具有较好的通用性。

7.灵活的路由策略

可以根据不同的需求设置灵活的路由策略，实现负载均衡和故障转移的优化。

8.支持虚拟 IP

方便地实现虚拟 IP 的漂移，保证服务的 IP 地址不变，提高了服务的稳定性和可访问性。

三、实验详解

实验环境

1.红帽7的四台机子

2.KA1：172.25.254.10/24；KA2：127.25.254.20/24

3.realserver1： 172.25.254.110/24；realserver2：172.25.254.120/24

4.防火墙，selinux全关

5.可以访问外网

`3.1 keepalived`虚拟路由管理

实验步骤：

1.服务器下载`httpd`模块，启动apache服务，写页面

与之前博客实验操作一样。

http://t.csdnimg.cn/RaUqChttp://t.csdnimg.cn/RaUqC

2.`KA`主机下载软件包

3.`KA`主机写配置文件

查看有没有子接口：

将文件传给KA2：

只做以下修改：

这时KA2上没有VIP,因为KA1好着的，KA1的抢占级别更高，所有VIP在KA1上。

4.抓包命令测试

当KA1好着的时候：
这时显示是KA1在发送VRRP通告信息，VIP在KA1上

当KA1下线了时：
这时显示KA2在发送VRRP通告信息，VIP也转到了KA2上

当KA1恢复后：
VIP又回到了KA1上

3.2开启通信功能及独立日志

实验步骤

开启通讯功能：

1.未开启时查看ping不通

2.修改配置文件

3.再次查看

独立日志：

1.修改日志配置文件

2.修改系统日志配置文件

3.重启服务，并查看独立日志是否成功：

3.3独立子配置文件

实验步骤

1.修改配置文件

2.创建子配置文件

3.测试查看

3.4非抢占和延迟抢占

实验步骤

非抢占：

延迟抢占：

3.5组播变单播

实验步骤

1.修改配置文件

2.测试

KA1好的时候：

KA1下线的时候：

3.6邮件通知

实验步骤

1.安装邮件发送工具

[root@KA2 ~]# yum install mailx -y

#KA1也要安装

2.`QQ`邮箱配置

[root@KA1 ~]# vim /etc/mail.rc
#直接添加到最后
set from=3528124611@qq.com  #这里写自己的QQ邮箱！！！
set smtp=smtp.qq.com
set smtp-auth-user=3528124611@qq.com
set smtp-auth-password=wixwywxpyilecjff  #这个是下面图片生成授权码的授权码，需要自己生成
set smtp-auth=login
set ssl-verify=ignore

这个在浏览器QQ邮箱中去生成：

3.发送测试邮件

测试时一定要确保自己的主机可以访问外网。

4.编写脚本

5.编写配置文件

KA2的操作和KA1一样，写脚本，写配置文件，内容一致

6.重启测试邮箱能否收到

3.7`keepalived+lvs`架构实验

实验步骤

1.在`LVS`主机中和`rs`主机中添加`VIP`

2.`rs`主机中使`vip`不对外响应

文件内容如下：

realserver2操作相同

3.`KA`主机下载软件包

4.`KA`主机编写配置文件

KA2操作相同

5.查看策略是否生效

6.测试

客户机访问测试轮询：

KA1主机监控策略变化，看是否可以监控后端服务器的状态，比如：
realserver1下线了，应该将其从策略里面移出

realserver1好的时候：

realserver1坏了的时候：

客户机仍然是可以正常访问的VIP到realserver2上了

realserver1恢复正常：

3.8 Keepalived+HAProxy

在做此实验之前要将之前做Keepalived+LVS的设定还原

实验步骤

1.恢复实验环境

#RS主机上删掉环回地址
[root@realserver1 ~]# ip a d 172.25.254.100/32 dev lo

# 开启ARP响应
[root@realserver1 ~]# vim /etc/sysctl.d/arp.conf
net.ipv4.conf.all.arp_ignore=0
net.ipv4.conf.all.arp_announce=0
net.ipv4.conf.lo.arp_ignore=0
net.ipv4.conf.lo.arp_announce=0

# 注释掉在KA主机上的LVS策略部分

2.`KA`主机下载软件包

[root@ka1 ~]# yum install haproxy -y

#KA2相同

3.`KA`主机开启内核参数

[root@ka1 ~]# vim /etc/sysctl.conf
net.ipv4.ip_nonlocal_bind = 1
[root@ka1 ~]# sysctl -p

4.KA主机编写haproxy配置文件

[root@ka1 ~]# vim /etc/haproxy/haproxy.cfg

........

isten webcluster
    bind 172.25.254.100:80
    mode http
    balance roundrobin
    server web1 172.25.254.110:80 check inter 3 fall 2 rise 5
    server web2 172.25.254.120:80 check inter 3 fall 2 rise 5

........

#KA2相同

5.编写脚本用于监测HAProxy状态

[root@ka1 ~]# vim /etc/keepalived/test.sh
#!/bin/bash
killall -0 haproxy

[root@ka1 ~]# chmod +x /etc/keepalived/test.sh

6.KA主机编写配置文件

KA1：

............

vrrp_script check {
        script "/etc/keepalived/test.sh"
        interval 1
        weight -30
        fall 2
        rise 2
        timeout 2
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 100
    priority 100
    advert_int 1
    #nopreempt
    #preempt_delay 5s
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        172.25.254.100/24 dev eth0 label eth0:1
   }
   unicast_src_ip 172.25.254.10
   unicast_peer {
        172.25.254.20
   }
   track_script {
      check
   }

}

............

KA2：

..........

vrrp_script check {
        script "/etc/keepalived/test.sh"
        interval 1
        weight -30
        fall 2
        rise 2
        timeout 2
}


vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 100
    priority 80
    advert_int 1
    #nopreempt
    #preempt_delay 5s
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        172.25.254.100/24 dev eth0 label eth0:1
    }
    unicast_src_ip 172.25.254.20
    unicast_peer {
        172.25.254.10
    }
}
vrrp_instance VI_2 {
    state MASTER
    interface eth0
    virtual_router_id 200
    priority 100
    preempt_delay 5s
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        172.25.254.200/24 dev eth0 label eth0:2
   }
   unicast_src_ip 172.25.254.20
   unicast_peer {
        172.25.254.10
   }
   track_script {
      check
   }

}

...........