A Virtualization, Photography, Techie, Foodie, Gadget Blog
Header image

I am adding new topic to the Blog.  High Performance Computing and Supercomputing on VMware vSphere.  This topic came up from a recent customer discussion on how they could build a distributed cloud to the purpose of grid computing that scales on par with traditional super computers.   Coming from a family that has been involved with supercomputers for decades, I found this topic to be of keen interest.  As a result, I’ve started to collect a series of notes and white papers on the topic of High Performance Computing (HPC) on VMware vSphere and the changes that must be considered to maximize performance and scalability of a virtual HPC Cluster Environment.

First, an old but mandatory read on the topic is covered in a Paper published by Cam Macdonald and Paul Lau from the University of Alberta titled:  Pragmatics of Virtual Machines for High-Performance Computing: A Quantitative Study of Basic Overheads by Cam Macdonell and Paul Lu
http://www.vmware.com/files/pdf/paullu.vmware.final.pdf

Macdonald and Lau’s paper is currently a little dated but many of the ideas still hold.  Some points to be aware of is understanding how vSphere 5 has been optimized to reduce overhead, allow for better performance, and the automated orchestration features that will allow for capacity on demand.  Macdonald’s and Lau’s closing issues regarding overhead have been reduced to less than 1% for most compute types and with the increase in performance of the CPU every year, this overhead becomes smaller yet.

Next, VMware Employee Jeff Buell posted a blog posts on “HPC Application Performance on ESX 4.1: Stream” back in Sept 2010.

http://blogs.vmware.com/performance/2010/09/hpc-application-performance-on-esx-41-stream.html

Jeff takes great strides in identifying factors that will optimize performance of the compute cluster.  Most notable is the use of local memory when writing applications will ensure optimal memory bandwidth once deployed and keeping the computer resources within a single NUMA node to optimize resource utilization.   While vSphere can address 1TB of RAM and up to 32CPU’s from a single VM, the optimization for performance lays on keeping VM’s tuned and sized to run within the optimal limitations of the server the VM is hosted upon.

Next, I want to make sure you follow the blog posts of Josh Simons.  Josh works in the Office of the CTO at VMware as a strategist specializing in HPC and maintains the VMware Blog posts on HPC here: http://communities.vmware.com/community/vmtn/cto/high-performance

Josh has contributed several videos and discussions on the topics.  With the recent Supercomputing 2011 event in Seattle, John pulled together several interviews and overviews of technologies that will enable Cloud based HPC.

In addition, Josh’s 2010 overview of HPC in the Cloud

http://communities.vmware.com/community/vmtn/cto/high-performance/blog/2010/11/02/video-available-isc-cloud-10-in-frankfurt

Lastly, my own observations and comments:

With the recent release of vSphere 5 and Auto Deploy, the process of maintaining a scalable Cloud infrastructure has become considerably simplified.  The process of updating an entire server farm can be reduced from weeks to minutes by leveraging PXE and an Image Server to refresh entire farms of servers at reboot.  By adding solutions such as templates, workflow orchestration, and capacity management, we can now scale up clusters of computers on demand to accommodate almost any size distributed workload.  Adding vCloud Director and vCloud connector allows us to scale the compute cluster even further into a single or multiple public cloud providers on demand.  In addition, with the new scalability improvements of vSphere 5, we are finding larger VM’s, more addressable RAM, less overhead, and significant IO gains at the Hypervisor.   All of these improvements contribute to the greater acceptance of HPC workloads in the Cloud and in a VM.

As I dig deeper into the topic, I hope I can contribute some of my own personal works to the field and leverage the knowledge of my colleagues to ensure others can explore this emerging growth area.

Looks like VMware made public a revised vSphere 5.0 License Model today. A lot of very good changes that directly benefit the end user. ( http://www.vmware.com/files/pdf/vsphere_pricing.pdf )

The biggest changes are around vRAM Maximums per processor.

vRAM Entitlement per CPU Socket by vSphere edition
- 32GB vRAM/CPU for Essentials Kit (up from 24GB)
- 32GB vRAM/CPU for Essentials Plus Kit (up from 24GB)
- 32GB vRAM/CPU for Standard (up from 24GB)
- 64GB vRAM/CPU for Enterprise (up from 32GB)
- 96GB vRAM/CPU for Enterprise Plus (up from 48GB)

This means a 4CPU Server of Enterprise Plus is entitled to 384GB of powered on VM’s, a 100% increase over the initial model. These entitlements can also still be pooled across vCenter Server (including vCenter Servers in Linked Mode) and only apply to the actual configured virtual RAM of powered on VM’s. VDI Users and VMware View users have a different license model for High Density VDI servers. (Discussed below)

VMware Server (the free hypervisor) users will also be happier. Under the old model, VMware Server was capped at 8GB. The revisions have increased the cap to 32GB per server (not a per CPU limit). This is a hard limit and cannot be exceed like the retail versions. Personally, I felt the 8GB limit was very limiting. The 32GB change is a significant step in the right direction and should accommodation most SMB’s/Branch Office/Home Office users. Those that feel hindered by the 32GB hard limit should look at vSphere Essentials and Essentials Plus (starting at $560) which provides 6 CPU’s (up to three servers with 2CPU’s each) with a vRAM entitlement of 192GB. Alternative Options are to move to the revised vSphere Acceleration Kits (Standard, Enterprise, and Enterprise Plus) which provide bundles of 6 CPU’s at substantial discounts. Pricing has vSphere Essential starts at $83/CPU retail!

Even better, There is no longer a penalty for very large VM’s. All VM’s only count vRAM consumption up to 96GB. Any vRAM over 96GB is not counted. That means a 1TB VM would be covered by a single CPU license. A 1TB VM is now covered by a single Enterprise Plus CPU server license. I can’t imagine running more than a single 1TB VM on a host, but people will always surprise you.

vRAM usage is now monitored on a 12 month rolling average with daily high water marks. This makes large infrequent deployments less of an issue for customer who anticipate going over the vRAM entitlement but know that they will be removing VM’s later.

As before, VMware View environments don’t follow the vRAM model. View is a CPU Socket based license for View Desktops. Non-VMware View users will be able to leverage a vSphere for Desktops product just for VDI. vSphere Desktop edition is licensed based on the total number of Powered On Desktop Virtual Machines and can be purchased either stand-alone in a pack size of 100 desktop VM or included with the VMware View Bundle.

Another interesting note for current vSphere 4.1 users with valid Support and Subscription (SnS). Customers who purchased licenses for vSphere 4.x (or previous versions) prior to September 30, 2011 to host desktop virtualization, and hold current SnS agreements, may upgrade to vSphere 5.0 while retaining access to unlimited vRAM entitlement. Desktop licenses covered by this provision, however, may not be managed by the same instance of Virtual Center which is being used to manage non-desktop OS virtual machines.

Lastly, I have heard that vCenter will get an update in the near future after release to accurately report these last minute changes. In the mean time we should be expecting a new tool to report the actual vRAM consumption.

There are lots of key aspects that were addressed in the initial vSphere 5 guide that have not changed but are different form the vSphere 4 model. Over all, I think the consumer gains a lot more value in the new editions! Unlimited RAM capabilities per server, no more Core/CPU limits, substantial increase in CPU’s per VM limit by edition (32 CPUs/VM for Ent+!) and vMotion all the way down to the Standard Edition.

A lot has changed. I see it all as a major improvement for both the SMB users and for the Enterprise.

vSphere 5 Feature Model per Edition

Taken from revised the vSphere 5 Pricing Guide