Hardware may be the most obvious component of server consolidation, but it's by far not the only one. This tutorial discusses how and why hardware, software, and human capital must be taken into account when considering undertaking such an endeavor.
Common sense holds that if organizations with hundreds, if not thousands, of servers consolidate, cutting the number of servers and server locations, they would save money.
Experience on the other hand teaches that making server consolidation pay off can be almost a black art.
Why? Because there are so many factors to juggle, from changes in hardware, to software configuration, to relations with the personnel department. This ServerWatch tutorial will consider some of these factors -- without straying into the black arts.
Here's a good starting point: Except in the most trivial cases, server consolidation is not just about hardware. Of course, using fewer servers is usually one of the goals, but in most cases that is not the way to approach achieving the benefits of server consolidation.
Server consolidation is a means to an end. The means of consolidation include hardware, software, services, and systems management. Server consolidation is also a process (and here's where the black arts comes in) of rationalizing and simplifying not only the physical servers but also the infrastructure that supports them -- and that can mean the human resources as well.
The end goal of server consolidation is a more efficient use of resources and better IT service. What does "efficient" mean in the case of servers? Lower total cost of ownership. And "better services?" Better access to information, improved levels of service (e.g., consistent 24/7/365 operation), and faster response. Under ideal circumstances server consolidation delivers both efficiency and better service.
Just remember that circumstances are not always ideal, however.
Centralization is an obvious principle of server consolidation. If you have servers in 40 offices, consolidate them at 10 locations. You might have the same number of servers, but the reduction in overhead by cutting sites can be prodigious.
However, centralization is not just a numbers game. There may be good reasons why servers are spread about, at least for some of them. To do the job right, avoid blanket consolidation; do the diligent thing and look at each server site on its own merits. Remember, you are changing more than servers. With consolidation comes changes in network architecture, communications, storage systems, application and data distribution, and personnel, among other things. Even a certain amount of corporate politics may be involved. Sometimes the reasons why a location has its own servers have little or nothing to do with IT.
It's much the same situation for reducing the number of servers. You can use bigger servers, load more work into fewer servers, create virtual servers, and use server blade systems, all approaches that can make server use more efficient. Yet each of these entails changes and complications (i.e., different hardware and software) and therefore expenses.
This is another way of saying that for most server consolidation projects you can draw up a balance sheet: Savings on one side and the costs of change on the other. The results may be surprising.
Often, for simplicity's sake, developers and IT staff like to put one application on one server. This enables people to say things like, "That's the database server." Sometimes there are good reasons for the one application, one server rule. Often, there is no real reason, and several applications could live quite efficiently together. Consequently, consolidating applications, usually along with the data, is (or should be) part of the server consolidation process.
This is not necessarily easy. Reconfiguring applications and data requires great attention to detail. Security, access rights, performance, storage management, and maintenance are just some of the issues that must be resolved. To give you a flavor of the subtleties in server consolidation, consider licensing. Common sense says that by running fewer copies of an application there is licensing money to be saved. However, that depends on how a vendor prices its licenses. With per-seat pricing, costs will not change because the number of users will remain the same. Pricing by size or number of processors may not change much either, since consolidation typically involves fewer but larger servers. Some vendors will bargain. Whatever the situation, this is just one area of consolidation that requires thought and care.
Just as the best advice for buying hardware is usually, "choose the software you need and then pick the hardware to run it," applications and data should usually drive server consolidation. By evaluating what impact consolidation will have on the software, you'll get a better picture of costs and be forced to think about the larger philosophical issues, like decentralization vs. centralization, and PC vs. mainframe.
There are some interesting arguments (most of which are old), but in practice most enterprises live in the zone that centralizes some applications and decentralizes others. The important thing is to look at how the servers are being used on a case-by-case basis before making decisions about centralization and rationalization.
If there is one theme that emerges from successful server consolidation projects, it's specificity. Hand waving like, "just get rid of a hundred servers and we'll save a ton of money," must be replaced by careful inventories of server resources, analysis of communications, software dependencies, data management, storage requirements, and staffing. Since server consolidation most often takes place at the enterprise level, such considerations require much work and expertise.
If you choose to go ahead with consolidation, then planning and implementation are equally demanding. An enterprise obviously doesn't just switch off 300 servers and turn on 100 others, especially if mission-critical software is running on them.
If you can afford it, there are plenty of consulting services available. From IBM, to Sun Microsystems, to an organization down the street, there is no shortage of people with more or less expertise in server consolidation. How effective this support can be depends on what kind of the expertise is available, and whether it stems from common sense or the black arts.
In general, many hardware vendors are happy to perform server consolidation consulting, albeit with a certain bias.
Before bravely moving forward with server consolidation plans, and before sitting down to determine return on investment and total cost of ownership, it is important to take a broad view.
What will be the consequences of consolidation if the company grows rapidly (or shrinks)? Will consolidation favor mergers and acquisitions? What about future technology?
Consider these magic words: Web services. Does the rise of Web services signal another round of distributed computing and decentralization? It's possible. While server consolidation is essentially a single enterprise's concern, it takes place in a world of computing where change has to be part of the consideration.
A server consolidation project is not one of the easier endeavors an enterprise can undertake. Yet server consolidation and the rationalization of other systems that often go with it can do wonders for a company.
This article was originally published on Thursday Jun 13th 2002