Everyone who has ever been a systems administrator or infrastructure manager has at some point experienced server sprawl. Over the past few years, technologies like virtualization, Docker and cloud services have come along to help address this challenge. Nonetheless, at some point either someone is going to say “do we really need all those servers? Surely there are at least a few that we can turn off?”
This article isn’t intended to stop server sprawl from occurring, but rather how to address it once it has occurred. While it may seem easy to just go into the data center (or VM console) and identify what can turn off and what needs to stay, oftentimes however, it isn’t.
1. What problem are you trying to address through server consolidation?
Like most projects, the scope on a server consolidation project can creep out of control if it is not managed properly. This is largely because there are several strategies that can be employed to reduce the quantity of servers in an organization. Because of this, it is critical to know what problem you are trying to solve first, and then decide on your consolidation strategy. Some common reasons to begin a server consolidation effort are:
- The administrative burden of several servers exceeds your staff’s capacity to manage them
- Two or more organizations have merged and there are too many servers performing the same functions
- To prepare for a move to a new data center
- Reduce cost of server operation
- To reduce the organization’s risk exposure
- To prepare for hardware lifecycle replacement
- Applications and their underlying infrastructure are ready for decommissioning.
2. Take inventory of all your servers (Physical and Virtual)
This seems like a no brainer, but I’ve been part of more than one project where additional servers were discovered as part of the consolidation project. It is incredibly important to understand the current state and quantity of servers for a given function, so that you can create a vision for the desired end state. Below is a sample of what each record in a server inventory could look like:
| Server Name | Function | Applications | %Utilization Estimate | Operating System | Security Level / Profile |
| NYC-SERVER1 | File Server | N/A | 85% | Windows Server | Confidential data |
| PHI-SERVER1 | LOB Application | Inventory Management | 50% | Linux | Confidential data |
It is important to not make this inventory more complicated than it needs to be in the beginning. While your technical teams will need to know things like external IP addresses, firewall rules, RAM, Storage, and CPU type, at this point you only need to know the basics. Once you have a basic inventory together, you can move on to categorization (for purposes of consolidation)
3. Categorize the functions of your servers
This is another one of those items that seems relatively easy. Every systems administrator groups their servers in one way or another. What is needed for a server consolidation effort is a consistent grouping system that is followed and understood by all project assignees. Below is an abbreviated list using two grouping methods within a grouping system. By having multiple methods within a grouping system, it is possible to evaluate consolidation opportunities in different ways.
| Function | Security Profile |
|---|---|
|
|
Grouping by Function
Grouping servers by function lets you evaluate consolidation opportunities based on similar workloads. By looking at one group at a time it becomes easier to evaluate what servers could be combined. With this method, ask questions like:
- Are all my servers in this grouping close to %80 utilized? If not, what workloads could be consolidated?
- Are any of my servers in this grouping overutilized?
- Is there business or application reasons to keep servers within a function separated? If not, does it make sense to combine them?
Grouping by Security Profile
Grouping servers by security profile allows you to incorporate risk management into your consolidation effort. It also provides a check and balance to your function grouping to help ensure you don’t create security problems by consolidating server workloads.
By grouping servers together based on security profile, you can ask questions like:
- Should all my servers in a security level be kept together?
- Does it make sense to consolidate “server 1” and “server 2” if they have different security levels?
- Can I reduce my cost of risk management by isolating the most private servers and increasing the security controls on just these servers?
4. Look to cloud options
Moving to the cloud can have a significant impact on your overall consolidation effort. There are many workloads that can be redesigned to leverage the advantages of moving to the cloud. However, if your focus is server consolidation, and you are looking to take your first steps into the cloud, collaboration suites and storage are a great starting point without having to invest too much development time. Office 365 and GSuite (and others) can significantly reduce the number of servers in your organization by eliminating the need for email and file servers.
Other great options for moving to the cloud are any client server applications that you have purchased over the years. Most software providers now have cloud options as well as professional service offerings to move from your on-premises version to the cloud version.
If you find opportunities to move in-house developed applications to the cloud, great! However, I highly recommend treating these efforts as separate projects that stand on their own. More on this later.
5. Virtualize everything that’s on-premises
I’ve been involved in virtualization efforts since the early 2000’s. There was a point in time where it was considered bad practice to virtualize databases and domain controllers. However, modern virtualization solutions make these old arguments irrelevant. A properly architected virtualization solution will allow you to virtualize almost every server you are hosting on premise without fear of a server apocalypse. If you provide adequate resources for your virtual machines there is no reason to keep physical servers around anymore (except for the hypervisor hosts, obviously). A fully virtual environment will also allow you much more flexibility with your server consolidation efforts.
6. Write your Consolidation Plan
Now that you know what you are trying to achieve, have grouped your servers, evaluated cloud options, and virtualized as much as possible, you are ready to write your consolidation plan. How you write your plan will be different for every organization. However, at a minimum your consolidation plan should have the following sections:
- Background / What problem you are trying to solve
- Current server count / cost
- Future Server count / cost
- Timeline for consolidating moving servers
- Which servers will be decommissioned
- A section on what success looks like at the end of the project.
- Sign off from senior IT management
What to Watch Out For
Any time a server consolidation initiative involves an application redesign, it’s a major red flag. I’m not suggesting that application redesigns are bad, or that organizations should not redesign an application when there is an opportunity to find efficiencies. I’m suggesting it’s a bad idea as part of a server consolidation project. Here is why.
Most application redesigns involve spinning up new servers to host the new redesigned application. In larger environments, this includes development, test, and production servers. Then the application developers should design the new system, perform all the testing required, and then move production to the new system. Next, the old environment must be decommissioned, which includes determining the disposition of the data in the old system, if not all of it was migrated. There are just way too many variables in an application redesign for your server consolidation project to depend on it. I’ve even seen the server count go up instead of down when application redesign is part of server consolidation.
Again, I want to reiterate, it’s usually a good idea to redesign applications when there is an opportunity to leverage new technology or reduce the resources consumed. However, an application redesign project should stand on its own and be a separate project from your server consolidation.
