Oct 7, 2008
Recently, I spent a day at the ASUG conference in Nashville to give a presentation together with Gunther Schmalzhaf, the SAP product manager of Virtualization and Adaptive Computing. We talked about how VMware Infrastructure and SAP Adaptive Computing not only work together and complement each other very well (great information can be found at *https://www.sdn.sap.com/irj/sdn/adaptive*), but also how SAP currently integrates the AC Controller and VMware VirtualCenter, enabling SAP Basis Administrators to monitor and manage the virtualized SAP landscape all within the Adaptive Computing Controller!
This is not only great from a functionality perspective, but it also shows yet again the alignment between SAP and VMware.
Now, what exactly is being integrated, and why is that good for our customers? Don’t Adaptive Computing and VMware Infrastructure do pretty much the same thing? After all, both start, stop, and relocate application resources, so shouldn’t I mostly use one or the other?
The answer is ‘no’. While both technologies address on a high-level similar pain points, they do so in very different and generally complementary ways. VMware virtualizes the server, and Adaptive Computing (AC) manages virtualized applications. VMware has all of the features/functions and know-how about the infrastructure, and SAP AC provides all of the manageability features for the SAP applications. Together, they provide end-to-end control for SAP Basis Administrators.
Start with the core use cases for parallel operations available today. First of all, Adaptive Computing can be used as an elegant P2V tool. You can quickly relocate (with downtime) your SAP instance from a physical server to a virtual machine. Another use case is that if you increase the size of a virtual machine in VirtualCenter, you can add more application resources through Adaptive Computing. You can also cleanly shut down the SAP instances before shutting down a VM, etc. Lastly, if you want to use Adaptive Computing for start/stop/relocate functionality of SAP services, but you have not installed your SAP instances in a ‘virtualized’ way (i.e. using logical host names, etc.), you can use VMotion to do the relocation, and that without downtime (now of course relocating the application and the OS together).
But the situation becomes a lot more interesting when you actually integrate both technologies, which SAP is doing currently. The present stage of the integration work was shown at SAP TechEd Las Vegas and at the aforementioned ASUG conference, and it will surely also be demonstrated at TechEd Berlin.
What does the integration entail? Let me start with a few customer questions that I frequently get. “With VMware ESX there is a new component in the stack. How do I do the monitoring then?”, “I am an SAP Basis Administrator and I need to see what else is running in my ESX servers. But I do not want to learn a new tool!”, or “My infrastructure manager does not want to give me access to VirtualCenter, so how can I see what is going on in my SAP landscape?” are some of the more common ones.
The upcoming integration addresses all of these points. The AC UI will feature a new tab called “Virtualization”, adding core virtual machine functionality to the existing AC functionality (which basically treats a virtual machine as a physical system). In the “Virtualization” tab you can see which application service is running on which virtual machine on which ESX host, and you get information about ESX hosts and virtual machine usage data. You can also execute core VMware commands like start/stop/suspend/resume for a VM, and trigger a migration using VMotion through the SAP UI. Very cool is also the following feature: If you click on “shutdown” for a VM, the AC Controller displays a pop-up window listing which SAP services are running in the VM and asks you whether it is still ok to proceed with the shutdown. This is clearly new stuff and a great interaction between virtual infrastructure and application.
Below are a few screen shots to provide more detail.
Jun 16, 2008
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