Leveraging Citrix StoreFront High Availability and Subscription Synchronization
As consultants, engineers, and architects we are regularly challenged with complex scenarios each with their own very specific requirements. These scenarios can really put our skill set to the test and require us to sometimes think outside of the box to achieve our customer’s or companies’ end goal. I have been working with Citrix for nearly 12 years in some form or capacity, with the last 5 years geared primarily towards designing and implementing various Citrix solutions. In my roles as a consultant and architect, I have been tasked with designing and implementing some fairly straightforward, out of the box configurations, as well as some very complex, not-so-straightforward configurations. In all honesty, the latter has been my favorite part of the job…taking a standard design and kicking it up a notch.
In this series of my Citrix Design Challenge, I will be reviewing some of my favorite Citrix Access Layer designs, which truly showcase the true power and flexibility of Citrix.
Customer Goal and Requirements
- Design a multi-site highly available Citrix access solution utilizing StoreFront 3.0 and F5 load balancers.
- The site configuration consists of several sites spanning multiple continents.
- Users should be directed and/or allowed to choose their closest site. F5 Global Traffic Manager is not an option.
- Provide a consistent, seamless experience to the end users across each site.
Challenge Accepted!
With Citrix StoreFront 3.0 and below, there were no real options for multiple sites/zones. The same rang true for XenApp/XenDesktop 7.6 and below, as Citrix had not built this component into its new FlexCast architecture. This meant that to get a truly stable environment with no performance degradation, all of the major XA/XD Infrastructure components would be required at each site. Okay, so we stand up a site at each location, but how do we integrate them so that the user experience is seamless to the end user? What happens if a site goes down? Does the user need to select a new site? Do they need to re-subscribe to their applications? Will the user see applications from every site? These are just a few questions that may come to mind, but they are extremely important as they pertain to the access layer and more importantly to your end users. Enter StoreFront HAA!
Citrix StoreFront has some great components built-in such as High Availability and Application Aggregation (let’s call it HAA from here on out). By leveraging HAA, each StoreFront site could be configured with its local site’s delivery controllers, along with a backup configuration of the other two site’s controllers. In addition, those other two sites would then be configured as aggregation groups, allowing applications from each site to be visible and accessible if the need arose. This meant that a user could log into Site A and see the Microsoft Office Suite of applications. That suite is then aggregated across each site so the user only sees one published version of Microsoft Word as opposed to three. When the application is launched, the application then attempts to launch off the originating site and failover to the secondary/tertiary sites should the resource(s) become unavailable. But how are unique applications handled? Well, aggregation simply aggregates the same pre-configured resources together. Should an application not be part of an aggregation group, it will show up and launch out of its respective site. Pretty cool, eh?
Okay, so we learned application aggregation is pretty awesome but we must also address the multi-site application subscription issue. When you subscribe to an application for the first time, that setting is stored in a flat file on the StoreFront server and synchronized amongst every server in the StoreFront site deployment. This is great for a single site, but we need to synchronize those settings with two other separate StoreFront deployments. Gimme some Subscription Synchronization baby!
Subscription synchronization is yet another built-in StoreFront component, which allows you the ability to create a StoreFront synchronization cluster and synchronization task. With this properly configured, remote StoreFront sites can pull in the user subscriptions on a scheduled timer task. By leveraging subscription synchronization, each site is configured to pull the settings from each other, allowing the user subscribed applications to be “synchronized” amongst each site. Should any of the sites become unavailable, the user could log into the backup site and see their previously subscribed favorite applications. Almost there!
Our last major obstacle is directing our end-users to the appropriate site. With Citrix NetScaler Global Server Load Balancing or F5 Global Traffic Manager, this would be easy peezy. But without these two great technologies, our option are limited. Site-based DNS could be configured in such a way that they point to the load balanced IP address of each site’s StoreFront deployment; however, this would require manual administrative effort to flip the switch should a site become unavailable. As a simple yet effective approach, a new launch page was created on each StoreFront site deployment. The page was pretty bare-bones, containing only a company logo along with links to each site (with a little HTML magic this could be spruced up some more). When a user navigated to the StoreFront FQDN, they were presented with the custom webpage where they could then click on a URL to access their local site. Should the site be unavailable, load balancing would automatically fail them over to the next pre-defined site without the user having to select a new site.
So with a few under-the-hood configurations, each requirement was met and the end goal was achieved.
Challenge presented, challenge accepted, challenge accomplished!