Home > ServerTemplates > v13.5 LTS > ST > Load Balancer with HAProxy (v13.5 LTS)

Load Balancer with HAProxy (v13.5 LTS)

 

Table of Contents    

Long Term Support

Stable, tested ServerTemplate assets

   ►   Overview

Description

Configures a dedicated HAProxy load balancer and Apache server. The ServerTemplate contains scripts and inputs that allow it to securely connect to application servers private/public IP address. 

  • Supports multiple pools for load balancing across multiple applications with the same load balancer(s).
  • Supports both HTTP and HTTPS protocols
  • Supports multiple clouds

The ServerTemplate is designed to work with the following application ServerTemplates published by RightScale.

The ServerTemplate is one of the core ServerTemplates in a typical a three-tier website architecture. It also includes iptables management for clouds that do not support cloud-level firewall services like security groups.

Note: For a complete list of the ServerTemplate's features and support, view the detailed description under its Info tab.

Technical Overview

What is HAProxy?

HAProxy (High Availability Proxy) is a software load balancer that can run on servers in a cloud. You generally use it to direct client web traffic to cloud application servers.

The recipes associated with the ServerTemplate install the following applications:

  • HAProxy Version 1.4  (If you are looking for HAProxy version 1.5, see the Load Balancer with HAProxy 1.5dev (v13.3) ServerTemplate.)
  • Apache HTTP Server Version 2.2.3, which is used to process incoming client web requests and forward them to HAProxy
     

Because load balancers are generally externally accessible to client traffic and represent the first layer of a typical multi-tiered cloud server architecture, they are called front-end servers.

General Best Practices

  1. Select an instance type that best meets your application's performance requirements. If possible, select an instance type that offers more memory or guaranteed interface/bandwidth I/O, which is ideal for a load balancer server.
  2. Launch load balancer servers in different availability zones or datacenters (if supported by the cloud) for additional protection against outages in a single zone affecting your entire web application. Typically, application servers and HAProxy load balancer servers will be in the same cloud. However, you can have load balancer servers and application servers in different clouds for cloud failover and migration scenarios.

Support for Multiple Load Balancing Pools

Although the ServerTemplate is commonly used to launch a set of load balancer servers that round-robin incoming web requests for a single application across an array of dedicated applications servers, it can also be configured to load balance across multiple applications using multiple vhosts. For example, if you have two different applications (e.g. free and pay versions) where both applications connect to the same database, you could create a single deployment where the same load balancer servers send traffic to the appropriate application tier.

diag-3tierArray-v1.png

Example: 1 Load Balancing Pool

diag-3tier_mult_vhosts-v1.png

Example: 2 Load Balancing Pools

DNS

To support external availability, ensure that the public IP addresses for your load balancer servers are assigned to DNS A records pointing them to a fully qualified hostname. Typically, all load balancer IP addresses in a deployment will use the same hostname. (e.g. www.example.com)

Note: When deploying on the Amazon EC2 cloud, you will typically assign Elastic IP (EIP) addresses—similar to static IP addresses in the cloud—to your front-end load balancer servers. This enables you to set up DNS A records for your load balancers before you launch them, rather than after. For more information on EIPs, see Create Elastic IPs (EIP). Other clouds also support a similar concept where you can create or reserve public IP addresses that you can assign to a server at boot or runtime. Note: A public IP address can only be assigned to a single running server.

Support for HTTPS (SSL)

To use Secure Sockets Layer (SSL) to authenticate HTTPS requests, use the following inputs to specify the required information. This ServerTemplate's runbook includes instructions for configuring load balancer inputs to support HTTPS, which requires an SSL server certificate and private key in X.509/PEM format. We recommend configuring your server certificate and "SSL" inputs before launching your load balancer servers, which helps you avoid making major functional changes to a running server.

  • SSL Certificate
  • SSL Certificate Chain
  • SSL Enable
  • SSL Certificate Key
  • SSL Passphrase

Note: If the cloud uses security groups (e.g. EC2 Security Groups), you must launch the load balancer servers with a security group where TCP port 443 is open to allow HTTPS requests. See Configure Multiple Security Groups for a Multi-Tiered Deployment.

Session Stickiness

If you want a user's session to be maintained, set the 'Use Session Stickiness' input to 'True' to configure the load balancers to send a user's subsequent requests to the same application server. However, it's important to remember that session stickiness will only work if an end user's browser allows and stores the session cookie from the load balancer. Set to 'False' to disable session stickiness and configure the load balancers to distribute incoming requests in a round-robin fashion across all serviceable application servers.

Load Balancing Algorithm

By default, the load balancers will distribute incoming requests to the application servers in its load balancing pool in a round-robin fashion. (e.g. 1,2,3,1,2...)  However, the ServerTemplate also has built-in supports for a few other configurations. Use the 'Load Balancing Algorithm' to select the load balancing logic that's best suited for your application.

  • roundrobin (default) - Incoming requests are distributed in a round-robin fashion. (a-b-c-a-b-...)
  • leastconn - Incoming requests are sent to the server with the fewest number of active connections.
  • source - Incoming requests from the same client IP address will be sent to the same application server.


To learn more, see the HAProxy Configuration Manual.

Security and Firewall Permissions

The way in which you access your HAProxy load balancer servers depends on your cloud provider. For Amazon EC2, CloudStack, and other clouds that support security groups, you must have a security group defined with the appropriate ports open (TCP port 22 open for SSH access, web port 80 for HTTP or 443 for HTTPS external client access, and any other port and protocol access required by your servers).

Iptables is also enabled by default on all servers, with the default SSH port (22) and web-access ports (80 and 443) open. If you need to open other ports on the server besides the defaults (22, 80, and 443), you must create the appropriate rules using the "Firewall" inputs.

The ServerTemplate contains the following iptables rules:

  • TCP 22 - open to any IP
  • TCP 80 - open to any IP
  • TCP 443 - open to any IP


In a typical web architecture, load balancer servers receive a client's incoming request and establishes a connection with a validated application server in its load balancing pool. The diagrams and scenario below will explain how an HAProxy load balancing server connects to an application tier.

Network Level

In all clouds, regardless of whether they support security groups or not, Iptables is used to set IP-specific port permissions, which provides better firewall permission control than only using security groups because access permissions are IP-specific (not group-specific). 

For example, the load balancer servers are typically the only publicly accessible servers in a deployment. They will accept requests over HTTP and/or HTTPS protocols and forward the incoming requests to servers in the application tier below over the cloud's private network.

The application servers will only listen for requests from servers defined in its Iptables configuration file. Remember, in most cloud infrastructures, you typically cannot control what private IP address is assigned to an instance. For example, in EC2, instances are randomly assigned a private IP address at launch time.

An HAProxy load balancer server must first be granted access at the network-level before it can successfully make an application-level request to an application server in its load balancing pool. 

diag-lb_security_network-v1.png

Application Level

Once an application server has updated its network permissions to allow requests from its related load balancer servers, HAProxy will check the specified health check page, which is defined by the 'Health Check URI' input to make sure that it can establish a connection with the application server. An HAProxy load balancer server will only send requests to an application server in its load balancing pool that passes the health check test. If the specified health check page yields a page not found error (403), it will keep the application server in its load balancing pool, however it will not establish any client sessions with that server. However, HAProxy will continue to periodically ping the health check page and will add the application server back into the pool once it returns a positive health check.

diag-lb_security_applevel-v2.png

Example

The following scenario will explain how iptables and tags are used to configure secure firewall permissions in the cloud.

  1. A load balancer server is launched and becomes operational. At this point, there are no application servers in its load balancing pool. Below is an example screenshot of the application server's security group permissions.
    screen-SecGrp_LB-v1.png
     
  2. An application server is launched and becomes operational. It's configured to accept inbound requests from properly tagged load balancer servers. Below is an example screenshot of the application server's security group permissions.
    screen-SecGrp_App-v1.png
     
  3. Connectivity between a load balancer server and an application server is established by using tags. The requests for connectivity occur at both tiers. The load balancers connect to the application servers that belong to its load balancing pool(s) while application servers connect to its designated load balancer servers. Notice the tags in the screenshot below. In this example, the load balancing pool is 'default' (as defined by the 'Load Balance Pools' input). The tag denotes the load balancing pool name ('default') and whether it is a "load balancer" or "application" server.

    screen-Server_Tags-v3.png
     
  4. When an application server is launched, the 'app:do_loadbalancers_allow' (boot) script updates its iptables to accept requests from properly tagged load balancer servers. Another boot script is run on the application server ('lb::do_attach_request'), which runs the 'lb::handle_attach' operational script on all properly tagged load balancer servers. If the load balancer can successfully resolve the designated health check page (specified by the 'Health Check URI' input), it will add the application to its listener pool by adding the application server's private (default) or public IP address to its local haproxy configuration file (/etc/haproxy/haproxy.cfg). The screenshot below shows the application server updating its firewall permissions (using iptables) to listen on TCP port 8000 for requests from the private (default) or public IP of both load balancer servers.

    screen-Audit_AllowLB-v1.png
    • Similarly, when a load balancer server is launched, its 'app::request_loadbalancer_allow' (boot) script makes a request to all of the properly tagged application servers to allow requests from its private IP using iptables. Once the network permission is applied, the 'lb::do_attach_all' script adds the properly tagged application servers to its load balancing pool. If the load balancer can successfully resolve the designated health check page (specified by the 'Health Check URI' input), it will add the application to its listener pool by adding the application server's private IP address to local haproxy configuration file (/etc/haproxy/haproxy.cfg).
  5. Both the application and load balancer ServerTemplates use the 'Reconverge List' input to keep the load balancing pool up-to-date by periodically running their respective scripts every 15 minutes.
    • Load Balancer with HAProxy Server
      • Reconverge List: lb::do_attach_all
    • (PHP/Rails/Tomcat/Django/IIS) Application Server
      • Reconverge List: app::do_loadbalancers_allow

HAProxy Status Report (Health Check Page)

HAProxy includes a built-in health-checking feature that allows it to monitor registered application servers to determine if they are running and accepting connections (up). To enable this feature, each application server must have an identically named health check page that will return an HTTP 200 OK status back to the HAProxy server each time a load balancer issues an HTTP GET request. The page's contents are not important, but the page name should be unique, preferably containing a random number. (For example, using index.html as your health-check page, while permitted, is not recommended.) The health-check page helps distinguish your application servers from other servers running outside of your deployment.

Go to the HAProxy Status page to verify that all of the application servers are properly connected to the load balancer servers. The default location of the status page is defined by the 'Status URI' input. By default, it's set to the value <hostname>/haproxy-status. (e.g. http://www.example.com/haproxy-status)   You may optionally set the Status Page Username and Status Page Password inputs in order to require a user name and password to log in and view the page.

screen-HAProxyStatus-v3.png

Note: Application servers in the load balancing pool that are not serviceable because the server is booting/decommissioning or the health check test failed will be highlighted in red. In the screenshot above, two application servers (highlighted in green) are properly connected to the load balancer servers.

You can also SSH into a load balancer server to view more details.

Tip: Don't forget to switch to the "root" user after you open your SSH session to access the HAProxy configuration files. Also, when switching to root, ensure that you have the server_superuser dashboard permission (available from Settings > Account Settings > Users).

# sudo -i

# cat /etc/haproxy/haproxy.cfg
...
backend default_backend
        mode http
        balance roundrobin

        # Haproxy status page
        stats uri /haproxy-status


        # when cookie persistence is required
        cookie SERVERID insert indirect nocache

        # When internal servers support a status page
        option httpchk GET /
        http-check disable-on-404

        # Special server line that allow HAProxy to start with cookies enabled and no valid servers.
        server disabled-server 127.0.0.1:1 disabled

server 01-0HF614O 10.168.31.215:8000 check inter 3000 rise 2 fall 3 maxconn 500
        server 01-0PSQOVD 10.170.195.5:8000 check inter 3000 rise 2 fall 3 maxconn 500

Notice that the load balancers are configured to send requests to each application server's private or public IP address on the port specified by the Application Listen Port input. (Default: TCP port 8000).

If you need to open other ports on an application server besides the default TCP ports (8000), you must create the appropriate rules using the "Firewall" inputs as described in the ServerTemplate's runbook documentation.  

Note: For more information about iptables, refer to the Linux supporting documentation for this tool.

You must to post a comment.
Last Modified
13:32, 11 Sep 2013

Tags


Announcements

None

Glossary | 用語용어 Site Map | Site Help Community Corporate Site Get Support Dashboard Login
Doc Feedback Product Feedback Resources MultiCloud Marketplace Forums

Dashboard Status


© 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.