Creating a Pool: The HTTP Type
We offer several types of load balancing pools, which each have different advantages.
- HTTP: the default type
- HTTPS: standard HTTPS pool
- Session persistent pools
- https_offload, http_fast, http_secure_redirect, and smtp. Described at Load Balancing Pool Types
Below we walk through a standard HTTP pool, which is the default, if no other type is selected at pool creation. Please note that you cannot change the pool type after creation. The only way to change a pool type is by deleting it and re-creating it with a new type.
Reserve a VIP
Each load-balancing pool has its own dedicated port number and virtual IP address (VIP), which is used to access the pool and its nodes from the outside world. To create a pool, you first reserve a VIP using the manage-lb-ip command. That VIP is reserved to you alone, and you can use it across multiple load balancing pools, as long as each pool has a unique VIP-port combination.
Create and Name the Pool
Next, use that IP address and the manage-lb-pool commands to create and name a pool. You will need to specify an IP, a port, and a name and will also have other options. We suggest that you use a straightforward name such as "web-frontend," or "pixel-servers."
It's easy to add individual nodes using the
"manage-lb-pool add-node" command. Nodes are referred to as "
ip:port", for example "
126.96.36.199:80". Once you've added a node, you can make sure that it's available via the "
manage-lb-pool status" command.
- For smoother load balancing and even response times, it's best to keep the CPU and memory specs on your instance nodes consistent.
- You can change the port associated with a node. To do so, issue two CLI commands in sequence: "
manage-lb-pool add-node" with the new
ip:portcombination, and "
manage-lb-pool remove-node" with the old
ip:portcombination. Note that changing a port will not affect the pool type (HTTP, HTTPS, etc.)
Load Balancing Method
The load balancing method is the logic a load balancer uses to route traffic to pool members. Note that the LTM will balance TCP connections and not individual requests. This means that if you select, say, "Round Robin" as a load-balancing method and load a URL in a browser you will continue to hit the same node until you start a new TCP session.
The available method options are below. The default method is round robin, but you can select a different one when creating or modifying your pool using the
--method parameter with the manage-lb-pool command. Possible values are: round_robin, fastest_node_address, least_connection_members, and observed_node_address. If you are unsure which method to choose, use a monitoring tool such as Ganglia and try various options. Stick with the one that results in the most predictable and even load distribution.
This is the default load balancing method. The Round Robin method passes each new connection request to the next server in line, eventually distributing connections uniformly across the array of machines being load balanced. Round Robin works well in most configurations, especially if the equipment that you are load balancing is roughly equal in processing speed and memory.
The Fastest Node method passes a new connection based on the fastest response of all currently active nodes. This method may be particularly useful in environments where nodes are distributed across different logical networks.
The Least Connections method passes a new connection to the node that has the least number of current connections. Least Connections works best in environments where the equipment you are load balancing has similar capabilities.
The Observed Connections method uses a combination of the logic used in the Least Connections and Fastest methods. Nodes are ranked based on a combination of the number of current connections and the response time. Observed Connections works well in any environment, but may be particularly useful when node performance varies significantly.
Monitoring Your Nodes
Every 5 seconds, the LTM sends a request string to each individual node and looks for a search string in response. The search string can be anywhere in the HTTP response header or the body of the response. If no response comes within 16 seconds, or the search string is incorrect, the load balancer records a node as down and stops sending traffic to it. If no search and request string are explicitly set, "
GET / HTTP/1.0\r\n\r\n" and "
200 OK" are the defaults.
If you like, you can specify a request and search string using the manage-lb-pool command. Then if you want to pull a node out of rotation, simply make a change to the search string in that node and the LTM will fail the node. Here's a specific example.
Suppose your web server speaks HTTP/1.0 and you're going to set your monitor to check if it returns the content of "
- You'll add the file "status.html" to all of your nodes.
- The request string should be "
GET /status.html HTTP/1.0\r\n\r\n" ("
\r\n" is a carriage return / line feed (CR/LF) sequence).
- The search string should either be the default "
200 OK" (which appears in standard HTTP headers) or a value of your choosing in your
- To intentionally fail a node, delete or modify the node's
For a closer look at this example, see Monitoring Your Nodes.
HTTP Headers for Client IP Addresses
It may appear that all requests to your load balanced applications come from the IP address of the AppNexus F5 load balancer. Information on the real client IP address will come in an X-Forwarded-For header by default. To extract this IP data, please see these short instructions from F5: http://devcentral.f5.com/weblogs/macvittie/archive/2008/06/02/3323.aspx
If you'd like to use something other than HTTP or HTTPS, we can do that for you manually. Please contact support by by creating a ticket at https://portal.appnexus.com/ or by sending an email to firstname.lastname@example.org.