Most GSLB implementations make data-center selection decisions from a single signal class. Geographic distance is one common choice; round-trip time from the platform's measurement points is another; static topology lookups are a third. Each captures a useful dimension and misses the others.
Geography ignores load — the closest data center may also be the one currently under capacity pressure. Latency from the GSLB's probes ignores the user — the user's real network path is not the path the probe took. Static topology assumes the network is unchanged since the configuration was written.
Production decisions need all three views at once: is the DC platform healthy? Is the application on the DC currently performing? Is the network from the user to the DC actually good right now? Each view has signals the others cannot replace.
TR7 GTM exposes the three signal classes — host, service, client — as independent inputs to DC selection, letting operators describe the policy that actually fits their workload.
DC selection is configured per DNS record. Operators choose which signal source to use, which specific metric within that source, how many DCs to pick, and how to distribute across the picks.
Five metrics measured at the DC platform: CPU, memory, bandwidth, status (up/down composite) and packet loss. Useful when DC platform pressure is the dominant signal for routing decisions.
Eight metrics measured per service: CPU, memory, bandwidth, request rate, connection count, new-session rate, status and healthyBackends. Routes traffic by what the application is actually doing, not just whether the host is up.
Four metrics measured from the network path to the requesting client: hops, MOS (Mean Opinion Score), packet loss and TTL. Captures the user-side experience that DC-side probes cannot see.
`pickDcCount` chooses how many DCs to return. `balanceAlgorithm` distributes across the picks — all, top-N, round-robin, weighted round-robin, random, weighted random, or closest.
Each DNS record in DC mode independently selects its signal source, criterion and distribution behaviour.
DC host source exposes cpu, mem, bw, status and packetLoss. Status is the composite reachability/health state computed from the DC's WAN and LAN access points. Useful when host-level capacity is the dominant routing signal.
Service source exposes cpu, mem, bw, request, connection, session_new, status and healthyBackends. The healthyBackends count is particularly load-bearing — it routes traffic to the DC where the application has the most working capacity right now, not just to the DC whose platform is up.
Client source exposes hops (path length), mos (Mean Opinion Score for VoIP/real-time traffic quality), packetLoss and ttl. These signals are measured against the client network, capturing the user experience that DC-side health probes do not see.
Static mode bypasses the multi-source selection and assigns DCs based on operator-defined rules. Useful for legacy DNS records, compliance-driven routing (specific DCs for specific clients) and tests.
Selection criterion is operator-controlled: lowest value wins, highest value wins, value equals target, or value differs by margin. The same DSL drives criterion evaluation across all three signal sources.
`pickDcCount` defaults to 1 but can be set higher to return multiple DCs in the DNS response. This enables true multi-DC load balancing rather than always-pick-one routing — DNS clients receive multiple answers and the client-side resolver or stub selects between them.
Once DCs are picked, the records within each DC are distributed according to `balanceAlgorithm`: all (return every record), top-1/2/3 (return top N), round-robin, weighted round-robin, random, weighted random, or closest (proximity to requester). The right algorithm depends on whether you want broad distribution, top-N concentration or stickiness.
When using the service source, operators specify the service name — different applications running on the same DC fleet can have different routing rules. The healthyBackends count for service A and service B can drive separate DC choices.
If selection returns no healthy DC, the record's fail-safe list provides last-resort answers — operator-defined IPs that are always returned when the multi-source signals all fail. Prevents NXDOMAIN as a final answer.
DC selection is configured per DNS record. The same domain can have an A record routed by service.healthyBackends, an MX record routed by host.status and a CNAME routed by client.packetLoss. Operators tune each record to its workload.
Multi-source selection works together with DC definitions, health-check scenarios, weighted DNS algorithms and fail-safe records.
Each signal source has its own measurement cadence. Host and service metrics refresh on the GTM's metric collection cycle (typically every 30-60 seconds). Client metrics update per resolver session. Operators tune cadence per source against the DC topology.
Selection uses one source at a time per record. When operators want host signals to gate service signals ("only consider service metrics if host is healthy"), they bind a host-based scenario to the service-source record. Layering is explicit.
The healthyBackends count is read directly from the application's load-balancing tier on each DC, not approximated from external probes. The number reflects the actual pool of healthy backends behind the service at that moment.
MOS is computed from network-quality measurements (jitter, packet loss, latency) against the requesting client network. It is most accurate for ongoing client sessions and converges within a few measurement windows for first-time clients.
If `pickDcCount` is greater than the available healthy DC count, all available healthy DCs are returned. The platform never invents fake DCs to meet the count target — operators see exactly which real DCs were eligible.
Selection and distribution algorithms compose: selection picks the eligible DCs by criterion; distribution determines how records within each DC are returned. A record can pick 3 DCs by service.healthyBackends, then return records within each DC by weighted random.
Service source with healthyBackends criterion routes traffic to the DC where the application has the most working capacity. Avoids hot-spotting a DC whose host is up but whose application backends are degraded.
Client source with packetLoss criterion routes each user to the DC with the cleanest network path from their network. Useful for VoIP, video, gaming and real-time applications where path quality matters more than geographic proximity.
Combine pick-N (e.g., return top 3 DCs) with weighted random distribution to share traffic across multiple healthy regions. Each DNS client receives multiple options; resolvers and stubs naturally distribute across them.
Use a host-based scenario as a gate ("DC is platform-healthy") and a service-based criterion as the picker ("DC has highest healthyBackends count among gated DCs"). Critical workloads get a two-layer selection without scripting.
Try multi-source DC selection on your own topology: host metrics, service metrics and client-side network measurements driving the same routing decision.