Tags: Azure

Azure Traffic Manager for NetScaler Gateway Failover

Azure Traffic Manager is designed to provide traffic routing to various locations based on a ruleset that you specify. It can be used for priority (failover), weighted distribution, performance, and geographic traffic distribution.

The failover option is similar to GSLB – and works in a similar way, so I am going to demonstrate that in this post. I’ve started with the following environment already configured:

  • Two Azure Locations (East US and South Central US), with a VPN between the sites to join the VNETs
  • 1 Domain Controller in each location
  • 1 NetScaler (standalone) in each location
  • 1 Citrix Environment spread across the two locations
  • NetScaler Gateway’s setup in both sites, and NAT’d out using Azure Load Balancer. (So that we have a public IP offering NetScaler Gateway services in both Azure Locations. Have a look at this Blog post if you require guidance on setting this up.)

Azure Lab Diagram

Before we setup the Azure Traffic Manager profile, we need to give our Public IP Addresses a DNS name label. To do this, browse to the Public IPs for your Load Balancers, and then click on “Configuration”. We need to give our Public IP addresses a DNS name label, as this is what Traffic Manager will be using to balance the endpoints.

Azure Public IP configuration

I have two public IPs so I have created two DNS Name Labels and given them appropriate names:

  • desktop-eus-jwnetworks = East US NetScaler Public IP
  • desktop-scus-jwnetworks = South Central US NetScaler Public IP

Next – it’s time to create the Azure Traffic Manager profile!

Traffic Manager profile creation

After we click create, we just need to populate a few basic details:

Traffic Manager profile creation

As you can see – I have given my Traffic Manager a name, selected Priority as the routing method (this gives us the failover in a similar manner to Active/Passive GSLB). Note: there are other options available:

Traffic Manager routing options

See here for an overview of the Traffic Routing Methods. Next – we need to configure some more settings on our Traffic Manager, to ensure that the Monitoring and Traffic Routing are going to work correctly. In the screenshot below I have adjusted the following:

  • DNS TTL – I’ve adjusted this to 60 seconds, this defaults to 300 seconds (5 minutes)
  • Protocol – HTTPS, this is because we are Monitoring the HTTPS NetScaler Gateway
  • Port – 443 as we are using this port for the NetScaler Gateway
  • Path – this is the path to the files that the monitor will be checking for, so in the case of NetScaler Gateway this is /vpn/index.html – if this page is not available then the service will be marked as unavailable.
  • Probing Interval – this is how often the endpoint health is checked. Values are either every 10 seconds or every 30 seconds
  • Tolerated number of failures – this is how many health check failures are tolerated before the endpoint is marked as unhealthy
  • Monitoring timeout – this is the time the monitor will wait before considering the endpoint as unavailable.

For more information on these configuration options – click here.

Traffic Manager configuration

Next – it is time to add our endpoints! To do this, click on Endpoints and then on Add:

Traffic Manager endpoints

We then need to add our Public IP addresses assigned to the Azure Load Balancers (where the NAT rules were created). Note – you will need to do this for BOTH endpoints:

Adding Endpoints to Traffic Manager

Once both are added, you will see the below in the Endpoints screen. Note that both Endpoints are shown as “Online” – this confirms our monitor is detecting the Endpoints as up. Also note that the Endpoints have priority – this means that under normal operation, all traffic will be sent to the “eus-desktop” endpoint (Priority 1), and in the event of a failure of the “eus-desktop” endpoint, all traffic will be directed to the “scus-desktop” Endpoint.

Endpoints

All that is left to do is test – however, first let’s make things neat for our users with a CNAME DNS Record. We are effectively going to CNAME our jwdesktop.trafficmanager.net record to something that users would be able to remember. You can find your record from the overview screen:

Traffic Manager overview

Next up I added a CNAME record in my Azure DNS Zone:

Add DNS Record

Add CNAME Record

Once this is created – we can start testing! But first, a diagram! Below is shown what we now have setup and working:

Solution Diagram

Note: in order to easily distinguish between my two Gateways, I set the EUS Gateway to the X1 theme, and the SCUS Gateway was left on the default NetScaler theme. When accessing https://desktop.jwnetworks.co.uk I am correctly shown the EUS Gateway:

EUS Gateway Test

Bingo – this all looks good to me! Next up, I disabled the Virtual Server for the EUS NetScaler:

Virtual Server Disabled

After around 30 seconds… the Monitor Status shows as Degraded:

[ for those interested in the maths (10 Second Probe interval + 5 second timeout)x1 tolerated failure (so effectively 15×2 attempts at connecting) ]

Endpoint Health

Next I refreshed the Page and we are presented with the SCUS Gateway page:

SCUS Gateway Page

As you can see, during a failure condition (the EUS Gateway vServer being taken down) the Traffic Manager directs traffic to our Priority 2 site, without any intervention from us. Any users would be able to refresh the page and then log back in. This can be used not only for NetScaler Gateway but for many internet facing services – for example OWA, SharePoint etc. There’s a great many services that can benefit from this type of failover and the resiliency that it offers.

Load Balancing Citrix StoreFront with Azure Load Balancer

Sometimes there is a requirement to Load Balance StoreFront using a method other than NetScaler. Although rare (in my experience!) this does occasionally happen when NetScaler is perhaps not being used for Remote Access –  in an internal only environment for example.

In this post I will explain how to Load Balance StoreFront using the native Azure Load Balancers. We start with a simple setup:

  • 1x Domain Controller
  • 2x Citrix StoreFront Servers – in an availability set called “EUS-StoreFront”
  • 1x Virtual Network (VNET)

All of the above is in the East US Azure Location.

We start by creating a new Azure Load Balancer. Note a few key settings here:

  • Type: Internal – this is because we are balancing traffic within our VNET (Internal Network only)
  • IP address – static… we don’t want the LB IP to change!

Once this is done – we can add the backend servers. We do this by targeting the Availability Set that the StoreFront Servers are in. For those familiar with NetScaler, this is similar to a Service Group:

Next – we need to configure some Health Probes. This allows us to determine the state of the StoreFront server and to confirm that the services we are load balancing are healthy and available. Note: at the current time Azure Load Balancer HTTP checks support relative paths only, so I have used /Citrix/CitrixWeb/monitor.txt – a simple text file (Static Content) I created to check that the Web Server is serving out content and thus working correctly. (https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/load-balancer/load-balancer-custom-probe-overview.md) I have configured by Health Probe as below:

Next – it’s time to create the Load Balancing Rule that will form the entry point for Load Balanced traffic. Note the Protocol (TCP), Ports (80 Frontend, and 80 Backend), Backend Pool (StoreFront Availability Set), Health Probe (our HTTP 80 monitor.txt check), Session Persistence (Client IP), and Idle Timeout (30 minutes is currently the maximum value):

We can then click OK and our Load Balancing Rule is created! Next I created a DNS A Record for StoreFront and pointed it at the Load Balancer IP. After this, I opened up a browser and typed in my newly created StoreFront DNS record. Bingo – we have a page!

To test that the Load Balancing was working. I shut down IIS on each server in turn, and then tested. Sure enough – even when only 1 out of 2 servers was running, the page stayed up and StoreFront was accessible.

This Load Balancer can be used for a variety of Web Applications, and is a simple way to Load Balance Azure based services as you require. Until next time… cheers!

GSLB for NetScaler Gateway across Azure Locations

In this post I’ll be going through how I have configured GSLB for NetScaler Gateway in Azure, and the various elements required for this type of configuration.

Firstly – I began by setting up the background infrastructure to demonstrate this test. Namely, 2x Active Directory DCs within two Azure Locations (Eastern US (EUS), and South Central US (SCUS)). These were on a Virtual Network setup for each location, joined with a Site to Site VPN utilizing Virtual Network Gateways. Next, I created a simple Citrix Environment that spanned the sites, ensuring I had resources in both sites – to properly demonstrate the failover.  An overview of the background infrastructure is shown below:

Next, I spun up two NetScaler BYOL versions:

These will form the bulk of the work where configuration will take place – in providing NetScaler Gateway via GSLB. I’m using Platinum Licensing, but Enterprise would also be fine (so that GSLB is available).

My NetScalers will all have multiple IP addresses assigned, for the SNIP, GSLB Site, and Gateway VIP:

Well worth a read at this point is CTP Gareth Carson’s awesome blog post around NetScaler deployment in Azure.

The next step for me was to setup 2x NetScaler Gateway vServers, which will be used for external access, and will be the vServers that will be provided by GSLB:

East US NetScaler:

South Central US NetScaler:

Next – I setup Authoritative DNS Listeners on both NetScalers, making use of the Subnet IP for this service (East US NetScaler shown below) :

So – next we can setup the GSLB Sites, to enable the synchronisation of GSLB information via Metric Exchange Protocol. It’s just a case of adding one local and one remote site on each NetScaler, and using the GSLB Site IPs. Once this is completed, the NetScalers will show as follows:

East US:

South Central US:

Once these are setup and showing as Active – we have communication between the NetScalers. This is carried out using Metric Exchange Protocol (MEP). Next – we need to configure GSLB, but first I am going to create the Public IP addresses for each site, as this makes the GSLB Setup easier! We will need two IP Addresses (one for each site), and TCP 443 (Gateway), and UDP 53 (ADNS) will need to be NAT’d through for this configuration to work. See the diagram below for an overview of this:

This is easy to configure – firstly we setup two Load Balancers, each with a Public IP (Static) assigned:

Ensure that Static is selected for the Public IP – otherwise this may change and then the solution will stop working:

Once this is created for both sites – we will have two Load Balancers ready to use for our NAT requirements:

At this point, I like to update the Network Security Groups on the NetScalers to ensure that the required inbound rules are in place. For both NetScalers we need to allow HTTPS and DNS inbound from anywhere (as these will be internet facing):

Once complete, we can then NAT through the required ports (TCP 443, and UDP 53) by creating an inbound NAT rule. Remember, you’ll need to do this twice on each Load Balancer – so both ports are forwarded to the NetScaler on the Load Balancer site.

Once these are all in place – we can test the NetScaler Gateway is up and accessible by visiting https:// and then the Load Balancer IP for each site. Before we configure GSLB on the NetScaler – we need to delegate the DNS Zone. This will vary depending on how your External DNS Servers are setup. Essentially – we need lookups for the Gateway URL to be handled by the NetScaler appliances. This means any lookups for the Gateway IP need to be delegated to the NetScaler appliances – so that they can provide the URL for the Active GSLB Site.

I’m using Azure DNS – so I have a zone setup. My URL is desktop.jwnetworks.co.uk – so I will be delegating control of this to the NetScalers. To start – create two A Records, one for each NetScaler, and these need to be pointed at the NAT’d IP. These will be used for the DNS Lookups. We then need to create a new NS Record for our Gateway Domain Name, with a 5 Second TTL, and pointing it at the A Records for the NetScalers we configured above:

Now that this is in place – it’s time to configure our GSLB Configuration! This can be done from one of the NetScalers and then propagated to the other via Configuration Sync. I’ll therefore carry this out on the EUS NetScaler – as you can see below, we have only the sites setup for GSLB (as we did this earlier):

We start by clicking the “Configure GSLB” button, and then run through the Wizard – I am going to run with an Active/Passive site:

We then click OK, and we are presented with the GSLB Sites pane – but we have already configured this:

We can click continue, and we then need to setup the GSLB Services. So these are the two NetScaler Gateways we are using to provide this service. The key here is that we need to make sure that the Public IP addresses are listed – EUS is shown below:

We then click Create, and then repeat this process for the SCUS Site – making sure that the Public IP address is entered again. Once this is done, we will have a Local and Remote Site Configured:

Next you will be prompted to create a GSLB Backup vServer – but I’m not going to create that as part of this Proof of Concept.

Next – we create the GSLB vServer. This is just the entry point for traffic being Load Balanced by GSLB. Note – ensure that you pick an appropriate load balancing method, and then click continue after filling out your details:

Next – click on Save, and the configuration is done! We can now sync the config across to the other NetScaler. This is done by clicking on “Auto Synchronisation GSLB” from the GSLB Dashboard:

Once this completes successfully – we can test our configuration! To start – we can do an nslookup, and set type=ns. This will tell us that the NameServers are correctly configured:

As you can see – the nslookup is returning all the expected information. Because we configured Active/Passive – the A record returned for a normal (A record) nslookup is that of the EUS NetScaler. Next – we can test that the Gateway Page is working and accessible:

Bingo – all good so far! Next – let’s try shutting down the EUS NetScaler and see if things are still working as expected. At this point the IP address returned should change from that of the EUS Load Balancer IP, to the SCUS Load Balancer IP:

Before EUS NetScaler Shutdown:

After EUS NetScaler Shutdown:

As you can see this works as expected, and after a page refresh, the NetScaler Gateway page is shown again:

This means that during a failure condition affecting the EUS NetScaler, requests for the Gateway URL will be directed (via DNS) to the SCUS Site. This provides Data Centre level failover for Gateway Services, making use of native Azure Load Balancers, and a single NetScaler on each site. This solution is suitable for pretty much any service accessed via a Web Browser – GSLB can be used in this way to fail NetScaler Gateway services over between Azure Sites or to distribute other traffic types as required.