Local Host Cache (LHC) allows Citrix Virtual Apps and Desktops users to launch new sessions when the connection between connectors and the control plane is not functioning as expected. LHC works by maintaining a subset of the site database on the Cloud Connectors in each resource location.
For customers leveraging their own access tier with Citrix StoreFront, the LHC feature enables them to provide users with access to their applications and desktops in case of loss of connectivity to the control plane.
What Is Local Host Cache for Citrix Virtual Apps and Desktops?
The easiest way to explain LHC in the context of Citrix Virtual Apps and Desktops is to think of it as an insurance policy that comes into play when, for whatever reason (service interruption, connection issues, etc.), the Cloud Connectors can’t communicate with the Citrix Broker service for 60 seconds. Without LHC, communication breakdown between a resource location and the Broker service could prevent end users from launching new apps and desktops sessions. LHC allows users to launch sessions using a secondary brokering service in these cases.
LHC is a combination of several services and components that come together during an interruption period to take over the brokering responsibilities until the connection to the cloud broker is reestablished. Our product documentation has details on how LHC works and on scaling considerations.
Tips for Using LHC
There are a few common areas where we see customers hit snags. One involves resource locations in LHC mode. Citrix Virtual Apps and Desktops deployments have one or more resource locations where the workloads are hosted. Each resource location, by default, maps to a zone within the service. LHC requires Citrix StoreFront to be able to contact each resource location users need access to. But that alone isn’t enough.
There are a few key configurations to be mindful of when setting up LHC, particularly for sites with multiple resource locations:
- All connectors (to which VDAs register) need to communicate with a StoreFront deployment, You probably saw that “important” note in the eDocs about StoreFront needing to be able to communicate with all connectors in a resource location. Like me, you probably read that the first connector alphabetically takes over first in LHC mode. So why is having all really that important? Well, this is actually a two-way street. The presence of StoreFront traffic is a pre-condition for connectors to know LHC mode is an option. If a connector is not detecting StoreFront communications, it will not evacuate VDA registrations during a failure event, rendering at least a portion of your VDAs unusable during the event and potentially compromising resource availability. You can find detailed documentation on configuring connectivity to StoreFront here.
- The StoreFront configuration matters. Users can launch applications and desktops only from registered VDAs in the zone containing the currently active/elected broker. Launches across zones (from a broker in one zone to a VDA in a different zone) are not supported during an outage. In multi-resource location environments, if all connectors are listed as part of a single site in StoreFront, this can cause challenges. There are two ways to correct this:
- First, if on StoreFront 1912 CU1 or later, enable StoreFront Advanced Health Checking (more info here) via the web.config file. This adds additional granularity to StoreFront’s logic in handling XML responses from connectors.
- Second, if that’s not an option, each resource location can be specified as a separate site in the StoreFront configuration, you can use Site Aggregation to de-duplicate icons as required.
- Don’t forget about remote access. Connectors are also probably serving as your STA in a Citrix Cloud world. To make sure connectors are properly detected as available or not available to handle STA functions in LHC mode, the Citrix ADC has a built-in monitor to detect availability of the broker service on Cloud Connectors including use as a STA for Gateway connections. Learn more here. Other monitors (tcp, ping) may not correctly identify that the STA is unavailable on non-elected Connectors during LHC mode.
- Once the considerations above are addressed, there are a few other key factors worth confirming:
- Connector Sizing: Cloud Connectors should be sized correctly for LHC, understanding that the LocalDB is limited to use of a single socket. Sockets with multiple cores are recommended. One socket with four cores or two sockets with three cores are common configurations. Learn more here.
- Resource Location Sizing: Once connectors have been appropriately sized, confirm that resource locations are also architected within the recommended scale parameters. Learn more here.
- Pooled Desktops: Power-managed Pooled Desktops require explicitly enabling machine reuse at the site and delivery group level to work with LHC. By default, at the time of writing, pooled desktops will enter maintenance mode if this configuration is not adjusted. Server hosted apps and static desktops do not require additional settings or policies. Learn more here.
- Monitoring: There are several key events to watch out for in the Windows Application event logs on Cloud Connectors regarding LHC: Citrix Config Sync Service and Citrix High Availability Service. More information is available here.
- 505: Indicates an issue syncing the configuration, which would prevent LHC mode for working correctly
- 507: Indicates that changes are ignored because the Connector is in LHC mode
- 3502: Indicatess that the connector is in LHC mode
- 3503: Indicate recovery to the primary Broker service
Last but not least, testing LHC is essential to validate that your environment is correctly configured. There is a method to force an outage on a Connector via the Windows Registry. (Get the details here.) Some customers have also used a HOSTS file entry to simulate loss of connectivity to the Citrix Cloud control plane. Be sure your testing also includes external access via Citrix Gateway, where applicable, to confirm STA up/down state is being correctly detected.
I hope this overview will help you to avoid some of the more common configuration challenges we see with LHC in the field. Share your questions comments below.
