Table of Contents | |||
Long Term Support Stable, tested ServerTemplate assets |
|
This ServerTemplate supports several load balancing options:
HAProxy
Define the following inputs at the deployment level.
Input Name | Description | Example Values |
Load Balance Provider | Select lb_haproxy if you're using RightScale's "Load Balancer with HAProxy" ServerTemplate. | text: lb_haproxy |
Virtual Host Names | If you are using an HAProxy load balancer ('lb_haproxy'), specify the virtual host name that will be used by the application server to connect to the correct load balancer server. Note: A load balancer can have multiple virtual host names. If a load balancer is serving requests to multiple virtual host names, the virtual host name that the application server will use must be included in the list otherwise it will connect to the "default" virtual host name, which is the first one in the list. | text: default text: test1.example.com |
ELB
Define the following inputs at the deployment level.
Input Name | Description | Example Values |
Load Balance Provider | Select lb_elb to use Amazon ELB. | text: lb_elb |
Load Balance Service ID Load Balance Service Secret | For ELB, specify the Amazon access key ID and secret access key for authentication purposes. | cred: AWS_ACCESS_KEY_ID cred: AWS_SECRET_ACCESS_KEY |
Load Balance Service Name | The name of the Amazon Elastic Load Balancer. | text: my-elb-name |
CLB
Warning: When using Rackspace CLB, you must wait until after launching your first application server before setting up your load balancer via the Rackspace API or control panel. This is because you cannot create a new CLB without at least one running cloud server or external node associated. Also, you must create the CLB in the same datacenter as your running servers; Rackspace randomly assigns you to one of their datacenters (e.g. ORD, DFW, etc.). For example, you cannot use a CLB created in ORD to load balance across servers in DSW. If you want to change the datacenter that you were assigned to, you must contact Rackspace.
To configure application servers to work with Rackspace CLB, set the below input values at the deployment level. Since you will configure these inputs before setting up your new Cloud Load Balancer on Rackspace, carefully note each entry so that your Rackspace configuration, upon setup, will match these values exactly.
Define the following inputs at the deployment level.
Input Name | Description | Example Values |
Load Balance Provider | Select lb_clb to use Rackspace CLB. | text: lb_clb |
Load Balance Service ID Load Balance Service Secret | Rackspace username and API key to use for authentication. | cred: RACKSPACE_USERNAME cred: RACKSPACE_AUTH_KEY |
Load Balance Service Name | The name of the Rackspace Cloud Load Balancer. | text: my-clb-name |
Load Balance Service Region | Choose the Rackspace region where you will deploy your Cloud Load Balancer: either "ORD (Chicago)," "LON (London)," or "DFW (Dallas/Ft. Worth)." In general, it is best to create your CLB in a region as close to your application servers as possible. | text: ORD |
Use the following operational recipes to start or stop the Apache HTTP Server application:
To restart the Apache HTTP service, run the web_apache::do_restart operational recipe.
Run one of the following scripts to add/remove an application server to/from the load balancing servers/service.
Application code is typically downloaded at boot time when an application server is launched. However, you can manually update the application code on a running server by executing an operational script. For example, you may want to retrieve the latest version of your application from a different branch in your software repository.
Run the following script to update the application code on a server.
When iptables is enabled, which is the default behavior in all Linux-based v12 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.
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).
| 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).
| text: tcp |
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.
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.
# sudo -i
# /sbin/iptables -L
Typically, an application server has a script (e.g app::do_loadbalancers_allow) listed in the 'Reconvergence List' input that tries to attach itself to the specified load balancer servers or service based on its tags. By default, all scripts listed in the Recovergence List input are run every 15 minutes.
Go to the current server's Inputs tab and add any recipes that you want to periodically be executed on the running application server to the 'Reconverge List' input. Note: This functionality only applies to Chef recipes. RightScripts are not supported in the Recoverge List.
Input Name | Description | Example Values |
Reconverge List | Space-separated list of Chef recipes to periodically run. | text: app::do_loadbalancers_allow |
Go to the Scripts tab and run the sys::do_reconverge_list_enable operational script.
© 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.