Is it the right time to virtualize?

Picture the scene. You’ve run your legacy infrastructure into the ground. You bought it six or seven years ago with a view to depreciating the hardware over four years, or perhaps even three, so it’s done its time and then some. Now it’s starting to get flakier than you can live with, and as your channel partner’s spares supply is now drying up you’re finding yourself searching eBay rather more than you used to. It’s time to renew the kit, and as you look around you see your peers, the vendors and people like me talking about how great virtualization is. But is it really time for you to virtualize?

The components

Before you can answer the question, you need to ask what you’re thinking of virtualizing. In the average infrastructure, you’re looking at three key components: the servers, the storage and the network. If your experience with virtualization is at the dipping-in-of-the-toe stage, the chances are that you don’t want to go for a big bang and do the whole lot together. Of the three, the one you wouldn’t want to consider virtualizing is the network infrastructure – at least not in the context of coming out with comments like: “I say, this Software Defined Networking lark sounds like a jolly wheeze”. You’re going to end up with some virtual networking, but that’ll be the stuff you’re obliged to do in the server world: stick with normal network kit for now.

This leaves servers and storage. There are two possible cases here: either you have a bunch of stand-alone servers with their own individual storage; or you have stand-alone servers that are already sharing virtualized storage. The bottom line is that if you want to virtualize your servers, you’ll want to be using virtualized storage – so if everything’s stand-alone in your legacy world you’ll need to scramble up a steeper learning curve.

Happily, storage virtualization is almost a commodity concept these days: there are so many vendors that you have loads of options for kit that’s very easy to comprehend, to configure and to scale as required. I’m not saying it’s trivial, but doing the storage along with the servers is definitely not twice as hard as just doing the servers on their own.

Hence you can focus on server virtualization: you’ll need to take the time to understand it and you’ll certainly benefit from engaging an external specialist until your internal expertise is up to scratch. Should you use VMware or Hyper-V? To be honest it’s entirely up to you, and many people I know simply go for one or the other through personal preference: while you could do an in-depth analysis of the pros and cons of each, in a run-of-the-mill installation you’re not going to do yourself a major disservice by picking the “wrong” one.

But is the time right?

Before taking the plunge, though, we should ask whether virtualizing is the way to go. As far as the maturity of the technology is concerned, though, there’s absolutely no reason not to do it. Commercial hypervisor platforms are incredibly mature, super-efficient and tremendously robust: virtualization technology came of age at least three years ago, probably more.

I mentioned the two best-known vendors of server virtualization: there are of course plenty of others. But we’re talking about taking a first foray into virtualization from a stand-alone world, which means we want stuff that is common, well known, supported by armies of vendors and specialist consultants. I’m gazing at the 2016 Gartner Magic Quadrant for x86 virtualization right now, and up in the top right-hand corner are those two well-known names; there’s a cluster down to the left, mainly in the “niche players” corner, which by comparison are also-rans. That’s not to demean them – there are some major name in there including Citrix and Oracle – but for a newbie in virtualization you’d be well advised to stick with the Big Two.

And don’t forget the non-computer systems

So yes, virtualization is mature enough for you to be doing it. And this fact is reinforced by the behaviour of equipment vendors who are known for selling noisy metal boxes but who will now sell you a virtual appliance instead. No more must you buy (say) a phone system that comprises 10U of metal boxes that sit humming in a rack: instead just download the virtual appliance and point the virtual platform’s GUI at it. Same with storage virtualization appliances, or Web gateways, or server load balancers. It’s no surprise: once a virtual world became at least as reliable as having a dedicated box to do something, the equipment vendors had no reason to make tin boxes any more. Building and shipping tin is costly, and each one you make has a tangible cost in parts and labour. A software appliance, on the other hand, is a “build once, sell many” concept.

So alongside the imminent task of virtualizing your servers, there’s probably other stuff you’ll want to spec into your hypervisor installation for later migration.

Don’t think it solves all your problems, though

Virtualization is mature, and for mainstream tasks it’s certainly my automatic choice. Because multiple virtual machines share a single hardware platform you can use the physical memory and processors much more efficiently: after all, in a non-virtualized setup you can hardly (say) use unused RAM in the mail server to bolster the database server’s performance.

But you still have to consider the design properly. Multiple virtual servers on a single physical platform prompt references to a cliché containing the words “eggs” and “basket”: you need robust, powerful, expensive kit to run a virtual setup, albeit that you probably need less than in a stand-alone infrastructure. You need to consider the lowest common denominator when you design the resilience. So if you have a need for always-on, automatic-failover systems then expect to spend big money on the advanced options that enable this, even if it’s only a few virtual machines that actually need it: in this respect you may end up building resilience that a bunch of your systems don’t really warrant simply because you have another bunch that do.

You also have to ensure you understand how all your networking is working. I said earlier that you’re not about to move to an SDN world, but your virtual server setup will have some elements of virtual networking – virtual switches and virtual firewalls being the obvious two. So you need to understand how networks work, what a trunk port is, how to configure stuff so it fails over properly when a link drops … all perfectly doable but something that takes brain power to comprehend if you’re to do it properly.

And consider virtualizing your virtualization

And the other thing I’d advocate is to use hardware to do what hardware does best. Just as I’d shy away from implementing an IP router using software (why would I do that when I can get hardware-based wire-speed routing for sensible money?), so I would recommend looking for hardware-based offerings for hooking servers together.

Imagine I’ve decided, for instance, that I’m going to implement my virtual cluster as two pair of four servers of a particular spec. My default position would be to go for pair of blade-based chassis, each with four server blades and maybe a pair of four-port 10GigE LAN cards. The processing oomph would be the same, but the interconnects between the blades would be faster than plumbing everything together through a LAN (chassis backplanes outpace external electric string) and the virtualization layer would ensure that only traffic that needs to exit the chassis will do so. And it’ll save power into the bargain too, and will need fewer LAN ports too (which reduces the complexity of the network).

It’s hard work, then

Virtual operation is non-trivial. It’s not just a case of buying some servers and whacking a hypervisor on them, and going from nothing to something needs assistance and learning. Concentrating multiple applications and appliances on a smaller collection of equipment increases the potential impact should a piece of hardware go TITSUP, so you need to be meticulous about understanding the alternatives for resilience and designing (and paying for) the right solution. Expect to employ third parties to help you, which of course will have a cost that may offset a chunk of the saving you’re making by procuring less hardware. Oh, and be wary of the trap that many companies fall into: it’s way too easy to right-click and select “New virtual server”, so I’ve seen organisations end up with almost as many virtual machines than they have employees and condemn themselves to sysadmin Hell.

So you need to be wary of your lack of maturity with regard to experience and knowledge in the field of virtualization. But if you’re suitably mindful of these drawbacks, is the technology mature enough? Is it time to virtualize?

Hell, yes.

This article was supported by Dell