Set up Autoscaling using Voting Tags
Table of Contents
Objective
To add scale-up and scale-down alerts for horizontal autoscaling of an alert-based server array, which is commonly used for autoscaling an application tier of a multi-tier deployment.
Note: The ability to set up autoscaling using Alert Escalations will be eventually be deprecated. (Set up Autoscaling using Alert Escalations?) Please use this tutorial for autoscaling purposes.
Table of Contents
Prerequisites
- Requires 'actor' user role privileges
- An existing Deployment that you want to set up for alert-based autoscaling. For queue-based scaling, see Create a Queue-based Server Array.
Overview
Once you've set up a typical website deployment you'll most likely want to configure it for autoscaling. Autoscaling is the ability to launch additional server resources automatically based upon different alert conditions you've predefined. For example, you can set up a server array so that additional servers are launched into the array (grow) when a majority of the servers are being overworked (e.g. cpu-idle < 30% for 15 min or longer) and then scale back down (shrink) when traffic decreases and underutilized application servers can be safely terminated. This tutorial explains how to set up horizontal scaling where additional servers are launched to help overworked servers, whereas vertical scaling involves increasing instance sizes where you're upgrading existing machines with more powerful counterparts.
Horizontal scaling is configured by using a RightScale concept called Voting Tags. These server tags are used specifically for the purpose of setting up a scalable, alert-based server arrays. The following steps will explain how to set up autoscaling using Voting Tags. To learn more about how server votes are counted, see Understanding the Voting Process.
Even if you don't think you'll need to autoscale in the near future, it's always a good idea to prepare your Deployment for such events. The ability to autoscale is one of the key benefits of cloud computing. If you've been following the Deployment Setup tutorials, you already have a typical 4-server Deployment. This tutorial explains the few extra steps that you need to take in order to properly configure a Deployment for horizontal scaling.
Steps
Create a Server Array
The first step is to create the server array. Although you can define your alert specifications first, the process of setting up a scalable server array is less prone to error if you start by creating a server array first. When you create the server array, be sure to associate it with the desired deployment. Remember, this server array will be used when servers in the deployment require additional server resources. Be sure to note the Voter Tag that you specify for the array ("Choose voters by tag"). Later on in the tutorial you will need to make sure that you use the same voting tag when you create your alert specifications. For this tutorial, simply use the default Voting Tag, which uses the Server Array's nickname (e.g. MyArray) and make sure that the array is disabled as you're not ready for autoscaling.
Create an Alert Specification
Now that you've created a Server Array and specified which Voting Tag RightScale should use to evaluate when a Server Array should autoscale, you are now ready to configure your alert specifications. Before you can create an alert specification, you must first answer the following questions:
- Which metric(s) should be used for autoscaling?
- Who should be allowed to vote for a scaling action?
Which metric(s) should be used for autoscaling?
Although, it's typically sufficient to scale up/down based on a single metric (e.g. cpu), you can set up an array where multiple metrics can trigger scaling actions. Let's say you want to set up a scalable array of PHP application servers. Since your application can be both memory and cpu intensive at times, you need to set up alert specifications where both of these key metrics are monitored. Additionally, you want the server array to scale up/down based upon both of these metrics. Remember, for each metric that you want to use for autoscaling, you have to create two alerts: one for scaling up and one for scaling down.
Who should be allowed to vote for a scaling action?
Next, you will need to determine who should be allowed to vote for a scale up/down action. The answer to this question, as well as the architecture of your deployment will impact how you configure your pool of voting Servers. Basically, you need to make sure that each Server that you want to be allowed to vote for a scaling action has the appropriate alert specifications. Remember, a Server can inherit its alerts from multiple sources, so you must choose the best place to define your alerts. Alert specifications can be defined at the Server, ServerTemplate, or Server Array levels. As a best practice, you should only configure them at the ServerTemplate or Server Array levels as it's difficult to keep configurations at the Server level consistent. The following guidelines can be used to help guide your decision.
- If your application is only being served by Servers in your Server Array, you can either specify them at the Server Array or ServerTemplate levels. This way, all new Servers that are launched into the array will inherit the correct alert specifications. Note: A Server will inherit alerts from its ServerTemplate and Server Array. So, it's important that you define an alert in one of those places and not both. Otherwise, your Server may have a duplicate alert that could affect a Server's aggregated vote.
- If your application is being served by Servers in your Deployment (not just in a Server Array), you will need to add the same alert(s) in multiple places. For example, if you have two FrontEnd servers that are serving your application, they should be allowed to vote for a scaling action. Therefore, you'll need to add the alert specifications to those Servers' ServerTemplates (e.g. "PHP FrontEnd v9"). You will also need to make sure that Servers in your Server Array also be allowed to vote since they will be dedicated application servers. Therefore, you'll need to add the same alert specification at either the Server Array level or to the ServerTemplate that's being used to launch new instances in the Server Array.
Once you've answered those prerequisite questions, you're ready to define those alert specifications. In this example, we'll be defining them at the ServerTemplate level.
Create an Alert Specification to "grow" and "shrink"
For this example, let's define the following alert specifications at the ServerTemplate level. Locate the ServerTemplate(s) that will be used by all voting Servers. If you're using FrontEnd servers or application servers in your Deployment and you want them to be able to vote for growing/shrinking an array, you will also need to add the same alert specifications to those ServerTemplates as well. Remember, in order to add an alert specification to a ServerTemplate, it must be an editable HEAD version, so you may have to clone the ServerTemplate. If an alert specification's condition exists for longer than the defined threshold, an alert is triggered.
- If 'cpu-0/cpu-idle' is < 30 percent for 15 minutes, then vote to 'grow' the server array by setting the 'MyArray' voter tag.
- If 'cpu-0/cpu-idle' is > 80 percent for 45 minutes, then vote to 'shrink' the server array by setting the 'MyArray' voter tag.
Important!
The voting tags must match! Voting Tags are NOT case-sensitive.
Remember, the Voter Tag that you specify when creating an alert specification must match the tag that you previously set at the Server Array level, otherwise autoscaling will not work properly.
Server Array: MyArray
Servers' Voting Tag: rs_vote:MyArray=none
Launch a Test Server
Before you enable the array for autoscaling, it's always a recommended best practice to launch a test server into the server array. Go to the Server Array's show page (Manage -> Arrays -> MyArray) and click the Launch action button. Make sure that the new Server has the proper Voting Tags. Check the Server's Info tab and make sure under the Tag(s) section it has the following tag: rs_vote:MyArray=none
Enable the Server Array
If the test Server was launched and configured properly, you can now enable the array for autoscaling. Under the Server Array's Info tab, click the Enable text link under Status. The Server Array is now active and will autoscale accordingly.
Next Steps
If you are following the Deployment Setup tutorials and just added a scalable server array to your 4-server setup, you may be curious about the next steps in the lifecycle of your Deployment.
As your site continues to grow, you may need to consider transitioning to a 3-tiered architecture where you have two dedicated load balancers, where the entire bandwidth/cpu/memory of the FrontEnd is used for load balancing purposes only so that it's no longer responsible for also serving the application. If you typically, only need around 6 servers to handle a majority of your load 90% of the time, you might want to let the FrontEnds continue to serve your application. However, if you anticipate a large scaling event in the future or if you plan to manage more than these 6 servers on a regular basis, you might want to migrate from the standard 4-server setup. See Transition from a 4-Server to 6+ Server Setup.
- © Copyright 2015 RightScale Technical Support