GSLB Active-Passive That Behaves Active-Active
A media company runs active-passive GSLB between a primary site in London and a standby site in Frankfurt. The GSLB vserver gslb_media uses the RTT method and has both site services bound. Each GSLB service is monitored by a TCP monitor on port 443. DNS for media.example.com is a CNAME to the GSLB vserver FQDN; the CNAME TTL is 300 seconds. Last week the London application farm returned HTTP 502 for 18 minutes because a backend database failed, but the London ADC TCP 443 port remained open. GSLB kept sending new users to London, and some users were also sent to Frankfurt even before the incident, which is not desired: Frankfurt should carry traffic only when London is unavailable. Users in Asia report slow startup because RTT chooses London and Frankfurt unpredictably. The company wants deterministic primary/standby behavior and faster detection of application failures without reducing DNS TTL to zero.
1. Why did GSLB keep sending users to London during the 502 incident, and what monitor change would detect it? Where should the monitor be bound?
Read the worked answer
GSLB makes DNS decisions from the state of the GSLB services, and that state is driven by monitors bound to the GSLB service. The TCP 443 monitor only proved that London's ADC was accepting connections; it did not prove the application was healthy. London returned HTTP 502 while TCP stayed open, so the GSLB service remained UP and RTT continued to include it. Bind an HTTP-ECV monitor to each GSLB service that requests a real health endpoint and expects an application-specific body, for example GET /health with STATUS=OK. Use interval 5, retries 3, downtime 30, and make /health check the database dependency. Bind the same monitor to the local LB services as well: the LB monitor controls local rotation, while the GSLB service monitor controls DNS answers. One without the other leaves a blind spot.
2. Configure deterministic primary/standby behavior. Explain the roles of RTT, backup GSLB vserver, and site priority.
Read the worked answer
RTT is an active-active proximity method: it measures round-trip time and can prefer Frankfurt for some clients when Frankfurt RTT is lower, which is exactly what Asia is seeing. It is not a primary/standby control. Configure a primary GSLB vserver with the London service and a separate backup GSLB vserver with the Frankfurt service, then set the primary backup to the backup vserver. The backup is used only when the primary has no UP GSLB service. If you use site-level priority instead, make Frankfurt a lower-priority or backup site and keep London as the only active site; do not rely on RTT to enforce that. After the change, verify with show gslb vserver and show gslb service that Frankfurt is not returned while London is healthy, and test from multiple resolvers.
3. Walk through the failover timeline with a 300-second CNAME TTL. What TTL and verification steps would you recommend?
Read the worked answer
With interval 5, retries 3, and downtime 30, GSLB marks London down after roughly 45 seconds of failed health checks. It then returns Frankfurt. But the CNAME TTL is 300 seconds, so recursive resolvers and some client caches can keep the old London answer for up to five minutes; the user impact can be around six minutes, not 45 seconds. Lower the CNAME TTL to 30-60 seconds if faster failover is required; do not use 0, which some resolvers ignore or clamp and which increases DNS load. Keep the monitor interval/retries aligned with the TTL so the total detection plus caching time meets the SLA. Verify by querying the GSLB vserver directly with nslookup or dig, checking show gslb vserver and show gslb service state transitions, and testing from a resolver that had cached the old answer.