Want More Power With Less Hardware?

Listen closely to the vendor community,and it sounds like everybody is ditching their small servers and either consolidating onto a few larger machines or buying a bank of blades that can be more tightly controlled.

Consider server consolidation. We look at when to do it, how to do it, and when to leave your infrastructure as-is.

We wondered how rampant this consolidation really is. Turns out, here, too, it depends on whom you ask.

"Our research shows that companies really want to reduce the number of servers under management and up utilization rates," says Clive Longbottom, an analyst at U.K.-based IT consulting firm Quocirca, "This can be for many reasons — cost cutting at the hardware capital cost level, cost cutting at the management level, lowering of real estate needs for server farms, consolidation of localities (bringing remote servers into a single server farm), and so on."

Others, however, see it as far less pervasive.

"Server consolidation does not appear to be that rampant," says Chip Nickolett, president of Comprehensive Solutions, a systems integrator and consulting firm with experience in server consolidation based in Brookfield, Wisc. "It is mainly performed by larger companies with a complex and robust infrastructure that have been looking at this as a way to reduce cost and provide more flexibility and ease of management."

During the past two years, Nickolett has seen a several types of server consolidations. Here are a few examples:

Blade Runner: Clients with Windows server or Citrix server farms, for example, have been swapping out numerous 2U and 4U servers for blade servers. This, he say, tends to happen once a support agreement becomes too expensive to maintain. Often, an organization can replace tens of single servers with one or two racks of blade servers, achieve higher performance, and be close to a break-even point when comparing the support costs of several old systems vs. the replacement cost of a new system. The space savings, reduced electrical and cooling demands, and easier infrastructure management come as a bonus. Further, SAN connection complexity and cost can sometimes be reduced.

Homogeneous Sprawl: Another scenario is in environments where various stand-alone servers service a single system or environment. As they grow or become more complex, consolidation becomes an appealing concept, as it can be achieved with relative ease. This can result in easier overall management as well as more-robust computing environments with higher levels of redundancy. It can also lower software licensing costs in situations where the same product, such as a database management system, supports many applications systems throughout the company.

Server Centralization: Some companies look to gain ground by centralizing several data centers into one large site. For example, Comprehensive Solutions helped a global distribution company that decided to consolidate systems located in Southern California, Japan, Hong Kong, Taiwan, and Australia into a single Sun cluster residing in Southern California. This was a heterogeneous environment consisting of Sun, Data General (incompatible Intel and Motorola systems), and Linux systems. The systems found in the Asia/Pacific region were older hardware running obsolete operating systems that had not been patched in years, and obsolete versions of the Ingres database were in use there. It took more than a year to plan, execute a pilot project, and fully deploy this consolidation.

Bottom line: Don't expect to achieve consolidation overnight. Plan thoroughly and lay out time lines conservatively to take into account all possible outcomes.

"While we were expecting some internationalization and localization issues, we encountered far more than we ever expected," says Nickolett. "But in the end the system was a huge success and performance improved, even for those in Asia."

You, too, should expect a host of issues to crop up when implementing such a grand scheme. Some issues that may surface are network latency, providing regional access and security, supporting multiple print queues and printers, maintaining separate databases, and supporting multiple time zones in different weeks when clocks change back or forward.

When to Consolidate

Timing the server consolidation process correctly is essential to the project's success. Most experts agree that it should be tied in to another upgrade initiative to maximize value. This might be: the replacement of older systems; an infrastructure upgrade that has the goal of improving security or disaster recovery capabilities, or storage simplification; to address a floor space crunch; to cut licensing costs, either through consolidation or moving to a less-expensive platform; or the addition of new systems that are more flexible and scalable.

"Enterprises with aging hardware, increasing processing demands, tight requirements for business continuity or disaster recovery, or rising infrastructure costs should look at their environment to see if server consolidation might benefit them," says Nickolett. "There is no simple formula for making this determination, but with the proper analysis the decision making process becomes easier."

What sort of time frame should be attempted? This depends on many factors, such as the existing architecture (are the current systems homogeneous or heterogeneous?), the operating system, the application server, the application, the capacity and utilization profile for each system, and, of course, the desired end result.

"Ensure that the application is scalable enough to manage the number of possible users on the new single platform," says Longbottom. "Otherwise, a consolidation project will take you a whole lot longer than you intended."

An additional area to consider closely is the budget. A common mistake is to purchase less than what is needed due to budget constraints. Later, more money will need to be spent to upgrade a component or subsystem. In this instance, it is better to delay a project rather than implement one on an inadequate platform and have it viewed as a failure.

Note, too, that several other elements influence any project's time frame. The number of users, storage I/O needs (this may necessitate moving to high-speed SANs from direct attached storage), and bandwidth requirements (multiple NICs might have to be made available for network load balancing) can all affect the rollout. Adequate time to roll it back if the consolidation doesn't work as expected should also be included.

Typically, consolidation is accomplished in three phases. The first phase is due diligence and planning. This provides the information management needs to make a sound business decision. The second phase is a pilot project that addresses some of the complexities of the environment. Many companies want to bypass this, but valuable lessons are often learned that can be applied early on in the project, resulting in overall cost savings. The third phase is the consolidation effort itself. Professional project management practices combined with a solid business and technical understanding of the environment help keep the project on track and on budget.

Bottom line: Don't expect to achieve consolidation overnight. Plan thoroughly and lay out time lines conservatively to take into account all possible outcomes.

Consultant Assistance

Some enterprises attempt consolidation on their own and often live to regret the decision. On relatively simple projects, vendor help might be forthcoming (e.g., switching eight IBM boxes for two larger IBM boxes). Alternatively, the internal resources may be skilled enough to look after any consolidation project.

But even when the skill sets are available in-house, an organizations should evaluate the consequences of going the do-it-yourself route. What IT projects will have to be put on hold while consolidation is undertaken? How will the maintenance of existing systems suffer in the interim?

"Don't engage in a server consolidation project until you've proven you can derive benefits from it and have thoroughly prepared both your personnel and resources for the process. It's like the old adage goes, when you fail to plan, you plan to fail." — Kelly Quinn, IDC analyst

There comes a point, therefore, when it might be better to bring in a consultant or systems integrator.

"I'd work with a systems integrator when the main project would be OS- or application-driven, and the consolidation would need to be designed around this need," says Longbottom.

Nickolett concurs

"If a company has in-house resources with sufficient skill and bandwidth then, consultants can be used mainly as a sanity check," he suggests. "But if they lack expertise, then they need to look at securing proven consulting assistance as early in the process as possible."

When to Leave it Alone

There are times, however, when it may be prudent not to engage in server consolidation. IDC analyst Kelly Quinn points out that it takes careful preparation to conduct such a project, and that a vital part of that step is defining what — if any — value will actually be derived from it.

"Don't engage in a server consolidation project until you've proven you can derive benefits from it and have thoroughly prepared both your personnel and resources for the process," says Quinn. "It's like the old adage goes, when you fail to plan, you plan to fail."

Longbottom stresses that enterprises should strenuously avoid consolidation unless there is a major technical upgrade happening at the same time. If the server operating system, for example, needs upgrading, it might also be a good time to look at server and application consolidation. Likewise, a merger could represent the ideal moment for such an initiative.

"Server consolidation can be highly impactful to the running of a business," says Longbottom. "I don't think that it is worth doing it just for the sake of it."

This article was originally published on May 11, 2006
Page 1 of 1

Thanks for your registration, follow us on our social networks to keep up-to-date