Recently, Epic added XenApp 7.15 LTSR (with Windows Server 2012 R2 VDAs) as a Target Platform for Hyperspace 2015 and 2017! As my colleague Nick Rintalan has said, XenApp and XenDesktop 7.15 is the biggest release in company history, so XenApp 7.15 moving from Experimental Platform to Target Platform is also a pretty big deal.

For the Epic Community Members out there who’ve been waiting to upgrade their XenApp 6.5 environments, the time is now, given that we’ve closed the most important IMA-to-FMA feature gaps in a release you can stay on for an extended period of time, and XenApp 6.5’s End of Life date (6/30/2018) is rapidly approaching.  If you’re on XenApp 6.5 and haven’t started doing so already, you need to begin the design process for 7.15 and start planning your migration — and if you’re on 7.6 LTSR, it’s time to start looking at the new features that 7.15 brings to the table.

As you head down this path, I wanted to highlight what I consider to be the two most important points from the Epic Hyperspace Reference Architecture for XenApp 7.15 LTSR that are “new” (relative to the RA for XenApp 7.6 LTSR and/or XenApp 6.5) and worth paying attention to:

  1. Multiple Sites are Recommended. If you have multiple datacenters and you’ve engaged with Citrix Consulting Services in the last few years, you’ve most likely had us recommend going with (at least) one XenApp Site per datacenter, rather than spanning a single site across multiple datacenters.  While better offline database support is included in the 7.15 release via Local Host Cache (LHC) and significant improvements have been made in brokering performance over greater controller-to-database latencies, Citrix and Epic still recommend a multi-site architecture for failure domain reasons, even though a single site may be technically feasible. At the end of the day, your EMR solution is by far the most important application in your organization, and ensuring uptime is likely your most important job as an IT professional.  While having to configure two Sites with the same settings and keep them in sync is definitely extra work (but fun work if you’re good at PowerShell), you can realize some pretty significant benefits:
    1. No Brokering Downtime During Site Updates/Upgrades. Applying a LTSR CU or the next CR?  That requires a database schema update during which brokering functionality for the site is unavailable.  With a multi-site architecture, you can build an upgrade plan that does not require a brokering outage by shifting users between sites and therefore is way less stressful.  Additionally, in the unlikely event of an upgrade issue, rather than working against the clock to restore service, you have the necessary time to troubleshoot what happened, attempt to remediate, and collect the necessary logs for support, with the other site handling production users.  If nothing else, the change control ticket you submit to conduct the upgrade/update event is going to be less of a hassle, since you can develop a non-user-impacting procedure.
    2. Smaller Failure Domains. If your storage vendor came to you and said that you could put all your enterprise’s data on a single storage array with built-in storage controller redundancy, would you?  I’m guessing the answer is no – we’ve all seen situations where a firmware update goes bad or some catastrophic event happens that takes down a full array.  Why would you treat your XenApp environment tasked with presenting your EMR solution any differently?  With the multi-site architecture, the maximum scope of user impact in the event of a catastrophic failure of the Site database is significantly reduced.
    3. Faster Failover. Rather than waiting for a SQL AoAG to fail over or the LHC to kick in (both of which take some time), in a multi-site architecture, as soon as StoreFront doesn’t receive a valid XML response for an aggregated site, requests are immediately directed to a different aggregated site without user-facing impact (check out Sarah Steinhoff’s amazing blog posts on the subject if you aren’t up to speed).

As Nick Rintalan pointed out, going with a multi-site(/pod) architecture is a business decision weighing risk against cost.  In my experience working with large healthcare organizations, trading reduced risk to the environment’s stability for a little extra work (which, again, can be offset by PowerShell chops) is well worth it in context of the criticality of uninterrupted EMR access.

  1. Using LHC is Recommended. As documented, an FMA-based LHC arrived in XenDesktop 7.12, which has been significantly improved since.  Moving forward, connection leasing will be deprecated, in favor of the LHC, which means that we are recommending it for 7.15 deployments.  There are, however, a few design considerations that aren’t especially obvious to keep in mind when working with this feature:
    1. Controller CPU Resources. The backbone of this feature is SQL Express LocalDB: when the Site database is down and the LHC has kicked in, a local SQL Express database is being used in a similar capacity that the Site Database was used.  SQL Express has a limitation that’s critically important here: it can only take advantage of one CPU socket (and up to 4 cores on that socket).  By default, most hypervisors (including XenServer and vSphere) create virtual machines with a virtual socket per vCPU.  For Controllers in a 7.15 environment leveraging the LHC, make sure that you change that configuration, such that you have one (or at most, two, for larger VMs) virtual sockets, with multiple virtual cores assigned to each socket.  For very large environments, consider using 8 vCPU Controllers, with one or two virtual sockets.
    2. Controller Load and Zone Size. When in LHC mode, only one Controller per zone is handling brokering, XML, and STA functionality.  While it’s unlikely that you’ll reach the published limit of 10,000 VDAs per zone in a XenApp environment leveraging the LHC, your observed scalability will vary depending on logon rate.  For the truly large healthcare systems out there, multiple zones may be required to account for XML scalability considerations.  Hospitals tend to have sneakily high logon rates due to shift changes and the fact that many places have installed Citrix Receiver on tens of thousands of devices, contributing to XML traffic during periodic application refreshes.

In addition to the updated Reference Architecture (which you should give a read, ASAP), make sure you check out this webinar with tips and tricks for making the upgrade to 7.15 LTSR a smooth process!

I hope this was helpful in getting the creative juices flowing as you design your new XenApp 7.15 LTSR Epic Hyperspace environment. If you run into any roadblocks, need some guidance due to a complex set of requirements, or need extra manpower and expertise to accelerate and reduce the risk of your plan/build/deploy effort, Citrix Consulting brings a wealth of healthcare experience to the table and is here to help.

Until next time,

Dan Morgan
Enterprise Architect, Citrix Consulting Services