In the last few years we have had some great successes of customers virtualizing their SAP landscapes in production on VMware, check out Mazda and Miami Dade at http://www.vmware.com/solutions/partners/alliances/sap-customer-success.html, both of whom presented their case studies at SAP Sapphire and SAP Tech Ed. For technical success follow the VMware best practice papers and SAP Marketplace notes on virtualizing on vSphere (see the references at the end of this blog). Here are some high level guidelines and considerations.
Support
SAP has supported VMware since Dec 2007 on Netweaver 6.40 and above (64 bit) in production. VMware engineers with SAP experience work with SAP support at SAP offices to provide coordinated handling of production support tickets.
Performance
Our customers are running both OLTP and batch workloads in production. Certified OLTP SAP virtual benchmarks exist. Two 3-tier vSphere certifications 2010016 and 2011044 (http://www.sap.com/solutions/benchmark/sd3tier.epx ) show scalability up to 16000 and 32125 benchmark users.
If you are interested in how virtualized SAP performs in comparison to native, first consider what the chief engineer of the Starship Enterprise (NCC-1701/NCC-1701A) is fond of saying “Ye canna change the laws of physics”, neither can VMware. For an apples-to-apples comparison take a look at 2-tier benchmark certifications 2011028 (physical) and 2011027 (vSphere5) at http://www.sap.com/solutions/benchmark/sd2tier.epx . The virtual result is within 6% of physical. Note that virtualizing SAP typically occurs when there is a hardware refresh/upgrade to newer servers with much faster chips. The latter (with VMware) can provide an overall performance boost compared to the customers current environment.
SAP batch processes are intensive workloads. Examples of such jobs include: MRP runs (Material Requirements Planning) in the manufacturing module; Demand Forecasting/planning Run in the Supply Chain Management product; Allocation Run (ARUN) in the SAP Apparel and Footwear module. SAP has designed these batch jobs to run multiple parallel units of work on multiple processes in the app servers. These app servers can be configured in multiple virtual machines that scale out horizontally to manage the overall runtime of the batch schedule (similar to horizontally scaling out OLTP workloads). The advantage with VMware is that these app servers can be quickly deployed for month-end processing and then decommissioned once batch has completed.
Virtualize in Phases
Virtualization of SAP landscapes is not an all or nothing approach. The SAP landscape consists of multiple SAP products (ERP, CRM, portal etc.) with separate production and non-production environments and separate application and database tiers. Virtualize the less critical systems first, gain experience with VMware, and develop your own internal best practices and then move on to the next set of systems. One option is to virtualize the application tier first all the way from non-production to production.
Design the Virtual Landscape Conservatively
SAP systems drive business critical processes and, as such, SAP users require and demand performance and stability. For instance, if shipping documents cannot get processed by SAP, goods can’t leave the warehouse and the supply chain suffers. Hence SAP application owners are more likely to take a cautious approach to infrastructure changes especially if they have agreed upon performance SLAs between the IT organization and business users. First adopt the phased virtualization approach discussed above to gain gradual confidence and experience in VMware. Next follow some conservative design practices.
You can get a sizing of your virtual environment from a VMware capacity planner assessment or from a sizing exercise by the SAP practice of the server/OEM vendor – similar to physical. VMware partners with all the server vendors. As it can be very difficult to predict actual workload before go-live, sizing will be conservative and factors in month-end peak processing requirements. We recommend setting a memory reservation to the configured size of the virtual machine to guarantee no memory over commit. Yes this will reduce consolidation, potentially impede vMotion and requires high-density DIMMs to efficiently load an ESX server, but the goal is to minimize risk of any performance issue in production and avoid ESX swapping. The latter can be viewed by SAP end-users as an outage and could have serious revenue impact to the business (monetary value of which far exceeds the hardware cost of the extra memory required for SAP).
Other conservative guidelines during initial architecture design may include: laying out virtual machines such that total number of vCPUs equals the number of cores of the ESX server; putting DRS in manual mode (initially SAP admins may prefer to have manual control, also with conservative sizing DRS would not have any impact). After go-live once the workload is known, rebalancing of virtual machines via vMotion can help increase utilizations to the point where vCPU over-commit is possible at which point automatic DRS can be activated.
If memory of virtual machines appear to be over-sized we ask that VMware admins work with SAP Basis administrators to use SAP tools to monitor actual SAP memory usage inside the virtual machine to determine if any down-sizing is required.
Coordinated Performance Monitoring
SAP has provided a rich set of performance monitoring tools that allow Basis admins to monitor the database, OS and SAP application. All of this can be done within the SAP presentation GUI. One such SAP monitoring transaction is “OS07N” which allows monitoring of OS/guest OS level performance counters. This transaction has been updated by SAP to include some virtual level performance metrics. However certain key performance metrics in the virtualized environment such as realistic CPU usage, disk I/O and network dropped packets can only be viewed using VMware tools like vCenter performance charts. SAP admins need to be aware of these counters and should work with the VMware teams to jointly address performance monitoring and management. The following table summarizes some useful performance metrics/tools at the different levels.
Figure: Some Useful Performance Tools/Counters (WIP)
You can find the SAP on VMware best practices guide at http://www.vmware.com/files/pdf/techpaper/SAP-Solutions-on-VMware-Best-Practice-Guide-2011.pdf . Chapter 10 has a summary of the technical best practices – yeah I know we should have separated this summary with titled sub-sections for memory, CPU, storage, network….easier to digest…..we’ll get to this on the next rev.
A complete list of VMware related SAP marketplace notes is available at http://forums.sdn.sap.com/thread.jspa?threadID=1524523&tstart=0 . As is the case with all SAP installations please read the notes.
This blog is part of a series on Virtualizing Your Business Critical Applications with VMware. To learn more, including how VMware customers have successfully virtualized SAP, Oracle, Exchange, SQL and more, visit www.vmware.com/go/virtualizeyourapps
