by David Brett, CTP
Something really cool happened last week. NetScaler in Microsoft Azure got a revamp! This is something that I have been waiting to see happen for ages and finally Microsoft, Citrix and NetScaler are supporting multiple network interfaces and Global Server Load Balancing in Azure!
This for me is huge!
So many people who run Citrix infrastructure services on-premises want the ability to fail over to a cloud hosted service. Historically this has been difficult to automate as NetScaler in Azure did not support GSLB and multiple IP addresses but thats now changed.
Consider the ability to have an immediately available failover data centre that runs at a reduced capacity. This could be your Azure data centre running at the bare minimum to allow business to continue in the event of a failure but having the ability to scale out at ease if the failure continues. With NetScaler now supporting GSLB and Multiple IP Addresses this is now a reality.
First, here is the Citrix article showing you all the changes that have taken place.
https://www.citrix.com/blogs/2017/03/31/netscaler-on-azure-gets-an-upgrade/
So, this post. I am going to take my on-premises Load Balanced StoreFront service and give it the ability to seamlessly fail over to my Azure Data Centre running on the UK South Region. This means that if my on-premises StoreFront service fails, it will continue to run from the cloud without any user intervention.
Microsoft Azure Connectivity
First, this article assumes that you have a site-to-site VPN running from your on-premises data centre to your Azure data centre.
As you can see, I have a vNet, Azure Gateway, Local Gateway and Connection defined in my Azure portal. For information my internal network is 192.168.0.0/24 and my Azure network is 10.0.0.0/16. As you can see below there is a connection between my Azure Data Centre and my local RRAS server in my lab.
If you want to know how to set up this site-to-site VPN, then you can follow a previous article I have written on my personal blog here:
On-Premises StoreFront
Next I will address my internal StoreFront Service. As you can see I have a single StoreFront server (web.bretty.me.uk) and this is sitting behind a Load Balanced vServer hosted on my internal NetScalers. In a production environment, you would have more than one StoreFront server but for the purpose of this article, this will suffice.
Internal StoreFront Service Group
Load Balancing vServer for StoreFront. Note the IP address: 192.168.0.210
Microsoft Azure StoreFront Server
Next, we will need a Windows Server in Microsoft Azure to host StoreFront in the event of a local service failure. Build a Windows 2016 Server in Azure and put it on your vNet that can connect to resources over your VPN
his server will not need a Public IP address as we will be connecting to it over our VPN. It will need a static IP address however, as we will be load balancing this server and do not want the IP address to change.
Select the network interface for the server, then select the IP Configurations
Next, make sure you have selected static for the IP Address.
Once you have your server up and running, download and install StoreFront onto it and add it to your on-premises server group.
Make sure that the server can sync the settings, this will ensure that users don’t loose their app subscriptions if the service fails out to the cloud.
Don’t worry about changing the base URL, as we will deal with this using Global Server Load Balancing later in this article.
Azure NetScaler Base Build and StoreFront Load Balancer
Next you need to build your NetScaler in Azure. Select and deploy a Citrix NetScaler. Bring your own license into the same network as your StoreFront Server you have in Azure already. Once built, connect to the NetScaler and add DNS and your License File.
Next, give your NetScaler a static IP address in the same way that you did for your StoreFront Server.
So, at this point we need to configure a StoreFront Load Balancer on your NetScaler in Azure. Go ahead and configure a Load Balancer to balance traffic to your StoreFront Server(s) that you have built in Azure only. There are plenty of guides out there on how to set this up, so I won’t re-invent the wheel here. Once done, you should have a Service Group and Load Balancing vServer running on your cloud hosted NetScaler.
Azure StoreFront Service Group
Azure StoreFront Load Balancer
Note the IP address 10.0.1.102
The next stage is to add an additional IP address to the NetScaler instance in Azure to allow traffic to be routed to the load balancer IP address.
Open up IP Configurations assigned to your NetScaler in the same way that you did when setting a static IP but instead, this time click Add
Give it a descriptive name and set a static IP the same as your load balanced IP address on your private network
Click to save your new IP address.
NOTE: This is adding an additional IP to a single card, there are other options to add IP addresses to separate cards but for the purpose of this post I will be adding all the addresses to a single card.
Once the config is saved, you should be able to ping and connect to both load balancer addresses.
Internal StoreFront Load Balancer
Azure Hosted StoreFront Load Balancer
ADNS
In order for StoreFront to be Globally Load Balanced, you will need an ADNS Service running on both your internal NetScaler and your instance in Azure. Go ahead and add the ADNS Service to both.
Internal ADNS Service
Azure ADNS Service
As with the Load Balancer, we will need to add another IP address to the NetScaler in Azure to allow connectivity to the new ADNS Service. Go ahead and add the new IP in the same way you did for the Load Balancer but give it the same IP address as your ADNS Service
For ease of use at this point, I like to add a static dos record for each ADNS service so that its easier to delegate the ins record later on. Ping both addresses to test they are live. You can also do a nslookup to both servers if you want to test connectivity.
Global Server Load Balancing
Next you will need to set up Global Server Load Balancing to send the users to your on-premises StoreFront Load Balancer as a primary target and in the event this fails, then drop them over to your Azure hosted Load Balancer.
I have written lots of articles on how to set up and configure Global Server Load Balancing so I am not going to re-write all the steps to create and setup the service. I will just show you what is needed to make this work. Please note that you will need the Services and vServers set up on BOTH NetScalers. The reason for this is that if you lose your internal NetScalers you still want the ADNS Service in Azure to be able to return the correct IP Details for the live service.
GSLB Sites
Set up a Local and remote site for GSLB on both NetScalers.
NOTE: When adding the site to the Azure NetScaler you will need to add another IP address to the IP Configurations to allow connectivity to GSLB.
GSLB Sites Local
GSLB Sites Azure
NOTE: At this point you will have 4 IP Addresses assigned to your NetScaler in Azure.
- NetScaler IP
- StoreFront Load Balancer IP
- ADNS IP
- GSLB Site IP
GSLB Services
Set up a Local and Remote Service on both NetScaler to point to the StoreFront Load Balancer IP Addresses, use any monitors that are relevant to ensure the services are up and running.
Local GSLB Services
Azure Hosted GSLB Services
GSLB vServers
Finally, you need to set up 2 GSLB vServers on each NetScaler to host the GSLB Services.
Local GSLB vServer
Azure Hosted GSLB vServer
Open up the on-premises GSLB vServer on each NetScaler and add the Azure Hosted GSLB vServer as a backup vServer, also add the domain name you want to use for GSLB.
Bound GSLB Service
Domain Binding
Backup vServer
ADNS Delegation
The final piece of the puzzle is to delegate your dos name to the ADNS services on both NetScalers. Open up DNS and create a new delegation for the domain name you bound to your GSLB vServer, and send the requests to BOTH ADNS Services you set up on your NetScalers.
That’s it, your storefront url will hit your internal StoreFront Servers as a primary site. If your internal StoreFront Servers fail then the service will fail out to the Microsoft Azure Cloud.
Hope this helps some of you see what you can do with Azure as a DR solution now that Multiple IP and GSLB is supported in Azure.
