As Cris mentioned in his blog post on Monday, the Citrix engineering teams are continuing to add features to XenApp and XenDesktop to make the new FlexCast Management Architecture (FMA) more resilient and provide a better user experience. One of the most requested when transitioning from IMA-based XenApp releases to FMA is additional support for database high availability (HA). Citrix customers have asked for a way to ensure that end users can always access their desktops and apps, without depending solely on the HA features built into SQL Server.
The IMA architecture used in XenApp 6.5 and earlier provided a local host cache (LHC), which is a Microsoft Access database running on each XenApp server that mirrors data from the primary SQL data store. The LHC is used when brokering sessions for desktops and apps, ensuring that users can continue to log in, even if the SQL data store is unresponsive.
The FMA architecture introduced in XenDesktop 5.0 and XenApp 7.5 instead relies on the high-availability features of the SQL Server itself. If the SQL Server fails for any reason, users with existing sessions are not impacted, but launching new desktops or applications requires the SQL database. For now, it is highly recommended to deploy SQL clustering, mirroring, or another HA technology.
The IMA and FMA architectures are substantially different. In particular, the differences in their usage of SQL significantly impacts both their scalability and their possible approaches to HA. IMA used the database only to store static configuration data. Database changes were infrequent, so each change could be replicated out to the LHCs of every server in the site. On the other hand, FMA allows a site to be scaled out by using the database to store both configuration data and dynamic information, such as user sessions and VDA registrations and load. Thus, the frequency of changes is drastically higher, and FMA must take a new approach to HA.
FMA’s Solution: Connection Leasing
Connection Leasing is a new feature under development for future releases of XenApp and XenDesktop. Its purpose is to mitigate the impacts of a database failure and ensure that users of site can continue to connect to their most frequently used apps and desktops under any circumstance.
Leasing works by caching the results of successful brokering operations and using this cache as a failover in the event of a database failure. During normal operations, each desktop or app launch generates a “lease”—an XML file containing the VDA’s address, application paths, and any other details stored in the database necessary for the session launch. In many ways, a lease resembles much of the data in an ICA file. The leases are then replicated among the controllers in the XA/XD site and cached on the local disk of each controller.
A lease maps the user, resource, and (optionally) the client device from which the connection was launched to all the details needed to broker a connection. If an FMA controller is unable to reach the database, it will check its local lease cache for the user and resource pair, and broker the user to their last-used VDA. Leases also have an expiration date—14 days by default. This means that as long as a user has launched a particular application or desktop within two weeks, they will continue to have access to that resource, regardless of the health of the FMA database.
Like IMA’s local host cache, FMA’s connection leasing provides for the high availability of end-user connections; however, management consoles and SDKs still require database connectivity to function. Thus, a highly available database, like clustering, mirroring, and always-on, is still recommended.
Leasing will be supported for connections to desktops and apps hosted on Server OS VDAs, providing the same level of functionality as the LHC in XenApp. As leasing is an improvement on the FMA architecture, it has the additional benefit of supporting desktops running on an assigned (but not pooled) Desktop OS VDA, including Remote PC Access.
Stay tuned, as we plan to share updates on our progress in future blogs.