Connection Leasing vs. Local Host Cache. Conclusion? CL doesn’t stand a chance!

When Citrix re-released their XenApp and XenDesktop products not that long ago, things changed. XenApp’s Independent Management Architecture, IMA, was no more and got replaced by XenDesktop’s Flexcast Management Architecture, or FMA. With it some of the functionality and features loved and used by many disappeared as well. Features like Sessions Lingering, Anonymous Users, Pre-Launch and a few more, were missed, and for some this even became one of the main reasons not to migrate at that time. Luckily Citrix has again reinstated some of the most popular features known to XenApp 6.5, again, not all, but some, in its latest XenApp release, version 7.6.

Old versus new

What about the Local Host Cache? Yup, still gone! Will it somehow, someday return? Probably not. Is Connection Leasing (CL) a valid replacement? No, is the short answer, unfortunately a lot of people think it is. In its defence, does it help to make XenApp 7.6 the best release up till now, at least since XenApp got introduced into the FMA? Absolutely! I think it’s great what they’ve done, but it’s no LHC. Also, I’ve seen multiple statements that refer to Connection Leasing as a HA feature, but that’s just wrong. Again I agree, it’s a great add-on, but no HA, period. I’m glad to point out that the Citrix E-Docs website does describe it correctly:

The connection leasing feature supplements the SQL Server high availability best practices by enabling users to connect and reconnect to their most recently used applications and desktops, even when the Site database is not available.

For example, let’s say we’ve got Connection Leasing in place and our SQL database goes down, because hey, our SQL cluster didn’t failover properly (that almost never happens :-) if you than need or want to start an application that you normally only use once every three to four weeks, or every two or three months for that matter, it simply won’t work. I’ll go into some more detail on how CL actually works in a minute, scroll down to the ‘What does Connection Leasing actually do’ section if you don’t have clue on what the general idea behind CL is.

Some limitations

I know, most users will only use a few applications on a daily basis, and thus, with Connection Leasing in place they will continue to have access to these applications if the central SQL database might become unavailable. However, once it is unavailable and Connection Leasing becomes active it will automatically replay the cached operations (of the past two weeks by default) as soon as a user tries to launch a new session or re-connect to an recently active session / application, here you need to be aware that there will be two brief moments where new sessions and re-connects won’t be accepted; right after the DB failure when the DC enters LC mode, and when it tries to restore it’s connection to the central Site database once the issue has been resolved. So it will take at least a new session launch or an attempt to re-connect to an earlier active session for LC to kick in. The same applies to assigned desktops. That’s right, assigned desktops! If they’re pooled, CL won’t be available, unfortunately this is one of the most implemented architectures today. This is due to the way Connection Leasing is designed to work, it only caches (personal) assigned resources, fair enough, but worth a mention none the less. So remember, if you don’t have a desktop assigned to you personally and SQL goes down, it also won’t work, and I quote:

Connection leasing is supported for server-hosted applications and desktops, and static (assigned) desktops; it is not supported for pooled VDI desktops or for users who have not been assigned a desktop when the database becomes unavailable.

And of course when the database is down the Administrator cannot use Studio to make any configuration changes or Director etc. but that’s nothing new, we have that problem with IMA as well. Make sure to check out Citrix’s E-Docs documentation page on Connection Leasing, there are some more considerations and limitations that you need to be aware of, you’ll find the link a few paragraphs down. Connection Leasing is enabled by default, but it’s only available as of version 7.6 of XenApp and or XenDesktop. You can disable it using the PowerShell SDK or through the Windows Registry as the E-Docs article will also show you.

With Connection Leasing enabled and active, load management within the Site may be affected. Server-based connections are routed to the most recently used VDA. Load evaluators (and especially, session count rules) may be exceeded.

Since, lately, CL is often compared to LHC, let’s do another one. Local Host Cache speeds up the application enumeration process during logon, with or without a healthy running database. Can Connection Leasing offer something similar? Nope, not at this time.

What does Connection Leasing actually do?

As mentioned earlier, it supplements SQL high availability. With Connection Leasing enabled each DDC, or Controller, caches the users connections to his or her recently used applications and or desktops. This is under ‘normal’ circumstances with the SQL database being available. This is what Citrix has to say about it on their E-Docs documentation page, you can check it out here by the way:

The leases generated on each Controller are uploaded to the Site database for periodic synchronization to other Controllers on the Site. In addition to leases, each Controller’s cache holds application, desktop, icon, and worker information. The lease and related information is stored on each Controller’s local disk. If the database becomes unavailable, the Controller enters leased connection mode and “replays” the cached operations when a user attempts to connect or reconnect to a recently used application or desktop from StoreFront.

By default connections are cached for a period of two weeks (I’m not sure if this is configurable, but I would be suppressed if not). So when the database becomes unavailable, everything that the user has launched within a two week period prior to the database becoming unavailable will be available from the CL cache, as mentioned this goes for server-hosted applications and desktops, and static (assigned) desktops only.

Leases for long-running active or disconnected application or desktop sessions are extended so that they are not they are not considered expired.

What about the Local Host cache?

Within the Independent Management Architecture each XenApp server, with the exception of so-called ‘Workers’ (Workers can’t be elected as a Data Controller, out of scope for now) holds a local copy of the central data (IMA) store. By default, a XenApp server (Data Collectors included) polls the central IMA store, through the local IMA service, every 30 minutes, the information obtained is stored into a local MDB database which is referred to as the Local Host Cache (LHC). Also, when configuration changes are made within the Farm, the Zone Data Collectors will be notified so that they can update their LHC, next, the Data Collectors will notify their Zone member servers so they can do the same. The Local Host Cache stores the following information:

• All servers in the farm, and their basic information.
• All applications published within the farm and their properties.
• All Windows network domain trust relationships within the farm.
• All information specific to itself. (Product code, SNMP settings, license information etc.)

All this ensures that when the IMA Store for whatever reasons isn’t reachable users can continue to work, logon, logoff etc. in fact, if needed the server can be  rebooted while the IMA store is down and the local IMA service will start from the LHC without any issues. It will continue to work indefinitely, although do note that Farm configuration changes are not possible; you simply won’t be able to start up any management consoles. As an added bonus, the LHC is also used to speed up the application enumeration process, XenApp servers can query their LHC without needing to contact their Zone Data Collector.

One on one wrap up

So now that we know how both features work and what they do, let’s do a final comparison to wrap things up. The table below compares some of the main differences between the two features, with and without a reachable database.

One last thing

As explained, Connection Leasing, during normal operations, will cache application related data onto the local disk of a Delivery Controller. It will also cache the worker, or VDA, information for each application and or desktop that the user has last used, it does this on an ongoing basis. Now this is the tricky part, I’m not sure if it will cache multiple possible workers, or VDA’s, that it has come across during the period of two weeks or if it will only cache the last one successfully used. I’m afraid I already know the answer to this one, but since this isn’t documented, I’ll leave it (kind off) open for now.

Some more ‘gotcha’s’ 

This is why, when the central database isn’t reachable and CL kicks in, it can (and probably will) affect load balancing and sessions limit configurations, because for each application it will use the last cached worker (VDA), in other words, the machine that served the application or desktop last. So when multiple users all end up having the same VDA’s cached for certain apps and or desktops, they will always end up on the same machine as long as the FMA database stays offline. Coming back to my comment on not being sure if it will cache multiple VDA’s, if it doesn’t (and I think that’s the case), than in theory, if the database becomes unavailable and if for some reason one or multiple of the cached VDA’s are also offline, well… you do the math. But I guess I’m stretching a bit :-)

Citrix TV video on Connection Leasing : http://www.citrix.com/tv/#videos/12049

Thanks for reading and as always please feel free to comment.

Bas van Kaam

Field CTO EMEA by day, author by night @ Nerdio

Father of three, EMEA Field CTO @ Nerdio, Author of the book Van de Basis tot aan Meester in de Cloud, Co-author of the book Project Byte-Sized and Yuthor of the book: Inside Citrix – The FlexCast Management Architecture, over 500 blog posts and multiple (ultimate) cheat sheets/e-books. Public speaker, sport enthusiast­­­­­­­­: above-average runner, 3 x burpee-mile finisher and a former semiprofessional snooker player. IT community participant and initiator of the AVD User group Community world wide.