Find Communities by: Category | Product


Making the case for replatforming SAP on Intel X86 with VMware


Last week at SAP TechEd’2011 in Las Vegas, I moderated an Expert Networking Lounge Session, working with our partner Intel, entitled “Implications of Replatforming your Cloud architecture on EMC/Intel” (session EXP290).  We had a good turn out with many of our existing customers & partners (Cargill, Disney, MGM Grand, Accenture, Nemaris) participating, and Sylvie Sollod of SAP Alliances Marketing and Mark Pfab of EMC Consulting joined us for a spirited discussion.  I will have a similar lounge session at SAPPHIRE NOW EMEA in Madrid in November.


I used these few slides as the conversation starter for the lounge session, and they were so well received that I want to go over them with you to make the case that the time is really NOW to replatform your SAP instances running on traditional UNIX over to Intel X86 and VMware.


Sometime, less is more, and the key points were presented in a mere 3 slides, plus a fourth slide showing where to download the white paper on EMC and VMware breaking the 1M IOPS barrier (there were of course, the obligatory cover slide and Thank You slide).


The first slide (after the cover slide) outlines the fantastic 289% ROI and 13 months payback achieved by Callaway Golf by virtualizing their SAP landscape – this study was done by the independent consulting firm ASG (Advanced Systems Group), so it is far more credible than the typical sales pitch, and Chinh Van, Callaway’s Director of Global ERP has spoken on record about this success numerous times (including on video interviews).  Chinh Van will next be discussing Callaway’s success with virtualizing SAP on VMware at the USF Conference in Strasbourg, France in October (USF is the SAP French Users Group, similar to ASUG in the Americas).  Here are some other key takeaways from this slide, which also came out the TCO study:


1. 20% less CAPEX

2. 15% less OPEX

3. 30% more productivity realized by Callaway’s IT staff

4. A significantly reduced backup window, in this case when working in tandem with DataDomain

5. Between 15 to 20 servers eliminated


So there is no questions that virtualizing SAP on VMware produces tangible economic benefits, and it is no surprise at all that a very large number of SAP customers who attended SAP TechEd have VMware in their mix in one way or another.


In fact, if you are running SAP on a “slowly dying” UNIX platform such as HP-UX or Solaris, you are essentially throwing money away, what with the high maintenance costs of those OS and hardware platforms, along with the lack of a clear future.


Those of you running SAP on AIX have a lot more to think about, especially since IBM has recently reduced the prices for the P7 servers and AIX by as much as 70% (according to our very reliable sources) and AIX LPARs do indeed offer very good virtualization capabilities.  IBM is reacting to the very compelling TCO offered by the Intel X86 and VMware combo!


And if you are really hung up on running Production on “real” UNIX, at least do yourself the favor of putting everything non-Production on Intel X86 and VMware.  But the time has come to go much further, to GO ALL IN (in Vegas parlance)!


Many traditional UNIX customers have often wondered if the X86 platform and VMware could really handle “real world” Production work load, so I am offering proofs that Intel X86 and vSphere5, working in combination with EMC VMAX storage, can handle just about any SAP workload!


The second slide showed the results of the record breaking SAP SD benchmark which ran on vSphere5 (certification #2011027) which was achieved by Fujitsu in Walldorf on July 19, 2011, and certified on August 2, 2011:


1. Using a Fujitsu PRIMERGY RX300 S6 with 2 Intel Xeon processors X5690 running at 3.46 Ghz in a 12 cores and 24 threads configuration and with 96MB of RAM, the Fujitsu team achieved a remarkable 25,120 SAPS for a single instance!

2. The SD benchmark simulated 4,600 SAP SD users with a response time of 0.99 seconds!


There is no doubt that vSphere5 can handle some of the most demanding SAP workload in the market today, running on Intel X86 architecture.


But the compute power needs to also be complemented by the I/O power, and the third slide was one that I borrowed from Chad Sakac’s presentation at VMworld 2011 also in Las Vegas in late August.  There, Chad announced that EMC and VMware collaborated to break the 1 million IOPS barrier using vSphere5 on a single ESX server and a fully loaded VMAX in an 8 engines configuration.  You can download the white paper documenting this feat at


In fact, Chad made it a point to ask the packed crowd at VMworld this question: “with these kinds of numbers, why aren’t you folks virtualizing your SAP or ERP environments”?  Why not indeed?


Remember that we now have documentation that vSphere5 can handle 25,120 SAPS and 1 million IOPS on a single SAP instance!


EMC Consulting (EMCC) even have processes and procedures in place to help you with a minimal (as in near-zero) downtime during migration and replatforming from your old to new SAP platform, which could also include a SAP version upgrade, a database change (e.g. from Oracle to DB2), and more, all of which are described in a white paper documenting a real world EMC customer experience with near-zero downtime migration and replatforming.


So what do you think?  Is this high time to really explore replatforming your SAP on traditional UNIX over to Intel X86 and VMware?  Should you check out the really cool vBlock and do a POC?  And we have not even began to discuss the richness of the VMware portfolio such as vMotion, vCloud, SRM (Site Recovery Manager) which add fantastic DR/BC capabilities and technical agilities at very little or no additional charges.


Oh, I almost forgot to mention that EMC IT completely believes in running SAP on vSphere5 and Intel X86 - refer to slide 32 and 33 of Bill Reid's fantastic presentation on Project PROPEL (EMC's own very large SAP implementation) where he clearly told everyone that EMC will have a 100% virtualized SAP deployment on vBlock.  Prior to Bill's presentation, Bernhard Schulzki discussed "SAP Running in a Cloud Architecture" to a packed room - very cool!


So, let the debate begin!



Tim K. Nguyen

Principal SAP Solutions Consultant & EMC Cloud Architect

EMC Solutions Group


Implementing FAST VP for SAP on VMAX, why are different FAST VP policies needed?


In my first two blog posts on “Implementing FAST VP for SAP on VMAX”, I reviewed some recommended best practices to define Storage Pools and Storage Groups, as well as discussed the art of creating FAST VP policies since our research indicated that different policies are needed for Production vs. non-Production and for SAP ECC instead of SAP BW for example.  I recommend that you review those 2 blogs since they provide you with the foundation for implementing FAST VP in any SAP environment.  As previously discussed, setting up the Storage Pools is the first step for deploying a VMAX and defining the Storage Groups is the first step to implement FAST VP.

In this blog, I will review some recommended FAST VP policies which were given to customers and I will comment on how they should be implemented.  I will also discuss why redo logs should NOT be under FAST VP controls.

So you have set up your Storage Pools so that the massive storage on the VMAX can be carved out, and using SMC (Symmetrix Management Console), you have carefully defined the Storage Groups for each of your servers (both database servers and application servers) and making sure that database redo logs are on their own Storage Groups.

You have also used various tools to profile and better understand your SAP applications performance profile over a period of time so that you can have a starting point for designing FAST VP policies.  Now, it is important for me to point out that this collection of performance metrics is done OUTSIDE of and SEPARATELY from the collection of performance metrics by the VMAX which will be the input for how the algorithm for data movement will be calculated (more on this point in future blogs).  You are now ready to explore the design of FAST VP policies and implement them.


As I indicated in my previous blog, it’s more art than science, and while I certainly have a few recommendations, it’s definitely YMMV (your mileage may vary) as no two SAP environments will have the same work load profiles.  Therefore, here are some rules of thumbs for good design & implementation of FAST VP policies:


1. Test & validate, test & validate, test & validate: as mentioned in my earlier blog, ideally, newly developed FAST VP policies should be tested under realistic workload in a Production-support environment (one that is similar to Production), and validated with performance measurements.  Additional modifications to the FAST VP policies may be needed before deployment into Production can occur.


2. If testing under load in non-Production is not possible, then you will need deploy conservatively, in order to observe & adjust, and continue on until the desired objective has been achieved.  You will start out with a conservative FAST VP policy designed to insure that there will be no performance degradation when FAST VP is initially turned on, then gradually applying more “aggressive” policies overtime.  A Symmetrix VMAX storage array will support up to 256 FAST policies, so you should have enough flexibility to implement this Observe & Adjust strategy.

3. FAST VP policies should be set to more than 100 percent: yes, this point was not completely clear when we first tested FAST VP for SAP in our Hopkinton solutions engineering lab, but thanks to the great contribution of our FAST VP guru John Burkhalter, we have learned a few things:

a. While the usage limit of each tier (e.g. FC, EFD, and/or SATA) must be between 1 percent and 100 percent, the COMBINED usage limit for all thin storage tiers in the FAST VP policy must total at least 100 percent, but ideally should be greater than 100 percent.

b. Creating a policy with a total upper usage limit greater than 100 percent allows flexibility with the configuration of a Storage Group whereby data may be moved between tiers without necessarily having to move a corresponding amount of other data within the same Storage Group - basically the essence of automatic retiering.

4. Database redo logs should NOT be under FAST VP control, as we want to have highly predictable performance without any tiering involved.  This is why the best practices call for redo logs to be put on their own Storage Groups, most often using FC but in some case using EFD for maximum performance.



The FAST VP for SAP policy used in tests done in our Hopkinton solutions engineering lab, and mentioned in our white paper, was 2% EFD, 38% FC, 60% SATA, which added up to 100%. While there is nothing wrong with this policy which yielded rather impressive cost savings results without impacting overall performance, we believe that more effective policies could be designed and deployed.

Therefore, here are some FAST VP policies which we have recommended to customers for Production (my thanks once again to my fantastic team of experts, John Burkhalter, Allan Stone, Brian Redmond, Jeff Kucharski, and Andrew Chen – see my first blog on FAST VP if you want to know who they are).


FAST VP policy example #1:  50% EFD, 100% FC, 0% SATA
This is a very conservative policy designed to maintain at least the equivalent or better performance than running on Thick LUN on other storage arrays.  With this policy, data resides mostly on FC, and may be able to be tiered to EFD, but data will never be tiered down to SATA.  This is a performance-first policy which will not yield any cost savings benefits since SATA is not in play, but one that can be used as the initial policy in Production in the event that load testing is not possible for whatever reason.



FAST VP policy example #2:  50% EFD, 100% FC, 40% SATA
With this policy, SATA is now in play, and infrequently used data will be tiered down (remember that as much as 75% of a typical SAP database is not used in normal operation).  This policy is ideal for a very active OLTP environment like SAP ECC since data will primarily be residing on FC but hot data may be tiered up to EFD.  This is also a good policy to implement as the next step after the conservative policy example #1 above, in order to build confidence with all stakeholders that performance is not being impacted as infrequently used data is tiered down to SATA.



FAST VP policy example #3:  50% EFD, 100% FC, 65% SATA
With this policy, infrequently used data (especially stuff which has not been touched for weeks or months) will be aggressively tiered down to SATA, but at the same time, really hot data may be tiered up to EFD, while allowing the majority of data to be on FC.  This could be a good policy for SAP ECC running in Production, but as I have stated previously, YMMV so it’s important to observe and adjust at all times.



FAST VP policy example #4:  80% EFD, 10% FC, 100% SATA
This is a hypothetical FAST VP policy, which could in theory provide the most optimal price performance for SAP since hot data will be on EFD while cold data will be on SATA, with practically nothing on FC.  I must point out that this hypothetical policy has NOT YET BEEN TESTED, and is put here primarily for discussion purposes.  So what do you think?  Will this policy work, or will performance problems be occurring?  Weigh in with your opinions.



We believe that while these Production-oriented FAST VP policies can also be used in non-Production situations, perhaps more cost effective policies can be created?  For instance, for a DEV environment supporting 5 users, may be a SATA only policy could make sense?

You can find more general information on FAST VP theory of operations and general best practices for any applications in EMC Technical Notes 300-012-015 and 300-006-718.

In the next blog, I will discuss the data collection window, when and how to turn on FAST VP policies, and suggestions on working with the data movement window.  In future blogs, I will discuss topics ranging from measuring the effectiveness of FAST VP policies, to validating the effectiveness using load testing, to designing policies for non-Production environments, to documenting costs savings and/or performance increase which would provide a nice TCO analysis which would validate the concept that implementing FAST VP for SAP on a VMAX is the right thing to do.


Tim K. Nguyen

SAP Global Technical Evangelist & EMC Cloud Architect

EMC Solutions Group

Filter Blog

By date:
By tag: