Advanced Site Recovery -- Technical Briefing
•Descargar como PPT, PDF•
1 recomendación•365 vistas
The document discusses DataCore's Advanced Site Recovery (ASR) solution. ASR allows organizations to distribute disaster recovery responsibilities across multiple smaller locations rather than relying on a single large disaster recovery site. It uses bidirectional replication between sites to keep disaster recovery locations up to date and allow workloads to failover seamlessly between primary and secondary sites during planned or unplanned outages. The key benefits of ASR are that it is fast, automated, universal in supporting different workloads, distributed across multiple sites, bidirectional to enable workloads to resume at the original location, and makes disaster recovery testing and verification easy.
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a Advanced Site Recovery -- Technical Briefing
Similar a Advanced Site Recovery -- Technical Briefing (20)
Más de James Price
Más de James Price (13)
Advanced Site Recovery -- Technical Briefing
- 1. 1© 2009 DataCore Software Corp. — All rights reserved © 2009 DataCore Software Corp Advanced Site Recovery (ASR)Advanced Site Recovery (ASR) Technical Briefing
- 2. 2© 2009 DataCore Software Corp. — All rights reserved TopicsTopics Why prepare for Site Recovery? Traditional approaches Motivation for splitting Disaster Recovery sites ASR unique attributes How it works Scenarios Combining HA with DR ASR Look & Feel Cut over procedure Central site restoration
- 3. 3© 2009 DataCore Software Corp. — All rights reserved Why Prepare for Site Recovery?Why Prepare for Site Recovery? Infrastructure failures Power, air conditioning, external network, etc. Equipment maintenance HW/SW upgrade, repairs, reconfiguration Facility closures Water leaks, fire, building construction/move, security lockdown Natural disasters Floods, earthquakes, storms, etc.
- 4. 4© 2009 DataCore Software Corp. — All rights reserved Regionally Distributed LocationsRegionally Distributed Locations VM Branch x Internet Central IT site
- 5. 5© 2009 DataCore Software Corp. — All rights reserved But, Single Disaster Recovery Site?But, Single Disaster Recovery Site? DR Site Remote Replication Central IT site • Fat pipe • Larger real-estate • More machines • Wasted resources • High-end Storage • Identical systems
- 6. 6© 2009 DataCore Software Corp. — All rights reserved Low Cost Alternative: 1-to-Many DRLow Cost Alternative: 1-to-Many DR VM VM VM VM Central IT site HA VM VM DR Site x Remote Replication Storage Virtualization • Thin pipes Storage Virtualization
- 7. 7© 2009 DataCore Software Corp. — All rights reserved ASR Unique AttributesASR Unique Attributes Take advantage of branch office locations Distribute DR responsibilities • One central site protected by 2 or more smaller locations • Viable with lower speed WAN circuits • Standard Windows Servers virtualize storage using Bi-directional replication No application dependencies No virtual machine dependencies No host agents
- 8. 8© 2009 DataCore Software Corp. — All rights reserved Combining HA with DRCombining HA with DR VM VM VM VM Central IT site HA Remote Replication
- 9. 9© 2009 DataCore Software Corp. — All rights reserved ASR – How it WorksASR – How it Works LUN LUN look-alike replicas ASR creates look- alike LUN replicas LUN replicas are completely identical Apps / VSEs / VMs don't encounter any differences Apps / VMs can be started in any location without modification Central IT Site DR Site Remote Replication
- 10. 10© 2009 DataCore Software Corp. — All rights reserved ASR Data FlowASR Data Flow Central IT siteCentral IT site PP SS SS DRDR L1L1 HA Optional DS1 DS1-DR Hourly Snapshots TransmiTransmi t Queuet Queue TransmiTransmi t Queuet QueueSync Mirror Sync Mirror Mapped (online) Mapped (offline) 1 2 L2L2 Only to restore Transmit Queue Kept current with DR site 3 DR Site xDR Site x Internet WAN PP DRDR
- 11. 11© 2009 DataCore Software Corp. — All rights reserved Failover: Two ScenariosFailover: Two Scenarios Controlled Scheduled cut over No data loss Minimally disruptive When: Major site maintenance Danger anticipated • Imminent ice storm • Hurricane • Flooding Relocation / facility move Uncontrolled No warning Some data loss • Buffered changes & caches never transmitted Crash-consistent system recovery
- 12. 12© 2009 DataCore Software Corp. — All rights reserved Cut Over ProcedureCut Over Procedure Controlled Suspend I/Os Flush caches Flush source buffer Await synchronization Restart on remote end Uncontrolled Restart on remote end
- 13. 13© 2009 DataCore Software Corp. — All rights reserved PP SS Central Site RestorationCentral Site Restoration Internet WAN Central IT siteCentral IT site PP SS L2L2 PP DRDR DS1 DS1-DR Restore Transmit Queue Updated from DR site Sync Mirror Mapped (offline) Mapped (online) 1 2 DR Site xDR Site x
- 14. 14© 2009 DataCore Software Corp. — All rights reserved Restoring Central SiteRestoring Central Site Controlled Suspend I/Os on remote DR site Flush caches Flush source buffer Await synchronization of all dependent volumes Apply changes to original virtual disks Uncontrolled Re-initialize Repeat for each DR site
- 15. 15© 2009 DataCore Software Corp. — All rights reserved Handling Link OutagesHandling Link Outages Elastic source buffer sized to accommodate 2 to 3 day WAN disruption Switches automatically to log mode when space is exhausted • Track blocks changed during outage • Transmit latest block contents when link is restored
- 16. 16© 2009 DataCore Software Corp. — All rights reserved Why Intermediate SnapshotsWhy Intermediate Snapshots Ensure point-in-time consistency across groups of volumes Separate from asynchronous updates that travel independently
- 17. 17© 2009 DataCore Software Corp. — All rights reserved Coordinating Dependent VolumesCoordinating Dependent Volumes Group operations • Single request drives simultaneous action across groups of virtual disks • In-band markers trigger remote snapshots Simplifies distributed updates
- 18. 18© 2009 DataCore Software Corp. — All rights reserved How is ASR Delivered?How is ASR Delivered? ASR Option - $2K per “region” Multi-day Implementation service • Performed by an ASR-authorized and trained DataCore solution provider Authorized partner requirements • DCIE (SANsymphony) • Attend ASR training (1 day) Prerequisites • SANsymphony nodes at each end • Inter-site IP connections
- 19. 19© 2009 DataCore Software Corp. — All rights reserved Key Features of DataCore’sKey Features of DataCore’s Advanced Site Recovery solutionAdvanced Site Recovery solution Fast • Keeps DR site up to date Automated Eliminates error prone, manual steps Universal • Works equally well for virtual & physical servers or different applications Distributed • Accounts for multiple sites / branch locations Bi-directional • Resume operation at original location Verifiable • Easy to regularly test / confirm recovery
- 20. 20© 2009 DataCore Software Corp. — All rights reserved Questions ?????
Notas del editor
- Many organizations with large central IT facilities rely on regional branch offices to better serve their customers. These branches have modest computing power and network connections.
- However, most of the thinking around Disaster Recovery attempts to offload the central IT workload to one large site. This choice drives the need to beef up the contingency location so that it can adequately cover for central site outages. Such design philosophy is driven by constraints of the devices, particularly high-end storage systems, used to replicate data between the sites. Basically, organizations must replicate not only data, but the physical storage systems at both ends to make this work. Server virtualization places no such requirements on the processing engines.
- The Advanced Site Recovery component of DataCore’s comprehensive business continuity portfolio allows central IT organizations to cost-effectively spread disaster recovery (DR) responsibilities among several smaller sites, allowing each of them to accept a more manageable role in keeping the business going.
- Spread DR responsibility across multiple sites (e.g., branch offices) Choose contingency sites best suited to handle additional load during DR Example DR site x: Mail Server & Database Server DR site y: Business Apps 1-3 DR site z: Business Apps 4 -7
- A production VVol (VMFS-DS1) that is accessed from the ESX server farm in the production site (site A) is replicated thru a WAN link to a helper VVol (L1) the DR site (site B). The helper VVol L1 gathers all the replicated data changes. Once an hour the latest state is moved to the production VVol peer (VMFS-DS1) on the DR site via periodic snapshot update. All data changes are replicated back to the production site to another helper VVol (L2). The helper VVol L2 gathers all data changes made on DR site for later failback to the primary site. In case of a failover to DR site is needed the production VVol replica on DR site will be promoted (mapping to spare ESX server activated) and VMs can be re-started in the DR site. Buffers on production and DR site ensure that data is stored as long as sites and/or link in between aren't available. In case of later failback to primary site a pre-defined snapshot is being executed that moves all the data changes, which occurred during operation in DR site, back to the production VVol and VMs can be re-started in their original location.
- To restore the primary site, a pre-defined snapshot is being executed that moves all the data changes, which occurred during operation in DR site, back to the production VVol and VMs can be re-started in their original location.
- Questions ???????