> For the complete documentation index, see [llms.txt](https://docs.console.zenlayer.com/welcome/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.console.zenlayer.com/welcome/cn/elastic-compute/01-overview/02-how-it-works.md). # HAVIP 工作原理 HAVIP 由两部分组成：**虚拟 IP** 本身，以及**持有者**——当前拥有该地址的唯一实例。本章描述两者之间的关系，以及故障转移期间发生了什么。 *** ## 子网范围的虚拟 IP HAVIP 是一个**在整个子网内有效**的虚拟 IP——子网内的任何实例都可以声明它。任何时刻最多只有一个实例作为**持有者**：它在自己的 vNIC 上拥有该 VIP，并接收所有发往 HAVIP 的流量；其他实例则处于备用状态。 哪些实例参与、谁来持有 VIP，由**您的故障转移软件**决定——[keepalived](https://www.keepalived.org/) 使用 [VRRP](https://en.wikipedia.org/wiki/Virtual_Router_Redundancy_Protocol)、LVS、kube-vip——而非由平台决定。ZEC 不参与选举；它所报告的持有者只是对当前哪个实例拥有该地址的观察结果。 *** ## 网络如何跟随持有者 虚拟 IP 是单一地址，但在其生命周期内由不同的 vNIC——即不同的 MAC 地址——承担服务，因为持有者会发生变化。为了让流量到达正确的位置，VPC 网络必须知道当前哪一个 vNIC 拥有这个 HAVIP。 这一信息由持有者本身提供： 1. 当某实例接管 VIP 时，其故障转移软件会在本地 vNIC 上声明该地址，并在子网上**通告**新的所有权（在 keepalived 的场景中，是一次免费 ARP）。 2. ZEC 网络监听到该通告后，更新其转发表，使 HAVIP 解析至新持有者的 vNIC。 3. 此后，VPC 内任何实例——或者绑定该地址的 [EIP](/welcome/cn/elastic-compute/01-overview/03-eip.md)——发往 HAVIP 的每个报文都将到达新的持有者。 第 2 步无需您手动配置。它是自动完成的，也正是这一点让 HAVIP 成为*虚拟* IP，而不仅仅是一个备用地址：地址与当前承担服务的 MAC 解耦，每当持有者变更时，网络会重新绑定两者。子网对广播/多播的支持承载了这条通告。 *** ## 故障转移分步说明 ![故障转移前后：虚拟 IP 从故障的持有者迁移到备用实例](https://2318250923-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F0CBWy7DFFtkhyEC9R4kE%2Fuploads%2Fgit-blob-1a93db51e1e9204f51efb7d62696026cc17653cd%2F02-failover.svg?alt=media) 考虑一个 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**](/welcome/cn/elastic-compute/01-overview/03-eip.md)——为面向公网的服务在 HAVIP 之前增加 EIP。 * [**使用场景**](/welcome/cn/elastic-compute/01-overview/04-use-cases.md)——本机制所适配的故障转移模式。