Citrix Blogs

Active/Active GSLB for XenDesktop – A Practical Approach (Part 1)

Eric Jurasinski

We often encounter customers with business continuity goals which require XenDesktop user VMs to be available to users in the event of a full site failure.  A passive DR failover configuration is often not desirable because customers want to be able to leverage their hardware investment in a secondary data center.  This leads to requests to architect a XenDesktop environment with active/active data center capability leveraging Global Server Load Balancing (GSLB) for XenDesktop.  Using Citrix NetScaler, it’s quite easy to run through the wizard driven interface and create a GSLB active/active XenDesktop environment that will send users to one data center or another based upon proximity, fastest response time, availability, etc… However, there are two big catches… How do we handle the user data and how do we find disconnected sessions across multiple data centers?

Well, the user data is easy as there’s data replication for that, right?  Sure there is, but it’s not instantaneous – replication could take hours, not seconds.  And what about file lock issues?  What’s going to happen when the user’s profile or documents are out of date?  What’s going to happen when they log in during the morning and get a desktop from one data center, log out at lunchtime, and then log in and get a desktop from another data center in the afternoon?  For an in-depth review of the many considerations around active/active XenDesktop deployments, see XenDesktop, GSLB & DR – Everything you think you know is probably wrong! written by my colleague Martin Zugec.

My colleague Dan Allen and I have recently had to design active/active XenDesktop deployments for several customers.  In this blog I will walk you through how we approached the design and successfully implemented the active/active solution.

So how do we deliver desktops to users in an active/active GSLB deployment?  We ultimately create two separate active/passive deployments and assign the users to a preferred active data center, dividing users equally by Active Directory groups.  In this configuration, users that are “homed” or assigned to Data Center 1 will always receive a desktop in Data Center 1 unless it is unavailable.  Likewise, users that are “homed” to Data Center 2 will always receive a desktop in Data Center 2 unless it is unavailable.  If neither data center is available… well we’re probably experiencing the zombie apocalypse and we all have bigger problems than desktop availability.  😉

This article will provide the high-level design and explain the key configurations to enable active/active GSLB for XenDesktop pooled desktops using Citrix NetScaler in a “homed user” configuration.  Also, stay tuned for Part 2 of this series which will provide more in-depth details and sample templates to help you quickly get a baseline configuration up and running. Finally, this article assumes the reader is already familiar with XenDesktop, NetScaler, NetScaler Gateway, and NetScaler GSLB concepts.  If a refresher is required, I recommend reading through these references before proceeding:

NetScaler Global Server Load Balancing Primer
Creating Groups for LDAP Group Extraction
 Deployment Guide ICA Proxy for XenApp – Access Gateway Enterprise Edition
Getting Started with XenDesktop 7

Before I jump into the specifics of this configuration, I have to give credit to my friend and colleague, Dan Allen for his thought leadership and guidance along the way.  Additionally, my core focus is as a Senior Architect for virtualization, not networking.  I’m sure there are many super smart NetScaler gurus out there that can suggest several alternative approaches involving Content Switching, AAA vservers, custom monitors, etc.  This article is covering one approach that uses the basic building blocks of server load balancing and GSLB which can be implemented by Citrix virtualization admins with a medium to advanced skill level.  It also assumes that all users are accessing pooled desktops.  With that, let’s get started…

Approach

The approach outlined in this article can be used with or without ICA proxy through the NetScaler Gateway.  For the purposes of this document, the configuration will assume ICA proxy is desired; however, if this was an internal deployment without ICA Proxy, nothing would fundamentally change with the design as NetScaler Gateway would still be used as the entry point.  If ICA Proxy is not desired, then simply configure the Web Interfaces sites as Direct for the access method but still keep the authentication at Access Gateway. Additionally, because we are going to direct users to a “preferred” or “home” data center based on group membership, NetScaler needs to know who the user is and what groups they are a member of.  Therefore, authentication must be performed at the NetScaler and group extraction will be used to determine the user group memberships.  Explicit authentication of users to Active Directory (single domain) is also assumed; however, multiple domains and Smart Card authentication will also work as well.  Finally, this approach will not work with Web Interface Services sites (PNAgent functionality).  For implementing highly available access to applications delivered via StoreFront, there are new StoreFront specific features that can be leveraged, but that is a conversation for another day!

Building Blocks

The following configuration items will be used:

Architecture

The following diagram illustrates the high-level architecture and main components (right-click and save image for a high-res version):

  • Diagram 2

    • Important Note:  NetScalers participating in a GSLB configuration do not share/replicate user authentication information.  However, multiple NetScaler Gateway vservers on a single NetScaler appliance will have access to user authentication information.  As the user access flow traverses the architecture illustrated above, it is important that any and all processes needing to verify user authentication be directed back to the same NetScaler appliance / HA pair that authenticated the user.  This includes desktop enumeration and desktop launch processes.  This is the reason for multiple NetScaler Gateway vservers and multiple Web Interface sites that differ only by which Callback vserver they use.

    Let’s break down this diagram and discuss how the pieces fit together.  We will use several examples.

    Scenario 1: A DC1 user is traveling and is closer to DC2.

    1. A DC1 user opens a browser and enters https://desktop.company.com.
    2. NetScaler provides active/active GSLB for the NetScaler Gateway configured at that address and sends the user to the vserver at DC2 as it has the fastest response time.
    3. The user enters their username and password and initiates a logon to the NetScaler gateway at DC2
    4. The NetScaler Gateway vserver authenticates the user via LDAP and performs group extraction. A NetScaler session policy/profile is bound to the DC1 group.  The session profile is configured to perform SSON to the vserver for Web Interface at DC1.  The full path to the Web Interface site in DC1 specifies a site configured to use the callback vserver in DC2.  For example, https://dc1-web.company.com/citrix/dc2.
    5. The Web Interface site in DC1 communicates with only the configured XenDesktop site(s) in DC1 and the list of desktops in DC1 is retrieved.
    6. The user selects from one or more available desktops to begin the launch process.
    7. Web Interface creates and delivers to Citrix Receiver on the user’s endpoint a launch.ica file.  If this is internal without ICA Proxy, the user connects directly to the IP address of their desktop in DC1.  If ICA Proxy is desired, the DC1 Web Interface site is configured to use dc1-desktop.company.com as the gateway server for ICA Proxy.
    8. As long as the NS Gateway at dc1-desktop.company.com is available, the user’s connection is now routed entirely through DC1 even though the initial connection was made to DC2 from a GSLB perspective.

    Scenario 2: DC1 user is close to DC1, but DC1 is down.

    1. A user opens a browser and enters https://desktop.company.com.
    2. NetScaler provides active/active GSLB for the NetScaler Gateway configured at that address and sends the user to the vserver at DC2 as it is the only one up.
    3. The user enters their username and password and initiates a logon to the NetScaler gateway at DC2
    4. The NetScaler Gateway vserver authenticates the user via LDAP and performs group extraction.  A NetScaler session policy/profile is bound to the DC1 group.  The session profile is configured to perform SSON to the vserver for Web Interface at DC1, but DC1 is down.
    5. The NetScaler detects that DC1 is down and instead of trying to communicate with a Web Interface server in DC1, it uses a Web Interface site in DC2 as the backup vserver.  The backup Web Interface site in DC2 is configured to use the NetScaler in DC2 as the callback for authentication.  The Web Interface server in DC2 communicates with XenDesktop sites in DC2 and only desktops from DC2 are presented to the user.
    6. The user selects from one or more available desktops to begin the launch process.
    7. Web Interface creates and delivers to Citrix Receiver on the user’s endpoint a launch.ica file.  If this is internal without ICA Proxy, the user connects directly to the IP address of their desktop in DC2.  If ICA Proxy is desired, the DC2 Web Interface site is configured to use dc2-desktop.company.com as the gateway server for ICA proxy.
    8. Even though the user is a DC1 user, he is now connecting to a desktop in DC2 through NetScaler Gateway at DC2.  Failover was seamless for the end user.

    Process Flow Diagram

    There are several additional scenarios that could be encountered. In all of the scenarios the high-level workflow is as follows:

    The following diagram illustrates the step-by-step process described above (right-click and save image for a high-res version):

    Note: Short names are used to keep the diagram manageable; therefore:
    dc#-desktop.company.com = DC#-ngICA
    dc#-callback.company.com = DC#-ngAAA

  • Diagram 2

    • Summary

    Active/Active GSLB for XenDesktop can be implemented by homing users to a preferred data center using LDAP group extraction.  Having users first authenticate at NetScaler gives us the power to direct users to the appropriate data center and make intelligent decisions on how to find an alternate data center when outages occur.  Creating a successful active/active desktop solution requires using pooled desktops and keeping the Web Interface and XenDesktop stacks isolated to one data center only.  In other words, do not aggregate XenDesktop sites from multiple data centers into a Web Interface site.  Finally, combining this with Dan Allen’sXenDesktop – High Availability & Load Balancing Add On for Web Interface!results in a very resilient solution that provides desktop fault tolerance at every level.

    The primary goal with this approach is to simply ensure that a user will always be able to launch a pooled desktop.  This solution can be combined with persistent desktops as well.  However, what we typically recommend for persistent desktops is that users always have a pooled desktop to fallback upon.  Persistent desktops are notoriously unreliable and you should always have a fallback mechanism.  For example, you could assign a user a persistent desktop in DC1, but also allow them to access pooled desktops as a fallback. If their persistent desktop in DC1 is unavailable, they can launch a pooled desktop (or XenApp hosted desktop) from DC1 as a fallback.  If all of DC1 is unavailable, then they will automatically be presented with a pooled Desktop from DC2.

    This solution does not address the user data and application challenges associated with the back-end data that Martin discussed in his blog that was referenced at the beginning of this article.  However, it does ensure that a user will always be able to logon to a desktop via XenDesktop.

    Stay tuned for Part 2 in this series where we dive into greater technical detail with the NetScaler and Web Interface configurations and show you exactly how to implement the design detailed in this post!

    Exit mobile version