Starting a virtualization project requires planning and preparation, especially when it comes to server consolidation -- the critical first step toward a virtualized environment.
Quantifying your virtualization project’s goals
A well-executed server consolidation project reduces the number of servers, which can minimize investments in hardware, hardware maintenance, data center space and energy use -- both in terms of electrical power that servers consume and electrical power that cooling systems consume.
Virtualization can also shorten the implementation timetable for new servers running mission-critical applications, which leads to indirect cost savings and increased revenues for businesses the data center supports. IT staffers can create virtual machines (VMs) in just a few hours to answer requests for new servers.
While all of these benefits are important to businesses, it’s difficult to put a dollar value on them in your virtualization project plan. It’s even more difficult to verify their value after installation and deployment, especially since no standard method to measure this value is available. Direct savings are easier to quantify and are generally sufficient to justify a move to a virtualized environment or the expansion of an existing virtualization project. A systematic and phased approach to your server consolidation project -- data collection, analysis as well as migration preparation and implementation -- will ensure that your virtualization project reaps all the important benefits.
Phase one: Data collection
The first step in planning a server consolidation project is to get a complete and accurate picture of the contents in your data center. This should include not just a physical inventory of all servers but also an exact description of what is installed on each server -- the operating system, middleware, and the application or database that the server supports. The data collection phase typically accounts for about 75% of the total server consolidation project planning.
Gather data for your server consolidation project from the following three workstreams. Some of the data collection can take place concurrently:
1. Compile information about the current data center environment, including the following:
- An inventory that covers each server’s make and model, serial number, physical location in the data center, date of manufacture, hostname and IP address. You should also include server resources such as CPU details, memory and network interface speed.
- A software inventory for each server listing the installed OS and version as well as middleware, including database management systems like Oracle or Microsoft SQL Server, and Web server software such as Apache or Microsoft IIS.
- A catalog containing a complete list of all applications and databases the data center supports. This should include apps developed in-house, purchased enterprise-specific software and generic apps like email. The catalog should also have contact information for members of software development and support teams who are responsible for each application and database in your virtualization project.
- Application/server mapping and database/server mapping for each app and database, as listed in the aforementioned catalog. Include a list of all “instances” of the application/database and associated details. In some cases, data center records may not include all necessary instance-mapping information. If so, gather this information later in the server consolidation project.
As you continue this part of your virtualization project plan, obtain performance metrics for all existing servers, or ask IT staff to create them if they don’t exist. These metrics should include resource-utilization levels for the CPU, memory, storage and network interface. Values should note any peaks in resource demand on a daily, weekly and monthly basis. Report these values at least every two weeks; straddling the end of a month can be very useful.
Routinely running these reports can reveal usage growth trends and identify high-demand applications. Because performance data is required for a period of several weeks, begin collecting data as early in your server consolidation project planning as possible. Run appropriate tools to collect this information. For example, use the Windows Reliability and Performance Monitor, a Microsoft Management Console snap-in for Windows Server 2008 that includes numerous reporting and logging features.
2. Interview application and database owners. For each application and database in the catalog, conduct interviews with appropriate development and support staff. These structured questions are intended to help your virtualization project plan:
- Update information about the application and/or the database, which is often incomplete.
- Become aware of plans for the application or database. For example, a database may be scheduled for decommissioning, replacement or a major overhaul.
- Understand if the application or database can run in a virtualized environment, including any ways in which an app can “behave badly” or be the subject of special regulatory requirements.
- Find out which versions of the OS the application should run on and which versions it has been tested for. Admins may try to move as many applications as possible onto the same version of each OS for manageability. This is not an essential part of the server consolidation project because you can build VMs that run several versions of an OS, but it is an opportunity to reduce the complexity of data center operations.
- Learn if the license keys for purchased software are tied to the server and how to obtain updated keys when moving the application to a new server, particularly to a VM.
- Obtain details of application-to-application and application-to-database dependencies.
Enter all of these results into a server consolidation project database -- ideally Microsoft
Access, SQL Server or Oracle. An Excel workbook is also adequate for smaller workstreams.
Table 1 illustrates the structure of a typical database for a server consolidation project. It gives you an idea of the number of data elements that are typically collected for each server, application and database. For larger data centers containing 1,000 servers that support numerous applications and databases, the consolidation database could contain more than 30,000 data points -- not including server performance data.
Table (or worksheet)
Number of rows
Typical number of columns
||Server ID—server hostname or other unique ID
||One per server||
||Application ID—generated by the project team if there is no unique
naming scheme in place
||One per application||
||Database ID—generated by the project team if there is no unique naming
scheme in place
||One per database||
||Application ID, server hostname
||One per application instance||
||Database ID, server hostname
||One per database instance||
|Daily server performance
||Server ID—server hostname or other ID
||One per server per observed day||
|Monthly server performance||Server ID—server hostname or other ID||One per server per observed month||
Note that the number of application instances or database instances appearing in the application/server mapping or database/server mapping tables is typically four to five times the number of applications or databases in the environment. Generally, there are three or four instances of each application and database within production and test and development roles.
In these stages of your server consolidation project, it’s common to discover that a few applications and their underlying databases co-reside on one server. In these instances, the same server will appear under both application/server mapping and database/server mapping. It may be useful to flag these cases by including a “combo server” column in the mapping tables, where a value of “Y” in that column indicates this co-residency. In addition, if some servers have been virtualized previously, include columns to record this.
With phase one of the server consolidation project under your belt, you’ve got all the server
data you need to keep plugging away at the overall virtualization project plan.
About the author:
Malcolm Hamer is an IT consultant and director at Acumen Solutions Inc., a business and technology consulting firm. Prior to that, Hamer has 20+ years of experience working in technology for global telecommunications organizations, the banking sector and the securities industry. Hamer is co-author of Telecommunications: a Systems Approach, Telecommunications Systems and Telecommunications Users’ Handbook. He also writes articles and frequently presents on a range of IT topics.
This was first published in August 2011