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