C/D/H Talks Tech

Author:

Eric Inch

I enjoy learning, using and helping others through technology. This is my second year with C/D/H after many years of consulting for numerous small and mid-sized companies. I enjoy challenging projects and continual improvement in all areas. Most recently, I have been working to help grow the virtualization practice at C/D/H and hopefully add that area to the already impressive expertise in infrastructure consulting at C/D/H.

When I’m not working, I enjoy spending time with my family. I have two little girls who keep me extremely busy but are always the highlight of my day.

For a more in-depth bio and a list of my areas of expertise, please visit http://www.cdh.com.

More about Eric
Articles by Eric Inch

Recently I’ve been reading a lot of comparative documentation on three of the main players in the virtualization space which include VMware, Citrix and Microsoft. I have setup and used each of these virtualization platforms and each one has their own features and drawbacks. I think if you look long enough, you will eventually see through the marketing smoke and come to the conclusion that ESX, XenServer and Hyper-V are all great products that accomplish pretty much the same things. They all offer a solution for maintaining high availability. They all support virtual machines with enormous specifications and they all have the ability to migrate VMs between hosts.

There is a nice feature, offered by only one of these solutions, that I feel really plays an important role in server consolidation. The feature I am talking about is VMware’s ability to over commit memory. The ability to share memory between VMs is achieved through a couple different ways but really allows for a higher consolidation ratio for servers. As an example, on a host with 80 GB of memory running XenServer or Hyper-V you can simultaneously run 40 VMs configured with 2 GB of memory (not quite due to memory requirements of the host, but for an easy example we’ll go with it. Besides, this is my blog posting, not yours!). On similar hardware, VMware could conceivably run 50-60 VMs configured with 2 GB of memory.

One of the main architectural reasons VMware can over commit memory is through transparent memory page sharing. Transparent memory page sharing works by sharing identical pages among VMs. As you can imagine, 40 VMs all running Windows Server 2008 (which you do, right?) have quite a bit of similar information in memory at any given time. Transparent memory page sharing frees up the duplicate information by sharing the common data in a read-only copy on the host and providing guests access to this data. Eliminating the redundant memory allows you to assign the additional memory to more VMs!

Addressing the skeptics:

Skeptic 1: “Wow, that is awesome information Eric, but I doubt companies actually use it in production.”

 Eric (Me): Actually, a recent survey of current VMware customers showed that 57% take advantage of VMware’s ability to over commit memory with 87% of them using it in their production environments.

 Skeptic 2: “But Eric, isn’t there a performance hit when determining which pages are shared throughout the environment?”

Eric (Me): Not really. The algorithms for determining shared pages run during periods of low utilization. While there are resources required to perform these operations, they take place during periods where there is minimal impact on performance.

Skeptic 3: “I liked your blog posting and you have a very nice tie in your profile picture, but how can memory be shared? Won’t multiple servers attempt to change the same shared memory?

Eric (Me): Thanks for the compliment on the tie. In regards to concurrent access or memory integrity, the copy of shared memory on the host is read-only. Should a virtual machine attempt to write to or modify a shared memory page, ESX will first copy the shared memory page. The VM requesting the write operation to the memory is then able to modify the contents of the copy without affecting other virtual machines sharing this same page.