Cloud Disaster Recovery: Leveraging Cloud Computing for Cheap Hot Sites

The small and medium business (SMB) are often deployed with just enough technology to run their operations due to financial constraints. Disaster recovery sites are rarely implemented for a company who likely cannot afford the costs to duplicate their entire infrastructure elsewhere, just-in-case.

Cloud computing holds a lot of promise for these companies due to the on-demand nature of resources available. Come learn how cloud computing (utilizing AWS) can offer those businesses a cost-effective method of continuing operations even if a worst-case scenario does afflict them. Discussion of a real-life scenario will be covered and the math and pros/cons of the plan will be reviewed.

Transcript

1. CLOUD DISASTER RECOVERY Leveraging Cloud Computing for Cheap Hot Sites
2. ME Senior Linux System Administrator for MNX Solutions; MSP in Monroe Built/taught Linux curriculum for Eastern Michigan University Previously the cloud computing subject matter expert for ePrize Deployed multi-cloud provider scalable infrastructure to handle Super Bowl advertising traffic for two digital promotions in 2010 Hold the Certificate of Cloud Security Knowledge (CCSK) from the Cloud Security Alliance Present at events on configuration management & scalability in cloud computing and other elastic infrastructure
3. Disaster Recovery Plans Cold Site: Location is prepared to service a failure without any existing hardware or backup data deployed Warm Site: Location is prepared to service a failure with hardware on the ready but not likely to have backup data there or at a smaller scale of capacity than a hot site Hot Site: Full production setting with near-complete backup data already deployed and ready to turn the key if there’s a failure
4. DRP: Cost Versus Benefit A hot site is obviously the most cost prohibitive as you want full parity to your existing environment in order to support production needs on a whim; this is rarely cheap! A warm site gives you a middle ground between preparedness and savings in that you may not be fully able to sustain 100% production computing but you’re able to get back online fast with some capacity much quicker than a cold site A cold site is cheap as you basically just have a shell of a plan deployed and have to get the rest together only if there is a failure
5. Why Do Hot Sites Cost So Much? Considerations for Cost: Server, network, and storage hardware duplication from main site Power needs are same as main site Network costs are likely the same as the main site Man power to stage, manage, and sanity check second environment Courier costs for off-site backups to be brought to the hot site
6. So What About ‘The Cloud’? Cloud computing allows for on-demand, elastic, measured, pooled service (infrastructure, platform, software) with broad network access A hot site needs resources that are ready to implement, can quickly scale-up, able to provide adequate network connectivity, and has data at the ready With the essential tenets of ‘cloud computing’ (as defined by NIST) being thought of in relation to hot sites, there’s an obvious correlation that could be leveraged
7. Cloud Hot Site Benefits You can stage resources, put them ‘offline’ and pay minimal data storage costs until you need to deploy them (‘spin them up’) Data storage costs are rather cheap: $0.10/GB at Amazon Web Services; $0.15/GB at Rackspace Cloud No overhead data center, power, networking, or hardware costs Deployment of cloud resources are not relegated to one data center; stage your resources in many states or even countries with one provider and the same methodologies
8. Making the Business Case Let’s talk about the Small and Medium Business (SMB): Don’t necessarily have the money to duplicate their 10 or 20 servers + networking + storage + power + facility costs Want to be fault-tolerant and have a DRP/BCP that works Pleasing customers is of the utmost priority; can’t afford to lose people due to downtime Can make the leap to a public cloud provider more easily due to the limited scope of computing resources needed
9. Framing Our Scenario Company Type: Web radio streaming for regional FM stations Infrastructure: Five servers @ $200/mo each 1 Load Balancer, 3 Web Servers, 1 Database Server Bandwidth Usage: 5 TB/Month (167GB/Day) Storage Usage: 400GB total across servers Other: 2 Static IPs; Linux Servers (8GB RAM; 4 x 2GHz Cores)
10. Framing Our Scenario, Cont. General Amazon Web Services Cost Factors: Static IP: In use is free; $0.01/hr if not, per IP Storage: $0.10/GB + $0.10/million I/O requests Bandwidth: $0.125/GB (In/Out Cost Average) Load Balancer: $0.025/hr + $0.008/GB transfer Servers: TBD based on which option is in use
11. Cheap and Dirty Cloud DR 1.Use a single t1.micro EC2 instance (1.7GB RAM, 1 x 1.8Ghz Core) 2.Build an EC2 Linux volume with ~500GB of storage + OS installed 3.Install the database and web server software + configs and starting data points 4.Register 1 static IP address for the database server 5.Create a rudimentary script that will: 1.Boot the EC2 instance on a given schedule (likely once an hour) 2.Synchronize server files + SQL data + configurations files (deltas only) 3.Shut the EC2 instance back down
12. Example DRP Run Book 1. Take the existing one EC2 instance and create three more copies 2. Change the instance type from t1.micro to m1.large 1. m1.large provides 7.5GB of RAM, 4 x 1.8GHz cores 3. Assign the database server its static IP address 4. Associate the three web server instances with an elastic load balancer 5. Edit DNS to point hosts to the new load balancer + database server 6. Alter configurations as needed and restore recent SQL data 7. Start services and execute some sort of sanity check script
13. Breaking Down Costs Monthly Carrying Costs Server $0.085/HR 120 HRS $10.20 Storage $0.100/GB 500 GB $50.00 Bandwidth $0.125/GB 250 GB $31.25 Static IPs $0.010/HR 720 HRS $7.20 Balancer Time $0.025/HR 0 HRS $0.00 Balancer Data $0.008/GB 0 GB $0.00 Monthly Total: Monthly Total: Monthly Total: $98.65 10 minutes of ‘server time’ per hour for data synchronization 250GB of deltas a month for production data versus EC2 DR site
14. Breaking Down Costs, cont. DR Cutover Costs for ONE WEEK Server $0.340/HR 4 x 168 HRS $228.48 Storage $0.100/GB 4 x 500 GB $46.66 Bandwidth $0.125/GB 1.176TB $147.00 Static IPs $0.010/HR 0 HRS $0.00 Balancer Time $0.025/HR 168 HRS $4.20 Balancer Data $0.008/GB 1.176TB $9.41 One Week Total: One Week Total: One Week Total: $435.75 ...or $1,867 a month; $867 more a month than usual
15. Cheap and Dirty DR Review For less than $100 a month you can scale from 1 meager, part- time instance up to 4 powerful instances with a load balancer in around 10 minutes if needed Configuration and data are less than an hour old generally $1,200 a year for an efficient, on-demand disaster recovery site; equivalent to just over 1 month of normal production operation This disaster recovery site isn’t going to be cheaper to run, but it’s not made for that purpose; only in an emergency! But we can still do a bit better...
16. Improvements to Cloud DR Lower DNS TTLs on records that will be changing; stage your CNAME for the load balancer and database static IP address so it’s ready to go Utilize configuration management solutions like Puppet to help synchronize data & configuration in a more organized, efficient way Run your t1.micro instance constantly and setup SQL slave replication rather than copying SQL dumps (with SSL of course...) Create an autoscaling group that will continue to add resources to improve your hot site as demand hits the servers
17. Potential Additional Savings Resize your Amazon volume to reasonable sizes and synchronize data to your new servers when you execute your run book; this will save on the 500GB volumes for each host you’d otherwise have With an autoscale group, start with one web server and add more/less capacity as needed to help reduce costs when you failover to cloud Utilize t1.micro instances for your web servers rather than m1.large and auto-scale smaller units of capacity for more granular savings Buy a reserved EC2 instance and save even more on carrying-cost Consider a different off-site storage provider who may be cheaper
18. Who This is Good For? If you or a client needs to have a reliable infrastructure but doesn’t necessarily have a budget to match their necessity, look into doing a cloud disaster recovery site If you don’t have a situation where public cloud infrastructure is a regulatory no-no or other legal impediments would prevent it You or your IT staff can feel comfortable with a given cloud provider, Amazon or otherwise, to implement a solution that leverages the best they have to offer for the least cost ...or you’re just looking for a reason still to use a real cloud provider ;)
19. Oh, and Don’t Forget... 750 hours of EC2 running Linux/Unix Micro instance usage 750 hours of Elastic Load Balancing plus 15 GB data processing 10 GB of Amazon Elastic Block Storage (EBS) plus 1 million IOs, 1 GB snapshot storage, 10,000 snapshot Get Requests and 1,000 snapshot Put Requests 15 GB of bandwidth in and 15 GB of bandwidth out aggregated across all AWS services ...New AWS Customers Get... For FREE for the first year! http://aws.amazon.com/free/
20. Thank You! Questions? mark.stanislav@gmail.com @markstanislav uncompiled.com