Presentation on theme: "Disaster Recovery with VMware Infrastructure"— Presentation transcript:
1Disaster Recovery with VMware Infrastructure VMware Infrastructure for Rapid, Reliable, and Cost-Effective Disaster Recovery
2Agenda Challenges of Traditional DR Properties of Virtualization for DRUsing VMware Virtualization in DRSRM Technical OverviewAs you know DR is a part of business continuity planning, which is a broad topic. In this presentation, we will not be able to cover all aspects of business continuity but will be focusing specifically on providing an overview of what VMware technology brings to disaster recovery solutions. Specifically, we’ll be discussing the following: (read slide bullets)…..
3What We Hear…Is This Familiar? “ We don’t have a DR plan for mission critical x86 systems – it would be too expensive and complex”Only 31% of CIO’s surveyed rate their plans as extremely or very effective (IDG)“ It is very difficult to test our DR plan because of all the extra hardware, configuration and special processes”[Note: slide is animated with clicks. Left side BOX comments are what customers are expressing as their pain. Right side BOX comments are analyst opinion based on studies.]This is a sampling of customer comments and survey results that are very telling about the state of DR. If it is an expensive mainframe based application or a high-end Unix based application you have those mostly covered.FIGURE - The above figure highlights that x86 servers are proliferating across data centers and many mission critical applications are now running on x86 platforms. This trend (running mission critical on x86) will continue to increase and with Service Oriented Architectures (SOA) it will mean x86 will require the same level of protection reserved for high-end applications (unix, mainframe). This is a challenging situation and a better lower cost approach to DR needs to evolve.VMware software radically changes the dynamics of DR.40% of all companies that experience a major disaster will go out of business if they cannot gain access to their data within 24 hours (Gartner)“ In our last disaster recovery test we missed our recovery objectives by days”
4Lack of a reliable disaster recovery plan DR Pain PointsLack of a reliable disaster recovery plan27-30% of business have no disaster recovery plan (VMworld, Imation)Inability to meet RTO and RPO requirements with current planBusiness needs and/or regulatory needsNeed to improve RTO from days to minutes or hoursNeed to improve RPO from 24 hours to 1 hour or lessIdle hardware at recovery siteUnable to instantly repurpose machines at the secondary siteManagement effort required to maintain recovery siteNeed to maintain system and application images at secondary siteUsually only data is regularly and cleanly updated
5Expensive and Complex Challenges of Traditional DR: Infrastructure DR Challenges TodayProdDRApplicationBound to HW5-10% utilizedApplicationOSOSWANx86x86OS filesOS fileslocalstoragelocalstorageStorageStorageExpensive and ComplexMultiple slow processes to transfer data to DR site for OS, application installation, configuration, data filesRequires 1:1 duplication of servers and infrastructure at DR siteMakes x86 physical DR strategies complex and expensiveIn traditional physical world paradigm, OS Bound to Hardware Configuration, App Bound to OSNote: 2 Bullets near the production site are about the constraints in the physical world. In the physical world the OS gets tied to the hardware; apps get tied to the OSThe identical DR site requirements between can be very restrictive…you’ll need the same server model, same hardware configuration, same firmware, same storage configuration, etc because of the dependencies (restrictive!) between hardware and software mentioned earlier.Also I’d like to briefly mention that the servers on the DR site are often unused (idle) but still take up all the resources – power, network, storage, spaceDefinitely not a good way to spend valuable resources.
6Slow and Unreliable Process Challenges of Traditional DR: RecoveryDR Challenges TodayProdDR“Boot & Pray”cd, tape or ghost imageApplicationWANApplicationOSOSx86x86OS filesOS fileslocalstoragelocalstorageStorageStorageSlow and Unreliable ProcessComplex to physically recover OS, applications & dataSeparate processes for system and application dataOS & applications have dependencies on hardware configurationTier 2 & 3 applications left unprotected, adding to Tier 1 RTO riskSo let’s take the physical-physical discussion one step further ---For your OS and application binary files -- you’ll typically use CD, tape or images such as Ghost imagesFor your application data – you’ll probably use replication technology (SAN-SAN, server-to-server based replication) or backup software.SAN-based replication can provide high-performance replication but at a cost of expensive $$$ SAN array licensesGiven all this complexity, expense and uncertainty – it’s no wonder than quite often DR is provided only for a few select Tier-1 applications while other important Tier-2,3 apps are left without full protection. However, the Tier-1 applications may be dependent on those Tier-2,3 servers. This approach certainly exposes your business critical IT to significant downtime risk.Identical and specific hardware is constraining your choices and impacting your budget decisionsToo much dependency on hardware configurationsRecovery requires complex and lengthy setup process (ghost, tape based, bare metal recovery on DR site) and separate hardware. If using tape: tape recovery can be really long and errors happen often. Finding tape can also be a nightmare if cataloging is not up to date.DR site is idle or under-utilized because it is reserved for a failover (disaster) and running other applications would require comprehensive and long set-up processAt VMware we believe there is a better way for IT – that leads to Reliable, Rapid and Cost-Effective Disaster Recovery
7Agenda Challenges of Traditional DR Properties of Virtualization for DRUsing VMware Virtualization in DRSRM Technical OverviewNow we will look to the virtualization benefits that make it a key enabler for better DR
8DR : The Killer App for Virtualization! Press“Best DisasterRecoveryProductof 2006”(TechTarget)Customers55% of customers using virtualization for BC/DR*55%So VMware is just about server consolidation, right? Let me share some findings…here are some recent findings and opinions that our customers (VMware Customers) and the press have to say about VMware and disaster recovery.Right Box (CUSTOMER) – 55% of the 2265 customers we recently surveyed across US and Canada – are actually using VMware for BC-DR!!!Left Box (PRESS – Tech Target) – Here is a award we received from a a leading technology media company (Tech Target) –we were voted by their panel as the # 1 Disaster Recovery product for 2006! (side note: we do not even have a fully packaged DR solution or a SKU but Tech Target’s readership voted it the GOLD award winner!)BOTTOM BOX (CUSTOMER)– read box …VMware is being used for critical applications that need DR protection: 85% of VMware customers (from a blind sample of 2265 VMware customers) assert that they are using VMware in production environments – what’s even more telling is that 43% use it as a default in their production environments2006 Customer Survey (n=2265)…85% use VMware in production; 43% set as a default policy for production servers**Source: VMware customer survey, 9/ N=2265
9What is Server Virtualization VMware server virtualization packages hardware, OS, and applications into a portable virtual machine packageBefore VirtualizationAfter VirtualizationBefore we move ahead let’s take a few minutes to review the basics of virtualization. By way of comparison, let’s think about the typical x86 (Intel or AMD processor) server as shown on the left. Each server has a hardware configuration, an operating system installed on the hardware, and applications installed in the operating system. Each layer of this architecture is pretty tightly tied to the layer below and ultimately to the hardware—the OS is customized to the hardware in the drivers it uses, the way you tune its parameters, etc. Applications are in turn tied to the OS that they’re installed on.What are the implications? One, you have only one OS and pretty much one workload per physical machine. It’s very difficult to put more than one major application on these servers because you risk running into conflicts and performance problems if you do. The result: utilization is very low—you’re paying for computing power that’s going to waste. On top of that, this architecture is pretty inflexible. How long would it take to repurpose an idle server for something else? Well, you’d need to archive the current OS and application, reinstall the OS, install the application, and so on.Virtualization changes all of that. It takes a physical system along with the operating system and anything installed in the operating system and packages them into what we call a “virtual machine”. A virtual machine contains a virtual hardware configuration as well as the operating system, applications, and data. To the OS and applications in a virtual machine, it’s no different than running on real physical hardware.Each virtual machine runs on top of this thin virtualization layer that VMware software places on a server. This virtualization layer takes care of transparently allocating physical resources to each virtual machine.Software tied to hardwareSingle OS image per machineOne application workload per OSMultiple workloads per machineSoftware independent of hardwareSystem, data, apps are files
14Challenges of Traditional DR Properties of Virtualization for DR AgendaChallenges of Traditional DRProperties of Virtualization for DRUsing VMware Virtualization in DRData and system protectionReplicationDR testingProtecting physical servers with virtual machinesSRM Technical OverviewThis section coming up will now highlight and talk about various architectures for backup and recovery, replication, DR testing and also show you how VMware can protect your physical server environment from failures.We will also show you how easy it is to test DR.
15VMware Availability Products And Features Avoid planned outagesQuick recovery from unplanned outagesComponentServerStorageDataN/ASiteNIC Teaming, MultipathingVMotion, DRS + Maintenance ModeVMware HAStorage VMotionEncapsulation, VCBEncapsulation, VCBEncapsulation, boot from shared storage, instant reprovisioning, HW independence, resource pools, snapshots, VLANsVMware Site Recovery Manager
16Data and System Protection – Physical vs. Virtual Data and system protection withphysical infrastructureSeparate processes for protecting data and system disksRequire identical hardware for guaranteed restoreComplex processes to ensure protectionSystemSystem configurationDataData and system protection withVMware InfrastructureSame process for data and system disksEntire system stored as dataHardware-independent virtual machines are easy to restore to any hardwareBefore we move into details let’s spend a minute talking about how virtualization impacts the backup and recovery process; backup and recovery will be a part of the DR plan for many environments using virtual machinesIn a physical environment some of the challenges of backup and recovery include:You typically use separate processes to protect your OS (system) disks and your application data disks because they typically reside on different storage; this adds complexity and time to your overall backup processTo guarantee successful restore, you would need to have identical hardware due to hardware dependencies.The entire process is extremely complex—you need to spend time rebuilding the OS, validating that your application works after recovery, etc.Virtualization can eliminate many of those challenges:Because VMware virtualization encapsulates both system and data disks as files, it’s easier to use the same process to backup and restore both system and data disks; because it makes it easy to put both system and data disks on shared storage, it’s also easier to use the same process to protect bothBecause of encapsulation, the entire system is stored as data, making it possible to restore not only data but also entire systems just by restoring a few filesBecause of the hardware independence of virtual machines, you can be certain that you’ll be able to successfully boot and use a system that’s been backed up—no more failures due to driver or other hardware dependenciesSystem, data, system config
17Backup Options with VMware – Reduce Backup Windows Backup AgentServiceConsoleBackup AgentServiceConsoleAppOSAppOSOSBackup AgenttapeBackup ServerIn-VMIn-ConsoleVCBAgent in each VMSame architecture as physical system backupFile-level incremental backup possibleAny storageAgent in Service ConsoleSimplified backup of full-disk imagesAny storageConsolidated Backup - Agent on Proxy ServerMove backup out of VMProvide LAN-free backupEliminate backup windowsPre-integrated with 3rd party backup productsThere are three ways that our customers commonly do backup and recovery in virtualized environments. These are:In-VM, Put backup agent in virtual machine: same configuration and procedure as with physical machinesProvides file-level backup and restoreIn-Console Backup from service console: backs up entire virtual machine by backing up the small number of files that encapsulate itSimpler, doesn’t load individual VM’s, but less granular restore since you can only restore full disk images, not individual files within virtual machinesMany customers use in-VM and in-Service Console backup as complementary options—in-VM for file-level backup of data and in-Service Console for image-level backup of system disksVMware Consolidated Backup (Next Page we will show how it works)Consolidated Backup, available in VI3, provides another option that has significant benefits.Key Points: What is it?Centralized agent-less backup for virtual machinesPre-integrated with major 3rd-party backup productsVCB does not do backups itself, but is rather an enabler that makes it easier to do backups using standard 3rd-party backup toolsCustomer ImpactReduce the load on ESX Server, thereby allowing it to run more efficiently and to run more virtual machines.Perform backups at any time, even in the middle of the dayImprove manageability of IT resources by using a single agent running on the proxy server rather than an agent on every virtual machine.Eliminate backup traffic on the local area network
19Replication with VMware: Array-Based Replication DR SITEPRIMARYSiteFailureWAN orDark FiberStorage arrayStorage arrayArray-Based Replication[Note to presenter : slide is automatically animated to illustrate key concepts.]For demanding performance requirements and lowest RTO/RPO, consider off-host replication via array-based or storage network-based replication. We will be discussing array based replication technology here – where the replication load is now being handled by the storage processors within the storage arrays on the primary and DR sites (connected by dark-fiber or a WAN)Array-based replication allows you to easily replicate entire virtual machines simply by replicating the storage disks on which they reside—virtual machines are just like any other files residing on a diskMost major array vendors (including EMC, NetApp, IBM, HP, Hitachi, Equallogic, LeftHand, etc.) provide some form of array-based replication for use with their arrays.TargetVMFSSourceVMFS
20Simpler Disaster Recovery Testing with Virtualization DR SiteSnapshot and clone replicated data to create testing VM’sConnect test VM’s to an isolated networkPower up testing VM’s to validate recoveryDelete VM clones used for testing15 GHz9 GHzPowered On DR VMsTestDRLiveDRReplicatedDataSANSnapshotVirtualization helps to make disaster recovery testing significantly easier than it is in a physical environment. In a physical environment you usually need to spend a lot of time and effort allocating additional hardware for testing, setting and configuring that hardware, and making sure that the testing environment won’t impact the actual recovery hardware. Once the test is completed you need to spend time cleaning up after the test.With VMware Infrastructure you can perform DR tests without requiring additional hardware for testing, without needing additional hardware and with significantly less time and effort needed to set up and configure the DR test.For testing, a snapshot of the replicated data is taken and then cloned to create a new virtual machineVirtual switches and VLAN’s can be used to create an isolated testing network that doesn’t interfere with other networks at the DR siteYou can now power up the testing VM’s and start validating your DR planOnce testing is over, to clean up you merely need to delete the VM clones and you’re ready for the next test.Target VMFS- Rapid DR setup and removal- Dual-use of DR site for batch, test and other workloadsOS.imageAppln.imageData.imageOSApplicationData.
21Recovery Process in a Virtualized Environment Example recovery process comparison40+hrsP-PConfigure hardwareInstall OSConfigure OSInstall backup agentStart “Single-step automatic recovery”RestoreVMPoweron VMV-V< 4+hrsComparing an example of the steps necessary to recover from a disaster in the physical to physical recovery scenario versus the physical to virtual scenario illustrates the dramatic difference that virtual infrastructure makes in simplifying and shortening the recovery process. With a physical recovery target, time to recovery is much longer—40+ hours in one customer example.In the same customer example, time to recovery using a virtual target has been reduced to 3+ hours and several fewer steps. Since the hardware is now virtualized, we no longer need to spend time verifying that we have the proper hardware configuration (or potentially even locating adequate hardware) for recovery—any hardware is a potential recovery target.RTO of minutes to a few hours, not days to weeks!
22VMware Site Recovery Manager: Technical Overview July 2008VMware
23Agenda Introduction and Key Concepts Site Recovery Manager 1.0 Prerequisites and SAN IntegrationSite Recovery Manager WorkflowsSite Recovery Manager Roles and PrivilegesAlarms and Site Status MonitoringSummaryAgenda for the presentation today.1. DR and SRM Introduction and Concepts2. SRM 1.0 Prerequisites and SAN Integration3. SRM Workflows (Protected and Recovery Site)4. SRM Roles and Privileges5. SRM Alarms and Site Status Monitoring6. SRM Core benefits and Summary
24What is a Disaster?Complete loss of a data center for an extended period of timeDeclaration of a disaster usually requires consensus from multiple parts of the organization (at the C*O level)What is not a disaster?Failure of an individual hostA temporary service interruptionThis is what we mean when we talk about disasters.There is of course a gray area—does failure of a storage array constitute a disaster? How long is “an extended period?”Can disaster recovery tools assist with planned outages?
25The Current State of Physical Disaster Recovery TierRPORTOCostIImmediate$$$II24+ hrs.48+ hrs.$$III7+ days5+ days$DR services tiered according to business needsPhysical DR is challengingMaintain identical hardware at both locationsApply upgrades and patches in parallelLittle automationError-prone and difficult to testIn our discussions with customers like you, we found that disaster protection for services tends to be tiered.In the first tier are services for which no downtime at all can be tolerated; those services tend to be deployed from the start in active-active configurations.For those sites that maintain identical idle hardware at the secondary site, just keeping up with OS patches can be a full-time job.For the remaining services, however, DR plans are in the three-ring binder (“read this in case of disaster”): To recover this server, confiscate that hardware, re-install the OS, recover from tape.Of course, these steps are very manual, and tend to be very difficult to test.
26Advantages of Virtual Disaster Recovery Virtual machines are portableVirtual hardware can be automatically configuredTest and failover can be automated (minimizes human error)The need for idle hardware is reducedCosts are lowered, and the quality of service is raisedPress In Caseof DisasterThere are a lot of the advantages of virtual machines that make them ideal vehicles for BC/DRVirtual machines can be transmitted over a wire (portable)Virtual machines can be programmatically powered on and off, and virtual networks can be programmatically reconfigured (automatically configured)By including the boot disk, virtual DR eliminates the need to apply OS patches in parallel at the primary and secondary sites (minimizes human error)Lower cost makes it possible to make high-quality DR protection ubiquitous, not just for the first tier of service
27Introducing VMware Site Recovery Manager Site Recovery Manager leverages VMware Infrastructure to deliver advanced disaster recovery management and automationSimplifies and automates disaster recovery workflows:Setup, testing, failoverTurns manual recovery runbooks into automated recovery plansProvides central management of recovery plans from VirtualCenterVMware is building on the core properties of VMware Infrastructure that make it so useful for disaster recovery with a new product—VMware Site Recovery ManagerSite Recovery Manager is a product that simplifies and automates disaster recoverySite Recovery Manager helps organizations to directly address the challenges of disaster recovery that were mentioned earlier: meeting RTO requirements, reducing cost, and reducing riskSite Recovery Manager is a separate product from VMware InfrastructureVMware has been working to leverage the disaster recovery features and capabilities of the VMware Infrastructure platform with a new product developed specifically for disaster recovery. This new product will simplify and automate the key elements of disaster recovery: setting up disaster recovery plans, testing those plans, executing failover when a datacenter disaster occurs, and failing back to the primary datacenterThis new product, VMware Site Recovery Manager, will make it possible for customers to provide faster, more reliable, and more affordable disaster recovery protection than previously possible. Although not a part of VMware Infrastructure, Site Recovery Manager works closely with VMware Infrastructure to manage and automate disaster recovery for virtual environmentsWorks with VMware Infrastructure to make disaster recovery rapid, reliable, manageable, affordable
28Site Recovery Manager at a Glance Site ASite BXProtected SiteRecovery SiteProtected SiteRecovery SiteSupports bi-directional site protectionVirtualCenterSite Recovery ManagerVirtualCenterSite Recovery ManagerProtected VMsofflinepowered onProtected VMsonline in Protected Sitebecome unavailableNOTE: This slide has animation to simulate at a high level what SRM doesHigh-level view of SRMSRM protects the VMs you select at the protected site, SRM starts up protected VMs at time of test or disaster in the recovery siteClick 1: SRM Protects VMs on ESX Prod1, shadow VMs created in the Recovery Site on ESX DR1Click 2: SRM Protects VMs on ESX Prod2, shadow VMs created in the Recovery Site on ESX DR2Click 3 : Disaster occursClick 4 : Business declares disaster. Initiate Recovery via SRM .Press the big red button and your protected VMs are restarted at the secondary siteArray ReplicationDatastore GroupsDatastore Groups
29Server Side Components * Site 1Site 2VC Server 2VC Server 1VCMS 2 DBVCMS 1 DBSRM Server 2SRM Server 1SRM 2 DBSRM 1 DBStorageReplicationAdapterStorageReplicationAdapterArray 2Array 1Block Replication SWNOTE: This slide has animationSRM is designed as a plug-in to VirtualCenter so that DR tasks can be executed inside the same management tool as other VM administration tasks such as creation, migration, deletion, etc…However, SRM is not “in” VC. It is a separate server process with its own separate database. The server processes for SRM and VC can be run on the same or different servers and the databases for VC and SRM can reside on the same or different database serversThe most interesting piece of the install is the storage replication adapters. As you know, SRM does not actually do the replication for DR, only the setup, test, and recovery workflows. SRM relies on block based replication (fiber or iSCSI) from our storage partners for replication. The storage replication adapters tie together the SRM product and the replication products. These adapters are developed, qualified, and supported by the storage partner for the optimal reliability and the best customer experience. They sit on the SRM server and once installed are invisible for the duration of their useTo Summarize2 VC servers (one per site)2 SRM servers (one per site)4 databases (two per site, one for VC and one for SRM)Pre-configured array based replicationBlock Replication SW* Note: Conceptual drawing only. Site Recovery Manager Server may run on another system than VCMS
30Site Recovery Manager Concept Relationship “Cheat Sheet” ProtectedLUNIndivisible unit of storage that can be replicatedDatastoreContains one or more LUNs (i.e. VMFS)Datastore GroupsAuto-generated collection of one or more datastores. Indivisible unit or storage failover.Protection GroupCollection of all VMs stored in a datastore groupRecoveryRecovery PlanContains one or more protection groupsThere are five “moving parts” that must be understood for SRM to be used. The first four relate to the protection tasks and the last relates to the recovery tasksLUNs are block devices presented from the storage arrays. LUNs are the unit of replication for the arrays and represent the smallest possible granularity for failover. It is never possible to failover the contents of part of a LUN without failing over the entire LUN – so group VMs on LUNs accordinglyVMware formats LUNs with VMFS, our filesystem and uses to store VMs. These VMFS formatted LUNs are referred to as datastores. Datastores commonly contain only a single LUN, but do have the ability to span LUNsDatastore groups are the smallest groups of datastores (and therefore LUNs) that can have their contents failed over with SRM. These groupings are calculated for you so you don’t have to worry about figuring them out. What causes LUNs and datastores to be grouped together and not distinctly managed are two things:A datastore spanning multiple LUNs causes those LUNs to be grouped together in the datastore group. Failing over part of a datastore is not possibleA VM can have multiple virtual disks and those virtual disks may sit on different datastores. In that case, those datastores are forced together into a datastore group so that you don’t try to failover only part of a VMProtection groups are created with a one to one mapping to datastore groups. Protection groups are simply the group of VMs that reside on a single datastore group. This is the actual unit of VM protection and recoveryRecovery plans. Once you have created protection groups, you can create recovery plans containing one or more of them. A recovery plan is simply a list of VMs from the protection groups, a startup order for those VMs, and any custom steps added before or after VM startup. This is the “virtual run book” that is executed during DR tests and actual DR failovers
31Key Concepts And Their Relationships Datastore Group 1Recovery Plan 1 (Whole Site)Protection Groups:LUN 1VMFS 1Protection Group 1Protection Group 1Datastore Group 2LUN 2Protection Group 2Protection Group 2VMFS 2Protection Group 3LUN 3Recovery Plan 2 (Subset)Protection Groups:Datastore Group 3LUN 4VMFS 3Protection Group 3NOTE: This slide has animationHere is a graphical representation of what was just describedLUN1 is formatted with VMFS1 and has 3 VMs. It has no dependencies on anything and is in its own datastore groupLUNs 2 and 3 has VMFS2 spanned across them so are in the same datastore. Since all 6 VMs on that datastore sit only on VMFS2 touching no others, VMFS2 (and therefore LUNs 2 and 3) is alone in the second datastore groupLUN4 is formatted with VMFS3 and LUN5 is formatted with VMFS4. They would be in separate datastore groups were it not for the VM with a virtual disk in each of them. VMFS3 and VMFS 4 (and therefore LUNs 4 and 5) are grouped together in a third datastore groupProtection groups 1, 2, and 3 are created corresponding to datastore groups 1, 2, and 3At the recovery site for all these VMs, recovery plan 1 is created containing all three protection groups and therefore all 10 of its VMs. This recovery plan would be used if the entire site was lostRecovery plan 2 is also created with only protection group 1 and its 3 VMs. This is for some partial failure – perhaps corresponding to a server rack, an array or a business unit. It would be run to recover that particular set of systemsLUN 5VMFS 4Protection Group 1Protected SiteRecovery Site
32Array Integration with Site Recovery Manager Vendor-specific scripts support:Array discoveryReplicated LUN discoveryTest initiation (simulated failover in an isolated environment)Failover initiation (actual failover of services to the recovery site)In cooperation with VMware and with the full support of VMware the storage vendors create the storage replication adapters for their respective storage arraysNOTE: This slide has animationSRM will leverage Storage Replication Adapters (SRAs) that have been written by the storage vendors to ensure tight integration with SRM.Note: In cooperation with VMware and with the full support of VMware the storage vendors create the SRAs for their respective storage arraysThe SRAs will perform the following tasks:Array discoveryReplicated LUN discoveryTest & Failover initiation
33VMware Site Recovery Manager Licensing Protected SiteRecovery SiteVirtualCenterSite Recovery ManagerVirtualCenterSite Recovery ManagerSRM Protected VMsNOTE: This slide has animation to illustrate how SRM licensing is associated with ESX servers that host protected virtual machinesHigh-level overview of SRM LicensingSite 1 and Site 2 will have two category of virtual machines (unprotected VMs and protected VMs)Click 1: Virtual Machines that are not protected by SRM (unprotected VMs)Click 2: Virtual Machines that will be protected by SRM (protected VMs) that can be restarted in Site 2 (recovery site)Click 3: SRM licensed per CPU socket on the ESX server that hosts the protected virtual machinesSRM License file will be applied to the licensing server in the protected site.Note: If SRM is going to be used to apply cross site protection (Site 1 to Site 2 and Site 2 to Site1), SRM licenses will be required for the ESX servers in Site 2 that are hosting the designated protected virtual machines that could be failed over to Site1 at time of disaster or scheduled BC/DR test.SRM can be purchased as individual component (per CPU socket on the ESX server that hosts the protected VMs) or as part of a management & automation bundle comprised of SRM plus the IT Service Delivery bundle (Lifecycle Manager, Stage Manager and Lab Manager).SRM licensed per CPU socket on the ESX server that hosts the protected virtual machines in the Protected SiteVMs not protected by Site Recovery Manager
34Safety Tip: DNS Validation – The Rule of ‘Four’ Validate DNS is working as expected by performing the following DNS lookups for the VC,SRM and ESX serversShort nameLong nameReverseForwardNOTE: This slide has animationIt is highly recommended to validate DNS is working as expected and that DNS lookups in the protected and recovery site return the correct resultsDNS should be validated from:the VC serverthe SRM servereach of the ESX serverNOTE: Complete the DNS checks from the protected and the recovery sites
35Site Recovery Manager 1.0 Prerequisites ESX 3.0.2, ESX 3.5VirtualCenter (VC) server version 2.5 installed at the protected site and at the recovery siteSite Recovery Manager server installed at the protected and at the recovery siteSite Recovery Manager plug-in installed on the VMware Infrastructure Clients that will access the protected and recovery siteNetwork configuration that allows TCP connectivity between VC servers and SRM serversAn Oracle or SQL Server database that uses ODBC for connectivity in the protected site and in the recovery siteA Site Recovery Manager license file installed on the VC license server at the protected site and at the recovery sitePre-configured array-based replication between the protected site and the recovery siteNOTE: This slide has animationSRM prerequisites (make mention of the below)Point out the need for a separate VC servers in the protected and recovery site, with separate databasesPoint out the need for a separate SRM servers in the protected and recovery site, with separate databasesPre-configured array based replication between the protected and recovery site2 VC servers (one per site)2 SRM servers (one per site)4 databases (two per site, one for VC and one for SRM)Supported Databases for SRM 1.01. SQL Server 2005 Enterprise/Standard/Express - SQL Native Client. (Note: If SQL Server is installed locally, you may need to disable "Shared Memory" network setting on DB server.)2. Oracle 9i - Oracle driver version x.x (Note: manually disable Bulk Insert in config file)3. Oracle 10gR1, 10gR2 - Oracle driver version x.x
36Site Recovery Manager Installation Workflow At the protected site the following activities are completed:Installation of the SRM serverInstallation of the SRM Plugin into the VI ClientInstallation of the Storage Replication Adapter (SRA)At the recovery site the following activities are completed:Installation of the SRM Plugin into the VI Client *It is important to complete the workflows in the order detailed in this presentationNOTE: This slide has animationSRM installation workflows involves the installation of the SRM server which can be completed at the protected site and then recovery site, or vice versaOnce the Installation Workflow has been completed, it is very important to complete the remaining SRM configuration workflows in the order that is detailed in the presentation* Note: Optional step, only required if a different instance of the VI Client is used to access the recovery site
37Protected and Recovery Site Datacenters PROTECTED SITENOTE: This slide has animation.Before moving into the SRM Configuration workflows lets review the two datacenters that are depicted to help frame the rest of the presentationProduction Datacenter we wish to protect – vim22dc (Protected Site) and VMs (app_vm1 to app_vm12)BC/DR Datacenter we will failover to – vim23dc (Recovery Site)RECOVERY SITE
38Site Recovery Manager User Interface SRM UI AccessLocal and Paired SiteProtection SetupNOTE: This slide has animationSRM is accessed via the VI Client. An SRM Plugin is installed onto your VI Client resulting in the Site Recovery Icon highlighted in the slideWith the exception of the Recovery Plans all SRM setup workflow will be completed from the VI Client that is connected into the protected site (Connection, Array Managers, Inventory Preferences and Protection Groups)The Recovery Plan for the VMs in the protected site is created from the VI client that is connected into the recovery siteRecoverySetup
39Setup Workflow – Protection Site At the protection site the following setup activities are completed:The user pairs the SRM servers at the protected and recovery sitesSecurity certificates are established between the SRM servers and the VC serversNOTE: This slide has animationStep 1: Pairing of the recovery site (vim23) to the protected site (vim22) which involvesConnecting the VC server in the protected site to the VC server in the recovery sitesCertificate validation between the VC servers in the protected and recovery sitesConnecting the SRM server in the protected site to the SRM server in the recovery sitesCertificate validation between the SRM servers in the protected and recovery sitesReciprocity is establishedPKCS12, Personal Information Exchange Syntax Standard, certificates can be used for things such as signing and file signing. They are different from other certificates in that rather than being only the public or private certificate, they are a combination of both plus the root certificate. This means the person they are made for only has to worry with one file.Certificates that are not properly signed will result in the Yellow Warnings Signs.Reciprocity will still be established allowing you to continue to the next step in the workflow.
40Setup Workflow – Protection Site (continued) Array Managers ConfigurationSelect the correct Manager Type from the Manager type drop down boxStorage Partner ParticipationVMware provides the SRA specificationStorage Partners create the SRAStorage Partners test the SRAVMware review the SRA test resultsSRA support with SRM granted if all test are passedStep 2: After the pairing of the site is completed via the SRM Connection wizard the next step is to configure the array managersDuring the installation workflow you installed an SRA for the Array you will be using for the replication of the datastores (datastore groups) between Site1 and Site 2During the Add Array Manager configuration workflow, you will be presented with a window similar to this, you need to select the correct manager type to enable SRM to integrate with the SAN that is replicating the datastores (datastore groups) between Site1 and Site 2
41Setup Workflow – Protection Site (continued) SRM identifies available arrays in the Protection and Recovery Side and the replicated datastores and determines the datastore groupsProtection Side Array DiscoveryRecovery Side Array DiscoveryStep 2 continued: SRM will identify which LUNS are being replicated, and present you with the listThe Array Manager wizard involves the follow steps:Protection Site array setup, pairing the array in the protected site to the array in the recovery siteRecovery Site array setupReview the mirrored LUNsReplicated DatastoresandDatastore Groups
42Setup Workflow – Protection Site (continued) Using the Inventory Preferences Mapper, the user maps resources in the protected site to their counterparts in the recovery site.Step 3: After the Array Mangers setup is completed via the SRM Array Managers wizard the next step is to configure the Inventory Preferences via the SRM Inventory Mapper wizardUsing the Inventory Mapper wizard, the protected VMs now need to be mapped to theNetworksCompute ResourcesVirtual Machine Foldersthat are available at the recovery siteNote: These are global preferences that will be applied to all the protected VMs when they are restarted at the recovery site. In addition to the global preferences individual per VMs customization can also be applied to the protected VMs, for example network configuration information (IP, Mask, Gateway, DNS and WINS servers) to allow the protected VMs to start up correctly on the network at the recovery site
43Setup Workflow – Protection Site (continued) A protection group is a group of VMs that will be failed over together to the recovery siteWorking through the Protection Group wizard you will need to select a temporary location for placeholder VM configuration files for the protected VMs at the recovery site.Step 4: After the Inventory Preferences setup is completed the next step is to configure Protection Groups via the SRM Inventory Mapper wizardDuring the creation of the Protection Groups, SRM requires a location to store some temporary VirtualCenter inventory files for the protected VMs. SRM will present the available datastores at the recovery site that could be selected for the storing of these temporary files. It is preferable and suggested that you select a non replicated datastore for these temporary files at the recovery site
44Setup Workflow – Protection Site (continued) Working through the Protection Group wizard a user selects which VMs need to be protected and assigns them to a protection groupThe creation of a protection group results in VC inventory updates in the recovery siteNOTE: This slide has animationStep 4 continued: After the Inventory Preferences setup is completed the next step is to configure Protection Groups via the SRM Inventory Mapper wizardA Protection group has a 1:1 Mapping to a DataStore Group in SRMA Protection Group contains the virtual machines you wish to protect in Site 1 (protected site) and allow for them to failed over to Site 2 (recovery site)This screen provides a summary of protected virtual machines (app_vm1 to app_vm12) and also shows which folders and resource RPs they will be mapped to in the recovery siteClick 1: Show the shadow VM Meta data being written to the temporary storage location that was selected when working through the protection group wizardClick 2: Show the automatic update of the VC Inventory in the Recovery Site as a result of the protection group being created
45Setup Workflow – Recovery Site At the recovery site the following setup activity is completed:The user creates a recovery plan which is associated to a single or multiple protection groupsStep 5: Working through the Recovery Plan wizard the user completes the setup of a recovery plan that is associated with a single protection group or multiple protection groupsRecovery Plan is a preprogrammed BC/DR run book that will ensure your tests and failovers are executed in a repeatable and reliable manner
46Site Recovery Manager Recovery Plan VM ShutdownHigh PriorityVM ShutdownPrepare StorageHigh PriorityVM RecoveryNOTE: This slide has animationStep 5: Working through the Recovery Plan wizard the user completes the setup of a recovery plan that is associated with a single protection group or multiple protection groupsSRM recovery plan called ‘Recovery Plan 2 – Protection Group 2’ required to complete a partial site failover for the local data center vim22dc which is protected by SRMThe protected VMs that will be failed over are app_vm7 through to app_vm12 from Protection Group 2 which is associated to the datastore group shared-san-2Low and Normal VM shut downHigh Priority VM shutdownDatastore group preparation at the Recovery SiteRecovery of VMsNormal PriorityVM Recovery
47Site Recovery Manager Recovery Plan (continued) Low PriorityVM RecoveryPost Test CleanupStorage ResetSite Recovery Manager Recovery Plan Benefits:Turn manual BC/DR run books into an automated processSpecify the steps of the recovery process in VirtualCenterProvide a way to test your BC/DR plan in an isolated environment at the recovery site without impacting the protected VMs in the protected siteNOTE: This slide has animationSRM recovery plan called ‘Recovery Plan 2 – Protection Group 2’ required to complete a partial site failover for the local data center vim22dc which is protected by SRM. The protected VMs that will be failed over are app_vm7 through to app_vm12 from Protection Group 2 which is associated to the datastore group shared-san-2
48Testing a Recovery Plan SRM enables you to ‘Test’ a recovery plan by simulating a failover with zero downtime to the protected VMs in the protected siteSRM enables you to ‘Test’ a recovery plan by simulating a failover of virtual machines from the protected site to the recovery site. The benefit of using SRM to run a failover simulation against a recovery plan is that it allows you to confirm that the recovery plan has been setup correctly for the protected VMs. You will be able to confirm that the protected VMs startup in the correct order, taking into account the various application service dependencies for the protected VMs in your environmentIt is worth pointing out that when you select the option to ‘Test’ a recovery plan via SRM, the simulated failover is executed in an isolated environment that includes network and storage infrastructure at the recovery site that is isolated from the protected site (production environment) which ensures the protected VMs at the protected site are not subject to any kind of service interruption during the testing of the recovery planSRM will also create a test report that can be used to demonstrate your level of preparedness to the business or individual business units whose services are being protected by SRM as well as to the auditors and compliance officers if requiredThe simulated failover completes by resetting the environment to be ready for the next event which could be another simulated failover, or an actual failover for a scheduled BC/DR test or in response to an event which resulted in the business declaring a disaster
49Testing a Recovery Plan (continued) Recovery OnlyStatusSuccessErrorsSuccessWaiting for InputNOTE: This slide has animationTesting of a SRM Recovery Plan can be completed without impacting the protected VMs (app_vm7 to app_vm12) at the protected siteSRM recovery plan called ‘Recovery Plan 2 – Protection Group 2’ required to complete a partial site failover for the local data center vim22dc which is protected by SRMThe protected VMs that will be failed over are app_vm7 through to app_vm12 from Protection Group 2 which is associated to the datastore group shared-san-2While the simulated failover test is running, the status of each step that makes up the recovery plan can be monitored by going to Recovery Steps tab in the VI Client which will inform you what steps are currently Running as well as what steps were completed with a Success status. It is worth pointing out that there are some steps in a recovery plan that will only be executed during a simulated test, these steps are identified by ‘Test Only’ under the Mode column, there are also some steps that will only be executed during an actual failover, these steps are identified by ‘Recovery only’ under the Mode columnOnce the simulated failover test is completes a report of the test run can be viewed from the History Tab. The report can be viewed by clicking on the ‘view’ link. The report contains a list of all the steps in the recovery plan along with a status of ‘success or error’ and the duration of each step in the recovery planTest Only
50Executing an Actual Failover WARNING - Executing an actual failover will permanently alter virtual machines and infrastructure of both the protected and recovery sitesNOTE: This slide has animationClick 1: Will take you to a storage configuration view after a SRM Recovery.SRM enables you to ‘Run’ a recovery plan which will result in the actual failover of virtual machines from the protected siteThe failover process via SRM is rapid, repeatable, reliable, manageable and auditableThere are two ways to initiate the actual failover, you can either click on the ‘Run’ button or click on the ‘Execute Recovery Plan’ link under the Commands sectionIf there is still connectivity back to the protected site at the time the disaster is declared by the business, SRM will first initiate the power down of the protected VMs at the protected site
51Executing an Actual Failover (continued) WARNING - Executing an actual failover will permanently alter virtual machines and infrastructure of both the protected and recovery sitesThe Run Recovery Plan dialog box warns you that you are about to run the a recovery plan which will result in changes to the protected virtual machines and the infrastructure of both the protected and recovery site datacenters. Click the radio button to confirm you understand the implications of running your recovery plan and then click on the Run Recovery Plan button to start the failover of protected VMs from the protected site to the recovery siteThe Run Recovery Plan dialog box also provides a summary of the Recovery Plan Information, that includes the Recovery Plan that is going to be run, along with the names of the protected and recovery sites, the number of protected VMs that will be failed over as well as a connectivity status from the recovery site back to the protected siteWhile the failover is being executed, the status of each step that makes up the recovery plan can be monitored by going to Recovery Steps tab of the recovery site’s VI Client which will inform you what steps are currently Running as well as what steps were completed with a Success statusWARNING - Failback to the protected site is a not an automated process in SRM 1.0
52SRM performs a Datastore re-signature SRM will automatically perform a re-signature on the Datastores in the Recovery Site that were replicated from the SRM Protected SiteLVM.EnableResignature=1With a re-signature - Datastore names will change to snapxxxx_datastorename, for examplesnap shared-san-1snap shared-san-2SRM VMware Topology Map after executing an actual failover from the protected site to the recovery site.Once the all the Recovery Plan steps have been executed as part of the actual failover, using the VI3 topology maps we can see the protected VMs (app_vm7 to app_vm12) are associated with an ESX host in the recovery site vim23 and serviced off a recovery site datastore.WARNING - The re-signature of the target datastore has implications during a failback (resync) of data back to the SRM Protected Site
53Failback Options with Site Recovery Manager 1.0 SRM 1.0 does not provide a push-button automated failback processFailback OptionsWithout SRM (no Recovery Plan, no Testing capabilities, no audit trail)Unregister the protected virtual machines in the Protected Site VCWork with your storage team, reverse data replicationVM re-inventory in Protected Site VC, restart and re-ip (manual or scripted)With SRM (Recovery Plan, Test before Recovery, built-in audit trail)Delete the protection groups in the Protected Site VCLeverage SRM, complete SRM workflows in the reverse direction from Recovery Site back to the Protected SiteRepeat the above steps from the Protected Site back to the Recovery Site to complete the re-protection of the virtual machines in the Protected SiteNOTE: This slide has animationSRM 1.0 does not support automated failback via the SRM UI.Should there be a need to failback data to the designated protected site (original or new) after a an actual DR event or scheduled BC/DR test there are two approaches.ManualWith SRMFailback with SRMStep Site Failback task1 Site B Protected VMs recovered to Site B are no longer being used and can be powered down2 Site B Power down the Protected VMs in Site B3 Site B Create a list of all the Protected VMs that were recovered to Site B4 Site B Perform a cleanup of the directory in Site B that contained the VM configuration files created during protection group creation in Site A5 Site A Connect to the VC instance in Site A and delete the PG 16 Site A Connect to the VC instance in Site A and perform a remove from inventory operation on all the protected VMs in Site A that were recovered to Site B7 Storage Work Work with your Storage team to complete a storage configuration change ‘personality swap’ whereby the Source LUN is now associated with Site B and the Target LUN is associated with Site A. Refer to Figure 6.5.8 Site B Complete the Array Manager configuration wizard in Site B which now has the Source LUN configured in Site B and the Target LUN configured in Site A9 Site B Configure the Inventory Preferences in Site B, these inventory preferences will be assigned to the protected VMs when they are restarted in Site A after the failback10 Site B Connect to the VC instance in Site B and configure PG 211 Site A Connect to the VC instance in Site A and configure RP 2 in Site A12 Site A Using SRM complete the Failback of the original protected VMs back to Site A. This is accomplished by performing a Recovery against RP 2. Figure depicts the storage configuration after the Recovery completes13 Site A Shutdown all of the protected VMs in Site A that were failed back from Site B during the SRM Recovery operation performed in Step 1214 Site A Perform a cleanup of the directory in Site A that contained the VM configuration files created during protection group creation in Site B15 Connect to the VC instance in Site B and delete PG 2 that was created in Site B in step 1016 Site B Connect to the VC instance in Site B and perform a remove from inventory operation on all the protected VMs in Site B that were recovered to Site A17 Storage Work Work with your Storage team to complete a second storage configuration change ‘personality swap’ whereby the Source LUN is now re-associated with Site A, the Target LUN is re-associated with Site B along with the Clone LUN as depicted in Figure 6.1118 Site A Create PG 3 in Site A for the protected VMs19 Site B Re-associate PG 3 from step 19 in Site A with RP 1 in Site B20 Site B Complete a final ‘Test’ a simulated failover against RP 1 to ensure that Site A is protected and ready for any event that may necessitate a Recovery via SRM to Site B should a disaster be declared
54Default Roles and Privileges in Site Recovery Manager NOTE: This slide has animationTo facilitate the application of specific sets of privileges which will enable you to perform a coherent set of operations, roles specific to SRM will be defined on the VC server during installation. These roles are described here.There are two sets roles. The first set contains the roles required for the primary site user to administer protection. The second set contains the roles required for the secondary site user to administer recovery. Note that the second set of roles also includes the privileges required to perform the necessary actions on the secondary site when the protection is administered from the primary site. This means that when the primary site user is required to login to the remote (secondary) site in order to complete protection configuration, she can use the account privileged to administer recovery there.The following is the list of roles and inventory objects where the roles need to be assigned:Protection Virtual Machine Administrator: This role should be assigned on the protected Virtual Machine object in the VC inventory. It grants the associated user the ability to setup and modify the protection characteristics of the protected virtual machine.Protection SRM Administrator: This role should be assigned on the Service Instance object in the primary SRM inventory. It grants the associated user the ability to pair two sites, configure inventory mappings, and SAN arrays.Protection Groups Administrator: This role should be assigned on the Primary Configuration/Protection Service object in the SRM inventory. It grants the associated user the ability to create and modify protection profiles.Recovery Inventory Administrator: This role should be assigned on the root of the VC inventory. It grants the associated user the ability to view customization specifications existing on the secondary site.Recovery Datacenter Administrator: This role should be assigned on the Datacenter object in the VC inventory where the VMs will be recovered. It grants the associated user the ability to view available datastores and perform recovery (shadow) VM customizations.Recovery Host Administrator: This role should be assigned on the Host or DRS cluster object in the VC inventory where the VM will be recovered. It grants the associated user the ability to configure VM components during recovery.Recovery Virtual Machine Administrator: This role should be assigned on the Folder and Resource Pool objects in the VC inventory where the recovery (shadow) VMs are to be placed. It grants the associated user the ability to create and add shadow VMs to the resource pool and the folder as well as the ability to reconfigure and customize the shadow VMs at runtime and during the process of recovery.Recovery SRM Administrator: This role should be assigned on the Service Instance object in the secondary SRM inventory. It grants the associated user the ability to configure SAN arrays and create protection profiles.Recovery Plans Administrator: This role should be assigned on the Secondary Configuration/Recovery Service object in the SRM inventory. It grants the associated user the ability to reconfigure protection and shadow VMs and setup and run recovery.Note that VC already defines a Read-Only system role which can be used to grant users the ability to view the Disaster Recovery service. In addition, the Administrator role can be used to grant user complete control over both the protection and recovery components.
55Alarms and Site Status Monitoring SRM will support the following alarm notification actions:Send to specified addressSend SNMP trap to VC trap receiversExecute specified command on VC hostWe recommend you complete setup of alarm notifications for:Remote Site DownRemote Site Ping FailedReplication Group RemovedRecovery Plan DestroyedLicense Server UnreachableSRM will support the configuration of event-triggered alarms so that you can associate a notification action with any given SRM Alarm Event. These alarms are configured via the SRM UI.To get familiar with SRM Alarms and how they work we recommend you enable the 5 listed here.Remote site failure is reflected in the SRM Alarm Events and will not automatically trigger a recovery. This must be initiated manually.
56Site Recovery Manager Server Monitoring SRM will raise VC events for the following conditions:Disk Space LowCPU use exceeded limitMemory lowRemote Site not respondingRemote Site heartbeat failedRecovery Plan Test started, ended, succeeded, failed, or cancelledVirtual Machine Recovery started, ended, succeeded, failed, or reports a warningEach SRM server monitors the CPU utilization, disk space, and memory consumption of the guest on which it is running, and also maintains a heartbeat with its peer SRM server. VC events are sent if any of these measures falls outside of configured bounds.
57Site Recovery Manager Core Benefits Expand disaster recovery protectionNow any workload in a VM can be protected with minimal incremental effort and costReduce time to recoveryAs soon as disaster is declared, a single button kicks off recovery sequence for hundreds of VMsIncrease reliability of recoveryReplication of system state ensures a VM has all it needs to startupHardware independence eliminates failures due to different hardwareEasier testing based off of actual failover sequence allows more frequent and more realistic testsNOTE: This slide has animationSite Recovery Manager makes it possible for organizations to expand the scope of better disaster recovery protection to more systems.It reduces time to recovery by automating recovery process.It increases reliability of recovery by eliminating several causes of failure encountered by traditional recovery and enabling easier, more frequent testing.Using Site Recovery Manager, you will be able to significantly improve your disaster recovery solution.For one, it makes it easy to expand the number of workloads being protected. By making optimal use of the recovery site resources, we allow a lower barrier to entry than with physical disaster recovery. By automating the difficult and/or manual parts of DR planning, failover, and test (e.g. mapping VMs to storage, booting in the right sequence, taking care of IP changes, etc.), Site Recovery Manager makes the incremental cost of protecting a VM very low from an operational perspective. The only real costs are the disk space at the destination site and enough bandwidth to handle the data change rate of that VM.Site Recovery Manager also significantly reduces time to recovery through automation of the recovery process.And Site Recovery Manager makes the recovery plan far more reliable. It makes hardware dependencies irrelevant by leveraging the hardware independence provided by virtualization. It helps you ensure that the right storage is replicated and only the right storage, including the VM’s system state, which us always completely up to date and patched. It takes care of networking changes you need when you recover to get everything to work properly. And most importantly, it makes it easy for you to do frequent non-disruptive tests to ensure that the recovery plan is correct and that your staff are practiced in executing it successfully.
58SummarySite Recovery Manager Leverages VMware Infrastructure to Make Disaster RecoveryRapidAutomate disaster recovery processEliminate complexities of traditional recoveryReliableEnsure proper execution of recovery planEnable easier, more frequent testsManageableCentrally manage recovery plansMake plans dynamic to match environmentAffordableUtilize recovery site infrastructureReduce management costsNOTE: This slide has animationIn short, Site Recovery Manager is designed to attack the key challenges of traditional disaster recovery—ensuring rapid, reliable, manageable, and affordable disaster recovery.Site Recovery Manager is designed to leverage VMware Infrastructure to address the key challenges we hear customers talking about regarding disaster recovery.Rapid recovery through automating the recovery process and eliminating complexities like hardware dependenciesReliable recovery by taking out failures due to human error or outdated run books and by enabling easier and more frequent testingManageable recovery by providing a central console for managing recovery plans in the same place as you manage your infrastructureAffordable recovery by leveraging the cost benefits of VMware Infrastructure, making it easy to utilize recovery site hardware for other workloads without impacting your recovery time, and by reducing the operational costs of training and of continued management of your disaster recovery plans
60Protected Site Topology Map To frame the technical SRM presentation that will follow we will use the two datacenters depicted in slide as a reference.Production Datacenter we wish to protect – vim22dc (Protected Site) and VMs (app_vm1 to app_vm12)BC/DR Datacenter we will failover to – vim23dc (Recovery Site)
61Setup Workflow – Recovery Site VC Updates The creation of the protection group results in VC Inventory updates in the recovery site.Protected VMs app_vm1 to app_vm12 are created in the VC inventory in the recovery site with the creation of their respective protection groups in the protected siteSRM Recovery Site VC Inventory view after the creation of the Protection Groups – Protection Group 1 and Protection Group 2.
62Questions?Questions?Q&A Session if time permits.