Starting Up a Multi-Tiered Deployment

Overview

Whether or not your RightScale-managed Deployment in the cloud is designed to scale or not, it is very common to configure it with multiple tiers. For example, the following three tiers are typical:

1. Front-end tier that services (and load-balances) requests
2. Middle application tier
3. Back-end database tier

There are two common configurations of the above multi-tiered Deployment model as well. One has the first two tiers completely separate; that is, tier one is strictly for load balancers, and tier two is strictly for the application (usually a scalable Server Array with a minimum instance count of two).  The other combines your application and front-end services for two Servers (and adds a scalable Server Array as well). 

In this example, the application is being served by both the FrontEnd Servers and Servers in the Server Array.

In this example, the application is only being served by Servers in the Server Array.

Depending on your specific configuration, how you shut down or start up your Deployment could differ somewhat. 

The key for determining the order in which to shut down or start up your Deployment components is dependencies--for example, what do the Servers running your application depend on to start up or shut down correctly?

Disclaimer

Because each specific application and Deployment for that application is different, there is not a strict set of rules for shutting down or starting up a multi-tiered Deployment that applies in every scenario.  For that reason, please consider the information in this document as guidelines (and not strict rules). 

Remember to implement reboot-safe RightScripts (and/or Chef Recipes), and test out your Boot- and Decommission-phase scripts thoroughly.

Starting Up

Although your specific application and Deployment could have certain dependencies that dictate a different start order, the following is typically considered best practice for a start order of a multi-tiered Deployment.

• Begin by starting up your database tier.
  • First start your master database.
    • Once operational, you will want to restore from the most recent backup and update your DNS entries.  This is done for you when you run the operational RightScript:  DB EBS restore and become master  (See the scripts Info tab and the contents of the RightScript itself for additional details.)
    • Note:  The last thing this RightScript does is start a backup.  Let the snapshot finish before booting your Slave Server(s).  See Clouds > CloudName > EBS Snapshots (Status == 100% Completed)
  • Boot your slave (or slaves, if you have them).  Remember that the Input specifying to initialize the slave at boot (e.g. INIT_SLAVE_AT_BOOT) should be set to "false" for the master, and "true" for the slave(s).
• Start the Servers in your load balancing tier.
  • Note: If you have any ancillary Servers you should start them now as well before starting your application Servers.  For example, caching Servers (memcached) or load testers (httperf). 
• Start your application tier Servers (or Server Array)

Important!  Several other considerations may come into play, depending on your specific situation and context:

• If some time has elapsed since you last shut down your Deployment you probably discarded your EIPs in order to save on costs.  Don't forget you will have to create new EIPs and replace the old ones previously used by your Load Balancers as well as update DNS A Record information.
• If you start your application Servers before your load balancers are on line, you will need to manually run an operational (or "any script") to register the application Servers with your load balancers.  If they are not registered with the load balancers than they will not be able to service incoming requests.  An example boot or operational RightScript that does this for Deployments using HAproxy to load balance is: LB app to HA proxy connect.

See also

• Shutting down a multi-tiered Deployment
• Typical scalable web architectures