Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Cloud DR: Leveraging Cloud Computing for Cheap Hot Sites

3,404 views

Published on

Published in: Technology, Business
  • Be the first to comment

Cloud DR: Leveraging Cloud Computing for Cheap Hot Sites

  1. 1. CLOUD DISASTER RECOVERY Leveraging Cloud Computing for Cheap Hot Sites
  2. 2. ME
  3. 3. MESenior Linux System Administrator for MNX Solutions; MSP in Monroe
  4. 4. MESenior Linux System Administrator for MNX Solutions; MSP in MonroeBuilt/taught Linux curriculum for Eastern Michigan University
  5. 5. MESenior Linux System Administrator for MNX Solutions; MSP in MonroeBuilt/taught Linux curriculum for Eastern Michigan UniversityPreviously the cloud computing subject matter expert for ePrize
  6. 6. MESenior Linux System Administrator for MNX Solutions; MSP in MonroeBuilt/taught Linux curriculum for Eastern Michigan UniversityPreviously 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
  7. 7. MESenior Linux System Administrator for MNX Solutions; MSP in MonroeBuilt/taught Linux curriculum for Eastern Michigan UniversityPreviously 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 2010Hold the Certificate of Cloud Security Knowledge (CCSK) from theCloud Security Alliance
  8. 8. MESenior Linux System Administrator for MNX Solutions; MSP in MonroeBuilt/taught Linux curriculum for Eastern Michigan UniversityPreviously 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 2010Hold the Certificate of Cloud Security Knowledge (CCSK) from theCloud Security AlliancePresent at events on configuration management & scalability in cloudcomputing and other elastic infrastructure
  9. 9. Disaster Recovery Plans
  10. 10. Disaster Recovery PlansCold Site: Location is prepared to service a failure without anyexisting hardware or backup data deployed
  11. 11. Disaster Recovery PlansCold Site: Location is prepared to service a failure without anyexisting hardware or backup data deployedWarm Site: Location is prepared to service a failure withhardware on the ready but not likely to have backup data there orat a smaller scale of capacity than a hot site
  12. 12. Disaster Recovery PlansCold Site: Location is prepared to service a failure without anyexisting hardware or backup data deployedWarm Site: Location is prepared to service a failure withhardware on the ready but not likely to have backup data there orat a smaller scale of capacity than a hot siteHot Site: Full production setting with near-complete backupdata already deployed and ready to turn the key if there’s a failure
  13. 13. DRP: Cost Versus Benefit
  14. 14. DRP: Cost Versus BenefitA hot site is obviously the most cost prohibitive as you want fullparity to your existing environment in order to supportproduction needs on a whim; this is rarely cheap!
  15. 15. DRP: Cost Versus BenefitA hot site is obviously the most cost prohibitive as you want fullparity to your existing environment in order to supportproduction needs on a whim; this is rarely cheap!A warm site gives you a middle ground between preparednessand savings in that you may not be fully able to sustain 100%production computing but you’re able to get back online fastwith some capacity much quicker than a cold site
  16. 16. DRP: Cost Versus BenefitA hot site is obviously the most cost prohibitive as you want fullparity to your existing environment in order to supportproduction needs on a whim; this is rarely cheap!A warm site gives you a middle ground between preparednessand savings in that you may not be fully able to sustain 100%production computing but you’re able to get back online fastwith some capacity much quicker than a cold siteA cold site is cheap as you basically just have a shell of a plandeployed and have to get the rest together only if there is a failure
  17. 17. Why Do Hot Sites Cost So Much?
  18. 18. Why Do Hot Sites Cost So Much?Considerations for Cost:
  19. 19. Why Do Hot Sites Cost So Much?Considerations for Cost: Server, network, and storage hardware duplication from main site
  20. 20. 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
  21. 21. 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
  22. 22. 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
  23. 23. 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
  24. 24. So What About ‘The Cloud’?
  25. 25. So What About ‘The Cloud’?Cloud computing allows for on-demand, elastic, measured,pooled service (infrastructure, platform, software) with broadnetwork access
  26. 26. So What About ‘The Cloud’?Cloud computing allows for on-demand, elastic, measured,pooled service (infrastructure, platform, software) with broadnetwork accessA hot site needs resources that are ready to implement, canquickly scale-up, able to provide adequate network connectivity,and has data at the ready
  27. 27. So What About ‘The Cloud’?Cloud computing allows for on-demand, elastic, measured,pooled service (infrastructure, platform, software) with broadnetwork accessA hot site needs resources that are ready to implement, canquickly scale-up, able to provide adequate network connectivity,and has data at the readyWith the essential tenets of ‘cloud computing’ (as defined byNIST) being thought of in relation to hot sites, there’s anobvious correlation that could be leveraged
  28. 28. Cloud Hot Site Benefits
  29. 29. Cloud Hot Site BenefitsYou can stage resources, put them ‘offline’ and pay minimal datastorage costs until you need to deploy them (‘spin them up’)
  30. 30. Cloud Hot Site BenefitsYou can stage resources, put them ‘offline’ and pay minimal datastorage costs until you need to deploy them (‘spin them up’)Data storage costs are rather cheap: $0.10/GB at Amazon WebServices; $0.15/GB at Rackspace Cloud
  31. 31. Cloud Hot Site BenefitsYou can stage resources, put them ‘offline’ and pay minimal datastorage costs until you need to deploy them (‘spin them up’)Data storage costs are rather cheap: $0.10/GB at Amazon WebServices; $0.15/GB at Rackspace CloudNo overhead data center, power, networking, or hardware costs
  32. 32. Cloud Hot Site BenefitsYou can stage resources, put them ‘offline’ and pay minimal datastorage costs until you need to deploy them (‘spin them up’)Data storage costs are rather cheap: $0.10/GB at Amazon WebServices; $0.15/GB at Rackspace CloudNo overhead data center, power, networking, or hardware costsDeployment of cloud resources are not relegated to one datacenter; stage your resources in many states or even countrieswith one provider and the same methodologies
  33. 33. Making the Business Case
  34. 34. Making the Business CaseLet’s talk about the Small and Medium Business (SMB):
  35. 35. Making the Business CaseLet’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
  36. 36. Making the Business CaseLet’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
  37. 37. Making the Business CaseLet’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
  38. 38. Making the Business CaseLet’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
  39. 39. Framing Our Scenario
  40. 40. Framing Our ScenarioCompany Type: Web radio streaming for regional FM stations
  41. 41. Framing Our ScenarioCompany Type: Web radio streaming for regional FM stationsInfrastructure: Five servers @ $200/mo each 1 Load Balancer, 3 Web Servers, 1 Database Server
  42. 42. Framing Our ScenarioCompany Type: Web radio streaming for regional FM stationsInfrastructure: Five servers @ $200/mo each 1 Load Balancer, 3 Web Servers, 1 Database ServerBandwidth Usage: 5 TB/Month (167GB/Day)
  43. 43. Framing Our ScenarioCompany Type: Web radio streaming for regional FM stationsInfrastructure: Five servers @ $200/mo each 1 Load Balancer, 3 Web Servers, 1 Database ServerBandwidth Usage: 5 TB/Month (167GB/Day)Storage Usage: 400GB total across servers
  44. 44. Framing Our ScenarioCompany Type: Web radio streaming for regional FM stationsInfrastructure: Five servers @ $200/mo each 1 Load Balancer, 3 Web Servers, 1 Database ServerBandwidth Usage: 5 TB/Month (167GB/Day)Storage Usage: 400GB total across serversOther: 2 Static IPs; Linux Servers (8GB RAM; 4 x 2GHz Cores)
  45. 45. Framing Our Scenario, Cont.
  46. 46. Framing Our Scenario, Cont.General Amazon Web Services Cost Factors:
  47. 47. Framing Our Scenario, Cont.General Amazon Web Services Cost Factors: Static IP: In use is free; $0.01/hr if not, per IP
  48. 48. 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
  49. 49. 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)
  50. 50. 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
  51. 51. 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
  52. 52. Cheap and Dirty Cloud DR
  53. 53. Cheap and Dirty Cloud DR1. Use a single t1.micro EC2 instance (1.7GB RAM, 1 x 1.8Ghz Core)
  54. 54. Cheap and Dirty Cloud DR1. 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
  55. 55. Cheap and Dirty Cloud DR1. 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 installed3. Install the database and web server software + configs and starting data points
  56. 56. Cheap and Dirty Cloud DR1. 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 installed3. Install the database and web server software + configs and starting data points4. Register 1 static IP address for the database server
  57. 57. Cheap and Dirty Cloud DR1. 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 installed3. Install the database and web server software + configs and starting data points4. Register 1 static IP address for the database server5. Create a rudimentary script that will:
  58. 58. Cheap and Dirty Cloud DR1. 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 installed3. Install the database and web server software + configs and starting data points4. Register 1 static IP address for the database server5. Create a rudimentary script that will: 1. Boot the EC2 instance on a given schedule (likely once an hour)
  59. 59. Cheap and Dirty Cloud DR1. 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 installed3. Install the database and web server software + configs and starting data points4. Register 1 static IP address for the database server5. 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)
  60. 60. Cheap and Dirty Cloud DR1. 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 installed3. Install the database and web server software + configs and starting data points4. Register 1 static IP address for the database server5. 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
  61. 61. Example DRP Run Book
  62. 62. Example DRP Run Book1. Take the existing one EC2 instance and create three more copies
  63. 63. Example DRP Run Book1. Take the existing one EC2 instance and create three more copies2. Change the instance type from t1.micro to m1.large 1. m1.large provides 7.5GB of RAM, 4 x 1.8GHz cores
  64. 64. Example DRP Run Book1. Take the existing one EC2 instance and create three more copies2. Change the instance type from t1.micro to m1.large 1. m1.large provides 7.5GB of RAM, 4 x 1.8GHz cores3. Assign the database server its static IP address
  65. 65. Example DRP Run Book1. Take the existing one EC2 instance and create three more copies2. Change the instance type from t1.micro to m1.large 1. m1.large provides 7.5GB of RAM, 4 x 1.8GHz cores3. Assign the database server its static IP address4. Associate the three web server instances with an elastic load balancer
  66. 66. Example DRP Run Book1. Take the existing one EC2 instance and create three more copies2. Change the instance type from t1.micro to m1.large 1. m1.large provides 7.5GB of RAM, 4 x 1.8GHz cores3. Assign the database server its static IP address4. Associate the three web server instances with an elastic load balancer5. Edit DNS to point hosts to the new load balancer + database server
  67. 67. Example DRP Run Book1. Take the existing one EC2 instance and create three more copies2. Change the instance type from t1.micro to m1.large 1. m1.large provides 7.5GB of RAM, 4 x 1.8GHz cores3. Assign the database server its static IP address4. Associate the three web server instances with an elastic load balancer5. Edit DNS to point hosts to the new load balancer + database server6. Alter configurations as needed and restore recent SQL data
  68. 68. Example DRP Run Book1. Take the existing one EC2 instance and create three more copies2. Change the instance type from t1.micro to m1.large 1. m1.large provides 7.5GB of RAM, 4 x 1.8GHz cores3. Assign the database server its static IP address4. Associate the three web server instances with an elastic load balancer5. Edit DNS to point hosts to the new load balancer + database server6. Alter configurations as needed and restore recent SQL data7. Start services and execute some sort of sanity check script
  69. 69. Breaking Down Costs Monthly Carrying CostsServer $0.085/HR 120 HRS $10.20Storage $0.100/GB 500 GB $50.00Bandwidth $0.125/GB 250 GB $31.25Static IPs $0.010/HR 720 HRS $7.20Balancer Time $0.025/HR 0 HRS $0.00Balancer Data $0.008/GB 0 GB $0.00 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
  70. 70. Breaking Down Costs, cont. DR Cutover Costs for ONE WEEKServer $0.340/HR 4 x 168 HRS $228.48Storage $0.100/GB 4 x 500 GB $46.66Bandwidth $0.125/GB 1.176TB $147.00Static IPs $0.010/HR 0 HRS $0.00Balancer Time $0.025/HR 168 HRS $4.20Balancer Data $0.008/GB 1.176TB $9.41 One Week Total: $435.75 ...or $1,867 a month; $867 more a month than usual
  71. 71. Cheap and Dirty DR Review
  72. 72. Cheap and Dirty DR ReviewFor less than $100 a month you can scale from 1 meager, part-time instance up to 4 powerful instances with a load balancer inaround 10 minutes if needed
  73. 73. Cheap and Dirty DR ReviewFor less than $100 a month you can scale from 1 meager, part-time instance up to 4 powerful instances with a load balancer inaround 10 minutes if neededConfiguration and data are less than an hour old generally
  74. 74. Cheap and Dirty DR ReviewFor less than $100 a month you can scale from 1 meager, part-time instance up to 4 powerful instances with a load balancer inaround 10 minutes if neededConfiguration 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
  75. 75. Cheap and Dirty DR ReviewFor less than $100 a month you can scale from 1 meager, part-time instance up to 4 powerful instances with a load balancer inaround 10 minutes if neededConfiguration 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 operationThis disaster recovery site isn’t going to be cheaper to run, butit’s not made for that purpose; only in an emergency!
  76. 76. Cheap and Dirty DR ReviewFor less than $100 a month you can scale from 1 meager, part-time instance up to 4 powerful instances with a load balancer inaround 10 minutes if neededConfiguration 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 operationThis disaster recovery site isn’t going to be cheaper to run, butit’s not made for that purpose; only in an emergency!But we can still do a bit better...
  77. 77. Improvements to Cloud DR
  78. 78. Improvements to Cloud DRLower DNS TTLs on records that will be changing; stage your CNAMEfor the load balancer and database static IP address so it’s ready to go
  79. 79. Improvements to Cloud DRLower DNS TTLs on records that will be changing; stage your CNAMEfor the load balancer and database static IP address so it’s ready to goUtilize configuration management solutions like Puppet to helpsynchronize data & configuration in a more organized, efficient way
  80. 80. Improvements to Cloud DRLower DNS TTLs on records that will be changing; stage your CNAMEfor the load balancer and database static IP address so it’s ready to goUtilize configuration management solutions like Puppet to helpsynchronize data & configuration in a more organized, efficient wayRun your t1.micro instance constantly and setup SQL slave replicationrather than copying SQL dumps (with SSL of course...)
  81. 81. Improvements to Cloud DRLower DNS TTLs on records that will be changing; stage your CNAMEfor the load balancer and database static IP address so it’s ready to goUtilize configuration management solutions like Puppet to helpsynchronize data & configuration in a more organized, efficient wayRun your t1.micro instance constantly and setup SQL slave replicationrather than copying SQL dumps (with SSL of course...)Create an autoscaling group that will continue to add resources toimprove your hot site as demand hits the servers
  82. 82. Potential Additional Savings
  83. 83. Potential Additional SavingsResize your Amazon volume to reasonable sizes and synchronize datato your new servers when you execute your run book; this will save onthe 500GB volumes for each host you’d otherwise have
  84. 84. Potential Additional SavingsResize your Amazon volume to reasonable sizes and synchronize datato your new servers when you execute your run book; this will save onthe 500GB volumes for each host you’d otherwise haveWith an autoscale group, start with one web server and add more/lesscapacity as needed to help reduce costs when you failover to cloud
  85. 85. Potential Additional SavingsResize your Amazon volume to reasonable sizes and synchronize datato your new servers when you execute your run book; this will save onthe 500GB volumes for each host you’d otherwise haveWith an autoscale group, start with one web server and add more/lesscapacity as needed to help reduce costs when you failover to cloudUtilize t1.micro instances for your web servers rather than m1.largeand auto-scale smaller units of capacity for more granular savings
  86. 86. Potential Additional SavingsResize your Amazon volume to reasonable sizes and synchronize datato your new servers when you execute your run book; this will save onthe 500GB volumes for each host you’d otherwise haveWith an autoscale group, start with one web server and add more/lesscapacity as needed to help reduce costs when you failover to cloudUtilize t1.micro instances for your web servers rather than m1.largeand auto-scale smaller units of capacity for more granular savingsBuy a reserved EC2 instance and save even more on carrying-cost
  87. 87. Potential Additional SavingsResize your Amazon volume to reasonable sizes and synchronize datato your new servers when you execute your run book; this will save onthe 500GB volumes for each host you’d otherwise haveWith an autoscale group, start with one web server and add more/lesscapacity as needed to help reduce costs when you failover to cloudUtilize t1.micro instances for your web servers rather than m1.largeand auto-scale smaller units of capacity for more granular savingsBuy a reserved EC2 instance and save even more on carrying-costConsider a different off-site storage provider who may be cheaper
  88. 88. Who This is Good For?
  89. 89. Who This is Good For?If you or a client needs to have a reliable infrastructure but doesn’tnecessarily have a budget to match their necessity, look into doing acloud disaster recovery site
  90. 90. Who This is Good For?If you or a client needs to have a reliable infrastructure but doesn’tnecessarily have a budget to match their necessity, look into doing acloud disaster recovery siteIf you don’t have a situation where public cloud infrastructure is aregulatory no-no or other legal impediments would prevent it
  91. 91. Who This is Good For?If you or a client needs to have a reliable infrastructure but doesn’tnecessarily have a budget to match their necessity, look into doing acloud disaster recovery siteIf you don’t have a situation where public cloud infrastructure is aregulatory no-no or other legal impediments would prevent itYou or your IT staff can feel comfortable with a given cloud provider,Amazon or otherwise, to implement a solution that leverages the bestthey have to offer for the least cost
  92. 92. Who This is Good For?If you or a client needs to have a reliable infrastructure but doesn’tnecessarily have a budget to match their necessity, look into doing acloud disaster recovery siteIf you don’t have a situation where public cloud infrastructure is aregulatory no-no or other legal impediments would prevent itYou or your IT staff can feel comfortable with a given cloud provider,Amazon or otherwise, to implement a solution that leverages the bestthey have to offer for the least cost...or you’re just looking for a reason still to use a real cloud provider ;)
  93. 93. Oh, and Don’t Forget... ...New AWS Customers Get... For FREE for the first year! http://aws.amazon.com/free/
  94. 94. Oh, and Don’t Forget... ...New AWS Customers Get...750 hours of EC2 running Linux/Unix Micro instance usage For FREE for the first year! http://aws.amazon.com/free/
  95. 95. Oh, and Don’t Forget... ...New AWS Customers Get...750 hours of EC2 running Linux/Unix Micro instance usage750 hours of Elastic Load Balancing plus 15 GB data processing For FREE for the first year! http://aws.amazon.com/free/
  96. 96. Oh, and Don’t Forget... ...New AWS Customers Get...750 hours of EC2 running Linux/Unix Micro instance usage750 hours of Elastic Load Balancing plus 15 GB data processing10 GB of Amazon Elastic Block Storage (EBS) plus 1 million IOs, 1GB snapshot storage, 10,000 snapshot Get Requests and 1,000snapshot Put Requests For FREE for the first year! http://aws.amazon.com/free/
  97. 97. Oh, and Don’t Forget... ...New AWS Customers Get...750 hours of EC2 running Linux/Unix Micro instance usage750 hours of Elastic Load Balancing plus 15 GB data processing10 GB of Amazon Elastic Block Storage (EBS) plus 1 million IOs, 1GB snapshot storage, 10,000 snapshot Get Requests and 1,000snapshot Put Requests15 GB of bandwidth in and 15 GB of bandwidth out aggregated acrossall AWS services For FREE for the first year! http://aws.amazon.com/free/
  98. 98. Thank You! Questions?mark.stanislav@gmail.com@markstanislavuncompiled.com

×