实现高可用的故障转移策略的工具——Keepalived

Shenqi Lotus

已于 2024-09-15 16:53:14 修改

阅读量743

点赞数 12

分类专栏： Linux运维_架构文章标签：运维架构

于 2024-09-10 23:35:17 首次发布

本文链接：https://blog.csdn.net/qq_47030101/article/details/142081824

版权

Linux运维_架构专栏收录该内容

12 篇文章 0 订阅

订阅专栏

文章目录

- 一、高可用与keepalived介绍
- - 1、什么是高可用
  - 2、实现高可用的技术
  - - 1). 负载均衡器
    - 2). 故障转移工具
    - 3). 数据库高可用性
    - 4). 存储高可用性
    - 5). 监控与报警工具
    - 6). 云服务高可用性
  - 3、Keepalived介绍
  - - 0-1）Keepalived是什么、功能介绍：
    - - Keepalived的功能
      - *注：Nginx和LVS在负载均衡上使用的区别：
      - 实际应用场景
      - *注：具体如何使用Keepalived和LVS进行负载均衡，具体配置是什么样的？
    - 0-2）Keepalived底层实现原理：
    - 1）VRRP：
    - 2）Keepalived的相关概念
    - - 选举投票机制
      - 抢占式、非抢占式机制
      - 脑裂状态
    - 3）keepalived的工作流程概述
- 二、配置Keepalived
- - 0、*Keepalived健康检查机制：
  - - VIPS 健康检查
    - 脚本健康检查
    - 网络接口健康检查
  - 1、安装keepalived
  - 2、配置语法
  - - 配置文件格式：
    - 具体配置内容组成：
    - 测试
  - 3、“抢占式“配置
  - 4、“非抢占式”配置
  - - 生产中Keepalived需要配置非抢占式的情况
  - 5、Keepalived自动引用执行外部脚本——脚本健康检查机制
  - - 1、写脚本
    - 2、Keepalived配置文件配置自动调用上述检测脚本
    - 测试
- 三、实验
- - 需求
  - 实现
  - - 环境准备
    - 1. Web服务器配置（`web1` 和 `web2`）
    - 2. 负载均衡配置（`lb1` 和 `lb2`）
    - 3. 数据库高可用配置（`db1` 和 `db2`）
    - 4. NFS高可用配置（`nfs1` 和 `nfs2`）
    - 5. 备份服务器高可用配置（`backup1` 和 `backup2`）
    - 总结

一、高可用与keepalived介绍

1、什么是高可用

高可用（High Availability, HA）是指系统或服务设计的能力，以确保在面临故障或其他问题时仍然能继续提供服务。其主要目标是最大限度地减少系统的停机时间和确保服务的持续可用性。

实现高可用性通常包括以下几个关键策略：

冗余设计：通过引入冗余组件（如备用服务器、网络路径或存储设备），以便在一个组件失败时，其他组件可以接管其功能，确保系统继续运作。
故障转移：设置自动化的故障转移机制，使系统在发现某个组件失败后，能迅速将负载转移到备用组件，从而减少停机时间。
负载均衡：使用负载均衡器分配流量或任务到多个服务器或节点，避免单个点的过载，从而提高系统的整体可用性。
数据备份和恢复：定期备份重要数据，并制定恢复策略，以便在数据丢失或损坏时能够迅速恢复。
监控和警报：实时监控系统的健康状态，设置警报以便在问题发生时能够迅速采取行动。

高可用性是关键任务系统（如金融服务、电商平台和在线应用）设计中的核心考虑因素，因为这些系统的可靠性直接影响用户体验和业务连续性。

2、实现高可用的技术

实现高可用性（HA）的工具和技术有很多，以下是一些常见的工具和技术，按类别划分：

1). 负载均衡器

Nginx：作为高效的负载均衡器和反向代理服务器，能够分配流量到多个服务器。
HAProxy：提供高性能的负载均衡和代理功能，支持多种负载均衡算法。
F5 BIG-IP：企业级负载均衡解决方案，支持高级流量管理和应用优化。

2). 故障转移工具

Keepalived：主要用于实现高可用性和负载均衡，支持虚拟路由冗余协议（VRRP）。
Corosync/Pacemaker：提供集群管理和故障转移功能，常用于Linux集群环境。
Microsoft Failover Clustering：用于Windows Server环境，提供应用程序和服务的故障转移支持。

3). 数据库高可用性

MySQL Group Replication：提供MySQL数据库的高可用性解决方案，通过多主复制实现数据冗余。
PostgreSQL Streaming Replication：用于PostgreSQL数据库的主从复制，确保数据冗余和故障转移。
Oracle Data Guard：为Oracle数据库提供高可用性和灾难恢复解决方案。

4). 存储高可用性

Ceph：一个分布式存储系统，提供高可用性和容错能力，支持对象存储、块存储和文件存储。
GlusterFS：一个分布式文件系统，提供数据冗余和高可用性。
Storage Area Network (SAN)：提供集中管理的高可用性存储解决方案。

5). 监控与报警工具

Prometheus：开源监控系统，提供强大的时间序列数据存储和查询功能，支持报警。
Grafana：与Prometheus等监控工具配合使用，提供可视化面板和报警功能。
Nagios：监控和报警工具，支持广泛的插件和通知机制。

6). 云服务高可用性

Amazon Web Services (AWS)：提供各种高可用性服务和解决方案，包括Elastic Load Balancing、Amazon RDS、Auto Scaling等。
Google Cloud Platform (GCP)：提供Cloud Load Balancing、Cloud SQL等高可用性服务。
Microsoft Azure：提供虚拟机规模集、Azure SQL Database、Traffic Manager等高可用性解决方案。

这些工具和技术可以根据实际需求和架构选择使用，以实现系统的高可用性。

3、Keepalived介绍

0-1）Keepalived是什么、功能介绍：

基于VRRP协议(虚拟路由冗余协议 Virtual Route Redundancy Protocol)，实现自动故障转移
Keepalived 是一个用于实现高可用性和负载均衡的工具，广泛用于Linux环境中。它主要提供故障转移和负载均衡功能，尤其在需要高可用性的系统中非常有用。

Keepalived的功能

故障转移（Failover）:

Keepalived 可以配置多个节点（如主服务器和备份服务器），并使用虚拟路由冗余协议（VRRP）来管理这些节点的故障转移。当主节点出现故障时，备份节点将自动接管其功能，从而确保服务的连续性。

负载均衡:

Keepalived 可以与 LVS（Linux Virtual Server）配合使用，提供负载均衡功能。它将入站流量分配到多个后端服务器，以实现负载均衡，从而提高系统的性能和可用性。

*注：Nginx和LVS在负载均衡上使用的区别：

Nginx 和 LVS（Linux Virtual Server）都可以实现负载均衡，但它们在配置和工作方式上有一些区别。以下是它们在负载均衡配置上的主要区别和实际示例。

1. Nginx 负载均衡

Nginx 通常用于应用层（第七层）负载均衡，支持多种负载均衡算法，且可以处理更复杂的路由规则和请求转发。下面是一个 Nginx的负载均衡配置示例：

http {
    upstream backend {
        server 192.168.1.101 weight=3;
        server 192.168.1.102 weight=2;
        server 192.168.1.103 weight=1;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://backend;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }
}

在这个配置中：

upstream backend 定义了一个负载均衡池，包含多个服务器及其权重。
proxy_pass 将请求转发到 backend 池中的服务器。
proxy_set_header 设置了转发请求时的头信息。

2. LVS 负载均衡

LVS 通常用于传输层（第四层）负载均衡，主要处理 IP 和端口的转发，适用于更高效的流量处理。下面是一个 LVS 的负载均衡配置示例：

! Configuration File for keepalived

global_defs {
   router_id LVS_DEVEL
}

virtual_server 192.168.1.100 80 {
    delay_loop 5
    lb_algo wrr
    lb_kind NAT
    real_server 192.168.1.101 80 {
        weight 1
        HTTP_GET {
            url {
                path /health
                status_code 200
            }
            connect_timeout 10
            fall 2
            rise 2
        }
    }
    real_server 192.168.1.102 80 {
        weight 1
        HTTP_GET {
            url {
                path /health
                status_code 200
            }
            connect_timeout 10
            fall 2
            rise 2
        }
    }
}

在这个配置中：

virtual_server 192.168.1.100 80 定义了一个虚拟服务器的 IP 和端口。
lb_algo wrr 使用加权轮询算法。
lb_kind NAT 使用网络地址转换负载均衡方式。
real_server 定义了多个真实服务器及其健康检查配置。

总结

Nginx：通常用于工作在应用层，支持复杂的请求处理和转发，适合需要应用层处理的场景。
LVS：工作在传输层，专注于高效的 IP 和端口转发，适合大规模的流量处理。

选择哪种方式取决于具体需求，包括处理复杂请求的能力和流量处理效率。

Nginx 的四层负载均衡主要是指其在 TCP 层（第四层）进行的负载均衡，它处理的是 TCP 流量而非 HTTP 请求。它工作在 OSI模型的传输层，根据 TCP 连接的基本信息（如 IP 地址和端口）来分发流量。以下是对四层负载均衡的详细说明及其配置方法。

Nginx 四层负载均衡的工作原理

传输层负载均衡： Nginx 在四层负载均衡模式下处理 TCP 流量。它根据客户端的 IP 地址和端口，及目标服务器的 IP 地址和端口，来决定如何将请求分发到后端服务器。

负载均衡算法： Nginx 支持多种负载均衡算法，例如轮询（Round Robin）、最少连接（Least Connections）等。你可以根据需要选择不同的算法来平衡负载。

以下是一个配置示例，展示了如何在 Nginx 中配置四层负载均衡：

配置四层负载均衡： 在 http 块外创建一个 stream 块，并在其中配置四层负载均衡。以下是一个示例配置：

stream {
    upstream backend {
        server 192.168.1.2:3306;
        server 192.168.1.3:3306;
    }

    server {
        listen 3306;
        
        proxy_pass backend;
        proxy_timeout 10m;
        proxy_connect_timeout 5s;
    }
}

在这个配置示例中：

stream 块：用于定义四层负载均衡配置。
upstream backend 块：定义了后端服务器的组。这里的 server 指令定义了两个后端 MySQL 数据库服务器。
server 块：定义了负载均衡的监听端口（3306）。proxy_pass backend 指令将流量转发到上面定义的 backend 服务器组。
proxy_timeout 和 proxy_connect_timeout：分别设置代理连接的超时时间和连接超时时间。

Nginx 的四层负载均衡是处理 TCP 流量的高效方法。通过正确配置 stream 块和 upstream 块，你可以轻松实现基于TCP 的负载均衡。根据你的具体需求，你可以调整负载均衡算法和超时时间等参数，以优化性能和稳定性。

LVS (Linux Virtual Server) 是一个在 Linux 操作系统上实现的负载均衡解决方案。它能将传入的流量分发到多台后端服务器上，从而提高系统的负载能力和可靠性。LVS工作在网络层（第4层），主要用于处理和分发网络流量。

一 LVS 的用途

负载均衡：将请求分配到多台服务器，提高处理能力。
高可用性：通过冗余配置减少单点故障。
扩展性：系统能够随着需求的增加而扩展。

二 在 CentOS 7 中配置 LVS

1. 安装必要的软件包

sudo yum install ipvsadm

ipvsadm 是管理 LVS 的工具。

2. 配置 LVS

LVS 主要有两种负载均衡方式：NAT（网络地址转换）和 DR（直接路由）。
注：这两种负载均衡方式的区别：
NAT（网络地址转换）

工作原理：在 NAT 模式下，LVS 服务器处理所有入站和出站流量的网络地址转换。客户端请求会先到达 LVS，然后 LVS 将请求转发到后端服务器，同时修改数据包的目标地址为后端服务器的 IP 地址。后端服务器处理请求后，响应数据包会返回到 LVS，LVS再将其转发给客户端，同时将源地址转换回 LVS 的虚拟 IP 地址。

优点：

简单易配置。
后端服务器的 IP 地址可以隐藏在 LVS 之后，提高了安全性。

缺点：

LVS 服务器会处理所有的流量，可能成为性能瓶颈。
每个请求和响应都需要进行地址转换，可能会增加延迟。

DR（直接路由）

工作原理：在 DR 模式下，LVS 服务器仅负责流量的负载均衡，而不对数据包进行地址转换。客户端请求直接到达后端服务器的 IP 地址，后端服务器的响应也直接返回给客户端。LVS 服务器仅在请求的负载均衡阶段进行干预，数据包的目标 IP 地址为虚拟 IP地址，但实际的数据包由后端服务器处理。

优点：

减少了地址转换的开销，提高了性能。
后端服务器处理请求的速度较快，因为它们直接处理请求，无需经过 LVS 服务器进行额外的转换。

缺点：

后端服务器的 IP 地址对客户端是可见的，可能存在安全隐患。
需要确保后端服务器的网络配置支持直接路由，这对网络设置有一定要求。

总结

NAT：处理所有的流量和地址转换，配置简单，但可能成为性能瓶颈。
DR：提高了性能，但要求网络配置较为复杂，后端服务器的 IP 地址对客户端可见。

根据实际需求和网络环境，你可以选择适合的负载均衡模式。

1）配置 NAT（Network Address Translation）模式

设置虚拟服务

  sudo ipvsadm -A -t <VIP>:<PORT> -s rr

其中 <VIP> 是虚拟 IP，<PORT> 是端口号（例如 80），-s rr 表示使用轮询调度算法。

添加真实服务器

sudo ipvsadm -a -t <VIP>:<PORT> -r <REAL_SERVER>:<PORT> -m

其中 <REAL_SERVER> 是后端服务器的 IP 地址。

查看配置

sudo ipvsadm -L -n

2）配置 DR（Direct Routing）模式

设置虚拟服务

sudo ipvsadm -A -t <VIP>:<PORT> -s rr

添加真实服务器

sudo ipvsadm -a -t <VIP>:<PORT> -r <REAL_SERVER>:<PORT> -g

-g 表示直接路由模式。

设置 ARP 响应

使 LVS 主机在网络上对虚拟 IP 的 ARP 请求作出响应：

  echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind

查看配置

sudo ipvsadm -L -n

3. 配置高可用性（可选）

为了确保 LVS 本身的高可用性，你可以使用 keepalived 来监控 LVS 状态并自动故障转移。

sudo yum install keepalived

然后编辑 /etc/keepalived/keepalived.conf 文件进行配置。

二、LVS 与 Nginx 的具体区别

LVS：

工作层次：第4层（传输层）。
功能：主要用于负载均衡，处理网络流量的分发，不涉及内容处理。
模式：支持 NAT、DR 和 TUN（隧道）模式。
用途：高效的流量分发，适用于大规模负载均衡。

Nginx：

工作层次：主要在第7层（应用层）。
功能：提供反向代理、负载均衡、内容缓存、SSL 终止等。
模式：主要是基于应用层的负载均衡，支持 HTTP、HTTPS、TCP 和 UDP。
用途：除了负载均衡，还可以处理 HTTP 请求，缓存静态内容，优化应用性能。

总结来说，LVS 是一个底层负载均衡解决方案，主要处理流量的分发，而 Nginx提供了更丰富的功能，可以处理请求的内容、缓存和更多应用层的功能。两者可以结合使用，例如使用 LVS 进行流量分发，并在每台真实服务器上运行Nginx 进行更细粒度的负载均衡和内容处理。

健康检查:

Keepalived 通过定期检查后端服务的健康状态来确定其是否正常工作。如果某个服务出现问题，Keepalived 可以自动将流量转移到健康的节点上。

虚拟IP地址管理:

Keepalived 可以管理虚拟IP地址（VIP）。VIP 可以在集群中的不同节点之间转移，从而实现故障转移和负载均衡。

脚本和通知:

支持自定义脚本来处理节点状态变化或故障转移过程中的特定操作。例如，可以在故障转移时发送通知或执行清理操作。

实际应用场景

Web服务的高可用性:

在多个Web服务器上部署Keepalived，确保在某个Web服务器故障时，流量自动转移到其他健康的服务器。结合负载均衡，可以提升整个Web服务的可用性和性能。

数据库高可用性:

在数据库集群中使用Keepalived来管理数据库主节点和备份节点之间的故障转移。例如，主数据库节点出现故障时，备份数据库节点可以自动接管，确保数据服务的持续可用性。

负载均衡:

使用Keepalived和LVS进行负载均衡，将客户端请求分配到多个应用服务器上。这对于需要处理大量请求的应用程序（如电子商务平台）特别有效。

邮件服务器高可用性:

部署Keepalived来管理邮件服务器的故障转移。例如，邮件服务器群集中的主服务器发生故障时，备份邮件服务器可以自动接管，确保邮件服务不会中断。

VPN和远程访问服务:

对于需要高可用性的VPN服务，使用Keepalived可以确保VPN服务器的故障不会影响用户的远程访问能力。

分布式系统:

在分布式系统中，Keepalived 可以用来管理和协调系统中的多个节点，确保系统的高可用性和可靠性。

Keepalived 的这些功能和应用场景使其成为实现高可用性解决方案的强大工具，特别适合于需要保证服务连续性和系统稳定性的环境。

*注：具体如何使用Keepalived和LVS进行负载均衡，具体配置是什么样的？

使用 Keepalived 和 LVS 进行负载均衡涉及两个主要组件：LVS（Linux Virtual Server）提供负载均衡功能，而Keepalived 负责高可用性和虚拟 IP 的管理。以下是一个简化的配置步骤和示例。

一 环境概述

LVS 负载均衡器（假设有两个节点）：LVS-1 和 LVS-2
后端服务器（假设有两个）：WEB-1 和 WEB-2
虚拟 IP 地址：192.168.1.100

二 安装软件

在所有节点上安装 lvs 和 keepalived：

sudo apt-get update
sudo apt-get install ipvsadm keepalived

三 配置 LVS

在 LVS-1 和 LVS-2 上配置 LVS：

配置 LVS 负载均衡

编辑 /etc/keepalived/keepalived.conf：

global_defs {
    notification_email {
        your-email@example.com
    }
    notification_email_from keepalived@example.com
    smtp_server 127.0.0.1
    smtp_connect_timeout 30
    router_id LVS_DEVEL
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0  # 负载均衡器的网络接口
    virtual_router_id 51
    priority 101
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.1.100
    }
}

virtual_server 192.168.1.100 80 {
    delay_loop 6
    lb_algo rr
    lb_kind NAT
    nat_mask 255.255.255.0
    persistence_timeout 50
    protocol TCP

    real_server 192.168.1.101 80 {
        weight 1
        HTTP_GET {
            url {
                path /
                digest 1234567890abcdef
                status_code 200
            }
        }
    }

    real_server 192.168.1.102 80 {
        weight 1
        HTTP_GET {
            url {
                path /
                digest 1234567890abcdef
                status_code 200
            }
        }
    }
}

这里的 virtual_server 配置了虚拟 IP 和负载均衡算法。real_server 配置了实际的后端服务器。

启动 Keepalived

启动服务并设置为开机自启动：

sudo systemctl start keepalived
sudo systemctl enable keepalived

同样的配置应在 LVS-2 上设置，但 state 应设置为 BACKUP，priority 应设置为比
LVS-1 低。

四 配置后端服务器

确保后端服务器（WEB-1 和 WEB-2）的 web 服务正常运行，并且它们可以接受来自负载均衡器的请求。

五测试

检查 LVS 配置

使用 ipvsadm 查看 LVS 配置是否正确：

bash sudo ipvsadm -L -n

测试虚拟 IP

在客户端机器上访问 192.168.1.100，确认流量是否均匀分配到后端服务器。

六总结

LVS 处理负载均衡流量。
Keepalived 管理虚拟 IP 和高可用性。

确保 keepalived 和 lvs 的配置文件在所有节点上正确设置，并且服务在所有相关机器上启动正常。

0-2）Keepalived底层实现原理：

Keepalived 是一个用于高可用性和负载均衡的工具，它主要利用了 VRRP（Virtual Router Redundancy Protocol）协议来实现高可用性，并通过多种负载均衡算法来分配流量。以下是 Keepalived 的底层实现原理的详细说明：

一. VRRP 协议

Keepalived 的高可用性功能是基于 VRRP 协议的。VRRP 协议的工作原理如下：

虚拟路由器：VRRP 允许多个路由器（或服务器）共享一个虚拟 IP 地址。这个虚拟 IP 地址在网络中看起来像是一个实际的路由器的 IP 地址。
优先级机制：在 VRRP 中，每个参与的节点都有一个优先级值。优先级最高的节点（称为主节点）负责处理所有到虚拟 IP 的流量。如果主节点失败，优先级次高的备用节点将接管主节点的任务。
心跳机制：主节点会定期发送 VRRP 广播包（心跳包）到网络中。如果备用节点在一定时间内没有接收到主节点的心跳包，它将认为主节点已失败，并将自己提升为新的主节点。

二. Keepalived 的工作流程

Keepalived 在底层通过以下方式实现其功能：

配置文件：Keepalived 的配置文件 keepalived.conf 定义了 VRRP 实例、虚拟 IP、健康检查等配置。配置文件中的每个 VRRP 实例代表一个虚拟路由器，包括其优先级和相关的虚拟 IP。
VRRP 实例：每个 VRRP 实例由 Keepalived 创建和维护。它负责处理与虚拟 IP 相关的所有 VRRP 协议的操作，包括心跳包的发送和接收。
健康检查：Keepalived 定期执行健康检查（通过脚本或内置的检查方法）来监控服务或节点的健康状态。如果健康检查失败，Keepalived
可以将节点标记为不可用，并通知其他节点进行相应的调整。

三. 负载均衡实现

Keepalived 的负载均衡功能通过以下方式实现：

LVS（Linux Virtual Server）：Keepalived 可以与 LVS 配合使用，LVS 是一个 Linux 内核模块，用于提供负载均衡功能。Keepalived 通过配置 LVS 的负载均衡策略（如轮询、最少连接数等）来分配流量。
负载均衡算法：Keepalived 支持多种负载均衡算法，包括轮询、最少连接、加权轮询等。配置文件中定义的算法决定了如何将流量分配到后端服务器。
健康检查：Keepalived 可以在负载均衡模式下执行健康检查，确保只有健康的后端服务器接收流量。如果一个服务器被标记为不可用，它将不会被分配新的连接。

四. 实现细节

心跳包：Keepalived 使用 VRRP 协议的心跳包（VRRP Advertisement）来确定主节点的状态。这些心跳包是周期性发送的，用于更新其他节点的状态。
状态转换：根据心跳包的接收情况，Keepalived 在节点之间进行状态转换（如从主节点到备用节点），确保在故障发生时服务可以继续运行。
脚本执行：Keepalived 支持执行自定义脚本来处理健康检查和其他任务。这些脚本可以在节点状态发生变化时执行，例如在主节点失败时启动备用节点的服务。

五. 系统集成

Netfilter：在负载均衡模式下，Keepalived 依赖于 Linux 的 Netfilter 框架来实现流量转发和负载均衡。
虚拟网络接口：Keepalived 创建虚拟网络接口（如 vrrp0），用于管理虚拟 IP 地址和流量的转发。

通过这些机制和技术，Keepalived 实现了高可用性和负载均衡功能，确保服务的连续性和系统的稳定性。

1）VRRP：

VRRP是为了解决以下问题：

在这里插入图片描述
注：ARP

ARP（Address Resolution Protocol，地址解析协议）是网络协议中的一种，用于在局域网中将网络层地址（如 IP
地址）映射到数据链路层地址（如 MAC 地址）。这在以太网等局域网环境中是非常重要的，因为以太网帧在传输数据时需要使用物理地址（MAC
地址）。

一、ARP 的工作原理

ARP 请求：当一台主机需要发送数据包到同一局域网中的另一台主机时，它需要知道对方的 MAC 地址。如果它只知道对方的 IP 地址，它会发送一个 ARP 请求广播包到网络上。ARP 请求包中包含了发送者的 IP 地址和 MAC 地址，以及目标的 IP 地址。

ARP 响应：局域网中的所有设备都会收到这个 ARP 请求包。目标主机（即拥有请求中的目标 IP 地址的主机）会检查请求包。如果目标主机匹配请求中的 IP 地址，它会发送一个 ARP 响应包回发送者。ARP 响应包中包含目标主机的 MAC
地址和 IP 地址。

缓存：发送者收到 ARP 响应后，将目标主机的 MAC 地址存储在本地 ARP 缓存中。这样在未来的通信中，它可以直接使用缓存中的 MAC 地址，而无需再次发送 ARP 请求。

数据传输：一旦发送者知道了目标主机的 MAC 地址，它就可以将数据包封装在以太网帧中，并将其发送到目标主机的 MAC 地址上。

二、ARP 缓存

为了减少 ARP 请求的数量和网络负载，主机会将 ARP 响应中得到的 IP 地址和 MAC 地址映射关系存储在本地的 ARP
缓存中。这个缓存会定期更新，通常会在一定时间后过期并重新请求。

三、ARP 的应用

局域网通信：ARP 在局域网内部用于帮助主机找到其他主机的 MAC 地址，从而实现数据包的正确传输。

网络设备：网络设备（如路由器、交换机）也使用 ARP 协议来处理和转发网络流量。

四、ARP 的安全性问题

ARP 是一种无状态协议，因此它容易受到伪造的 ARP 响应（ARP 欺骗或 ARP
中毒）的攻击。这种攻击可以使网络中的流量被截获、篡改或丢失。为了保护网络安全，可以采用如动态 ARP 检测（DAD）、静态 ARP
表和其他安全措施来防范 ARP 欺骗攻击。

总体来说，ARP 是局域网中不可或缺的协议，确保了 IP 地址到 MAC 地址的正确映射，从而实现数据的有效传输。

注：VRRP是什么

VRRP（Virtual Router Redundancy
Protocol）是一种网络协议，旨在提高网络中默认网关的可靠性。它通过在网络设备之间提供冗余的虚拟网关，来确保网络的持续可用性。

一、原理

VRRP 的基本原理是通过虚拟路由器（Virtual Router）的概念来实现冗余。当网络中的某个设备（称为 VRRP主路由器）发生故障时，另一台设备（称为 VRRP 备份路由器）会自动接管虚拟路由器的角色，以确保网络连接不会中断。

虚拟路由器：VRRP 定义了一个虚拟路由器，它由一组物理路由器共同管理。虚拟路由器有一个虚拟 IP 地址和一个虚拟 MAC 地址。

主路由器和备份路由器：在 VRRP 配置中，其中一台物理路由器被指定为主路由器（Master Router），其他的则是备份路由器（Backup Routers）。主路由器负责处理所有通过虚拟 IP 地址的流量。

选举过程：备份路由器会定期发送 VRRP 通告消息，以保持其与主路由器的通信。如果主路由器失效或停止响应，备份路由器会通过选举过程自动成为新的主路由器。

优先级：每台路由器在 VRRP 中都有一个优先级值。优先级较高的路由器更有可能被选为主路由器。

二、应用场景

VRRP 主要用于以下场景：

提高网络可靠性：通过提供冗余的网关，VRRP 确保了当主路由器失效时，网络流量可以迅速切换到备份路由器，避免了单点故障。

企业网络：在企业网络中，VRRP 可以用于提供主路由器的冗余，确保关键业务系统的网络连接不会因为路由器的故障而中断。

数据中心和云环境：在数据中心或云环境中，VRRP 可以用来提升虚拟路由器的可用性，确保服务的高可用性和稳定性。

ISP 和服务提供商：互联网服务提供商（ISP）和其他网络服务提供商可以使用 VRRP 来提高其网络基础设施的可靠性，减少由于设备故障导致的服务中断。

总之，VRRP 是一种重要的网络协议，它通过提供路由器冗余，确保了网络的高可用性和稳定性。

在这里插入图片描述
注：
VMAC与VIP与实际MAC、实际IP如何做到不冲突的？之间的关系？

在 VRRP（Virtual Router Redundancy Protocol）中，VMAC（虚拟 MAC 地址）、VIP（虚拟 IP地址）、实际 MAC 地址和实际 IP 地址是如何工作的，并且如何避免冲突，这是一个非常有趣且复杂的问题。下面是详细的解释：

一、VRRP 相关概念

VIP（Virtual IP Address）：这是 VRRP 协议中配置的虚拟 IP 地址。这个地址并不直接绑定到任何一个路由器的物理接口上，而是被配置为虚拟的，以便在主路由器发生故障时可以转移给备用路由器。

VMAC（Virtual MAC Address）：这是 VRRP 协议中配置的虚拟 MAC 地址。它用于确保在 VIP 转移时，网络上的流量可以顺利地转发到新的主路由器。VMAC 是由 VRRP 协议在协议运行时生成和管理的。

实际 MAC 地址：这是物理网络接口卡的 MAC 地址。每台物理路由器的每个接口都有一个唯一的 MAC 地址。

实际 IP 地址：这是每台物理路由器上配置的实际 IP 地址，用于与其他设备进行通信。

二、关系和底层实现原理

VIP 和 VMAC 的关系：

VRRP 的核心在于通过 VIP 和 VMAC 实现冗余路由。VIP 是所有 VRRP 路由器共享的虚拟 IP 地址，而 VMAC 是与 VIP 相关联的虚拟 MAC 地址。
当 VRRP 主路由器（Master Router）发送 ARP 响应时，它会将 VMAC 映射到 VIP 上，这样网络中的设备就能将数据包发送到虚拟 MAC 地址上。

如何避免冲突：

VIP 和实际 IP 地址：VIP 是虚拟的，不会与任何实际 IP 地址冲突。实际 IP 地址是路由器物理接口上的地址，而 VIP 是用于整个 VRRP 群组的虚拟地址。网络中的设备在向 VIP 发送数据包时，会使用 VMAC
作为目标地址。
VMAC 和实际 MAC 地址：VMAC 是动态分配的虚拟地址，不会与任何路由器的实际 MAC 地址发生冲突。VRRP 确保在同一网络中，只有一个设备在某个时刻使用特定的 VMAC，这样就避免了冲突。

底层实现原理：

主备切换：在 VRRP 中，当主路由器出现故障或不可用时，备用路由器会检测到这一情况并接管 VIP 和 VMAC。备用路由器会开始使用 VMAC 作为其物理接口的 MAC 地址，从而确保流量继续流向新的主路由器。
ARP 通知：VRRP 主路由器定期发送 ARP 通告，告知网络其他设备 VIP 对应的 VMAC 地址。这样，即使主路由器切换，网络中的设备也会自动更新其 ARP 缓存，以便将流量发送到新的 VMAC 地址上。
VRRP 广播：VRRP 协议通过定期广播 VRRP 报文来维护路由器的状态，确定哪个路由器是主路由器。备用路由器会根据这些信息决定是否需要接管 VIP 和 VMAC。

总之，VRRP 通过 VMAC 和 VIP 机制实现了路由器的冗余和自动故障转移，确保了网络的可靠性和稳定性。实际 MAC 地址和实际 IP地址在这种机制中起到的是支持和补充作用，不会与虚拟地址发生冲突。

2）Keepalived的相关概念

选举投票机制

——配置优先级，决定分配熟为主节点、从节点
Keepalived的选举投票机制是为了确保高可用性服务中的主备切换。它的底层实现主要通过虚拟路由冗余协议（VRRP）。在VRRP中，所有参与的节点通过心跳包相互通信，并通过一个简单的选举算法来决定哪个节点成为主节点。具体来说，主节点的选举基于优先级和节点的优先级值，优先级值最高的节点会成为主节点。如果主节点失效，其他节点会基于优先级进行重新选举，以确定新的主节点。

抢占式、非抢占式机制

——是否强制决定熟为主从节点
决定主备机谁去占有VMAC、VIP另一种机制，决定是否依赖于选举投票机制
在Keepalived中，抢占式和非抢占式机制决定了主节点的切换策略：

抢占式机制：如果一个节点的优先级比当前主节点高，它将自动抢占成为新的主节点。通过设置preempt参数，当主节点故障后，从节点会自动接管，如果之前的主节点恢复了，那么会将VIP强回来
非抢占式机制：即使一个节点的优先级比当前主节点高，它也不会自动抢占。这个机制下，主节点不会被新的优先级更高的节点替换，直到当前主节点失败或重新启动。这是通过Keepalived的配置中的nopreempt参数控制的。如果设置为preempt，即允许抢占。

底层实现中，Keepalived使用VRRP协议来进行心跳检测和选举过程。节点通过VRRP的选举机制来决定主节点，抢占与否由节点的优先级和配置决定。主节点故障后，从节点会自动接管，如果之前的主节点恢复了，因为设置了nopreempt参数，那么即便之前这个主节点比当前已接管的节点的优先级高，它也不会强制将当前已接管的节点占有的VIP抢过来

脑裂状态

主备机同时抢占VMAC、VIP时出现的非正常状态，具体解释如下：

Keepalived的“脑裂”状态发生在多个节点同时认为自己是主节点的情况。这通常发生在网络分区或心跳丢失时，导致节点之间无法正确同步主节点的状态。

造成脑裂的原因包括：

网络分区：网络出现问题，导致节点无法相互通信。
注：
网络分区是指网络中的一部分节点无法与另一部分通信，通常由于网络故障、配置问题或硬件故障。它会导致网络的某些节点无法互相接收到数据或消息，从而影响服务的正常运行和状态同步。
“网络分区”这个术语描述了网络被“分割”成几个独立的区域，这些区域之间无法相互通信。这个“分区”指的是网络逻辑上的隔离，而不是物理上的隔离。每个分区中的节点可以互相通信，但分区之间的节点无法进行数据交换。
心跳丢失：心跳包丢失或延迟过长，节点误以为主节点失效。
配置不一致**：不同节点的配置文件不一致，导致选举过程出错。

复刻脑裂状态的方法：

故意断开网络：通过切断主节点和备份节点之间的网络连接，模拟网络分区。
配置不一致：在不同节点上设置不同的优先级或配置，以制造心跳丢失。
人为延迟：通过网络工具或故障模拟器引入网络延迟，使心跳包丢失。

3）keepalived的工作流程概述

在主节点上进行“心跳检测”，根据上述机制；检查主机是否存活；
如果检测失败（即主节点出现故障），那么会kill主节点的keepalived的进程；
然后，依据上述机制；将VIP、VMAC分配到从节点中

二、配置Keepalived

0、*Keepalived健康检查机制：

Keepalived 的健康检查机制主要通过 check 和 track 相关配置项实现，用于监控和验证后端服务器或网络接口的状态，以确保高可用性和负载均衡。具体来说，Keepalived 使用了以下几种健康检查机制：

VIPS 健康检查

在 Keepalived 的 VRRP (Virtual Router Redundancy Protocol) 配置中，健康检查机制通常用于监控虚拟 IP (VIP) 的可用性。Keepalived 会检查 VRRP 实例所管理的 VIP 的状态，以确保主节点能够正确地处理流量。

配置示例

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 101
    advert_int 1

    authentication {
        auth_type PASS
        auth_pass mysecret
    }

    virtual_ipaddress {
        192.168.1.100
    }

    track_script {
        ......
    }
}

脚本健康检查

Keepalived 允许通过脚本进行健康检查。这种方式通常用于检查后端服务器的健康状态，比如应用服务器或数据库服务器。健康检查脚本会定期执行，并根据返回结果来决定是否认为后端服务器可用。Keepalived 通过执行脚本来检测服务或应用程序的健康状况，从而决定是否将虚拟 IP 地址从主节点转移到备份节点。

一. 脚本健康检查概述

健康检查功能通过 vrrp_script 配置块定义，这些脚本会定期执行并根据其返回值来决定是否将 VIP 从一个节点转移到另一个节点。

二. 配置健康检查的步骤

编写健康检查脚本

首先，你需要编写一个脚本，用于检查某项服务或应用程序的健康状态。脚本应该返回 0 表示成功，非 0 表示失败。例如，一个简单的脚本检查HTTP 服务是否在运行：

#!/bin/bash
# /usr/local/bin/check_http.sh

if curl -s --head http://localhost | grep "200 OK" > /dev/null; then
    exit 0
else
    exit 1
fi

确保脚本有执行权限：

chmod +x /usr/local/bin/check_http.sh

配置 Keepalived

在 keepalived.conf 配置文件中，定义一个 vrrp_script
块来指定脚本，以及相关的参数，如间隔时间和权重。然后，将该脚本与 vrrp_instance 配置块中的 track_script
参数关联。

以下是一个示例配置：

global_defs {
    router_id LVS_DEVEL
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 101
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1234
    }
    virtual_ipaddress {
        192.168.1.100
    }
    track_script {
        chk_http
    }
}

vrrp_script chk_http {
    script "/usr/local/bin/check_http.sh"
    interval 2
    weight 2
}

script：指定要执行的脚本路径。
interval：定义脚本执行的时间间隔（单位是秒）。
weight：根据脚本的返回值调整节点的权重。返回 0 时加上 weight 值，非 0 时则减去 weight 值。

验证配置

在修改了配置文件之后，重启 Keepalived 服务以应用新配置：

sudo systemctl restart keepalived

检查 Keepalived 的状态和日志，以确认配置是否生效：

sudo systemctl status keepalived

查看日志文件，如 /var/log/syslog 或 /var/log/messages，以获取详细信息。

三. 注意事项

脚本权限：确保健康检查脚本具有适当的执行权限。
脚本输出：脚本应仅返回 0 或非 0 状态码。其他输出可能会干扰 Keepalived 的正常操作。
日志检查：如果脚本执行结果没有预期的效果，检查日志文件以找出潜在问题。

通过正确配置健康检查脚本和 Keepalived，你可以确保集群中的节点能根据健康状态自动调整，

脚本健康检查的关键参数：

script：指定要执行的脚本路径。
interval：脚本执行的时间间隔（秒）。
timeout：脚本执行的超时时间（秒）。
fall：表示在多少次失败后判定为不可用。这个参数指定了在健康检查脚本连续失败多少次后，Keepalived会认为后端服务器或服务不可用。例如，如果设置fall为3，那么在脚本连续失败三次后，Keepalived会将该服务器的状态标记为DOWN。
rise：表示在多少次成功后判定为可用。这个参数指定了在健康检查脚本连续成功多少次后，Keepalived会认为后端服务器或服务恢复为可用状态。例如，如果设置rise为2，那么在脚本连续成功两次后，Keepalived会将该服务器的状态标记为UP。

网络接口健康检查

Keepalived 可以监控网络接口的状态。这主要用于监控接口是否处于活动状态，并根据接口的健康状态来决定是否切换主备角色。

配置示例

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 101
    advert_int 1

    authentication {
        auth_type PASS
        auth_pass mysecret
    }

    virtual_ipaddress {
        192.168.1.100
    }

    track_interface {
        eth0
    }
}

track_interface 参数：

track_interface { eth0 }：表示 Keepalived 将监控 eth0 接口。如果该接口变为 DOWN，可能会导致主节点状态转移到备用节点。

健康检查脚本的内容示例

一个简单的健康检查脚本（check_http.sh）可能如下：

#!/bin/bash

URL="http://localhost/health"

# 使用 curl 检查 HTTP 服务是否可用
if curl --silent --fail "$URL" >/dev/null; then
    exit 0  # 成功
else
    exit 1  # 失败
fi

这个脚本尝试通过 curl 请求一个健康检查的 URL。如果请求成功（返回码为 0），脚本退出码为 0，表示服务可用；否则，退出码为 1，表示服务不可用。

总结

Keepalived 的健康检查机制可以通过 VRRP 实例的状态检查、脚本检查和接口状态检查来实现。它们协同工作，确保系统的高可用性和负载均衡。通过这些检查，Keepalived 能够在后端服务器出现故障或网络问题时及时采取行动，例如切换主节点或将流量转移到健康的服务器。

1、安装keepalived

如：两台负载均衡服务器中分别安装

yum install keepalived

2、配置语法

配置文件格式：

Keepalived 的配置文件格式遵循一种简洁的、基于文本的规则，不涉及复杂的嵌套结构。其配置文件的语法与传统的 INI 文件格式相似，但有些特定的规则和结构。下面详细说明 Keepalived 配置文件的格式规则以及 INI 文件结构的基本概念。

一、Keepalived 配置文件格式规则

块结构：

配置文件以块结构组织，其中每个块以特定的标识符开始。例如，global_defs、vrrp_instance 和 virtual_server 是主要的配置块。
每个块都定义了相关的配置项，块的结束由换行或下一个块的开始标志表示。

参数定义：

在每个块中，参数通常以 key value 的形式定义。例如，state MASTER、interface eth0。
参数可以有不同的数据类型，包括字符串、数字和列表。

嵌套和子块：

某些配置块可能包含嵌套的子块。例如，vrrp_instance 块中的 authentication 和 virtual_ipaddress 是子块。
子块的定义使用花括号 {} 包含，里面的内容按行书写。

注释：

配置文件支持注释，以 # 开头的行表示注释，注释内容不会被解析器处理。
注释可以出现在配置项的行尾，也可以单独成行。

换行和空白：

配置文件中的换行和空白字符用于分隔配置项和块。解析器忽略多余的空白行和空格。

*二、INI 文件结构

INI 文件是一种简单的配置文件格式，广泛用于配置文件和初始化文件。其基本结构包括：

节（Section）：

INI 文件通过节来组织配置项，每个节以方括号 [section_name] 开始。
节用于分组相关的配置项，使文件更易于组织和管理。

键值对（Key-Value Pair）：

在节中，配置项以 key=value 的形式定义。
键和值之间用等号 = 分隔，键和值都是字符串。

注释：

注释行以分号 ; 或井号 # 开头，表示该行是注释内容。
注释不会被解析器处理，只用于说明。

空白和换行：

空白行和多余的空格被忽略，空白行通常用于增强可读性。
换行用于分隔不同的节和配置项。

三、示例

INI 文件示例：

[database]
host=localhost
port=3306
user=root
password=secret

[server]
host=0.0.0.0
port=8080

Keepalived 配置文件示例（与 INI 文件类似，但有自己特定的规则）：

global_defs {
    router_id LVS_DEVEL
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 101
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1234
    }
    virtual_ipaddress {
        192.168.1.100
    }
}

virtual_server 192.168.1.100 80 {
    delay_loop 6
    lb_algo wrr
    lb_kind NAT
    probe {
        interval 2
        timeout 1
        weight 2
    }
    real_server 192.168.1.10 80 {
        weight 1
        HTTP_GET {
            url {
                path /index.html
                digest e5c0a1f3d7c1
            }
            timeout 3
        }
    }
}

四、总结

Keepalived 配置文件的格式基于文本，使用块结构和简单的参数定义来组织配置。这种格式与 INI
文件的结构类似，但具体语法和规则是针对 Keepalived 服务定制的。两者都旨在提供一种直观的方式来管理配置文件，但
Keepalived 的配置文件具有更强的特定领域定制功能。

具体配置内容组成：

Keepalived 的配置文件通常分为全局配置、虚拟路由器配置。配置文件的语法如下：

Keepalived 的配置文件通常包含几个关键部分，其中一些是必须项，而另一些则是可选的，用于提供额外的功能或细化配置。以下是Keepalived 配置文件的主要内容及其说明：

一. 全局定义（Global Definitions）

router_id: 唯一标识本 Keepalived 实例的名称，用于区分不同的实例。这不是必须的，但在多实例环境中推荐使用。

二. VRRP 实例（VRRP Instances）

vrrp_instance: 定义一个 VRRP 实例，这是配置中的主体部分，每个实例定义一组节点如何协作管理虚拟 IP。
state: 指定当前实例的状态，可以是 MASTER 或 BACKUP。
interface: 指定该实例绑定的网络接口。
virtual_router_id: 虚拟路由器的标识符，同一 VRRP 组的所有节点必须相同。
priority: 节点的优先级，决定故障转移时的抢占逻辑。
advert_int: VRRP 通告间隔时间。
authentication: 认证信息，包括类型和密码，确保通信安全。
virtual_ipaddress: 定义一个或多个虚拟 IP 地址，是 VRRP 实例中的必须项。
track_script: 引用外部脚本来作为健康检查，非必须，但常用于增强健康检查功能。
track_interface: 监控网络接口状态，非必须。

三. 虚拟服务器（Virtual Servers）

virtual_server: 用于配置负载均衡规则，非必须，主要用于与 LVS 结合使用。
delay_loop: 初始延迟时间，用于防止频繁切换。
lb_algo: 负载均衡算法，如 rr（轮询）、wrr（加权轮询）等。
lb_kind: 负载均衡类型，如 NAT、DR 等。
real_server: 定义后端真实服务器及其健康检查规则。

四. 脚本定义（Script Definitions）

script: 定义用于健康检查的脚本，非必须，但常用于自定义健康检查逻辑。

五. 其他配置

preempt: 决定是否允许优先级更高的节点抢占 MASTER 状态，非必须。
no_preempt: 与 preempt 相反，防止高优先级节点抢占当前 MASTER。
smtp_alert: 配置邮件报警，非必须。

六必须的配置项

vrrp_instance 块中的state, interface, virtual_router_id, priority, authentication, 和 virtual_ipaddress 是必须的，因为它们是 VRRP 协议正常运作的基础。

七非必须的配置项

大多数其他配置，如 track_script, virtual_server, preempt, no_preempt 等，都是非必须的，它们用于提供额外的功能或细化控制。

正确配置这些选项可以确保 Keepalived 能够有效地管理高可用性和负载均衡。在实际部署中，应根据具体需求和网络环境来调整配置。

注：vrrp_instance的state可以不配置吗什么情况下一定需要配置？

在 Keepalived 的 vrrp_instance 配置中，state选项可以选择不配置，但这会影响高可用性实现的行为。以下是关于 state 配置的详细说明及其应用场景：

一、默认行为

未配置 state: 如果 vrrp_instance 中没有指定 state，Keepalived 默认将实例状态设为 BACKUP。这样可以确保至少一个节点在没有其他节点的情况下会处于备份状态。

二、需要配置 state 的情况

明确指定角色:

如果你有明确的角色要求，比如某个节点应该总是作为主节点运行，而其他节点作为备份，则需要显式地配置 state。这对于生产环境中的高可用性设置尤其重要，确保角色分配符合设计预期。

高可用性策略:

在具有多个节点的高可用性环境中，如果希望控制哪个节点成为初始的主节点，必须配置 state。例如：
state MASTER: 指定该节点为主节点，应该优先处理流量。
state BACKUP: 指定该节点为备份节点，只有在主节点失败时才接管。

非抢占式配置:

如果使用 nopreempt 选项来防止备份节点在主节点恢复后抢占主节点角色，这时必须明确配置主节点的 state 为 MASTER，而备份节点的 state 为 BACKUP。这确保了主节点的角色不会被备份节点在恢复时抢占。

状态持久化:

在某些应用场景中，需要保证在重启或配置变更后，节点状态保持一致。明确配置 state 有助于确保在重新启动或重新加载配置后，节点的角色按照预期保持不变。

三、总结

可以不配置 state: 在简单的高可用性环境中，未配置 state 可以让 Keepalived 使用默认的备份状态。这样适用于一些基本的配置要求。

需要配置 state: 在需要明确控制节点角色、实施非抢占式策略或确保节点状态一致性的情况下，必须显式配置 state 以满足特定的高可用性需求。

1. 全局配置：
```
global_defs {
    router_id <router_id>
    ...
}
```
- router_id: 每台路由器的唯一标识符。

注：全局配置与router_id的配置：

在配置 Keepalived 时，全局配置块用于定义对所有 VRRP 实例适用的全局设置。以下是关于全局配置的详细说明：

一、全局配置

定义：

全局配置块 (global_defs) 用于设置与所有 VRRP 实例相关的全局参数。这些设置对所有的 VRRP 实例都生效，提供了统一的配置基础。

是否必需：

不一定需要配置全局配置。虽然 global_defs 提供了便捷的全局设置，但如果你的配置比较简单，可能不需要用到它。

主要配置项：

router_id：
定义：router_id 是全局配置中的一部分，用于唯一标识每个 Keepalived 实例。它在 VRRP 环境中用于区分不同的路由器实例。
是否必需：router_id 不是强制性的，但在使用 VRRP 协议时，配置它通常是一个最佳实践。它帮助确保每个 Keepalived 实例在网络中有一个唯一标识，特别是在复杂或大规模环境中尤为重要。

二、如何配置全局配置

1. 配置 router_id：

实际情况：

多实例环境：如果你有多个 Keepalived 实例运行在同一网络中，建议为每个实例配置唯一的 router_id。这可以防止实例间的标识冲突。
高可用性集群：在高可用性集群中，确保每个节点有唯一的 router_id 以避免路由器冲突。

示例配置：

 ```plaintext
 global_defs {
     router_id node1
 }
 ```

在上面的配置中，router_id 被设置为 node1，表示这是网络中的一个唯一标识。

2. 配置其他全局参数：

script_user：指定执行自定义脚本的用户。
daemon：决定是否以守护进程模式运行。
log_facility：设置日志记录的设施。

示例全局配置：

global_defs {
    router_id my_router
    script_user nobody
    daemon
    log_facility local0
}

三、总结

全局配置块 (global_defs) 并不是强制性的，但在实际应用中，特别是复杂的环境中，配置 router_id和其他全局参数有助于管理和区分不同的 Keepalived 实例。router_id在多实例和高可用性配置中尤其重要，它确保每个实例都有唯一的标识。

在 Keepalived 中，router_id 是全局定义的一部分，用于唯一标识每个 Keepalived 实例。通常情况下，每个
Keepalived 实例都会有一个唯一的 router_id。在某些场景下，特别是在大规模或复杂的网络环境中，你可能会遇到需要配置多个
Keepalived 实例，并且每个实例都需要有一个独特的 router_id。以下是一些具体的情境及配置示例：

一、 多个 Keepalived 实例

在一个大规模的环境中，你可能需要在多个物理服务器或虚拟机上运行多个 Keepalived 实例。例如，你在两个不同的数据中心有两个不同的
Keepalived 实例，每个实例需要有不同的 router_id 来进行唯一标识。

配置示例

数据中心 A 的配置

! Configuration File for keepalived

global_defs {
    router_id dcA_node1
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 101
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass secretA
    }
    virtual_ipaddress {
        10.1.1.100
    }
}

数据中心 B 的配置

! Configuration File for keepalived

global_defs {
    router_id dcB_node1
}

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass secretB
    }
    virtual_ipaddress {
        10.2.2.100
    }
}

二、 在同一网络中运行多个 Keepalived 实例

在一个大型网络中，你可能需要在同一网络中的不同节点上运行多个 Keepalived 实例，以支持不同的 VRRP 实例或不同的服务。每个
Keepalived 实例都需要有唯一的 router_id 来区分。

配置示例

节点 1 的配置

! Configuration File for keepalived

global_defs {
    router_id node1
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 101
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass secret1
    }
    virtual_ipaddress {
        192.168.1.100
    }
}

节点 2 的配置

! Configuration File for keepalived

global_defs {
    router_id node2
}

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass secret2
    }
    virtual_ipaddress {
        192.168.1.100
    }
}

三、 高级场景中的多个 VRRP 实例

在某些高级场景中，你可能在同一个节点上配置多个 VRRP 实例，以支持不同的虚拟路由器 ID。即使在同一节点上，你也需要确保每个实例有唯一的
router_id。

配置示例

节点 A 的配置

! Configuration File for keepalived

global_defs {
    router_id nodeA
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 101
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass secret1
    }
    virtual_ipaddress {
        192.168.1.100
    }
}

vrrp_instance VI_2 {
    state BACKUP
    interface eth0
    virtual_router_id 52
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass secret2
    }
    virtual_ipaddress {
        192.168.1.101
    }
}

节点 B 的配置

! Configuration File for keepalived

global_defs {
    router_id nodeB
}

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass secret1
    }
    virtual_ipaddress {
        192.168.1.100
    }
}

vrrp_instance VI_2 {
    state MASTER
    interface eth0
    virtual_router_id 52
    priority 101
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass secret2
    }
    virtual_ipaddress {
        192.168.1.101
    }
}

四、总结

在不同的环境中，特别是在多实例配置的场景下，确保每个 Keepalived 实例有唯一的 router_id
是很重要的。router_id 帮助避免在网络中出现路由器标识的冲突，确保 VRRP 协议的正常运作。

在上面的配置示例中，节点A和节点B指的是不同的机器。具体来说：

节点 A 和 节点 B 分别代表在不同物理服务器或虚拟机上运行的 Keepalived 实例。每个节点在网络中都有唯一的标识符 router_id，这个标识符用于确保在 VRRP (Virtual Router Redundancy Protocol) 环境中每个 Keepalived 实例可以被唯一识别。

一、 节点 A 的配置
在节点 A 的配置中，router_id 被设置为 nodeA。节点 A 配置了两个 VRRP 实例(VI_1 和 VI_2)，分别对应不同的虚拟路由器 ID (51 和 52)。

二、 节点 B 的配置
在节点 B 的配置中，router_id 被设置为 nodeB。节点 B 同样配置了两个 VRRP实例 (VI_1 和 VI_2)，也对应虚拟路由器 ID (51 和 52)。

三、 重点总结

唯一标识：每个节点的 router_id 都是唯一的，用于标识每个 Keepalived 实例。在上面的示例中，节点 A 和节点 B 有不同的 router_id（nodeA 和 nodeB），这表示它们是不同的机器。

不同虚拟路由器 ID：两个节点上的 VRRP 实例可以使用相同的虚拟路由器 ID，意味着它们可以作为相同虚拟路由器组的一部分。这样，节点 A 和节点 B 可以通过 VRRP 协议共同管理相同的虚拟 IP地址，但由于它们是不同的机器，所以它们的 router_id 必须唯一。

主备模式：在 VRRP 配置中，通常一个节点是主节点 (MASTER)，而其他节点是备份节点 (BACKUP)。在上面的示例中，节点 A 和节点 B 的主备角色会根据配置文件中的 state 设置不同。例如，节点 A可以是主节点，而节点 B 可以是备份节点，或者反之。

因此，节点 A 和节点 B 是不同的机器，这使得它们能够在同一 VRRP 实例中协作，但它们的配置和 router_id确保它们可以被唯一识别和区分。

1. 虚拟路由器配置：

定义 VRRP 实例，配置虚拟路由器的详细信息，包括状态（主节点或备份节点）、接口、虚拟路由器ID、优先级和认证。
在 Keepalived 的配置中，vrrp_instance 是用来定义一个 VRRP (Virtual Router Redundancy Protocol) 实例的。这个配置块是实现高可用性的关键部分，它定义了故障转移和虚拟 IP 管理的行为。在 vrrp_instance 配置中，有几个参数是必须的，以确保 VRRP 实例能够正确运行：

state: 指定当前节点是主节点 (MASTER) 还是备份节点 (BACKUP)。主节点会处理虚拟 IP 地址的流量，而备份节点则处于待命状态，仅在主节点故障时接管。

interface: 指定 VRRP 实例绑定的网络接口。这是 VRRP 通告和虚拟 IP 流量将使用的接口。

virtual_router_id: 定义虚拟路由器的标识符。这个 ID 必须在所有参与同一虚拟路由器的节点上保持一致，以便它们能够相互识别并协同工作。

priority: 节点的优先级，用于在主节点选举中决定哪个节点将成为主节点。优先级数值越高，节点成为主节点的可能性越大。

authentication: 定义认证方法和密码，以确保只有配置正确的节点才能参与 VRRP 实例。这通常包括 auth_type（认证类型，通常是 PASS）和 auth_pass（共享密码）。

virtual_ipaddress: 定义一个或多个虚拟 IP 地址（VIPs），这些 IP 地址将在主节点和备份节点之间进行故障转移。当主节点出现故障时，备份节点将接管这些 IP 地址。

这些参数是构成 VRRP 实例的基础，缺少任何一个都可能导致 VRRP 实例无法正常工作。除了这些必须的参数外，还可以根据需要配置其他参数，例如 advert_int（设置 VRRP 通告间隔）、track_script（定义健康检查脚本）等，以增强 VRRP 实例的功能和灵活性。

注：在Keepalived配置中，virtual_router_id和router_id的区别：

假设你有一个高可用性集群，包含三台服务器：Router1、Router2 和Router3。这些服务器要共同提供一个虚拟路由器的功能，实现负载均衡和高可用性。

示例：

1. virtual_router_id

定义: 用于标识 VRRP 实例组。
配置示例: 在 Keepalived 配置文件中，所有三个路由器（Router1、Router2 和 Router3）配置相同的 virtual_router_id，例如 51。这样，它们都属于同一个 VRRP 实例组。

vrrp_instance VI_1 {
    virtual_router_id 51
    ...
}

作用: 所有参与这个实例组的路由器必须有相同的 virtual_router_id，以便它们可以协同工作，提供高可用的虚拟 IP 地址。

2. router_id

定义: 用于唯一标识每个参与 VRRP 实例组的路由器。
配置示例: 在每台路由器的配置中，指定不同的 router_id。例如，Router1 配置为 1.1.1.1，Router2 配置为 1.1.1.2，Router3 配置为 1.1.1.3。

global_defs {
	router_id 1.1.1.1
}
vrrp_instance VI_1 {
    virtual_router_id 51
    ...
    track_interface {
        ...
    }
	...
}

global_defs {
	router_id 1.1.1.2
}
vrrp_instance VI_1 {
    virtual_router_id 51
    ...
    track_interface {
        ...
    }
    ...
}

global_defs {
	router_id 1.1.1.3
}
vrrp_instance VI_1 {
    virtual_router_id 51
    ...
    track_interface {
        ...
    }
	...
	
}

作用: router_id 在 VRRP 协议中帮助区分具体的路由器，每个路由器都有唯一的 router_id，以便在出现故障时能够准确识别和切换角色。

注：在Keepalived配置中，主节点和备份节点的vrrp_instance的名字以及vrrp_instance中的virtual_router_id需要相同吗？不同会有什么影响？

在 Keepalived 配置中，主节点和备份节点的 vrrp_instance 名称以及 vrrp_instance 中的virtual_router_id 必须相同。这是因为 virtual_router_id 用于识别属于同一个虚拟路由器组的节点，而
vrrp_instance 的名称是用来区分不同的 VRRP 实例。

一、为什么需要相同

相同的 virtual_router_id:

确保所有配置为同一个虚拟路由器的节点能够相互通信和协调状态。这是 VRRP 协议工作的基础，使得这些节点能够共同管理同一个虚拟 IP 地址（VIP）。
当一个节点检测到它成为最高优先级的节点时，它将接管 VIP。所有其他节点（具有相同 virtual_router_id 的节点）都会同意这一变更，因为它们能够通过 VRRP 通告来感知到状态变化。

相同的 vrrp_instance 名称:

确保配置文件的一致性和清晰性。虽然 Keepalived 允许在同一个配置文件中定义多个 vrrp_instance，但通常每个 VRRP 实例的名称应该反映它的作用或标识，以便于管理和理解。
在实际操作中，通常每个 VIP 组只配置一个 vrrp_instance，因此所有管理该 VIP 的节点都应使用相同的 vrrp_instance 名称。

二、如果不同会有什么影响？

不同的 virtual_router_id:

如果主节点和备份节点配置了不同的 virtual_router_id，它们将无法正确地进行故障转移。每个节点都会认为自己是独立的虚拟路由器，不会与其他节点共享状态信息或VIP。
这将导致 VIP 管理混乱，可能多个节点同时尝试使用不同的 VIP，或者 VIP 在故障时没有被正确地转移。

不同的 vrrp_instance 名称:

如果名称不同，但 virtual_router_id 相同，通常不会影响功能，但可能会导致配置管理上的混淆，特别是在有多个 VRRP 实例需要管理时。
保持一致的命名有助于维护和故障排查，减少因配置不一致导致的错误。

总之，为了确保 Keepalived 的 VRRP 实例能够正确地进行故障转移和 VIP 管理，所有参与同一虚拟路由器的节点应配置相同的vrrp_instance 名称和 virtual_router_id。这样做可以保证节点间的有效通信和状态同步，从而实现高可用性。

vrrp_instance <instance_name> {
    state <MASTER|BACKUP>
    interface <interface_name>
    virtual_router_id <id>
    priority <priority>
    advert_int <interval>
    authentication {
        auth_type <PASS|AH>
        auth_pass <password>
    }
    virtual_ipaddress {
        <ip_address>
    }
    track_interface {
        <interface_name>
    }
}

state: 实例的初始状态（MASTER 或 BACKUP）。MASTER状态的路由器会处理数据包转发，而BACKUP状态的路由器则作为备用，仅在MASTER路由器失效时接管工作。
interface: 绑定的网络接口。
virtual_router_id: 虚拟路由器的 ID。
priority: 路由器的优先级。优先级高的更有可能成为MASTER占有VIP
advert_int: 广播间隔时间（秒）。设置了VRRP通告间隔（interval），即路由器之间发送VRRP通告消息的时间间隔。
authentication: 配置认证类型和密码。
virtual_ipaddress: 配置虚拟 IP 地址。当主节点运行时，虚拟IP会被分配给主节点
track_interface: 监控的接口。

注：authentication块的解释：

在Keepalived配置中，authentication块用于定义虚拟路由器冗余协议（VRRP）实例的认证方式。对于主路由器（MASTER）和备份路由器（BACKUP），authentication块的配置应该是相同的，以确保它们能够正确地进行通信和状态同步。以下是authentication块的详细说明：

authentication {
    auth_type <PASS|AH>
    auth_pass <password>
}

auth_type: 指定认证类型。可以是PASS（使用密码认证）或AH（使用IPsec的认证头进行认证）。
auth_pass: 当auth_type设置为PASS时，需要提供一个密码。这个密码用于在VRRP通信中验证路由器的身份。

例如，如果主路由器和备份路由器都使用密码认证，并且密码是mysecret，则配置如下：

authentication {
    auth_type PASS
    auth_pass mysecret
}

确保在主路由器和备份路由器上使用相同的auth_type和auth_pass值，以便它们能够相互认证并协同工作。

配置文件通常存储在 /etc/keepalived/keepalived.conf。你可以根据需要进行调整来满足特定的网络需求。

示例：

! Configuration File for keepalived

global_defs {
   router_id LVS_DEVEL
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 101
    advert_int 1

    authentication {
        auth_type PASS
        auth_pass mysecret
    }

    virtual_ipaddress {
        192.168.1.100
    }
    track_interface{
    	eth0;
    }
    #如果 eth0 接口变为 DOWN 状态，Keepalived 将会根据配置的策略作出相应的处理，比如触发故障转移。track_interface 是 Keepalived 中一个重要的功能，用于确保网络接口的健康状态能够被持续监控，从而保障系统的高可用性。
    
    # Check if the backend server is up
	# （可选）定义健康检查脚本，用于检查后端服务器的健康状态
	track_script {
	    script "/usr/local/bin/check_backend.sh"
	    interval 2
	}
    
}

# Optional: Define a real server configuration for LVS (if used)
# （可选）配置 LVS（Linux Virtual Server），定义虚拟服务器、负载均衡算法、实际服务器及其健康检查。
virtual_server 192.168.1.100 80 {
    delay_loop 6
    lb_algo wrr
    lb_kind DR
    protocol TCP

    real_server 192.168.1.101 80 {
        weight 1
        TCP_CHECK {
            connect_timeout 10
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}

测试

1）配置两台负载均衡服务器lb01和lb02
lb01作为主节点：
在这里插入图片描述

lb02作为从节点：
在这里插入图片描述

2）测试结果：

配置失败结果：
注意：一定要按上面的有空格的格式来配置，不然会有以下报错：

Sep 14 17:04:35 lb01 Keepalived_healthcheckers[7187]: Opening file '/etc/keepalived/keepalived.conf'.
Sep 14 17:04:35 lb01 Keepalived_healthcheckers[7187]: Unknown keyword 'global_defs{'
Sep 14 17:04:35 lb01 Keepalived_healthcheckers[7187]: Unknown keyword 'router_id'
Sep 14 17:04:35 lb01 Keepalived_healthcheckers[7187]: Unknown keyword '}'
Sep 14 17:04:35 lb01 Keepalived_healthcheckers[7187]: Unknown keyword 'state'
Sep 14 17:04:35 lb01 Keepalived_healthcheckers[7187]: Unknown keyword 'virtual_router_id'
Sep 14 17:04:35 lb01 Keepalived_healthcheckers[7187]: Unknown keyword 'priority'
Sep 14 17:04:35 lb01 Keepalived_healthcheckers[7187]: Unknown keyword 'authentication'
Sep 14 17:04:35 lb01 Keepalived_healthcheckers[7187]: Unknown keyword 'auth_type'
Sep 14 17:04:35 lb01 Keepalived_healthcheckers[7187]: Unknown keyword 'auth_pass'
Sep 14 17:04:35 lb01 Keepalived_healthcheckers[7187]: Unknown keyword '}'
Sep 14 17:04:35 lb01 Keepalived_healthcheckers[7187]: Unknown keyword 'interface'
Sep 14 17:04:35 lb01 Keepalived_healthcheckers[7187]: Unknown keyword 'virtual_ipaddress{'
Sep 14 17:04:35 lb01 Keepalived_healthcheckers[7187]: Unknown keyword '10.0.0.43'
Sep 14 17:04:35 lb01 Keepalived_healthcheckers[7187]: Unknown keyword '}'
Sep 14 17:04:35 lb01 Keepalived_healthcheckers[7187]: Unknown keyword 'advert_int'
Sep 14 17:04:35 lb01 Keepalived_healthcheckers[7187]: Unknown keyword 'track_interface'
Sep 14 17:04:35 lb01 Keepalived_healthcheckers[7187]: Unknown keyword 'eth0'
Sep 14 17:04:35 lb01 Keepalived_healthcheckers[7187]: Unknown keyword '}'
Sep 14 17:04:35 lb01 Keepalived_healthcheckers[7187]: Unknown keyword '}

配置成功结果：

主节点日志信息：

Sep 14 17:32:34 lb01 systemd: Starting LVS and VRRP High Availability Monitor...
Sep 14 17:32:34 lb01 Keepalived[7309]: Starting Keepalived v1.3.5 (03/19,2017), git commit v1.3.5-6-g6fa32f2
Sep 14 17:32:34 lb01 Keepalived[7309]: Opening file '/etc/keepalived/keepalived.conf'.
Sep 14 17:32:34 lb01 systemd: PID file /var/run/keepalived.pid not readable (yet?) after start.
Sep 14 17:32:34 lb01 Keepalived[7310]: Starting Healthcheck child process, pid=7311
Sep 14 17:32:34 lb01 Keepalived[7310]: Starting VRRP child process, pid=7312
Sep 14 17:32:34 lb01 systemd: Started LVS and VRRP High Availability Monitor.
Sep 14 17:32:34 lb01 Keepalived_healthcheckers[7311]: Opening file '/etc/keepalived/keepalived.conf'.
Sep 14 17:32:34 lb01 Keepalived_vrrp[7312]: Registering Kernel netlink reflector
Sep 14 17:32:34 lb01 Keepalived_vrrp[7312]: Registering Kernel netlink command channel
Sep 14 17:32:34 lb01 Keepalived_vrrp[7312]: Registering gratuitous ARP shared channel
Sep 14 17:32:34 lb01 Keepalived_vrrp[7312]: Opening file '/etc/keepalived/keepalived.conf'.
Sep 14 17:32:34 lb01 Keepalived_vrrp[7312]: VRRP_Instance(vi_lb) removing protocol VIPs.
Sep 14 17:32:34 lb01 Keepalived_vrrp[7312]: Using LinkWatch kernel netlink reflector...
Sep 14 17:32:34 lb01 Keepalived_vrrp[7312]: VRRP sockpool: [ifindex(2), proto(112), unicast(0), fd(10,11)]
Sep 14 17:32:35 lb01 Keepalived_vrrp[7312]: VRRP_Instance(vi_lb) Transition to MASTER STATE


Sep 14 17:32:37 lb01 Keepalived_vrrp[7312]: VRRP_Instance(vi_lb) Entering MASTER STATE


Sep 14 17:32:37 lb01 Keepalived_vrrp[7312]: VRRP_Instance(vi_lb) setting protocol VIPs.
Sep 14 17:32:37 lb01 Keepalived_vrrp[7312]: Sending gratuitous ARP on eth0 for 10.0.0.43
Sep 14 17:32:37 lb01 Keepalived_vrrp[7312]: VRRP_Instance(vi_lb) Sending/queueing gratuitous ARPs on eth0 for 10.0.0.43
Sep 14 17:32:37 lb01 Keepalived_vrrp[7312]: Sending gratuitous ARP on eth0 for 10.0.0.43
Sep 14 17:32:37 lb01 Keepalived_vrrp[7312]: Sending gratuitous ARP on eth0 for 10.0.0.43
Sep 14 17:32:37 lb01 Keepalived_vrrp[7312]: Sending gratuitous ARP on eth0 for 10.0.0.43
Sep 14 17:32:37 lb01 Keepalived_vrrp[7312]: Sending gratuitous ARP on eth0 for 10.0.0.43
Sep 14 17:32:42 lb01 Keepalived_vrrp[7312]: Sending gratuitous ARP on eth0 for 10.0.0.43
Sep 14 17:32:42 lb01 Keepalived_vrrp[7312]: VRRP_Instance(vi_lb) Sending/queueing gratuitous ARPs on eth0 for 10.0.0.43
Sep 14 17:32:42 lb01 Keepalived_vrrp[7312]: Sending gratuitous ARP on eth0 for 10.0.0.43
Sep 14 17:32:42 lb01 Keepalived_vrrp[7312]: Sending gratuitous ARP on eth0 for 10.0.0.43
Sep 14 17:32:42 lb01 Keepalived_vrrp[7312]: Sending gratuitous ARP on eth0 for 10.0.0.43
Sep 14 17:32:42 lb01 Keepalived_vrrp[7312]: Sending gratuitous ARP on eth0 for 10.0.0.43

从节点日志信息：

Sep 14 17:32:23 lb02 systemd: Starting LVS and VRRP High Availability Monitor...
Sep 14 17:32:23 lb02 Keepalived[7655]: Starting Keepalived v1.3.5 (03/19,2017), git commit v1.3.5-6-g6fa32f2
Sep 14 17:32:23 lb02 Keepalived[7655]: Opening file '/etc/keepalived/keepalived.conf'.
Sep 14 17:32:23 lb02 systemd: PID file /var/run/keepalived.pid not readable (yet?) after start.
Sep 14 17:32:23 lb02 Keepalived[7656]: Starting Healthcheck child process, pid=7657
Sep 14 17:32:23 lb02 Keepalived[7656]: Starting VRRP child process, pid=7658
Sep 14 17:32:23 lb02 systemd: Started LVS and VRRP High Availability Monitor.
Sep 14 17:32:23 lb02 Keepalived_healthcheckers[7657]: Opening file '/etc/keepalived/keepalived.conf'.
Sep 14 17:32:23 lb02 Keepalived_vrrp[7658]: Registering Kernel netlink reflector
Sep 14 17:32:23 lb02 Keepalived_vrrp[7658]: Registering Kernel netlink command channel
Sep 14 17:32:23 lb02 Keepalived_vrrp[7658]: Registering gratuitous ARP shared channel
Sep 14 17:32:23 lb02 Keepalived_vrrp[7658]: Opening file '/etc/keepalived/keepalived.conf'.
Sep 14 17:32:23 lb02 Keepalived_vrrp[7658]: VRRP_Instance(vi_lb) removing protocol VIPs.
Sep 14 17:32:23 lb02 Keepalived_vrrp[7658]: Using LinkWatch kernel netlink reflector...
Sep 14 17:32:23 lb02 Keepalived_vrrp[7658]: VRRP_Instance(vi_lb) Entering BACKUP STATE
Sep 14 17:32:23 lb02 Keepalived_vrrp[7658]: VRRP sockpool: [ifindex(2), proto(112), unicast(0), fd(10,11)]
Sep 14 17:32:29 lb02 Keepalived_vrrp[7658]: VRRP_Instance(vi_lb) Transition to MASTER STATE


Sep 14 17:32:31 lb02 Keepalived_vrrp[7658]: VRRP_Instance(vi_lb) Entering MASTER STATE


Sep 14 17:32:31 lb02 Keepalived_vrrp[7658]: VRRP_Instance(vi_lb) setting protocol VIPs.
Sep 14 17:32:31 lb02 Keepalived_vrrp[7658]: Sending gratuitous ARP on eth0 for 10.0.0.43
Sep 14 17:32:31 lb02 Keepalived_vrrp[7658]: VRRP_Instance(vi_lb) Sending/queueing gratuitous ARPs on eth0 for 10.0.0.43
Sep 14 17:32:31 lb02 Keepalived_vrrp[7658]: Sending gratuitous ARP on eth0 for 10.0.0.43
Sep 14 17:32:31 lb02 Keepalived_vrrp[7658]: Sending gratuitous ARP on eth0 for 10.0.0.43
Sep 14 17:32:31 lb02 Keepalived_vrrp[7658]: Sending gratuitous ARP on eth0 for 10.0.0.43
Sep 14 17:32:31 lb02 Keepalived_vrrp[7658]: Sending gratuitous ARP on eth0 for 10.0.0.43



Sep 14 17:32:35 lb02 Keepalived_vrrp[7658]: VRRP_Instance(vi_lb) Received advert with higher priority 100, ours 99
Sep 14 17:32:35 lb02 Keepalived_vrrp[7658]: VRRP_Instance(vi_lb) Entering BACKUP STATE
Sep 14 17:32:35 lb02 Keepalived_vrrp[7658]: VRRP_Instance(vi_lb) removing protocol VIPs.

3、“抢占式“配置

 vim /etc/keepalived/keepalived.conf

默认是启用了抢占式的

4、“非抢占式”配置

定义：在非抢占式模式下，即使主路由器恢复正常，它也不会重新成为主路由器。当前主路由器将继续保持主路由器状态，直到其失败或其他情况发生。
配置：
- 使用 no_preempt 指令启用非抢占式功能。

1）配置主节点

# 已知lb01，eth0网卡已有IP为10.0.0.5
global_defs {
	router_id lb01
}

vrrp_instance vi_lb {
	state BACKUP
	virtual_router_id 43
	priority 100
	interface eth0
	authentication {
		auth_type PASS
		auth_pass 1234
	}
	virtual_ipaddress {
		10.0.0.43/32
	}
	track_interface {
		eth0
	}
	advert_int 2
	# 配置非抢占参数
	nopreempt
}

2）配置从节点
从节点可以不配置nopreempt参数

# 已知lb02的eth0网卡已有IP为：10.0.0.6
global_defs {
	router_id lb02
}

vrrp_instance vi_lb {
	state BACKUP
	virtual_router_id 43
	interface eth0
	priority 99
	authentication {
		auth_type PASS
		auth_pass 1234
	}
	virtual_ipaddress {
		10.0.0.43/32
	}
	track_interface {
		eth0
	}
	advert_int 2
}

生产中Keepalived需要配置非抢占式的情况

在 Keepalived 的 VRRP 配置中，非抢占式配置（non-preemptive mode）意味着即使优先级较高的路由器上线，已经处于主状态的路由器不会被强制替换。这种配置对于某些生产环境中的场景非常有用。

一、什么时候使用非抢占式配置

稳定性优先: 当你希望当前的主路由器（Master）保持稳定，不被优先级较高的备份路由器打扰。这对于需要保证服务连续性的应用场景很重要。

避免频繁切换: 如果你的网络环境中，某些路由器可能会频繁重启或因维护而上线下线，使用非抢占式配置可以避免由于路由器上线而导致的频繁状态切换。

二、生产中的具体例子

数据库集群:
场景: 在一个数据库集群中，主节点处理所有写操作，备份节点用于读取或备份。为了避免在数据库维护时频繁切换主节点，可以使用非抢占式配置来确保现有的主节点在维护期间不被新的备份节点替代。
配置示例: 配置 Keepalived 的 VRRP 实例时，将 nopreempt 设置为非抢占模式：

vrrp_instance VI_1 {
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass mysecret
    }
    virtual_ipaddress {
        192.168.1.100
    }
    nopreempt
}

负载均衡系统:
场景: 在负载均衡系统中，已经在线的负载均衡器节点处理流量，避免因其他节点上线而导致的切换。这样可以防止流量在负载均衡器间频繁移动，确保业务的稳定性。
配置示例: 同样，在 Keepalived 配置中启用非抢占式配置以确保流量不会因节点上线而被重新分配。

使用非抢占式配置可以帮助你维护系统的稳定性，减少由于节点上线导致的不必要的主备切换，从而保证服务的持续可用性。

5、Keepalived自动引用执行外部脚本——脚本健康检查机制

这里的例子，是脚本编写检测Nginx进程的存活状态，来决定主/从机的Keepalived进程的启停

1、写脚本

#!/bin/bash
# 筛选出Nginx进程数，如果进程数为0，那么重启Nginx，等待3秒，再去检查，如果恢复正常，则终止，如果仍为0，那么就停止keepalived服务进程，这样从节点就会分配到了VIP
ngx_state=`ps -ef | grep -c [n]gix`
if [ $ngx_state -eq 0 ];then
	systemctl restart nginx
	sleep 3
	if[ $ngx_state -eq 0 ];then
		systemctl stop keepalived
	fi
fi

一定要确保脚本文件有执行权限，才能便于Keepalived自动执行它
在这里插入图片描述

2、Keepalived配置文件配置自动调用上述检测脚本

# （可选）定义健康检查脚本，用于检查后端服务器的健康状态
track_script {
    script "脚本路径"
    # 定义了 Keepalived 执行指定健康检查脚本的时间间隔。interval：间隔
    interval 2
}

测试

注意vrrp_script块一定要在vrrp_instance上面，这样才能先识别到

! Configuration File for keepalived

global_defs {
        router_id lb01
}
vrrp_script chk_ngx {
        script "/etc/keepalived/check_ngx.sh"
        interval 2
}

vrrp_instance vi_lb {
        #state MASTER
        #state BACKUP
        state MASTER
        virtual_router_id 43

        priority 100

        authentication {
                auth_type PASS
                auth_pass 4439
        }

        interface eth0

        virtual_ipaddress {
                10.0.0.43/32
        }

        advert_int 2

        track_interface {
                eth0
        }

        #nopreempt

#       vrrp_script chk_ngx {
#               script "/etc/keepalived/check_ngx.sh"
#               interval 2
#       }
        track_script {
                chk_ngx
        }
}

#vrrp_script chk_ngx {
#       script "/etc/keepalived/check_ngx.sh"
#       interval 2
#}

脚本已执行效果：
在这里插入图片描述

三、实验

需求

1、在LNMP架构下；
2、现有两台CentOS7的Web服务器；部署同一个Web应用——WeCenter；
3、使用两台CentOS7的负载均衡服务器，使用Nginx实现七层负载均衡；将用户请求分发到上面两个Web服务器中；同时也配置Keepalived实现负载均衡服务器的高可用；
5、如何配置确保两个Web服务器的WeCenter不冲突；
6、使用两台数据库服务器，也需要使用Keepalived，配置高可用性；使用sersync，配置数据同步
*7、使用两台NFS服务器，也需要使用Keepalived，配置高可用性；使用sersync，配置数据同步；
*8、每天备份WeCenter应用网站的用户数据到一台备份服务器中；使用两台备份服务器，也需要使用Keepalived实现高可用性；使用sersync，配置数据同步

实现

在LNMP架构下实现高可用性和负载均衡，涉及多个组件的配置。下面是详细的步骤，包括负载均衡、数据库高可用、NFS高可用、备份服务器高可用等方面的配置。

环境准备

Web服务器: web1 和 web2
负载均衡服务器: lb1 和 lb2
数据库服务器: db1 和 db2
NFS服务器: nfs1 和 nfs2
备份服务器: backup1 和 backup2
备份服务器: backup1 和 backup2

1. Web服务器配置（`web1` 和 `web2`）

安装LNMP（Linux, Nginx, MySQL/MariaDB, PHP）：

sudo yum install epel-release
sudo yum install nginx mysql-server php php-fpm php-mysql -y

部署WeCenter：

下载并解压WeCenter：

wget http://www.wecenter.com/downloads/wecenter-vx.x.x.tar.gz
tar -xzvf wecenter-vx.x.x.tar.gz
mv wecenter /var/www/html/

配置Nginx：

sudo vi /etc/nginx/conf.d/wecenter.conf

内容如下：

server {
    listen 80;
    server_name yourdomain.com;

    root /var/www/html/wecenter;
    index index.php index.html index.htm;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

启动服务并设置开机启动：

sudo systemctl start nginx
sudo systemctl enable nginx
sudo systemctl start php-fpm
sudo systemctl enable php-fpm

配置数据库连接：
- 确保web1和web2都连接到数据库服务器上的同一个数据库实例，配置一致的数据库连接参数。

2. 负载均衡配置（`lb1` 和 `lb2`）

安装Nginx：
```
sudo yum install nginx -y
```

配置Nginx作为负载均衡器：

sudo vi /etc/nginx/nginx.conf

内容如下：

http {
    upstream backend {
        server web1;
        server web2;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://backend;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }
}

安装Keepalived：
```
sudo yum install keepalived -y
```

配置Keepalived：

在lb1上（设置为MASTER）：

sudo vi /etc/keepalived/keepalived.conf

内容如下：

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 101
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass mypassword
    }
    virtual_ipaddress {
        192.168.1.100
    }
}

在lb2上（设置为BACKUP）：

sudo vi /etc/keepalived/keepalived.conf

内容如下：

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass mypassword
    }
    virtual_ipaddress {
        192.168.1.100
    }
}

启动Keepalived：

sudo systemctl start keepalived
sudo systemctl enable keepalived

3. 数据库高可用配置（`db1` 和 `db2`）

安装MySQL/MariaDB：

sudo yum install mariadb-server mariadb -y

配置主从复制：

在db1（主数据库）上：

sudo vi /etc/my.cnf

内容如下：

[mysqld]
server-id=1
log_bin=mysql-bin
binlog_do_db=wecenter

然后重启MySQL并创建复制用户：

sudo systemctl restart mariadb
mysql -u root -p
CREATE USER 'replica'@'%' IDENTIFIED BY 'replica_pass';
GRANT REPLICATION SLAVE ON *.* TO 'replica'@'%';
FLUSH PRIVILEGES;
SHOW MASTER STATUS;

在db2（从数据库）上：

sudo vi /etc/my.cnf

内容如下：

[mysqld]
server-id=2
relay_log=relay-bin
log_bin=mysql-bin
read_only=1

然后重启MySQL并配置从数据库：

sudo systemctl restart mariadb
mysql -u root -p
CHANGE MASTER TO MASTER_HOST='db1', MASTER_USER='replica', MASTER_PASSWORD='replica_pass', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154;
START SLAVE;
SHOW SLAVE STATUS\G;

配置Keepalived：

在db1上（设置为MASTER）：

sudo vi /etc/keepalived/keepalived.conf

内容如下：

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 52
    priority 101
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass mypassword
    }
    virtual_ipaddress {
        192.168.1.101
    }
}

在db2上（设置为BACKUP）：

sudo vi /etc/keepalived/keepalived.conf

内容如下：

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 52
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass mypassword
    }
    virtual_ipaddress {
        192.168.1.101
    }
}

启动Keepalived：

sudo systemctl start keepalived
sudo systemctl enable keepalived

4. NFS高可用配置（`nfs1` 和 `nfs2`）

安装NFS服务器：
```
sudo yum install nfs-utils -y
```

配置NFS共享：

在nfs1和nfs2上，编辑/etc/exports：

/mnt/nfs_share  *(rw,sync,no_root_squash)

启动NFS服务：

sudo systemctl start nfs-server
sudo systemctl enable nfs-server

配置Keepalived：

在nfs1上（设置为MASTER）：

sudo vi /etc/keepalived/keepalived.conf

内容如下：

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 53
    priority 101
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass mypassword
    }
    virtual_ipaddress {
        192.168.1.102
    }
}

在nfs2上（设置为BACKUP）：

sudo vi /etc/keepalived/keepalived.conf

内容如下：

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 53
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass mypassword
    }
    virtual_ipaddress {
        192.168.1.102
    }
}

启动Keepalived：

sudo systemctl start keepalived
sudo systemctl enable keepalived

5. 备份服务器高可用配置（`backup1` 和 `backup2`）

安装备份工具（例如rsync）：
```
sudo yum install rsync -y
```

配置rsync备份任务：

在backup1上创建备份脚本：

sudo vi /usr/local/bin/backup.sh

内容如下：

#!/bin/bash
rsync -avz /var/www/html/wecenter/ backup_user@backup2:/mnt/backup/

设置脚本权限：
```
sudo chmod +x /usr/local/bin/backup.sh
```

配置定时任务：

sudo crontab -e

添加以下内容：

0 2 * * * /usr/local/bin/backup.sh

配置Keepalived：

在backup1上（设置为MASTER）：

sudo vi /etc/keepalived/keepalived.conf

内容如下：

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 54
    priority 101
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass mypassword
    }
    virtual_ipaddress {
        192.168.1.103
    }
}

在backup2上（设置为BACKUP）：

sudo vi /etc/keepalived/keepalived.conf

内容如下：

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 54
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass mypassword
    }
    virtual_ipaddress {
        192.168.1.103
    }
}

启动Keepalived：

sudo systemctl start keepalived
sudo systemctl enable keepalived

总结

Web服务器通过Nginx负载均衡。
数据库服务器配置主从复制和Keepalived实现高可用性。
NFS服务器配置共享和Keepalived。
备份服务器配置rsync和Keepalived。

这样配置后，系统应该具备了基本的高可用性和负载均衡。请根据实际情况进行适当调整和测试。

Shenqi Lotus

关注

12
点赞
踩
8

收藏

觉得还不错? 一键收藏
0
评论
复制链接

分享到 QQ

分享到新浪微博

扫一扫

专栏目录

实现高可用的故障转移策略的工具——Keepalived

文章目录

一、高可用与keepalived介绍

1、什么是高可用

2、实现高可用的技术

1). 负载均衡器

2). 故障转移工具

3). 数据库高可用性

4). 存储高可用性

5). 监控与报警工具

6). 云服务高可用性

3、Keepalived介绍

0-1）Keepalived是什么、功能介绍：

Keepalived的功能

*注：Nginx和LVS在负载均衡上使用的区别：

实际应用场景

*注：具体如何使用Keepalived和LVS进行负载均衡，具体配置是什么样的？

0-2）Keepalived底层实现原理：

1）VRRP：

2）Keepalived的相关概念

选举投票机制

抢占式、非抢占式机制

脑裂状态

3）keepalived的工作流程概述

二、配置Keepalived

0、*Keepalived健康检查机制：

VIPS 健康检查

脚本健康检查

网络接口健康检查

1、安装keepalived

2、配置语法

配置文件格式：

具体配置内容组成：

测试

3、“抢占式“配置

4、“非抢占式”配置

生产中Keepalived需要配置非抢占式的情况

5、Keepalived自动引用执行外部脚本——脚本健康检查机制

1、写脚本

2、Keepalived配置文件配置自动调用上述检测脚本

测试

三、实验

需求

实现

环境准备

1. Web服务器配置（web1 和 web2）

2. 负载均衡配置（lb1 和 lb2）

3. 数据库高可用配置（db1 和 db2）

4. NFS高可用配置（nfs1 和 nfs2）

5. 备份服务器高可用配置（backup1 和 backup2）

总结

1. Web服务器配置（`web1` 和 `web2`）

2. 负载均衡配置（`lb1` 和 `lb2`）

3. 数据库高可用配置（`db1` 和 `db2`）

4. NFS高可用配置（`nfs1` 和 `nfs2`）

5. 备份服务器高可用配置（`backup1` 和 `backup2`）