For years our customers have told us that they understand benefits of VDI and secure app and data delivery, but they need us to make deployment and management as simple as possible. That’s why we introduced the Citrix Cloud and its services: to reduce complexity, and make it as easy as possible to deploy Citrix technologies.
The XenApp and XenDesktop Service is a great example. It’s a Citrix Cloud offering where we host the infrastructure components. When implementing the XenApp and XenDesktop Service, we wanted to develop a cost effective method of managing Delivery Controllers for our customers. Delivery Controllers are a critical component of every site and we wanted to ensure consistency across all the Delivery Controller instances running in Citrix Cloud. To do this we needed to keep all virtual machines hosting the Delivery Controllers up to date with the latest security patches.
We knew that as more and more cloud-hosted XenApp and XenDesktop sites were spun up, we needed to a way to prevent configuration drift. To bring the latest features to our customers, we also planned to upgrade to a newer release every 14 days and needed an easy way to push out these updates. Lastly, we knew we must have a robust disaster recovery solution.
Single Image Controller
To help address all these imperatives, we established the concept of a Single Image Controller. The core concept behind Single Image Controller is that we will maintain a single base image for all of our Delivery Controllers. These base images will be generated as part of the product build process triggered by each code change. Once we near the start of our next release cycle, we have our QA team perform a test close down on the next release. After all tests have been passed, we begin a phased rollout of the new build to all customers.
We designed our deployments so that each upgrade spins up a new VM and connects to a database (which we regularly backup). Any machine failure or disk corruption can be restored by simply deploying a new Delivery Controller and connecting it to the database – no different than any regular upgrade. This approach also prevents configuration drift (by avoiding reliance on long-lived VMs) and automatically gains the latest Windows security patches as part of regular upgrades.
Baking Single Image Controller and Deployment
As previously stated, the goal is to have a completely generic base image. However, we need the ability to inject any tenant-specific data at first boot time. While baking the base image, we perform the following tasks:
- Update latest Windows patches and dependencies
- Install the latest XenDesktop product code
- Install monitoring tools
- Configure static VM
In order to deploy a Controller from the base image, we must perform the following post deployment operations:
- Inject customer configuration into the VM
- Connect the VM to a dedicated database server
- Create the XenDesktop site
The goal is to maximize the amount of processing done during the base image preparation as this is a one-time cost as opposed to a cost paid during each tenant deployment/upgrade. Furthermore, by putting more into the base image, we gain test coverage and quality assurance. Our QA team can fully validate the base image prior to deploying in production. This allows our engineering team to focus testing on more important runtime functionalities, and less on install and static VM configuration.
We start with a Controller on version 1 with a matching XenDesktop-Database schema for version 1. This is a fully functional XenDesktop site that is ready to be upgraded.
We bring up a new VM cluster which is on the next XenDesktop release code base. This cluster is based from the latest Single Image Controller base image.
It’s important to note that using additional VMs simplifies the ability to rollback a failed upgrade. This approach is particularly viable when hosting in a public cloud where the cost of a few extra VMs for a short time is much less compared to purchasing extra hardware in an on-premises data center.
Before adding the new Controller cluster to the Site, we take a backup of the Database. This backup provides us the ability to revert back to the initiate state in event of any issues encountered during the upgrade.
We register the new Controller cluster to the Site. These Controllers are expected to be backwards compatible with the previous database schema version.
Although the new Controllers are part of the Site, there is no DNS record (CNAME) directing traffic to the new Controllers.
The database schema still matches the previous release. Prior to updating the schema, we need to detach all Controllers to ensure quiescence.
At this point, we upgrade the database schema to the newer version.
After the database schema has been upgraded, we can restore the connection strings for all services on both the new and old Controllers.
We also run health checks on the Site to ensure the database upgrade was successful.
Upon successful health checks, we change our CNAME in DNS to point to the new Controllers. This will cause all VDAs to seamlessly reference the new Controllers without requiring any reconfiguration. We can then remove the previous Controllers from the Site and delete the database backup.
At this point, we have performed a successful upgrade, which was seamless to end users.
In the event of a failure (during any point in the above procedure), we can simply rollback the upgrade by restoring the database backup and removing the new Controllers.