Table of Contents | |||
Infinity Leading edge features |
|
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 (v14 Infinity) 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 (v14 Infinity).
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 is 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 |
Load Balance Pools | Comma-separated list of URIs or FQDNs for which the load balancer will create server pools to answer website requests. The last entry will be the default backend and will answer for all URIs and FQDNs not listed here. A single entry of any name (for example, default) will mimic basic behavior of one load balancer with one pool of application servers. This will be used for naming server pool backends. Note: Application servers can provide any number of URIs or FQDNs to join corresponding server pool backends (for example, www.mysite.com, api.mysite.com, /serverid, default). | text: www.mysite.com, api.mysite.com
For the standalone and 3-tier tutorials, use: text:default |
Load Balancing Algorithm | Defines which load balancing algorithm is used to establish connections with application servers in the load balancing pool.
| text: roundrobin |
Use Session Stickiness | Determines session stickiness. Set to 'True' to use session stickiness, where the load balancer will reconnect a session to the last server it was connected to (via a cookie). Set to 'False' if you do not want to use sticky sessions; the load balancer will establish a connection with the next available server. | text: true |
HAProxy SSL Certificate | PEM formatted string containing SSL certificates and keys for SSL encryption. To configure HAProxy without SSL encryption, do not set this input. | nil |
Statistics Page Password | Password to access HAProxy statistics page | nil |
Statistics URI | HAProxy statistics URI | text: /haproxy-status |
Statistics Page Username | The username that is required to access the load balancer statistics report page | nil |
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.
Launch new application servers that will connect to the HAProxy load balancers or connect any operational application servers using the 'rs-haproxy::frontend' operational script.
The easiest way to check the status of the HAProxy load balancing pool is to view the HAProxy Status page. By default, the Status URI input is set to /haproxy-status.
If you created DNS A Records for the load balancer servers, you can visit the HAProxy Status page by entering your <FQDN>/haproxy-status in a web browser window. (e.g. josh-www.rightscaleblue.com/haproxy-status)
If DNS A Records are not used, you can also use the public DNS name or IP of a load balancer server. (e.g. http://192.34.456.77/haproxy-status)
Each application server that is successfully added to the load balancing pool will be highlighted in green. In the example screenshot above, two application servers are in the load balancing pool and are able to receive requests from the load balancer servers. Notice that each application server is identified by its universally unique identifier (UUID) that RightScale assigns to each instance. You can find the server's UUID in its machine tags or under its Info tab.
Application servers highlighted in red are not included in the load balancing pool and will not receive any client requests. There are several reasons why an application server may be highlighted in red.
© 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.