This article can also be found in the Premium Editorial Download "Virtual Data Center: Rethinking virtual infrastructure network architecture."
Download it now to read this article plus other related content.
Lifecycle management is more complicated in a virtual infrastructure, and there are significant differences between lifecycle management in physical and virtual infrastructures.
In a data center, all machines have a lifecycle, whether they are physical or virtual.
In the ideal dynamic data center, physical machines are host servers only -- machines running a hypervisor to support applications within virtual machines (VMs) -- so that their lifecycle is greatly shortened and lifecycle management is simplified.
The process is simple: Get the machine, place it in a rack, install the hypervisor (if it isn't already there) and add it to your resource pool. Then, retire the machine once it has outlasted its usefulness. But for the VMs that run services and applications your end users interact with, lifecycle management requires a more extensive effort.
This lifecycle has four stages:
- Planning: Identifying and preparing machines for deployment.
- Preparation and deployment: Acquiring the required software, installing the operating system and the application, configuring the system and testing potential deployment strategies. This phase culminates with the deployment of the VM.
- Production: Change management, application optimization and system administration of the application within the production network.
- Retirement: Replacement or upgrade planning and removal of obsolete technologies and processes.
The lifecycle for VMs includes the same phases as those of a physical machine, but the timeline for the lifecycle -- especially the first two phases of the lifecycle -- is much shorter than that of a physical machine. Previously, you began by obtaining the hardware for the new server, configured it once it came in, installed the operating system, then installed and configured the application that provided the expected workload.
After that, you tested the system, assigned an IP address to it and possibly configured the network to support it. All this could easily take up to six weeks before a system was ready. Today, with the proper seed machines, you can provision a server much faster, sometimes in as little as 20 minutes.
This is because you can create preconfigured VM templates that that already include the OS and any standard utilities you use in your organization to create new machines. But you still need to take the time to learn and understand server applications before you can deploy them. For example, deploying a new Microsoft SQL Server VM or any other relational database engine in a VM should not be done lightly. This takes time and preparation.
This is one reason why you must rely on VM lifecycles. Another reason is to make sure that your virtual server infrastructure does not become unwieldy. It is really easy to fall into the VM sprawl trap when VMs are so easy to create. With a standard lifecycle process, you will control the urge to create VMs as needed, or you'll at least give them time-based policies so they will automatically be removed from the network once they are no longer required.
Although the provisioning process has a serious impact on the amount of work required to create new service offerings within VMs, you must still take the time to properly configure server applications. That's where virtual appliances can come in handy.
About the authors
Danielle Ruest and Nelson Ruest are IT experts focused on continuous service availability and infrastructure optimization. They are authors of multiple books, including Virtualization: A Beginner's Guide and the Windows Server 2008, The Complete Reference for McGraw Hill Osborne as well as the MCITP Self-Paced Training Kit (Exam 70-238): Deploying Messaging Solutions with Microsoft® Exchange Server 2007 for MS Press. Their newest work is a training kit for Microsoft exam 70-652: Configuring Windows Server Virtualization with Hyper-V. Contact them at firstname.lastname@example.org.
This was first published in September 2010