Global Server Load Balancer
(GSLB) Test Drive

Welcome to our GSLB test drive.

Go for Test Drive

We hope you enjoy your experience with the Edgenexus GSLB and would like you to have a realistic configuration to play with.

Thank you for your interest in the Edgenexus GSLB product.

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.

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.

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 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:

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 :

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.

Refresh the GSLB Virtual Service menu screen.

GSLB Policy

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.

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.

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.

With the correct IP address for your Test Drive instance entered like the example above.

You should get a result shown below where you can see the response is from server1.geo.yourdomain.com with IP address 185.43.50.85

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 185.43.50.87

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.

Thank you.

We would welcome any questions you may have to pre-sales@edgenexus.io

0808 1645876

(866) 376-0175

pre-sales@edgenexus.io

Don’t take our word for it – take a free trial

Hardware, software or even your own online image complete with a full test environment.
Just let us know what you need here

APPLICATIONS

RESOURCES

PARTNERS

APP STORE

Global Server Load Balancer
(GSLB) Test Drive

We hope you enjoy your experience with the Edgenexus GSLB and would like you to have a realistic configuration to play with.

GSLB Policy

Testing the GSLB as your Primary DNS Server

Thank you.

Don’t take our word for it – take a free trial

Contact us

Try it now

Support

Global Server Load Balancer (GSLB) Test Drive

We hope you enjoy your experience with the Edgenexus GSLB and would like you to have a realistic configuration to play with.

GSLB Policy

Testing the GSLB as your Primary DNS Server

Thank you.

Don’t take our word for it – take a free trial

Contact us

Try it now

Support

Global Server Load Balancer
(GSLB) Test Drive