Port

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.

Protocol

Either TCP or HTTP. HTTP enables some additional options described below. HTTP KeepAlives are forced off in HTTP mode. NodeBalancers do not perform HTTPS/SSL termination. Use TCP mode to balance non-HTTP services.

Algorithm

How initial new connections are allocated across the backend Nodes.

• Round Robin - Allocates connections in a weighted circular order across the backend Linodes.
• Least Connections - Tracks each backend Linode's connection count, and allocates new connections to the node with the least connections.
• Source IP - Modulates the client's IP to allocate them to the same backend on subsequent requests. This works so long as the set of backend Linodes doesn't change, however Session Stickiness affects this behavior.

Session Stickiness

NodeBalancers have the ability for Session Persistence - meaning subsequent requests from the same client will be routed to the same backend Node when possible.

• None - No additional Session Stickiness will be performed.
• Table - The NodeBalancer itself remembers which backend a given client IP was initially load balanced to (see Algorithm, above), and will route subsequent requests from this IP back to the same backend, regardless of changes to the number of healthy backend nodes. If a backend node goes offline, entries in the table for that node are removed.
• HTTP Cookie - Requires the configuration protocol be set to HTTP. The NodeBalancer sets a cookie named NB_SRVID identifying the backend a client was initially load balanced to (see Algorithm, above), and will route subsequent requests from this IP back to the same backend, regardless of changes to the number of healthy backend nodes. If a backend node goes offline, the client is balanced to another backend and the cookie is rewritten.

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.

Passive

When servicing an incoming request, if a backend node fails to connect or times out it will be considered unhealthy and taken out of rotation.

Active

NodeBalancers also proactively check the health of back-end nodes by performing TCP connections or making HTTP requests. The common settings are:

• Check Interval - Seconds between active health check probes.
• Check Timeout - Seconds to wait before considering the probe a failure. 1-30.
• Check Attempts - Number of failed probes before taking a node out of rotation. 1-30.

Three different Health Check Type exist:

• TCP Connection - requires a successful TCP handshake with a backend node.
• HTTP Valid Status - performs an HTTP request on the provided path and requires a 2xx or 3xx response from the backend node.
• HTTP Body Regex - performs an HTTP request on the provided path and requires the provided PCRE regular expression matches against the request's result body.

Node Status

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.

Node Mode

Changes to a Node's Mode are applied within 60 seconds.

• Accept - allows the node to accept incoming connections so long as it is healthy.
• Reject - remove the node from rotation; discontinue health checks on this backend. Existing connections remain active.
• Drain - will only recieve connections from clients whose session stickiness points to this node.

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.

This guide is licensed under a Creative Commons Attribution-NoDerivs 3.0 United States License.

Last edited by Amanda Folson on Thursday, August 4th, 2011 (r2386).