Kicking ESX Host Hardware Standards Down a Notch

The hardware vs software race is becoming more and more a hare vs tortoise these days, with the advent of multicore. And you can understand why – concurrency is hard. _Very_ hard. But oddly enough, I don’t see much on the intertubes about people changing their hardware standards, except for the odd bit of marketing.

Although the HP BL 495c is in some respects an interim step to where we really want to go (think PCIe-V), the CPU / memory design of the blade is pretty much spot on. That is, as more cores become available, we should be moving to less sockets and more slots.

I’m not going to entertain the whole blade vs rackmount debate. I totally understand that blades may not make much sense in small shops (places with only a few hundred servers). I probably should change the description of my blog… I only talk enterprise here people. Not small scale, not internet scale, but enterprise scale (although to be honest a lot of the same principles apply to enterprise and internet scale architectures, on the infrastructure side at least).

The next release of VMware Virtual Infrastructure will make this even more painfully obvious. VMware Fault Tolerance was never designed for big iron – it’s designed to make many small nodes function like big iron. OK, so maybe the hare vs tortoise comparison isn’t really fair with regards to VMware ;-).

But this doesn’t only apply to ESX host hardware standards – it should apply to pretty much any x86 hardware standards, _especially_ those targetted at Windows workloads. We’ve seen it time and time again – even if the Windows operating system did scale really well across lots of cores (and it won’t until 2008 R2), the applications just don’t. We only need to look at the Exchange 2007 benchmarks that were getting attention around the time of VMworld Europe 2008 for evidence of this. If Exchange works better with 4 cores than it does 16, you can bet your life that 99.999% of Windows apps will be in the same boat. Giving your business the opportunity to purchase the latest and greatest 4 way box will do nothing but throw up artifical barriers to virtualisation. The only Windows apps that require so much grunt are poorly written ones.

So if you haven’t revisited your ESX host hardware standards in the past year or so, it’s probably time to do so now, so you can be ready when VI.next finally drops. Concurrency may be hard, but I wouldnt call distrubted processing easy either – the more the underlying platform can abstract these difficult programming constructs, the more easy it will be to virtualise.

Advertisements

Tags:

2 Responses to “Kicking ESX Host Hardware Standards Down a Notch”

  1. Wharlie Says:

    Can you please explain “VMware Fault Tolerance was never designed for big iron”, I’m not disagreeing, I’ve done a number of enterprise implementations that span both ends of the scale-up/scale-out spectrum and tend to agree with the scale-out approach. But it’s good to head in the right direction especially with regard to future enhancements.

    • admin Says:

      Hi Wharlie, what I meant by that is FT makes a few small boxes more attractive than a single big box. I have yet to see an x86 box that could take a CPU failure (or if there is one I don’t know about, how about a mainboard failure :). It’s probably less relevant to larger scale infrastructures that you and I deal with currently, but FT will make the decision between many smaller nodes vs fewer bigger nodes a little more interesting šŸ™‚

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: