Global Server Load Balancing with NS1 and NGINX Plus

Global server load balancing (GSLB) is the intelligent distribution of traffic across server resources located in many points of presence (PoPs). GSLB is generally implemented by controlling the responses to DNS requests, directing each user to the most appropriate destination IP address based on the availability, performance, and proximity of each PoP.

Many DNS providers offer some form of GSLB. NS1 has one of the most advanced solutions available as a service, with a rich API that PoPs can use to dynamically inform the NS1 servers about their availability and current loads.

This document describes how to use NGINX’s NS1 agent to interface with the NS1 service, enabling sophisticated GSLB across many PoPs that are powered by F5 NGINX Plus. You can colocate an instance of the agent alongside each NGINX Plus instance, or configure an agent to query one or more NGINX Plus instances remotely. (This guide covers only the colocation option.)

The agent periodically queries the NGINX Plus API for several metrics that it uses to calculate the current number of active connections and load average on the NGINX Plus instance, and reports those metrics to NS1. The agent can also be configured to report the status of the site as up: true or up: false (that is, down).

The agent supports the following capabilities:

Remote health checks to direct clients to an available Point of Presence (PoP)

Local capacity checks to ensure clients are directed to a PoP with healthy servers

Central capacity balancing for clients across PoPs according to the load of each PoP and draining of traffic from overloaded PoPs

The solution functions with other NS1 capabilities, such as geo‑proximal routing to direct each client to the closest PoP.


Verifying Traffic Redistribution When a Threshold Is Exceeded

You can configure NS1 to redistribute traffic away from a given NGINX Plus instance when a load metric for the instance exceeds one or more thresholds that you set. 

The thresholds are set in an NS1 shed filter. NS1 describes the shifting of traffic to a different IP address as “shedding load” from the current IP address.

Verify NS1 redistributes traffic correctly when the number of active connections on an instance exceeds the set threshold.

Creating the Shed Filter
Perform these steps to create the shed filter:


#5
Back on the A record’s details page, in the Filter Chain column click the Shed Load box. It expands to display an explanation of how the filter works. Click the label on the white box at the bottom of the explanation and select Active connections from the drop‑down menu.


Testing the Threshold
With the shed filter in place, we’re ready to verify that NS1 shifts traffic to the next‑nearest NGINX Plus instance when the number of active connections on the nearest instance exceeds the high watermark (upper threshold) of 5. As noted in Step 7, we’ve set a very small value so we can quickly see the effect when it’s exceeded. With the low watermark setting of 2, NS1 will start shifting traffic probabilistically when there are three active connections and definitely when there are five or more connections.

We have written a script that continuously simulates more than four simultaneous connections. We have also configured the backend app to perform a sleep, so that the connections stay open long enough for the agent to report the number of active connections to NS1 before they close.