Virtualization, Sustainability and Selfishness

[Former Member]

On December 7, leaders from 192 countries will gather at the UN Climate Change Conference in Copenhagen to make serious decisions about the future of our planet. More details about this are at Hopenhagen.org

I have the pleasure (?) of seeing the system landscapes of a lot of SAP customers and have advised a fair few on landscape strategy as a whole. I've seen everything from IBM AS/400 to Dell and from Informix to MSSQL. I don't think there's a best platform or a best RDBMS, but rather just the best one for a customer at that point in time.

This blog isn't about the pros and cons of one platform or RDBMS, but rather about what they all have in common - in my experience of SAP landscapes: massive waste of resources. This blog is about where selfishness and climate change can meet, with sensible business acumen.

Our internal SAP landscape consists of some 40 SAP systems, a mix of demo, development and productive systems - many of which are idle most of the time. We consolidated this into 2 Dell servers running VMWare with a lot of RAM and a shared SAN.

This replaced a sprawl of older failing servers - 2 racks full in fact. But a new Wintel server full of CPUs and RAM and at 100% utilization uses just 1400BTUs of energy. This is the same as a 3 year old server running at idle! Given that we run our VMWare farm near capacity, the 40 SAP servers use the same energy as two old systems doing nothing.

Either of these uses about 450W, i.e. 4000KWh/year, and therefore costs about £/$400 to power over one year. So consolidating 40 servers with 2-4Gb RAM running (mostly) at idle to 2 running at 100% saves £/$15000 per annum.

Worried about performance if you consolidate that much? Don't be. The latest Dell pizza boxes run at around 25,000 SAPS for 8 cores/2 CPUs. Our old Dell boxes were about 1500 SAPS for 2 CPUs. So for 2 vs 40 systems, that's 50,000 vs 60,000 SAPS. You would have to be running the old systems at >80% load on average to be worried about performance.

If you're interested, SAPS are a measure of CPU performance - a bit like MIPS, if you like, but more meaningful. 100 SAPS equates to 2000 full processed order line items per hour capacity. In real terms it's a nice way of comparing between different hardware platforms, and a nice way to size SAP systems.

Anyhow, I digress. 2 systems replaces 40, with savings of £/$15,000 for power consumption alone along the way. That's before we talk about the reduced cost of supporting virtualized SAP systems, reductions in hosting fees and air conditioning, and various other aspects. Saving the planet doesn't need to be about hugging trees - it can be about clear business thinking and ROI.

I've taken a specific example of how this worked for us but this is just as applicable during any hardware refresh. Maybe you don't want to buy Dell and you want to buy IBM or HP - if so, the same things apply on any Wintel platform.

Or, you are on UNIX and you don't think it relates to you? Actually, the UNIX guys got there first. Solaris containers & zones, HP vPars and nPars, IBM LPARs and virtualizion, all do much the same. And taking it to the next level, you can utilize your VMWare farm to provide fast application servers for your UNIX SAP central instances - getting UNIX reliability for your central instance and Wintel price/performance for your application servers. This might sound controversial, but Wintel systems are much faster per CPU than their UNIX brethren, with the arguable exception of IBM's expensive and super fast 5GHz POWER6 CPU, for the pedantic!

What I'm not suggesting is that you rip out all your existing SAP hardware and replace it with shiny new boxes. But when it's time to replace it. When support runs out and CPUs start to fail, think about your strategic direction. In the scheme of things we don't have that extensive a SAP landscape and we have 50,000 SAPS and 200Gb+ of RAM.

Your strategic direction should be to make your assets work harder. Servers running at 80%, not 20%, work harder for you, cost you less, and may save the earth. Here's a few tips to get you on your way:

1) When sizing SAP VMware instances, add up the RAM allocated to each server, and subtract the "free memory" in device manager for each system - you don't need to buy RAM for free memory in VMWare, and this is called overcommitting memory! When you're done, add 25% for overheads to calculate your total RAM requirements.

2) If you want to virtualize productive systems, give them dedicated CPU and RAM - don't overcommit on these. Sorry if you have the Oracle RDBMS, they don't yet support VMWare for productive systems. Check Note 1173954 Support of Oracle for VMWare and XEN.

3) Based on (1) and (2), buy enough servers with enough memory to support your total RAM requirements. Buy the fastest CPU on the market and think in the terms of around 12Gb per core. In real terms this means fill the server up with memory and CPUs and you will be fine, unless you have some very CPU heavy systems. I tend to find you run at 100% memory and 60% CPU on this basis, which is fine.

4) Be sure to read the VMWare related notes. 1056052 - Windows VMWare ESX 3.x or vSphere configuration guidelines is a good place to start.