Regardless of the option you choose, using some sort of load balancing solution in your infrastructure is highly recommended. However, if you need a solution that is cost-effective up front, you can setup an open source load balancing solution such as HAproxy.
HAProxy is an open source load balancer that functions as a fast proxy server and provides high availability for TCP and HTTP-based applications. HAproxy is easy to install on a SmartMachine and includes support for SMF. Although not installed on a SmartMachine by default, HAproxy is available as a package in pkgsrc on any SmartMachine you provision. Once installed, you will need to configure HAproxy in various ways to fit your environment.
In this topic:
To install HAproxy, run this command:
Installation of HAproxy includes an SMF manifest that supports the enabling, disabling, and restarting of the HAproxy persistent daemon process. You can enable that process by running:
|You can learn more about using SMF in the Joyent Public Cloud here.|
The default location for HAproxy is:
The default location for the HAproxy configuration file is:
There are two specific components of an HAproxy configuration that you will need to address: configuration properties and the load balancing algorithms your configuration will use.
HAproxy is installed with a configuration file that is populated with default values for various parameters. Before you start using HAproxy, you will need to set these parameters to values that support your environment. HAproxy configuration parameters are broken down into three primary components:
- The arguments from the command-line, which always take precedence
- The global section, which sets process-wide parameters
- The proxies sections, which you can set as defaults, listen,
frontend and backend.
Below are some notable parameters.
|mode||tcp, http, or health|| This parameters sets the mode for the proxy instance. Use one of the three following values with this parameter.
|maxconn||number||Fix the maximum number of concurrent connections on a frontend. Consumes about 17 kB of RAM per established connection. That means that a medium system equipped with 1GB of RAM can withstand around 40000-50000 concurrent connections if properly tuned.|
|retries||number||Set the number of retries to perform on a server after a connection failure.|
|option||forwardfor, httplog, tcplog, logasap, dontlognull|| These are options you can set in your configuration. You can set any number of these options in your configuration by including the option parameter multiple times.
Proxy sections are defined in the following way:
|defaults <name>|| Sets default parameters for all sections following its declaration.
| frontend <name>
|| Describes a set of listening sockets accepting client connections.
| backend <name>
|| Describes a set of servers to which the proxy will connect to forwarded incoming connections.
| listen <name>
|| Defines a complete proxy with its frontend and backend parts combined in one section.
|All proxy names must be formed from upper and lower case letters, digits, '-' (dash), '_' (underscore) , '.' (dot) and ':' (colon). ACL names are case-sensitive, which means that "www" and "WWW" are two different proxies.|
The algoritm you define determines how HAproxy balances load across your servers. You can set the algorithm to use with the balance parameter.
Requests are rotated among the servers in the backend.
|Servers declared in the backend section also accept a weight parameter which specifies their relative weight. When balancing load, the Round Robin algorithm will respect that weight ratio.|
Each server is used in turn, according to the defined weight for the server. This algorithm is a static version of the round-robin algoritm, which means that changing the weight ratio for a server on the fly will have no effect. However, you can define as many servers as you like with this algorithm. In addition, when a server comes online, this algoritm ensures that the server is immediately reintroduced into the farm after re-computing the full map. This algoritm also consome slightly less CPU cycles (around -1%).
Each server is used in turn, according to the defined weight for the server. This algorithm is a static version of the round-robin algoritm, which means that changing the weight ratio for a server on the fly will have no effect. However, you can define as many servers as you like with this algorithm. In addition, when a server comes online, this algoritm ensures that the server is immediately reintroduced into the farm after re-computing the full map. This algoritm also consome slightly less CPU cycles than the Round Robin algorithm (around -1%).
A hash of the source IP is divided by the total weight of the running servers to determine which server will receive the request. This ensures that clients from the same IP address always hit the same server, which is a poor man's session persistence solution.
This algorithm hashes either the left part of the URI (before the question mark) or the whole URI (if the whole parameter is present) and divides the hash value by the total weight of the running servers. The result designates which server will receive the request. This ensures that the proxy will always direct the same URI to the same server as long as all servers remain online.
This is used with proxy caches and anti-virus proxies in order to maximize the cache hit rate. This algorithm is static by default, which means that changing a server's weight on the fly will have no effect. However, you can change this using a hash-type parameter.
|You can only use this algorithm for a configuration with an HTTP backend.|
The URL parameter specified in argument will be looked up in the query string of each HTTP GET request.
You can use this algorithm to check specific parts of the URL, such as values sent through POST requests. For example, you can set this algorithm to direct a request that specifies a user_id with a specific value to the same server using the url_param method. Essentially, this is another way of achieving session persistence in some cases (see the official HAproxy documentation for more information).
The following are example configurations for HAproxy. You can use these as a base for your own configurations.
|The IP addresses noted here are just an example. If you use these examples as a template, ensure you modify relevant IPs to fit your environment.|
For more information on HAproxy, see the full set of HAproxy documentation found here.