On this page
This is part 3 of a three-part series on a two-site edge for an AI inference API: part 1, a second pod network with Multus on the EVPN VXLAN fabric; part 2, the F5 BIG-IP edge: BGP route health, Advanced WAF and CIS; part 3, failover between the two sites with BIG-IP DNS.
Part 2 built one site's edge, with a BIG-IP that withdraws the API's route when the backends fail. That handles a failed pool inside a site. It doesn't help when the whole site is down, because the internet still sends traffic to that site's address block. Sending users to another site needs DNS. This part builds global server load balancing (GSLB) with F5 BIG-IP DNS across two sites, fails one, and measures how long clients keep getting the failed site's address.
The lab
There are two copies of the site from the earlier parts, east and west. Each has its own fabric, Kubernetes cluster, llama.cpp replicas and BIG-IP. The two share only an internet core, a client and a caching resolver. Each BIG-IP runs a DNS listener in its site's public block. The two BIG-IPs form one sync group, exchange health over iQuery between their public self IPs, and answer for one wide IP, api.gslb.example. The resolver is configured with both listeners for gslb.example.
What the run shows
- With east healthy, both listeners return east's address. Global availability uses the first pool in the list while it's available.
- When east failed, BIG-IP DNS marked the east pool offline two samples after east's virtual server went offline, between 4 and 11 seconds later, and the listener switched to west.
- The resolver handed out east's address until its cached answer expired. Its last east answer came 11 seconds after the first sample that showed east's virtual server offline.
- A request through the resolver after the switch reached west and got HTTP 200.
- On the first run, with each pool's fallback left at its default, the west listener alternated between both sites' addresses with a TTL of 0 while east was down.
