• Save
Disaster Recovery using AWS -Architecture blueprints
Upcoming SlideShare
Loading in...5
×
 

Disaster Recovery using AWS -Architecture blueprints

on

  • 10,204 views

This presentation explores various ways of architecting Disaster Recovery using Amazon Web services (AWS) Cloud The sample architecture element contains Managed DNS servers , Load Balancers and Data ...

This presentation explores various ways of architecting Disaster Recovery using Amazon Web services (AWS) Cloud The sample architecture element contains Managed DNS servers , Load Balancers and Data replicators , Amazon EC2 , MySQL M-M , AWS EBS ,AWS Elastic Load Balancing, AWS Auto Scaling , AWS CloudWatch and AWS S3

Statistics

Views

Total Views
10,204
Views on SlideShare
6,832
Embed Views
3,372

Actions

Likes
20
Downloads
1
Comments
1

17 Embeds 3,372

http://cloud.8kmiles.com 1863
http://cloudblog.8kmiles.com 1056
http://wilmersarmiento.tumblr.com 190
http://www.cloud.8kmiles.com 105
http://192.168.0.202 53
http://54.245.97.154 20
http://www.scoop.it 19
http://www.8kmiles.com 16
http://ec2-184-72-177-141.compute-1.amazonaws.com 13
http://www.linkedin.com 12
http://localhost 10
http://paper.li 6
https://wiki.wer-ist-moo.de 3
http://8kmilessoftwareservices.com 3
http://translate.googleusercontent.com 1
http://ec2-184-72-210-248.compute-1.amazonaws.com 1
http://www.slideshare.net 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Disaster Recovery and Business Continuity Planning now an AWS Cloud Solution Provider

    KingsBridge Systems is now an AWS Partner providing disaster recovery and business continuity planning services that is running on AWS EC2 Instances. Please check out the Partner link at

    http://aws.amazon.com/solutions/solution-providers/disasterrecovery/

    You can also find out more about the AWS hosted SaaS solution at

    http://www.disasterrecovery.com/products/overview.foundation.html

    The first step in effective disaster recovery and business continuity is planning. Then integration with your planning tool and physical Cloud solutions can help you reduce your business continuity recovery time objectives.

    I hope you will check out http://www.disasterrecovery.com upon reading this and call and ask us about our Amazon Web Services based solution.

    We are also looking to expand the integration of our solution with other AWS solution providers. Upon reviewing our solution if you think there is a potential win win win situation please do contact us.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Disaster Recovery using AWS -Architecture blueprints Disaster Recovery using AWS -Architecture blueprints Presentation Transcript

    • Disaster Recovery using AWS Architecture Blueprints Harish Ganesan Co founder & CTO 8KMiles Harish11g.AWS@gmail.com www.twitter.com/harish11g http://www.linkedin.com/in/harishganesan
    • Introduction• Explore various ways 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
    • DR Architecture blueprints using 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
    • List of AWS used in DR Blue prints• AWS Security groups• AWS Elastic Load balancing• AWS Auto Scaling• AWS EC2 & EBS• AWS CloudWatch• AWS Elastic IP• AWS S3
    • List of Other Architectural components used • Managed DNS • LAMP (or) LAMJ stack • MySQL Master- Master replication • SOLr Search servers • Schedulers and Back ground programs
    • Blue Print 1 : Main and DR website in AWSMain web site is hosted Disaster Recovery (DR)in AWS USA east region web site is hosted in AWS Europe region
    • 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
    • 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 CMySQL Master –Master Data H Hreplication D D Master – Master Data replication
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • Blue Print 1 : Architectural ObjectivesObjectives Main site DR siteElastic Load balancing  Auto Scaling  Failover  High Availability  Monitoring  Management  Replication inside a region  Replication across regions  Security  Backups  Recovery  
    • 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 .
    • 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.
    • 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
    • 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
    • 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
    • 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
    • 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
    • Blue Print 2 : Main site in AWSMain web site is hostedin AWS USA east region Disaster Recovery (DR) web site is hosted in USA West in a Traditional data center
    • Blue Print 2 : Main site in AWSMain website in AWS Cloud Traditional Data center- USA AWS USA east West DR website in Traditional data center
    • 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/BGMySQL Master –Master Data Hreplication D D Master – Master Data replication
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • Blue Print 2 : Architectural ObjectivesObjectives Main site DR siteElastic Load balancing  XAuto Scaling  XFailover  High Availability  XMonitoring  Management  Replication inside a region  Replication across regions  Security  Backups  Recovery  
    • Blue Print 3 : DR site in AWSMain web site is hostedin Traditional Data centerin USA east region Disaster Recovery (DR) web site is hosted in AWS USA West Region
    • Blue Print 3 : DR site in AWSDR website in AWS Cloud Traditional Data center- USA AWS USA west east Main website in Traditional data center
    • 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 ServersMain 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 OWeb/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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • Blue Print 3 : Architectural ObjectivesObjectives Main site DR siteElastic Load balancing X Auto Scaling X Failover  High Availability  Monitoring  Management  Replication inside a region  Replication across regions  Security  Backups  Recovery  
    • DR Architecture blueprints suitability• 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
    • DR Architecture blueprints suitability• 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
    • Which is the right Cloud based disasterrecovery strategy for me?
    • Leave it to the experts , we willsolve this Cloud Adoption Strategy Cloud Architecture Consulting Cloud Migration Cloud Application Development Cloud Implementation “Lets get the job done”
    • ContactHarish11g.aws@gmail.comhttp://in.linkedin.com/in/harishganesanwww.twitter.com/harish11ghttp://harish11g.blogspot.com 47