Note: Please go to docs.rightscale.com to access the current RightScale documentation set. Also, feel free to Chat with us!
Home > ServerTemplates > v13.5 LTS > ST > Load Balancer with HAProxy (v13.5 LTS) > Load Balancer with HAProxy (v13.5 LTS) - Runbook

Load Balancer with HAProxy (v13.5 LTS) - Runbook

 

Table of Contents    

Long Term Support

Stable, tested ServerTemplate assets

  ►  Runbook

After successfully setting up your HAProxy load balancer server or servers in the cloud using the Load Balancer with HAProxy (v13.5 LTS) - Tutorial, you may need to perform the following common administrative operations.

Common Operational Tasks

Check HAProxy Status

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

 

screen-3tier_haproxy_status-v1.png

Each application server that's 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.

  • The application server's firewall permissions are not allowing ingress communication from the load balancers. Check the firewall permissions of the application server (as defined by its security group, if applicable, and/or iptables rules).
  • The application server is not operational. Perhaps the application server is in the booting or decommissioning state.
  • The health check failed. 

Enable HTTPS (SSL)

By default, HAProxy load balancers that you set up by following instructions in the Load Balancer with HAProxy (v13.5 LTS) - Tutorial, have port 80 open for client HTTP connections to the server. To also enable client HTTPS communications via port 443, you must set related "SSL" inputs as shown in the following table. We recommend that you set up credentials for password values and other sensitive data as shown in the examples. (For Amazon EC2, CloudStack, and other clouds that support security groups, your load balancers must have an associated security group set up with TCP port 443 open for client connections to allow HTTPS access.)

This setup also requires an SSL server certificate and private key in X.509/PEM format. You can create a self-signed certificate using a tool such as OpenSSL, or obtain a server certificate signed by a recognized certificate authority (CA) such as VeriSign. See How do I create an SSL certificate for my web server?

It's strongly recommended that you set the SSL inputs at the deployment level before launching the load balancer servers. If the load balancer servers are already running, it's recommended that you relaunch the load balancer servers so that it can inherit the correct values for the SSL inputs.

Input Name Description Example Value
SSL Certificate The contents of the SSL server certificate, in X.509/PEM format. cred:SSL_CERTIFICATE
SSL Certificate Chain The certificate authority (CA) certificate chain associated with the SSL server certificate, when applicable. cred:SSL_CERTIFICATE_CHAIN
SSL Enable Set to "true" to enable SSL communications for your load balancer. text:true
SSL Certificate Key The SSL server certificate's private key, in PEM format. cred:SSL_CERTIFICATE_KEY
SSL Passphrase If the SSL certificate key is protected by a passphrase, specify the passphrase here. cred:SSL_PASSPHRASE

 


Start and Stop Apache

Use the following operational scripts to start or stop the Apache HTTP Server application:

  • Run web_apache::do_stop to stop the Apache service.
  • Run web_apache::do_start to start the Apache service.

Restart Apache

To restart the Apache HTTP service, run the web_apache::do_restart operational script.


Enable Multiple Load Balance Pools

By default, the ServerTemplate is configured to support a single load balancing pool called 'default'. However, you can specify a more descriptive name if desired. (e.g. myapp)  It's recommended that you use a single word for the name or use a dash to separate two words. (e.g. my-app)

The ServerTemplate also has built-in support for servicing multiple load balancing pools so that you can use the same set of load balancers to distribute traffic across multiple pools. For example, you could have two load balancing pools. (e.g. app1.example.com and app2.example.com) In such cases, use the Load Balance Pools input to enter a comma-separated list of vhosts, fully-qualified domain names (FQDN), or URIs for the different application server pools. Make sure that each load balancer server in the deployment has the same configuration for this input. 

Input Name Description Example Value
Load Balance Pools

Specify the load balancing pool(s) that the load balancer server will service. Typically, an application server will belong to one load balancing pool, however an HAProxy load balancing server can service multiple pools. An application server can also connect to multiple load balancing pools, if desired. 

Specify the load balancing pool(s) that the server will service. To service multiple pools, application server will connect to or disconnect from by using one of the following types:

  • Virtual Hostname (e.g. default)
  • URI (e.g. /myapp)
  • FQDN (e.g. myapp.example.com)

text: default

 

text: /app1,/app2

 

text: app1.example.com,app2.example.com

 

 

If you are using multiple vhosts, you must configure each application pool appropriately so that the application server will be a member of the correct server pool. For the application servers that are going to be a member of one of the server pools, you must only specify a single load balance pool for the Load Balance Pool input. Remember, both the load balancer servers and application servers use the same input to set up the server pools. Typically, you would set the comma or space-separated list of load balance pools at the deployment level (for the load balancer servers to inherit) and use separate server arrays for each application server pool where the input is set to a specific pool at the server array level. For example, each array would have a different setting.

Server Array 1: 'App1' Pool

Input Name Description Example Value
Load Balance Pools The name of the specific application server pool that the application servers will be a member of. text: app1.example.com

 

Server Array 2: 'App2' Pool

Input Name Description Example Value
Load Balance Pools The name of the specific application server pool that the application servers will be a member of. text: app2.example.com

 


Check the Load Balancing Pool

As a troubleshooting step, you may want to verify that a load balancing pool has all of its application servers. You must have the 'server_login' user role privilege in the RightScale account in order to perform this action.

  1. SSH into a load balancer server.
  2. Switch to the 'root' user. 

Note: When using newer images (>5.8/13.4), ensure that you have the 'server_superuser' permission to the Rightscale account where the server is running in order to gain root privileges using the sudo command (Settings > Account Settings > Users).

# cd sudo -i
  1. Navigate to the HAProxy load balancing pool directory.
# Replace <pool_name> with the desired pool name specified in the 'Load Balancing Pools' input above
# cd /etc/haproxy/lb_haproxy.d/<pool_name>/
  1. View a list of all the application servers in the load balancing pool. Servers are listed by their RightScale UUID. You can use an application server's tag to match the listed results. (e.g. server:uuid=01-0E6SPHKHBQLRE) In the example below, there are two application servers in the load balancing pool.
# ls
01-0E6SPHKHBQLRE  01-FHU456S69I2AD

 

A load balancer server will only send traffic to application servers in its load balancing pool. If an application server is missing from the list, it's probably because the server either stranded in booting or was unable to connect to the load balancing pool. Check the application server's security group settings (if applicable) or IP tables to verify that the application server can accept requests from the load balancer servers. 

 


Add or Remove a Firewall Rule

When iptables is enabled, which is the default behavior in all Linux-based v13 ServerTemplates, TCP ports 22, 80, and 443 are configured to be open to any IP address in order to enable minimum functionality and access. If you want to add or remove a firewall rule on a running (operational) server by opening or closing a port, you can set the following inputs accordingly and run the sys_firewall::setup_rule operational script.

If you want the firewall rules to be set at boot time, you can either add the Chef recipe to the end of the boot script list or update the sys_firewall::default recipe to change the list of default firewall permissions by explicitly opening up additional ports. However, you should only consider overriding the default recipe if you want to change the default behavior for all of your servers that use that cookbook.

Note: If the cloud provider supports security groups, you must also open or close the appropriate ports in the security group resource.

  1. Go to the current server's Inputs tab and set the following inputs accordingly.
     
Input Name Description Example Value
Firewall Rule Port Specify the port number to open or close. text:  8080
Firewall Rule

Defines whether you are creating or removing a firewall permission for the specified port (Firewall Rule Port) over the specified IP protocol (Firewall Rule Protocol), as restricted by the specified IP range (Firewall Rule IP Address).

  • enable (default) - Enable access by adding a firewall permission that allows (ingress) access.
  • disable - Disable access by removing an existing firewall permission.
text:  enable
Firewall Rule IP Address

Use CIDR notation to define the range of IP addresses that will either be allowed or denied access to the specified port (Firewall Rule Port) over the specified IP protocol (Firewall Rule Protocol).

Leave this value set to "any" (default) to allow access from any IP address (0.0.0.0/0). Use an exclamation point (!) before the IP address specification to deny access (i.e. "blacklist") from a specific IP address (e.g. !192.1.2.3) or IP range (e.g. !192.3.0.0/24)

text: any

text:  192.1.2.0/24

Firewall Rule Protocol

Specify the Internet protocol for the specified port (Firewall Rule Port).

  • tcp (default)
  • udp
  • both
text:  tcp

 

  1. Run the sys_firewall::setup_rule operational script to add the firewall permission to the running server(s).

List Current Firewall Rules

For troubleshooting and security purposes, you may want to list a server's current firewall rules to make sure that a server has the expected IP/port permissions. This script is especially useful if you want to check the firewall rules across all servers in a deployment to validate that all of them have the same iptables rules. 

  1. Go to the running server's Scripts tab and run the sys_firewall::do_list_rules operational script.
  2. Go to the server's Audit Entries tab to view the output. The output will look similar to the following example.
22:25:03: ==================== do_list_rules : Firewall rules Begin ==================
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
FWR        all  --  0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FWR (1 references)
target     prot opt source               destination         
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:22 
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:443 
ACCEPT     tcp  --  10.123.456.22        0.0.0.0/0           tcp dpt:8000 
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:80 
REJECT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x16/0x02 reject-with icmp-port-unreachable 
REJECT     udp  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable 
==================== do_list_rules : Firewall rules End ====================

 

If you want to perform the same action via SSH, follow the steps below.

  1. SSH into the running server. (Requires 'server_login' user role privileges.)
  2. Switch to the 'root' user.

Note: When using newer images (>5.8/13.4), ensure that you have the 'server_superuser' permission to the Rightscale account where the server is running in order to gain root privileges using the sudo command (Settings > Account Settings > Users).

# sudo -i
  1. Type the following Unix command.
# /sbin/iptables -L

Enable or Disable Iptables

Iptables is typically enabled by default ('Firewall' = enabled). However, you can use the following script to enable or disable Iptables on an instance.

Warning! You should only perform this action if you fully understand its implications. For example, if the cloud provider does not support cloud-level firewall services such as security groups, you could permanently lock yourself out of the instance if you disable Iptables.

To enable Iptables, follow the steps below.

  1. Set the 'Firewall' input to 'enabled'.
  2. Run the sys_firewall::default (boot script).

 

To disable Iptables, follow the steps below.

  1. Set the 'Firewall' input to 'disabled'.
  2. Run the sys_firewall::default (boot script).

Enable or Disable System Security Updates

Typically, ServerTemplates are configured with frozen software repositories that are locked down to a specific date to ensure that the same versions of software and packages are installed on a server at launch time. You also have the option to configure the server so that you can easily apply security patches from one of the related system software repositories as they become available. (Currently, only the Epel and Ubuntu Precise (v12.04) repositories are checked for security updates.) System security updates are disabled by default at the ServerTemplate level, as defined by the 'Enable security updates' input. As a best practice, you should determine whether or not you want to reserve the ability to apply security updates as an operational script before you launch the server. Changing this setting after a server is operational is not recommended.

To enable security updates, follow the steps below.

Warning! Once security updates are enabled, they cannot be disabled.

  1. Set 'Enable security updates' input to 'enable' at the deployment level, or at the (next) server level if you do not want this change to be applied to all future servers launched in the deployment.
  2. Launch or relaunch the server, if possible. Otherwise, you must update the input setting under the current server's Inputs tab and run the rightscale::setup_security_updates boot script.

Apply System Security Updates

If the server is enabled for system security updates (Enable security updates = enable), a server tag will be added to the server when a security update becomes available ('rs_monitoring:security_updates_available=true'). By default, a triggered alert sends an email notification to the account owner as a reminder that a security update is available on a particular server. If a security update is available, follow the steps below to download and apply the security update.

  1. Check to make sure that a security update is available. All effected servers will have the following server tag: rs_monitoring:security_updates_available=true 
  2. Run the rightscale::do_security_updates operational script. You can either apply the update on a per server basis under the "current" server's Scripts tab. However, if you want to apply the update to some or all servers in a deployment, run the script at the deployment level instead (under the deployment's Scripts tab).
  3. A reboot may be required to apply the security update. If you see the following reboot tag on the server ('rs_monitoring:reboot_required=true'), you must manually reboot the server at your convenience (View Server > More Actions > Reboot) to complete the security update.
You must to post a comment.
Last modified
11:16, 6 Nov 2013

Tags

This page has no custom tags.

Classifications

This page has no classifications.

Announcements

None


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