Virtualizing SAP? No Problem.

August 13th, 2014 by

We just worked with a midmarket wholesale distributor to virtualize SAP, and saved them $60K in the process. Here’s what we learned.

As organizations continue down the path of virtualization, they reach a point where it’s time to tackle those mission critical applications. If the nightly virus update is slow, life goes on. But a distributor that can’t close the month because of SAP performance is a whole other story. These are the “last apps standing” between 50% and 90%+ virtualized. In this case, our role was helping the ops team tackle two issues:

  • Pre-deployment capacity planning
  • Run-time performance assurance

 

Application Resource Requirements

SAP is deployed as a typical 3 tier application with a database, application and web server, and run across three environments: development, test, and production. To understand the virtualization requirements for this project they mapped out vCPU, Memory, Storage and Network resources for each environment based on best practice guidelines from SAP. Sizing for the app server may include:

  • Development: 2 vCPUs; 16 GB vMem; 100 GB Storage; 1 NIC
  • Test: 2 vCPUs; 8 GB vMem; 60 GB Storage; 1 NIC
  • Production: 2 vCPUs; 12 GB vMem; 10 GB Stroage; 2 NIC

Adding these to the web server and database requirements is fairly straight forward. This gave us our starting point for requirements.

First Pass at Infrastructure Sizing

A big opportunity for the team was to smartly reduce infrastructure needs. SAP’s guidelines left them uncertain if they will be using the environment as efficiently as possible. “We know we are really not efficient because there is no real detail in terms of what SAP needs. If I argue with them, and I get it wrong, it’ll be on my shoulders. No one will know if I overprovision, but the project will be much more expensive.”  Also, based on our experience, the best practice sizing recommendations from vendors are often incomplete.

To explore this challenge, we used the Planer capability within VMTurbo’s Operations Manager. We created the templates representing the various footprints for the SAP development, test and production workloads. The inputs generated a comparison of today and the future. The team was surprised: not only did they not have to procure new hardware (which they had budgeted at $60K), they could actually decommission one of their hosts and still handle the production deployment with room to breathe through increased memory and CPU utilization on the other 3 hosts.

Capacity planning for SAP cluster
VMTurbo’s capacity plan capability enables you to determine if you have the resources you need to run future workloads

Moving from Plan to Run Time

Closely provisioning resources would save the team almost $60K in new hardware. But there was that nagging feeling, “What if the inputs are incorrect? What if once we go live, more users touch production?”

The benefit of VMTurbo is that its primary focus is controlling the environment to assure performance. This means that VMTurbo can manage SAP workloads and the required resources in real-time. When VMTurbo produces a plan its doing it based on the same analysis that is used to keep the environment performing so the reality mirrors the plan. Basically, we’re on the hook if the plan doesn’t work.

Let’s look at an example. As the end of the month approaches and this distributor is consolidating numbers across multiple distribution centers, there is going to be an increase in the number of users concurrently working in the SAP production environment. As application workload increases, and the utilization of memory rises, the VMs may begin to swap memory to disk. Swapping to disk is relatively fast but moving back from disk will cause delays and degradation in application performance, preventing the finance department from getting the numbers done on time. Or a customer service rep following up on a question regarding an invoice may need to look up a record in the same production SAP environment. The customer on the other end of the line is not going to appreciate that the VMs are slow in reading back from disk…

Now let’s look at the same scenario with VMTurbo. Memory utilization increases on the host for the production SAP VMs. VMTurbo recognizes that the host that is providing this memory is running out and raises the price of memory. The VM realizes that Memory is now expensive and goes shopping for a better deal on another host. At the same time VMTurbo performs this same analysis across all of the other factors ensuring workload performance – Compute, Storage and Network – for all VMs and resources in the environment effectively creating a market. If VMTurbo finds a better deal, maybe on the hosts for tests, or a host for a non-mission critical application, VMTurbo would recommend a move. This allows the ops team to burst into other clusters and prevent performance degradation for the application. And with VMTurbo in automation mode the move will happen without the System Admin having to lift a finger.

To see how VMTurbo can help you tackle those mission critical applications download a 30 day trial today.

This article is about agility. Read more like it at the [Performance, Efficiency, Agility] series.
This article is about agility. Read more like it at the [Performance, Efficiency, Agility] series.

Leave a Reply

Your email address will not be published. Required fields are marked *