Test drive GSLB (Global Server Load Balancer)
Thank you for your interest in the edgeNEXUS GSLB product.
We hope you enjoy your experience with the edgeNEXUS GSLB and would like you to have a realistic configuration to play with.
- As part of this test drive we have pre configured a few example services to get you up and running
- We host this setup on Azure but don’t worry you don’t need to have an Azure account and also its FREE
- You are welcome to re-configure the appliance to try it on your own servers
The following instructions are designed to help you navigate your way around the edgeNEXUS ALB-X Application Delivery Platform and the GSLB GUI.
Firstly get your test drive here:
There are several applications for GSLB in an application delivery / hosting environment:
- Multi cloud and Hybrid cloud or even migrating to the cloud
- Provide data centre resilience, redirecting traffic to a backup site in the event the primary site fails completely
- Provide optimised content delivery by directing a client to the best location to fulfil requests
- Provide geographic localised content based on client location
GSLB manages this by adding intelligence to the DNS resolution process.
So to make the most out of the test drive you ideally need access to your own DNS server and be able to define a sub domain that will be resolved by the GSLB.
Typically the GSLB function is used for certain applications/services and involves resolution of part of your DNS name space.
So for example it might be used to provide intelligence and resilience for the www portion of yourcompany.com domain.
To assist with management of the GSLB function typically a separate sub domain name is created that delegates DNS resolution duties to the GSLB.
For example anything containing geo.yourcompany.com forward to GSLB for resolution.
The GSLB will have several A record entries for each possible server that hosts the application. e.g. www1.geo.yourcompany.com, www2.geo.yourcompany.com.
The corporate DNS server is configured with CNAME entry that aliases the www.yourcompany.com domain name to www.geo.yourcompany.com so the resolution task is forwarded to the GSLB as the authoritative source for resolving the desired resource.
The GSLB will health check each of the servers configured as part of the www.geo.yourcompany.com name space and respond with the most appropriate server depending on the GSLB policy configured.
Appliances deployed in Azure are allocated IP addresses from the Azure private IP address space. The ALB-X and GSLB are no different in this regard. In order to gain access from the Internet a Public to Private NAT function is used.
As part of the test drive launch process you will be sent details how to access the ALB-X application platform management web interface. It uses a HTTPs connection to port you
You will have a unique username and password (in an email sent from Azure).
Once you accept the local certificate warning and logged in with the credentials
When logged in you will be presented with the IP Services screen.
Here we have pre configured 3 services and labeled their function in the Service Name field
Let’s head over to the Library to take a look at the Add-Ons option
Here you can see the GSLB application that has been pre-deployed it has been configured with a container name (gslb1) and is already running.
GSLB Add-On application runs in a Docker container and uses a separate docker0 network interface to communicate with the ALB-X application platform.
Part of the Add-On deployment configuration involves giving the Application a container name e.g gslb1.
When a docker application is started it is allocated an IP address from the docker0 pool. This IP address can be automatically resolved by ALB-X by referring to the application using its docker container name.
You must only use the container name NOT the IP as that can change 🙂
You can see on the right hand side that the application has been assigned an IP address from the 172.31.x.x default docker0 IP address range
The GSLB uses 2 ports to communicate externally:
port 53 TCP/UDP for DNS traffic and 9393 TCP for access to the management web console.
These we have pre configured along with the container name and the GSLB application has been started.
In order to gain access to the GSLB running on the docker0 interface in Azure it is necessary to use Services on the ALB-X platform to translate from the eth0 Azure private IP address to the docker0 internal IP address.
Two of the IP services have been pre configured for this purpose.
You should be able to access the GSLB management GUI by entering the Azure host name you were provided with followed by port :
The default username / password are admin/jetnexus
After sign in you are presented with the GSLB Dashboard configured with a dummy domain name entry.
Note it is not possible to edit a domain name entry you will need to add your own domain name entry in order to configure a different value to use the GSLB in your DNS environment.
For the moment we can continue to explore the dummy configuration to see how the system is setup and operates.
The domain you enter here is the one that the GSLB will be responsible for resolving. So for example if you decide as we have in the example to use ‘geo’ as your sub domain and you have a dot com domain you would enter
when adding the new domain.
The rest of the settings can be left as default.
You will now have 2 domains configured like this.
If you click onto the preconfigured geo.yourdomain.com entry you will see that 2 A record entries have been added along with dummy default SOA record.
The A record entries are where the IP addresses of the application servers (or load balancer VIPs) are configured.
For a full DNS configuration you will also need to add name server records to point to the GSLB IP address/s themselves.
Let’s refer back to the IP Services screen in ALB-X.
The second entry configured using port 53 is the service used to allow your own DNS server to communicate with the GSLB server.
The third entry in our case here using port 80 is there to define and perform the health check for the real servers and also map the A record entries to the GSLB domain Service Name.
The important parts of the configuration for this entry are:
Service Name. This is what the upstream CNAME entry in the upstream DNS server will be pointing to to resolve the IP address for the service the client is trying to access. So in the example configuration we have used service1.geo.yourdomain.com.
Address entries in the Real Servers section of the service configuration. The ALB-X does a lookup for the IP addresses for the hostnames configured as real server entries by referring to the GSLB which is configured as its primary DNS entry. It will perform the health check configured under the Basic tab to confirm reachability of the returned server IP address / port.
The information configured for this service is ‘scrapped’ by the GSLB using the ALB-X REST API and entered in the GSLB Virtual Services configuration.
Let’s take a look back at the GSLB GUI to see what is there.
Here we can see it has found and imported the entry for service1.geo.yourdomain.com.
To prove it is finding this info from the ALB-X service configured with the same Service Name let’s change the Service Name in the ALB-X to something else like www.geo.yourdomain.com (it must have the same geo.yourdomain.com suffix)
Refresh the GSLB Virtual Service menu screen.
Now you can see the domain name has changed to www.geo.yourdomain.com
Looking along the entry you can see that the default GSLB Policy is Round Robin. As its name suggests when queried for the domain name www.geo.yourdomain.com it will respond by cycling round the possible alternative hosts/IP address available in sequence.
If you click on Edit and the GSLB Policy drop down you can see the other Fixed Weight and Geolocation GSLB Policy options available.
Click into www.geo.yourdomain.com entry either by clicking on link or selecting manage.
Here you can see the health of the servers that are part of the GSLB balanced domain.
Their Status is shown as connected i.e. the health check is passing. As this service is configured for round robin and both servers are set to Online each site or server will receive traffic in turn. If you want to operate the secondary site in DR (disaster recovery) mode and only send traffic to it in the event that the primary fails you can achieve this by configuring the Activity option for the ALB-X service.
Click back to the ALB-X IP Services tab and double click the Activity setting for server2.geo.yourdomain.com, choose Standby and click Update. The Status LED should change to orange. Click back to the GSLB Virtual Service window click refresh and you should see the Status for server2.geo.yourdomain.com ia now showing as Fall-back standby.
Testing the GSLB as your primary DNS server
The ideal scenario to perform testing of the GSLB will be to integrate it into your current IT DNS server environment. If this is not possible you can perform some simple tests to start of with by reconfiguring your test device PC/Mac etc to use the GSLB as its primary DNS server and an alternative DNS as the secondary.
Any actions requiring DNS resolution will then be sent first to the GSLB to resolve and you can thus see the responses it returns. If the GSLB can not resolve the name the Host will send to the secondary.
Example DNS server PC config
With the correct IP address for your Test Drive instance entered like the example above…
Open a command prompt and attempt to ping www.geo.yourdomain.com
You should get a result shown below where you can see the response is from server1.geo.yourdomain.com with IP address 184.108.40.206
Now cause the first server to fail the health check by changing the configure port to 81 instead of 80.
Server2 now has a green status and server1 is red.
Repeat the ping test to www.geo.yourdomain.com
Now the response is from server2.geo.yourdomain.com with IP address 220.127.116.11
When performing these tests you need to bare in mind caching that takes place within the DNS resolution process so switch over will not be immediate. When setting up the GSLB as an authoritative resolver for sub domains the TTL should be set to a low level to ensure stale results are not returned.
Hopefully you now have a good idea how the system works and how to configure the different aspects of the edgeNEXUS GSLB. We encourage you to continue experimenting with the test drive and welcome any questions you may have to firstname.lastname@example.org
Now go and have a coffee and take an Aspirin 🙂