Unit 3.5: High Availability at the Network Edge

Introduction

A public endpoint is only as available as the single network interface that currently answers for it. If that interface belongs to one server and the server is lost, the address stops responding, and every client that cached it is stranded until something moves the address elsewhere. The architectural question at the network edge is therefore not "how do I make a server reliable" but "how do I keep a stable public address answering when the thing behind it changes". IONOS gives you a specific primitive for this, IP failover, with a precise and narrow scope. This unit treats edge HA as a design decision: what IP failover guarantees, what it deliberately does not, and how it slots into the broader resilience picture that Module 7 completes.

1. IP Failover: A Shared Address Across Redundant NICs

IP failover is the platform's mechanism for an active-passive edge. The Cloud IP-Failover feature provisions the same IP address to multiple network interfaces belonging to different virtual servers on the same LAN. One NIC is designated the master and holds the address as its primary IP; the other NICs in the group are replicas that stand ready to carry the same address. When the master server fails, the address can move to a replica NIC, so the public endpoint keeps answering without the client ever learning a new address.

What makes this work as a stable endpoint is that the address must be a reserved public IP. DHCP-generated addresses cannot be used in a failover group. This is the same reservation discipline you applied when building the three-LAN topology in Unit 3.1: the reserved IPv4 address is region-bound and persists independently of any single server, which is exactly the property an HA endpoint needs. The failover group simply binds that persistent address to a set of candidate NICs and tracks which one currently owns it.

The single most important property to internalise is the boundary of the guarantee. IP failover provides provisioning of the same IP to multiple interfaces. It does not monitor the availability of the service reached through that IP. The platform moves an address between NICs; it does not run a health probe against your application, decide that your web server is returning errors, and trigger a switch on your behalf. The detection and decision logic that promotes a replica to master lives in your guest operating system. The established pattern is a software HA layer running on the servers themselves, for example keepalived driving VRRP, or a vendor appliance's own HA mechanism, which decides when to claim the shared address and then drives the move. The platform supplies the shared-address primitive; you supply the brains that decide when to fail over. This is the recurring division of labour the platform draws at the infrastructure level versus the application level, and at the edge it is unusually sharp.

Two further constraints shape every design that uses IP failover:

• The LAN must be public (connected to the internet) and must not contain a load balancer. IP failover and a managed load balancer are alternative edge patterns, not layered ones: where a Managed Application Load Balancer or Network Load Balancer already fronts the tier, that balancer is the availability construct and IP failover does not apply on the same LAN.
• Virtual MAC addresses are not supported. A failover design cannot assume a portable layer-2 identity travelling with the address; the move is at the IP layer, and the replica answers with its own MAC once it owns the address. Plan ARP/neighbour behaviour and any gratuitous-ARP expectations accordingly, since the guest HA software is what announces the move.

IP failover must be configured for all such HA setups; it is the native construct for a self-managed active-passive pair behind one public address, and the platform documents no alternative for that specific shape.

2. When Edge IP Failover Is the Right Tool

IP failover earns its place in a narrow band of designs, and recognising that band keeps you from misapplying it. The following table contrasts the edge-availability options you now have across this module.

The decisive question is whether the thing you are protecting manages its own availability and needs a single sticky public address, or whether it is a horizontally scalable tier that a managed balancer should spread traffic across. A self-managed network virtual appliance, a software firewall, or a clustered service that expects to own a floating VIP is the classic IP-failover candidate: it already runs keepalived or an equivalent, and it only needs the platform to let two of its NICs share one reserved address. A stateless web or API tier is not; that belongs behind a managed load balancer, where health checking and backend distribution are handled for you.

IP failover is also bounded by fault domain. Because the failover group lives on a single LAN, it protects against the loss of a server, not against the loss of an availability zone or a region. That is the seam where the next two mechanisms take over.

3. Composing Edge HA with Multi-Zone Placement and DNS Failover

No single construct delivers end-to-end resilience, and designing as if one does is the most common edge mistake. The robust posture is layered, with each mechanism covering the fault domain the one below it cannot.

At the bottom, multi-zone placement spreads the redundant members of any pair across availability zones so that a zone-level fault does not take both halves at once. This is a placement decision made at provisioning time, and it interacts directly with edge HA: an IP failover pair whose master and replica sit in the same zone gains nothing when that zone is lost. Place the members in different zones, and be deliberate about it rather than accepting an automatic placement that may co-locate them. (Compute exposes Zones 1, 2, and Auto; "Auto" is convenient but is exactly the setting that can silently put a redundant pair together, so name the zones explicitly for any HA pair. Module 7 returns to this auto-zone trap in the resilience context.)

Above placement, DNS failover covers the fault domains that no single IP can span. A reserved IP and its failover group are anchored to one region and one LAN; they cannot move an endpoint to a second site or a second region. When the fault domain you must survive is larger than a LAN, the steering moves up to the name. As Unit 3.7 develops, this is a customer-built pattern rather than a native product: your own health check (an external monitor, or a signal from a load balancer's target health) detects a dead endpoint and calls the Cloud DNS API to re-point a low-TTL record at a healthy one. Cloud DNS itself is not health-aware; it serves whatever record you set and never changes an answer on its own. This is how you get automated failover across zones and sites given that there is no managed failover product. DNS failover steers only new connections, so the tiers it fronts must be stateless for the pattern to be safe.

Read together, the three layers form a clear hierarchy: IP failover keeps a single public address answering when a server dies on one LAN; multi-zone placement ensures the redundant members do not share a zone-level fate; and DNS failover redirects clients when an entire endpoint, zone, or site is gone. Each is necessary, none is sufficient alone, and the edge design is the act of choosing which layers a given endpoint actually needs.

FinCorp at the edge

FinCorp's regulated workloads sit behind a self-managed network firewall appliance that the security team insists on operating themselves, for policy and audit reasons. That appliance is the textbook IP-failover case: two firewall instances on the public LAN, master and replica, sharing one reserved public IPv4 address, with the appliances' own HA process deciding when the replica claims the address. FinCorp places the two firewall instances in different availability zones so a zone fault cannot drop both, and accepts that the platform will not health-check the firewall service for them; that monitoring is the appliance's job. For the public-facing stateless web tier sitting behind that firewall, FinCorp does not use IP failover at all; it uses the Managed Application Load Balancer from Unit 3.3, because that tier scales horizontally and benefits from health-checked distribution. The cross-site question, surviving the loss of the primary region entirely, is deferred to the DNS failover design in Unit 3.7 and the continuity plan in Module 7, because no edge IP can answer that requirement. The decision accumulates: one reserved IP and an IP-failover pair for the self-managed appliance, managed load balancing for the elastic tiers, and DNS as the cross-fault-domain steering layer.

Decision Summary

The selection rule: protect a self-managed, single-address pair with IP failover; protect an elastic tier with a managed load balancer; protect against zone loss with explicit multi-zone placement; and protect against the loss of an entire endpoint or site with DNS failover. The mechanisms layer; they do not substitute for one another.

Summary

High availability at the IONOS network edge is built by composition, not by a single feature. IP failover gives a self-managed active-passive pair a stable reserved public IP that can move between redundant NICs on the same public LAN, but it deliberately stops at provisioning the shared address: the health detection and the decision to fail over live in your guest, and the construct cannot span a load-balanced LAN, use a DHCP address, or rely on a virtual MAC. Around that primitive you layer explicit multi-zone placement to defeat zone-level faults and DNS failover to redirect clients when an entire endpoint or site is gone, which is the platform's answer to having no managed failover product.

Key Points:

• IP failover provisions one reserved public IP across multiple NICs on different servers on the same public LAN; the master holds it, replicas can take it over.
• The platform does not monitor service health for failover. Detection and promotion are the customer's responsibility, typically a guest HA layer such as keepalived/VRRP or a vendor appliance's own HA.
• IP failover requires a reserved public IP (no DHCP), a public LAN with no load balancer, and does not support virtual MAC addresses.
• IP failover is for self-managed single-address pairs; elastic stateless tiers belong behind a managed load balancer instead.
• Edge HA composes with multi-zone placement (defeat zone faults; set zones explicitly, never Auto for a redundant pair) and DNS failover (defeat endpoint/zone/site loss), each covering a fault domain the other cannot.

Important Terminology:

• IP failover group: A set of NICs on different servers on one public LAN that share a single reserved public IP, with one designated master, enabling active-passive failover of the address.
• Master / replica NIC: Within a failover group, the master currently owns the shared address as its primary IP; replicas are eligible to take it over.
• Active-passive HA: A redundancy model where one node serves traffic and a standby takes over on failure, as opposed to active-active load sharing.

Further Reading

• Unit 3.3, Load Balancing - Layer 7 (Application), and Unit 3.4, Load Balancing - Layer 4 (Network), for the managed-load-balancer edge alternative.
• Unit 3.7, DNS and Failover Routing, for cross-zone and cross-site failover steering.
• Module 7, Operations, Resilience, and Performance, for multi-zone placement, the auto-zone trap, and the full business-continuity picture.