|Table of Contents|
| || |
Leading edge features
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.
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.
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:
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.
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.
Example: 1 Load Balancing Pool
Example: 2 Load Balancing Pools
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.
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.
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.
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.
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.
To learn more, see the HAProxy Configuration Manual.
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:
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.
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.
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.
The following scenario will explain how iptables and tags are used to configure secure firewall permissions in the cloud.
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.
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.
|Glossary | 用語 | 용어||Site Map | Site Help||Community||Corporate Site||Get Support||Dashboard Login|
|Doc Feedback||Product Feedback||Resources||MultiCloud Marketplace||Forums|
© 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.