A server consolidation project begins with data collection: gathering server statistics and resource requirements...
so you can determine the server consolidation ratio. Then, the goal of the analysis phase in a server consolidation project is to create a complete definition of the consolidated end state.
The target end state will be represented in the following ways:
- A list of all servers that will exist after the server consolidation project is completed, including servers that will be retained and new ones that will be purchased.
- The number of virtual machines (VMs) that will be created on each server. Some servers may remain as standard servers, without virtualization software installed on them. These servers will host a single application, a single database or a combination of the two.
- The exact placement of each application and database instance in this virtualized environment, including the physical server and, except when a dedicated nonvirtualized machine is used, the VM where the application or database will reside.
Which servers should you keep?
Your first activity in the analysis phase of the server consolidation project is to identify which servers to retain in the new environment, so you can plan the server consolidation ratio. Base this on a review of the characteristics detailed in the server consolidation project table -- CPU, memory, network interface.
You might decide to upgrade some servers by, for example, adding memory. Once you have listed the servers that will be retained, you can assign simple codes to them (E1, E2, E3 and so on) to facilitate subsequent steps in the server consolidation project.
Then you can begin the main analysis task: assigning each application instance and database instance to a physical server in the end state. If you have several hundred, or even thousands, of servers listed in the project database, this may seem like a daunting task. Certain assumptions, however, can help you dramatically reduce the number of choices and better plan the server consolidation ratio. It’s not unusual to complete the analysis in as little as three hours for a server consolidation project that involved two months of data gathering.
When choosing applications or databases to consolidate on the same physical server -- in separate VMs, of course -- here are the application consolidation objectives:
- Do not exceed a reasonable number of VMs on each physical server. For example, you may need 10 VMs for production servers but fewer VMs for test and development instances.
- Virtualization software can support more than 200 VMs per server. However, you should avoid such a concentration of production instances on one physical server because this would create a single point of failure.
- Do not overload physical servers. Be sure that the sum of the demands of the individual applications on CPU, memory and network connectivity is within the machine’s capabilities.
To meet the previous two objectives in your server consolidation project, mix heavy-load and light-load applications or databases on each physical server. Placing several light-load applications that efficiently use server resources would go against the first goal of application consolidation. And if you use a few heavy-load applications, you would run the risk of poor performance during peak usage times across applications.
Utilities like the Application Consolidation Tool (ACT) from Indus IT Valley in St. Louis can help you streamline application-instance tracking. Other third-party services can help you plan for application consolidation. If you approach the identification process without tools, the traditional method is to extract this table as a Microsoft Excel spreadsheet that contains one row per application/database instance. You’ll want to omit all apps and databases that are scheduled for decommissioning during the server consolidation project. Your application consolidation spreadsheet should contain the following column names:
- Application ID/database ID
- Current server ID
- Green zone (start day/time and end day/time)
- Workload factor
- Workload class
- Special cases
- Physical server assignment
- VM number
The first two columns uniquely identify each application/database instance on its current server. Items from the role column onward are attributes of that application/database instance.
Workload factor is a percentage that describes the load that an application instance or database instance will place on the end-state server on which it will reside. Workload class is a broad classification of an application/database instance that you derive from the calculated workload factor and other similar measurements.
The special cases column should contain critical information about the application or database. This application consolidation data comes from the data center’s records or previous interviews; you’ll need to take any special cases into account before making final decisions about your server consolidation project.
In the physical server assignment and VM number columns, you’ll enter a code (such as E3) to identify the physical server where a group of applications or databases will reside. VM number identifies the specific virtual machine on that server. Once you designate all existing servers that will be retained in the end state as E1, E2, E3, etc., you can assign new servers with codes like N1, N2, N3 and so on.
To easily determine which instances to assign to each physical server in the end state, combine the application/database instance review table and some sorting and manual row selection. You can adapt these five general steps to suit your organization’s server consolidation project.
1. Sort the instances according to special cases to separate application/database instances that must go on a dedicated server. Enter the server designation for each instance (E1, E2, E3, etc.) in the physical server assignment column. There is no value for the VM Number column, so put “NV” to indicate that it’s a nonvirtualized server.
2. Sort the remaining instances according to workload class, and assign dedicated servers to any instances that are “unsuitable.”
3. Group any instances that aren’t assigned to dedicated machines in previous steps according to role and the green zone. It’s a good idea to keep instances with the same role together on physical machines so that it’s easier to apply different standards and support procedures.
4. Select instances to go on each physical server from within each group of rows that share the same role and green zone. Your selection should contain a balanced combination of workload classes—two high, three medium and five low, for example. Verify that the sum of the workload factors adds up to at least 30%, but no more than 50% of the total workload.
Once your selection looks acceptable, enter the code for the next available server in the physical server assignment column. Then assign VM numbers (starting at 1) to each of the selected instances.
5. Repeat this process until you have assigned all instances within a common green zone. Continue assigning instances (roles and green zones) to physical servers and giving each a VM number.
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.