Scaling a Multi-Site Citrix VDI Deployment on Nutanix AHV
A regional healthcare provider runs 1,200 non-persistent Citrix Virtual Apps and Desktops desktops on a 12-node Nutanix AHV cluster across two data centers, with Prism Central managing both sites. Each site has 6 nodes (N+1), and the clusters are not stretched. The organization plans to add 400 desktops for a new clinic network and wants to introduce NVIDIA vGPU for radiology image review on 60 desktops. Current average CPU utilization is 55%, memory 68%, and storage 45%; login storms cause 200 ms storage latency spikes. The infrastructure team proposes adding two nodes per site and placing all infrastructure VMs (Citrix Delivery Controllers, StoreFront, SQL, file servers) on the same cluster as the desktops. They also ask whether Prism Central should be deployed as a single VM or a three-VM cluster. The CIO is concerned about single points of failure and blast radius.
1. Evaluate the proposed scaling and infrastructure placement. What changes would you recommend for availability and performance, and why?
Read the worked answer
The proposed two nodes per site may be insufficient because the 400-desktop addition is a 33% growth in users, and vGPU workloads reduce consolidation ratios. Build a per-desktop CPU and memory model, retain at least 20-30% headroom, and account for N+1 at the GPU host level, not just cluster level. Placing Citrix Delivery Controllers, StoreFront, SQL, and file servers on the same cluster as desktops increases blast radius and puts management workloads in direct contention with login storms. Recommend a separate management cluster, or at minimum anti-affinity rules and resource reservations, so a VDI host failure or boot storm cannot take down the control plane. Keep Citrix infrastructure active-active across sites where possible. For Prism Central, a single VM is a production single point of failure. Use a three-node Prism Central cluster on the management cluster, with anti-affinity, static addressing, and backup. This separates management-plane failure domains from the desktop clusters and gives the CIO a defensible availability design.
2. How should NVIDIA vGPU be configured and scheduled on AHV for the 60 radiology desktops, and what licensing or support considerations apply?
Read the worked answer
Start with the Nutanix and NVIDIA support matrix, then select a supported GPU card and vGPU profile sized for radiology image review. Each desktop needs enough framebuffer for large image sets; a 4-8 GB vGPU profile is a reasonable starting point, but validate with the ISV. Dedicate GPU-capable hosts to the radiology pool rather than mixing GPU and CPU-only workloads, because GPU capacity is not fungible and live migration support may be limited. Use AHV affinity policies to keep the 60 VMs on the correct GPU hosts and reserve GPU capacity for N+1. License NVIDIA vDWS for professional graphics, and confirm that the chosen profile is licensed for the use case. Monitor GPU utilization and framebuffer pressure in Prism Central. Test failover and maintenance scenarios before go-live, because a GPU host outage must not strand radiology users without a documented recovery path.
3. What Prism Central deployment model should be used, and what operational practices should accompany it?
Read the worked answer
Deploy Prism Central as a three-node cluster for production, not as a single VM. A single VM removes redundancy for the management plane and becomes a hard dependency for both sites. Place the three Prism Central VMs on the management cluster with anti-affinity so they do not share a host failure domain, and size them according to Nutanix guidance for the number of managed nodes and VMs. Use static IPs, DNS, and NTP, and back up Prism Central configuration regularly. Restrict management-network access and integrate authentication with the provider's directory. Operate Prism Central as a shared service with its own monitoring and upgrade window, separate from the desktop clusters. This design lets the CIO treat management as a resilient service rather than an incidental VM, and it supports future growth without re-architecting the control plane.