Concepts and

Architecture of Grid
Computing
Advanced Topics Spring 2008
Prof. Robert van Engelen

Overview

Grid users: who are they?

Concept of the Grid
Challenges for the Grid
Evolution of Grid systems
Model of the Grid architecture
Condor-G: Globus and Condor
Applications

2/12/08

HPC II Spring 2008

Grid Users

Computational/experimental scientists and engineers

Industry

Link people (video conferencing & remote collaboration systems)

Share resources
Problem solving

Government

Control remote instruments

Access to data repositories and (super)computers
Visualization and data analysis

Public policy making based on collaborative information sharing

Disaster response using information gathering and decision making

Education

2/12/08

Virtual classrooms (one-way video conferencing)

Remote demonstrations and remote access to collections
HPC II Spring 2008

Scientific Users of the Grid

Scientists and engineers may need the Grid for

Data intensive applications

Imaging

Using supercomputers as scientific instruments

Example simulations: Japanese earth simulator, DOE nuclear bomb
simulations, computational chemistry, life sciences,

Remote access to instruments

2/12/08

Managing collections of medical images: MRI, CT scans, X-rays,

Comparing images and metadata for epidemiological studies

Scientific simulations

Collider experiments in particle physics produce petabytes per year

Astronomy digital sky surveys, e.g. the virtual observatory project
Example data grids: NSF GriPhyN, DOE PPDG, EU DataGrid

Example: network for earthquake engineering simulation

HPC II Spring 2008

Concept of the Grid

A common theme underlying these usage modalities is a need for

coordinated resource sharing and problem solving in dynamic,
multi-institutional virtual organizations
What is a Virtual Organization (VO)?

The Grid concept

A group of individuals or institutions defined by a set of sharing rules

Grid = a technology that manages two opposing forces: sharing & trust
Sharing: coordinated resource sharing in a VO between participants
with varying degrees of prior relationships and trust
Trust: trust within a VO is precisely defined by the sharing rules
governed by security and access policies

Limited trust means limited sharing

No trust means no sharing!
Why trust at all?

2/12/08

There is a common goal, could be monetary gain

Isolation of shared resources from critical infrastructure, e.g. sandboxing
HPC II Spring 2008

Resource Sharing Relationships

Physical organizations

Two virtual organizations

AirCar, Goeing, CyclesRUs

VO-Space: AirCar and Going
collaborate on space project
VO-Cycles: ray tracing cycle
sharing consortium formed by
Goeing and CyclesRUs

Resource sharing within a VO

Is conditional: policies for

when, where, and what

2/12/08

HPC II Spring 2008

can run programs A or B

can read data D
can use idle machines if
budget not exceeded

Is secure: pooling of resources

that are certified as secure
6

Challenges

Trust (security is built on trusted parties or trusted third-party CA)

Sharing of applications and data

Problem: incompatible protocols

Solution: XML-based protocols and open standards

Reliability and robustness (a non-functional requirement)

Problem: incompatible machines and OS, need to limit access

Solution: virtualization, Grid resource allocation policies

Communication of Grid policies and metadata: Grid interoperability

Problem: how to trust VO members and its agents (autonomous apps)

Solution: proxy credentials provided by a CA in public key infrastructure

Problem: Grid-based systems can be brittle (network connections)

Solution: two-phase commit, transaction-based protocols

Quality of service (QoS) (a non-functional requirement)

2/12/08

Problem: need end-to-end resource management, transactions

Solution: budgeting of cycles, bandwidth, and storage capacity
HPC II Spring 2008

Evolution of Grid Technologies

Custom solutions (early 90s)

2/12/08

Metacomputing explorative work

Applications built directly on Internet protocols (TCP/IP)
Limited functionality, security, scalability, and robustness

HPC II Spring 2008

Evolution of Grid Technologies

Globus toolkit version 2 (GT2) (1997)

2/12/08

Popular open-source collection of tools for secure sharing

Defined and implemented protocols, APIs, and services
De-facto Grid standards

HPC II Spring 2008

Evolution of Grid Technologies

Open Grid Services Architecture (OGSA) (2002)

Community standard with multiple implementations

2/12/08

Globus GT3 implementation

Service-oriented architecture based on XML Web services

HPC II Spring 2008

10

Open Grid Services

Architecture

OGSA (GT3) is a redesign of Globus GT2

Factoring of component behaviors
Problem: current tools combine too many aspects redundantly
OGSA identifies basic set of essential services

Service orientation
Services instead of applications
A service has a well-defined web interface (like an HTTP server)

Aligned with XML web services

OGSAs idea was good, but its use is not successful

XML-based message protocols

Need simpler, more basic service protocols instead of OGSA-specific extensions
of the web service description language (WSDL)

Globus GT4 uses WS-RF (resource framework) a set of messaging-level

protocols for resource properties, lifetime management,

2/12/08

HPC II Spring 2008

11

Evolution of Grid Technologies

Managed, shared virtual systems (?)

Improved technology

Improved quality of service

2/12/08

Virtualization to make Grid more seamless

More active management, e.g. network QoS requires WAN-level support

HPC II Spring 2008

12

Model of the Grid Architecture

The hour-glass model of the

Grid architecture

Role of layers:

2/12/08

Thin center: few standards

Wide top: many high-level
behaviors can be mapped
Wide bottom: many underlying
technologies and systems

HPC II Spring 2008

Fabric: interfaces local control

Connectivity: secure
communications
Resource: sharing a single
resource
Collective: coordinated
sharing of multiple resources
Applications: you decide
13

Fabric Layer

Need to manage a resource

Reserve usage in advance
Allocate space (e.g. storage)

Grid fabric layer provides standardized access to local

resource-specific operations
Software is provided to discover
Computers (OS version, hardware config, usage load)
Storage systems
Networks

Globus General-purpose Architecture for Reservation

and Allocation (GARA)

2/12/08

HPC II Spring 2008

14

Connectivity Layer

Need secure connectivity to resources

Assumes trust is based on user, not service providers
Use public key infrastructure (PKI)
User is recognized by a Certificate Authority (CA) (within Grid)
Single sign-on: allow users to authenticate only once
Delegation: create proxy credentials to allow services/agents to
act on a users behalf

Integrate and obey local security policies in global view

Unix file permissions, ACLs,

Globus Security Infrastructure (GSI)

Standardized mechanism for proxy credential creation and
mapping to local access authentication scheme (logins)
Based on generic services security (GSS) API, which allows
applications to perform these security operations autonomously

2/12/08

HPC II Spring 2008

15

Resource Layer

Need access to resources

Invoke remote computation
Monitor computation
Discover resources
Perform data transport (e.g. to and from computations)

Globus Grid Resource Allocation and Management

(GRAM)

Globus Monitoring and Discovery Service (MDS-2)

Job manager and reporter

Registry of resources and monitoring of resource usage stats

Globus GridFTP
Good old FTP but faster (multiple streams), integrated security
Partial file access

2/12/08

HPC II Spring 2008

16

Collective Layer

Need to coordinate sharing of resources

Directory services
Coallocation, scheduling, brokering services
Monitoring and diagnostic services
Data replication services

Tools
Workflow systems
Collaboratory services

Globus DUROC resource coallocation library

2/12/08

HPC II Spring 2008

17

Resource Allocation via

Description Languages

Condor classified advertisements (ClassAds) describe job and requirements

machine architecture
command or executable starting application
constraints on required resources
executable size
required memory
operating system and release
owner
rank specifying preferred resources

Globus RSL uses LDAP-like notation

[
Type = "job";
Owner = "Myself";
Executable = "Myimage";
Rank = other.PhysicalMemory > 256 && other.Mips > 20 || other.Kflops > 2000;
Imagesize = 275M;
Constraint = other.Virtual > self.Imagesize;
]
2/12/08

HPC II Spring 2008

18

Resource Allocation and Job

Scheduling

Resource owner states policy

to manage requestors and
allocate resources according
to rules

Job scheduling and match

making based on rules

Condors 7 steps to run a Condor job

2/12/08

user access by group via a

group authorization policy
predefined time slot when job
has right to run
maximum CPU amount
allowed for job
maximum disk amount
available to group

HPC II Spring 2008

Condor schedd
Globus GRAM for RSL
19

Condor-G: Condor for the Grid

Condor-G can
cross institutional
boundaries
Supports both
Condor and nonCondor pools
Uses

7 steps to run a Condor-G job

2/12/08

HPC II Spring 2008

Grid Security
Infrastructure
(GSI)
Grid Resource
Allocation
Manager (GRAM)
Global Access to
Storage (GASS)
20

Condor-G Glidein

Condor pool on top of a

Condor-G system
User submits glideins via
Condor-G over GRAM

User submits Condor jobs to

run on the pool
Matchmaker more complex

2/12/08

HPC II Spring 2008

A glidein is a Condor
deamon
Each glidein creates (part of)
an ad-hoc Condor pool

Can be user-defined

21

Two Example Applications

NEESgrid Earthquake Engineering Collaboratory

The Virtual Observatory World-Wide Telescope

2/12/08

HPC II Spring 2008

22

NEESgrid

Used by the earthquake engineering community

http://it.nees.org

Goals is to enhance the utility of experimental facilities

Sharing of experimental data
Collaboration between experts from different domains

Five basic functional components

2/12/08

Collaboration technology
Information management for sharing data
Simulation systems and software
NEESgrid-enabled desktops for direct access to Grid
Support nodes which maintain online knowledge bases

HPC II Spring 2008

23

NEESGrid Overview

2/12/08

HPC II Spring 2008

24

NEESPoP

NEESPoP (NEES Point of Presence) deployed at each

experimental facility
Provides
Site status published via Globus MDS
Teleobservation using streaming data services protocol (NSDS)
Telecontrol of actuators using transaction-oriented NEES
telecontrol protocol (NTCP)
Collaboration services (via so-called CHEF portlets)

2/12/08

Forums, electronic notebooks

Metadata browser for editing and publishing of metadata associated
with experimental and simulation data
Remote administration services
Data access via GridFTP
HPC II Spring 2008

25

NEESgrid and Google Earth

Earthquake engineering-related points of interest

2/12/08

HPC II Spring 2008

26

The Virtual Observatory

World-Wide Telescope

Unify astronomy archives into giant database

Integrate archives as a single intelligent telescope
Hope for new discoveries through federating datasets
from multiple independent projects
Hierarchical architecture
Archives: raw data (images/text) organized with metadata
XML Web services: on-demand queries and a XML schema data
model (VOTable) to represent astronomy data
Registries and portals: record what kind of data the archive
provides (sky coverage, temporal coverage, spectral coverage,
and resolution)

2/12/08

HPC II Spring 2008

27

Virtual Observatory Tools

Digital sky surveys are created using the Chimera virtual data toolkit
(built on Globus and Condor)
Virtual Sky provides image navigation over the whole sky, e.g.
access via http://skyview.gsfc.nasa.gov

2/12/08

HPC II Spring 2008

28

Further Reading

[Grid] Chapter 4
Optional:
NEESgrid: [Grid] Chapter 6
Virtual Observatory: [Grid] Chapter 7
Condor and reliability: [Grid] Chapter 19

2/12/08

HPC II Spring 2008

29