AWS Citrix Netscaler HA Solution

Making Citrix Netscaler highly available within AWS environments sounds less complicated and at first glance easy to implement.

And yet, in the past, it was not that simple.

Why?

Building an HA solution in AWS is quite simple by itself by using AWS Autoscaling.

However, the basic requirements are that the instances themselves are stateless, dynamic configuration, and log data is stored in a central location (S3 Buckets) and that the AWS API can be used natively by the instances.

For a long time, the VPX image versions made available through the AWS Market Place did not meet any of the above requirements.

Many customers, therefore, limited themselves to providing the Netscaler in a single mode.

The Netscalers themselves offer the integrated functionalities to build HA solutions.

So what always worked in classical data centers turned out to be a big problem in AWS environments.

Well? Is there a solution?

Yes, there is!

Citrix has now made improvements and the AWS API-Call functionality has been implemented in the current VPX images from the AWS Market Place.

However, these instances are still not stateless as they still cannot transfer their configurations to S3 Buckets.

So a HA setup works today by the following combination: Use the internal VPX HA functions in combination with AWS API-Calls.

Architecture Example

Deployment of the VPX instances with 3 network interfaces

By default the VPX instances are operated with 3 network interfaces:

— A management interface for the configuration of the Netscaler itself, here ETH/0.

— A client interface for the access of all external accesses, here ETH/1

— A server interface for the transfer traffic client interface to the backend systems, here ETH/2

ETH/1 and ETH/2 are provided in AWS as ENI (Elastic Network Interface) and are additionally bound to the VPX instance.

Deployment Instance Profile (IAM Role) for VPX instances

The IAM role on the VPX instances is required to use the AWS API function.

With the permissions you provide Netscaler can determine your status within the AWS environment and more importantly, you can assign the required Elastic IP yourself in the failover case.

Necessary authorizations:

"Effect": "Allow",
            "Action": [
                   "ec2:DescribeInstances",
                   "ec2:DescribeNetworkInterfaces",
                   "ec2:DetachNetworkInterface",
                   "ec2:AttachNetworkInterface",
                   "ec2:StartInstances",
                   "ec2:StopInstances",
                   "ec2:RebootInstances",
                   "ec2:DescribeAddresses",
                   "ec2:AssociateAddress",
                   "ec2:DisassociateAddress",

Provision of an Elastic IP address

Elastic IP addresses are known to be publicly persistent IP addresses.

We assign the EIP to the client ENI_1 of the first Netscaler instance.

This is important:

Do not assign EIP to the instance! Assign it to the network interface and the assigned internal private IP address to the network interface.

Create IPSet on the Netscaler instances

IPSet corresponds to the HSRP construct from Cisco.

IPSet is configured on both netscalers. Virtual IP addresses, one for each clientENI, are created and assigned to the EIP in the IPSet.

Security Groups VPX Instances

The two VPX instances need the following communication ports to exchange their internal events and health checks

— TCP 0-65500
— UDP 3000 – 3010

This security group should be linked to the ETH/0 (Management Network Interface)

What happens in the case of failover?

In case of an error on the primary Netscaler, the AWS API functionality on the 2nd Netscaler is now used to read the EIP from ClientENI 1. The EIP is then assigned to ClientENI 2 (2nd Netscaler). This process takes less than 20 seconds, user sessions survive the failover without problems and do not abort.