This post has already been read 11080 times!
I wrote an article in the Citrix User Group Community, where I highlighted deploying a single NetScaler in Azure to provide some resilience for a Citrix Cloud Solution.
I promised a follow up at the end of the article and here it is.
I have decided to highlight how to deploy a NetScaler Gateway In Azure using Active/Passive mode and a multi NIC Configuration using high availability.
The Azure Market Place has a ready to go template to help you deploy this solution.
It will deploy the following –
- 2 NetScaler’s
- 1 Azure Load Balancer
- 6 Network Security Groups
- 6 NICS
- 3 Public IP’s
- 1 Availability Group
- 1 storage account
Have the Gateway IP PIP (Public IP) already defined. This way you can sort out your external DNS before template deployment and simply add the public IP to the Azure Load Balancer. More on this later.
You can create the resource Group/Subnets beforehand if you wish. You need 3 subnets, or the template will create 3 for you.
Search for the NetScaler template on the Azure Marketplace.
The template outlines the following –
Citrix NetScaler 12.0 High Availability (HA) Azure Resource Manager (ARM) template is designed to ensure easy and consistent way of deploying NetScaler pair in Active-Passive mode. This template increases reliability and system availability with built in redundancy. This ARM template supports Bring Your Own License (BYOL) or Hourly based selection. Choice of selection is offered during template deployment.
Citrix NetScaler is an all-in-one web Application Delivery Controller (ADC) that makes applications run faster, reduces web application ownership costs, optimizes the user experience, and makes sure that applications are always available.
Citrix NetScaler offers many tools for application deployment. Some of the primary tools are:
- Application Acceleration and Application Security
- HTTP Compression and HTTP Caching
- Web Application Firewall (WAF)
- L4-7 Load Balancer
- Global Server Load Balancing (GSLB)
- SSL Acceleration
- Server Offloading
- Server Consolidation
- Content Switching and Content Caching
- High Availability
- Remote Access and Remote Monitoring
- Policy Engine with Multi-Tenancy
- Data Loss Prevention
- Session Persistence
This template will guide through deployment of Citrix NetScaler HA Active-Passive mode. Preconfigured to include components and setting to deliver seamless HA experience. Details of topology can be found at http://docs.citrix.com/en-us/netscaler/12/deploying-vpx/deploy-vpx-on-azure/configure-vpx-pair-ha-inc.html. On successful deployment, Pair of NetScaler will be pre-configured in HA-INC mode. NetScaler 12.0 VPX HA template support different SKU’s of NetScaler such as BYOL and hourly license such as VPX 10, VPX 200, VPX 1000 and VPX 3000.
Next you have the option to choose or create a Resource Group.
Put in your preferred username/password combination and it is here you can choose the licencing method. I have opted for BYO (Bring your own) which I will upload to the device and configure with the Mac ID of the VPX system once known.
You can also choose the virtual machine sizes. The recommended size is 2 x Standard DS3 v2 machines.
Next screen gives you the option of choosing or creating the vnet (virtual network) and your subnets. It is here you can choose the vnet/subnets you already created or let the template configure a new vnet and 3 subnets.
In the screen shot below I had 3 subnets already created.
One for management, one for Infrastructure and one where I placed my VDA (Xenapp/Xendesktop machines.
Once you have defined each subnet the template wizard prompts you to review your subnet configuration.
I came across the below error. This was because my subscription only allows a certain number of cores. I removed some machines and I was able to run it again successfully.
Second attempt I was able to proceed and create the HA environment.
Azure lets you know the deployment is happening once you click create.
Again, in my deployment there was a failure but the template did deploy.
Then this message pops up informing me the template is deploying.
The error details I received are here.
Once deployed you should see the following virtual VPX machines in the Resource Group Location.
The Azure objects I highlighted already will also be created in your chosen Resource Group.
Now you should connect to the internal management IP’s of your NetScaler appliance on your chosen management subnet.
The IP’s again can be identified by drilling in to the virtual machines and going to the Networking setting –
You will see your IP’s and the NSG rules set on the Interfaces. If you want to connect to your Public IP (PIP) for management, it is here you will need to relax the NSG rules to allow the access.
There is a public IP and an internal IP that is shown at the top of the screen shot.
Once you obtain your management IP’s from both devices you will be able to connect to the internal management IP’s (NSIP).
Here the fun stuff of configuring your two VPX devices will begin!
One thing to note is that when you log in you will see that your HA is set up and all nicely configured and can successfully failover.
- Obtain your licensing and upload.
- Import your certificates. Don’t forget the complete chain!
- Upload the CA certs to your NetScaler and then install them.
Choose the Intermediate certificate.
Now import your Server Certificate. Mine is in PFX format.
Upload to the NetScaler device.
Choose the PFX certificate.
Put in your certificate password and click Install.
Your Server certificate should appear as below.
One more time – Do not forget to link the chain!
Bind the Server certificate to the Intermediate.
Now you have the appropriate licencing on both your HA appliances and Certificates are uploaded you can proceed with the install of your Netscaler Gateway VIP’s (VIRTUAL IP).
The Xenapp/ Xendesktop Gateway wizard process is well documented so I will not outline this process here. Please check out my CUGC blog at the top for links to other CTP members posts on this process.
Additional Configuration after Template Deployment
This additional configuration after the template deployment needs to be carried out.
First of all you need to create 2 NetScaler Gateway’s.
You can create this using the Xenapp and Xendesktop wizard on the Netscaler.
You can easily deploy a second NetScaler after the first one by clicking on the highlighted icon below.
Once again, I will not run through the NetScaler Gateway configuration as this is well documented.
On the virtual machine Interfaces in the Azure portal, the Gateway IP’s must be assigned.
VPX0 NIC INTERFACE
VPX1 NIC INTERFACE
Make sure your NSG (Network Security Group) on both interfaces is allowing port 443 inbound. The NSG acts like a firewall.
This needs to be done for both machines (VPX0 and VPX1) and the NICS the Gateway is assigned to.
The reason you need to create 2 Gateways in an Active/Passive deployment is that you can only assign one IP to one interface in Azure.
For example, if I was to assign 10.0.0.111 to VPX0/NIC1, I would be unable to assign that IP to VPX1/NIC1.
As the gateway IP is a floating IP shared between two VPX devices, we need two Gateways with the same configuration so we can assign different IP’s to the NICS so the Azure Load Balancer can point to the Gateway.
Azure Load Balancer Configuration
You need to assign your public IP (PIP) for your NetScaler Gateway to a Frontend load balancer.
In an on-premises environment if the primary NetScaler goes down, the secondary node will flood the subnet with ARP to take over the IP address of the VIP and SNIP to restore the connection. In Azure GARP doesn’t work therefore we use the ALB in front and have a single public IP which health probes against the backend NetScaler’s and if one of the NetScaler’s goes down, the HA function in NetScaler will (when configured with INC) will set the virtual server as up on a separate IP address and the ALB will start to failover traffic to the second VIP on the second NetScaler.
More on Azure Load Balancer can be found here –
Access the ALB (Azure Load Balancer) via your Resource Group that contains the deployed resources.
You then need to create your Frontend configuration and assign the PIP (Public IP) to it.
Remember you can create your PIP before deployment so you are able to sort out your SSL certificate and external DNS before implementation day.
You simply click ADD and you get the option to configure a Frontend LB.
The next thing you need to do is create your backend Pools. This will be the machines and target IP’s the Frontend Load Balancer will connect to within your environment.
Simply click ADD and configure as necessary. If you don’t see your target IP you may not have assigned this on your machines NICS in Azure. Remember the IP’s defined within your NetScaler ADC configuration must exist on the NICS of the virtual machines in Azure.
The Backend IP’s can be seen below and they are pointing to the individual Gateway IP’s assigned to each NIC. (Remember 2 Gateway’s).
Lastly we need to configure the load balancing rules. This is the glue if you like, that will make your Frontend Load Balancer pass on 443 connections to the Backend you just configured.
One thing that caught me out when I was configuring this set up was the Health Probe. I used the probe that was assigned by default. I could never hit the Gateway logon page and I was scratching my head for a while. When I created an additional Health Probe on 443 I was able to hit the Gateway externally. Before I did this I could not get a TELNET response from the Gateway externally.
In Azure SNIP IP’s are not floating. This means your SNIP IP can be different across appliances.
Make sure you have a SNIP for each subnet you communicate to. This then needs to be assigned to the Azure VM interface. Remember you cannot assign the same IP to more than one NIC.
Remember to add both your Gateways to Storefront. You can simply download the configuration file here and import it in to your Storefront.
That is basically it. You should now have a NetScaler HA active/passive solution in Azure.
This is front ended by an Azure Load Balancer.
Simply connect to your Public URL and log in and you are good to go.
The next article will highlight the Active/Active approach in Azure.
Follow me on Twitter @CitXen