Zone-Resilient Catalog Design Under a Hard vCPU Ceiling
Northwind Financial runs Citrix DaaS for 4,200 task workers in Chicago and London. The estate lives in three Azure subscriptions under one Enterprise Agreement, all in East US 2, and today is one machine catalog of 55 D4s_v5 session hosts pinned to availability zone 1, with a single Cloud Connector pair in the primary subscription. Total consumed Dsv5 vCPU in East US 2 is 240 of a 350 regional quota. The service window is 06:00-19:00 Central, the business requires that a full zone outage must not stop new logons, and finance wants monthly chargeback per business unit. Two constraints are non-negotiable: no subscription may carry more than 60 percent of its regional Dsv5 quota, and a monthly image update must never double the compute footprint. Last month's zone 1 incident left London users unable to launch for 40 minutes even though zone 2 was idle.
1. Design the catalog and Cloud Connector layout so a full zone 1 outage still permits new logons. Justify each element.
Read the worked answer
Core principle: Citrix DaaS does not fail over capacity that does not exist. A catalog pinned to zone 1 cannot provision into zone 2 while zone 1 is unavailable, so usable capacity in zone 2 must already be provisioned and registered before the incident, not created during it.
Catalog layout
- Create a second machine catalog from a host connection tied to subscription 2, selecting zone 2 at catalog level. Check in your tenant whether the current release allows a single catalog to span zones; where it does not, one catalog per zone is the supported pattern. Confirm against the MCS documentation at design time rather than assuming.
- Place both catalogs in one delivery group so brokering is a single logical pool and users are not asked to pick a zone.
- Maintain a permanent floor of powered-on hosts in zone 2 sized to the London morning ramp. A catalog whose machines are all deallocated is not a failover plan: power-on plus registration plus agent start is realistically 6-8 minutes for this image.
Cloud Connectors
- Two connectors per subscription, in separate zones, outbound 443 to Citrix Cloud only, with line of sight to AD and DNS. A connector pair in subscription 1 cannot serve a catalog in subscription 2 if that subscription's network path fails, and connectors are cheap relative to an outage.
- Keep connectors out of any forced-tunnelling route that sends 443 through an on-premises proxy; that is a classic cause of intermittent registration loss.
2. Current usage is 240 of 350 vCPU (69 percent), which already breaches the 60 percent rule. How do you place zone 2 capacity and still run monthly image updates? Show the arithmetic and the sequencing.
Read the worked answer
Arithmetic first. 60 percent of 350 is 210 vCPU, so the estate is 30 vCPU over its own ceiling before anything new is added. At 4 vCPU per D4s_v5, roughly 8 hosts (32 vCPU) plus the connector and management VMs must move out of subscription 1 into subscription 2 or 3. Subscription 1 then sits near 208 vCPU, leaving almost no headroom.
Consequence for the design: zone 2 capacity must be built in a different subscription, which also gives the second host connection a clean quota pool. Split the estate so each subscription carries roughly 45-50 percent, leaving genuine room for update churn.
Image updates and the no-doubling rule
- Template-based catalog updates create new machines while old ones still exist. Cap concurrent new-machine creation per catalog so the transient peak fits inside the remaining quota; a peak of 10 extra hosts is 40 vCPU, which is fine in a 45 percent subscription and impossible in one at 208/210.
- Stagger catalogs: update zone 1 in week 1 and zone 2 in week 2, so the two transient peaks never overlap.
- Account for the MCS preparation VM, snapshots and any temporary disks in the same quota math; they are small but they are not zero.
Verification: request a quota increase as a parallel track, but do not design against it, because the 60 percent rule is a governance constraint, not an Azure limit.
3. How would you prove before go-live that the zone-outage requirement is actually met, and what would you monitor afterwards?
Read the worked answer
Testing. Azure does not offer a 'simulate zone failure' button, so build the test yourself: deallocate every session host in zone 1 (and optionally deny traffic to the zone 1 connector subnet via NSG), then immediately run scripted logons as users in both geographies. Pass criteria should be stated numerically in advance, for example: 50 concurrent launches succeed within 90 seconds, and no more than one retry per user.
Watch for the failure mode that the last incident exposed. Users could reach Workspace and be told there were no machines, which means brokering was healthy but capacity was not. A good test therefore records time-to-first-successful-launch, not just 'did the site respond'.
Cadence. Repeat the test after every image update and after any catalog size change, because both move the available-capacity floor.
Monitoring
- Citrix Monitor: registered machines per catalog, machines in maintenance mode, and failed sessions by delivery group. Alert on registered machines in the zone 2 catalog dropping below the floor.
- Azure Monitor: per-subscription and per-family vCPU quota utilisation at 80 percent, VM allocation failures, and host power-on latency trend.
- Chargeback: tag resource groups and catalogs per business unit, and push Azure Cost Management plus Citrix utilization data to finance monthly.
Log the outage test result next to the alert thresholds so the operational runbook and the design assumption cannot drift apart.