Virtual management - a lesson from history

On the desktop, two cores is better than one; background processes are now free to run about on a separate compute unit from your main task, but four cores is in many cases still a complete waste over two. Six cores, eight, twelve, sixteen… this is simply ludicrous when we start putting it under Alice’s desk for her to check her email and view a PDF. As a rule of thumb, I ask myself if a user would benefit from having more than two cores in their desktop. If the answer is no, they get a thin client and VDI. Some users I simply can’t justify pushing on to VDI; they need all the power they can get. In fact, we have users with spiffy quad core systems under their desk, and a virtual machine or two of their own, all of which they cheerfully flatten all day long.

On the server front we consolidate our servers from many into one in order to save money; whether in initial purchase costs, electricity or cooling. We drive up the utilisation of our servers in doing so, thus making them more efficient. We then end up running these smaller number of servers harder and hotter, resulting in more frequent component failures. ($15,000 server crashed by failure of ten-cent fan!) In response, server vendors offer us more complex and redundant servers and management software all of which are more power hungry and expensive. While virtualisation can save money in some deployments, improperly dealing with “eggs in one basket” by trying too hard to virtualise mission critical services can destroy any budget gains made.

Beyond just worrying about a single hardware failure causing multiple VM failures, you need to look at the power utilisation of properly designed servers. It’s easy to look at thirty servers or desktops with 600W power supplies and see that being collapsed into a single server with a 1400W power supply. What’s harder is asking yourself if all thirty of those systems needed enough power to require 600W power supplies in the first place. If you are considering consolidation through virtualisation, then the chances are the answer to this question is no.

The FTP server or spam filter for a small business is unlikely to need a 130W CPU with four DIMMs and RAID array. In fact you could probably shove it on a spiffy little Mini-ITX Atom board with a small flash disk, passively cool the whole thing and have it pull less than 60W. With no moving parts and judicious parts choices, you could cheerfully get ten years out of a system like that. It could just sit in a corner and sip power. In my experience, there are quite a few workloads that can be successfully “physicalised”. That is, moving the workload onto a dedicated piece of hardware that is tightly specified for the job. Little overhead for growth, ultra-low power consumption, but zero expectation that the requirements will ever change for the system doing that job.

Looked at another way, computing workloads are in many places moving rapidly towards becoming appliances. The general purpose PC, be it desktop or server is facing a crisis. There is little if any more single-thread performance to be had. This leaves us cutting up our systems either with parallelisation of our applications (not easy,) or with virtualisation. Virtualisation bears with it its own extra costs and complexity, so we respond by virtualising only what needs to be virtualised, and making simple appliances out of the rest. To make matters more complicated, everywhere you turn there is someone claiming to have found the “one true path”, with the “one true technology stack” that can solve all problems, cure all ills.

Utter bollocks. In trying to find a magical solution to getting decent power management out of the virtualised portion of my network, I came to realise that every chunk of software or hardware I dug up to solve my problems probably wouldn’t apply to most other networks. For this reason many of these solutions never made it into my VDI power management articles. I also came to the conclusion that there is absolutely nothing special about VDI. It is almost impossible to separate the issues surrounding its implementation from those surrounding the implementation of server workloads.

There are nifty software stacks that can do it all and make you tea, but they bear a heavy price. This price is not only that of the costs of licensing, but vendor lock-in. (Something my spidey-sense tells me is going to get to me much more of an issue in the coming decade.) For small and medium enterprises, these costs are so high that when you do the math to figure out what the cheapest solution to high uptime with virtualised systems is you don’t come up with hardware or software. The cheapest solution to these problems is still wetware. It seems that when trying to balance cost, power usage, performance and uptime considerations, there’s just no viable replacement for a well trained systems administrator who knows his network. ®