> 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 从故障的持有者迁移到备用实例](/files/Xg3SSC0tYukqQ2V3NCVQ)

考虑一个 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)——本机制所适配的故障转移模式。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.console.zenlayer.com/welcome/cn/elastic-compute/01-overview/02-how-it-works.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.