亚马逊云科技VPC多可用区keepalived配置指南

前言

在上一篇博客中（亚马逊云科技VPC中的keepalived配置指南），我们介绍了在AWS VPC中配置keepalived需要考虑的问题，并提供了使用辅助IP作为keepalived VIP的配置方案。由于辅助IP仅允许绑定到同一子网的网络接口，因此这个方案要求keepalived集群成员的网络接口位于同一个子网，即这些节点必须创建在同一个可用区。

为了满足更高的可用性，有些客户希望能在多可用区创建keepalived集群。本文介绍在AWS VPC网络中创建多可用区keepalived集群所需要考虑的问题及配置方案。

您可以参考上一篇博客中我们介绍的keepalived的基本工作方式和AWS VPC的网络设计考虑，这些内容在本文中不再重复介绍。

AWS VPC的多可用区keepalived方案设计

在上一篇博客中我们描述了AWS VPC网络所遵循的行为。VPC网络按照路由表中的路由条目转发报文，路由查找规则使用最长前缀匹配 (LPM: Longest Prefix Match) 。路由表缺省预置本地网络路由，前缀为VPC CIDR，下一跳为local。本地网络路由不可修改。

在上一篇博客中，我们使用了辅助IP作为keepalived的VIP，就是利用了VPC本地网络路由。由于VPC中的子网创建后不能更改所在的可用区，这意味着任何一个内网IP地址都无法动态更改所在的可用区，所以仅利用本地路由机制无法实现在VPC内实现跨可用区的VIP漂移。如果想在VPC内实现跨可用区的VIP漂移，必须要使用本地路由以外的路由，即通过在路由表中添加新的路由条目来实现。

AWS VPC路由表简介

AWS VPC中的每个子网有且只有一个关联的路由表。子网中的节点发送的报文遵循路由表中的路由规则。

子网路由表预置目标为VPC CIDR的本地路由，并且不可修改（例如CIDR为10.100.0.0/16的VPC内的所有路由表都预置前缀为10.100.0.0/16，下一跳为local的路由）。VPC中通常包含多个路由表，每个路由表都可以和多个子网关联。通过配置路由表路由条目以及路由表与子网的关联关系，可以满足业务多样的网络拓扑需求。

子网路由表中可以添加多个路由条目，每一个路由条目由目标前缀（Prefix）和下一跳组成。目标前缀是网络数据去向的IP地址范围，使用<IP network address>/<prefix len>的格式，例如10.100.1.0/24。当所添加的路由条目中的目标前缀与VPC CIDR重叠时，仅允许添加与VPC中子网CIDR相同的目标前缀，这是AWS VPC网络的一个限制条件。与VPC CIDR无关的目标前缀没有限制。

子网路由表中路由条目的下一跳可以有多种类型，常见的有互联网网关 （IGW）、NAT网关、ENI等。在本文描述的方案中，将使用ENI作为路由条目的下一跳。路由条目中的下一跳可以通过API或者控制台修改，修改后立即生效。

作为一种安全机制，在缺省情况下，AWS VPC会限制EC2实例仅能使用已分配的子网IP地址进行报文收发，其余报文会被丢弃。已分配的IP地址包括ENI的主IP地址、辅助IP地址及ENI代理的IP地址前缀。EC2实例在某些场景下需要使用任意的IP地址来收发报文，例如EC2本身作为一个路由器、防火墙等网络中间节点来转发来自其它位置的流量。AWS EC2实例提供选项，允许用户对这些实例的特定ENI关闭报文的源/目的IP地址检查。

通过路由表更新支持keepalived VIP漂移的设计考虑

在上一篇博客中我们已经描述了keepalived的工作原理，本文不再重复。在keepalived集群进行故障切换时，VIP需要从原有的Master节点漂移到新选举的Master节点。这个过程包括两个主要的操作：

1. 新的Master节点内部绑定VIP；如果可能的话，原Master节点内部解绑VIP。这个操作由keepalived模块原生支持。
2. VPC路由表更新，将VIP路由到新的Master节点。

与上一篇博客不同，上述的第二个步骤没有采用绑定/解绑辅助IP的方案，而是使用更新路由表的操作以实现将VIP路由到不同可用区的实例。

我们推荐选择VPC CIDR以外的私有网络地址（RFC 1918）作为VIP [讨论2]。在本博客中我们选择了192.168.1.100这个IP地址作为示例。在实际的网络环境中，我们建议选择与网络中的其它节点不冲突的私有网络地址。推荐规划预留专门的网段，从该网段中分配VIP并管理VIP的使用记录。

由于VPC中可能存在多个路由表，在进行路由表更新时需要将所有访问VIP的子网路由表都进行更新。

使用弹性IP (Elastic IP, EIP) 实现面向公网访问的keepalived VIP

在上一篇博客中，在辅助IP解绑/绑定的同时，与辅助IP关联的EIP会一直保持关联，同步漂移到新的节点。通过这种方式，与辅助IP关联的EIP承担了面向互联网访问的VIP角色。

在本博客讨论的多可用区场景中，由于没有使用辅助IP，如果需要提供面向互联网的访问，我们需要在VIP漂移时增加EIP解绑/绑定的操作。

为了防止绑定/解绑EIP对实例原有公网IP的影响，我们可以为节点添加额外的ENI专门用于承载作为VIP的EIP。出于简化考虑，在本博客中EIP直接关联到实例的主网卡。

本博客中的VIP漂移触发机制沿用上一篇博客的做法，在keepalived中配置触发动作，当节点成为Master时调用AWS CLI，更新路由表，同时可选解绑/绑定EIP。

使用EC2基于路由表和EIP实现VIP漂移的配置流程

图1 基于路由表更新和EIP重新绑定实现keepalived

我们用一个最小环境来演示使用EC2实例在AWS VPC的多可用区中配置keepalived的具体操作。在这个例子里面，我们用两台处于不同可用区的EC2实例运行keepalived，分别作为主、备节点。我们在这两台实例上配置nginx提供一个简单的web页面，用于验证VIP是否成功漂移。在不同的可用区创建客户端来测试VIP的访问（本文仅描述了在一个可用区中创建客户端，其余可用区操作类似）。完整的配置包括以下几个部分：

• 创建2个EC2实例用于运行keepalived和nginx web服务器，这两个实例位于不同可用区的公有子网
• 为keepalived实例的instance profile添加IAM权限，用于操作路由表和EIP
• 创建一个EC2实例用于模拟客户端
• 创建安全组规则，用于keepalived实例之间互相通信和客户端访问keepalived实例web服务。将安全组绑定到各个实例
• 启动keepalived服务，并触发主备切换。分别从客户端访问VIP，验证VIP绑定到了正确的节点

⚠️ 本文中所有示例基于Amazon Linux 2023操作系统，其它发行版请根据实际情况调整相关命令。

一、环境准备

我们将启动两台t3.micro EC2实例，分别作为Master和Backup节点，实现通过VIP的主备切换。这两台EC2实例需要创建在公有子网中，以验证使用EIP作为面向公网访问的VIP切换方案。

⚠️ 请确认两台实例位于不同可用区的公有子网。

安装keepalived, AWS CLI和nginx

在两台 EC2 实例上分别执行以下命令：

sudo yum install -y keepalived aws-cli nginx

# 验证安装成功
keepalived -v
aws --version
nginx -v

我们另外启动一台t3.micro实例，用于模拟客户端。客户端使用的curl命令已经包含在Amazon Linux 2023系统镜像中，无需额外安装操作。

二、IAM权限配置

在本例中，我们使用EC2 instance profile来为keepalived实例配置修改路由条目的权限。您也可以使用其它方式来为keepalived实例提供必要的IAM权限，例如使用AK/SK。要使 EC2 实例具备修改路由条目的能力，需要为两台实例绑定一个包含以下权限的 IAM 角色：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:ReplaceRoute"
            ],
            "Resource": "*"
        }
    ]
}

该角色的信任关系需要包含EC2服务，才可以允许绑定到EC2实例上。我们为该角色添加如下信任关系：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "ec2.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

⚠️ 请在AWS控制台为Master和Backup实例分别绑定该IAM角色。

三、添加安全组规则

keepalived集群节点之间需要使用VRRP协议进行通信。VRRP协议是独立于TCP/UDP的IP协议，IP协议号为112。我们可以添加安全组入站规则以放行相应的keepalived协议。在VPC中，我们也可以通过使用default安全组实现节点之间的无限制通信，这也是我们在本文中所使用的方式。在VPC中的default安全组中包含一条入站规则，该规则允许来自本安全组的所有流量。这意味着绑定了default安全组的所有网络接口之间的通信不受限制，同时并未开放来自其它源地址或其它安全组的访问。default安全组的这个设计特别适用于集群节点间的相互通信。

⚠️ 我们为Master、Backup节点和客户端节点分别添加绑定default安全组，同时保留原有安全组。

四、创建 VIP 分配脚本

在replace route操作之前，需要路由表中预先创建相应的路由条目。在所有需要访问VIP的子网路由表里分别创建一条路由：目标为192.168.1.100/32，下一跳为Master或Backup节点的ENI ID。

在两台 EC2 实例上分别执行以下命令：

sudo mkdir -p /etc/keepalived/scripts

执行以下脚本生成修改路由条目的脚本文件，并根据你实际的VIP、ENI ID、Route table ID修改，循环更新所有要访问VIP的子网路由表中的路由条目：

cat << 'EOF' | sudo tee /etc/keepalived/scripts/rt_vip_master.sh
#!/bin/bash
# 路由表列表(空格分隔多个Route table ID)
RTB_LIST="rtb-001 rtb-002 rtb-003" # 替换为实际的路由表ID
VIP=192.168.1.100
# 替换为本机ENI ID
ENI=eni-<EC2 eni id>

# 循环更新所有路由表
for RTB in $RTB_LIST; do
    /usr/bin/aws ec2 replace-route \
        --route-table-id $RTB \
        --destination-cidr-block $VIP/32 \
        --network-interface-id $ENI
done
EOF

赋予脚本可执行权限：

sudo chmod +x /etc/keepalived/scripts/rt_vip_master.sh

⚠️ keepalived Master、Backup节点上都需要执行上述操作，并替换ENI ID为该节点的ENI ID

五、创建keepalived配置文件

Master节点配置

执行脚本内容如下：

cat << EOF | sudo tee /etc/keepalived/keepalived.conf
vrrp_instance VI_1 {
    state MASTER
    interface ens5   # 替换为实例的网络接口名
    virtual_router_id 51
    priority 100
    advert_int 1
    virtual_ipaddress {
        192.168.1.100
    }
    unicast_peer {
        10.0.2.100  # Backup节点的IP
    }
    notify_master /etc/keepalived/scripts/rt_vip_master.sh nobody
}
EOF

Backup 节点配置

执行脚本内容如下：

cat << EOF | sudo tee /etc/keepalived/keepalived.conf
vrrp_instance VI_1 {
    state BACKUP
    interface ens5   # 替换为实例的网络接口名
    virtual_router_id 51
    priority 90
    advert_int 1
    virtual_ipaddress {
        192.168.1.100
    }
    unicast_peer {
        10.0.1.100 # Master节点的IP
    }
    notify_master /etc/keepalived/scripts/rt_vip_master.sh nobody
}
EOF

分别在keepalived Master和Backup节点启动keepalived服务和nginx服务：

sudo systemctl enable keepalived --now
sudo systemctl enable nginx --now
systemctl status keepalived.service
systemctl status nginx.service

六、验证VIP漂移

1. 验证 VIP 当前绑定在 Master 节点

在 Master 节点上执行以下命令，确认 VIP 192.168.1.100 已绑定到网卡 ens5：

ip addr show ens5 | grep 192.168.1.100

输出如下，表示 VIP 当前处于 Master 节点：

inet 192.168.1.100/32 scope global ens5

2. 创建简单的web页面

在Master节点创建一个简单的页面：

cat << EOF | sudo tee /usr/share/nginx/html/index.html
Hello from node 1                                              
EOF

在Backup节点创建一个简单的页面：

cat << EOF | sudo tee /usr/share/nginx/html/index.html
Hello from node 2
EOF

3. 验证服务访问正常

在客户端节点，使用curl命令向两个keepalived节点分别发起HTTP请求：

curl 10.0.1.100 10.0.2.100

输出如下：

Hello from node 1
Hello from node 2

在客户端节点使用curl命令向VIP发起HTTP请求前，如上文所述我们需要关闭keepalived所有节点的源/目的IP地址检查：

curl 192.168.1.100

输出如下：

Hello from node 1

以上输出表明VIP目前绑定在节点1上，即Master节点。

4. 模拟主节点故障切换

我们可以有多种方式模拟Master节点的故障。keepalived提供多种配置选项用于监控系统的健康情况，比如使用track_script自定义健康检查脚本。本文中通过停止Master节点的 keepalived服务来模拟Master节点的故障。

在 Master 节点执行：

sudo systemctl stop keepalived

在客户端节点，使用curl命令再次向EIP的private IP发起HTTP请求：

curl 192.168.1.100

输出如下：

Hello from node 2

以上输出表明VIP已经成功漂移，目前绑定在节点2上，即Backup节点。

通过以上步骤，成功验证了keepalived在Master节点故障时，能够将VIP漂移到Backup节点，确保服务高可用。

七、公网访问VIP

以上实验都是在VPC内部的client实例上去访问VIP。如果需要从互联网访问VIP，则需要增加配置，使用EIP关联到Master节点的ENI上。

首先要给keepalived的两个实例附加的role增加associate address的权限，具体配置如下：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:AssociateAddress",
                "ec2:ReplaceRoute"
            ],
            "Resource": "*"
        }
    ]
}

另外，在某个节点成为主节点时需要把EIP关联到该节点的ENI上。在notify master的脚本rt_vip_master.sh里增加associate address操作：

cat << 'EOF' | sudo tee /etc/keepalived/scripts/rt_vip_master.sh
#!/bin/bash
# 路由表列表(空格分隔多个route table id)
RTB_LIST="rtb-001 rtb-002 rtb-003" # 替换为实际的路由表ID
VIP=192.168.1.100
# 替换为本机ENI id
ENI=eni-<EC2 eni id>
# (可选) EIP Allocation ID，如果为空则跳过绑定
EIP_ALLOC="eipalloc-001" # 替换为实际的EIP分配ID
#EIP_ALLOC=""

# 循环更新所有路由表
for RTB in $RTB_LIST; do
    /usr/bin/aws ec2 replace-route \
        --route-table-id $RTB \
        --destination-cidr-block $VIP/32 \
        --network-interface-id $ENI
done
# 如果设置了 EIP_ALLOC，就绑定 EIP 到当前 ENI
if [[ -n "$EIP_ALLOC" ]]; then
    /usr/bin/aws ec2 associate-address \
        --allocation-id $EIP_ALLOC \
        --network-interface-id $ENI \
        --allow-reassociation
fi
EOF

最后，需要更新Master和Backup节点的安全组，以允许从公网访问HTTP端口。具体做法是在安全组中添加Inbound规则，类型为HTTP (或TCP端口80)， 来源为您电脑所使用的公网IP（或0.0.0.0/0）。之后，我们就可以在本地电脑使用curl或者浏览器去访问VIP了。

总结与讨论

本博客讨论了如何使用AWS VPC子网路由表中的路由条目更新实现keepalived的VIP漂移，从而实现多可用区keepalived集群节点的主备切换。结合弹性公网IP的重新绑定，同时可以支持面向公网的keepalived服务。

讨论

1. 通过VPC对等连接 (VPC Peering) 、VGW和TGW从VPC外部访问keepalived VIP

由于方案中VIP是任意选择的一个IP地址，并未由VPC管理和分配，该VIP无法从VPC对等连接、VGW和TGW从VPC外部访问。如果需要从VPC外部访问VIP，需要在VPC内创建虚拟网络设备（VNF），通过TGW的connect attachment使用GRE隧道通信，并且使用BGP动态路由实现虚拟网络设备自身的高可用配置。相关配置可参见AWS网络博客文章。

2. 使用VPC内的IP地址作为VIP

一个常见的考虑是使用VPC内的未分配IP作为VIP，但是需要注意VPC路由表限制只能以子网CIDR作为路由条目的目标。虽然我们可以创建一个空的子网并在路由表中添加以该子网为目标的路由条目，然后选择该子网中的一个IP地址作为VIP，但是创建这个子网增加了方案的复杂度，与使用VPC外的IP相比而并没有带来额外的价值。

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者