> 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/elastic-compute/01-overview.md). # High-Availability Virtual IP Some software runs its own high availability around a **virtual IP** — one address that a group of servers share and hand off between themselves when a node fails. LVS (the kernel-level load balancer), keepalived active/standby pairs, and Kubernetes VIPs all work this way. On an ordinary cloud network they don't work. The VPC fabric drops the broadcast and multicast traffic these tools depend on, and it won't deliver packets to an address that an instance simply claims for itself. A **High-Availability Virtual IP (HAVIP)** is the ZEC feature that lifts that restriction. ![A HAVIP is a floating private IP that any instance in the subnet can claim](/files/NRPCHeRALyyBqNQZarvP) *** ## What ZEC Provides A HAVIP is a private IP **reserved inside a subnet** and not pinned to any one instance. It takes effect at the **subnet level**: once the HAVIP exists, any instance in that subnet may run failover software and claim the address. The platform provides the two things VIP-based tools need: * **A floating address.** The HAVIP can be held by any instance in the subnet. The network delivers HAVIP traffic to whichever instance currently holds it, and follows it when that changes. * **A broadcast- and multicast-capable subnet.** The HAVIP's subnet carries the broadcast and multicast traffic the failover software relies on — VRRP advertisements (unicast or multicast), gratuitous ARP, and the like. *** ## What It's For HAVIP exists to make virtual-IP HA software run on ZEC: * **LVS** — a kernel-level load balancer whose service VIP floats across a director pair. * **keepalived active/standby pairs** — any two-node service (a database primary/replica, a proxy, a gateway) sharing one address, where the survivor takes it over. * **Kubernetes** — a floating endpoint for the control plane, or service IPs announced by an L2 mechanism such as MetalLB or kube-vip. In every case the software already knows how to elect a leader and announce a VIP. HAVIP is simply the network underneath that lets it. The [Use Cases](/welcome/elastic-compute/01-overview/04-use-cases.md) chapter walks through each pattern in detail. A HAVIP carries traffic to the **single** instance currently holding it — it is a failover mechanism, not a load-balancing one. When you want traffic *spread* across many instances with platform-run health checks, use a [Load Balancer](/welcome/elastic-compute/load-balancing.md) instead. The two combine cleanly: a self-built LVS tier often *is* the thing sitting behind a HAVIP. *** ## Where a HAVIP Lives A HAVIP is created inside one subnet, and through that subnet belongs to one VPC in one region. That placement is fixed for life: * The virtual IP is drawn from the subnet's CIDR and cannot move to another subnet, VPC, zone, or region. * Any instance that claims the HAVIP must have a [vNIC](/welcome/elastic-compute/networking/network-interface.md) in that same subnet — only an instance on the subnet can hold a subnet-local address. *** ## What's Next * [**How a HAVIP Works**](/welcome/elastic-compute/01-overview/02-how-it-works.md) — the broadcast domain behind the VIP and the failover sequence. * [**EIP to HAVIP**](/welcome/elastic-compute/01-overview/03-eip.md) — putting a HAVIP behind an EIP for internet-facing services. * [**Use Cases**](/welcome/elastic-compute/01-overview/04-use-cases.md) — LVS, databases, proxies, gateways, and Kubernetes, laid out concretely. *** ## Frequently Asked Questions **Does ZEC pick which instance holds the HAVIP?** No. The platform never elects a holder — your failover software does (keepalived/VRRP, kube-vip, an LVS director script). ZEC observes the announcement on the subnet and points the network at whichever instance currently owns the address. **Can a HAVIP move to another subnet, VPC, or region?** No. A HAVIP is created in one subnet, and through that subnet belongs to one VPC in one region. That placement is fixed for life — the virtual IP is drawn from the subnet's CIDR and cannot be reassigned elsewhere. **Do I need an EIP for a HAVIP to work?** No. A HAVIP works inside the VPC on its own — the normal case for internal LVS, database VIPs, Kubernetes control-plane endpoints, and self-built gateways. Add an EIP only when the HA service must accept traffic from the internet. **Can two instances hold the same HAVIP at the same time?** No. At most one holder at a time. The network points the HAVIP at whichever instance most recently announced ownership, so single ownership has to be guaranteed by your failover software — and, for stateful services like databases, by fencing the old holder before the new one takes the address. VRRP priority alone is not a fencing mechanism. **How fast is a HAVIP failover?** That depends on your software, not on the platform. Your VRRP advertisement interval and dead-timer decide when the standby promotes itself; the network re-points within the subnet promptly after the new holder announces. Tune the guest-side timers to the cutover speed your service needs. **Can I use a HAVIP to load-balance traffic across instances?** No. A HAVIP delivers traffic to the single instance currently holding it — it is a failover mechanism, not a load-balancing one. When you want traffic *spread* across many instances with platform-run health checks, use a [Load Balancer](/welcome/elastic-compute/load-balancing.md) instead. A self-built LVS tier behind a HAVIP combines the two cleanly. **What happens to the EIP during failover?** Nothing changes — the EIP is bound to the HAVIP, not to an instance. The HAVIP re-points to the new holder underneath, and the EIP keeps pointing at the HAVIP. The public address survives instance failure unchanged. --- # 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/elastic-compute/01-overview.md?ask= ``` 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.