In-Depth

Platform Usage Models -- A Grid Computing Example (Part 3 of 3)

Grid system complexity can tie an organization in knots in an endless debate trying to justify a deployment. The Hierarchical Usage Model Framework may help.

• By Enrique Castro-Leon
• 08/15/2006

Computing grids can arguably be one of the most complex systems that can be built with modern technology. So complex is a grid system that an organization can be tied in knots in an endless debate trying to justify a deployment. The Hierarchical Usage Model Framework, or Hierarchical Framework for short, helps decompose this tough issue into more manageable parts, making it easier for the Finance staff to justify an investment while giving the Engineering staff enough leeway to build a useful system.

There is nothing inherently special about grid computing systems, especially in terms of the hardware used to build them. The highest-performing grids built to run the toughest engineering and scientific applications have been built out of specialty or custom components. However, there are no specific requirements that grids be built of high-performance custom components. There is even a class of grids, which we will call embedded grids, built from low-performance embedded processors optimized for low power consumption. What distinguishes a grid is the structuring that links together otherwise ordinary computing components.

There is no canonical categorization in the layers in a grid system for the purposes of building our usage models. The criteria are pragmatic: a classification must be easy to understand and must yield insight into the system behavior. To illustrate the non-exclusive approach, we will describe two layering systems for grids, one fine and one coarse.

Let’s start with the fine layering first. One way of instantiating the framework is in the nine layers illustrated in Figure 1, namely:

1. CPUs
2. Chipsets
3. Baseboards
4. Nodes
5. Clusters
6. Departmental grids
7. Intra-grids
8. Extra-grids
9. Virtual Organizations

Grids consist of individual computers or nodes. Co-located nodes may be linked via a local fast network or interconnect into a cluster. Individual nodes or clusters are then joined into a grid through a LAN or WAN. These are elements in the middle, in layers 4 through 6, encompassing the most recognizable components in a grid system. Hence, we call these layers collectively the visible grid.

Figure 1. The Multi-Level Framework Instantiated for Grids
Click to enlarge

Individual nodes are represented in layers 1 through 4, namely, processors, chipsets, baseboards and nodes. These layers encompass the constituent computers in a grid. These computers can be servers, workstations, ordinary PCs, or even mainframes. Because hardware figures prominently in these layers, collectively we call them the physical grid.

We have grids proper in the upper layers 5 through 9. The distinguishing factors in these layers are the political boundaries. Departmental grids are owned within one organization or department in a company. Intra-grids are company-wide grids that reside inside a company’s firewall. Extra-grids feature resources that cross company boundaries, including hosted resources. Hence, layers 5 through 9 are identified collectively as the business grid. The term virtual organization is attributed to Ian Foster (see note 1).

The Coarse Example

Two defining characteristics for grids are federation and re-use. Grids are made up of large numbers of similar, replicated elements re-using preexisting, available technologies, such as operating systems and processors.

The three-level coarse classification bears a certain resemblance to the federated style of certain governments such as Mexico, Brazil, or the United States. The physical grid, visible grid, and the business grid can be likened to city, state, and the country [federal] government in these countries. Each level has its own dynamics and has specific interactions with the levels above and below. Peers in a federation have a degree of autonomy yet are interlinked in specific ways.

The instantiated Hierarchical Framework depicted in Figure 1 clearly shows the separation of concerns in a grid system.

Each level carries its own particular audience and usage models. For instance, one audience addressed at the CPU level is hardware engineers, specifically baseboard designers working with 1-, 2-, or 4-CPU applications.

Up a few levels, at the cluster level, we have a stakeholder audience of software engineers designing algorithms to run well in a distributed environment. These software engineers are concerned about issues of message latency and bandwidth as well as algorithmic scalability.

Moving up yet a few more levels takes us to the Business Grid, to the same case study described in Part 1 of this series. Stakeholder audiences at this level are CIOs, CTOs, and workers in the Finance department. Application considerations include whether a grid system should be deployed in-house or outsourced and whether to finance the infrastructure as capital expenditure (owned) or as a recurring expense (leased).

Beyond usage models, a Hierarchical Framework analysis presents the opportunity to identify additional system attributes that can impact usage models. These attributes can run at some or all levels in the model. For instance, the software “attribute” shows up as microcode at the CPU level, as firmware at the baseboard level, as the OS, middleware, and applications in the visible grid, and as business processes in the Business Grid.

A successful grid system will need to satisfy the requirements at every single level at which it operates. On the other hand, the Hierarchical Framework also provides a hint on how to plan and optimize a very complex grid system one layer at a time. Finding layers that have been overlooked during planning are indicative of future trouble spots.

An interesting exercise left to the reader is to apply the Hierarchical Framework to the planning of an organization’s transition to a Service Oriented Architecture (SOA). This example would be as expansive in scope as a grid, ranging from single programs to relationships across business groups within a company and interactions across companies and industry groups.

The Hierarchical Framework is also applicable to simpler deployments, such as the deployment of a PC system with manageability features (managed clients). The instantiated model will not be as complex as the one used for a grid system. Usually three to four layers will do the job. The benefits will be the same: a rapid identification of stakeholders for each layer, the usage patterns for each layer providing checks and balances against other methods already in use.

- - -

Note 1: Ian Foster et al., The Anatomy of the Grid: Enabling Scalable Virtual Organizations, International Journal of High Performance Computing Applications, Volume 15, Issue 3 (August 2001)