Understanding the Limitations of the new XenDesktop 7.12 Local Host Cache

For several years now, one of the defining differences between XenApp 6.5 and XenDesktop 7.x has been the absence of the Local Host Cache. As a refresher, LHC was used to keep a local copy of the database on each XenApp server to insure that in the event of a database outage your farm would continue to function.  That’s all well and good when every XenApp server in a farm essentially had the brains to run itself off that local copy! Unfortunately in this case times have changed, and an individual VDI or VSI now merely has the limited guts it needs to broker sessions.  All the true heavy lifting is now handled by the Delivery Controllers.  And those, as you probalby know, are COMPLETELY reliant on SQL being available.  Yes, Citrix provided a partial solution with Connection Leasing.  That has serious limitations however, and I didn’t see it get a ton of use.

So after thinking long and hard about the problem, the Citrix team has come up with an interesting (albeit somewhat limited) solution.  The new LHC methodology allows connection brokering to continue to occur when there is a disruption in the connection between the DDCs and the SQL databse OR between the local network and the Cloud Control Plane if you are using the Citrix Cloud.  Please note though this important caveat… LHC is NOT a replacement for a highly available SQL infrastructure.  That should always be your first line of defense in keeping your Site highly available.  As you will see later in the post, there are some limitations and concerns that LHC cannot address.

So what is the actual solution?  Essentially, one of your brokers in a Site (or potentially in a Zone) will fill the role of a Secondary Broker.  That Delivery Controller will run a local SQL Local Database that maintains a limited copy of the Site Data to allow users to continue to broker.  Let’s take a look at how it works under the covers.

Normal Operation

When you have the LHC role enabled in 7.12 this is what a normal broker attempt looks like:

  1. The User requests a session from StoreFront.
  2. StoreFront queries a DDC in it’s list using the Broker Service from the Primary Broker.
  3. The User is connected to their session via the VDA after talking to the Site database.
  4. Every 2 minutes a query for changes is run on each Broker’s configuration.
  5. If any changes have occured (config changes, machine assignments, etc) ALL data is written by the CSS to the Secondary Broker that is running the LHC Local Databse.  The LHC database is recreated every time a change is detected.

LHC Failure Scenario

So let’s see what happens when the DDC can no longer communicate to the SQL Databases.  Prior to LHC, your entire Site would be down.  Now it works like this:

 

  1. The link to the Database dies.  The Primary Broker Broker Service realizes there is a problem and stops accepting StoreFront requests.
  2. The DDC instructs the Secondary Broker to start listening for and processing requests.
  3. ALL VDAs in the Site are re-registered with the Secondary Broker ONLY during the outage.
  4. All brokering of sessions happens from the Secondary Broker.
  5. The Primary Broker Broker Service watches for the connection to be restored.  When that happens, the Secondary Broker is told to stop listening.  The next time the VDA tries to communicate it will re-register.  Over time all registrations are removed from the Secondary Broker and it resumes the role of updating the LHC Local Database.

So That Sounds Great!

And is it!  It’s a huge improvement over Connection Leasing.  But let’s talk about some of the obvious caveats!

  • ALL registrations and brokering are going to a single Delivery Controller now.  If you have a farm of a significant size that’s going to be an enormous hit to handle on one DDC.  Citrix recommends not using LHC unless your site is under 5,000 machines because a single DDC will not be able to handle more.
  • No data is written back from the LHC to the SQL Datastore.  Whatever happens during that outage is transient.  You cannot use Studio, PoSh, etc;
  • Machine power status is unknown and you cannot power manage your machines.
  • If you have a Delivery Group marked Shutdown After Use, those machines are ALL placed in Maintenance Mode.  The LHC has no way of knowing when a “dirty” (or used) machine has come back up as good.  This means that in 99% of cases, non-persistent VDI will not be supported in this new LHC model.  – IMPORTANT NOTE – If you use a different method to reboot such as AppSense logoff scripts, your pools will remain just fine in LHC.  This only applies to machines Citrix tries to shut down after use.
  • You cannot make new machine assignments during an outage.

There are a couple of other concerns, and I suggest you read the complete articles from Citrix on LHC.

 

Broker Election

In a site with multiple Delivery Controllers, they actually elect a Secondary Broker based on an alphabetical list of DDC FQDNs.  If the chosen Secondary Broker goes down a new Secondary Broker gets elected.  All other peer Secondary Brokers reject connections during an outage unless they get elected.  For Sites with Zones this process actually occurs in every Zone individually but the Secondary Brokers do communicate across an independent channel and maintain Site information for ALL zones in the Site.

 

Resource Requirements

Because they now have to support the LHC database AND have to potentially support all VDAs in the Site registering to them (and because any of them potentially could become a LHC server) your DDCs need to be resized.  Personally I recommended to increase the RAM size 4GB on each as a precaution.  The longer the outage the greater the RAM utilization.  Additionally, SQL Local Database is limited in CPU capability to 1 socket and 4 cores.  Depending on how you size your Delivery Controllers it could put a strain on the DDC acting as the LHC.  Make sure to provide enough resources in case of a failure.  There is also increased storage and IOPS consumption for the LHC host based primarily on the number of logins per second and the length of the outage.

 

Enabling Connection Leasing

So with all that said, now you want to actually turn it on right?  Well, you have three scenarios:

  1. You are installing a brand new 7.12 Site.  By default, LHC will be disabled and Connection Leasing will be enabled.
  2. You are upgrading a 7.x Site. IF Connection Leasing was disabled prior to upgrade, Local Host Cache will be enabled.  If not it will be disabled.
  3. If your Site contains more than 5,000 machines Local Host Cache is disabled regardless of your Connection Leasing status.  Fun times!

But Paul, I thought you said LHC was better than CL?  I certainly did, and it certainly is!  I’m not sure why Citrix went this route.  But if you want to manually enable LHC do the following from the Citrix PoSH:

Set-BrokerSite -LocalHostCacheEnabled $true -ConnectionLeasingEnabled $false

If you wanted to check your LHC setting do a Get-BrokerSite and validate that LocalHostCacheEnabled is True.

 

Another very good tip directly from the Citrix docs:

Force an outage – You might want to deliberately force a database outage:

  • If your network is going up and down repeatedly.
  • Forcing an outage until the network issues resolve prevents continuous transition between normal and outage modes.
  • To test a disaster recovery plan.
  • While replacing or servicing the site database server.

To force an outage, edit the registry of each server containing a Delivery Controller. In HKLM\Software\Citrix\DesktopServer\LHC, set OutageModeForced to 1. This instructs the broker to enter outage mode, regardless of the state of the database. (Setting the value to 0 takes the server out of outage mode.) In a Citrix Cloud scenario, the connector enters outage mode, regardless of the state of the connection to the control plane or primary zone.

There’s more stuff on Citrix about monitoring LHC, adjusting the SQL sizing, etc;  But hopefully this gives you the basics of the new LHC and what it can (and can’t) do.

, , ,

One Comment

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">