Two data centers, 130 ms apart: one Site with zones or two Sites?
Northwind Logistics is designing a new Citrix Virtual Apps and Desktops deployment. It has 4,200 internal users split roughly 60/40 between Amsterdam and Dallas. Each location has its own data center, vSphere cluster and 10 GbE core; the inter-data-center link is 130 ms RTT with 500 Mbps committed bandwidth. The business wants one active/active design in which users always land in their own data center, and in which a data center outage lets users relaunch in the surviving site within a 30-minute RTO. Sessions themselves do not need to survive a failover. The database team offers a SQL Server Always On availability group with synchronous commit inside each data center and asynchronous commit across them. One engineer proposes a single Site with two zones and one StoreFront store; another proposes two independent Sites with one store per Site and GSLB in front. A pilot showed Dallas users brokering from Amsterdam with 140 ms ICA RTT.
1. Which topology do you recommend, one Site with two zones or two independent Sites? Justify the decision using the traffic and failure characteristics of each component.
Read the worked answer
The decision hinges on where the site database lives, not on where the VDAs live.
What a single Site buys you is administrative: one Studio console, one catalog and delivery group definition, one policy set, and zone preference to pin users to their local zone. What it costs you is that a zone is only an administrative boundary inside one Site, not an independent unit. Every controller in both data centers reads and writes the same site database; VDA registration and session state live there; and the controller that handles a launch is whichever one answers. Across a 130 ms link with asynchronous commit, a Dallas launch served by an Amsterdam controller pays multiple WAN round trips before ICA even starts - which is exactly the 140 ms RTT seen in the pilot.
Two independent Sites put SQL, brokers and VDAs in the same failure domain, so a Dallas launch never depends on Amsterdam. The costs are real and must be accepted consciously: duplicated catalog, delivery group, application and policy definitions; two upgrade events per year; no automatic cross-site load balancing; and no session reconnection across sites - which the 30-minute RTO already concedes.
Recommendation: two Sites. Reserve the single-Site-plus-zones model for topologies where inter-DC latency is single-digit milliseconds (metro or stretched LAN), where zone preference reliably delivers locality, and where one console genuinely outweighs site autonomy.
Validate before signing off: that each Site's database connection string uses its local Always On listener with synchronous commit, and that no controller in either Site has a network path that makes the remote database attractive as a failover target.
2. With two Sites, how do you make users land in their own data center, and what does failover actually look like for them?
Read the worked answer
Locality in a two-Site design is enforced at the entry point, not by the broker.
Layer 1 - name resolution and routing. GSLB (or split-horizon DNS with health-aware records) sends Amsterdam users to the Amsterdam StoreFront cluster and Dallas users to Dallas, with a health monitor on the StoreFront store URL. A single published external name is fine, provided the GSLB monitor reflects real store health rather than ping.
Layer 2 - what each store enumerates. This is the decisive control: each store is bound only to its own Site's Delivery Controllers. A Dallas user therefore cannot be brokered by an Amsterdam controller even if Dallas machines are all busy - the wrong-site launch failure is eliminated structurally, unlike zone preference in a single Site, which is a best-effort preference that can be overridden.
Layer 3 - external access. Each NetScaler Gateway instance should point its STAs at the Site it fronts, and the store's Gateway configuration should exist in both stores so a surviving Site can serve external users. If optimal gateway routing or a single external URL is used, document which Gateway each store must fall back to.
Failover behaviour: GSLB health check fails, clients receive the surviving store, and they relaunch. Because no session persistence is required, the user experience is 'reconnect and reopen', which the RTO accepts. What must be engineered is capacity: the surviving Site must be sized so that its local load plus the failed site's load fits, or the failover must be scoped to defined priority groups (for example only critical delivery groups are re-enabled cross-site).
Test explicitly: a forced Site outage, authentication through the surviving Gateway, and a full 4,200-user launch simulation - not a ping to the load balancer.
3. The Dallas site handles 40% of users. What design decisions follow from the requirement that the surviving site absorb them within 30 minutes?
Read the worked answer
A 30-minute RTO is a capacity and operational statement, not a technology statement, and it forces four decisions.
1. Headroom is a design input, not an afterthought. Either each Site is built at roughly 1.5x its own peak (Amsterdam carries 2,520 locally plus 1,680 from Dallas, i.e. 4,200 against a design peak), or the failover is deliberately partial. Choose one and write it down; a partially sized site that silently gets asked to absorb everything is the most common DR failure in these designs.
2. Power management and catalogs must be ready for a cold start. With MCS or PVS pooled machines, the surviving catalog must have enough powered-on or rapidly startable capacity; boot storms across 1,680 desktops can exceed 30 minutes on their own. Pre-warm a buffer, keep Autoscale or power management schedules that can start the surge quickly, and test the actual boot rate rather than assuming it.
3. Delivery group scoping. Publish the failover set as a separate delivery group (or use priority/restricted access) so a partial failover is a two-click operation rather than a rebuild: critical applications first, then general desktops if capacity allows.
4. Operational readiness. Two Sites means two upgrade pipelines, two certificate lifecycles and two monitoring stacks. Director should be configured to see both Sites, GSLB monitors must be tested with a real failure, and the DR runbook should specify who re-enables which delivery groups and how users are told to reconnect.
Verification: a documented, executed DR test showing time-to-capacity from the outage to 1,680 successful launches, with the bottleneck identified (storage, DHCP, boot storm, StoreFront, authentication).