Follow the instructions below to set up an Advanced Failover Architecture as described in Best Practices for using Elastic IPs and Availability Zones. This setup has a production deployment where instances are running in more than one availability zone. In this setup, there are two frontend load balancers using Elastic IPs and the same number of application servers in each zone. Therefore, if there is a failure in one of the availability zones, your site's available performance will temporarily be cut directly in half. If redundancy is the main goal and there are no limits to your budget, you can create very complex deployments with instances spread across many zones.
Remember, if you have instances running in multiple availability zones, you'll have to pay for the zone-to-zone transfer fees. Data transferred between instances across different availability zones on EC2 costs $0.01 per GB.
This advanced architecture addresses the weaknesses of DNS multiple A record solutions. Either load balancer 1 or 2 could distribute load to any available application server. TTL delays that are inherent with any DNS scheme have been avoided.
If you follow the diagram above as an example, your production setup will consist of two active deployments with another deployment configured to launch in another zone. Each deployment will be dedicated to a particular zone. Notice that you're using an Elastic IP for each frontend load balancer with the same number of application servers in each availability zone. The clone operation makes this duplication a one-click solution (with a few adjustments later).
The next step is to clone the Production (1b) deployment and call the new one "Production (1c)". Remember, you do not want to clone "Production (1a)" because if the zone with the Master-DB fails, you will simply promote the Slave-DB to Master-DB and launch a new Slave-DB instance.
For advanced architectures, it's better to think at the deployment level, instead of at the individual server level. Instead of creating backups for each type of server, you can simply create backup deployments that are ready to be launched in a different availability zone if one of the zones stops.
Once you start thinking of collections of servers are a "Deployment Unit" the move from Zone to Zone is a simple operation.
Simply click the Clone button for a deployment and change the availability zones for all servers accordingly.
All of the servers in your account with the same network options are on the same local network even when in distinct deployments.
In this recipe, you do not want to launch the entire deployment at the same time. Do not use the "launch-all" button because it's important that the servers in the backup deployment are launched in the correct order.
If your Master-DB is large and takes a long time to start from backups, one advanced strategy would be to keep a Slave-DB "hot" by keeping one slave up and running in as many zones as you can afford.
In a failure scenario (or heavy load), the extra backup Slave-DB will already be connected to the load balancers and application servers, and be ready to serve a larger percent of the traffic. Most application servers launch quickly and can be added as needed. These "spare slaves" make a great place to test backup restore policy and QA new software. Occasionally you can restore a Slave-DB and check to make sure the data is correct. It provides a great place to perform these types of audits.
© 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.