Reality IT: Server Consolidation Takes Time

No matter what you may hear, an initiative like this is not as straightforward as it seems. And smart IT people know enough to take their time--or risk making a

February 11, 2005

3 Min Read
NetworkComputing logo in a gray background | NetworkComputing

What this all boils down to is one tall order: a "forward" server consolidation for the new projects and a "backward" server consolidation for the upgrades and migrations.

Spearheading the initiative are data-center manager Marvin Mips and network manager Dirk Packet. Marvin and his team own our larger servers, which include various Unix and other non-Wintel boxes. Dirk and his crew are responsible for Wintel servers, even though most of those boxes live in the data center owned by Marvin's staff.

Honkin' Big Servers

When we began evaluating our server options for the consolidated environment, we focused on 16- and 32-way boxes. We would need multiples of each. We have great relationships with our server vendors, and they were salivating after hearing our plans. Marvin and Dirk checked the market, talked to peers, studied analyst reports and narrowed down their list of manufacturers. The vendors agreed with us that consolidation made sense.

Our utilization reports also confirmed this direction. Have you ever noticed how little of your servers' processor and memory are actually used? The consolidation would let us make better use of processing power and combine multiple enterprise applications on each box. Apart from the objections of some software vendors, who don't like to share server power, Marvin and Dirk saw no reason not to push ahead with the project.For me, the consolidation also meant more centralized management and monitoring, as well as better use of resources. And the larger systems came with excellent vendor support, including remote monitoring and real on-site support teams when needed.

My IT security manager, Bucky Rogers, was worried about putting all our server eggs into one vulnerable basket. The vendors promised solid solutions for separating virtual and physical server slices, but Bucky did his own research to confirm that we wouldn't cause a monumental security vulnerability.

There were a few other considerations. Where would the new servers go? We had plenty of room following our recent move to a new computer room. What about storage? We knew we'd need a SAN, and we had budgeted for it.

We considered a blade server alternative but decided against it. Marvin wanted true server consolidation, not just individual servers in a blade enclosure. And Dirk didn't like the idea of deciding which applications would fit onto what blade.

Dig DeeperAfter making our architectural decisions, we moved beyond slide presentations to more detailed talks with vendors. Some helped Dirk and Marvin research specs for the new applications and collect data on the performance of existing boxes. We considered the need for growth. We pored over complex vendor spreadsheets to determine which servers and apps could be consolidated. We left nothing to guesswork.

As I write this, we are still working on our consolidation plan. No matter what you may read, an initiative like this is not as straightforward as it seems. It involves a high level of complexity and extremely detailed planning. Don't get me wrong--we can't keep adding a pizza box server here and there forever. But server consolidation takes time. And smart IT people know enough to take that time--or risk making a big mistake.

Hunter Metatek is an enterprise IT director with 15 years' experience in network engineering and management. The events chronicled in this column are based in fact--only the names are fiction. Write to the author at [email protected].

Read more about:

2005
SUBSCRIBE TO OUR NEWSLETTER
Stay informed! Sign up to get expert advice and insight delivered direct to your inbox

You May Also Like


More Insights