How to Manage Global Load Balancers
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 backend resources in specific regions or across different regions, which prevents the health of a service from depending on the health of a single server, cluster, or region.
After creating a global load balancer, you can add additional backend resources and domains, and modify its settings to fit your needs.
Add or Remove Resources
To add backend resources to a global load balancer, click Networking in the main menu, click the Load Balancers tab, and then click the global load balancer that you want to add resources to.
On the load balancer’s overview page, click the Connect Resources button. In the Add Resources modal, enter the name of the Droplet, regional load balancer, or the tag you want to add to the load balancer. The field populates with a list of resources that match your search criteria. Click the item that you want to add and then click the Add Droplets button. The selected resources are added to the load balancer’s backend node pool.
To remove backend resources, click the More button beside the resource you want to remove and then click Remove.
Additional Settings
To edit your global load balancer’s settings, click Networking in the main menu, 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
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
Traffic Distribution Priority
By default, global load balancers route traffic to your backend resources 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.
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).