How to avoid bumps on the road to grid computing

UPS has always been driven by technology. It invests close to $1 billion per year in IT. Recently it added the New Data Center technology of grid computing to its infrastructure, says Brian Cucci, manager for UPS' Advanced Technology Group in Mahwah, N.J. Last October, Cucci's group completed a year-long project that moved a mission-critical COBOL billing application from the mainframe to a Linux grid running DataSynapse GridServer. Here Cucci shares the five biggest lessons he learned from that and other grid projects.

• Software licenses, not technical issues, could be what prevents an application from running on your grid.

"If you are going to target an application to run on a grid, you are virtualizing that application to run anywhere. But you may be locked contractually to run it only on, say, two dual-core boxes, and then you are not going to get the power of that grid," Cucci says. His team analyzed which types of licenses were grid friends and which were foes, he says. The most grid-friendly is enterprise licensing, which lets software run anywhere. Concurrent-user licenses - or any form of license based on how many times an application runs somewhere - also are friendly. Node-locking licensing - or any form of license that dictates the type of machine - are the worst. CPU-based licensing can work but isn't great because contractually limiting the software to a specified number of CPUs undermines the power of the grid. Getting vendors to modify their licenses to be more grid-friendly can be tough. Vendors are often fearful that multiprocessing computers will eat their revenues - and rightly so: Grids and multicore machines often let enterprises do more with less software.

Read a related story on the first application UPS ported to its grid.

• Expect capacity planning to be more guesswork and gut instinct than established engineering.

Because UPS chose Linux, an affordable operating system already well known internally, there were few surprises for the team in building the grid itself, Cucci says. But the team found little guidance in how to estimate workloads so it could determine how big a grid to build. Even the most intense workloads ran lightning-fast on the grid. A process that took 270 minutes to complete on the mainframe could be completed in less than 40 minutes on a two-server, eight-CPU grid, he says. Adding servers did not always translate into proportionately faster performance, however. For instance, tests showed that a two-server, eight-CPU grid connected to a storage-area network reduced application-processing time by 42% compared with a grid that had a single server and four CPUs. Adding a third server made the grid only marginally faster, however, reducing application-processing time by 53%. A four-server, 16-CPU grid reduced processing time by 56% compared with the single-server grid but ran only 3% faster than the three-server grid. As it experimented with capacity, UPS tended to overestimate the number of boxes needed, Cucci says. But there was an upside: Because the grid was inexpensive to buy and operate, there was no large financial penalty for overbuilding it.