Note: Please go to to access the current RightScale documentation set. Also, feel free to Chat with us!
Home > Guides > Dashboard Users Guide > Manage > Arrays > Actions > Add a Scalable Application Server Array to a Deployment

Add a Scalable Application Server Array to a Deployment


  • A running 3-tier deployment that was created by following one of the "3 Tier Deployment Setup" tutorials.
  • At least two operational application servers.
  • 'designer' and 'actor' user role privileges


In this tutorial, you will perform the following actions:

  • Create an alert-based, application server array.
  • Add custom alerts for autoscaling purposes. (i.e. growing/shrinking the server array)
  • Transition to a deployment that solely uses a server array for the application tier.




Create a Server Array

The first step is to create a new alert-based server array and associate it with your 3-tier deployment. 

  1. Go to your 3-tier deployment's Servers tab. Go to the ServerTemplate that you used to create the application servers in the existing deployment. Since a server array is designed to launch identical instances with the same configuration, you will use the same ServerTemplate to launch and configure each instance into array. 
  2. Click the ServerTemplate's Add Array action button. Although you can use a HEAD version of a ServerTemplate it's strongly recommended that you use a committed revision of the ServerTemplate, especially for use in production environments. The use of a HEAD version of a ServerTemplate should only be used for certain development and staging environments.
  3. Select the compute Cloud into which the instances will be launched (e.g. AWS US-West) and your 3-tier Deployment. (Note: Once the cloud is selected for a server array, it cannot be changed.)

Server Details tab

Provide the required information under the Server Details tab.


  • Hardware
    • Array Name - Enter a name for the server array. (e.g. MyArray)
    • MultiCloud Image - Select the appropriate MultiCloud Image (MCI) based upon the desired operating system and distribution. If you do not have a preference, the MCI
    • Instance Type - Select which instance type of the chosen cloud that will be used to launch new instances in the server array.
    • Pricing* - Select which pricing option to use for launching new instances in the array. For example, AWS offers "on-demand" and "spot" pricing options.
    • EBS Optimized* - (AWS only) Select this checkbox to use high performance connectivity to EBS volumes for supported instance types.
      * Denotes cloud-specific options that may not be applicable based on the chosen cloud.
  • Networking
    • SSH Key* - Select the SSH Key that will be used to launch the instance.
    • Security Group(s)* - Select which security group(s) will be used to launch the instance. Security groups are firewall settings that are enforced by the cloud provider.  At least one security group must be selected. (Note: The specific firewall permissions of the security group can be modified at a later time.)
    • Availability Zone* - The zone/datacenter into which the instances will be launched. If the cloud supports more than one zone/datacenter, it's strongly recommended that you use the 'Weighted across multiple zones' option to distribute instances in the array across multiple zones for high availability purposes.
      * Denotes cloud-specific options that may not be applicable based on the chosen cloud.

Array Details tab

Provide the required information under the Array Details tab.


  1. Autoscaling Policy
    • Status - Defines whether or not the array is active. It's strongly recommended that you keep the 'disabled' state until you have properly tested the array and confirmed that it will successfully launch instances that reach the operational state.
      • Disabled - The array is inactive and will not be allowed to automatically resize based on its alerts.
      • Enabled - The array is active and all of its preferences will take effect including min/max counts and resize policy (i.e. autoscaling)
    • Min Count - The minimum number of instances that will be launched into the server array. If you are using a server array to launch all application servers in a deployment, it's strongly recommended that the minimum count is greater than one for high availability purposes. (e.g. 2)
    • Max Count - The maximum number of instances that can be launched into a server array. (e.g. 20)
    • Array Type - Select the Alert-based option since you are going to create alerts to trigger resize actions. (i.e. autoscaling up/down)
  2. Array Type Details
    • Decision Threshold - Resize action (grow/shrink) will be based on a voting system where each application server has a voting tag based on whether or not any of the alert specifications defined for autoscaling exists. This parameter defines the percent of voting servers that must exist before a resize action can occur. The default setting (51%) ensures that a majority of the servers must vote for the same scale up/down action in order to trigger a resize of the array (i.e. autoscaling). See Understanding the Voting Process for details.
    • Choose Voters by Tag - Defines the tag that RightScale's elasticity daemon will check for to determine who is a "voter" for this particular server array. You must make sure that each server array has a different voter tag otherwise you may have servers in a different deployment that are voting and causing resize actions for an incorrect server array. If you do not have a strong preference for a voter tag, it's recommended that you simply use the default option, which uses the server array's nickname as the voter tag. (e.g. MyArray)  (Important: The voter tag is case sensitive.)
    • Resize up by - Defines how many new instances you want to launch when you grow (i.e. scale up).  When a decision is made to "grow an array," we recommend launching at least 2 servers in order to ensure that a significant impact will be made to your setup. Remember, if your deployment needs more server resources, it's better to overcompensate than under-compensate. Similarly, if you have larger setups or you have a predictable scaling pattern (ex: 5 servers at a time), you also have the flexibility to scale in bulk. (e.g. 2)
    • Resize down by - Defines how many new instances you want to launch when you grow (i.e. scale up). (e.g. 1)
    • Resize calm time - The calm time defines how long you want to wait before you repeat another action.  Since it takes a few minutes for a new server to be launched and become fully operational, you'll want to give yourself a buffer before another action can be taken.  For normal situations, we recommend using a calm time of 15 minutes. (e.g. 15)
  1. Click Confirm.
  2. Review your choices and click Finish.

Add Alerts for Autoscaling

The next step is to add custom alerts for autoscaling purposes. It's important to remember that any "voting" server must have the same set of custom alert specifications. For example, if you have any application servers that you created and launched in the context of the deployment (i.e. servers listed under the deployment's Servers tab), you must make sure each of them have the same alerts as the server array.

In this example, you're going to replace the current application servers in the deployment with a scalable server array of application servers, which will allow your application tier to "grow" by launching additional application servers or "shrink" by terminating existing application servers that are no longer needed to handle the current work load. Therefore, you can add the alerts at the server array level (under the server array's Next Alerts tab), so that any new instances launched into the array will be configured with the same alerts. Another option would be to add the alerts at the ServerTemplate level, but then it would be difficult to use the same ServerTemplate in a different context because it would contain deployment-specific alerts.

See Best Practices for Autoscaling Alerts.

  1. Go to the server array's Next Alerts tab.
  2. Create an alert specification for growing the array. Click New.
    • Name - Enter a name for the alert. (e.g. Grow Array)
    • Description - Enter a brief description. (e.g. Launch additional instances into the server array.)
    • Condition - Enter the condition under which an alert will be triggered for a 'grow' action. The condition consists of a specific metric, threshold, duration for which the condition must exist, and the desired voting action (grow/shrink) that will be taken. The tag will dynamically change on the server when an alert is triggered. Instead of associating the alert specification with an alert escalation, you're going to set a tag on the server that will be used for voting for a resize (autoscaling) action.
      • metric: 'cpu-0/cpu-idle'
      • threshold: < 30%
      • duration: 5 minutes
      • vote: vote to 'grow' server array by setting the voter tag 'MyArray'  (RightScale's elasticity daemon will evaluate the number of voters for a resize action by finding all servers with the matching voter tag.)  diag-VotingTagMatch3tier-v1.png
    • Click Save when ready
  3. Create an alert specification for shrinking the array. Click New.
    • Name - Enter a name for the alert. (e.g. Shrink Array)
    • Description - Enter a brief description. (e.g. Terminating servers that are no longer needed.)  Note: The oldest instance (i.e. the one with the earliest launch time) will be terminated first.
    • Condition - Enter the condition under which an alert will be triggered. You will most likely want to use the opposite condition as the "grow" alert specification.
      • metric: 'cpu-0/cpu-idle'
      • threshold: > 70%
      • duration: 5 minutes
      • vote: vote to 'shrink' server array by setting the voter tag 'MyArray'

Configure Inputs

Since you already defined values for the inputs that are required by the "application" ServerTemplate at the deployment level when you created the 3-tier deployment, you should not have to define any inputs prior to launching a test instance. However, if there are any missing inputs that need to be defined, it's strongly recommended as a best practice that you define all inputs related to the server array under the deployment's Inputs tab.

Note: The Input confirmation screen that you are typically used to seeing in the dashboard when you launch a single server in a deployment, is not displayed when an instance is launched in a server array either manually or automatically (because of a resize action). Therefore, it's important that all required inputs have correct values set otherwise the instance may become stranded in booting.

  1. Go to the deployment's Inputs tab and provide values for any missing inputs that are required by any boot scripts.

Test the Server Array

As a best practice, you should always manually launch a single instance in a server array to verify your configuration settings.

  1. Go to the server array and click the Launch action button. If you have configured your inputs correctly, the server will reach the operational state. If the server becomes "stranded in booting," terminate the server and check your inputs again.

Enable the Server Array

Once a server array is enabled (i.e. active) it's allowed to autoscale by either resizing up or down based on the predefined alert conditions. Minimum and maximum server count settings will also take effect.

  1. Go to the server array's Info tab and click the enable text link for the "Status" field. If the server array does not have enough running servers to meet the minimum server count (e.g. 2), RightScale's elasticity daemon will evaluate the number of "operational" servers in the server array and launch enough new servers to satisfy the minimum server count. Note: Only "operational" servers will satisfy the array's minimum instance count.


Clean-up Application Server Tier

Most users find it useful to simply use a server array for managing the entire application tier instead of managing dedicated application servers in a deployment, as well as a server array. For example, if you want at least two running application servers at all times, you can simply set the application server array to have a minimum server count of two. Remember, any server that needs to be a "voter" for an autoscaling action needs to inherit the correct alert specifications for voting for a grow/shrink resize action of the array. In this tutorial, you added the alert specifications to the server array so that any new servers launched into the array will inherit the same alerts for autoscaling. If there are any running application servers in the deployment, you may want to terminate them because they do not have the proper alerts for autoscaling and are therefore unable to vote for a scaling action.

  1. If the server array has a minimum server count of two and you have at least two operational application servers in the array that are properly connected to the load balancer tier and master database server, go to the deployment's Servers tab terminate any running application servers.
  2. Once the servers are terminated, delete the servers from the deployment.

The deployment should now have a reference architecture similar to the following diagram.


Post Tutorial Steps

Test the Server Array for Autoscaling (Optional)

Use the following tutorial to perform an autoscaling test on the alert-based server array to verify that the alerts and resize actions are occuring as expected.

You must to post a comment.
Last modified
16:05, 31 Dec 2013


This page has no custom tags.


This page has no classifications.



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