In the earlier article series Failover (im)possibilities I wrote about the failover/load balancing possibilities in XenDesktop 7.x, where part 5 was about Desktop 7.11. In this article I will discuss the XenDesktop 7.12 release and will also go into a bit more detail what is expected in future releases (where possible).
The king is dead, long live the king
Since XenDesktop 7.x is released as the successor of the XenApp 6.5 product people are asking (almost begging) to have a similar functionality as the Local Host Cache in the XenApp 6.5. Citrix tried it with the release of Connection Leasing in XenDesktop/XenApp 7.6. Connection Leasing was better than nothing, but could not fulfill the request the customers were asking for. Citrix announced at Synergy 2016 that Local Host Cache functionality will become available in the 7.x release. Many people expected that this would be there in the 7.11 release. Unfortunate this version did not have the functionality enabled. However with the release of XenDesktop 7.12 the functionality is now available.
It’s completely new build functionality, so it is not a further development of Connection Leasing. Logically it is not comparable with the XenApp 6.5 Local Host Cache functionality as the framework is complete different. Connection Leasing is also still available in 7.12, but is/will become depreciated functionality (no developments anymore). However when you do a fresh install Connection Leasing is still the feature that will be enabled by default. However when upgrading it will be enabled in the scenario that Connection Leasing is not enabled and the XenDesktop site does not contain more than 5000 VDAs. Other scenarios where Connection Leasing is enabled, will still use Connection Leasing after the upgrade. Enabling/Disabling is done via PowerShell commands, with Get-BrokerSite you can check which of the features are enabled.
Citrix did write a good article about the functionality, also Bas van Kaam wrote a detailed article about this functionality. I’m not going to repeat the whole story, but outline the basics of the Local Host Cache functionality. On Delivery Controller a local database will be created and synced with the XenDesktop Site database. This local database is based on MS SQL Express and does not require any maintenance or back-ups. During normal operations everything works the same as in previous version. The Citrix Broker services (now also called the principal broker) on each Delivery Controller take care of the registration of VDAs (and so on). The synchronization of the database is done via a new service Citrix Config Synchronizer Service, which copies the data and imports the information is the local database. Citrix calls this the secondary broker in their articles and documentation.
In the case the connection to the Site database is lost the principle broker will instruct the secondary broker to start listening and process registration request. All VDAs will re-register with the secondary broker (as no VDA registrations are taken over with this functionality). If you have more Delivery Controllers (with you should have) an alphabetic list will be used to determine which Delivery Controller will be the active Secondary Broker. In other words only one Delivery Controller will handle all VDA registrations. If the Secondary Broker fails, another Delivery Controller will become the active Secondary Broker.
The principle broker will monitor if the connection with the database is available again. If the database is available again the principle broker instruct the secondary broker to stop listening. When the VDA communicates with the Delivery Controller a re-registration process is taken place. Currently the feature can handle up to 5000 VDAs, which sound logical as Citrix also mentions that one Delivery Controller can handle up to 5000 VDAs.
Logically the secondary broker requires resources to function, check the Citrix article for all figures. Also there are some limitations (some examples: no Studio/PowerShell, no anonymous logons, no new assignments to VDIs, no power operation on hypervisor from XenDesktop).
Logically I tried this new functionality in my own demo/test environment. The functionality is working as expected. The current sessions keep running and I could set-up new connection to a XenApp servers via StoreFront (and/or NetScaler). As the article of Citrix did not stating anything about StoreFront connections I removed the Delivery Controller out of the StoreFront configuration, which I expected becoming the active Secondary Broker. Unfortunate this causes that desktops and applications cannot be enumerated anymore (which sounds logical as there is no service available on the remaining Delivery Controllers). So you need to guarantee that the server acting as active Secondary Broker is also included in the StoreFront configuration.
Also the reverse process when the database is available again, functioned as expected.
Portal
Together with XenDesktop 7.12 StoreFront 3.8 is released. Concerning the multi-site settings nothing has changed (as expected, the functionality is there and functioning). It is not directly related to failover possibilities, however the new functionality will make it easier to set-up more portals. The new functionality I’m talking about is the option to hosting different stores on different IIS websites. This makes it possible to host different FQDN on one StoreFront server, currently you needed to create different StoreFront servers. The creation of the stores on different IIS websites functionality is currently only available via PowerShell, after that the store and Receiver for Web can be managed out of the StoreFront console. In the article StoreFront 3.8 is Available NOW! Feng Huang is describing the set-up. Hopefully this functionality will be available in the StoreFront console.
Published App/Desktops & Zones
In XenDesktop 7.11 Zones were reintroduced. This was a major enhancement and it was implemented nicely. Definitely one of the game changes for large organizations which are still on XenApp 6.5. See part 5 or my detailed article Zones in Citrix XenDesktop/XenApp 7.11.
With the introduction of Zones I asked if the application priority for applications (which partly overlaps Zone functionality) will be there to stay. In XenDesktop 7.12 the application priority is still there in the same form, so nothing has changed. So I’m still missing the option to create a two way load balancing option for an application, which also zones is not offering (yet). So usergroup 1 will use Delivery Group 1 as highest priority where usergroup 2 will use Delivery Group 2 as highest priority and vice versa.
The same applies to the Zones introduced in XenDesktop 7.11. The functionality is exactly the same as in the 7.11 release. So we are still missing to regulate the selection of the VDA when the configured default zone does not have resources available. A random VDA from one of the other zones is chosen. I would like to control this as well. Hopefully this functionality will be added in a later release. I have some customers which are using this functionality over multiple data centers.
A new enhancement in XenDesktop 7.12 are Tags. Tags have different purposes like restrict search displays in studio, scheduled restarts of subsets of machines in a Delivery Group and/or restrict the assignment of Citrix policies. Tags can also be used to limit/assign VDA to a specific application or desktop. Personally I think it will be used for applications the most. I have seen customers that some specific applications are installed on a subnet of the machines available for general purpose. Within XenApp 6.5 you could set-up the application properties that only those servers (or better Worker Group) were configured. By using the tagging functionality we reach the same outcome. Although the machines are in a larger Delivery Group only those machines are available for that specific application(set). This is done by adding a tag to the VDAs (can be per VDA or Delivery Group) and the application(group). It is not directly related to failover/load balancing, but one of those features that is used a lot within XenApp 6.5 (in combination with Worker Groups). A nice addition of Citrix to the product. I tested this quickly using the Tag to a desktop Tag within Delivery Group and it worked fine, but remember you also possible limit other failover mechanism using the Tags. Check this Tag article which describes the functionality in detail.
Citrix Provisioning Services
A few days after the XenDesktop 7.11 release also Citrix Provisioning Services 7.12 became available. This version has some cool new enhancements, were streaming of Linux vDisk is the biggest announcement. Remember that is just technology preview only, so Citrix advises not to use it in production. However looking at fail-over nothing has changed. As stated earlier I think my thinking caps are not high on the list (if they are already on a feature list).
Summarization
In this additional fifth article in the series about Citrix XenDesktop Failover (im)possibilities I took a look what XenDesktop 7.12 brought us for failover possibilities. Summarized the enhancement is the introduction of the Local Host Cache functionality in this release. I think this is what people wanted to see from Citrix (at least 95% of the customer base). For the real large infrastructures the 5000 VDA limit can be blocking currently, remember that the active Second Broker will be a single point of contact for both VDAs as StoreFront enumerations.
Other additions are not really directly related to failover and load balancing (multiple IIS websites/Tags) but can help simplifying the XenDesktop infrastructure or create a similar set-up as the XenApp 6.5 infrastructure.
Currently my wish list holds the following items:
-
Application Priority in a two-way method (or moved to Zones functionality)
-
Additional priority levels in Zone for failover zones
-
Different IIS website StoreFront functionality included in the StoreFront console
-
Additional priority levels for Load Balancing in Citrix Provisioning Services
-
LHC supported on 5000+ VDAs infrastructures