I/O holds up the traffic in virtual systems
Clearing the bottlenecks
We can now host 512 virtual machines on a single physical server. That's a lot of virtual machines trying to squeeze a lot of I/O out of a single server's networking interfaces.
Meanwhile, vSphere 5 is out.
Customer feedback prompted some revisiting of that licensing philosophy.
VMWare made a far more interesting move on the low end. The company upgraded the free version of the hypervisor with some new features, including a change of the RAM allowance from 256GB to 32GB.
This naturally led to fierce debates on internet forums and gave tech blogs everywhere plenty to write about.
The change was bad for my customers. Determining what to do has occupied a great deal of my time and led to some interesting discoveries.
In late 2011, the virtualisation discussion has moved beyond “virtualising your servers”. You are either virtualised or you are not, in which case you are in a steadily evaporating minority that even niche players don’t really want to deal with anymore.
In a virtualised world, VMWare makes the best operating system to install on the bare metal of your x86 server. Many competitors are struggling to match features that are two major versions old. At best, they are competing against VMWare’s last product release.
Against this backdrop I must measure VMWare’s changes to ESXi. Modern servers are so fast and so powerful that only VMWare seems able to actually make use of them.
In many cases, the ability to fill up a system’s RAM with virtual machines means nothing if the underlying hypervisor can’t keep up with the demands on I/O.
I have servers in the field running 8Gbit network interface cards (NICs) providing both SAN access as well as client-facing network ports. These servers run only 128GB of RAM – an average of a mere 25 virtual machines apiece – and they absolutely flatten those NICs all day long.
I have begun upgrading the heaviest usage servers to shiny new 10Gbit NICs, only to discover that these systems are perfectly capable of flattening four 10Gbit NICs as well.
You never really appreciate how powerful a pair of Xeons is until you have asked yourself: “Exactly how much I/O do I have to feed this monster before I have bandwidth to spare?”
The processor is no longer the bottleneck in the data centre
I have rarely had moments with other hypervisors where I stood back and said: “Gigabit Ethernet is dead.” My high-demand VMWare systems, however, constantly remind me of this truth.
Except for some very rare corner cases, the processor is no longer the bottleneck in the data centre. I/O is.
In this brave new world, he who can shuffle bits around the quickest wins. Being the best at coping with this I/O bottleneck is what allows VMWare to get away with anything it wants – for the moment, at least.
Some of the systems I am running are two and even three years old. Their replacements will be able to house even more virtual machines and chow down on even more bandwidth.
My Christmas list now reads: "Dear Santa, I would like several gold bars, a pony and a crate of Intel 4up 10 Gigabit Ethernet NICs. I am going to need them."
When contemplating the conundrum of VMWare's new licensing, I find I have four choices.
I can choose to port my virtual estate to a competitor and accept that the I/O limitations of its hypervisors impose practical limits on how many virtual machines I can cram into a single host. Competitor offerings are also far less feature-rich, but even at the top end they are significantly cheaper.
I can stick with VMWare’s free hypervisor, but this will see massive server sprawl as I constantly run up against the 32GB server barrier.
I can choose to run a hybrid environment, keeping the high-I/O stuff on VMWare and migrating everything else to competitors. Or I can just pay the tithe.
Whichever path I choose, one thing is abundantly clear. Whether we are talking hypervisors, networking, storage or any other aspect of modern server design, I/O has become the primary consideration.
Great news if you make hypervisors, storage or networking gear. Less so for my wallet. ®