Now that Local Host Cache is available for every Citrix Virtual Apps & Desktops service customer: Let’s talk Local Host Cache! To many of you those three words are very important, but in case you are new to Citrix, let me take you through our Local Host Cache journey.

First, what is Local Host Cache or LHC? Our docs team does a great job of explaining it here, but to sum it up in a few words Local Host Cache keeps a copy of your Citrix Virtual Apps and Desktops (previously XenApp and XenDesktop) database to promote resiliency and ensure high availability. It is designed for dealing with outages or connection issues with the database and keeps a local copy of the database on the broker in case the primary database is not accessible.  However, this post is less about what it is and more about the journey it has taken.

In 2017, we introduced the LHC feature into the 7.x platform. Now here we are in 2018 and we wanted to bring LHC to the cloud service to help extend the robustness of the Citrix Cloud Virtual Apps and Desktops service. One of the key reasons we see customers so interested in our cloud services is disaster recovery and high availability. Especially in a hybrid cloud deployment where they are utilizing the Citrix cloud service, yet the workloads are still in the on-premises datacenter. We knew that introducing LHC capabilities within the Virtual Apps and Desktops service would help customers deal with cloud outages and this is where our journey starts.

In Citrix Cloud deployments the VDA thinks the Cloud Connector is the broker. The Cloud Connector is a proxy to the Cloud Broker, but in the event of an outage, the Cloud Connector is able to broker connections by leveraging the LHC feature we host inside of it. The LHC on the Cloud Connector keeps a local copy of the database that remains in sync with the primary database hosted in Citrix Cloud. The system primarily synchronizes the site configuration. In the event of an outage, VDAs re-register to the LHC in the local Cloud Connector and the local DB is able to hold the state of all the VDAs in the on-premises resource location. This allows the Cloud Connector to perform the duties of the Cloud Broker until the connection to the cloud is re-established.

Since the Cloud Connector is managed by Citrix, we can manage/update it just like any of our cloud services. We are also about to roll out new functionality to the Cloud Connector without admin intervention. Staying true to the cloud practices we use for cloud services, we push Cloud Connector updates in a canary or gradual rollout, thereby not every customer gets the new features all at once.

A feature canary rollout allows us to manage the deployment of a feature after the platform update has been completed. While platform updates are frequent and the canary rollout lasts 1-2 weeks, a feature canary rollout can take much longer. We use this mechanism to ensure features behave as we expect and in case of an issue, we limit the impact on you, our customers.

When we felt that LHC in the Cloud Connector was ready, we did just that. We initiated a canary rollout. Unfortunately, we did experience an issue and we had to pull back the feature. Unfortunately, we did not manage it well. It created confusion and concern among our customers. We recognize that and I’m writing this blog to help communicate that we are committed to improving this process.

During the initial stages of the LHC canary deployment, we identified a serious bug that was not present in the traditional, on-premises XenApp and XenDesktop LHC deployment. Keep in mind that while we share a great deal of code between on-premises and cloud, the cloud is sometime different than on-premises. As we analyzed the bug, we recognized that keeping the feature enabled could make things worse. As a precautionary measure, we decided to turn off LHC on the Cloud Connector. One of the cool things about the cloud is having kill switches to prevent things from going bad. But in the process of doing this, we did not communicate clearly what we were doing. We should have done a better job of clearly notifying you of what was happening and sent a notification to your account as to why this was happening. For those of you impacted, I do apologize. I believe that for Citrix Cloud deployments to be successful, we need to work in a partnership where we share the success of your deployment. That requires more communication and transparency in our operations.

The Citrix Cloud Virtual Apps and Desktops team are actively working on the LHC issue and are eager to deliver this new capability out to your, our customers. However, we will communicate with you about this upcoming change both within the administrative console and via email. Even though the team runs through a rigorous testing cycle before rolling out new features, in the event of a future issues with any Citrix Cloud Virtual Apps and Desktops services feature we will make extra efforts to communicate exactly what is happening, why it is happening and how we plan to resolve it in the future.

Thank you for being our partner in delivering a digital workspace.