Shanghai Economics 101 – Conclusion

In the past entries, we’ve looked only at the high-end processors as applied to system prices, and we’ll continue to use those as references through the end of this one. We’ll take a look at other price/performance tiers in a later blog, but we want to finish-up on the same footing as we began; again, with an eye to how these systems play in a virtualization environment.

We decided to finish this series with an analysis of  real world application instead of just theory. We keep seeing 8-to-1, 16-to-1 and 20-to-1 consolidation ratios (VM-to-host) being offered as “real world” in today’s environment so we wanted to analyze what that meant from an economic side.

The Fallacy of Consolidation Ratios

First, consolidation ratios that speak in terms of VM-to-host are not very informative. For instance, a 16-to-1 consolidation ratio sounds good until you realize it was achieved on an $16,000 4Px4C platform. This ratio results in a $1,000-per-VM cost to the consolidator.

In contrast, let’s take the same 16-to-1 ratio on a $6,000 2Px4C platform and it results in a $375-per-VM cost to the consolidator: a savings of nearly 60%. The key to the savings is in vCPU-to-Core consolidation ratio (provided sufficient memory exists to support it). In the first example that ratio was 1:1, but in the last example the ratio is 2:1. Can we find 16:1 vCPU-to-Core ratios out there? Sure, in test labs, but in the enterprise we think the valid range of vCPU-to-Core consolidation ratios is much more conservative, ranging from 1:1 to 8:1 with the average (or sweet spot) falling somewhere between 3:1 and 4:1.

Second, we must note that memory is a growing aspect of the virtualization equation. Modern operating systems no longer “sip” memory and 512MB for a Windows or Linux VM is becoming more an exception than a rule. That puts pressure on both CPU and memory capacity as driving forces for consolidation costs. As operating system “bloat” increases, administrative pressure to satisfy their needs will mount, pushing the “provisioned” amount of memory per VM ever higher.

Until “hot add” memory is part of DRS planning and the requisite operating systems support it, system admins will be forced to either over commit memory, purchase memory based on peak needs or purchase memory based on average memory needs and trust DRS systems to handle the balancing act. In any case, memory is a growing factor in systems consolidation and virtualization.

Modeling the Future

Using data from the Univerity of Chicago and as a baseline and extrapolating forward through 2010, we’ve developed a simple model to predict vMEM and vCPU allocation trends. This approach establishes three key metrics (already used in previous entries) that determine/predict system capacity: Average Memory/VM (vMVa), Average vCPU/VM (vCVa) and Average vCPU/Core (vCCa).

Average Memory per VM (vMVa)

Average memory per VM is determined by taking the allocated memory of all VM’s in a virtualized system – across all hosts – and dividing that by the total number of VM’s in the system (not including non-active templates.) This number is assumed to grow as virtualization moves from consolidation to standardized deployment.

Nehalem-EP: Your Best Consolidation Option?

Intel’s Nehalem is new and sexy, but currently limited to 2P platforms. This fact is forcing Intel to refer customers to their aging Xeon 7400 series (based on the older “Core” architecture, not Nehalem)  for 4P solutions and those seeking higher consolidation ratios. Still, leading equipment and solution vendors are scrambling to build offerings around the 2P-only Nehalem due to its significant value proposition over aging, dead-end Intel technology that can not keep-up in an increasingly virtualized world.

Intel asks you to “replace nine (single-core) servers” with one 2P Nehalem system and promises to “deliver ROI in 8-months” based on power savings alone. This “enhanced value proposition” is a compelling component of a solution providers’ foot-in-the-door strategy to lay-out system, storage and virtualization refreshes. The goal: higher consolidation rates and better virtualized performance promised by Nehalem (better results can be achieved with AMD Shanghai – see below). But with no 4P or 8P offerings is Nehalem the only option? Better yet, is it even a cost effective “refresh” option?

To understand the value proposition of Nehalem in an increasingly virtualized world, we need to identify the key benefits of the technology and how a single 2P system can replace 9 2P/1C systems. Simply put, Nehalem represents the most current virtualization hardware offering from Intel, finally bringing it to parity with AMD’s quad-core offering which has proved itself over the last 18-months. Its updated quad-cores, IPC, bus architecture and hardware assisted virtualization technologies deliver capabilities that older single-core systems can not match.

EPT and RVI – Hardware Virtualization Enhancements

AMD introduced its hardware assisted virtualization in 2006 with AMD-V (code named Pacifica) available in all processors supporting Socket-F and AM2 platforms (except the low-end Semperon). This technology enabled Xen-based hypervisors – lacking broad binary translation engines – to virtualize operating systems without modification. Intel later countered lead with Intel VT-x in its Itanium and Pentium D 662/672 desktop processors in 2005.  Intel added VT-x capability to Xeon processors in 2H/2006. Intel makes VT-x available in some Core and Core2 processors, Xeon 3000/5000/7000 and Core i7 processors. No Celeron, Pentium Dual-Core (prior to 662) or Pentium M processors have this feature.