How to Manage Global Load Balancers Beta

DigitalOcean fully manages Regional Load Balancers and Global Load Balancers, ensuring they are highly available load balancing services. Load balancers distribute traffic to groups of Droplets in specific regions or across different regions, which prevents the health of a backend service from depending on the health of a single server or a single region.


After creating a global load balancer, you can add additional Droplets and domains, and modify its settings to fit your needs.

Add or Remove Droplets

To add Droplets to a global load balancer, click Networking in the main navigation, click the Load Balancers tab, and then click the global load balancer that you want to add Droplets to.

On the load balancer’s overview page, click the Add Droplets button. In the Add Droplets modal, enter the name of the Droplet, or the tag associated with a group of Droplets, you want to add to the load balancer. The field populates with a list of Droplets and tags that match your search criteria. Click the Droplet or tag that you want to add and then click the Add Droplets button. The Droplets are added to the load balancer’s backend node pool.

The Add Droplet model

To remove Droplets, click the More button beside the Droplet you want to remove and then click Remove.

Additional Settings

To edit your global load balancer’s settings, click Networking in the main navigation, and then click Load Balancers to go to the load balancer’s overview page. From the overview page, click the Settings tab.

You can edit the following settings in the Settings tab:

Domains

In the Domains section, you can add or remove domains that route traffic to the load balancer, and subsequently, its backend Droplets. Follow the instructions in the Connect a Domain section of the setup guide to add a domain to your load balancer.

CDN Caching

Enabling CDN caching allows DigitalOcean’s CDN to cache your server’s responses. This places your most requested content closer to your users, and reduces the load on your origin server.

If you enable CDN caching, your server responses must include the Cache-Control HTTP header. This tells the CDN how long to cache the response for before requesting a new response from the origin server. For example, the following header, Cache-Control: public, max-age=3600, tells the CDN to cache the response for one hour.

The following example shows how to set up your server responses for caching using an Express JS server. The server response is set to cache for one hour.

    
        
            
const express = require('express');
const app = express();

// Middleware to set caching headers
app.use((req, res, next) => {
    res.set('Cache-Control', 'public, max-age=3600'); // Cache for 1 hour
    next();
});

app.get('/', (req, res) => {
    res.send('Hello World');
});

app.listen(3000, () => {
    console.log('Server running at http://127.0.0.1:3000/');
});

        
    

Forwarding Rules

Unlike regional load balancers, global load balancers can only have one forwarding rule, and the rule can only use HTTP protocols (HTTP, HTTPS, and HTTP2 ) to forward traffic to the backend Droplets. The rule can only forward traffic to either ports 80 and 443.

You can update the forwarding rule’s protocol and port in the Forwarding Rules section as needed.

Health Checks

In the Target section, you choose the Protocol (HTTP, HTTPS, or TCP), Port (80 by default), and Path (/ by default) that nodes should respond on.

In the Additional Settings section, you choose:

  • The Check Interval, which is how many seconds the load balancer waits between health checks.
  • The Response Timeout, which is how many seconds the load balancer waits between responses.
  • The Unhealthy Threshold, which is how many consecutive times a node must fail a health check before the load balancer stops forwarding traffic to it.
  • The Healthy Threshold, which is how many consecutive times a node must pass a health check before the load balancer forwards traffic to it.

The success criteria for HTTP and HTTPS health checks is a status code response in the range 200 - 399. The success criteria for TCP health checks is completing a TCP handshake to connect.

Note
HTTP and HTTPS health checks may fail with Droplets running Apache on Rocky Linux because the default Apache page returns a 403 Forbidden HTTP response code. To fix this, either change the health check from HTTP/HTTPS to TCP or configure Apache to return a 200 OK response code by creating an HTML page in Apache’s root directory.

In the Target section, you choose the Protocol (HTTP, HTTPS, or TCP), Port (80 by default), and Path (/ by default) that nodes should respond on.

In the Additional Settings section, you choose:

  • The Check Interval, which is how many seconds the load balancer waits between health checks.
  • The Response Timeout, which is how many seconds the load balancer waits between responses.
  • The Unhealthy Threshold, which is how many consecutive times a node must fail a health check before the load balancer stops forwarding traffic to it.
  • The Healthy Threshold, which is how many consecutive times a node must pass a health check before the load balancer forwards traffic to it.

The success criteria for HTTP and HTTPS health checks is a status code response in the range 200 - 399. The success criteria for TCP health checks is completing a TCP handshake to connect.

Note
HTTP and HTTPS health checks may fail with Droplets running Apache on Rocky Linux because the default Apache page returns a 403 Forbidden HTTP response code. To fix this, either change the health check from HTTP/HTTPS to TCP or configure Apache to return a 200 OK response code by creating an HTML page in Apache’s root directory.

Traffic Distribution Priority

By default, global load balancers route traffic to your Droplets in the nearest available region. However, if a region becomes unhealthy, traffic is routed to the nearest healthy region. You can change this to prioritize routing traffic to specific regions in the event of failover.

Sticky Sessions

Sticky sessions send subsequent requests from the same client to the same Droplet by setting a cookie with a configurable name and TTL (Time-To-Live) duration. The TTL parameter defines the duration the cookie remains valid in the client’s browser. This option is useful for application sessions that rely on connecting to the same Droplet for each request.

SSL

The SSL option redirects HTTP requests on port 80 to HTTPS on port 443. When you enable this option, HTTP URLs are forwarded to HTTPS with a 307 redirect. To redirect traffic, you need to set up at least one HTTP forwarding rule and one HTTPS forwarding rule.

HTTP Idle Timeout

By default, load balancer connections time out after being idle for 60 seconds. You can increase or decrease this amount of time to fit your application’s needs. You can set it for a minimum of 30 seconds and a maximum 600 seconds (10 minutes).