A 20:1 proposition

Server consolidation has become a proven method to stop spiraling IT costs.

Server consolidation is fast becoming the strategy of choice for IT organizations faced with burgeoning costs from their distributed application environments. The success stories are piling up: The Gap reported saving $2 million annually by consolidating from 269 two-way servers to 10 eight-way servers, and reaping a 43% improvement in ROI over two years. Pella consolidated 16 Microsoft Exchange mail servers down to six, increasing reliability and cutting costs in half. JetBlue.com consolidated 64 servers down to just three boxes, saving more than 60% in staffing and maintenance costs.

According to IDC research, 79% of U.S. organizations are in the middle of server and storage consolidation projects, up from 52% in 2000. "And the vast majority - 85% to 90% of the users we've surveyed - are happy with the way things have gone and plan to do more," says Matt Eastwood, program director of worldwide server research IDC.

But as with any IT project, there's a right way and a wrong way to approach server consolidation. The primary hurdles to success, users and analysts say, are not so much technical as they are organizational and political.

Get buy-in

When IT is decentralized, "getting other groups to buy in to the consolidation idea is not easy," says Devin York, IT director of financial systems for Continental Airlines in Houston.

Under York's guidance, the financial systems group spearheaded the consolidation of 50 application servers for six departments onto two 32-way HP 9000 Superdome servers running HP-UX, saving the airline $2 million off the bat and $1 million a year in maintenance costs.

But Continental's internal setup made the process difficult. At the airline, IT projects are departmentally driven. Over the years, this had helped each department better track and limit costs, but it had left the company's data center with a hodgepodge of space-eating, difficult-to-maintain application servers.

"Every group had its own Web server, application tier and database server, so for every group there were at least three boxes that needed to be supported and maintained," York says. Some mission-critical departmental applications were distributed, as well. Some pieces of his group's revenue accounting package were housed on the mainframe,while other parts were on different servers across the company.

"The systems and processes were a little bit everywhere," York says. "And that's not a great idea." This architecture was especially problematic when York's group looked to upgrade the revenue accounting application because simply finding the various pieces and getting them all synched up at once was difficult.

The Superdome was a good fit for Continental because it supported hardware partitioning and HP-UX, on which most of the various departments' mission-critical applications already ran, York says. Plus, consolidating applications on the Superdome would help all the groups save money, while providing each with a better server environment, complete with failover and redundancy - features none could afford on its own. Still some groups were leery.

"Each group has pretty tough performance goals set by management, so people were hesitant to give up their hardware," he says. "They wanted to be able to control their own destinies when it came to meeting yearly goals."

The trick was proving to management that they could meet or beat their goals while saving money. "It came down to a financial argument. We showed them how they could get better availability and better performance for 15% less than the annual cost of supporting their own environments," York says.

In the end, when it came time to justify costs to upper management, no department wanted to be the odd one out. "It becomes difficult for them to say 'No' because the next time they need to upgrade, their cost is going to be more than ours and someone in management will wonder why they didn't go along with our consolidation. You can't say 'No' to better performance at lower cost when you're at an airline that's struggling," he explains.

With the re-architecting of the revenue accounting project nearing deadline, the financial systems group implemented the new Superdome architecture in 2002, bringing applications from the six other groups onboard at the same time. The financial systems group manages the hardware for the others, although each group retains responsibility at the application level.

Go slow

Many organizations find that starting with a non-critical application will help demonstrate the consolidation concept. "We see people targeting the low-hanging fruit first," IDC's Eastwood says. "They target the infrastructure - the e-mail systems, the file and print servers, the networking-type servers - because those are the assets that IT has full control over."

At Zurich Life, this meant starting with development and staging servers. Using VMware virtualization software and HP/Compaq ProLiant DL 380 and 580 servers, this financial insurance firm reduced the overall number of application servers from about 200 Windows-based machines to fewer than 80, says Mark Bradley, who led the project and is now applications development analyst at a large financial company.

"To do any sort of change in the production environment, there are so many groups involved that getting approvals is difficult," he says. "But in a staging-and-development environment, you're under the radar, so getting a change in and out is easier." Once you've proved a concept in the development area, getting approvals and starting on the production servers is easier, he says.

At Endress & Hauser, a global process controls manufacturer, starting small meant targeting a Linux-based IT project management application running on several IBM AS/400 servers distributed throughout the company's 35 business units. "We started with a very small application," says Jan Olaf, executive board member at Endress & Hauser. Because only IT used this Linux application, Olaf's group felt comfortable starting with it. "We were the only ones who were impacted by the consolidation, and we were able to get feedback directly from our own people," he says.

Endress & Hauser eventually consolidated its 19 production SAP systems, together with associated DB2 database servers, onto just two IBM zSeries 990 mainframes configured with 48 zSeries processors, and running a mix of Linux and Windows 2003. The production SAP systems, which support more than 3,500 users in 35 corporate locations worldwide, are distributed on 14 logical partitions, while the databases are distributed on six logical partitions on the zSeries 990. The mainframes are housed at Endress & Hauser's data center in the headquarters city of Weil am Rhein, Germany.

The best consolidation platforms can accommodate some kind of hardware and software partitioning because the applications - and the users - sometimes require finer degrees of separation, users say.

Four stages of server consolidation

Each stage increases the complexity of the process but also improves the payback.

Server consolidation can mean a variety of things to different people, and users considering launching a consolidation project would be wise to think through their goals. As a starting point, consider these four distinct phases for your server consolidation project, IDC says.



The easiest and most basic stage. During this stage, IT centralizes its various distributed application servers to one data center by moving the physical boxes to a central location. Administration is eased, but not much is gained because the applications remain tied to a plethora of individual servers.
Physical consolidationDuring this stage, IT combines like application servers — say several Microsoft Exchange mail servers — onto fewer or larger systems with the same application type or platform. This results in fewer servers overall, leading to lower maintenance and administrative costs.2

Data integration

During this stage, IT combines applications with different data formats onto a single platform. For example, it moves from a mix of database platforms to just Oracle. This not only reduces the number of application servers, but standardization helps further streamline support and maintenance costs.

Application integration

provides the most bang for the buck. During this stage, IT consolidates servers supporting different application workloads onto fewer or larger systems.
-Joanne Cummings

For example, HP's Superdome uses hardware partitioning, which enables Continental to keep each department's applications separated. This makes each group more comfortable with the consolidated setup. "We install everything and do things like failover for the whole box, but at the [operating system] level, the groups own their applications and they're all kept completely separate. And that's the way they like it," York says.

At the financial services firm, Bradley uses a mix of hardware and software partitions to accommodate different applications. "Some applications work just fine in a VMware environment," where processing power is carved up virtually using the software, he says. "But for a seriously [network-intensive] chatty app, a blade server is a better fit." This is because blades use their onboard switching capabilities to provide an extra layer of separation that's not possible in a strict VMware environment, he says.

Of course, consolidated servers do have their downsides, users say.

Scheduling can get dicey, for example. Patching the operating system for the primary server is easier than patching across multiple servers, but it could mean bringing down all the resident applications at the same time. "With 24-by-7 ATM machines and a variety software, anytime we want to bring a server down, it almost requires an act of God," Bradley says. "Nobody can agree on the best time."

Bradley says this problem might get solved when he moves to VMware ESX Server 2.5, which became generally available in December. "It lets you move your VMware sessions off one box and onto another just by dragging and dropping. So you could patch your [operating system] on one machine and drag it back without affecting anything, which is nice," he says.

Continental's York follows a similar protocol, patching systems every time he does a failover test for the Superdome environment, a task he schedules quarterly. Patches for critical holes are done as needed.

"Firmware upgrades have been the biggest hassle. The complex thing about a consolidated server or storage environment with the firmware is that there is a dependency chain. If a tape library needs a certain firmware, well, you better make sure that firmware is also compatible with everything else you're running. It's all more complex," he says.

Five ways to sell your server consolidation project


Consolidate storage first to gain buy-in for the concept and then move on to application servers.
2Attack low-hanging fruit such as mail and print servers first and build on your success. costs.
3If you charge back, show savings that way.
4If you don’t charge back, then focus on detailing service-level improvements, staff/asset utilization savings and business flexibility (all of which should exist at some level).
5Be patient and don’t consolidate all at once. Wait and consolidate when an upgrade is necessary anyway, and even then do it bit by bit.

Backups also are sore spots, Bradley says. The VMware environment initially caused problems for him because every time the backups ran on the various applications on the box, it brought the server to its knees. VMware is aware of this problem and has posted a series of fixes and workarounds, one of which is using background Perl scripts to create back-up snapshots.

"We were able to build a Perl script to kind of stop and start the server," Bradley says. "Rather than run a tape backup within each VMware session, we stop it, take a snapshot of that file, and then start it again. It gives us a full backup of everything on that box and on the VMware session, and it's much faster. It doesn't drag on the CPU and utilization."

Go overboard

Perhaps the most important piece of advice users offer is to choose your consolidation platform wisely. Make sure it's large enough."You should always buy the biggest and the best hardware you can afford for this. You really can't overprovision because the more you provision, the more you can do," Bradley says.

Another tactic is to get a pay-as-you-go deal from your vendor. "That's the best way," Olaf says. "In our consolidation project, with the first application of the SAP system, we didn't need all 48 processors of the machine - and we didn't pay for it. But as we increased the number of applications, we could increase the number of processors, on a pay-as-you-go basis. It was very flexible and cost-effective."

1 2 Page 1
Page 1 of 2