Friday, May 7, 2010

Ready, Fire, Aim Provisioning

After the initial implementation, provisioning is often done on the fly, as application managers quickly learn the benefits of not having to wait for a new physical server in order to start a new application. With this method of provisioning IT simply responds to the needs of the application owners without taking the time to question those needs. Or in some cases, the application owners are allowed to provision VMs on their own. In either case, this leads to a massive expansion in the VM population - VM sprawl. As we discussed in our article "Managing VM Sprawl", this condition not only often leads to wasted resources, it also puts pressure on the backup and storage services that are supporting the virtual infrastructure.  At that point there is a sudden rush to create spreadsheets that track and document the virtual infrastructure.

Ready, Aim, Aim, Aim, Fire Provisioning

At the other end of the spectrum is a very detailed provisioning process that requires a series of emails back and forth between the application manager requesting the VM and the VM administrator. In some cases organizations have "automated" this process by capturing the key information into a spreadsheet that the application manager fills out. The challenge with this process is that many times the information is not complete, either because the requestor doesn’t know the answers or assumes that it doesn't matter. This leads to the constant back and forth trying to establish what the VM should look like.

Even after the information about the new VM has been successfully captured the work of actually creating and monitoring the virtual machine has to be accounted for. Beyond the actual work of implementing the VM the virtual administrator has to advise the application manager that it’s ready and available for use. Finally, these systems must be monitored to try to identify idle or orphaned VMs, which is the core of the VM sprawl problem. The net result of this over-management is increased provisioning times. For some customers this time can quickly creep up from instantaneous (which users expect) to a few weeks from the point that the initial VM request was made. 

The Provisioning Workflow

A balance between these two extremes needs to be struck in order to maintain data center flexibility and responsiveness, while also maintaining order and control. The goal of VM provisioning products like Vizioncore's vControl attempt to strike that balance by making VM provisioning a workflow instead of a series of loosely related tasks.

Typically, the application owner will start the virtual machine request process by completing a form ,often through a web portal. This form, like other web forms, can be set with required and custom fields. It also can have an expiration date on the server so that temporary VMs, like those for test or labs,can be de-provisioned when the time is right. Once the form is filled out the VM administrator will receive a notification that there‘s a new VM request pending. Then, they can review the information and either approve or reject the request from there. Once the VM has been approved the administrator can allow the software to execute the actual creation of the virtual machine based on the parameters agreed to via the portal. This execution step is a critical function and the virtual administrator should confirm it is available from the software supplier. If the virtual administrator has to configure the system themselves there is no need to move beyond the use of a spreadsheet.

The value in using a software tool to automate the provisioning process is that it provides the perfect ‘ready, aim, fire’ balance to running a virtual infrastructure. As a result of these tools, provisioning times are greatly reduced but also, provisioning is done in a completely controlled process with the virtual administrator’s oversight. VMs are created as the application managers want them but in a consistent fashion to the rest of the VMs.

George Crump, Senior Analyst