This post is a bit controversial (which posts on VMlover aren’t?), it is based upon discussing the recent discussing x86 hardware releases and there value prop of being capable of having more total RAM Density for Virtualised environment’s. When I say Virtualised I mean Server workloads that run business applications not VDI.

One of the reasons that this post could be classed as controversial is this, I question whether RAM density is really giving the customer excessive space and capacity that we are being led to believe it can, and when I say this I mean using a box with suitable IO/form factor that we would class as our sweetspot for Virtualisation based on the usual factors such as a comfortable level of Consolidation ratio, price per VM etc ?

Wind the clock back

Four or so years ago when 32 Bit memory address was de facto for a all OS’s, it was also the start of something good with the beginning of Server Virtualisation being accepted within most enterprise datacentres. At this time 64bit OS/Applications were only a twinkle on a distant roadmap or limited to high end Risc based platforms, the transition to running your applications hosted at the time on 32 Bit was also no way just a swing to x64 bit from 32, the vendors had to do large volumes of work for x64 to become a reality.

Today though datacentres are very different, we have 64bit versions of almost every x86 commodity OS going all capable of exploiting larger allocated RAM volumes to allocate for apps and these apps are compiled to  make best use of large quantities of RAM, one example being Exchange 2007 which is designed to make best use of RAM to cache as much feasibly possible without having to use disk and introduce the deadly bottleneck to virtualised environment of Disk I/O.

My controversial bit

So what am I getting at? Well I think we are still regardless of the excessive volume of RAM that is available to populate in recent x86 Hardware we are still unlikely to get the levels of consolidation ratio in the real world that the marketing from the manufacture uses as the key selling point.  I think we see a relative curve of new x64 gen OS and Applications requiring more higher volumes of RAM to run sufficiently as a baseline minimum requirement, we also have an explosion of growth in required RAM resource to operate applications on x64 bit due to demand for optimal performance and more concurrency.

In Virtualised server environments VMware vSphere allows assignment memory volumes to VM’s that are suitable to run Tier 1 workloads such as Exchange, SAP and Oracle. Again as with the OS/APP stack In the past, a Virtualised environment comprised of in earlier incarnations of smaller under utilised VM’s, now you have VM’s with 12-16GB of RAM which run extremely happily and the more RAM the merrier, so overall larger VM’s mean less VM density per Host. Within Virtualised environments you also have the factor of eggs in one basket scenario and implication of outages on hosts storing large density VM counts, from which has been discussed many times across the blogosphere, some architects and designers prefer a more risk adverse strategy to deploying with this generally being down to SLA expectancy from your business. Personally if you have a resilient and highly available environment built with failover in mind using a VM host with high capable density is certainly acceptable and something that can be implemented.

So to summarise my controversial view, I fill that OS/App and VM RAM sizing requirements is relative to how big the host grows so will not allow you to achieve what you think is possible due to this.

Some future solutions to this problem

I’m going to digress away from the existing facts I’ve stated effect the Host size against VM density argument, and talk about future directions that may ensure we can achieve higher density with hosts.

Removal of the OS or the level of bloat that is required to run an OS would be a start, this is something which has been a vision even back in 2007 by Mendel Rosenbaulm. Reduction of the OS means running the application on finely tuned minimal footprint operating environment which uses only what the application requires. This strategy is achievable today either with JeOS or dare I say it for Windows environments with 2008 Server Core, Remember though having a thinner less feature rich OS usually means it has no GUI and the admin needs to rely on pure CLI commands to operate the environment. In future vendors need to focus to the same way VMware has architected its management strategy with ESXi. ESXi has API to use externally controlled and managed management tools such as vCenter, PowerCLI, additionally it utilises open standard interfaces such as CIM and WS-MAN for managing hardware components.

An obvious is developers could of course work on making applications more efficient, this is tough though, the industry has a shaded past to shake off with apps being compiled to run within the Windows world. This however has had the flip side of meaning it is easier to manage and easier to deploy. My prediction is the next step to more efficient applications is within development of cloud based applications where metered OPEX cost of running applications will drive efficiency.

At a different altogether layer to approaching the problems of excessive memory consumption by the OS and Application, VMware vSphere includes great technology which can provide a more denser environment, this does so with the following key features

• Transparent Page Sharing – VMware environments can reduce the amount of memory used physically by sensibly knowing memory pattern allocation and sharing this between VM’s, this removes a large volume of noise that would occur in non TPS based environments such as Hyper-V and Citrix (for now) that can’t do this and can’t overcommit resource.
• Memory Ballooning – Working as a Virtual hardware driver within a VM, the driver responsible for Ballooning will manage memory allocation based on memory activity occuring within the VM, if memory is requested it works with the Host to provide requested memory (if available), if it isn’t requesting memory it will then interact with the Host to allow it to reallocate memory to another VM that needs it.
• Memory Compression – A future release that will compress memory pages, Scott Drummonds has detail on this http://vpivot.com/2010/03/01/memory-compression/
• Flash Caching – I wrote about this and how Oracle Exadata benefits last week, this provides disk caching but at a faster state than standard spinning rust provides

The above do have performance penalties in some shape or form, they are small but it is important to bear this in mind.

Summary

Maybe a bit controversial here but its my view, I am a realist and very rarely fall for marketing goop and excessive numbers touted on a spec sheet. I think its important that the industry look to make the workload more efficient instead of using Moores Law to make there products look attractive and better than other competitors.

One Response to “High Density Virtual Hosts”