VMware announced Monday that VMware Site Recovery Manager will be available for order next week. Site Recovery Manager is a new product for disaster recovery management and automation that leverages the storage technologies of our storage partners. Clearly, business continuity and disaster recovery are critical for SAP customers, so this is a great time to talk about the DR project that we have been conducting at the SAP Co-Innovation Lab together with SAP and NetApp. See also the NetApp press release.
What are the issues with 'traditional' DR as we know it? First of all, many SAP (and non-SAP) customers do not have a proper DR plan in place, because it is too complex and cost-prohibitive for them. Investing in a heavily under-utilized infrastructure simply does not make sense to them. And if they have plans, they rarely get around to actually testing the framework. I generally hear from customers that they carve out time for this important effort once a year, at best. Concerns about impact on production are another issue. The DR framework is another huge challenge since it usually consists of a long list of manual steps which are often executed by multiple groups, making it very hard to minimize recovery time. Given the critical importance of having a functioning datacenter, these issues leave customers with significant exposure if unexpected failure events occur.
Site Recovery Manager addresses these issues by enabling you to easily create and manage centralized disaster recovery plans, allowing for mouse-click automated testing of these plans without impacting your production systems, and automating the site fail-over in case of a disaster.
In the SAP Co-Innovation Lab (see also VMware Joins the SAP Co-Innovation Lab!) , we tested this scenario for SAP, as it is a critical feature for our joint customers. The DR setup we staged in the lab gives a good example of the product in the SAP context, and it also shows the way Site Recovery Manger integrates with storage partner technologies (NetApp in this case).
Below we illustrate how easy it is to test the DR setup with Site Recovery Manager.
Starting Point:
We start with two SAP applications on the production site: IDES-prd and SCM-prd. The applications are located on two separate physical servers. On the DR site, we only have one physical server, which already is used by a sandbox system, SCM-sbx. The two SAP production instances are 'protected' and a DR plan is created automatically (although it is still customizable) to govern the fail-over steps in case of a disaster. In this case, we want both system to fail over to the one physical node on the DR site, and we choose to keep the sandbox system running. The protected systems are replicated in short intervals to the DR site.
Testing:
To illustrate the testing, we open VMware VirtualCenter in both the production and the DR sites. In the production VirtualCenter window, we open an SAP GUI from the console and look at the SAP sales orders, shown in the upper left window in Figure 1 below. In the DR VirtualCenter window, we execute the DR test scenario. Testing steps is as easy as pressing the button "test" for the appropriate plan. The test plan integrates with the underlying NetApp storage to create a FlexClone of the replicated VMs, boots them in an isolated (for test purposes) network, so that there is no interference with the production systems. The picture below (click on it for a better resolution) shows that the SAP VMs (IDES-prd and SCM-prd) are “recovered”, which means that the VMs have been started.
Figure 1: SAP DR plan in Action (upper left: production site, lower right: DR site - please click on the image for better resolution)
Now we are ready to test the systems. We go to the Inventory at the DR Site and open the console for the IDES-prd system. We login to the SAP UI and look up the sales orders. Note that the prd system and the DR system are running simultaneously, but that there is no interference, since the DR systems are created from a clone of replicated environment in an isolated network (try doing all of that in a physical environment!).
Figure 2: Test of Recovered SAP Systems (upper left: production site, lower right: DR site - please click on the image for a better resolution)
The sales orders exactly match between production site and recovery site, since in this case we haven’t created new sales orders since the last replication.
So the test is successful! Note also that both SAP systems started on the same host, while the pre-existing sandbox system was still running on that host as well. Of course, you can automatically suspend all existing VMs as part of the plan so that the recovered production instances have maximal resources.
jorad
chreis
jasondinalt
m@t
