ST.

ANN’S COLLEGE OF ENGG & TECH

CHIRALA-523187

GRID COMPUTING

PRESENTED BY:

K.V.S.R.HARSHA CHALUVADHI.SVR.SKUMAR
III B-TECH,CSE III B.TECH ,CSE
E-mail:[email protected] E-mail:[email protected]
Mobile:9247888083
 GRID COMPUTING

ENABLING SCALABLE VIRTUAL ORGANISATIONS

ABSTRACT:-
“Grid” computing has emerged as an important new field, distinguished from
conventional distributed computing by its focus on large-scale resource sharing,
innovative applications, and, in some cases, high-performance orientation. In this article,
we define this new field. First, we review the “Grid problem,” which we define as
flexible, secure, coordinated resource sharing among dynamic collections of individuals,
institutions, and resources—what we refer to as virtual organizations. In such settings,
we encounter unique authentication, authorization, resource access, resource discovery,
and other challenges. It is this class of problem that is addressed by Grid technologies.
Next, we present an extensible and open Grid architecture, in which protocols, services,
application programming interfaces, and software development kits are categorized
according to their roles in enabling resource sharing. We describe requirements that
we believe any such mechanisms must satisfy and we discuss the importance of defining
a compact set of intergrid protocols to enable interoperability among different Grid
systems. Finally, we discuss how Grid technologies relate to other contemporary
technologies, including enterprise integration, application service provider, storage
service provider, and peer-to-peer computing. We maintain that Grid concepts and
technologies complement and have much to contribute to these other approaches.
Introduction:-
The term “the Grid” was coined in the mid1990s to denote a proposed distributed computing
infrastructure for advanced science and engineering .Considerable progress has since been made
on the construction of such an infrastructure , but the term “Grid” has also been conflated, at
least in popular perception, to embrace everything from advanced networking to artificial
intelligence.

A set of individuals and/or institutions defined by such sharing rules form what we call a virtual
organization (VO) VO’s vary tremendously in their purpose, scope, size, duration, structure,
community, and sociology. Nevertheless, careful study of underlying technology requirements
leads us to identify a broad set of common concerns and requirements.
Current distributed computing technologies do not address the concerns and requirements just
listed. . Business-to-business exchanges focus on information sharing (often via centralized
servers). So do virtual enterprise technologies, although here sharing may eventually extend to
applications and physical devices . Enterprise distributed computing technologies such as
CORBA and Enterprise Java enable resource sharing within a single organization. The Open
Group’s Distributed Computing Environment (DCE) supports secure resource sharing across
sites, but most VOs would find it too burdensome and inflexible.

The Emergence of Virtual Organizations:-

Consider the following four scenarios:

1. A company needing to reach a decision on the placement of a new factory invokes a

sophisticated financial forecasting model from an ASP, providing it with access to
appropriate proprietary historical data from a corporate database on storage systems
operated by an SSP

2. An industrial consortium formed to develop a feasibility study for a next-generation

supersonic aircraft undertakes a highly accurate multidisciplinary simulation of the
entire aircraft. This simulation integrates proprietary software components developed
by different participants.

3. A crisis management team responds to a chemical spill by using local weather and soil
models to estimate the spread of the spill, determining the impact based on population
 location as well as geographic features such as rivers and water supplies.

4. Thousands of physicists at hundreds of laboratories and universities worldwide come

together to design, create, operate, and analyze the products of a major detector at CERN.

These four examples differ in many respects: the number and type of participants, the types of
activities, the duration and scale of the interaction, and the resources being shared. But they
also have much in common, as discussed in the following (see also Figure 1).
In each case, a number of mutually distrustful participants with varying degrees of prior
relationship (perhaps none at all) want to share resources in order to perform some task.
Furthermore, sharing is about more than simply document exchange (as in “virtual
enterprises”it can involve direct access to remote software, computers, data, sensors, and other
resources. For example, members of a consortium may provide access to specialized software
and data and/or pool their computational resources.
The Nature of Grid Architecture:-
The establishment, management, and exploitation of dynamic, cross-organizational VO sharing
relationships require new technology. We structure our discussion of this technology in terms
of a Grid architecture that identifies fundamental system components, specifies the purpose and
function of these components, and indicates how these components interact with one another.

In defining a Grid architecture, we start from the perspective that effective VO operation
requires that we be able to establish sharing relationships among any potential participants.
Interoperability is thus the central issue to be addressed. In a networked environment,
interoperability means common protocols. Hence, our Grid architecture is first and foremost a
protocol architecture, with protocols defining the basic mechanisms by which VO users and
resources negotiate, establish, manage, and exploit sharing relationships. A standards-based
open architecture facilitates extensibility, interoperability, portability, and code sharing; standard
protocols make it easy to define standard services that provide enhanced capabilities. We can
also construct Application Programming Interfaces and Software Development Kits to provide
the programming abstractions required to create a usable Grid. Together, this technology and
architecture constitute what is often termed middleware
At issue is our need to ensure that sharing relationships can be initiated among arbitrary parties,
accommodating new participants dynamically, across different platforms, languages, and
programming environments. In this context, mechanisms serve little purpose if they are not
defined and implemented so as to be across organizational boundaries, operational policies, and
resource types. Without interoperability, VO applications and participants are forced to enter
into bilateral sharing arrangements, as there is no assurance that the mechanisms used between
any two parties will extend to any other parties. Without such assurance, dynamic VO
formation is all but impossible, and the types of VOs that can be formed are severely limited. so
we require standard protocols and syntaxes for general resource sharing.

A protocol definition specifies how distributed system elements interact with one another in
order to achieve a specified behavior, and the structure of the information exchanged during this
interaction .VOs tend to be fluid; hence, the mechanisms used to discover resources, establish
identity, determine authorization, and initiate sharing must be flexible and lightweight, so that
resource-sharing arrangements can be established and changed quickly.
A service is defined solely by the protocol that it speaks and the behaviors that it implements.
The definition of standard services—for access to computation, access to data, resource
discovery, coscheduling, data replication, and so forth— allows us to enhance the services
offered to VO participants and also to abstract away resource- specific details that would
otherwise hinder the development of VO applications.

Grid Architecture:-

1).Fabric: Interfaces to Local Control

The Grid Fabric layer provides the resources to which shared access is mediated by Grid
protocols: for example, computational resources, storage systems, catalogs, network resources,
and sensors

2).Connectivity: Communicating Easily and Securely:-

The Connectivity layer defines core communication and authentication protocols required for
Grid-specific network transactions. Communication protocols enable the exchange 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.
Authentication solutions for VO environments should have the following characteristics :

1. Single sign on.

2. Delegation.
3. Integration with various local security solutions:

4. User-based trust relationships:

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.

Two primary classes of Resource layer protocols can be distinguished:

Information protocols are used to obtain information about the structure and state of a
resource, for example, its configuration, current load, and usage policy (e.g., cost).

Management protocols are 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.

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
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. to metrics such as response time, reliability, and cost .

5).Applications:-
The final layer in our Grid architecture comprises the user applications that operate within a VO
environment. 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.

Grid Architecture in Practice:-

We use two examples to illustrate how Grid architecture functions in practice. Table 1 shows
the services that might be used to implement the multidisciplinary simulation and cycle sharing
(ray tracing) applications . The basic Fabric elements are the same in each case: computers,
storage systems, and networks. Furthermore, each resource speaks standard Connectivity
protocols for communication and security, and Resource protocols for enquiry, allocation, and
management. Above this, each application uses a mix of generic and more application-specific
Collective services.

In order to manage the execution of large numbers of largely independent tasks in a VO

environment, this system must keep track of the set of active and pending tasks, locate
appropriate resources for each task, stage executables to those resources, detect and respond to
various types of failure, and so forth. An implementation in the context of our Grid architecture
uses both domain-specific Collective services (dynamic checkpoint, task pool management,
failover) and more generic Collective services (brokering, data replication for executables and
common input files), as well as standard Resource and Connectivity protocols. Condor-G
represents a first step towards this goal .

“On the Grid”: The Need for Intergrid Protocols:-

Our Grid architecture establishes requirements for the protocols and APIs that enable sharing of
resources, services, and code. It does not otherwise constrain the technologies that might be
used to implement these protocols and APIs. In fact, it is quite feasible to define multiple
instantiations of key Grid architecture elements. For example, we can construct both Kerberos-
and PKI-based protocols at the Connectivity layer—and access these security mechanisms via
the same API, thanks to GSS-API (see Appendix). However, Grids constructed with these
different 15 protocols are not interoperable and cannot share essential services—at least not
without gateways. For this reason, the long-term success of Grid computing requires that we
select and achieve widespread deployment of one set of protocols at the Connectivity and
Resource layers—and, to a lesser extent, at the Collective layer. Much as the core Internet
protocols enable different computer networks to interoperate and exchange information, these
Intergrid protocols (as we might call them) enable different organizations to interoperate and
exchange or share resources. Resources that speak these protocols can be said to be “on the
Grid.” Standard APIs are also highly useful if Grid code is to be shared. The identification of
these Intergrid protocols and APIs is beyond the scope of this article, although the Globus
Toolkit represents an approach that has had some success to date.
Relationships with Other Technologies:-
The concept of controlled, dynamic sharing within VOs is so fundamental that we might assume
that Grid-like technologies must surely already be widely deployed.In brief, current distributed
computing approaches do not provide a general resource-sharing framework that addresses VO
requirements. Grid technologies distinguish themselves by providing this generic approach to
resource sharing. This situation points to numerous opportunities for the application of Grid
technologies.

1).World Wide Web:-

The ubiquity of Web technologies (i.e., IETF and W3C standard protocols—TCP/IP, HTTP,
SOAP, etc.—and languages, such as HTML and XML) makes them attractive as a platform for
constructing VO systems and applications. However, while these technologies do an excellent
job of supporting the browser-client-to-web-server interactions that are the foundation of
today’s Web, they lack features required for the richer interaction models that occur in VOs.
For example, today’s Web browsers typically use TLS for authentication, but do not support
single sign-on or delegation.

2).Enterprise Computing Systems:-

Enterprise development technologies such as CORBA, Enterprise Java Beans, Java 2 Enterprise
Edition, and DCOM are all systems designed to enable the construction of distributed
applications. They provide standard resource interfaces, remote invocation mechanisms, and
trading services for discovery and hence make it easy to share resources within a single
organization. However, these mechanisms address none of the specific VO requirements listed
above. Sharing arrangements are typically relatively static and restricted to occur within a
single organization. The primary form of interaction is client-server, rather than the coordinated
use of multiple resources.A “Grid Jini” that employed Grid protocols and services would allow
the use of Jini abstractions in a large-scale, multi-enterprise environment.
3).Internet and Peer-to-Peer Computing:-
Peer-to-peer computing and Internet computing is an example of the more general (“beyond
client-server”) sharing modalities and computational structures that we referred to in our
characterization of VOs. As such, they have much in common with Grid technologies.
. One reason is that peer-to-peer and Internet computing developers have so far focused entirely
on vertically integrated (“stovepipe”) solutions, rather than seeking to define common protocols
that would allow for shared infrastructure and interoperability.

As these applications become more sophisticated and the need for interoperability becomes
clearer we will see a strong convergence of interests between peer-to-peer, Internet, and Grid
computing . For example, single sign-on, delegation, and authorization technologies become
important when computational and data sharing services must interoperate, and the policies that
govern access to individual resources become more complete.

CONCLUSION:-
We have provided in this article a concise statement of the “Grid problem,” which we define as
controlled and coordinated resource sharing and resource use in dynamic, scalable virtual
organizations. We have also presented both requirements and a framework for a Grid
architecture, identifying the principal functions required to enable sharing within VOs and
defining key relationships among these different functions. Finally, we have discussed in some
detail how Grid technologies relate to other important technologies.
We hope that the vocabulary and structure introduced in this document will prove useful to the
emerging Grid community, by improving understanding of our problem and providing a
common language for describing solutions. We also hope that our analysis will help establish
connections among Grid developers and proponents of related technologies.