Many business’s IT infrastructures are based around this set up, with the operating system bound to a specific set of hardware and a specific Application bound to that OS. From there the server runs at about 5-10% of its capacity for most of the day with it peaking only during heavy usage. The data has to be backed up to a local SAN for recovery purposes, generally needing special software to be employed to ensure its being backed up fully and efficiently.

If this is a vital server and has a disaster recovery and business continuity plan implemented with it to ensure that downtime is kept as low as possible, then it will have an identical server installed for failover. This server is only used if the original server fails, but is still uses power and space. Not only that, but this server has to be the same identical model, containing the same hardware configuration, firmware, and local storage to ensure immediate complete compatibility with the original server. This adds cost as you need to have a second set of the hardware and it has to be that same model, limiting upgrade paths for the business.

This set up generally falls into the “Boot and Pray” model of disaster recovery, as the complexity of the set up causes the admin to hope that it works rather than being able to guarantee a smooth transition from server. This has to be done with every vital server that needs to have a redundant back up and each one has its own unique set up, creating a large amount of complexity that is involved with managing all these different machines. This complexity increases the company’s RTO and RPO and makes recovering a much larger ordeal.

VMware’s solution involves turning each server into a VM (Virtual Machine) this VM is a container which holds all the files needed to run and operate the server. VMware uses its software to create a layer between the VM and the physical machine, basically tricking the server software into thinking it’s still running on its original machine when in fact VMware is mapping the virtual hardware to the physical hardware. Utilization rates jump from 10% to 70% as multiple VMs can now be ran on a single server and moved to another one if they need more CPU utilization. This also allows it to remove the need to have local storage in the machines as each VM, which is a container file, can be stored on a local SAN and sent to specific server as needed. Having the storage on the local SAN now makes backups much easier as now they are copying a single file to ensure it has a backup copy, versus employing third party software to copy every file manually to a second storage solution.

With VM’s in place, the need for having identical hardware for each server is eliminated as this virtual translation layer allows the server to be booted from any server regardless of configuration. Having this feature allows IT to buy from any vendor and lets them buy more powerful machines instead of being forced to replace old machines with identical hardware; it also lets them repurpose old hardware that was going to be retired into backup servers. Having the ability to move the virtual server to any physical server reduces the RTO and RPO as now the complexity of managing the set up is reduced and so is the likely hood of not being able to boot the backup server when you need it most. Finally costs are reduced as now there is less hardware needed, space used, cooling and power needed. It also allows IT staff to work on more pressing matters as the need to monitor and check the back ups are decreased from having less physical machines.