RightScale User Conference NYC 2011 - Brian Adler - Solutions Architect, RightScale As a result of assisting many customers with complex multi-tiered deployments across diverse industries and use cases, RightScale Professional Services has amassed a set of best practices for deploying applications in highly available, fault-tolerant environments. These configurations may span multiple zones, regions, and clouds from multiple vendors, or they may simply be designed for portability so they can be readily redeployed from one cloud to another for performance, price, geo-location, or other drivers. This session will cover best practices and tips and tricks for architecting multi-zone and multi-cloud deployments.

1. Architecting for High-Availability and Multi-Cloud Environments Brian Adler - Sr. Professional Services Architect, RightScale June 8th, 2011

3. Takeaways

4. Designing for Failure

5. Cloud and component definitions (more terminology)

6. Architectural options and considerations to protect against cloud failures

8. Designs incorporating redundancy and replication to enable systems to continue operating properly (perhaps at a degraded level) if one or more components fails

9. High Availability (HA)

10. Fault Tolerant systems are measured by their Availability in terms of planned and unplanned service outages for end users

11. 99% Availability = 3.65 days of downtime per year

12. 99.9% Availability = 8.76 hours of downtime per year

13. 99.99% Availability = 53 minutes of downtime per year

14. 99.999% Availability = 5.26 minutes of downtime per year

15. Disaster Recovery (DR)

17. Takeaways

18. Designing for Failure

19. Cloud and component definitions (more terminology)

20. Architectural options and considerations to protect against cloud failures

22. Best Practices for implementation of these architectural options

23. Multi-Availability Zone (AZ), Multi-Region and Multi-Cloud

24. Architectural options

26. Takeaways

27. Designing for Failure

28. Cloud and component definitions (more terminology)

29. Architectural options and considerations to protect against cloud failures

31. Application owners are ultimately responsible for availability and recoverability

32. Need to balance cost and complexity of HA efforts against risk(s) you are willing to bear

33. Cloud infrastructure has made DR and HA remarkably affordable versus past options

34. Multi-Server

35. Multi-AZ

36. Multi-Region

38. Takeaways

39. Designing for Failure

40. Cloud and component definitions (more terminology)

41. Architectural options and considerations to protect against cloud failures

43. What does that really mean?

44. Amazon Web Services is not a cloud

45. EC2 is not a cloud

46. Eucalyptus, Cloud.com, OpenStack are not clouds

47. EC2 US-East, Rackspace, ‘my private cloud’… these are clouds

48. An availability zone is not a cloud (but it is part of one)Think of a cloud as a “resource pool” accessed via an API

50. Zones utilize separate power sources, are physically segregated

52. Different sets of available resources

53. Different formats, encodings and versions

54. Abstractions and features differ

55. Network architectures differ: VLANs, security groups, NAT, IPs, ACLs, …

56. Storage architectures differ: local/attachable disks, backup, snapshots, …

57. Hypervisors, machine images, cost models, billing, reporting… etc.Each cloud is unique in some/many/all respects, with different access mechanisms and varying functionalities provided by the managed resources.

59. Design using generic concepts (“durable storage”) yet deploy using cloud specifics (“EBS volumes”)

60. Have tools that translate your concepts to cloud-specific ones (e.g. scripts/recipes that choose the correct provider for the desired resource)

62. Takeaways

63. Designing for Failure

64. Cloud and component definitions (more terminology)

65. Infrastructure abstraction and automation as building blocks for highly available applications

66. Architectural options and considerations to protect against cloud failures

68. Develop expertise in-house and / or get outside help.

69. Conduct a risk assessment for each application.

70. Specify your target Recovery Time Objective and Recovery Point Objective.

71. Design for failure starting with application architecture. This will help drive the infrastructure architecture.

72. Implement HA best practices balancing cost, complexity and risk.

73. Automate infrastructure for consistency and reliability.

74. Document operational processes and automations.

75. Test the failover... then test it again.

78. Always place (at least) one of each component (load balancers, app servers, databases) in at least two AZs.

79. Maintain sufficient capacity to absorb AZ / cloud failures.

80. Reserved Instances – guarantee capacity is available in a separate region/cloud

81. Replicate data across AZs and backup or replicate across clouds/regions for failover.

82. Setup monitoring, alerts and operations to identify and automate problem resolution or failover process.

84. Multi-Cloud Cold / Warm / Hot DR Options No Downtime Multi-Cloud HA (Live/Live Config) Hot DR > 5 Minutes (Least Common) > 1 Hour Warm DR (Recommended) Cold DR > Few Hours (Most Common) $ $$ $$$ $$$$

86. Slow to replicate data to other cloud

88. Minimal additional cost

93. Takeaways

94. Designing for Failure

95. Cloud and component definitions (more terminology)

96. Infrastructure abstraction and automation as building blocks for highly available applications

97. Architectural options and considerations to protect against cloud failures

99. Assume everything will fail and architect a solution capable of handing each and every failure condition

100. No one size fits all solution is available

101. Every application has its own architecture

102. Not all infrastructure building blocks fit well with all applications

103. Tradeoffs between levels of resiliency and cost

104. The options available in the cloud today are unprecedented

105. Capabilities for global redundancy

106. Time to access

107. Investment required

108. Follow our High Availability Checklist (or create your own)

110. We hope to see you at our next RightScale User Conference! See all presentations and videos at RightScale.com/Conference.