GRID INFRASTRUCTURE ARCHITECTURE

A Modular Approach from CoreGRID

Augusto Ciuffoletti

CNAF, Istituto Nazionale di Fisica Nucleare, Via B. Pichat, Bologna, Italy

Antonio Congiusta

DEIS, University of Calabria, Via P. Bucci, Rende, Italy

Gracjan Jankowski, Michal Jankowski, Norbert Meyer

Supercomputing Department, PSNC, ul. Noskowskiego, Poznan, Poland

Ondrej Krajicek

Institute of Computer Science,Masaryk University Brno, Botanick, Brno, Czech Republic

Keywords:

Grid Computing, Grid Information Service, Workﬂow Management, Checkpointing, Network Monitoring.

Abstract:

The European Union CoreGRID project aims at encouraging collaboration among european research institutes.

One target of such project is the design of an innovative Grid Infrastructure architecture, speciﬁcally addressing

two challenging aspects of such entity: scalability and security. This paper outlines the results of such activity,

ideally extending the content of the ofﬁcial deliverable document (CoreGRID, 2006).

1 INTRODUCTION

According to (Foster et al., 2002), a Grid is a complex

architecture consisting of a collection of resources,

which are made available at user level through a num-

ber of services. Such deﬁnition opens the way to a

number of functional components, whose deﬁnition

is of paramount importance for the design of a Grid:

their semantics anticipate the capability of a Grid to

make an efﬁcient use of the resources it contains, to

offer differentiated levels of quality of service, and,

in essence, to meet user needs. Given the complex-

ity and importance of such infrastructure, its design

should address modularity as a primary feature: ser-

vices provided by the Grid infrastructure should be

precisely deﬁned as for their interface and semantics,

and form an integrated architecture which is a frame-

work for their implementation. Modularity makes vi-

able the independent evolution of each component,

and allows the customization of the overall infrastruc-

ture.

In order to guarantee interoperability among com-

ponents, standard interfaces are not sufﬁcient. In fact,

the capabilities of a certain functional component

should be well understood, and agreed in the commu-

nity that develops other interoperating services: typ-

ical requirements address resource access, workﬂow

management, and security. Such semantics should be

compatible with the expected needs of the user, be it

a human or a Grid-aware application.

In addition, past experiences (Laure et al., 2006)

prove that there is a tradeoff between portability and

reuse of legacy tools: when functionalities that were

not designed for integration are included into an ex-

isting project, the whole project tends to inherit all

portability problems of the legacy parts. A plugin ori-

ented approach does not solve the problem, but tends

to complicate the design, and may even restrict porta-

bility.

Taking into account such problems, we indicate a

wrapper oriented approach: legacy tools are not di-

rectly included in the design, but accessible through

interfaces that comply with portability requirements

of the hosting environment. The agent that imple-

ments such functionality (the “wrapper”) is in charge

of publishing portability issues that characterize the

speciﬁc resource.

One key issue in the design of a Grid environment

is the technology used to support the Grid Informa-

tion System (GIS). It is more and more evident that a

unique technology (for instance, a relational database)

cannot satisfy all needs, and may exhibit real scala-

bility limits in case of take off of the Grid technol-

ogy (BerkeleyDB, ). Here we propose a differentiated

strategy for such vital component, splitting its func-

Ciuffoletti A., Congiusta A., Jankowski G., Jankowski M., Meyer N. and Krajicek O. (2007).

GRID INFRASTRUCTURE ARCHITECTURE - A Modular Approach from CoreGRID.

In Proceedings of the Third International Conference on Web Information Systems and Technologies - Internet Technology, pages 46-54

DOI: 10.5220/0001273100460054

 SciTePress

tionality into a directory service, and a streaming sup-

port. The monitoring infrastructure provides input to

the GIS: we describe such infrastructure decomposed

into resource and middleware monitoring, workﬂow

monitoring and network monitoring.

Another key aspect of a Grid infrastructure is job

submission. According to the GGF guidelines in (Ra-

jic et al., 2004), we consider a unique component

that performs batch submissions, scheduling and local

queuing, workload monitoring and control. However,

such component needs support for checkpointing and

accounting, two activities that appear to require ca-

pabilities that need to be addressed speciﬁcally. We

introduce two components that implement such func-

tionalities.

The resulting Grid infrastructure should address

both the need of e-science applications, mostly ori-

ented to storage and computation intensive applica-

tions with moderate scalability, and emerging indus-

trial applications, where the demand is variegated and

includes the management of a large number of small

jobs: in this perspective, ﬂexibility is mandatory to

allow customization.

Since we want to follow a clean design strat-

egy, we address interoperation and integration is-

sues since the early steps, using the GIS as a back-

bone. As a consequence, the adoption of a program-

ming style and tools that support polymorphism is

mandatory: the ”wrapper oriented” approach indi-

cated above helps on this way.

In Section 2 we indentify the functional compo-

nents, and in section 3 we consider a GIS which pro-

vides an integration backbone. In ﬁgure 1 we depict a

schematic view of our proposal.

2 FUNCTIONAL COMPONENTS

OF A FRAMEWORK

ARCHITECTURE

The focus of a Grid infrastructure is on resource man-

agement: the goal is to compose the operation of

basic services into higher level tasks. To this pur-

pose, the Grid infrastructure accepts and processes

task descriptions that articulate a stepwise composi-

tion of computing activities. The use of appropriate

basic services, whose availability is constantly moni-

tored by a Resource Monitoring component, is sched-

uled after unfolding the dependencies between atomic

computational tasks. Resource scheduling extends

not only in the name space, to determine which re-

source is to be used, but also in time, describing when

a certain resource will be busy on a certain task.

The operation of assembling resources in order to

perform a complex task is associated to the Workﬂow

Analyzer component, whose role is to accept the oper-

ational description of a complex task, to manage, and

to monitor its unfolding. The unfolding of a work-

ﬂow must be sufﬁciently ﬂexible, in order to cope

with unanticipated events that may affect resources,

either improving or degrading their performance. The

appropriate way to cope with such events is the logis-

tic re-organization of workﬂow execution, which usu-

ally entails the displacement of stateful computations,

by re-instantiating services whose state corresponds

to an intermediate computational step.

Two basic functionalities are offered: the registra-

tion of a snapshot of an intermediate state of a ser-

vice, and the re-instantiation of the same service with

the given intermediate state. All resources in a work-

ﬂow participate to such reorganization, and the re-

sulting workﬂow execution must be consistent with

the expected semantics. The Checkpoint Manager

component is in charge of supporting the logistic re-

organization of a workﬂow, preserving the relevant

state information of a component services in prepa-

ration for the reconﬁguration of the supporting low

level services. Speciﬁc checkpointing indications are

inserted in the operational description provided to the

Workﬂow Analyzer.

Since resources are similar to goods, their sharing

must be controlled accordingly, taking into account

property and commercial value. In that sense, the

Grid infrastructure provides identities to Grid users,

and deﬁnes service semantics according to the iden-

tity of the user, thus enforcing individual property.

Using the same tools, the usage of a certain service

is quantiﬁed, and a commercial value associated with

it. The User and Account Management component is

appointed with such aspects.

The whole Grid infrastructure hinges upon the

Grid Information System (GIS), which supports the

integration between the parts of this distributed en-

tity. From an abstract point of view, the content of the

Grid Information System represents the state of the

Grid, and is therefore dynamic. However, while some

data remains constant for long periods of time, other

are updated frequently, for instance when such infor-

mation represents the residual (or preemptable) share

of a resource.

The activity of a component is pervasive, and

many distinct agents contribute to its implementa-

tion: for instance, each site can provide a Work-

ﬂow Analyzer agent in charge of accepting user re-

quests. Such approach ﬁts naturally with security re-

quirements, which are based on mutual identiﬁcation

among agents.

GRID INFRASTRUCTURE ARCHITECTURE - A Modular Approach from CoreGRID

Functional components Descriptors GISStreams

− Job descr.

− Workflow descr.

− Session descr.

User Interface

− Environment descr.

− Session descr.

− Resource descr.

− User descr.

− Job descr.

− Session descr.

− Workflow descr.

− Ckpt provider descr.

− Ckpt image descr.

− Job descr.

− Ckpt provider descr.

− Ckpt image desc.

− Job descr.

Grid Information Service

Analyzer

Workflow

Checkpoint

Manager

User/Account

Management

Resource

Monitoring

Figure 1: Integration between the functional components of our framework. Each component. is a distributed entity that

contributes to resource management exchanging descriptors with other components. Persistent information ﬂows are encap-

sulated into streams, represented by session descriptors).

Here we give a summary of the functionalities

each component offers, and we outline their internal

structures: we use as a reference the work of the part-

ners of the CoreGRID Institute on Grid Information,

Resource and Workﬂow Monitoring.

2.1 Workﬂow Analyzer

The Workﬂow Analyzer cares about workﬂows man-

agement under several aspects such as mapping,

scheduling, and orchestration of workﬂow tasks

against the available, dynamic Grid resources. To

such purpose, it has close interaction with the Grid

Information System in order to discover and allocate

appropriate resources. But, at the same time, it is also

a source of information coming from the monitoring

of the workﬂows being executed: most of such infor-

mation is reused by the Workﬂow Analyzer itself for

adjusting the ongoing executions.

A Grid workﬂow can be speciﬁed at different lev-

els of abstraction: in (Deelman et al., 2003) abstract

workﬂows and concrete workﬂows are distinguished,

the difference being whether resources are speciﬁed

through logical ﬁles and logical component names or

through speciﬁc executables and fully qualiﬁed re-

sources or services. According to this approach the

workﬂow deﬁnition is decoupled from the underlying

Grid conﬁguration.

For this reason, the mapping phase (also referred

to as matchmaking) is particularly important for se-

lecting the most suitable resources that better satisfy

the constraints and requirements speciﬁed in the ab-

stract workﬂow, also with regard to quality of service

and workload. The mapping process produces a con-

crete workﬂow that is suitable to be executed by a

workﬂow engine, providing for scheduling and exe-

cution management capabilities. It is worth observ-

ing that, in case of dynamic scheduling, it is possible

WEBIST 2007 - International Conference on Web Information Systems and Technologies

to re-invoke the mapping process at runtime, in order

to modify the concrete workﬂow instance as a result

of relevant events modifying the status of candidate

resources.

However, it is important to instrument job descrip-

tions before actual execution, in order to ensure that

the workﬂow execution is suitably checkpointed: suc-

cinct requirements about workﬂow recoverability are

in the Workﬂow description provided by the user.

When the workﬂow enters the running state, the

Workﬂow Analyzer monitors its advancement, and

takes appropriate actions in response to relevant

events. During the workﬂow execution, monitoring is

essentially related to the observation of the workﬂow

status. In particular, information about the execution

of each single job included in the overall workﬂow is

reported by the monitoring system. Typical informa-

tion is constituted by services execution status, fail-

ures, progress, performance metrics, etc.

In case of failure, the workﬂow execution service

itself tries to recover the execution, for example by re-

assigning the work to a different host in case of host

failure. To implement fault tolerance on a more re-

ﬁned extent, it is necessary whenever possible to trig-

ger checkpoint recording, and drive the restart of one

or more jobs from the last available checkpoint. The

decision whether to checkpoint or restart a workﬂow

is made on the basis of information from Resource

monitoring.

2.2 Checkpointing

The Checkpointing component is built around the

idea of Grid Checkpointing Architecture (Jankowski

et al., 2006; Jankowski et al., 2005), a novel concept

that deﬁnes Grid embedded agents and associated de-

sign patters that allows the integration of a variety of

existing and future low-level checkpointing packages.

The emphasis has been put to make the GCA able

to be integrated with other components and especially

with the upper layer management services, for in-

stance the Grid Broker or the Workﬂow Analizer. The

main idea of the GCA boils down to provide a number

of Checkpoint Translation Services (CTS) which are

treated as drivers to the individual low-level check-

pointing packages. The CTSes provide a uniform

front-end to the upper layers of the GCA, and are cus-

tomized to the underlying low-level checkpointers.

When the CTS is deployed on a Computing Re-

source, the GCA has to be informed about its exis-

tence. To fulﬁll this requirement each CTS is regis-

tered at component named Grid Checkpointing Ser-

vice (GCS), and the GCS further exports the infor-

mation about the available CTSes and related proper-

ties to the GIS, so that the GIS becomes the mech-

anism that connects the GCA with the external Grid

environment. Additionally, from the point of view of

the Workﬂow Analyzer, the GCS is the gateway to

which a checkpoint request has to be sent. When the

GCS receives the request of taking the checkpoint of

a given job, it forwards the request to the appropriate

CTS. The GCS is able to ﬁnd the adequate CTS using

the information that the execute-job-wrapper registers

when a checkpointable job is started.

The execute-job wrapper is a special program pro-

vided together with an associated CTS. The compo-

nent that is in charge of submitting the user’s job to

the given Execution Manager replaces the actual job

with the adequate execute-job wrapper and passes to

the second the original job and the global identiﬁer

assigned to this job. Which execute-job wrapper is to

be used depends on which CTS has been matched to

the job’s requirements, according with GIS records.

When the execute-job wrapper is started it appro-

priately conﬁgures the GCA environment and ﬁnally

with help of exec() syscall replaces itself into the orig-

inal job.

When the Workﬂow Analyzer decides that a given

job is to be recovered, then the job has to be resubmit-

ted in an adequate way: one relevant issue is that the

job can be resubmitted only to a Computing Element

associated with a CTS of the same type that was used

to checkpoint the job. When a proper Computing El-

ement is found the job is resubmitted to it, but instead

of resubmitting the original job itself the recovery-

job-wrapper is resubmitted. The original job, as well

as the identiﬁer of the checkpoint that is to be used in

the recovery process, are passed to the recovery-job-

wrapper as the arguments.

The recovery-job wrapper is the counterpart of the

execute-job wrapper used for the recovery activity.

The recovery-job wrapper starts fetching the image,

and the subsequent actions are similar to those per-

formed by the execute-job wrapper. As a last step, the

recovery-job wrapper calls the appropriate low-level

checkpointing package to recover the job using the

image indicated by the calling Workﬂow Analyzer.

The GCA shares the motivations of the Grid

Checkpoint and Recovery working group of the GGF

(Stone et al., 2005), which is to include the check-

pointing technology into the Grid environment. How-

ever, the GCA focuses mainly on legacy checkpoint-

ing packages and, notably those that are not Grid-

aware, while the GridCPR ”is deﬁning a user-level

API and associated layer of services that will permit

checkpointed jobs to be recovered and continued on

the same or on remote Grid resources”. Therefore,

while GridCPR works on a speciﬁcation that future

GRID INFRASTRUCTURE ARCHITECTURE - A Modular Approach from CoreGRID

Grid applications will have to adhere to in order to

make them checkpointable, our effort is towards the

integration of existing products into a complex frame-

work.

2.3 User and Account Management

The User and Account Management component

(Denemark et al., 2005) offers a controlled, secure

access to grid resources, complemented with the pos-

sibility of gathering data from resource providers in

order to log user activity for accounting and audit-

ing purposes. These objectives are realized introduc-

ing authorization, ensuring an appropriate level of job

isolation and processing logging data. A virtual envi-

ronment encapsulates jobs of a given user and grants

a limited set of privileges. Job activity is bound to

a user identity, which is qualiﬁed as a member of an

organization.

The User and Account Management component is

a pluggable framework, that allows combining differ-

ent authorization methods (e.g. gridmap ﬁle, banned

user list, VO membership based authorization) and

different implementations of environments (virtual

accounts, virtual machines, and sandboxes). The con-

ﬁguration of the framework is quite ﬂexible and de-

pends on detailed requirements which may vary be-

tween the resources, so the administrators may tune

local authorization policy to the real needs and abili-

ties.

The internal architecture of an agent consists of

3 modules: an authorization module, a virtual envi-

ronment module and a virtual workspace database.

The authorization module performs authentication

ﬁrst (based on existing software, such as Globus GSI).

The authorization is done by querying a conﬁgurable

set of authorization plugins. The virtual environ-

ment module is responsible for creation, deletion and

communication with virtual environments modeled as

Stateful Resources. The module is also pluggable,

so it is possible to use different implementations of

VE. The database records operations on the virtual

environments (time of creation and destruction, users

mapped to the environment, etc.). These records to-

gether with the standard system logs and accounting

data, provides complete information on user actions

and resource usage.

2.4 Resource Monitoring

The information on resources and accompanying

middleware is provided by the Resource Monitor. Re-

source Monitor component collects data from various

monitoring tools available on the grid. We do not pre-

sume any particular monitoring approach, since the

current state of the art provides quite wide range of

monitoring toolkits and approaches. It is however

a difﬁcult task to integrate and process monitoring

information from various monitoring tools. More-

over, we cannot assume any scale of the resulting in-

frastructure thus scalability of the proposed solution,

both in terms of amount of monitored resources and

required processing throughput for monitoring data,

must be emphasized.

To achieve the desired level of scalability, with se-

curity and ﬂexibility in mind, we propose the design

of a Resource Monitor based on the C-GMA (Kra-

jicek et al., 2006) monitoring architecture. C-GMA is

a direct extension of the GMA (Tierney et al., 2002)

speciﬁcation supported by the Open Grid Forum.

The key feature supplied by the C-GMA is the in-

troduction of several metadata layers associated with

services, resources and monitoring data. The meta-

data may specify the data deﬁnition language used

by the services, the non-functional properties and re-

quirements imposed by the services and resources

(such as security and QoS-related requirements) and

others. The metadata are used in the matchmak-

ing process implemented by the C-GMA architecture,

which is essentially a reasoning on provided metadata

about the compatibility of the services and data de-

scribed by them. When the examined parties are con-

sidered compatible, the “proposal” is sent to them to

initiate a potential communication. In this way, and

with the introduction of various translation compo-

nents, the C-GMA architecture enables the exchange

of monitoring data between various monitoring ser-

vices.

The Resource Monitor service leverages this func-

tionality by connecting to the C-GMA monitoring ar-

chitecture and using translation services for various

monitoring toolkits it collects the monitoring data and

supplies them to the Grid Information System.

Special attention is paid to Network Monitor-

ing, since scalability issues appear as challenging.

We have identiﬁed one basic agent, the Network

Monitoring Element, which is responsible of imple-

menting the Network Monitoring Service (Ciuffo-

letti and Polychronakis, 2006). Network Monitoring

Elements (NMEs) cooperate in order to implement

the Network Monitoring component, using mainly

lightweight passive monitoring techniques. The ba-

sic semantic object is Network Monitoring Session,

which consists in the measurement of certain traf-

ﬁc characteristics between the Domains whose NMEs

participate in the session.

To improve the scalability of the Network Moni-

toring Service, the NMEs apply an overlay Domain

WEBIST 2007 - International Conference on Web Information Systems and Technologies

partition to the network, thus decoupling the intra-

domain network infrastructure (under control of the

peripheral administration), from the inter-domain in-

frastructure (meant to be out of control of the periph-

eral administration). According to the overlay domain

partitioning network, monitoring sessions are asso-

ciated to Resources denoted as Network Elements

(NE), corresponding to inter-domain trafﬁc classes.

The overlay domain partition is maintained in an

internal distributed database, which allows the coor-

dination among Network Monitoring Elements. The

management of network monitoring sessions includes

the control of periodic sessions, as conﬁgured by net-

work administrators, and of on-demand sessions dy-

namically conﬁgured by applications, and uses a scal-

able peer to peer mechanism to diffuse updates.

3 INTEGRATION BETWEEN

FUNCTIONAL COMPONENTS

The central idea of the proposed architecture is to con-

vey all the data through the Grid Information Service

in order to have a standard interface across the differ-

ent administrative sites and services (see (Aiftimiei

et al., 2006; Andreozzi et al., 2005) for a similar ap-

proach).

One relevant feature of a data repository, and of

the Grid Information System, is the volatility of its

content. At one end we ﬁnd “write once” data, that

are not subject to update operations and have a rela-

tively low volatility. At the other hand we ﬁnd data

that are frequently updated. The functionality associ-

ated to the Grid Information System is a mix of both:

while certain data, like a Workﬂow description, fall

in the “write-once” category, other kind of data, like

resource usage statistics, fall into the category of data

that are frequently updated: a solution that devises a

common treatment for both kinds of data suffers of a

number of inefﬁciencies, ﬁrst the lack of scalability.

Therefore our ﬁrst step is to recognize the need of

distinct solutions for persistent and for volatile data.

One criteria to distinguish the two kinds of data is

the length of the time interval during which the infor-

mation remains unchanged, under normal conditions.

Here we assume that a signiﬁcant threshold is given

by the typical job execution time: we consider as per-

sistent those pieces of information that, under normal

conditions, remain valid during the execution of a job.

We call such informations descriptors: starting from

the speciﬁcations of the components that compose our

framework given in previous sections, we now clas-

sify the descriptors that are exchanged among them,

and that collectively represent the persistent content

of the Grid Information System.

Workﬂow descriptor It is acquired from a user in-

terface by the Workﬂow Analizer component. It

has the function of indicating the stepwise orga-

nization of a Grid computation. It contains high

level indications about the processing requested

at each step, as well as dependencies among in-

dividual steps. It should be designed in order to

hide all unnecessary details, for instance pack-

age names or versions, and focus on the func-

tionality (for instance, “fast fourier transform”, or

“MPEG4 compression”). During workﬂow ex-

ecution, such structure is used by the Workﬂow

Analizer component in order to monitor workﬂow

execution.

Job descriptor It is produced by the Workﬂow Anal-

izer component, and fed to various other compo-

nents: it is used by the Checkpointing compo-

nent in order to prepare the execution environment

with checkpointing facilities, and by the User and

Account Management component in order to as-

sociate an appropriate environment to its execu-

tion. The Job description is used by the Workﬂow

Analizer component in order to instruct resources

about their activity, and during workﬂow execu-

tion, to monitor workﬂow advancement.

Checkpoint Image Descriptor It is produced by the

Checkpointing component (in case of the GCA,

this descriptor is produced by the CTS) upon

recording a new checkpoint. The descriptor con-

tains the bookkeeping data regarding the newly

created image. The data can be used by the Work-

ﬂow Analizer in order to ﬁnd the identiﬁer of the

image that is to be used in order to perform recov-

ery and migration. The GCA itself, basing on the

descriptor, is able to fetch the image to the node

on which the given job is to be recovered.

Checkpoint Provider Descriptor It is produced by

the Checkpointing component. The descriptor ad-

vertises the location of service that provides ac-

cess and uniﬁed interface to a particular low-level

checkpointing package. The Workﬂow Analizer

uses such descriptior to ﬁnd the node that provides

the desired checkpointing package, as speciﬁed in

job descriptor. Upon recovery, the descriptor al-

lows ﬁnding the nodes offering the same package

used for checkpointing.

Session descriptor It is produced by a generic com-

ponent, and supports the exchange of volatile

data, as described below.

User descriptor It is produced and used by the User

and Account Management component. It contains

a description of a user, like its name, institution,

GRID INFRASTRUCTURE ARCHITECTURE - A Modular Approach from CoreGRID

reachability, role, as well as security related data,

like public keys. The Workﬂow Analysis compo-

nent uses such data to enforce access restrictions

when scheduling a Workﬂow.

Environment descriptor It is produced and used by

the User and Account Management component.

It contains references to he descriptions of the re-

sources associated to a given processing environ-

ment, as well as the access modes for such re-

sources. This may correspond, for instance, to

what is needed to run a speciﬁc kind of job, and

to the identities of the users that are allowed to

operate within such environment. The Workﬂow

Analysis component uses such data in order to

process a workﬂow description.

Resource descriptor It represents usual resource de-

scriptions, including storage, processing, network

and network monitoring elements. The identiﬁca-

tion of a resource includes its network monitoring

domain. The Workload Analyzer uses such de-

scriptions in order to schedule job execution, and

allocate checkpoint storage.

The management of descriptors relies on a

directory-like structure. Such structure cannot be con-

centrated in replicated servers, but distributed in the

whole system based on local needs. Functional com-

ponents that need to have access to such data should

address a proxy, which makes available the requested

information, or add/delete a descriptor. An LDAP

directory provides a ﬁrst approximation of such en-

tity: however, descriptors are not organized hierarchi-

cally. A better alternative is an adaptive caching of

those descriptors that are considered locally relevant:

for instance, the descriptor of a monitoring session

might be cached in a GIS proxy near the monitored

resource. Descriptors are diffused in the system using

a low footprint, low performance broadcast protocol,

and cached wherever needed.

The volatile data is represented by data that

change during the execution of a job: a typical ex-

ample is the workload of a computing element. Such

data are produced by one of the components de-

scribed in the previous section, and made available

to a restricted number of other components. The

storage into a globally accessible facility, included

a distributed relational database, seems inappropri-

ate since the information is usually transferred from a

source to a limited number of destinations. The con-

cept that is usually applied to solve such kind of prob-

lems is the multicast.

A multicast facility appropriate for diffusing

volatile data of a Grid Information System has many

points in common with a Voice over IP infrastructure:

the container of the communication is similar to a Ses-

sion (as deﬁned in the SIP protocol). In contrast with

a typical VoIP application, the data trasfer within a

session in mainly uni-directional and requires a low

bandwidth with moderate real time requirements: we

call streams the information ﬂows associated to the

trasport of volatile data within a Grid Information

System.

All of the components outlined in section 2 are

able to initiate or accept a session with another com-

ponent: security issues are coped with using the de-

scriptors associated with the agents. E.g., a Resource

will accept a call only from a Workﬂow analyzer that

submitted a job. Here we outline some of the relevant

streams:

Resource usage stream It is originated by a re-

source, like a Storage Element, and summarizes

the performance of the resource, as well as the

available share of it. Typical callers are the Work-

ﬂow Analyzer, either during the resource selection

or the execution phase.

Workﬂow advancement stream It is originated by a

Workﬂow Analyzer component, and reports the

caller about the workﬂow advancement. Typical

callers are user oriented interfaces.

One characteristic of a session, that makes it not

interchangeable with a directory service, is that the

establishment of a session has a relevant cost, which is

amortized only if the session persists for a signiﬁcant

time interval. For this reason we include sessions in

the number of entities that have a descriptor recorded

in the Grid Information Service.

Such descriptor advertizes the existence of a given

session: it is a task of the callee to create and make

available an appropriate Session descriptor, as out-

lined above. Sessions can be activated on demand,

or be permanently available: such option depends on

the balance between the workload needed to activate

a new session on demand, and of keeping it warm for

connection. E.g., Network Monitoring sessions will

be mostly activated on demand, while Storage usage

statistics can be maintained permanently active.

4 COMPARISON WITH OTHER

WORKS

The architecture we propose takes into account the

goals and achievements of a number of scientiﬁc, as

well as industrial projects that accepted the challenges

proposed by the design of an effective grid infrastruc-

ture.

WEBIST 2007 - International Conference on Web Information Systems and Technologies

One outstanding project which is being developed

to meet the requirements the scientiﬁc community is

gLite: it is developed within the European EGEE

project, the successor of DATAGRID. Its purpose is to

capitalize tools and experience matured in the course

of DATAGRID, in order to assemble a Grid infrastruc-

ture usable for high performance computation, ﬁrst

the LHC experiment on schedule for the next year.

We consider gLite (Laure et al., 2006) as a pre-

cious source of experience about a real scale Grid en-

vironment. We considered as relevants the inclusion

of a number of features that are not considered, or

considered at an embrional level, in gLite. Namely,

we introduce a speciﬁc component that takes into ac-

count job checkpointing, we adopt a more powerful

workﬂow description language (but gLite is working

towards a DRMAA (Rajic et al., 2004) compliant in-

terface), we take into account the task of workﬂow

monitoring under scalability requirements, also con-

sidering networking resources, we differentiate the

functionality of the GIS into a high latency direc-

tory service, and a multicast real-time streaming ser-

vice. Overall, with respect to gLite, we considered the

need for a wide portability: although such problem

is not overly relevant for the environment for which

gLite has been developed, we considered it relevant

in a broader scope. To improve portability we sug-

gest the realization of an integrated framework for the

whole infrastructure, hosting legacy components en-

capsulated in speciﬁc wrappers.

With respect to implementations based on the DR-

MAA proposed standard (Rajic et al., 2004) we con-

sider the interactions between Resource Management

and Checkpointing, since we observe that the re-

source management is the component in charge of in-

structing the resource about activities relevant to re-

covery and relocation of running jobs. Therefore we

describe an interface between a component in charge

of managing a transparent management of check-

points, and another in charge of interpreting user re-

quests.

The N1GE by Sun (Bulhes et al., 2004) is consid-

ered as a relevant representative of the industrial effort

towards the implementation of a Grid infrastructure.

Such project recognises the problems arising from the

adoption of a monolythic relational database, and ad-

heres to the DRMAA standards as for job descrip-

tions. In order to overcome scalability limits imposed

by a monolythic databases, it adopts a more ﬂexible

commercial database, Berkeley DB (BerkeleyDB, ).

In our proposal we identify the kind of services of

interest for our infrastructure, and indicate comple-

mentary solutions, that cannot be assimilated to a re-

lational database. This should improve scalability and

resource usage.

The focus of the GPE (Ratering, 2005) prototype

by Intel is to bridge users from non-Grid environ-

ments, and to provide an interface that will remain

sufﬁciently stable in the future, shielding the user

from the changes of a still evolving middleware tech-

nology. Therefore the focus is on the provision of

a powerful interface that adapts to several kinds of

users. In order to take advantage of legacy tools,

like UNICORE (UNICORE, 2003), security issues

are delegated to a speciﬁc component, the Security

Gateway, that enfoces a secure access to sensitive re-

sources. In our view this is a source of problems,

since the presence of a bottleneck limits the perfor-

mance of a system. Instead, we indicate a pervasive

attention to security issues, in order to implement ap-

propriate security issues inside each agent.

We pay special attention to a Grid resource that

is often overlooked: the network infrastructure. Such

resource is difﬁcult to represent and to monitor since,

unlike other resources, its complexity grows with the

square of system size. Yet this resource has a vital role

in a distributed system as a whole, since its availabil-

ity determines its performance, and directly reﬂects

on jobs performance.

5 CONCLUSIONS

CoreGRID is an European project whose primary

goal is to foster collaboration among european orga-

nizations towards the deﬁnition of an advanced Grid

architecture. One of the tasks that contributes to this

achievement is targeted at the description of an Inte-

grated Framework for Resource and Workﬂow Moni-

toring. In order to enforce integration since the early

steps, the research and development activities from

several research groups are included in the same con-

tainer, with frequent and planned meetings.

This paper presents an early result on this way, af-

ter two years from the beginning of the project. We

have tried to understand the problems left opened by

other similar initiatives, speciﬁcally aiming at scal-

ability and security issues, and identiﬁed the actors

inside our framework. The research groups have pro-

duced relevant results for each of them that are only

summarized in this paper; instead, we focus on the

integration among such actors, based on descriptors

advertised in the Grid Information Service.

GRID INFRASTRUCTURE ARCHITECTURE - A Modular Approach from CoreGRID

ACKNOWLEDGEMENTS

This research work is carried out under the FP6 Net-

work of Excellence CoreGRID funded by the Euro-

pean Commission (Contract IST-2002-004265).”

REFERENCES

Aiftimiei, C., Andreozzi, S., Cuscela, G., Bortoli, N. D.,

Donvito, G., Fantinel, S., Fattibene, E., Misurelli,

G., Pierro, A., Rubini, G., and Tortone, G. (2006).

GridICE: Requirements, architecture and experience

of a monitoring tool for grid systems. In Proceedings

of the International Conference on Computing in High

Energy and Nuclear Physics (CHEP2006), Mumbai -

India.

Andreozzi, S., De Bortoli, N., Fantinel, S., Ghiselli, A., Ru-

bini, G., Tortone, G., and Vistoli, C. (2005). GridICE:

a monitoring service for Grid systems. Future Gener-

ation Computer Systems Journal, 21(4):559–571.

BerkeleyDB. Diverse needs, database choices. Technical

report, Sleepycat Software Inc.

Bulhes, P. T., Byun, C., Castrapel, R., and Hassaine, O.

(2004). N1 grid engine 6 – features and capabilities.

Technical report, SUPerG.

Ciuffoletti, A. and Polychronakis, M. (2006). Architecture

of a network monitoring element. Technical Report

TR-0033, CoreGRID.

Deelman, E., Blythe, J., Gil, Y., Kesselman, C., Mehta, G.,

Vahi, K., Blackburn, K., Lazzarini, A., Arbree, A.,

Cavanaugh, R., and Koranda, S. (2003). Mapping

abstract complex workﬂows onto grid environments.

Journal of Grid Computing, 1(1):25–39.

Denemark, J., Jankowski, M., Matyska, L., Meyer, N.,

Ruda, M., and Wolniewicz, P. (2005). Usermanage-

ment for virtual organizations. Technical Report TR-

0012, CoreGRID.

Foster, I., Kesselman, C., Nick, J., and Tuecke, S. (2002).

The physiology of the grid: An open grid services ar-

chitecture for distributed systems integration.

Jankowski, G., Januszewski, R., Mikolajczak, R., and Ko-

vacs, J. (2006). Grid checkpointing architecture - a re-

vised proposal. Technical Report TR0036, CoreGRID

- Network of Excellence.

Jankowski, G., Kovacs, J., Meyer, N., Januszewski, R., and

Mikolajczak, R. (2005). Towards Checkpointing Grid

Architecture. In PPAM2005 proceedings.

Krajicek, O., Ceccanti, A., Krenek, A., Matyska, L., and

Ruda, M. (2006). Designing a distributed mediator for

the C-GMA monitoring architecture. In In Proc. of the

DAPSYS 2006 Conference, page to appear, Innsbruck.

Laure, E., Fisher, S., Frohner, A., Grandi, C., Kunszt, P.,

Krenek, A., Mulmo, O., Pacini, F., Prelz, F., White, J.,

Barroso, M., Buncic, P., Hemmer, F., Meglio, A. D.,

and Edlund, A. (2006). Programming the grid with

glite. Technical Report EGEE-TR-2006-001, EGEE.

Rajic, H., Brobst, R., Chan, W., Ferstl, F., Gardiner, J.,

Haas, A., Nitzberg, B., and Tollefsrud, J. (2004).

Distributed resource management application API

speciﬁcation. Technical report, Global Grid Fo-

rum. http://www.ggf.org/documents/GWD-R/GFD-

R.022.pdf.

Ratering, R. (2005). Grid programming environment (GPE)

concepts. Technical report, Intel Corporation.

Stone, N., Simmel, D., and Kielmann, T. (2005). An ar-

chitecture for grid checkpoint and recovery (gridcpr)

services and a gridcpr application programming inter-

face. Technical report, Global Grid Forum. draft.

Tierney, B., Aydt, R., Gunter, D., Smith, W., Swany, M.,

Taylor, V., and Wolski, R. (2002). A grid monitoring

architecture. Technical Report GFD 1.7, Global Grid

Forum.

UNICORE (2003). UNICORE plus ﬁnal report. Technical

report, BMBF Project UNICORE Plus.

WEBIST 2007 - International Conference on Web Information Systems and Technologies