I was on a consulting engagement with a European customer the other day, and an interesting question came up. In fact, the question sent me researching for an answer. I thought that I would share what I found.
Piggyback Without Oinks
The customer was using the NetScaler Link Aggregation functions for application access reliability as well as capacity purposes. This is common place.
But this time I was asked about controlling NetScaler High Availability Failover in the event of a link failure. In past, I’d seen the link aggregation used to maintain connectivity to one or more external internet/ISP connections for reliability.
Bandwidth Triggered Failover
This question was different. The customer wished to have the NetScaler actually fail over to the backup NetScaler device in the event of a failure of any one of the links to the LACP-enabled switch ports. We had to configure for bandwidth triggered failover.
How To Do This
Some quick research revealed that, in the NetScaler configuration, I can create a Channel object within the NetScaler->Network configuration and specify throughput criteria.
Pretty normal activity, here. I simply add the interfaces I want aggregated. This is a simple activity using the NetScaler Graphical User Interface.
But what I added here was a value in the Throughput field.
In this case, I set it to 1500 mps. This said that for this entity – a channel consisting of two interfaces – the minimum throughput must be 1.5 gbs to be considered operational. In my actual configuration, the NetScaler interfaces are 1 gbps devices, as are the associated switch interfaces.
Since this aggregation consists of only two interfaces, the failure of one of the links would violate the prescribed threshold. This would then cause a failover to occur, and the secondary NetScaler to execute its HA routines and become the primary system.
Needless to say, each of the NetScaler systems should be cabled to discreet switches for optimum reliability.
While you are configuring this, you may also wish to consider some HA implications. Think about setting the Throughput threshold on the backup NetScaler to a lower value.
That way, in the event of single interface failure (it never rains but it pours, right?), the operational NetScaler is allowed to limp along until the original primary comes back up.
Note also, that when you set this up in an HA pair, the creation of the Channel object is not propagated to the backup NetScaler.
This is good, because it allows for different settings to be applied. But it’s not so good if you forget to define it on the secondary NetScaler…
Oh, And One Last Thing…
Lastly, I would be remiss if I did not raise the issue using the NetScaler INC (Independent Networking Configuration) parameter when setting up the NetScaler High Availability.
While this parameter was not required in my specific example, it may be required if the two NetScaler appliances are connected to different network segments, That configuration might require individualized routing algorithms. That’s when INC would come into play.
And an installation that is going to require setting up the NetScaler link aggregation may just require this parameter to be set as well.
Let’s Hear Your Thoughts
As usual, you comments are welcome.
Follow me at Twitter
Or send me email