Tags: NetScaler

GSLB for NetScaler Gateway across Azure Locations

· · , , , , , ,

Tagged: , , , , , , ,

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.

 

 

 

 

Quick Post! – Using NetScaler responder policies/actions and backup vServers to notify users of Service Downtime

· · , ,

Tagged: , , ,

NetScaler, as I am sure you are aware, is a superbly powerful Application Delivery Controller. One of the most useful features is the use of Responder Policies/Actions, and Backup vServers to indicate that a service is down or to provide access to an alternative service for end users.

Let’s say – you have a load balancer configured that balances two Web Servers, which you then present for users to access. This load balancer could be configured with monitoring to check the health of the Web Servers, and also to ensure that the servers are loaded evenly with requests.

But – what happens when both servers are down? Maybe you have scheduled patching, or there is a fault. Leaving users with a blank page or one that times out is never ideal, and letting them know there is a fault is always best. This is especially relevant if the users are accessing pages of a commercial nature – for example, “The Online shop will be back open at 2pm” is a lot better than a blank page.

Both of the options below take less than 10 minutes configuration on a NetScaler – so if you need to get a page up quickly… these are very useful!

To do this – we can go down one of the two routes below:

Option 1

Use the Redirect URL option on the vServer – this redirects client requests to the custom URL when the service is down. So for example this could be a custom page on elsewhere, which explains that there is an issue.

This could be used for Scheduled patching for example – for times when we know the site will be down, we just add the URL to the vServer and any users who visit during the maintenance window will see the redirected page.

Option 2

Another option, is to use the Backup vServer feature within NetScaler – this is great because it can be used to direct traffic to a backup Data Center if our primary is unavailable. But also – we can use this feature to put up a NetScaler generated page informing the user that there is a problem with the backend service.

To do this – we need to create a new vServer to use for Maintenance. Create this with the following basic settings:

Then create a service for this – any local service bound to 127.0.0.1 will do. Assign a basic monitor so that the service shows as up.

Next – go to AppExpert, and then Responder, and create a Responder Action. Fill out the details as below – note: you will need to create a new HTML Page, this is the 2nd and 3rd screenshots below:

HTML Page:

Click on Done, and then Click Create for the Responder Action.

We can then go back to the vServer and assign this under the Policies option. Select the options as per the screenshot below and press Continue:

Next we are presented with the below screen, click on the Plus sign next to “Select Policy”:

Fill out the details as per the below:

Click on “Create” and then click on “Bind”. Finally, click “Done”. We can now apply this vServer as a backup vServer to others – so that if those vServers are down, this page will be shown to users.

This is configured on a per vServer basis as per the below:

Now when accessing the page, and with the services down – the following page is shown:

Obviously, you can customise the page a little more than I have – but hopefully this will help. It’s a quick step to setup and gives some extra information to users when there is scheduled work or an unexpected fault.