Deploying NetScaler VPX on Azure without ALB

The new API means that you do not need the Azure Load balancer.

Hello!

I had a colleague present a session in December on the option to deploy a NetScaler VPX in Azure without an Azure Load Balancer in front of the HA pair. I wanted to share the specifics as you might have missed it. Also, when running another webinar recently, it had a lot of interest!

Assumptions

• I am assuming that your VPX setup will be in active/passive HA.

• Some Azure-specific elements are discussed in this piece. Nothing too heavy!

Background

There are several options for setting up a NetScaler using the VPX form factor, it has its own section in the documentation, and Azure is just one of the many choices offered. That link is here.

The Azure HA deployment, detailed here, has typically followed this approach:

Typical Azure setup for HA NetScaler

I think the first thing that leaps out at you is, why does Azure need a load balancer in front of a load balancer? In the case of ALB-based HA, since the VIP is hosted by ALB there is no need for IP migration from node to node.

The animation below shows how IP migration would work on other Cloud platforms, which is used in failover scenarios on the Public cloud (AWS, GCP). Since the IP migration takes time with the current Azure control plane, there is a reliance on the ALB to monitor the HA pair and divert the traffic upon failover.

This isn’t a massive issue, it is just how the appliances are deployed in Azure. That said, the ALB isn’t ‘free’ to run. The cloud costs will need to factor in the running costs for that piece in addition to the NetScaler costs.

What changed?

Microsoft is in the process of upgrading its Azure API stack, they expect this updated API to be rolled out this year. It will be rolled out in phases, most new VMs will go via the new API. It can also be requested.

So what?

The result of this new API is that you don’t need an ALB. The official docs page is here. It looks like this:

New setup.

There is a pre-requisite for this, obviously you need the new API.

• If the new Azure control plane is not enabled for your subscription, high-availability deployments might experience longer failover duration. In such cases, contact Azure support for assistance in enabling the new control plane.

• Also, new features like this are typically brought into the feature phase of firmware, in this case, that is a 14.1-34.42 or later release.

What is the result?

The main change is that the architecture is simpler, and the cost is less (obviously). This cost calculation could have a bigger difference if you start to look at other services that you might have run in Azure vs running them on NetScaler, as the NetScaler is a fixed cost irrespective of how many firewall rules or services you have. To be clear, this is not a criticism of Azure, it is just a consequence of running in the cloud.

Questions:

1. Question: I have 13.1, will I need to move versions?

   Response: Yes, as stated above, this isn’t going to be added to the 13.1 release.

2. Question: How do I migrate from old to new?

   Response: I would expect this would require a few stages

   1. Check you have the new API enabled on your subscription. If it isn’t enabled, request it.

   2. Check the VPX version includes the support for the feature, if not upgrade the VPX to 14.1-34.42 or later.

   3. Remove the Azure Load Balancer.

   4. Modify the vServer configuration to listen on the secondary private IP addresses and remove any IP set bindings or ALB front IP address configurations.

   5. Test the revised setup to validate.

Summary

Hopefully, this makes sense. There were no ‘cost calculations’ included with this. That said, it isn’t that difficult to work out that running less in the cloud saves money!

Let me know if you have any questions.