> 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/04-use-cases.md).

# 使用场景

[概述](/welcome/cn/elastic-compute/01-overview.md)章节提到了 LVS、keepalived 对和 Kubernetes。本章详细介绍最常见的部署模式——每种都是端到端的。

HAVIP 部分每次都相同，因此值得一次说明：**在您实例所在的子网内创建一个 HAVIP，然后让您的故障转移软件指向该地址。** 无需挂载步骤。下面每一节都聚焦于围绕 HAVIP 的软件特定配置。

![三种 HAVIP 部署：数据库对、反向代理对、网关对](https://2318250923-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F0CBWy7DFFtkhyEC9R4kE%2Fuploads%2Fgit-blob-8fe6e2e98c347a26556fe93f6574888daf20a3d5%2F04-use-cases%20\(1\).svg?alt=media)

***

## 场景 1 —— 内核负载均衡器（LVS）调度器对

**您要做的：** 您将 LVS——内核的 IPVS 负载均衡器——作为自己的负载均衡层运行。两个**调度器**实例共享同一个服务 VIP；主调度器将到达的连接分发到一组真实服务器。如果主调度器故障，备用调度器必须接管 VIP，使虚拟服务继续运行。

**部署方式：**

1. 在调度器所在的子网内创建一个 HAVIP。该地址即为 **LVS 服务 VIP**——客户端访问的目标。
2. 在两个调度器上运行 keepalived。其 VRRP 实例跟踪 HAVIP；keepalived 的 `virtual_server` 块承载 IPVS 配置，因此持有 VIP 的调度器同时也是配置 IPVS 的调度器。
3. 将真实服务器置于同一 VPC 内，并按本地化部署方式选择 IPVS 转发模式（DR、NAT 或 tunnel）——HAVIP 管理的是*哪个调度器为主*，与真实服务器路径无关。
4. 对于面向公网的 LVS，将 [EIP](/welcome/cn/elastic-compute/01-overview/03-eip.md) 绑定到 HAVIP。对于内部 LVS——后端调用共享虚拟服务——保持私有即可。

!!! note "两层职责，相互独立" HAVIP 提供**调度器**故障转移；IPVS 提供面向**真实服务器**的流量分发。两者相互独立——不要指望 HAVIP 做任何分发，也不要指望 IPVS 自行抵御调度器丢失。

***

## 场景 2 —— 数据库主备故障转移

**您要做的：** 您运行一个数据库——PostgreSQL、MySQL——一个主节点配一个或多个副本。应用必须连接到一个单一稳定的地址，该地址始终指向*当前的*主节点。集群管理工具（Patroni、repmgr、MHA、Orchestrator）在主节点死亡时提升某个副本；地址必须跟随该提升。

**部署方式：**

1. 在数据库子网中创建一个 HAVIP。将所有应用连接串都指向它——绝不要指向某个具体的数据库实例。
2. 在每个数据库实例上运行 keepalived（或您集群管理工具自己的 VIP 钩子）。
3. 将 VIP 持有权与**主节点角色**而非实例存活性绑定：当前主节点持有 HAVIP；副本保持释放状态。最干净的接线方式是让集群管理工具的提升回调来升降 keepalived 状态。
4. 故障转移时，集群管理工具提升某个副本，该实例随即声明 HAVIP。应用使用相同地址重连，落到新的主节点上。
5. 保持私有——应用服务器位于 VPC 内部。

!!! warning "VIP 迁移前必须 fence 旧主节点" 数据库 VIP 绝不能同时被两个实例持有——那是带*写入*的脑裂。请由集群管理工具的提升决策驱动 VIP 持有权，并确保被降级的主节点在新主节点接管之前先释放地址（或被 fence）。仅靠 VRRP 优先级并不构成 fence 机制。

***

## 场景 3 —— 反向代理 / API 网关对

**您要做的：** 您在后端之前运行一对反向代理或 API 网关——HAProxy、Nginx、Envoy。由于它们是无状态的，任一实例都能承担所有流量；您希望有一个统一的入口地址，并在一台故障时瞬时切换。

**部署方式：**

1. 在代理所在的子网中创建一个 HAVIP——它就是这个唯一的入口地址。
2. 在两个代理实例上运行 keepalived，VRRP 都指向该 HAVIP。
3. 健康检查**代理进程或其监听端口**，使运行中实例上的卡死代理能够释放 VIP，而不是黑洞掉流量。
4. 面向公网？将 [EIP](/welcome/cn/elastic-compute/01-overview/03-eip.md) 绑定到 HAVIP。仅内部使用（客户端是 VPC 内的其他服务）？保持私有即可。

!!! note "主备模式，而非双主模式" HAVIP 每次只将流量送至一个实例，因此这是主备模式——备用代理在故障转移前处于空闲状态。由于代理是无状态的，**抢占通常无害**：让恢复的实例重新接管 VIP 几乎没有成本。如果您需要两个代理同时服务，那需要[负载均衡器](/welcome/cn/elastic-compute/load-balancing.md)，或者两个 HAVIP 通过 DNS 拆分。

***

## 场景 4 —— 自建网关设备（NAT / 防火墙）

**您要做的：** 您将自建的 NAT 网关、防火墙或路由设备作为一对实例运行。VPC 内的其他实例将该设备作为其**默认网关**或下一跳。网关地址必须能抵御设备故障，否则后端所有实例将同时失去网络连通性。

**部署方式：**

1. 在通过设备路由的实例所在的子网中创建一个 HAVIP。该 HAVIP 即为**下一跳地址**。
2. 将受保护实例的默认路由（或相关路由条目）指向该 HAVIP。
3. 在两个设备实例上运行 keepalived。持有者拥有 HAVIP，执行 NAT / 转发；故障转移时备用实例接管网关地址。
4. 在两个设备上启用 IP 转发，并保持防火墙 / NAT 规则集完全一致——任一实例都可能成为持有者。

!!! warning "HAVIP 迁移的是地址，而非连接状态" NAT 转换表和防火墙连接跟踪条目位于实例本身，而非 HAVIP。故障转移后，新持有者的状态表为空，因此现有连接可能被重置——除非您的设备自行复制状态（例如使用 `conntrackd`）。HAVIP 保证*地址*存活；让*连接*存活是您软件的职责。

***

## 场景 5 —— Kubernetes 控制平面与 Service VIP

**您要做的：** Kubernetes 需要在两处稳定的 VIP：控制平面节点共享的单一 API server 端点，以及在 VPC 网络上暴露的 `LoadBalancer` 类型 Service 地址。

**部署方式：**

* **控制平面端点。** 在控制平面节点所在的子网中创建一个 HAVIP，并将其用作集群的 `controlPlaneEndpoint`。在控制平面节点上运行 kube-vip（或 keepalived）；持有 HAVIP 的节点对外提供 API server 服务，VIP 在节点故障时迁移。
* **Service 地址。** 对于 L2 模式部署——MetalLB 的 L2 模式，或 kube-vip 的 ARP 模式——该机制由当前承载 Service IP 的节点通过免费 ARP 进行通告。**每个 Service IP 分配一个 HAVIP**；子网对广播/多播的支持正是让这些 ARP 通告生效的关键。
* 通过将 [EIP](/welcome/cn/elastic-compute/01-overview/03-eip.md) 绑定到对应 HAVIP，将某个 Service 暴露到公网；集群内部端点保持私有。

!!! note "每个独立 VIP 都对应一个 HAVIP" 控制平面端点与每个 `LoadBalancer` 类型 Service 都是独立的地址，具备独立的故障转移——请为每个分配独立的 HAVIP。不要尝试将多个角色复用到同一个上。