Uploaded byHarish Ganesan
Disaster Recovery using AWS -Architecture blueprints
The document outlines disaster recovery architecture using Amazon Web Services (AWS) with three blueprints, each highlighting different configurations for main and disaster recovery sites. It discusses key components and their functionalities like managed DNS, load balancing, and database replication, while weighing the pros and cons of each architecture. Recommendations for suitable use cases are provided for each blueprint, addressing scalability, availability, and cost-effectiveness.
In this document
Powered by AI
Introduction to disaster recovery architecture using AWS, mentioning key elements like DNS, load balancers, and high availability.
Explains three blueprints for disaster recovery: both sites in AWS, main site in AWS and DR in traditional center, and vice versa.
Lists AWS tools used in DR blueprints such as Security Groups, Elastic Load Balancing, EC2, EBS, and other components like DNS and MySQL replication.
Details Blueprint 1 where both main and DR sites are in AWS, discussing architecture elements like web servers, DNS, load balancers, scaling, and replication.
Highlights benefits of Blueprint 1 such as high availability and elasticity, alongside concerns regarding dependency on AWS and migration costs.
Shows architectural objectives for both main and DR sites, emphasizing key functionalities like load balancing and monitoring.
Discusses EBS and S3 as critical components for storage and data management in disaster recovery solutions.
Explains the significance of AWS Elastic Load Balancer and Auto Scaling in managing application traffic and adapting to load changes.
Describes AWS CloudWatch monitoring capabilities and the role of Managed DNS in ensuring seamless recovery.
Explains the setup and benefits of MySQL Master-Master replication for data integrity in DR architecture.
Details on Blueprint 2 where the main site is in AWS and DR is in a traditional center, including its architecture and scalability challenges.
Lists objectives for Blueprint 2 functionality and highlights the complexities and potential issues related to maintaining a hybrid architecture.
Explains Blueprint 3 with the main site in a traditional center and DR in AWS, focusing on scaling, challenges, and architectural objectives.
Discusses the suitability of the three blueprints based on operational needs and existing infrastructure contracts.
Encourages working with experts to determine suitable cloud-based disaster recovery strategies.
Provides contact details for further inquiries related to AWS disaster recovery solutions.
More Related Content
Similar to Disaster Recovery using AWS -Architecture blueprints
Disaster Recovery using AWS -Architecture blueprints
- 1. Disaster Recovery usingAWS Architecture Blueprints Harish Ganesan Co founder & CTO 8KMiles Harish11g.AWS@gmail.com www.twitter.com/harish11g http://www.linkedin.com/in/harishganesan
- 2. Introduction • Explore variousways of architecting Disaster recovery using Amazon cloud (AWS) • Sample architecture element contains Managed DNS servers , Load Balancers and Data replicators • Failover , Scalability , Load Balancing , Monitoring ,Back up/Recovery and High Availability is factored in the architecture Blue prints
- 3. DR Architecture blueprintsusing AWS • Blue print1 :Both Main Site and Disaster recovery site in AWS Cloud • Blue print2 : Main site in AWS cloud and Disaster recovery site in Traditional customer data center • Blue print3 : Main site in customer data center and Disaster recovery site in AWS cloud
- 4. List of AWSused in DR Blue prints • AWS Security groups • AWS Elastic Load balancing • AWS Auto Scaling • AWS EC2 & EBS • AWS CloudWatch • AWS Elastic IP • AWS S3
- 5. List of OtherArchitectural components used • Managed DNS • LAMP (or) LAMJ stack • MySQL Master- Master replication • SOLr Search servers • Schedulers and Back ground programs
- 6. Blue Print 1: Main and DR website in AWS Main web site is hosted Disaster Recovery (DR) in AWS USA east region web site is hosted in AWS Europe region
- 7. Blue Print 1: Main and DR website in AWS Main website in AWS Cloud AWS Europe region AWS USA east region Disaster Recovery website in AWS Cloud
- 8. Blue Print 1:Main and DR website in AWS GEO IP / Directional DNS Servers directs the user requests to Main site in AWS USA region. In case of Disaster in Main site 1 AWS USA region , the web requests are directed to DR site in Europe GEO IP / Directional DNS Servers Main Site - AWS USA DR Site - AWS Europe Region Region AWS Auto scaling / AWS Elastic Load AWS Auto scaling / AWS Elastic Load Balancer Balancer ELB redirects incoming requests to 2 same Web / APP server based on C C Session Sticky Algorithm L L Web/App Servers Elastic IP O Web/App Servers Elastic IP O EBS U EBS U EC2 D EC2 D MySQL Master W MySQL Master W Search Servers A Search Servers A 3 MySQL T MySQL T Master Schedulers/BG C Master Schedulers/BG C MySQL Master – Master Data H H replication D D Master – Master Data replication
- 9. Blue Print 1: Architecture Explanation • Main website(MWS) hosted in AWS USA east • Disaster recovery website(DRW) hosted in AWS Europe • Managed DNS passes the web requests to Main website under normal circumstances • AWS Elastic Load Balancer of MWS passes the request to appropriate web/app servers • Web / App servers are Amazon EC2 instances configured with AWS EBS • Web / App servers are enabled with Boot from EBS Continued
- 10. Blue Print 1: Architecture Explanation • Web/App servers are configured with AWS auto scaling ( Min 2 and Max 20) • MySQL Data base servers are configured in Master-Master replication mode • MySQL M-M replication inside Main site (MWS) • MySQL M-M replication between Main and DR site ( Asynchronous mode) • MySQL Servers are Amazon EC2 instances with AWS EBS ( Both Main and DR site) Continued
- 11. Blue Print 1: Architecture Explanation • MySQL servers are manually scaled in Main site • Main website (MWS) is monitored using AWS CloudWatch • An exact replica of Main website infrastructure can be run as DR website in AWS Europe • Web/App servers in DR website can be configured with AWS auto scaling ( Min 1 and Max 10) • In event of failure , managed DNS will pass the requests to DR website in Europe Continued
- 12. Blue Print 1: Architecture Explanation • Disaster recovery (DR) website can take over the requests seamlessly from the main website in this architecture • DR website can also auto scale its capacity depending upon the load , in short it can handle whatever the main site is architected for • Once the Main site is up, the Managed DNS will pass the web requests and DR website can Shrink down automatically to minimum capacity
- 13. Blue Print 1: Positives • Inter regional DR for High Availability • DR site can act immediately in event of Main site failure • DR site is designed to handle same load as the Main site • No compromises on the DR site with respect to Scalability, Security , Monitoring and Stability • Elastic: DR site can expand and Shrink according to load like Main site • Cost effective and Highly available architecture
- 14. Blue Print 1: Negatives • Complete Dependency on AWS cloud • Technical intricacies in moving EBS volumes , S3 snapshots , AMIs between AWS USA and Europe regions • Migration cost of moving both Main and DR site to the AWS Cloud • Impacts on existing customer data center contracts • Impact of typical cloud problems like Slow IO, privacy and regulations apply here
- 15. Blue Print 1: Architectural Objectives Objectives Main site DR site Elastic Load balancing Auto Scaling Failover High Availability Monitoring Management Replication inside a region Replication across regions Security Backups Recovery
- 16. Solution Components :EC2 and EBS • Elastic Block Storage (EBS) – Amazon Elastic Block Store (EBS) provides block level storage volumes for use with Amazon EC2 instances. – Amazon EBS is particularly suited for applications that require a database, file system, or access to raw block level storage. – Our Use case :Application executables , configurations , Data base files and OS are installed in the AWS EBS in this reference architecture .
- 17. Solution Components :AWS S3 • Simple Storage Service (S3) – Amazon S3 provides a simple web services interface that can be used to store and retrieve any amount of data, at any time, from anywhere on the web. – Our Use case : The application data files that are uploaded , AWS EBS snapshots are stored in S3.
- 18. Solution Components :AWS ELB • Elastic Load Balancer (ELB) – Elastic Load Balancing automatically distributes incoming application traffic across multiple Amazon EC2 instances. – Elastic Load Balancing detects unhealthy instances within a pool and automatically reroutes traffic to healthy instances until the unhealthy instances have been restored. – Our Use case : Load Distributed among Servers located in Multiple AZ and Dynamically Auto Scaled EC2 instances
- 19. Solution Components :AWS Auto Scaling • Auto Scaling – Auto Scaling allows you to automatically scale your Amazon EC2 capacity up or down according to conditions you define. – Auto Scaling is particularly well suited for applications that experience hourly, daily, or weekly variability in usage. – Our Use case : EC2 Server instances dynamically Scaled up and Down depending upon the Load using the Auto scaling
- 20. Solution Components :AWS CloudWatch • AWS CloudWatch – Amazon CloudWatch enables you to monitor your Amazon web services in real-time. – Amazon CloudWatch helps us to access up-to-the- minute statistics, graphs, and set alarms for our metric data. – Our Use case : EC2 servers , EBS , ELB are monitored and alerts are sent using AWS CloudWatch
- 21. Solution Components :Managed DNS • Managed DNS – a solution that can monitor the health of multiple endpoints or websites and automatically failover at DNS level in case of a failure at the primary website – Our Use case : Used for transparent switch between Main and Disaster recovery website during failures
- 22. Solution Components :MySQL replication • MySQL Replication – MySQL will be setup in Master – Master replication mode – M-M setup offers failover inside data center as well as across Data centers – Data Replication will be done asynchronously – Our Use case : Data is replicated between Main and DR website MySQL database using Master-Master replication
- 23. Blue Print 2: Main site in AWS Main web site is hosted in AWS USA east region Disaster Recovery (DR) web site is hosted in USA West in a Traditional data center
- 24. Blue Print 2: Main site in AWS Main website in AWS Cloud Traditional Data center- USA AWS USA east West DR website in Traditional data center
- 25. Blue Print 2:Main site in AWS – DR site in Traditional DC GEO IP / Directional DNS Servers directs the user requests to Main site in AWS USA region. In case of Disaster in Main site, 1 the web requests are directed to DR site in USA West GEO IP / Directional DNS Servers Main Site - AWS USA DR Site – Traditional DC in Region USA west AWS Auto scaling / AWS Elastic Load Manual scaling / Load Balancer Balancer ELB redirects incoming requests to 2 same Web / APP server based on C Session Sticky Algorithm M L O Elastic IP O Web/App Servers Web/App Servers N EBS U I EC2 D T MySQL W MySQL Master Master Search Servers O Search Servers A R 3 T MySQL MySQL S Master Schedulers/BG C Master Schedulers/BG MySQL Master – Master Data H replication D D Master – Master Data replication
- 26. Blue Print 2: Architecture Explanation • Main website(MWS) hosted in AWS USA east • DR website(DRW) hosted in Traditional data center in USA West • Managed DNS passes the web requests to Main website under normal circumstances • AWS Elastic Load Balancer of MWS passes the request to appropriate web/app servers • Web / App servers are enabled with Boot from EBS in Main site Continued
- 27. Blue Print 2: Architecture Explanation • Web/App servers are configured with AWS auto scaling ( Min 2 and Max 20) in Main site • MySQL Data base servers are configured in Master-Master replication mode • MySQL M-M replication inside Main site (MWS) • MySQL M-M replication between Main and DR site ( Asynchronous mode) • MySQL Servers are Amazon EC2 instances with AWS EBS in Main site Continued
- 28. Blue Print 2: Architecture Explanation • MySQL Servers are virtualized instances configured with Network storage in DR site • MySQL servers are manually scaled in both sites • Main website (MWS) is monitored using AWS CloudWatch • DR website will be monitored using Traditional data center tools • Web/App servers in DR website runs on minimal capacities Continued
- 29. Blue Print 2: Architecture Explanation • In event of failure , managed DNS will pass the requests to DR website in USA West • DR website can take over the requests seamlessly from the main website • DR website cannot scale its capacity depending upon the load , since it is runs on a minimal non elastic capacity it cannot handle similar loads of Main site
- 30. Blue Print 2: Positives • DR site MAY act immediately in event of Main site failure (depending upon hot /warm/cold DR strategies) • Leverage the existing infra contracts with Traditional data center provider • Cloud adoption and migration in phases (first main site followed by DR site) • Main Site handles load and DR site is a low cost Stop gap alternative during failures • Partial dependency on AWS
- 31. Blue Print 2: Negatives • Very complicated architecture for management – 2 types of monitoring , provisioning, backup ,Security etc , In short 2 different infrastructure architectures has to be maintained by the sys admins – Can turn in to a maintenance nightmare if not administered well • DR site cannot handle and sustain the loads of Main site . • Cannot guarantee High availability • Cost ineffective on the Sys Administration front
- 32. Blue Print 2: Architectural Objectives Objectives Main site DR site Elastic Load balancing X Auto Scaling X Failover High Availability X Monitoring Management Replication inside a region Replication across regions Security Backups Recovery
- 33. Blue Print 3: DR site in AWS Main web site is hosted in Traditional Data center in USA east region Disaster Recovery (DR) web site is hosted in AWS USA West Region
- 34. Blue Print 3: DR site in AWS DR website in AWS Cloud Traditional Data center- USA AWS USA west east Main website in Traditional data center
- 35. Blue Print 3:DR site in AWS – Main site in Traditional DC GEO IP / Directional DNS Servers directs the user requests to Main site in USA east region. In case of Disaster in Main site, 1 the web requests are directed to DR site in AWS USA West region GEO IP / Directional DNS Servers Main Site – Traditional DC in DR Site - AWS USA west USA east Region AWS Auto scaling / AWS Elastic Load Manual scaling / Load Balancer Balancer ELB redirects incoming requests to 2 same Web / APP server based on C M Session Sticky Algorithm L O Elastic IP O Web/App Servers N Web/App Servers EBS U I EC2 D T MySQL MySQL W Master Search Servers O Master Search Servers A R 3 T MySQL S MySQL Master Schedulers/BG Master Schedulers/BG C MySQL Master – Master Data H replication D D Master – Master Data replication
- 36. Blue Print 3: Architecture Explanation • Main website(MWS) hosted in USA east in Traditional Data center • DR website(DRW) hosted in AWS USA west region • Managed DNS passes the web requests to Main website under normal circumstances • Load Balancer of Main site passes the request to appropriate web/app servers Continued
- 37. Blue Print 3: Architecture Explanation • Web/App servers are configured with Manual scaling in Main site • MySQL Data base servers are configured in Master-Master replication mode • MySQL M-M replication inside Main site (MWS) • MySQL M-M replication between Main and DR site ( Asynchronous mode) Continued
- 38. Blue Print 3: Architecture Explanation • MySQL servers are manually scaled in both sites • DR website (MWS) is monitored using AWS CloudWatch • Main website will be monitored using Traditional data center tools • Web/App servers in Main website runs on minimal capacities Continued
- 39. Blue Print 3: Architecture Explanation • In event of failure , managed DNS will pass the requests to DR website in USA West • DR website can take over the requests seamlessly from the main website • DR website running in AWS UAS west can easily scale its capacity depending upon the load
- 40. Blue Print 3: Positives • DR site can act immediately in event of Main site failure • Leverage the existing infra contracts with Traditional data center provider • Cloud adoption and migration in phases (first DR site followed by Main site) • Main Site handles predictable load and Elastic DR site will act as Stop gap alternative during failures • Partial dependency on AWS • Cost effective
- 41. Blue Print 3: Negatives • Very complicated architecture for management – 2 types of monitoring , provisioning, backup ,Security etc , In short 2 different infrastructure architectures has to be maintained by the sys admins – Can turn in to a maintenance nightmare if not administered well • Cannot guarantee High availability • Cost ineffective on the Sys Administration front
- 42. Blue Print 3: Architectural Objectives Objectives Main site DR site Elastic Load balancing X Auto Scaling X Failover High Availability Monitoring Management Replication inside a region Replication across regions Security Backups Recovery
- 43. DR Architecture blueprintssuitability • Blue print1 :Both Main Site and Disaster recovery site in AWS Cloud – Suitable for web applications , Mobile apps , social and gaming websites – Unpredictable load bursts , growing companies • Blue print2 : Main site in AWS cloud and Disaster recovery site in Traditional customer data center – Enterprises web applications, online Media companies etc which already have 1-2 years contracts signed with traditional data centers – Fairly predictable or “On & Off” workload bursts
- 44. DR Architecture blueprintssuitability • Blue print3 : Main site in customer data center and Disaster recovery site in AWS cloud – Suitable for applications with predictable loads – SMB companies which already have 1-2 years contracts signed with traditional data centers
- 45. Which is theright Cloud based disaster recovery strategy for me?
- 46. Leave it tothe experts , we will solve this Cloud Adoption Strategy Cloud Architecture Consulting Cloud Migration Cloud Application Development Cloud Implementation “Let's get the job done”
- 47.