My previous couple of articles, “Getting a Direction in the Sea of Grid” and “Preparing for the Grid,” dealt with the process of beginning to address the advantages of Grid computing in an enterprise setting. With some of those first steps out of the way, the next step is to determine the efficacy of a Grid solution in a way that doesn't expose the business to an overly large risk. As with other flavors of IT, one good way to do this in the Grid space is with a proof-of-concept (POC) project.

There are many different descriptions using the word “Grid” out in the marketplace of ideas. As Pawel Plaszczak and I pointed out in our book Grid Computing: The Savvy Manager's Guide, while it is useful to consider a data Grid, compute Grid, instrument Grid, partner Grid, enterprise Grid or any of the other flavors talked about in various venues, it is also worth keeping in mind that these are really subsets of the larger thing known as “the Grid.” A financial firm creating an Internet-based Grid application that uses many compute resources is often referred to as a compute Grid. While this is certainly true in the common vernacular, it is also true that many of these applications run on a public network, use open protocols and demonstrate non-trivial levels of service. Thus, it is also accurate to say that it is an application on the Grid at large. In effect, the financial firm is a business creating a virtual organization and using resources on the Grid. The distinction can be important when discussing proof-of-concept (POC) projects because, while the concepts of data Grid or compute Grid may be handicaps in building an enterprise Grid solution, they are of great benefit when scoping a POC project. An enterprise architect might be missing the boat by thinking about compute Grids and failing to take advantage of the ability of the broad array of solutions available in the larger Grid space. That same architect can, however, use the smaller scale of a compute Grid point solution to demonstrate some key capability and prove out an idea before investing large amounts of time and money into a full Grid solution.

Currently, most POC efforts are taking place surrounding the areas of compute Grids and data Grids. These two areas are prime targets for a number of reasons:

• Most intuitive.

• Most existing literature.

• Many products to chose from.

• Easy to demonstrate smaller scale solutions.

Compute Grid POCs

There are many organizations that would benefit from the application of Grid technology. Among the most long-standing, with examples dating back to the beginning of the industry, are those that make use of an enormous amount of compute power. Within this group, there are two broad classes of applications: those that are embarrassingly parallel (e.g., those applications that execute the same instructions over many pieces of data); and those that run on a cluster and require a lot of communication between various pieces of the application (e.g., Message Passing Interface (MPI) applications). For each of these, the fashion in which one constructs a POC is a little bit different.

Embarrassingly Parallel Applications

In an embarrassingly parallel application, the primary goals for the POC are to demonstrate the discovery of available resources and the mechanisms used to distribute jobs to the various resources. The bulk of the POCs being done at this time answer the discovery part of the equation by either scavenging CPU time from various desktops around a lab or using an existing farm or cluster to demonstrate CPU provisioning in a dedicated shared facility. The various advantages and disadvantage of scavenged CPU versus dedicated shared CPU is beyond the scope of this article, but it is worth noting that many of the world's top IT organizations are choosing to go the path of dedicated shared CPU for manageability reasons. As the global IT marketplace is currently going through another round of desktop consolidation, it isn't clear what the ongoing support for scavenged CPU will be.

The embarrassingly parallel POC will, once the resources have been cataloged in the system, dispatch jobs to the available resources and gather the results. Compared to serializing these kinds of jobs on a typical computer, or even supercomputer, the improvement in turn-around time for this class of application can be quite startling.  We've seen applications that took 15 hours to run be completed in 15 minutes by distributing the work among many nodes.

Even in the POC, the advantages of a compute Grid for embarrassingly parallel applications are easily demonstrable. If a single node takes 15 hours, two nodes 7.5 hours and eight nodes a bit under two hours, then the concept of using Grid technology has been quite well proven for that application. There is no need to deploy a 64-node farm to demonstrate the concept.

Cluster Applications

Many people confuse clusters with Grid computing, so it is worth repeating here that a cluster is not a Grid. A cluster is a resource on a Grid. As such, there are some interesting demonstrations that can be done making clusters available via a Grid infrastructure like Globus.

As with embarrassingly parallel applications, the goal of the POC is to demonstrate discovery of resources and execution of jobs on those resources. Broadly speaking, this is what all execution management is about. In the case of the cluster application, the resource is simply a cluster instead of an individual node. In a POC of such applications, it isn't necessary to have many nodes in each cluster. In fact, a single physical cluster will often times be logically partitioned into multiple smaller clusters. This allows the 128-node system to be viewed logically as four 32-node clusters. With various tools, these individual clusters can be made to appear available for jobs or not, with the dispatch of jobs demonstrated to the stakeholders in the project.

Data Grid POCs

The compute Grid POC process is pretty interesting because there are a couple different ways to go about proving value for the enterprise. Similarly, with data Grid POCs, there are the reasonably distinct goals of “fire and forget” and “high speed transfer.”

Fire and Forget

One interesting piece of the Globus Toolkit is a service known as Reliable File Transfer (RFT). RFT is designed to allow a user or application to request that a set of files be moved, and then leave RFT to do the actual provisioning of that data movement. Interested parties can then check back to see the status of the requests. This is a great facility in situations where links are slow and there are many files to move. It is also a pretty good demonstration in the lab.

What a POC on this front can do is tell RFT about two days worth of data to move and then walk away. When the demonstration completes many thousands of transfers over the course of a few days, people can intuit the power of the service. Similarly, pulling the plug between a pair of machines and then, the next day when the cable is reconnected, have the transfers resume as if nothing had happened is also a cool way to show the robustness of the platform.

High Speed Transfer

GridFTP is a protocol for doing high efficiency data movement across fast WAN connections. A POC on this front can consist of demonstrating other transport protocols and GridFTP across the same link. GridFTP, because of it's support for handling real world packets drops in an efficient manner, will outperform most older mechanisms by a wide margin in many of these tests. Another way to demonstrate this without blasting data down a production WAN is to build a WAN simulator in a lab. These kinds of tools also have the advantage of presenting a controlled failure in the network layer. It is really compelling to do a demonstration of a long WAN transfer and be able to show that even if the number of packet errors is increased substantially, there is only a modest decrease in GridFTP througput. Again, these results can be compared to something like naïve FTP or other transfer protocols.

While there can be a lot demonstrated in print, there is something very useful about going through the steps necessary to build a POC like those above. Understanding what it takes to install the software, configure the systems, manage the demonstration and administer the various services to the point of being able to successfully demonstrate this kind of functionality is a powerful tool for proving that Grid technology is capable of meeting the challenges at hand.

About Rich Wellner

Rich Wellner is the enterprise architect for Univa Corp., specializing in Globus solutions for large-scale challenges.  He is the author, with Pawel Plaszczak, of the upcoming book Grid Computing: The Savvy Manager's Guide. He can be reached at [email protected].