Active-Active GSLB for a Two-Datacenter HR Portal
A retailer is consolidating two application sites into an active-active design. The employee HR portal (ADC in front of two IIS nodes writing to SQL Always On) must run from both Amsterdam and Dallas, and each site is sized to carry 100% of the load. RTO is 15 minutes and the business will not accept a manual DNS change during an outage. The public zone retail-example.com is hosted by a managed DNS provider that permits only A, CNAME, and TXT records; NS delegation for a new subdomain is allowed but needs a 10-day change request. Peak load is 9,000 concurrent TLS sessions and roughly 1,100 new handshakes per second at 2K RSA. The back end is also TLS, with mutual authentication from the ADC. Each site has an MPX 8905 pair on 13.1, TLS 1.3 and P-256 certificates are mandatory, and the network team refuses anycast. The architect must document the DNS integration, the load-balancing metric, and why the existing throughput-only sizing model is unsafe.
1. How should DNS be integrated with GSLB given the provider constraints, and what must be verified on the ADC before cutover?
Read the worked answer
Two integration models are possible, and the constraint decides the timeline rather than the design.
NS delegation (target state). Delegate a subdomain, for example gslb.retail-example.com, from the managed provider to the GSLB site IPs as NS records. The ADC then answers authoritatively per query and remains health-aware, and you control TTL and persistence end to end. Because the provider needs 10 days, raise the request on day one and run the CNAME model in the meantime.
CNAME (interim state). Publish app.retail-example.com as a CNAME to the GSLB FQDN, with the ADC authoritative for that FQDN. The ADC still returns the selected site's address, but every answer now passes through resolver caching. Confirm the provider honours a 30-60 second TTL; if it enforces 300 seconds or more, the 15-minute RTO is at risk because cached answers keep pointing at the failed site.
Pre-cutover checks: GSLB site IPs reachable on the MEP and RPC ports (3009 and 3011 by default) in both directions; TCP 53 permitted to both site IPs; monitors bound to each GSLB service and validated by disabling one service deliberately; TTL behaviour tested with dig against several public resolvers; and a documented rollback that removes the CNAME or delegation. Note that recursive resolvers hide client subnets, so any proximity decision is only as good as the resolver population, not the actual user location.
2. Which GSLB metric and persistence design would you standardise on, and what would change your mind?
Read the worked answer
The metric has to answer one question: which site will give this user a good experience right now, given both sites are healthy.
Round-trip time (RTT) is the stronger default here. It measures the actual path from each site to the client's resolver, including real congestion on the MPLS and internet paths, and it fails over automatically when a site's monitor degrades. The trap is the monitor: a plain TCP monitor measures a handshake, not the portal. Bind an HTTP or ECV monitor that touches the app tier and, ideally, exercises the database path, otherwise RTT ranks sites on network distance while the slow site wins.
Static proximity is the fallback if RTT proves noisy. With 4,000 of 6,500 users concentrated in known corporate ranges, explicit location entries are defensible and stable, but the default location for everyone else is a guess and will not react to a congested path.
Persistence: use HTTP cookie-based site persistence so a user does not hop sites mid-session, with the cookie domain set so it survives the CNAME, and set a persistence timeout matched to the portal's idle timeout. Do not rely on source-IP persistence: corporate NAT and proxy pools collapse thousands of users into a few addresses and skew site load. Also remember that RTT and static proximity cannot be nested; if you need per-site weighting, apply weights on the GSLB services rather than trying to combine methods.
3. The customer says the pair is sized for 20 Gbps of throughput, so 1,100 handshakes per second is trivial. Write the sizing argument.
Read the worked answer
Throughput and TLS transaction rate are separate capacity axes, and this design is limited by the second one.
Count every handshake. 1,100 new front-end handshakes per second at 2K RSA is only half the figure. Because the ADC re-originates TLS to the back end with mutual authentication, each new front-end session can trigger a back-end handshake too, so plan for roughly 2,200 handshakes per second per site, and each site must do this alone at 100% load.
Key size and protocol matter. Datasheet TLS transaction rates are usually quoted at 1K RSA; 2K RSA is materially slower per handshake. P-256 ECDSA with TLS 1.3 is cheaper and uses a 1-RTT handshake, which helps, but only if the certificate, the cipher group, and the crypto hardware all support it.
Reduce the load before buying more. Enable TLS session reuse and tickets on the front end, and session reuse on the back-end services, so repeat users are not full handshakes. Confirm the resulting rate with stat ssl during a load test rather than trusting a paper calculation.
Then add headroom. Size each site to the measured handshake rate plus 30-40%, remember that 9,000 concurrent sessions consume session memory on both nodes, and validate the failover case: when one node is down, the survivor must absorb the full site load on its own.