Context
The firm delivers virtual desktops with Citrix Virtual Apps and Desktops, on an infrastructure that is partly VMware and partly Nutanix: pooled desktops created with Citrix Provisioning and with MCS, user profiles on Nutanix Files. Disaster recovery relied on Zerto replicating the main VMs to an external site: NetScaler, StoreFront, Delivery Controller, database, Provisioning servers and their desktops.
I reviewed the existing configuration and proposed the target one, together with the technical requirements to get there.
The challenge
- MCS desktops do not replicate. The clones MCS creates depend on the hosting connection they were born on: they cannot be copied from one storage to another like other VMs.
- A DR to rebuild at the worst moment. With a replicated farm, a disaster means powering on and bringing back the whole Citrix infrastructure.
- Images always in step. Every master image update has to reach the DR Machine Catalogs too.
- Consistent profiles. In DR every user has to find their own profile, which today lives on Nutanix Files in production.
- Service account permissions. The LTSR version in use connects to the Nutanix cluster, not to Prism Central: the hosting connection needs a cluster administrator.
The proposed architecture
The DR site hosts a complete, independent Citrix farm, not a replica of production: two NetScaler VPX, two StoreFront servers, two Delivery Controllers, its own database and a hosting connection to the local Nutanix cluster. Users keep the same address: normally they land in production, in a disaster they land in DR.
Only what is needed travels between the sites: the master images, through Nutanix Protection Domains, and the profiles on Nutanix Files. When an image is updated, the DR MCS Machine Catalogs are updated from the replicated copy on their own hosting connection, and DR stays ready without recreating the catalogs.
Key decisions
- A ready farm, not a copy. DR has its own Citrix infrastructure, always running and reachable, so the catalogs can be kept up to date at any time.
- Replicate the images, not the clones. Protection Domains carry the master images to DR; MCS creates the clones on site.
- One platform. In the target design production and DR both run on Nutanix, with MCS on both sites instead of Citrix Provisioning and VM replication.
- Replicated profiles. The profiles on Nutanix Files are kept in step between the production and the DR cluster.
- A stated limit. Until the on-premises version can connect to Prism Central, a capability Citrix has announced for DaaS, the hosting connection account has to be a cluster administrator: a risk to know and manage.
01
Solution, layer by layer
Pick a layer involved to read what was done.
L1 · Secure access
In the proposed design each site has its own pair of NetScaler VPX and two StoreFront servers: in DR the access path is already running, not a copy to power on, and users keep the same address.
L2 · Digital workspace
A second Citrix Virtual Apps and Desktops farm, independent and always reachable, with its own Delivery Controllers and database and a hosting connection to the DR Nutanix cluster. Every master image update also updates the DR MCS Machine Catalogs.
L3 · Hyperconverged platform
Master images reach DR through Nutanix Protection Domains; MCS clones do not, because they depend on the hosting connection they were born on. The profiles on Nutanix Files are also kept in step between production and DR.
02
Results
- 2
- independent Citrix farms, production and DR
- 0
- Machine Catalogs to recreate in a disaster
- 2
- Nutanix replications: master images and profiles
- 1
- platform on both sites: Nutanix
03