HAVIP 工作原理
HAVIP 由两部分组成：虚拟 IP 本身，以及持有者——当前拥有该地址的唯一实例。本章描述两者之间的关系，以及故障转移期间发生了什么。
子网范围的虚拟 IP
HAVIP 是一个在整个子网内有效的虚拟 IP——子网内的任何实例都可以声明它。任何时刻最多只有一个实例作为持有者：它在自己的 vNIC 上拥有该 VIP，并接收所有发往 HAVIP 的流量；其他实例则处于备用状态。
哪些实例参与、谁来持有 VIP，由您的故障转移软件决定——keepalived 使用 VRRP、LVS、kube-vip——而非由平台决定。ZEC 不参与选举；它所报告的持有者只是对当前哪个实例拥有该地址的观察结果。
网络如何跟随持有者
虚拟 IP 是单一地址，但在其生命周期内由不同的 vNIC——即不同的 MAC 地址——承担服务，因为持有者会发生变化。为了让流量到达正确的位置，VPC 网络必须知道当前哪一个 vNIC 拥有这个 HAVIP。
这一信息由持有者本身提供：
当某实例接管 VIP 时，其故障转移软件会在本地 vNIC 上声明该地址，并在子网上通告新的所有权（在 keepalived 的场景中，是一次免费 ARP）。
ZEC 网络监听到该通告后，更新其转发表，使 HAVIP 解析至新持有者的 vNIC。
此后，VPC 内任何实例——或者绑定该地址的 EIP——发往 HAVIP 的每个报文都将到达新的持有者。
第 2 步无需您手动配置。它是自动完成的，也正是这一点让 HAVIP 成为虚拟 IP，而不仅仅是一个备用地址：地址与当前承担服务的 MAC 解耦，每当持有者变更时，网络会重新绑定两者。子网对广播/多播的支持承载了这条通告。
故障转移分步说明
考虑一个 HAVIP 10.0.1.50 位于某子网中，并在 keepalived 中配置了两个实例——vm-A（持有者）和 vm-B（备用）：
1. 稳态
vm-A 持有 10.0.1.50。客户端连接到 10.0.1.50 并由 vm-A 提供服务。vm-B 运行相同服务，但不接收任何流量。
2. 持有者故障
vm-A 崩溃、断电或服务死亡，停止发送 VRRP 心跳。
3. 备用检测
vm-B 的故障转移软件未检测到心跳，判定 vm-A 已死，将自己提升为持有者。
4. 备用声明 IP
vm-B 在其 vNIC 上声明 10.0.1.50 并在子网上通告新的所有权。
5. 网络重新指向
ZEC 网络监听到该通告，将 10.0.1.50 重新绑定到 vm-B 的 vNIC。
6. 新稳态
发往 10.0.1.50 的流量现在到达 vm-B。客户端使用的地址始终未变。
vm-A 恢复后接下来发生什么完全取决于您的 keepalived 配置——可能会重新接管持有者角色（如果配置为更高优先级并启用了抢占），也可能保持备用状态。ZEC 仅汇报当前持有该地址的实例。
!!! note "故障转移速度由您的软件决定，而非由 ZEC 决定" 第 3 步发生的速度——也即停机时长——由您的 VRRP 通告间隔和死亡定时器决定，与平台无关。第 5 步中网络的重新指向会在收到子网内的通告后迅速完成。请根据您的服务所需的故障转移速度，在客户端调整相关定时器。
为什么 HAVIP 位于同一广播域
HAVIP 之所以能工作，是因为它处于一个二层广播域内。这个广播域是机制的核心：它承载了故障转移软件依赖的 VRRP 通告与免费 ARP，并让新持有者的通告能到达每一台主机，使网络重新指向 VIP。
子网是这个广播域的可见形式。因此"HAVIP 与所有可能持有它的实例共享同一子网"这一规则的实质是"它们共享同一个广播域"——位于其他子网的实例处于另一个广播域，没有声明该 VIP 的二层路径，地址也无法跟随它移动。
下一步
EIP 绑定到 HAVIP——为面向公网的服务在 HAVIP 之前增加 EIP。
使用场景——本机制所适配的故障转移模式。
最后更新于