Gallery

Virtualise your servers: storage strategy

Posted on 5 Jan 2010 at 14:41

Jon Honeyball considers storage in the final part of his guide to virtualising your servers

On our journey of migration from a wholly local server environment to one based completely on virtualised technologies, it’s time to look at storage.

We've already moved the servers moved from real tin to running within a virtual machine, hosted within a hypervisor that itself runs on the real tin. But storage is a topic we can’t avoid. You need to do some careful thinking at this stage and wrap your head around some new concepts.

When we created those virtual machines, we used local storage on which to store the VM images. If we were running Hyper-V, then the disks would be formatted as NTFS and the VMs would be stored in the Microsoft virtual disk format, while if we were on VMware the disks would be formatted in VMware VMFS format and the virtual machines would be stored within that.

I must now interject and say this is the point at which you ought to decide to go for properly set up hard disks.

In my HP ProLiant DL380 G5 servers, I have eight 2.5in hot-plug drive bays on each front panel, accompanied by a serious hardware RAID controller inside the box. I take one pair of 36GB 15,000rpm hard disks and mirror them via this controller, and this array is used to contain the boot volume in which sits the hypervisor ESX.

A second pair of 146GB 15,000rpm hard disks are then set up as another pure mirror, and this second volume is used for storing those VMs that will be held on the machine itself. I like this arrangement as I can fit another two pairs of hard disks, both mirrored, to fill up the remaining four hot-swap slots, and I get the opportunity to decide how I want to partition this data storage for an appropriate degree of fault tolerance.

Be very clear that all your server disks in this environment need to be mirrored at the very least, and mirror the mirrors if you’re really paranoid.

Set up your hardware RAID controller for hot-swappability if that’s a requirement. On no account scrimp or save on these disks and controllers: they’re the core of your virtual server environment, and any unmanaged failure there will take down more than just one server.

If you have two or more of this sort of server configuration, it’s possible to move an entire virtual machine from one to the other in case of failure or to balance loads.

This takes time because both VM image and file system need to be copied, which isn’t a terribly long process but is the reason why you’ll quickly want to turn to external storage to host the VM images themselves.

I've previously described how to wire up network-connected storage directly to a server using the iSCSI protocol and a proper iSCSI SAN (storage area network) box. What’s the point? For starters, all your storage is consolidated into one box and becomes immediately available to all your virtualised servers. This box is hopefully optimised for its role of delivering disk space, so look for things like RAID control, Gigabit Ethernet interfaces, a proper power supply, and hot-pluggable drives.

Many high-performance servers are deliberately designed to be computational VM servers and so make little provision for lots of storage, especially in the 1U size bracket – installing an external 1U iSCSI SAN box can bring that level of facility to your rack.

Download a year of Jon Honeyball's Advanced Windows columns by heading to our Free Downloads site