Monday, July 13, 2009

Access Gateway Enterprise Edition with GSLB for XENAPP or XENDesktop

By: Rick Rohne


Gaining High availability for XENAPP across geographically separated sites has always been a challenge, especially when you are talking about connecting over the Internet and you have little control. Citrix Netscaler offers the GSLB option which helps overcome these challenges.

Overview



Daniel Feller from Citrix has written a great article explaining the differences between the different physical and logical site layouts in a XENAPP Environment. I encourage you to read it if you are considering deploying XENAPP or AGEE with Multiple Site redundancy. Click here to read the article. I wanted to take just a minute to point out some things you shoud consider in a multi-site configuration.

Active/Passive GSLB with ICA Proxy

An Active/Passive ica proxy configuration is very straight forward. All users are directed at one site, while the other site sits and waits until the primary site goes down. This is by far the easiest configuration to go with. You should still consider having dedicated Web Interface Servers at each site and if possible, have a XENAPP Site configured for both locations.

Active/Active GSLB with ICA Proxy



Active/Active is the second option. This configuration makes both sites hot and relies on DNS queries to equally load users to both sites. Once the user is connected, the source IP persistence is used to keep the connection stuck to the site the user first came in on.

While Active/Active GSLB is desired, there are some challenges. For instance, when we discuss typical GSLB, we are usually talking about Web Browsers. Web Browsers have the tendency to cache the DNS names which really makes GSLB persistency a piece of cake (And failover a night mare). The ICA protocol and most every other application in the world honors DNS, so if the IP address changes mid stream, then the protocol will automatically begin connections to the new IP address. In many scenarios this breaks the ICA connection and really ticks off end users.

To work around this, consider using Wild Card certificates with a user FQDN and two site based FQDN's all matching the wildcard certificate.

example:

Certificate = *.GSLB.com

AGEE Site = AGEE.GSLB.com / IP = balanced between 1.1.1.1 or 1.2.1.1

SiteA = siteA.GSLB.com / IP = 1.1.1.1

SiteB = siteB.GSLB.com / IP = 1.2.1.1

While the Browser access the main site AGEE.GSLB.com, each web interface in their respective site should be configured with ICA proxy settings to their respective site. This ensures that ica proxy always stays connected to the same site even if the client resolves a different AGEE IP address.

Site Dedicated Web Interface Servers for AAC mode


Each site needs to have it's own Web Interface servers if you are using Access Gateway Enterprise Edition with Advanced Access Control Authentication. This is because the Web Interface server must "Always" communicate back to the same AGEE Vserver that the user first came in on. I generally control this by configuring hosts files on the WI servers to always resolve the local site AGEE VServer.

Use Netscaler Monitors

Netscaler and AGEE come with default monitors that can monitor your XENAPP, XENDESKTOP, or Web Interface servers. These monitors should be configured at the Load Balancing Service level and the GSLB Service level. Using real monitors allows your Netscaler configuration to be a little smarter and can determine a server outage, or even a site outage.

Use DNS Views



DNS views can be configured to provide the correct DNS answer for internal vs. external communication. DNS views are DNS policies that simply look at the source IP of the DNS server that is making the query. If the query is coming from the internal network, the Netscaler will answer with an Internal IP address. if it's coming from anything else, it answers with the external IP address. DNS views are a great way to allow for the XENAPP plugin to connect direct when laptops are local, but connect Gateway Direct when users are on the Internet.

Use Static Proximity



Static Proximity is a configuration in the Netscaler that looks at the source address of the client DNS server and forces the client to the appropriate site. This is great when you have multiple XENAPP sites and you would like to limit the distance from the client to the correct site.

Summary



In summary, GSLB is a great tool to add value and high availability to your XENAPP or XENDESKTOP farm. There is a lot of information out on the net that can help build a sound environment.


More information on Access Gateway Enterprise

3 comments:

  1. Thanks for Great info. It is amazing to me that even in 1013, this article has more useful info in it than all of the info available on the Citrix web site.

    Thanks

    ReplyDelete
  2. Thank you for this incredibly informative article. You've given a lot of useful information.

    ReplyDelete
  3. Well, it requires a lot. thank you for sharing, but I think that I'll need the way more help to deal with it.

    ReplyDelete

Microsoft Virtualization, Citrix, XENServer, Storage, iscsi, Exchange, Virtual Desktops, XENDesktop, APPSense, Netscaler, Virtual Storage, VM, Unified Comminications, Cisco, Server Virtualization, Thin client, Server Based Computing, SBC, Application Delivery controllers, System Center, SCCM, SCVMM, SCOM, VMware, VSphere, Virtual Storage, Cloud Computing, Provisioning Server, Hypervisor, Client Hypervisor.