This is the NodeBalancer reference guide. Please see the NodeBalancer How-To for practical examples.
Click the NodeBalancers tab, and then "Add a NodeBalancer". You must choose the same location as your back-end Linodes for a given deployment.
Here you may adjust the NodeBalancer's display label, along with the 'Client Connection Throttle'. The connection throttle limits the number subsequent new connections from the same client IP address.
Each NodeBalancer config adds another port that the NodeBalancer will listen on. For instance, if you wish to balance both port 80 and 81, you'll need to add two configuration profiles to your NodeBalancer.
The public port for this configuration. Ports 1 through 65534 are available for balancing, provided that the port is not already in use by another config.
You can choose either TCP, HTTP, or HTTPS. HTTP and HTTPS enable some additional options described below.
TCP: Use TCP mode to balance non-HTTP services.
HTTP: HTTP KeepAlives are forced off in HTTP mode.
HTTPS: With HTTPS selected, your NodeBalancer will terminate SSL connections. As with HTTP mode, KeepAlives will be disabled and the client's IP address will be provided in the X-Forwarded-For header.
If HTTP or HTTPS is selected, the NodeBalancer will add an X-Forwarded-Proto header, with a value of either http or https, to all requests sent to the backend. The header value is based on the type of request (HTTP or HTTPS) originally received by the NodeBalancer.
Note that HTTPS requests (and HTTP requests, for that matter) are terminated on the NodeBalancer itself, and that's where the encryption over a public network ends. NodeBalancers use the HTTP protocol to communicate with your backends over a private network. You should have your backends listen to the NodeBalancer over HTTP, not HTTPS.
How initial new connections are allocated across the backend Nodes.
NodeBalancers have the ability for Session Persistence - meaning subsequent requests from the same client will be routed to the same backend Node when possible.
If you need Session Persistence it is our recommendation to utilize both the Source IP algorithm in combination with either Table or HTTP Cookie if possible.
If you select the HTTPS protocol, the Certificate and Private Key fields will appear.
Copy your certificate into the Certificate field. If you have chained certificates, you can copy all of them into the text field, one after the other.
Copy your passphraseless private key into the Private Key field.
NodeBalancers perform both passive and active health checks against the backend nodes. Nodes that are no longer responding are taken out of rotation.
When servicing an incoming request, if a backend node fails to connect, times out, or returns a 5xx response code (excluding 501 and 505), it will be considered unhealthy and taken out of rotation.
NodeBalancers also proactively check the health of back-end nodes by performing TCP connections or making HTTP requests. The common settings are:
Three different Health Check Type exist:
NodeBalancers work over the private network. Backend nodes must have a private IP configured via static networking.
Once you have established a basic configuration, you will be asked to set up "Nodes". Nodes are combinations of addresses and ports that you wish to balance.
A Node's status, as seen from the perspective of the NodeBalancer, is indicated via its status field. It either has a value of UP or DOWN. The Last Status Change field also indicates the last time this node's status changed.
Changes to a Node's Mode are applied within 60 seconds.
The use-case for Drain would be to set a node to Drain a day or so in advance of taking the node down. That way existing sessions would likely have ended.
NodeBalancers add an X-Forwarded-For (XFF) HTTP header field, which allows your nodes to identify a client's originating IP address. This is useful for logging purposes. Here's an example XFF HTTP header:
You'll need to configure your web server software to use the XFF header.
If you're using the Apache web server, you can use the mod_rpaf module to replace REMOTE_ADDR with the clent's IP address in the XFF header. After you install the module, you'll need to specify 192.168.255.0/24 as a proxy in httpd.conf.
If you're using the Nginx web server, you can add the following lines to your Nginx configuration file:
real_ip_header X-Forwarded-For; set_real_ip_from 192.168.255.0/24;
This will allow Nginx to capture the client's IP address in the logs.
This guide is licensed under a Creative Commons Attribution-NoDerivs 3.0 United States License.
Last edited by Alex Fornuto on Wednesday, March 26th, 2014 (r4349).