Planning The Virtualisation Journey

Virtualisation is a term that has been around for a good number of years – first in the mainframe space and (more recently) in areas like storage, server, network and desktops. Virtualisation today touches almost every aspect of a standard technology implementation. Virtualisation involves more than just consolidating multiple physical servers onto a single platform. Like any other IT initiative, the virtualisation architecture needs to be properly planned to ensure adequate Return on Investment (RoI).

Typically the journey begins by planning not only for the actual virtualisation or consolidation, but more importantly the complete environment that includes virtual servers, virtual networking and storage for those servers, and a management environment that facilitates effective management & operation of the environment. While each aspect of virtualisation is too large a topic to be covered in a single post, as a first step, this post specifically talks about server virtualisation.

More from Biztech

Future Group - Reliance Retail Deal approved by CCI RBI ban on cryptocurrencies takes effect; prohibition could force investors to tap the black market

Regardless of the size of the business, server virtualisation can lead to definitive cost and performance benefits – both explicit and implicit. Explicit cost benefits would include lesser number of physical hosts to be procured resulting in lower capital cost, consolidating workloads onto lesser number of hosts leading to lower software license, and implicit would include the savings accruing to lower space requirements, lower power and cooling needs for running the same number of applications. Of course, management costs also reduce!

Essentially server virtualisation entails installing a layer of software (typically called a Hypervisor) as the base Operating environment on a physical host (server). Commonly available hypervisors include VmWare VSphere, Microsoft Hyper-V, and Citrix Xen. Virtual machines with their own CPU processing cores, dedicated RAM, disk space, and network interface controllers can then be created using bundled management tools having simple point and click interfaces. Each virtual machine then behaves like a physical machine – on which appropriate server operating systems can be installed and used.
So, applying the above concepts to an environment running physical servers entails the following key considerations:

Choice of virtualisation platform: There are multiple platforms available and almost all of them offer a ‘try-before-you-buy’ edition. Each would have its own strengths as well as plethora of management tools (both owned and third party). Basic virtualisation features are normally available in a scaled down, free edition. After the trial is concluded comes the issue of licenses. Typically these licenses are server based – depending on the number of processors and number of cores on a processor. Basic Management tools are in-built, but for managing a larger (read greater than 3 in case of VmWare) number of hosts, one needs to purchase a priced edition of the tool. Annual support/maintenance costs apply post the initial purchase.

Environmental requirements: Simply virtualising is not enough – unless the environment (specifically network & storage) is complementing. With respect to network an important part is having high speed links to the host servers. Typically a Gigabit Ethernet network with multiple links to servers is recommended. This should ideally be complemented by a well-planned underlying storage layer – either a SAN or NAS device that is connected through a high-speed fibre channel. Together these will maximise throughputs resulting in better user experience as well as provide flexibility for overall storage. One needs to remember to provide adequate headroom in allocating storage since the host would also need some storage overheads to keep system snapshots.

Application testing & performance: While converting a running physical server to a virtual one is a fairly easy task and tools are available to do this conversion, before converting, one needs to ensure that the ISV would support the application in a virtualised environment. Once converted, however one has to do extensive testing on the virtualised applications to ensure no performance dips and/or functionality losses. Generally each physical host would move to a higher utilisation level and overall performance should increase. However, one has to do capacity planning & sizing keeping in mind peak processing load requirements. Most important, one has to avoid keeping all instances of a particular function on the same host (for example, putting primary and backup domain controllers on the same host.)

Backup: Most implementations would treat backup of a virtual machine at par with the physical counterpart and wish to replicate their backup strategies and software in the new environment. However, this is not always advisable. Since the entire virtual machine (VM) contents essentially resides in a single (large) file, backups can be taken at the virtual machine level – which would provide bare metal recovery in the event of a host failure. However, this method is not the most suitable for file level / application level recovery. Current ISVs offer specialised backup / restore solutions for virtualised environments. VmWare in fact, in its latest edition (v5) has removed the VCB (VmWare Consolidated Backup) facility from its product suite and instead has provided a set of APIs into which various backup solutions can integrate.

Disaster Recovery: While most server class machines currently available have a fair amount of redundancy and fault tolerance built-in, depending on the business criticality, one would want to look at multiple host servers. Regardless of redundant components, if only one host server exists and that fails, every virtual server fails. Therefore a consideration is to have at least one (or more) additional host servers so the virtual machines can be moved from one server to the other if needed. If high uptime is critical, one should consider the high-availability options found in these platforms. These solutions will automatically move virtual servers from one host to another in the event of a complete physical server failure.

Security: One crucial thing to remember is that in a virtualised environment – especially with self-provisioning of new VMs, it is very easy to create ‘server sprawl’ where one loses track of exactly how many VMs are running in the environment – thus impacting security. Such machines often slip under the radar when it comes to patch deployment / system hardening. And it takes just one unpatched machine to get compromised that has the potential to jeopardise the entire setup. It is a good idea to maintain an automated patch management solution in virtualised environments besides a robust server change control process.

If these considerations are kept in mind in planning a server virtualisation initiative, it would definitely exemplify Murphy’s law “In theory there is no difference between theory and practice, but in practice there is.”