Grid Architectur

8/7/2019 Grid Architectur

http://slidepdf.com/reader/full/grid-architectur 1/28

Grid Computing

1 Dept. of Computer Science & Engineering, NIT Agartala

GRID COMPUTING

A seminar report submitted for the partial fulfilment of the requirements

for the degree

of

MASTER OF TECHNOLOGY

In

Computer science & Engineering

ByBraja Gopal Patra

Under the Supervision of

Anita Padhi Asst. Professor

Department of Computer Sc. & Engg.

Department of Computer Science & Engineering

NATIONAL INSTITUTE OF TECHNOLOGY, AGARTALABarjala-799055, Tripura, India

29th

April, 2011



Grid Computing


ABSTRACT

The last decade has seen a substantial increase in commodity computer and network

performance, mainly as a result of faster hardware and more sophisticated software.

Nevertheless, there are still problems, in the fields of science, engineering, and business,

which cannot be effectively dealt with using the current generation of supercomputers. In

fact, due to their size and complexity, these problems are often very numerically and/or data

intensive and consequently require a variety of heterogeneous resources that are not

available on a single machine. A number of teams have conducted experimental studies on

the cooperative use of geographically distributed resources unified to act as a single

powerful computer. This new approach is known by several names, such as metacomputing,

scalable computing, global computing, Internet computing, and more recently G rid

computing .

The early efforts in Grid computing started as a project to link supercomputing

sites, but have now grown far beyond their original intent. In fact, many applications can

benefit from the Grid infrastructure, including collaborative engineering, data exploration,

high-throughput computing, and of course distributed supercomputing. Moreover, due to the

rapid growth of the Internet and Web, there has been a rising interest in Web-based

distributed computing, and many projects have been started and aim to exploit the Web as

an infrastructure for running coarse-grained distributed and parallel applications. In this

context, the Web has the capability to be a platform for parallel and collaborative work as

well as a key technology to create a pervasive and ubiquitous Grid-based infrastructure.



Grid Computing


ACKNOWLEDGEMENT

I would like to take this opportunity to express my deepest gratitude to all the people,who in various ways lent me their helping hands to achieve my dreams of successfully the

Seminar Report on ³Grid Computing´.

I shall be always indebted to my parents & friends, who taught me to respect elders,gave me a place to stand in this world for inception of very existence, always encouraged me

to do my best and provided necessary support of all kinds to achieve the power of knowledge.

I owe a deep gratitude to my Guide Mrs.Anita Padhi Asst. Professor Dept. of

Computer Sc. & Engg, who provided me the opportunity to work under him. I am thankful tohim for his affection towards me & for his valuable time to teach me on the topic in spite of

his busy schedule.

I also owe my deep gratitude to my honorable HOD Associate Prof. Diptendu

Bhattacharya & co-ordinator Mr.Nirmalya Kar, Asst. Professor & Faculties of CSE Dept. of

³ NIT,Agartala´ who encouraged me & inspired me to complete this Seminar Reportsuccessfully.

Last but not least, a special thanks to all of them who could not find a note of mention

in this Seminar Report.

BRAJA GOPAL PATRA

M.TECH CSE 2 ND SEM

ROLL NO.-10PCS001

NIT AGARTALA



Grid Computing


CERTIFICATE

This is to certify that the Seminar entitled ³Grid Computing´ has been

submitted by Braja Gopal Patra under my guidance in partial fulfillment of

the degree of Master of Technology in Computer Engineering of NIT, Agartala

during the academic year 2010-2011.

Anita Padhi Diptendu Bhattacharya (Asst. Professor & Guide) (Associate Prof. & HOD, CSE Dept.)



Grid Computing


CONTENTS

1. INTRODUCTION 1

.1.1 Benefits of Grid Computing 3

.1.2 Levels of Deployment 4

2. GRID CONSTRUCTION: GENERAL PRINCIPLES

2.2 Design Features 6

3 GRID ARCHITECTURE

3.1 Fabric: Interfaces to Local Control 9

3.2 Connectivity: Communicating Easily and Securely 10

3.3 Resource: Sharing Single Resources 11

3.4 Collective: Coordinating Multiple Resources 11

3.5 Applications 13

4 THREATS IN GRID 15

5 SECURITY MEASURES

5.1 PKI Infrastructure 15

5.2 Kerberos 16

5.3 SAML and Identity Federations 17

5.4 Passwords 18

5.5 Credential Transitions 18

6 GRID APPLICATIONS

6.1 Distributed Supercomputing 19

6.2 High-Throughput Computing 20

6.3 On-Demand Computing 20

6.4 Data-Intensive Computing 21

6.5 Collaborative Computing 21

7 CONCLUSIONS 23

8 REFERENCES 23



Grid Computing


Grids enable the sharing, selection, and aggregation of a wide variety of resources

including supercomputers, storage systems, data sources, and specialized devices (see

Figure 1)that are geographically distributed and owned by different organizations for

solving large-scale computational and data intensive problems in science, engineering, and

commerce. Thus creating virtual organizations and enterprises as a temporary alliance of

enterprises or organizations that come together to share resources and skills, core

competencies, or resources in order to better respond to business opportunities or large-scale

application processing requirements, and whose cooperation is supported by computer

networks.

The concept of Grid computing started as a project to link geographically dispersed

supercomputers, but now it has grown far beyond its original intent. The Grid infrastructure

can benefit many applications, including collaborative engineering, data exploration, high-

throughput computing, and distributed supercomputing.

A Grid can be viewed as a seamless, integrated computational and collaborative

environment (see Figure 1). The users interact with the Grid resource broker to solve

problems, which in turn performs resource discovery, scheduling, and the processing of

application jobs on the distributed Grid resources. From the end-user point of view, Grids

can be used to provide the following types of services.

C omputational services: These are concerned with providing secure services for executing

application jobs on distributed computational resources individually or collectively.

Resources brokers provide the services for collective use of distributed resources. A Grid

providing computational services is often called a computational Grid. Some examples of

computational Grids are: NASA IPG, the World Wide Grid, and the NSF TeraGrid .

Data services: These are concerned with proving secure access to distributed datasets and

their management. To provide a scalable storage and access to the data sets, they may be

replicated, catalogued, and even different datasets stored in different locations to create an

illusion of mass storage. The processing of datasets is carried out using computational Grid

services and such a combination is commonly called data Grids. Sample applications that

need such services for management, sharing, and processing of large datasets are high-

energy physics and accessing distributed chemical databases for drug design.

Application services: These are concerned with application management and providing

access to remote software and libraries transparently. The emerging technologies such as

Web services are expected to play a leading role in defining application services. They build

on computational and data services provided by the Grid. An example system that can be

used to develop such services is NetSolve.

Information services: These are concerned with the extraction and presentation of data with

meaning by using the services of computational, data, and/or application services. The low-



Grid Computing


level details handled by this are the way that information is represented, stored, accessed,

shared, and maintained. Given its key role in many scientific endeavors, the Web is the

obvious point of departure for this level.

K nowledge service:These are concerned with the way that knowledge is acquired, used,

retrieved, published, and maintained to assist users in achieving their particular goals and

objectives. Knowledge is understood as information applied to achieve a goal, solve a

problem, or execute a decision. An example of this is data mining for automatically building

a new knowledge.

To build a Grid, the development and deployment of a number of services is

required. These include security, information, directory, resource allocation, and payment

mechanisms in an open environment and high-level services for application development,

execution management, resource aggregation, and scheduling.

Grid applications (typically multidisciplinary and large-scale processing

applications) often couple resources that cannot be replicated at a single site, or which may

be globally located for other practical reasons. These are some of the driving forces behind

the foundation of global Grids. In this light, the Grid allows users to solve larger or new

problems by pooling together resources that could not be easily coupled before. Hence, the

Grid is not only a computing infrastructure, for large applications, it is a technology that can

bond and unify remote and diverse distributed resources ranging from meteorological

sensors to data vaults and from parallel supercomputers to personal digital organizers. As

such, it will provide pervasive services to all users that need them.

1.1 Benefits of Grid Computing

Grid computing can provide many benefits not available with traditional computing

models:

Better utilization of resources ² Grid computing uses distributed resources more efficiently

and delivers more usable computing power. This can decrease time-to-market, allow for

innovation, or enable additional testing and simulation for improved product quality. By

employing existing resources, grid computing helps protect IT investments, containing costs

while providing more capacity.

Increased user productivity ² By providing transparent access to resources, work can be

completed more quickly. Users gain additional productivity as they can focus on design and

development rather than wasting valuable time hunting for resources and manually

scheduling and managing large numbers of jobs.



Grid Computing


Scalability ² Grids can grow seamlessly over time, allowing many thousands of processors

to be integrated into one cluster. Components can be updated independently and additional

resources can be added as needed, reducing large one-time expenses.

F lexibility ² Grid computing provides computing power where it is needed most, helping to

better meet dynamically changing work loads. Grids can contain heterogeneous compute

nodes, allowing resources to be added and removed as needs dictate.

1.2 Levels of Deployment

Grid computing can be divided into three logical levels of deployment: Cluster

Grids, Enterprise Grids, and Global Grids.

1.2.1 C luster G rids

The simplest form of a grid, a Cluster Grid consists of multiple systemsinterconnected through a network. Cluster Grids may contain distributed workstations and

servers, as well as centralized resources in a datacenter environment. Typically owned and

used by a single project or department, Cluster Grids support both high throughput and high

performance jobs. Common examples of the Cluster Grid architecture include compute

farms, groups of multi-processor HPC systems, Beowulf clusters, and networks

ofworkstations (NOW).

F igure 2 Three levels of grid computing: cluster, enterprise, and global grids.



Grid Computing


1.2.2 Enterprise G rids

As capacity needs increase, multiple Cluster Grids can be combined into an

Enterprise Grid. Enterprise Grids enable multiple projects or departments to share

computing resources in a cooperative way. Enterprise Grids typically contain resources

from multiple administrative domains, but are located in the same geographic location.

1.2.3 G lobal G rids

Global Grids are a collection of Enterprise Grids, all of which have agreed upon

global usage policies and protocols, but not necessarily the same implementation.

Computing resources may be geographically dispersed, connecting sites around the globe.

Designed to support and address the needs of multiple sites and organizations sharing

resources, Global Grids provide the power of distributed resources to users anywhere in the

world.

2.

GRID CONSTRUCTION: GENERAL PRINCIPLES

This section briefly highlights some of the general principles that underlie the

construction of the Grid. In particular, the idealized design features that are required by a

Grid to provide users with a seamless computing environment are discussed. Four main

aspects characterize a Grid.

M ultiple administrative domains and autonomy: Grid resources are geographically

distributed across multiple administrative domains and owned by different organizations.

The autonomy of resource owners needs to be honored along with their local resource

management and usage policies.

H eterogeneit y:A Grid involves a multiplicity of resources that are heterogeneous in nature

and will encompass a vast range of technologies.

Scalabilit y: A Grid might grow from a few integrated resources to millions. This raises the

problem of potential performance degradation as the size of Grids increases. Consequently,

applications that require a large number of geographically located resources must be

designed to be latency and bandwidth tolerant.

D ynamicity or adaptabilit y: In a Grid, resource failure is the rule rather than the exception.

In fact, with so many resources in a Grid, the probability of some resource failing is high.

Resource managers or applications must tailor their behavior dynamically and use the

available resources and services efficiently and effectively.



Grid Computing


2.1 Design Features:

The following are the main design features required by a Grid environment.

Administrative hierarchy:An administrative hierarchy is the way that each Grid

environment divides itself up to cope with a potentially global extent. The administrative

hierarchy determines how administrative information flows through the Grid.

C ommunication services:The communication needs of applications using a Grid

environment are diverse, ranging from reliable point-to-point to unreliable multicast

communications. The communications infrastructure needs to support protocols that are used

for bulk-data transport, streaming data, group communications, and those used by distributed

objects. The network services used also provide the Grid with important QoS parameters

such as latency, bandwidth, reliability, fault-tolerance, and jitter control.

Information services A Grid is a dynamic environment where the location and types of services available are constantly changing. A major goal is to make all resources accessible

to any process in the system, without regard to the relative location of the resource user. It is

necessary to provide mechanisms to enable a rich environment in which information is

readily obtained by requesting services. The Grid information (registration and directory)

services components provide the mechanisms for registering and obtaining information

about the Grid structure, resources, services, and status.

N aming services: In a Grid, like in any distributed system, names are used to refer to a wide

variety of objects such as computers, services, or data objects. The naming service provides

a uniform name space across the complete Grid environment. Typical naming services are provided by the international X.500 naming scheme or DNS, the Internet¶s scheme.

Distributed file systems and caching: Distributed applications, more often than not, require

access to files distributed among many servers. A distributed file system is therefore a key

component in a distributed system. From an applications point of view it is important that a

distributed file system can provide a uniform global namespace, support a range of file I/O

protocols, require little or no program modification, and provide means that enable

performance optimizations to be implemented, such as the usage of caches.

Security and authorization:Any distributed system involves all four aspects of security:

confidentiality, integrity, authentication, and accountability. Security within a Grid

environment is a complex issue requiring diverse resources autonomously administered to

interact in a manner that does not impact the usability of the resources or introduces security

holes/lapses in individual systems or the environments as a whole. A security infrastructure

is the key to the success or failure of a Grid environment.



Grid Computing


System status and fault tolerance: To provide a reliable and robust environment it is

important that a means of monitoring resources and applications is provided. To accomplish

this task, tools that monitor resources and application need to be deployed.

Resource management and scheduling: The management of processor time, memory,

network, storage, and other components in a Grid is clearly very important. The overall aims

to efficiently and effectively schedule the applications that need to utilize the available

resources in the Grid computing environment. From a user¶s point of view, resource

management and scheduling should be transparent; their interaction with it being confined to

a manipulating mechanism for submitting their application. It is important in a Grid that a

resource management and scheduling service can interact with those that may be installed

locally.

C omputational economy and resource trading: As a Grid is constructed by coupling

resources distributed across various organizations and administrative domains that may be

owned by different organizations, it is essential to support mechanisms and policies that help

in regulate resource supply and demand. An economic approach is one means of managing

resources in a complex and decentralized manner. This approach provides incentives for

resource owners, and users to be part of the Grid and develop and using strategies that help

maximize their objectives.

P rogramming tools and paradigms: Grid applications (multi-disciplinary applications)

couple resources that cannot be replicated at a single site even or may be globally located for

other practical reasons. A Grid should include interfaces, APIs, utilities, and tools to provide

a rich development environment. Common scientific languages such as C, C++, and

FORTRAN should be available, as should application-level interfaces such as MPI andPVM. A variety of programming paradigms should be supported, such as message passing

or distributed shared memory. In addition, a suite of numerical and other commonly used

libraries should be available.

User and administrative G U I: The interfaces to the services and resources available should

be intuitive and easy to use. In addition, they should work on a range of different platforms

and operating systems. They also need to take advantage of Web technologies to offer a

view of portal supercomputing. The Web-centric approach to access supercomputing

resources should enable users to access any resource from anywhere over any platform at

any time. That means, the users should be allowed to submit their jobs to computational

resources through a Web interface from any of the accessible platforms such as PCs, laptops,

or Personal Digital Assistant, thus supporting the ubiquitous access to the Grid. The

provision of access to scientific applications through the Web (e.g. RWCPs parallel protein

information analysis system) leads to the creation of science portals.



Grid Computing


3. GRID ARCHITECTURE

Our goal in describing our Grid architecture is not to provide a complete

enumeration of all required protocols (and services, APIs, and SDKs) but rather to identify

requirements for general classes of component. The result is an extensible, open

architectural structure within which can be placed solutions to key VO requirements. Our

architecture and the subsequent discussion organize components into layers, as shown in

Figure. Components within each layer share common characteristics but can build on

capabilities and behaviors provided by any lower layer.

In specifying the various layers of the Grid architecture, we follow the principles of

the ³hourglass model´. The narrow neck of the hourglass defines a small set of core

abstractions and protocols (e.g., TCP and HTTP in the Internet), onto which many different

high-level behaviors can be mapped (the top of the hourglass), and which themselves can be

mapped onto many different underlying technologies (the base of the hourglass). By

definition, the number of protocols defined at the neck must be small. In our architecture,

the neck of the hourglass consists of Resource and Connectivity protocols, which facilitate

the sharing of individual resources. Protocols at these layers are designed so that they can be

implemented on top of a diverse range of resource types, defined at the F abric layer, and

can in turn be used to construct a wide range of global services and application-specific

behaviors at the Collective layer ² so called because they involve the coordinated

(³collective´) use of multiple resources.

F igure2. The layered Grid architecture and its relationship to the Internet

protocol architecture. Because the Internet protocol architecture extends

from network to application, there is a mapping from Grid layers into

Internet layers.



Grid Computing


3.1 Fabric: Interfaces to Local Control

The Grid F abric layer provides the resources to which shared access is mediated by

Grid protocols: for example, computational resources, storage systems, catalogs, network

resources, and sensors. A ³resource´ may be a logical entity, such as a distributed file

system, computer cluster, or distributed computer pool in such cases, a resource

implementation may involve internal protocols (e.g., the NFS storage access protocol or a

cluster resource management system¶s process management protocol), but these are not the

concern of Grid architecture.

Fabric components implement the local, resource-specific operations that occur on

specific resources (whether physical or logical) as a result of sharing operations at higher

levels. There is thus a tight and subtle interdependence between the functions implemented

at the Fabric level, on the one hand, and the sharing operations supported, on the other.

Richer Fabric functionality enables more sophisticated sharing operations at the same time,

if we place few demands on Fabric elements, then deployment of Grid infrastructure issimplified. For example, resource-level support for advance reservations makes it possible

for higher-level services to aggregate (coschedule) resources in interesting ways that would

otherwise be impossible to achieve. However, as in practice few resources support advance

reservation ³out of the box,´ a requirement for advance reservation increases the cost of

incorporating new resources into a Grid.

Experience suggests that at a minimum, resources should implement enquiry

mechanisms that permit discovery of their structure, state, and capabilities (e.g., whether

they support advance reservation) on the one hand, and resource management mechanisms

that provide some control of delivered quality of service, on the other. The following brief and partial list provides a resource-specific characterization of capabilities.

C omputational resources: Mechanisms are required for starting programs and for

monitoring and controlling the execution of the resulting processes. Management

mechanisms that allow control over the resources allocated to processes are useful, as are

advance reservation mechanisms. Enquiry functions are needed for determining hardware

and software characteristics as well as relevant state information such as current load and

queue state in the case of scheduler-managed resources.

Storage resources: Mechanisms are required for putting and getting files. Third-party and

high-performance (e.g., striped) transfers are useful. So are mechanisms for reading and

writing subsets of a file and/or executing remote data selection or reduction functions.

Management mechanisms that allow control over the resources allocated to data transfers

(space, disk bandwidth, network bandwidth, CPU) are useful, as are advance reservation

mechanisms. Enquiry functions are needed for determining hardware and software



Grid Computing


characteristics as well as relevant load information such as available space and bandwidth

utilization.

N etwork resources: Management mechanisms that provide control over the resources

allocated to network transfers (e.g., prioritization, reservation) can be useful. Enquiry

functions should be provided to determine network characteristics and load.

C ode repositories: This specialized form of storage resource requires mechanisms for

managing versioned source and object code: for example, a control system such as CVS.

C atalog s: This specialized form of storage resource requires mechanisms for implementing

catalog query and update operations: for example, a relational database.

3.2 Connectivity: Communicating Easily and Securely

The Connectivity layer defines core communication and authentication protocols

required for Grid-specific network transactions. Communication protocols enable theexchange of data between Fabric layer resources. Authentication protocols build on

communication services to provide cryptographically secure mechanisms for verifying the

identity of users and resources.

Communication requirements include transport, routing, and naming. While

alternatives certainly exist, we assume here that these protocols are drawn from the TCP/IP

protocol stack: specifically, the Internet (IP and ICMP), transport (TCP, UDP), and

application (DNS, OSPF, RSVP, etc.) layers of the Internet layered protocol architecture.

This is not to say that in the future, Grid communications will not demand new protocols

that take into account particular types of network dynamics.

With respect to security aspects of the Connectivity layer, we observe that the

complexity of the security problem makes it important that any solutions be based on

existing standards whenever possible. As with communication, many of the security

standards developed within the context of the Internet protocol suite are applicable.

Authentication solutions for VO environments should have the following characteristics:

Single sign on: Users must be able to ³log on´ (authenticate) just once and then have

access to multiple Grid resources defined in the Fabric layer, without further user

intervention.

Delegation: A user must be able to endow a program with the ability to run on that user¶s

behalf, so that the program is able to access the resources on which the user is authorized.

The program should (optionally) also be able to conditionally delegate a subset of its rights

to another program (sometimes referred to as restricted delegation).



Grid Computing


Integration with various local security solutions: Each site or resource provider may

employ any of a variety of local security solutions, including Kerberos and UNIX security.

Grid security solutions must be able to interoperate with these various local solutions. They

cannot, realistically, require wholesale replacement of local security solutions but rather

must allow mapping into the local environment.

User-based trust relationships: In order for a user to use resources from multiple providers

together, the security system must not require each of the resource providers to cooperate or

interact with each other in configuring the security environment. For example, if a user has

the right to use sites A and B, the user should be able to use sites A and B together without

requiring that A¶s and B¶s security administrators interact.

3.3 Resource: Sharing Single Resources

The Resource layer builds on Connectivity layer communication and authentication

protocols to define protocols (and APIs and SDKs) for the secure negotiation, initiation,monitoring, control, accounting, and payment of sharing operations on individual resources.

Resource layer implementations of these protocols call Fabric layer functions to access and

control local resources. Resource layer protocols are concerned entirely with individual

resources and hence ignore issues of global state and atomic actions across distributed

collections; such issues are the concern of the Collective layer discussed next.

Two primary classes of Resource layer protocols can be distinguished:

Information protocolsare used to obtain information about the structure and state of a

resource, for example, its configuration, current load, and usage policy (e.g., cost).

M anagement protocolsare used to negotiate access to a shared resource, specifying, for

example, resource requirements (including advanced reservation and quality of service) and

the operation(s) to be performed, such as process creation, or data access. Since management

protocols are responsible for instantiating sharing relationships, they must serve as a ³policy

application point,´ ensuring that the requested protocol operations are consistent with the

policy under which the resource is to be shared. Issues that must be considered include

accounting and payment. A protocol may also support monitoring the status of an operation

and controlling (for example, terminating) the operation.

3.4 Collective: Coordinating Multiple Resources

While the Resource layer is focused on interactions with a single resource, the next

layer in the architecture contains protocols and services (and APIs and SDKs) that are not

associated with any one specific resource but rather are global in nature and capture



Grid Computing


interactions across collections of resources. For this reason, we refer to the next layer of the

architecture as the Collective layer. Because Collective components build on the narrow

Resource and Connectivity layer ³neck´ in the protocol hourglass, they can implement a

wide variety of sharing behaviors without placing new requirements on the resources being

shared. For example:

Directory servicesallow VO participants to discover the existence and/or properties of VO

resources. A directory service may allow its users to query for resources by name and/or by

attributes such as type, availability, or load. Resource-level GRRP and GRIP protocols are

used to construct directories.

C o-allocation, scheduling, and brokering servicesallow VO participants to request the

allocation of one or more resources for a specific purpose and the scheduling of tasks on the

appropriate resources. Examples include Apple¶s, Condor-G, Nimrod-G, and the DRM

broker.

M onitoring and diagnostics servicessupport the monitoring of VO resources for failure,

adversarial attack (³intrusion detection´), overload, and so forth.

Data replication servicessupport the management of VO storage (and perhaps also network

and computing) resources to maximize data access performance with respect to metrics such

as response time, reliability, and cost.

G rid-enabled programming systemsenable familiar programming models to be used in Grid

environments, using various Grid services to address resource discovery, security, resource

allocation, and other concerns. Examples include Grid-enabled implementations of the

Message Passing Interface and manager-worker frameworks.

Workload management systems and collaboration framework s are also known as problem

solving environments (³PSEs´) ² provide for the description, use, and management of multi-

step, asynchronous, multi-component workflows

Software discovery servicesdiscover and select the best software implementation and

execution platform based on the parameters of the problem being solved. Examples include

NetSolve and Ninf.

C ommunity authorization serversenforce community policies governing resource access,

generating capabilities that community members can use to access community resources.

These servers provide a global policy enforcement service by building on resource

information, and resource management protocols (in the Resource layer) and security

protocols in the Connectivity layer. Akenti addresses some of these issues.

C ommunity accounting and payment servicesgather resource usage information for the

purpose of accounting, payment, and/or limiting of resource usage by community members.



Grid Computing


C ollaboratory servicessupport the coordinated exchange of information within potentially

large user communities, whether synchronously or asynchronously. Examples are

CAVERNsoft, Access Grid, and commodity groupware systems.

These examples illustrate the wide variety of Collective layer protocols and services

that are encountered in practice. Notice that while Resource layer protocols must be general

in nature and are widely deployed, Collective layer protocols span the spectrum from

general purpose to highly application or domain specific, with the latter existing perhaps

only within specific VOs.

Collective functions can be implemented as persistent services, with associated

protocols, or as SDKs (with associated APIs) designed to be linked with applications. In

both cases, their implementation can build on Resource layer (or other Collective layer)

protocols and APIs. For example, Figure shows a Collective co-allocation API and SDK

(the middle tier) that uses a Resource layer management protocol to manipulate underlying

resources. Above this, we define a co-reservation service protocol and implement a co-

reservation service that speaks this protocol, calling the co-allocation API to implement co-

allocation operations and perhaps providing additional functionality, such as authorization,

fault tolerance, and logging. An application might then use the co-reservation service

protocol to request end-to-end network reservations.

F igure3. Collective and Resource layer protocols, services, APIs, and SDKS

can be combined in a variety of ways to deliver functionality to applications.

Collective components may be tailored to the requirements of a specific user community, VO, or application domain, for example, an SDK that implements an

application-specific coherency protocol, or a co-reservation service for a specific set of

network resources. Other Collective components can be more general-purpose, for example,

a replication service that manages an international collection of storage systems for multiple

communities, or a directory service designed to enable the discovery of VOs. In general, the

larger the target user community, the more important it is that a Collective component¶s

protocol(s) and API(s) be standards based.



Grid Computing


3.5 Applications

The final layer in our Grid architecture comprises the user applications that operate

within a VO environment. Figure illustrates an application programmer¶s view of Grid

architecture. Applications are constructed in terms of, and by calling upon, services defined

at any layer. At each layer, we have well-defined protocols that provide access to some

useful service: resource management, data access, resource discovery, and so forth. At each

layer, APIs may also be defined whose implementation (ideally provided by third-party

SDKs) exchange protocol messages with the appropriate service(s) to perform desired

actions.

F igure4. APIs are implemented by software development kits (SDKs), which in turn

use Grid protocols to interact with network services that provide capabilities to the

end user. Higher level SDKs can provide functionality that is not directly mapped to

a specific protocol, but may combine protocol operations with calls to additional

APIs as well as implement local functionality. Solid lines represent a direct call; dash

lines protocol interactions.

We emphasize that what we label ³applications´ and show in a single layer in Figure 4 may

in practice call upon sophisticated frameworks and libraries (e.g., the Common Component

Architecture , SciRun , COR BA , Cactus, workflow systems) and feature much internal

structure that would, if captured in our figure, expand it out to many times its current size.These frameworks may themselves define protocols, services, and/or APIs. (E.g., the

Simple Workflow Access Protocol) However, these issues are beyond the scope of this

article, which addresses only the most fundamental protocols and services required in a

Grid.



Grid Computing


4. THREATS IN GRID

Unlike traditional cluster computing in which only a small number of users work in a

closed system, Grid computing exposes local clusters to a large number of users via the

Internet using open Grid middlewares such as Globus, gLite and Unicore. Like most

complex IT systems, hence middleware solutions exhibit a number of security problems

opening the entire system to attack. As a consequence, Grids are an attractive target for

intruders, since the Grid offers standardized access to a large number of machines, which

can be misused in various ways. The considerable computing power of clusters exposed via

the Grid can be used to break passwords, and the large storage capacity is perfect for storing

and sharing illegal software and data. The generous bandwidth of the Internet is ideal for

launching Denial-of-Service (DoS) attacks or for hosting file sharing services, to name just

a few attacks.

5. SECURITY MEASURE

5.1 PKI Infrastructure:

Asymmetric cryptography allows for efficient key management, especially in loosely

coupled distributed environment. The concept of two separated keys has been proven to

provide a scalable solution to parties that need to mutually communicate and do not share

any pre-distributed secret. As the simplest implementation of an asymmetric cryptography, a

plain key-pair can be used to establish an authentication connection. This approach is

employed by the popular ssh protocol, where such a simple publickey based authenticationis mandatory to implement and widely used. While it is convenient for users, experience

shows that having authentication based only on plain keys is not sufficient and is hard to

maintain in a large environment. The main drawbacks are a lack of information that a

particular public key is bound to and a lack of centralized mechanism that could be used to

revoke a public key if the corresponding private key becomes untrusted. These drawbacks

have been fully revealed recently, when vulnerability in some version of the openssl toolkit

was announced, which could cause that weak cryptographic material was generated. When

handling the vulnerability by the grid community, an audit has been performed to check all

Grid certificates. If a weak key for a certificate has been found, the certificate has been

revoked and the certificate owner asked to regenerate their certificate. This allowedresolving the issue quickly and centrally invalidate all vulnerable certificates. No such

precaution can be implemented for ssh keys deployed on many machines due to the lack of

centralized key management.



Grid Computing


5.1.1 PKI in Grids

Even though both SPKI and PGP offer interesting features, to our best knowledge they

are not used in any current Grid environment. Contemporary Grids that are based on PKI

either use the standard X.509 KI or they use a special form of digital certificates derived

from X.509. The former approach is employed by the UNICORE grid middleware, where

jobs are signed by the owner¶s private key before submission. In thebasic version, the

UNICORE infrastructure than uses the X.509 certificate to verify the signature during the

job processing. Other grid systems based on PKI use certificates in a different way. Instead

of creating long-lived digital signatures, they provide users with mechanism of single sign-

on (SSO) and credential delegation, which allows users to submit a job to or request an

operation at the infrastructure along with appropriate credentials. The credentials are used by

the job and middleware component to perform any operations that are necessary to complete

the job on the user¶s behalf. Proxy certificates are very often used as the mechanism

providing SSO and delegation. A proxy certificate is a special kind of X.509 certificate that

is signed by an ordinary user, not by a dedicated CA. The generation of a proxy certificate is

performed during the login stage by the user. Lifetime of proxy certificates is very short,

usually ten hours. Proxy certificates provide an efficient mechanism for SSO, however they

also present new issues. One of the most severe one is a lack of revocation mechanism that

could be used to revoke existing proxy certificate. Another issue concerns support of long-

running jobs and other operations that last longer than is the proxy lifetime. Despite a

renewal mechanism has been designed and implemented, it is not an ideal solution since it

requires introduction of an additional trusted component. Proxy certificates are often

managed using MyProxy, which provides a repository where proxy certificates stored and

later retrieved using a password or another credential assigned during the storing step. In

addition to support of the repository mode, a MyProxy server can also be configured to actas a CA issuing standard X.509 certificates. Regardless particular type of certificates or PKI,

one of the key drawbacks of the PKI is that current tools and producers for certificate

management are too complicated for users. This leads either to rejection of the PKI or to

insecure private-key management, which dis-empowers the entire Grid infrastructure.

5.2 Kerberos

Kerberosis an authentication protocol using a trusted central authentication service ²

Key Distribution Center (KDC). Each user and service shares a secret keywith KDC. KDC

issues tickets asserting identity of their bearers, which serve similarpurpose as public-key

certificates. A ticket has a limited lifetime but unlike public-keycertificates, it can be only

used against a particular end-service, which is specified in theticket. To support the SSO

principle, Kerberos uses a universal Ticket Granting Ticket(TGT) that is used to authenticate

against a KDC to retrieve tickets for end-services.Apart from supporting mutual

authentication of the peers, the Kerberos protocol alsoprovides means for message

encryption or integrity protection.Since a KDC holds a list of all users and services, every



Grid Computing


authentication amongusers and services involves contacting KDC. This feature makes it hard

to deployKerberos in highly distributed environments since users must be registered with

KDCfirst. In order to make Kerberos more scalable, the users¶ space can be divided

intoadministrative groups (realms), served by independent KDCs. The Kerberos cross-

realmauthentication mechanism allows seamless interoperability among different realms.

The current mechanism of establishing a cross-realm trusted relationship is one themost

serious obstacles that prevent from using Kerberos-based infrastructure in Gridsystems. In

order to create such a relationship, the KDC administrators must meetto exchange cross-

realm keys, which do not scale in large infrastructure. However,Kerberos has become a de-

facto standard for local security infrastructures operated bymany institutions. There are

several Kerberos implementations available today, bothopen-source and commercial.

5.3 SAML and Identity Federations

Federating institutions has becoming very popular recently, because it allows users toco-

operate in a secure manner. The concept of federation can be applied to

environmentoperating both Kerberos and PKI, but in this section we primarily focus on

system based on the Shibboleth infrastructure.An identity federation is an infrastructure

connecting user management systemsfrom different institutions to provide standardized

access to information about usersmaintained by their systems. Federations provide a

standardized platform to whichsystems for user management and end applications can

connect and share authenticationand authorization data. Every organization participating in a

federation manages itsusers by a local user management system. An Identity Provider (IdP)

service is builton the top of each local user management system, providing a standardized

interfaceto access authentication information and other attributes about the users. Any partyinthe federation can get this information by calling the IdP service using a

standardizedprotocol. End services (Service Providers ² SP) are able to process the data

returned bythe user¶s home IdP and use them to make access control decisions. Before users

areallowed to use a service, they have to present a set of attributes issued and signed bytheir

home IdP. These attributes are provided to users or to a service working on theirbehalf upon

proper authentication of the user with the IdP.The major advantage of using the federation

model lies in the fact that users use theirhome institution¶s credentials to access any service

in a federation. Whenever users accessa service (SP) and do not have an authenticated

session activated, they are redirectedto their home IdP to authenticate. After successful

authentication they are sent back tothe SP along with additional information about their

identity added by the IdP. The SPaccepts this authentication assessment since it trusts the

IdP, and applies appropriateaccess control methods. Every SP in the federation uses this

mechanism transparentlyfrom the user¶s point of view. There is no need to introduce new

credentials for every newservice or to synchronize existing credentials (like passwords)

among different services.Having no additional credentials also means there is no need to

distribute them among theusers. Such an arrangement not only eases credential management

but also makes it moresecure, as users are only required to maintain one piece of



Grid Computing


authentication informationand always authenticate at the same (web) interface. Unlike PKI,

the federation model ismore acceptable to the users, as it is not tied to any particular

authentication method andinstitutions can select the most appropriate method for their users.

5.4 Passwords

Passwords are very often used to user¶s authentication in computer systems.

Regardlessthe popularity of passwords, they can hardly be used for authentication to Grid

servicessince they do not provide SSO. However, passwords are still usually used in Gridsto

initial login to the infrastructure, i.e., to access private keys in files or MyProxyrepositories,

obtain a Kerberos tickets, etc.One interesting implementation of passwords is one-time

passwords (OTP) that canbe used even from untrusted location since their potential sniffing

does not cause anyharm. As suggested by the name, an OTP can be used once and is not

accepted forauthentication after using. There are several solutions that provide support for

OTP,including specialized devices for OTP generation (including proprietary solutions

basedon tokens RSA SecurID or CryptoCard).

5.5 Credential Transitions

Virtually all current grid systems support only a single authentication mechanism

anddo not provide any coordinated way how a user could smoothly change their

credentialtypes. Ideally such transitions would be also supported by the middleware that

couldobtain a credential type according to the needs of the end service or another

middlewarecomponent. Such a capability would ease integration of a Grid with other

systems thatrequire different authentication mechanisms. In this section we provide an

overviewof transition mechanisms that are available from current security components.

Wehave tested all the transition described and also contributed to development of

severalcomponents and mechanisms involved. A schema of transitions can be seen in Fig.

3.The main use-case we have in mind is to ease users¶ work and allow them to use abroader

scale of authentication methods instead of dictating a particular one. Accordingto our

experience, if an infrastructure is sufficiently easy to use, it is also safer sinceusers do not

pass over barriers using insecure techniques (such as uncontrolled copyingof private keys,

etc.).



Grid Computing


F igure5: Schema Transition

6. GRID APPLICATIONS

What types of applications will grids are used for? Building on experiences in

gigabittestbeds, the I-WAY network, and other experimental systems, we have identifiedfive major application classes for computational grids, and described briefly in this section.

More details about applications and their technical requirements are provided in the

referenced chapters.

6.1 Distributed Supercomputing

Distributed supercomputing applications use grids to aggregate substantial

computational resources in order to tackle problems that cannot be solved on a single

system. Depending on the grid on which we are working, these aggregated resources might

comprise the majority of the supercomputers in the country or simply all of the workstations

within a company. Here are some contemporary examples:

Distributed interactive simulation (DIS) is a technique used for training and planning

in the military. Realistic scenarios may involve hundreds of thousands of entities, each with

potentially complex behavior patterns. Yet even the largest current supercomputers can

handle at most 20,000 entities. In recent work, researchers at the California Institute of



Grid Computing


Technology have shown how multiple supercomputers can be coupled to achieve record-

breaking levels of performance.

The accurate simulation of complex physical processes can require high spatial and

temporal resolution in order to resolve fine-scale detail. Coupled supercomputers can be

used in such situations to overcome resolution barriers and hence to obtain qualitatively new

scientific results. Although high latencies can pose significant obstacles, coupled

supercomputers have been used successfully in cosmology, high-resolution abinitio

computational chemistry computations, and climate modeling.

Challenging issues from a grid architecture perspective include the need to co schedule

what are often scarce and expensive resources, the scalability of protocols and algorithms to

tens or hundreds of thousands of nodes, latency-tolerant algorithms, and achieving and

maintaining high levels of performance across heterogeneous systems.

6.2 High-Throughput Computing

In high-throughput computing, the grid is used to schedule large numbers of loosely

coupled or independent tasks, with the goal of putting unused processor cycles (often from

idle workstations) to work. The result may be, as in distributed supercomputing, the

focusing of available resources on a single problem, but the quasi-independent nature of the

tasks involved leads to very different types of problems and problem-solving methods. Here

are some examples:

Platform Computing Corporation reports that the microprocessor manufacturer

Advanced Micro Devices used high-throughput computing techniques to exploit over athousand computers during the peak design phases of their K6 and K7 microprocessors.

These computers are located on the desktops of AMD engineers at a number of AMD sites

and were used for design verification only when not in use by engineers.

The Condor system from the University of Wisconsin is used to manage pools of

hundreds of workstations at universities and laboratories around the world. These resources

have been used for studies as diverse as molecular simulations of liquid crystals, studies of

ground penetrating radar, and the design of diesel engines.More loosely organized efforts

have harnessed tens of thousands of computers distributed worldwide to tackle hard

cryptographic problems.

6.3 On-Demand Computing

On-demand applications use grid capabilities to meet short-term requirements for

resources that cannot be cost effectively or conveniently located locally. These resources

may be computation, software, data repositories, specialized sensors, and so on. In contrast



Grid Computing


to distributed supercomputing applications, these applications are often driven by cost-

performance concerns rather than absolute performance.

For example:

The NEOS and NetSolve network-enhanced numerical solver systems allow users to

couple remote software and resources into desktop applications, dispatching to remote

servers calculations that are computationally demanding or that require specialized software.

A computer-enhanced MRI machine and scanning tunneling microscope (STM) developed

at the National Center for Supercomputing Applications use supercomputers to achieve real

time image processing. The result is a significant enhancement in the ability to understand

what we are seeing and, in the case of the microscope, to steer the instrument.

A system developed at the Aerospace Corporation for processing of data from

meteorological satellites uses dynamically acquired supercomputer resources to deliver the

results of a cloud detection algorithm to remote meteorologists in quasi real time.

The challenging issues in on-demand applications derive primarily from the dynamic

nature of resource requirements and the potentially large populations of users and resources.

These issues include resource location, scheduling, code management, configuration, fault

tolerance, security, and payment mechanisms.

6.4 Data-Intensive Computing

In data-intensive applications, the focus is on synthesizing new information from

data that is maintained in geographically distributed repositories, digital libraries, and

databases. This synthesis process is often computationally and communication intensive aswell.

Future high-energy physics experiments will generate terabytes of data per day, or

around a peta byte per year. The complex queries used to detect ³interesting" events may

need to access large fractions of this data. The scientific collaborators who will access this

data are widely distributed, and hence the data systems in which data is placed are likely to

be distributed as well.

The Digital Sky Survey will, ultimately, make many terabytes of astronomical

photographic data available in numerous network-accessible databases. This facility enables

new approaches to astronomical research based on distributed analysis, assuming that

appropriate computational grid facilities exist.

Modern meteorological forecasting systems make extensive use of data assimilation

to incorporate remote satellite observations. The complete process involves the movement

and processing of many gigabytes of data.



Grid Computing


Challenging issues in data-intensive applications are the scheduling and configuration of

complex, high-volume data flows through multiple levels of hierarchy.

6.5 Collaborative Computing

Collaborative applications are concerned primarily with enabling and enhancing

human-to-human interactions. Such applications are often structured in terms of a virtual

shared space. Many collaborative applications are concerned with enabling the shared use of

computational resources such as data archives and simulations; in this case, they also have

characteristics of the other application classes just described. For example:

The BoilerMaker system developed at Argonne National Laboratory allows multiple

users to collaborate on the design of emission control systems in industrial incinerators. The

different users interact with each other and with a simulation of the incinerator.

The CAVE5D system supports remote, collaborative exploration of large

geophysical data sets and the models that generate them-for example, a coupled

physical/biological model of the Chesapeake Bay.

The NICE system developed at the University of Illinois at Chicago allows children

to participate in the creation and maintenance of realistic virtual worlds, for entertainment

and education.

Challenging aspects of collaborative applications from a grid architecture perspective

are the real- time requirements imposed by human perceptual capabilities and the rich

variety of interactions that can take place.

We conclude this section with three general observations. First, we note that even in

this brief survey we see a tremendous variety of already successful applications. This rich

set has been developed despite the significant difficulties faced by programmers developing

grid applications in the absence of a mature grid infrastructure. As grids evolve, we expect

the range and sophistication of applications to increase dramatically. Second, we observe

that almost all of the applications demonstrate a tremendous appetite for computational

resources (CPU, memory, disk, etc.) that cannot be met in a timely fashion by expected

growth in single-system performance. This emphasizes the importance of grid technologies

as a means of sharing computation as well as a data access and communication medium.

Third, we see that many of the applications are interactive, or depend on tight

synchronization with computational components, and hence depend on the availability of a

grid infrastructure able to provide robust performance guarantees.



Grid Computing

7. CONCLUSIONS

There are currently a large number of projects and a diverse range of new and

emerging Grid developmental approaches being pursued. These systems range from Grid

frameworks to application testbeds, and from collaborative environments to batch

submission mechanisms.

Grid computing has many promises making today¶s computing easier by managing

resources better and creating an environment for advanced apps of tomorrow making it this

applications portable.

8. REFERENCES

1. Foster, C. Kesselman, editors. The Grid: Blueprint for a New Computing

Infrastructure, Morgan Kaufmann, San Francisco, Calif. (1999).

2. Ian Foster,Carl Kesselman, Steven Tuecke.The Anatomy of the GridEnabling Scalable

Virtual Organizations.

3. Daniel Koußril, LudßekMatyska, and Michal Procházka,GabrielaKrßcmaßrová,

PetrSojka(Eds.).Survey of Authentication Mechanisms for Grids.CESNET Conference

2008, Proceedings, pp. 39±48, 2008.

4. Shuai Zhang Shufen Zhang Xuebin Chen XiuzhenHuo.The Comparison Between Cloud

Computing and Grid Computing: 2010 International Conference on Computer

Application and System Modeling (ICCASM 2010).

5. http://www.wikipedia.com/gridcomputing/

Grid Architectur

Documents

Transcript of Grid Architectur