Many companies already have a presence in Microsoft Azure with a few simple servers or a complex virtual data centre (yes, “centre,” not “center,” as I am a Brit!) Something I am constantly being asked about is the ability to use Microsoft Azure for business continuity and the options around failing services from your hosted data centre to the cloud seamlessly. This has always been possible but often required some manual intervention or complex configurations.
Fortunately something pretty cool happened recently. NetScaler in Microsoft Azure got a revamp! This is something that I have been waiting on for quite some time and finally Citrix, Microsoft and NetScaler are nicely integrated and fully functional. The results you can get with that combination are pretty astounding.
This blog post will focus on the ability to use NetScaler Global Server Load Balancing to take a Citrix StoreFront service running in your on-premises data centre and seamlessly fail it over to the Microsoft Azure Cloud. It assumes that you already have a network connection between your data centre and your Microsoft Azure Virtual Network. If you want more information on what Global Server Load Balancing is or how it works then you can read all about it on the Citrix Product Documentation site here.
Microsoft Azure Network Connectivity
Lets start with the Microsoft Azure Networking. In this example I have a simple network set up in my Azure subscription consisting of the following:
- A Virtual Network defined in the UK South region with a 10.0.0.0/16 Address Space
- An Azure hosted Network Gateway attached to my Virtual Network
- A Local Network Gateway defined with the Public IP of my On-Premises Firewall and a 192.168.0.0/16 Address Space
- A Connection between my Azure Gateway and my Local Network Gateway up and running
On-Premises StoreFront Service
I want to have a highly available StoreFront Service running for my users internally, as well as across data centres, so, as you can see below, I have a NetScaler Load Balancing Virtual Server fronting my internal Citrix StoreFront servers. Currently, the domain name for StoreFront is pointing directly to the IP Address of this Load Balancer.
Microsoft Azure StoreFront Service
Next, I want to build a server in Microsoft Azure to host Citrix StoreFront in the event that both on-premises servers fail. Note here that I am only building a single server and not making the service in Azure highly available by default. This is deliberate, as I don’t want servers running in the cloud unless they really have to, as I will need to pay for them. This way, I can use the cloud service to act as a fail over site until such a time that I fix my on-premises service, in the event that bringing by on-premises service up takes longer than expected I can simply add additional servers to the Azure Load Balancer hosting StoreFront as I need them. This will be different if you are wanting to run primary services from Azure!
Build a Windows 2016 Server in Azure and put it the Virtual Network that can connect to on-premises resources over your VPN.
Note that the server does not have a public IP; this will not be required as we connect to the server over the internal 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 and make sure you have selected “static.”
Log into the server, install Citrix StoreFront, and add the server to the existing server group within the StoreFront management console.
Make sure that the StoreFront Servers can sync the settings; this will ensure that the servers look and feel the same in the event of a on-premises service failure and also the users will not lose their app subscriptions if the service fails out to the cloud.
Azure NetScaler Base Build and StoreFront Load Balancer
Next, you need to build your NetScaler in Azure. Go to the Azure marketplace and select and deploy a Citrix NetScaler and bring your own license into the same network as your StoreFront Server. Once built, connect to the NetScaler and perform the initial config, adding the DNS and License Files.
Make sure that you have assigned a static IP Address to the NetScaler in the same way you did for the StoreFront Server
At this point, you need to configure a StoreFront Load Balancer on your NetScaler in Azure. Go ahead and configure a Load Balancer to balance traffic to the StoreFront Server that you have built in Azure only. When configuring the Load Balancer on the NetScaler, give it an IP Address in the same Subnet as the NSIP for the NetScaler.
This is where things are now different for NetScaler in Azure, it used to run in Single IP Mode and this was not possible, but now you can run multiple services on the same NetScaler each with their own IP Address!
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 Balanced 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 you just defined on your NetScaler
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 balanced addresses in both your on-premises data centre as well as your Azure hosted data centre.
In order for StoreFront to be Globally Load Balanced, you will need an ADNS Service running on both your Internal NetScaler(s) and your NetScaler(s) in Azure. Go ahead and add the ADNS Service to both.
Internal ADNS Service
Azure ADNS Service
In the same way we did for the Load Balaced StoreFront Servers, 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.
I normally add a Static DNS record to point to both my ADNS services, so that its nice and easy to delegate domains without having to remember specific IP Addresses. At this point, you should be able to ping and nslookup on both your Internal and Azure ADNS Services.
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.
There are many articles out there on setting up and configuring Global Server Load Balancing, so I will not detail each and every step you will need to run through to set GSLB up. I will just show you what is needed to make this work.
Please note that you will need the Services and Virtual Servers set up on BOTH NetScalers both on-premises and in Azure. The reason for this is that both ADNS Services need to know about all services in the local and remote GSLB Sites in order to return the correct IP Address for the live service to the user.
Set up a Local and Remote site for GSLB on both NetScalers. When adding the site to the Azure NetScaler you will need to add another IP address to the IP Configurations to allow connectivity to the GSLB Site.
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
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.
GSLB Virtual Servers
Finally, you need to set up 2 GSLB Virtual Servers on each NetScaler to host the GSLB Services.
Open up the on-premises GSLB Virtual Server on each NetScaler and add the Azure Hosted GSLB Virtual Server as a backup.
Finally add the domain name you want to use for GSLB.
The final piece of the puzzle is to delegate your DNS 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.
If you think about the possibility for moving services to and from Azure at-will, NetScaler running GSLB into Azure is a pretty powerful combination!
If you want to find out more about this or to ask for some more information then be sure to look me up at Citrix Synergy in Orlando.
See you there!