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.
To maximize their investment, IT executives are going to want to run as many applications on the grid as it can handle. Cucci says his team’s goal is 100% utilization, but mature workload-management tools are not available yet to help plan for such usage.”Chargeback tools exist in DataSynapse, but are only good once you build and deploy,” he says. Discovering how many applications, as well as which application combinations, the grid can handle will be a matter of trial and error, so be sure your planning phase includes extra time for this, he says. Grid newbies also must remember to factor business-continuity capacity into the mix. For its business continuity needs, UPS built two grids - one for each of its primary data centers - to run specific applications and to handle failover.
Often a grid is built to run only portions of a mainframe application. The goal is to slice out the compute intensive part, run it on the grid, then deliver the results back without skipping a beat. To make this work, the grid has to produce results identical to the original mainframe code. This will probably require lots of unexpected reengineering. For instance, UPS’ billing application uses a timestamp in the file name. The mainframe relies on the name to work with the data. UPS discovered, however, that Linux uses a timestamp convention that’s different from the one the mainframe uses - and the grid operates faster. As a result, the grid was giving multiple files the same name and in a timestamp format the mainframe didn’t recognize. Before going live, Cucci’s team had to to fix this hidden problem.
Plan on gutting your systems management processes.
If a long-running mainframe application has a problem, the IT folks have a reliable methodology for fixing it. When that same application - or just a part of it - moves to a new platform, IT executives need to build new systems management procedures for it. The tools used to diagnose problems on a Linux grid are different from those used to troubleshoot mainframe problems, plus the mainframe experts are often not the Linux experts. New support teams will likely need to be created. The most efficient project timeline considers the support process from the outset, Cucci says. Otherwise, this requirement will be discovered at some point - and it’s best that it not be discovered after the production rollout is complete and a broken application is waiting to be fixed.
IBM mainframe
2
5
grid client gateway
3
Grid computing at UPS
UPS built a Linux grid to run an all-important invoice appliation. Here’s how it works.
1 A mainframe batch job copies raw billing data to storage 1 shared between the mainframe and the grid.
2 6 A mainframe job scheduler activates a grid client via specialized code called the grid client gateway.
3 The gateway submits the job to the grid.
4 Invoice-generation software on the grid uses the
raw billing files to create invoices, which then reside on the shared storage.
5 Upon completion, the gateway returns job codes
from the grid’s output to the job schedulaer for use in the rest of the mainframe-based invoice process.
6 Subsequent mainframe jobs access the invoices from
4 the shared storage.
Shared storage
linux grid using
dataSynapse gridServer
References:
Archives