There aren’t many reasons not to virtualize servers in your storage environment, but there are plenty of compelling data protection reasons to go ahead and virtualize them all.
So, is it exaggeration to say all servers should be virtualized? Not at all. And I’m serious when I say every single one. There are very few exceptions to my rule, with the biggest, most legitimate exception being the need for the OS/application to interact directly with hardware, such as a USB key, tape drive or peripheral. With modern compute hypervisors showing so very little latency in I/O performance between physical access to resources and virtualized resources, it’s not an excuse for 99.99% of us to stay physical due to performance concerns or CPU/memory requirements and so on.
Even if you have a single app running on the OS as the only server in a building, it should be virtualized so the only thing running on the metal is the hypervisor. Perhaps that’s why even the Standard license of Windows Server OS allows for one physical OS instance and one virtualized instance at no additional charge. Let’s discuss why.
Rebuild-ability. The biggest pain of any server restoration is what used to be referred to as “bare-metal recovery” (BMR), whereby one has to install a new, clean OS before installing the backup mechanism, and before starting the actual restore of the real OS, applications or data. Instead, BMR functionality enables one to create and then leverage an image-based restore of the primary partitions. This is so critical that as the Windows built-in backup utility has “evolved” (some say devolved), its System Image function is essentially a built-in BMR utility. The challenge with most BMR approaches, and a real differentiator of backup products in the early 2000s, was the ability to restore a BMR image onto dissimilar hardware using mechanisms that most of us believed were voodoo and fairy dust (unreliable and always suspect). Instead, a virtualized server is portable, with a generic set of CPU, memory, network, display properties and storage conveniently wrapped up inside of virtual hard disks (VHDs) and VMDKs.
That rebuild-ability solves the BMR hassle, and enables several other data protection scenarios that are predicated on servers being self-contained, hardware-agnostic and “portable” objects.
Migration. Have you ever outgrown your hardware? Of course you have. But in a virtual world, instead of building a new server and migrating the data and server configuration, you can simply move the virtual machine (VM). In many cases, the hypervisor host has more resources than what the VM originally was configured for (or was using), so a two-minute-or-less bounce to shut down the VM, add virtual resources (CPU/memory/storage) and then boot up is all that’s required. If you’re relocating, both major hypervisors allow for a live migration, usually without any downtime. And, after all, data protection is about ensuring productivity and avoiding downtime. Migrations are just planned downtime, but downtime nonetheless, and another data protection scenario that virtualization offers a solution for.
Business continuity (BC)/Disaster recovery (DR), including DR as a Service.Nowhere is portability more coveted than in BC/DR scenarios that are typically based on the assumption that a calamity has struck and the business is down until its IT assets are restored. In those scenarios, it’s likely you’ll have different hardware (whole environments) and very little time. So,bringing up VMs on alternative hosts or within a cloud-based host is just so easy that it would be imprudent not to do it.
Rollback and snapshotting. While physical servers often require specialized storage capabilities to do snapshots, VMs can be snapped easily from the hypervisor management user interface (UI). In some cases, the VM-management UI may be calling underlying software-defined or hardware-enabled functions, but in other cases (e.g., Hyper-V) its “snapshot” is effectively stitched out of differencing VHDs behind the scenes. However it’s enacted, the phenomenal ability of right-clicking a VM and rolling it back to a previous version as easily as rolling back a Word document is too powerful not to have as part of your data protection and recovery strategy.
There are likely other virtual server data protection scenarios I’m overlooking right now, but (hopefully) you get the idea. Unless you have VMs that require interaction with physical peripherals, you’d be hard-pressed to convince me that not every server should be virtualized — even those simple 1U, single-purpose boxes in your branch office or small business.
[Originally posted on TechTarget as a recurring columnist]