Citrix Access Gateway Advanced Load Balancing Contingency and High Availability Design Options
Citrix Access Gateway Advanced Edition is a great product, lots of my time is spent designing, implementing and integrating this product usually with a Citrix XenApp backend which includes Web Interface.
One question seems to always pop up though. Is it resilient and what happens if a component of the infrastructure fails?
Let us take a look at the components required to build the infrastructure and what might happen if one fails. We will start at the front end and work backwards from there (as this is what the client hits first).
1. The Citrix Access Gateway Appliance.
This is the VPN concentrator component, it can be used as a direct VPN concentrator and also provides secure SSL encryption for published resources such as Citrix XenApp applications, internal file shares, internal websites, outlook web access and other stuff.
- Options for contingency
NOTE: You can natively load balance (active/active) more than one Citrix Access Gateway Appliance but only when you are using it as a VPN concentrator. It cannot be natively load balanced when used for access to Citrix XenApp published applications and the other internal resources mentioned above.
When providing access via a full VPN client, the client device is told about the other Citrix Access Gateway devices that you may have, so if the client becomes disconnected it will try and connect to the next available appliance if the original is unavailable.
If you have integrated the Citrix Access Gateway with Citrix XenApp and the Advanced Access Control server components and you are providing published applications etc, then it is not natively load balanced. So what can you do about it?
Well, one option is to buy more than one access gateway appliance and use it as a standby device. You can then ensure the configurations are the same which means you can physically replace one with the other. Another option is to buy a second device, ensure the configurations are identical and on the event of a failure, use a NAT rule to redirect incoming traffic to your identical standby access gateway appliance.
Ideally though, you need some automated fault tolerance. The only way to achieve that is to invest in a couple of network load balancing devices that can sit in front of the access gateway devices, detect a failover and then redirect the client as needed. Take a look at the Citrix Netscaler devices.
2. The Citrix Access Gateway Advanced Server Component.
If you have integrated your access gateway appliance with the advanced edition (advanced access controls) then you now have a Windows server which is sat on your internal infrastructure, this server is responsible for rendering the users web pages, performing sophisticated end point analysis scans, applying filters and policies and ultimately granting the user with the right access you have defined in your security policy.
So, a pretty important part of the infrastructure then….
- Options for contingency
Piece of cake, you just have more than one. Load balancing is natively built in to the product in active/active form, users are distributed evenly and migrated in the event of a failure. Even better, you virtualise these servers and also provide a degree of host hardware fail over.
3. The Citrix Access Gateway Advanced Database
Like Citrix XenApp, Citrix Access Gateway Advanced stores all its static configuration in a farm database. All connection polices, administrators, end point analysis scans, logon points, filters, polices and published resources are stored in the database.
So, a critical part of the infrastructure this is…
- Options for contingency
With Citrix XenApp if this database goes offline the Citrix XenApp servers will continue to function and process logon requests because the XenApp servers maintain a local copy of the database.
This is not the case with the database that the Access Gateway Advanced server uses, if this database goes offline then your whole Access Gateway Advanced environment goes off the air until the database server is restored, big problem.
The good news is that you can obviously use a clustered database (typically with Microsoft Cluster Services). This then gives you host fail over with the database.
Some organisations span Access Gateway Advanced environments across sites to provide a form of continuity in the event of a site failure, but at this moment in time (unless someone can correct me), you cannot implement a strategy to syncronise two Advanced Access Gateway databases across locations, nor can you use stretched clusters. So, the only option there is to have a separate installation per site.
4. Citrix Web Interface.
If you are using the default navigation gui (which most people are), then you will be using web interface as a published resource within the access gateway environment. This will be providing the advanced server component with the XenApp published application icons (seen within the users browser) and details required to connect to XenApp servers.
Again a pretty important component that can be easily overlooked….
- Options for contingency
Again, pretty easy but an absolute must. Windows Network Load Balanced can be used to provide a load balanced virtual IP address for your advanced server component to connect to for published applications.
5. Citrix XenApp.
Citrix XenApp has built in contingency, all of the components have fault tolerance built in (if designed/implemented correctly).
End
I have also included a diagram that I completed recently which may be useful.
Regards,
Lee Wynne
Feel free to join me on linkedin





Comment by Alex on 16 August 2008:
Your blog is interesting!
Keep up the good work!