> 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/04-use-cases.md). # Use Cases The [overview](/welcome/elastic-compute/01-overview.md) named LVS, keepalived pairs, and Kubernetes. This chapter lays out the deployments that come up most often — each end to end. The HAVIP part is the same every time, so it is worth stating once: **create one HAVIP in the subnet your instances share, then point your failover software at its address.** There is no attach step. Each section below focuses on the software-specific configuration around that. ![Three HAVIP deployments: a database pair, a reverse-proxy pair, and a gateway pair](/files/Rc7180mx6WQGm9Vuq27k) *** ## Scenario 1 — Kernel Load Balancer (LVS) Director Pair **What you're doing:** You run LVS — the kernel's IPVS load balancer — as your own load-balancing tier. Two **director** instances share one service VIP; the active director spreads incoming connections across a pool of real servers. If the active director fails, the standby must take the VIP and keep the virtual service running. **How to lay it out:** 1. Create a HAVIP in the directors' subnet. This address is the **LVS service VIP** — what clients connect to. 2. Run keepalived on both directors. Its VRRP instance tracks the HAVIP; keepalived's `virtual_server` block carries the IPVS configuration, so the director that holds the VIP is also the one programming IPVS. 3. Put the real servers in the same VPC and pick an IPVS forwarding mode (DR, NAT, or tunnel) exactly as you would on-prem — the HAVIP governs *which director is active*, nothing about the real-server path. 4. For an internet-facing LVS, bind an [EIP](/welcome/elastic-compute/01-overview/03-eip.md) to the HAVIP. For an internal LVS — backends calling a shared virtual service — leave it private. !!! note "Two layers, kept separate" The HAVIP gives you **director** failover; IPVS gives you the spread across **real servers**. They are independent — do not expect the HAVIP to balance anything, and do not expect IPVS to survive a director loss on its own. *** ## Scenario 2 — Database Primary/Standby Failover **What you're doing:** You run a database — PostgreSQL, MySQL — as a primary with one or more replicas. Applications must connect to a single, stable address that always points at the *current* primary. A cluster manager (Patroni, repmgr, MHA, Orchestrator) promotes a replica when the primary dies; the address has to follow that promotion. **How to lay it out:** 1. Create a HAVIP in the database subnet. Point every application connection string at it — never at an individual database instance. 2. Run keepalived (or your cluster manager's own VIP hook) on each database instance. 3. Bind VIP ownership to the **primary role**, not to instance liveness: the instance that is primary holds the HAVIP; replicas keep it released. The cleanest wiring is to let the cluster manager's promotion callback raise/lower the keepalived state. 4. On failover, the cluster manager promotes a replica and that instance claims the HAVIP. Applications reconnect to the same address and land on the new primary. 5. Keep it private — application servers are inside the VPC. !!! warning "Fence the old primary before the VIP moves" A database VIP must never be held by two instances at once — that is split-brain with *writes*. Drive VIP ownership from the cluster manager's promotion decision and make sure the demoted primary releases the address (or is fenced) before the new one takes it. VRRP priority alone is not a fencing mechanism. *** ## Scenario 3 — Reverse-Proxy / API-Gateway Pair **What you're doing:** You run a pair of reverse proxies or API gateways — HAProxy, Nginx, Envoy — in front of your backends. Because they are stateless, either instance can serve all traffic; you want one entry-point address and an instant takeover when one dies. **How to lay it out:** 1. Create a HAVIP in the proxy subnet — this is the single entry-point address. 2. Run keepalived on both proxy instances, all pointing VRRP at the HAVIP. 3. Health-check the **proxy process or its listening port**, so a hung proxy on a still-running instance releases the VIP instead of blackholing traffic. 4. Internet-facing? Bind an [EIP](/welcome/elastic-compute/01-overview/03-eip.md) to the HAVIP. Internal-only (clients are other VPC services)? Leave it private. !!! note "Active/standby, not active/active" A HAVIP delivers traffic to one instance at a time, so this pattern is active/standby — the standby proxy is idle until failover. Because the proxies are stateless, **preemption is usually harmless**: letting a recovered instance reclaim the VIP costs nothing. If you need both proxies serving at once, that is a job for a [Load Balancer](/welcome/elastic-compute/load-balancing.md) or for two HAVIPs split by DNS. *** ## Scenario 4 — Self-Built Gateway Appliance (NAT / Firewall) **What you're doing:** You run your own NAT gateway, firewall, or routing appliance as a pair of instances. Other instances in the VPC use the appliance as their **default gateway** or next hop. The gateway address must survive an appliance failure, or every instance behind it loses connectivity at once. **How to lay it out:** 1. Create a HAVIP in the subnet whose instances route through the appliance. This HAVIP is the **next-hop address**. 2. Point the protected instances' default route (or the relevant route entries) at the HAVIP. 3. Run keepalived on both appliance instances. The holder owns the HAVIP and does the NAT / forwarding; on failover the standby takes the gateway address. 4. Enable IP forwarding on both appliances and keep their firewall / NAT rule sets identical — either one may be the holder. !!! warning "The HAVIP moves the address, not the connection state" NAT translations and firewall connection-tracking entries live on the instance, not in the HAVIP. After a failover the new holder starts with an empty state table, so established flows may reset unless your appliance replicates state itself (for example with `conntrackd`). The HAVIP guarantees the *address* survives; surviving *connections* is your software's job. *** ## Scenario 5 — Kubernetes Control-Plane and Service VIPs **What you're doing:** Kubernetes needs stable VIPs in two places: a single API-server endpoint shared across the control-plane nodes, and `LoadBalancer`-type Service addresses exposed on the VPC network. **How to lay it out:** * **Control-plane endpoint.** Create a HAVIP in the control-plane nodes' subnet and use it as the cluster's `controlPlaneEndpoint`. Run kube-vip (or keepalived) on the control-plane nodes; the node holding the HAVIP serves API-server traffic, and the VIP moves on node failure. * **Service addresses.** For an L2-mode setup — MetalLB in L2 mode, or kube-vip in ARP mode — the mechanism announces a Service IP with gratuitous ARP from whichever node currently hosts it. Allocate **one HAVIP per Service IP** you want to expose; the subnet's broadcast/multicast support is exactly what lets those ARP announcements take effect. * Expose a Service publicly by binding an [EIP](/welcome/elastic-compute/01-overview/03-eip.md) to its HAVIP; keep cluster-internal endpoints private. !!! note "One HAVIP per distinct VIP" The control-plane endpoint and each `LoadBalancer` Service are separate addresses with separate failover — give each its own HAVIP. Do not try to multiplex several roles onto one. --- # 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, and the optional `goal` query parameter: ``` GET https://docs.console.zenlayer.com/welcome/elastic-compute/01-overview/04-use-cases.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.