|Table of Contents|
Long Term Support
Stable, tested ServerTemplate assets
To set up an HAProxy load balancer server or servers in a public or private cloud environment.
This tutorial describes the steps for launching one or more HAProxy load balancer servers in the cloud, using the Load Balancer with HAProxy ServerTemplate. However, in a typical three-tier server architecture there are two dedicated load balancer servers, which is necessary to support redundancy and failover for client communications.
For a technical overview of this ServerTemplate, see Load Balancer with HAProxy Server - Overview.
Although the Load Balancer ServerTemplate does not assume that any specific predefined credentials exist, we recommend that you set up the following credentials if you need to enter any of the following input values. This ServerTemplate assumes that all of these credentials are setup if you want to use the desired functionality that these inputs depend on.
For information on setting up credentials, see Create a New Credential.
If you are launching HAProxy load balancer servers in EC2, it's recommended that you use Elastic IPs. Typically, you will have two load balancers for redundancy purposes. If you haven't already done so, create an Elastic IP for each load balancer. Be sure to create the Elastic IPs in the AWS region (e.g. 'us-east') where you intend to launch the load balancer servers. See Create Elastic IPs (EIP).
Follow these steps to add a load balancer server to the deployment.
For production environments, it's strongly recommended that you have at least two load balancer servers (preferably in different availability zones or datacenters) for redundancy purposes. The easiest way to create a second load balancer is to simply clone and modify the first load balancer server.
The next step is to define the properties of your load balancer server or servers by entering values for inputs. As a best practice, you should define required inputs for the servers at the deployment level. For a detailed explanation of how inputs are defined and used in Chef recipes and RightScripts, see Inputs and their Hierarchy.
To enter inputs for the Chef recipes that will run on your load balancers, open the deployment's Inputs tab, click Edit, and use the following settings to configure input values. We recommend that you set up credentials for password values and any other sensitive data as shown in the examples.
|Input Name ||Description ||Example Value |
|Virtual Host Names|| |
Comma-separated list of host names for which the load balancer will answer website requests and forward to the correct backend pool of application servers. This value is used to name backend server pools. A single entry of any name, e.g. 'default' or 'applistener', will mimic basic behavior of one load balancer with one pool of application servers.
If you are using multiple virtual host names, the first entry will be the default backend and will answer for all host names that are not listed. Typically, you will specify hostnames for each load balancing pool. (e.g. app1.example.com,app2.example.com)
Note: Application servers can only provide a single host name and will join server pool backends using this name (for example, default, www.mysite.com, api.mysite.com, default.mysite.com).
|Health Check URI|| |
Relative URI (resource path), including the preceding forward slash, pointing to the health-check page on your application servers. For example, /hlthchk378923.html points to the file hlthchk378923.html in the application directory on your application servers. During the testing phase, you may leave this input set to the default (/) value, indicating that health check pages are not included on the application servers.
For the DotNetNuke 3 tier example, use 'text:/Default.aspx
|Use Session Stickiness||Leave this value set to "true" to enable session persistence (stickiness). In this case, the load balancer will route client requests made in the same session to the same application server, via a cookie. Set to "false" to disable session stickiness, in which case the load balancer routes each new client request to the next available application server, regardless of session.|| |
For the 3-tier tutorial, use:
Status Page Password
Status Page Username
Username and password (if required) to access the HAProxy status report page, which is accessible from the URI set in Status URI.
|Status URI|| |
Relative URI (resource path) pointing to the HAProxy status report page. If you use the default value (/haproxy-status) you can append this value to the hostname or public DNS/IP address for your load balancer to access the status report—for example, http://example.com/haproxy-status or http://188.8.131.52/haproxy-status.
|Input Name ||Description ||Example Value |
|Application Name||On your application servers, the server subdirectory where your application code files are stored. This must match the Application Name input for your application servers.||text: myapp|
|Multi-Processing Module||Set to the value matching the application servers that your load balancer will connect to: "prefork" for PHP servers, or "worker" for Rails, Apache Tomcat, and stand-alone application servers.||text: prefork|
|SSL Certificate||Contents of the X.509/PEM-format SSL server certificate used for enabling HTTPS communications.|| |
|SSL Certificate Chain||The certificate authority (CA) certificate chain associated with the server certificate used to set up HTTPS communications.|| |
|SSL Enable||Set to "true" to enable SSL ('https'). |
Set to "false" to disable SSL. (default)
|SSL Certificate Key||The SSL server certificate's private key, in PEM format.|| |
|SSL Passphrase||If required by an SSL certificate, you must provide the passphrase so Apache can start.|| |
If you are using Elastic IPs or already know the public IP addresses that will be used by the load balancer servers, you might have already set up the DNS records for the load balancing tier. However, if you do not know the public IP addresses that will be assigned to the load balancer servers, you must manually set up the DNS records after the servers have been launched. Once the servers become operational (and have been assigned their respective public IP addresses), create or update the DNS records with your DNS provider. Each load balancer server should have its own DNS record with the same hostname (e.g. www.example.com) that points to its public IP address.
The DNS records for the HAProxy load balancing tier should direct traffic from the associated hostname (FQDN) (e.g. www.example.com) to the application servers in its load balancing pool.
© 2006-2014 RightScale, Inc. All rights reserved.
RightScale is a registered trademark of RightScale, Inc. All other products and services may be trademarks or servicemarks of their respective owners.