Select Page

Radware AppDirector – GSLB Configuration

Radware AppDirector – GSLB Configuration

To help provide site redundancy for critical business applications, we decided to pursue Radware’s GSLB (Global Server Load Balancing) solution running on the AppDirector. Radware’s GSLB provides the ability to automatically provide site selection based on proximity to the datacenter, availability of services, and/or load at each location. Unfortunately after scouring through Radware’s documentation and researching online I still couldn’t seem to nail down the proper configuration. The following processes should help explain the proper configurations for a few different scenarios.

Pre-Work

The below assumes that the following has been configured:

  1. Create L4P virtual interface to use for DNS queries.
  2. Set glue records for domain pointing to a public IP NAT’ed to virtual interface above. (Can also use DNS delegation or NS records for individual sub domains).

Step 1: Create new Application Server in Local Farm Table for your Distributed AppDirector

By now, you should have two AppDirectors (preferably two pairs running VRRP) at each location. Each should have a Farm, Application servers, and VIP created for your respective application. As stated above, the first step should be creating a new application server in the farm at each location which will point to the opposite Distributed AppDirector. You need to create one of these for EVERY site/application you intend to use GSLB for if they are using different farms & VIPs.

AppDirector –> Severs –> Applications Servers –> Table

Required Changes all below – also marked on the screenshot below

  1. Server Name – Keep names consistent for Distributed AppDirector entries
  2. Server Address  – Should be the public (NAT’ed) address of the other site for this application
  3. Server Port – Keep as None
  4. Type – Change to Distributed AppDirector
  5. Operation Mode – If this site will be Active, keep as Regular. If this site will be a backup/DR site, change to Backup.

Step 2: Create DNS records on AppDirector.

As you should know by know, DNS is a critical part of any GSLB deployment, providing direction for the clients. Here is no different. Your AppDirector must be able to respond to DNS queries from your clients as the authoritative DNS server for your domain, telling them which public IP address to hit. Note: Make sure to first enable DNS under AppDirector –> DNS –> Server.

AppDirector –> DNS –> Host Names

Configure the following required fields below – also marked in screenshot below.

  1. Host Name – URL of your site/application
  2. L4 Policy Name – Choose the L4P that will service this site/application
  3. Farm Name – Choose the farm that will service this site/application
  4. External NAT Address – Use this ONLY if you are NAT’ing upstream from the AppDirector (ie Firewall). If your L4P IP address is your public IP, this field isn’t required.
  5. Preferred Resolve IP: Automatically populates IP that corresponds to your L4P

Step 3: Enable DNS & Application Redirection for Farm

In order to have the AppDirector redirect clients, you need to enable redirection on the individual farms that will serve your clients. You can also enable Application Redirection, which assists in redirecting the client during a transaction if the original site becomes unavailable.

Configure the following required fields below – also marked in screenshot below.

AppDirector –> Farms –> Redirection

  1. Select Farm that will service your site/application
  2. DNS Redirection – Change to Enabled
  3. Application Redirection Mode – Change to Enabled

A few additional fields to note here include the Farm Distribution Threshold, which dictates how local load balancing is handled; and the Farm Capacity Threshold which will dictate how site to site load balancing is handled. For example, if Farm1 in Datacenter1 reaches its Farm Capacity Threshold, LRP reports to the AppDirector in Datacenter2 that it can no longer accept incoming connections from the other distributed AppDirectors for that farm. All new traffic will be directed to Farm1 in Datacenter2 until the number of connections in Datacenter1 drops below the threshold.

Step 4: Creating Load Reports

Load reports establish the communication between the AppDirectors, allowing them to report the status of their local farms and servers. Without load reports, one of the applications or farm, or worse – the entire datacenter, could become unavailable yet users would still be redirected to it. As shown above, load reports not only communicate the status of the farm but also the number of connections at each location. Make sure to create a load report at BOTH locations. It’s worth noting that this was the trickiest part of the entire GSLB setup and where documentation seemed to be unclear.

Configure the following required fields below – also marked in screenshot below.

AppDirector –> Distributed System –> Report Configuration

  1. Distributed Farm Name – Enter the exact name of the farm on the other AppDirector (I’ve found that it is case-sensitive – as in many other areas within the UI)
  2. Farm Name – Select the local farm name from the drop down list.
  3. Distributed Server – The public address of the application in the local datacenter. This should match the application server’s IP you created in Step 1 for the other AppDirector.
  4. L4 Policy Name – Select the local L4P that will server the application.
  5. Destination Address – Enter the IP where the report will be sent to (ie The IP address of the AppDirector in the other datacenter – likely an IP assigned to G-1 or G-2) Do not use the VRRP address here – which was my first inclination.
  6. Redundant Destination Address – Exactly like above but the IP of the second AppDirector in the other location (if you are running VRRP).

If you start getting syslog events with warnings such as “Illegal Report from X.X.X.X” than the IP addresses are likely incorrect or don’t match the opposite Distributed AppDirector setup in Step 1.

Conclusion

At this point, you should have a working GSLB solution and it should be functioning properly. To test, ping your application/site multiple times. The DNS resolution will likely resolve to one public IP and than the other. If not, check the status of the application servers at each location, making sure they are administratively up and that a health check from the HMM or Farm level check aren’t failing. I currently use the AppDirector to load balance both publicly available and private sites (only available internally) and it works perfectly.

*Note: Please comment if this helped you, if you have questions, or let me know what else you’d like to see posts on.

About The Author

Bryan Krausen

Bryan Krausen is currently working as a Technical Architect with experience in a vast number of platforms. Bryan has been active within the VMware vExpert community for several years and is the leader of the Louisville VMware User Group (VMUG) and Louisville AWS User Group.

Leave a reply

Your email address will not be published.