Note: Please go to to access the current RightScale documentation set. Also, feel free to Chat with us!
Home > Guides > Dashboard Users Guide > Manage > Deployments > Servers > Actions > Vertically Scale a Server

Vertically Scale a Server


  • A Server (or Server Array) that has already been determined is in need of vertical scaling.  By "vertically scaling" we mean increase the instance type which typically includes more CPU, memory and storage capacity.  The most common need for vertical scaling is that CPU and/or memory has been maxed out for a prolonged period due to increased demand.  ("Horizontally scaling" means that the number of instances is increased.  This is commonly accomplished via the RightScale Cloud Management Platform with auto-scaling at the application tier using Server Arrays and monitoring/alerts.)  Monitoring of your Servers in a Deployment is a critical component in the determination process prior to scaling.
  • Understanding of the relationship between Servers, ServerTemplates and MultiCloud Images.  If you don't understand this relationship well, please read About ServerTemplates and  About MultiCloud Images.  You should also browse about in the Dashboard in the following manner:
    • Navigate to your Deployment
    • Select a Server in your Deployment.  Read the information in the Server's Info tabs.
    • Select the ServerTemplate hyperlink from which that Server was built from.  Read through its Info tab.
    • Select the default MultiCloud Image (MCI).  Read through the Description field.


Important!  Many considerations should be taken into account before coming to the conclusion to scale vertically.  The Steps in this tutorial assume that you have already made an intelligent decision that vertical scaling is the logical next step.  Please read the Common Scenarios section prior to completing the Steps.  Note that the Post Tutorial Steps section discusses additional steps and considerations that may (or may not) need to be performed, depending on what type of Server you are scaling.  As always, changes as potentially drastic as the ones discussed in this document should be thoroughly tested and re-tested on a staging Deployment before implementing in a production environment.

Common Scenarios and Considerations

There are many reasons tied to various scenarios that may result in the need to vertically scale a Server (or Servers).  Several, but not all scenarios and considerations are mentioned here.  Consider logging a ticket with RightScale Technical Support or reaching out to the RightScale community ( with any unanswered questions or issues.

Front end Servers

Usually front end Servers (e.g. load balancers) are small instance types.  Front end Servers can typically handle a large number of connections as the software is merely proxying network requests.  Nevertheless, the process in vertically scaling in this scenario is fairly straight forward in that the image does not need to be changed.  For example, scaling from a small to a medium instance remains on a 32 bit platform.  The image (pointed to by the MultiCloud Image) does not need to be modified, just the instance type.

Some Deployments may include a single Server that is used for both load balancing and running your application.  Although the temptation might be to scale your front end/application Servers in this scenario, the recommended procedure is to separate out your application into a Server Array and dedicate your front end Servers to load balancing.  With that said, some have chose to scale their combined front end/application Servers.  This might entail scaling from a medium to a large instance which demands an architecture change from a 32 bit to a 64 bit platform. The process for changing both the instance type andimage is slightly more involved.

The process for vertically scaling in both scenarios mentioned is covered in this tutorial.  Namely:

  • Platform architecture change not required (e.g. remains 32 or 64 bit before and after scaling)
  • Platform architecture change is required (e.g. 32 bit to 64 bit architecture)

Application Servers

Obviously each application is different and has potentially many areas that could bottleneck performance.  However, with respect to scaling application Servers, the question often becomes one of vertical vs. horizontal scaling.  Should you increase the instance type or the number of instances running your application?  With using RightScale monitoring and alerts coupled with a deep understanding of your application you can make an intelligent decision.  However, sometimes testing both scenarios is the best course of action prior to making your decision on the type of scaling.  In addition to monitoring and alerts, consider running a load tester against a staging Deployment.

Back end Database Servers

The most common scenario after determining your database Servers need to be scaled is a large instance being scaled to an extra large.  Most production Deployments with decent sized applications are already on a 64 bit platform.  Scaling in this scenario is simply increasing the instance type.  In fact, load on the database Servers is the most common reason to scale a Server vertically (for reasons already touched on). 

Steps (same architecture)

The following are steps you can take to vertically scale a Server that has already been determined too small.  Scaling from the current instance type to the new instance type will not require an new image.  (That is, the architecture remains either a 32 or 64 bit architecture before and after scaling.)


  • For a Server, navigate to Manage > Deployments > Servers
  • Select the Server that you wish to scale
  • For a Server Array, navigate to Manage > Arrays
    • Select the Server Array that you wish to scale

Change the Instance type

  • Click the Edit action button
  • Use the drop down menu to select the correct Instance Type.  Note:  It is likely set to "Inherit from the MultiCloud Image". 
  • Click the Save action button when ready

Launching the larger Server

This step could be as simple as selecting the Launch or Relaunch action button.  However, there could be front end, application or database specific procedures you will need to apply before launching the new Server.  Please read the Post Tutorial Steps before launching your newer, larger Server.

Steps (different architectures)

In some cases scaling vertically will require not just an increase in the instance type but also a new image.  This is because the architecture may change from a 32 to a 64 bit platform.  For example, if scaling a front end load balancer from a small to a large instance type.


  • For a Server, navigate to Manage > Deployments > Servers
  • Select the Server that you wish to scale
  • For a Server Array, navigate to Manage > Arrays
    • Select the Server Array that you wish to scale

Change the MCI or Instance Type and Image Type

Once again, there are two more common scenarios here. 

  1. If you have been using RightScale ServerTemplates your Server's MultiCloud Image field is likely set to "Inherit from ServerTemplate".  Further, your Instance Type and Image are "Inherited from MultiCloud Image".  In this scenario, all you need to do is:
    1. Click the Edit action button
    2. Change your MultiCloud Image to the 64 bit version of the one you were already using.  For example, change "RightImage_CentOS_5.4_i386_v4.4" to "RightImage_CentOS_5.4_x64_v4.4"
    3. Click the Save action button when ready
    4. Note:  When you launch/relaunch this Server it will inherit the correct 64 bit Image and the larger instance type.  There is no need to change those fields, they will be inherited correctly.
  2.  You may need to manually update both the Instance type and Image fields explicitly.  If so:
    1. Click the Edit action button
    2. Change the Instance type from a small to a large
    3. Change the Image to the equivalent 64 bit image.  For example, change from "RightImage CentOS_5.4_i386_v4.4.10" to "RightImage CentOS_5.4_x64_v4.4.10"
    4. Click the Save action button when ready

Launching the larger Server

This step could be as simple as selecting the Launch or Relaunch action button.  However, there could be front end, application or database specific procedures you will need to apply before launching the new Server.  Please read the Post Tutorial Steps before launching your newer, larger Server.

Post Tutorial Steps

Again, depending on the type of Server you are scaling, you may need to apply various procedures.  Not the least of which is how and when to launch the larger Server.

Front end Servers

There are generally two trains of thought when it comes to launching your new front end Server.  (Note:  This discussion assumes you are using EIPs and HAproxy based ServerTemplates.  If you are not, the concepts still apply however.)

  1. Simply launch or relaunch your new Server, allowing it to assume control of the assigned EIP, immediately routing requests, etc.  Some may prefer this quick and easy method and trust that the new Server will function properly.  This may be fine when testing in a staging environment, but you should be more controlled in a production environment.  The next method is safer and strongly recommended in a production environment.
  2. Having already cloned the original front end and scaled it vertically, launch the Server without assigning the EIP.  Test out the Server, route requests through its public DNS, etc. Once satisfied, then assign the EIP to the newer larger Server.  Terminate the older front end Server when completely through with this process.

Important!  Regardless of which restart method you implement, if you are using v4 RightImages (e.g. pre RightLink enabled images on your load balancers), your new load balancer may come up, and go operational, yet not function properly.  Further, you will start getting notifications because HAproxy is not running on your load balancer. 

  • The problem is this:  When your load balancer goes operational, there is no way for your (v4 based image) application Servers to automatically know this and register with the load balancer.  If there are no entries for your application Servers in the load balancers configuration file (/etc/haproxy/haproxy.cfg) then HAproxy will not even start
  • The fix is:  On each Server (or Server in your array), run the 'LB app to HA proxy connect' operational RightScript.  HAproxy will automatically be started in addition to the registration process being completed.  (Note:  You can run the script on multiple application Servers in an array.)  Refresh your browser on the publicly facing URL of your application.  Where you were getting 503 errors (Service temporarily unavailable) you should see your application again.

This load balancer restart issue with HAproxy (or other load balancer software for that matter) is implemented more elegantly when using Servers with properly configured RightLink enabled images.  The Server can take advantage of superior communications and machine tags to essentially announce "I'm a newly operational load balancer, application Servers should register in my load balance pool."  There is no need to manually run any operational scripts.

Application Servers or Server Array

Database Servers

Often when scaling a database Server that is part of a master/slave configuration, you will complete the Steps mentioned above on the slave first.  A summary of remaining steps you will likely include in your procedure are as follows:

  • Sync the new Slave’s data off the current (smaller) Master (before launching it)
  • Run the Operational Script - 'Promote Slave to Master'
  • Launch a new (larger) slave database Server
  • Upgrade your “old” Master in similar fashion, so it is comparable in size and performance.
  • Make it the “new” Slave.


For more detail on steps to launching new database Servers, you should consult the documentation that pertains closest to your specific configuration, such as:

Note that you can also use the RightScale Forums ( or file a support ticket (  Determining when you need to scale a database Server usually requires a real DBA.  Database optimization regarding indexing, normalizing and identifying slow queries is best left to the experts.

If planned out thoroughly and executed carefully you can scale your database Servers with virtually no down time and no adjustments required to your applications because the RightScripts automatically make the necessary DNS adjustments for you.

You must to post a comment.
Last modified
13:50, 24 Sep 2014



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.