> For the complete documentation index, see [llms.txt](https://docs.glesys.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.glesys.com/platform/control-panel/api/real-world-use-cases/load-balancing-and-failover-using-the-glesys-api.md).

# Load balancing and failover using the Glesys API

By using "DNS round robin" together with the Glesys API to add or remove servers, you achieve both load balancing and failover.

***

One of the simplest ways to load‑balance a web service is by using “DNS Round Robin.” In its most basic form, you have two servers, each with its own IP address. Then you create duplicate A records for the domain—one pointing to each server—so that traffic is distributed between the two servers. Below is an example of how to automatically remove and add those records.

## Automating failover

One of the issues with “DNS Round Robin” is that if one of the servers goes down, half of the visitors will be unable to reach the service.

This can, for example, be remedied using the Glesys API with a simple script shown below.

The Bash script runs on both servers. To check whether the other server is still functioning, its webpage is scanned for a specific text string. If that string is not found, the domain’s DNS records are changed so that both point to the working server. After that, the script continues to test whether the site is up. When the site comes back online, the DNS records are switched back so that both servers are used again.

To make this work, the script must be run on both servers, and the values for `THIS`  and `THAT` need to be adjusted so that they reference each other.

{% hint style="danger" %}
Keep in mind that this is merely an illustrative example meant to spark ideas about how you can leverage DNS and the Glesys API to achieve powerful effects in a simple way. It is not intended to be used directly for load‑balancing production servers.
{% endhint %}

{% code title="failover.sh" %}

```bash
#!/bin/bash
#Note: This script is hard‑coded with record IDs. Check them with:
#/usr/bin/curl -X POST -d domain=example.com -k --basic -u cl12345:API-KEY https://api.glesys.com/domain/list_records
THIS="10.0.0.1"
THAT="10.0.0.2"
URL="http://$THAT/blog/testblog"
SEARCH="Some text on the site"
RECORD1="12345"
RECORD2="12346"
ACCOUNT="CL12345"
APIKEY="SECRET"

getStatus() { /usr/bin/wget -O - $URL 2> /dev/null | grep "$SEARCH" &>/dev/null; echo "$?"; }
setRecords(){
       echo "setting records to $1 and $2";
       /usr/bin/curl -X POST -d record_id=$RECORD1&data=$1 -k --basic -u $ACCOUNT:$APIKEY https://api.glesys.com/domain/update_record
       /usr/bin/curl -X POST -d record_id=$RECORD2&data=$2 -k --basic -u $ACCOUNT:$APIKEY https://api.glesys.com/domain/update_record
}

while :
do
       STATUS=$(getStatus)
       if [ $STATUS -eq 1 ]; then
               echo "Site is down!";
               setRecords "$THIS" "$THIS"
               while [ $STATUS -eq 1 ]; do
                       sleep 20
                       STATUS=$(getStatus)
                       echo "still down"
               done
               setRecords "$THIS" "$THAT"
       fi
       echo "Site is up!";
       sleep 60
done
```

{% endcode %}

With the solution above, you can build a service with very high availability. For example, combine colocation in our Stockholm data center with a virtual server in Falkenberg, Amsterdam, Oslo, or London.

More information about the API is available on [GitHub](https://github.com/glesys/api-docs/wiki). There are also some more [examples on GitHub](https://github.com/glesys/api-docs/).