Citrix NetScaler… The basics continued, part three. High Availability!

I think we are all familiar with the term High Availability, or HA in short. It simply means that if a single machine or system fails we will have another equally configured system, or multiple, in standby mode or actively participating a.k.a. active / active, ready to take over when needed. This way we won’t loose any of the functionality that the failing, or failed, machine was providing us with. Which in the case of the NetScaler could be anything from a Gateway to Load Balancing, SSL offloading, Content Switching and more. Needless to say that the Citrix NetScaler has some nifty build-in HA capabilities as well.

Other (related) articles from these series include:

1. Citrix NetScaler Gateway, the basics!
2. Citrix NetScaler (10.5) licensing. What’s new with Access Gateway!
3. Citrix NetScaler… The basics continued, part one. VIP’s, Monitors and other objects!
4. Citrix NetScaler… The basics continued, part two. Static routes, SNIP and MIP!
5. Citrix NetScaler… The basics continued, part four. What about SSL?
6. Citrix NetScaler… The basics continued, part five. Global Server Load Balancing!
7. Citrix NetScaler… The basics continued, Part six. Content Switching!
8. Citrix NetScaler… The basics continued, part seven. Split Tunneling!

They come in pairs

NetScaler HA, meaning at least two and max 64, NetScaler appliances (these could be VPX’s just as easy by the way), is also known and referred to as a NetScaler HA pair (although there can be more than two of course). In the case of NetScaler HA one node will always be primary and active, while the other node(s) will be passive and marked as secondary. The secondary node(s) will send a continues stream of so-called heartbeat messages (interval is configurable) checking to see if the primary device is active and accepting connections. If it fails to respond, and after multiple retries, the, or a, secondary node will take over, which is referred to as a failover. I’ll refer to NetScaler HA as a pair from here on, which is a very common setup.

Some considerations

Before having a look at some of the NetScaler HA pair characteristics, I’d first like to point out some specifics to consider when thinking about implementing NetScaler HA. These are also listed on the NetScaler E-Docs pages so I’ll just pick out a few.

1. Different NetScaler models cannot be paired, the model and make of both NetScaler appliances must be equal.
2. Both NetScalers must run the same software version, licenses included.
3. The configuration files (ns.conf) on both appliances must be identical with the exception of the NSIP addresses and the id’s and IP addresses of the other HA node, one is pointing to the other in a HA configuration.
4. There are a view more specific things to consider, check out the link above.

HA specific

1. As mentioned, within a NetScaler HA pair one of the two appliances is always leading, also known as the primary node. As such, the primary node is responsible for, and will handle and manage, all incoming traffic with regards to any virtual servers that might be configured as part of the HA pair setup and all the VIP’s, SNIP’s and MIP’s that come with it including all other features that might have been enabled / configured, basically just a ‘normal’ NetScaler does.

2. Both machines will have their own unique NetScaler IP address, or NSIP in short. Although these IP addresses can be used to individually manage each NetScaler appliance, you need to be aware that within a NetScaler HA pair all management and configuration tasks are, or need to be, done on the primary node only.

3. Here I would like to note, something I also mentioned in one of my earlier articles, that we can also enable management on one of the Subnet IP addresses. If we do this when dealing with a NetScaler HA setup, the system will always lead us to the primary node of the HA pair, can’t go wrong.

4. In a HA pair all changes made on the primary node will automatically replicate (which is enabled by default) to the secondary node, note that this is one way traffic only. This will include all SNIP’s (routes) and interfaces, MIP’s, VIP’s, Static Routes, policies, monitors and all other types of objects and configuration settings you can think of.

5. By default, on the High Availability configuration page within the NetScaler management console of each node, synchronisation can be manually initiated as well and is auto triggered when a secondary node has rebooted or when the primary node becomes secondary after a failover. When synchronization is manually forced from the secondary node it will synchronize its configuration to the primary node overriding its current config. Something you need to be careful with.

7. As quoted from the E-Docs: After a failover, all clients must reestablish their connections to the managed servers, but the session persistence rules are maintained as they were before the failover. Note that you can also manually initiate a failover to test you setup or for maintenance purposes for example, as mentioned above.

When enabling HA

I probably don’t have to tell you this, but before making any major configuration changes to your NetScaler (HA pair), make sure to back-up your current configuration and store it somewhere safe.

Also, I just mentioned that all configuration changes made on the primary NetScaler will automatically get synchronized / replicated to the secondary node once it is in place. When creating your HA setup (enabling HA) and adding in a second node you might want to take some additional security measures to prevent the config of your primary node from being overridden in the case something goes wrong.

When creating an HA pair you normally would logon to the node you want to make the primary node, VPX-1 for example, and then add in the secondary node, VPX-2, from the High Availability configuration page (create HA node) by filling in the IP address and the accompanying user name and password of the remote node. Once you click OK the auto replication mechanism will kick in, synchronizing the secondary node with the primary one.

But wait…

Before you do that you might want to configure each node individually, changing the High Availability Status, starting with the secondary node to stay secondary (remain in listening mode) and the primary node to stay primary. Both can be found on the High Availability configuration page as well. Now if something goes wrong or you make a mistake when actually enabling HA, you don’t have to worry about the secondary node potentially overriding your primary node.

After the HA pair has been created and synchronization is successful you can change the High Availability Status of both nodes back to the ‘Enabled’ (actively participate in HA). You need to do this on each node separately. Also note that both ‘Secondary node will fetch the configuration from primary’ (HA Synchronization) and ‘Primary node will propagate configuration to secondary’ (HA Propagation) are checked to ensure proper synchronization operations.

From a visual perspective it would look something like this:

Thanks for reading. To be continued…

Bas van Kaam

Field CTO EMEA by day, author by night @ Nerdio

Father of three, EMEA Field CTO @ Nerdio, Author of the book Van de Basis tot aan Meester in de Cloud, Co-author of the book Project Byte-Sized and Yuthor of the book: Inside Citrix – The FlexCast Management Architecture, over 500 blog posts and multiple (ultimate) cheat sheets/e-books. Public speaker, sport enthusiast­­­­­­­­: above-average runner, 3 x burpee-mile finisher and a former semiprofessional snooker player. IT community participant and initiator of the AVD User group Community world wide.