on Observations Architecture, Protocols, Services, APIs, SDKs, and the Role of the Grid Forum
Ian Foster With: Carl Kesselman, Steven Tuecke Thanks also to: Bill Johnston, Marty Humphrey, Rusty Lusk, Reagan Moore, and others
1
Overview
1. 2. 3. 4. 5.
The Grid problem: controlled resource sharing in multiinstitutional settings Standards as a means of enabling sharing of code, resources, services Aside: definition, role, and importance of protocols, services, SDKs, APIs, etc. A "Grid Architecture": a categorization of protocols, services, SDKs, and APIs Questions for the Grid Forum
2
The Grid Problem
x Grid R&D has its origins in highend
computing & metacomputing, but... x In practice, the "Grid problem" is about resource sharing & coordinated problem solving in dynamic, multiinstitutional virtual organizations
x Primary challenge: to enable, maintain, and
Lack of central control, omniscience, trust
control the sharing of resources to achieve a common goal
3
Examples of Virtual Organizations
x Members of a scientific collaboration
x Application server provider + customers x Participants in peertopeer network
E.g., NSF PACIs, IPG, NEESgrid, GriPhyN Sharing: computers, storage, software, ... Sharing: ASP computers
Tremendous variety in scope, timescale, types of sharing, etc.
4
E.g., Gnutella, Napster, Entropia, ... Sharing: resources on individual PCs
Universal Nature of the Grid Problem
x "Sharing" fundamental in many settings
x Sharing issues not adequately addressed by
Application Service Providers, Storage Service Providers, etc.; Peertopeer computing; Distributed computing; Business to business; ...
existing technologies
x Grid community has unique experience
5
Sharing at a deep level, across broad ranges of resources and in a general way E.g., user provides ASP with controlled access to their data on an SSP: how??
Creating Usable Grids: What are the Challenges?
x Approaches to problem solving
x Structuring and writing programs
Data Grids, distributed computing, peertopeer, collaboration grids, ... Abstractions, tools
x Enabling resource sharing across distinct
institutions
Resource discovery, access, reservation, allocation; authentication, authorization, policy; communication; fault detection and notification; ...
6
What is the Role of Grid Forum in Enabling Grid Computing?
1.
x Experiences, patterns, structures x Useful even if every application & Grid is a vertical "stovepipe"
2. 3.
Information exchange, of course
x In code development: libraries, tools, ... x Via resource sharing: shared Grids x In infrastructure
x
Advocacy Enabler of shared effort
Opinion: Long term, only the third is sufficiently compelling to justify GF
7
Q: How do we Enable Shared Effort? A: "Standards" are Required
x To enable portability/sharing of code x To enable resource sharing
E.g., MPI lets me write portable // programs E.g., IP lets my computer speak to yours E.g., X.509 lets me share Certificate Authorities Variously, APIs/SDKs, protocols, syntax, ... Observe that these are sometimes confused, so let's spend some time on definitions ...
8
x To enable shared infrastructure x But what sorts of "standards"?
Some Important Definitions
x Resource x Network protocol
x Network enabled service
x Application Programmer Interface (API) x Software Development Kit (SDK) x Syntax
x Not discussed, but important: policies
9
Resource
x An entity that is to be shared
x Does not have to be a physical entity
E.g., computers, storage, data, software
x Defined in terms of interfaces, not devices
E.g., Condor pool, distributed file system, ...
E.g. scheduler such as LSF and PBS define a compute resource Open/close/read/write define access to a distributed file system, e.g. NFS, AFS, DFS
10
Network Protocol
x A formal description of message formats and a
set of rules for message exchange
x Good protocols designed to do one thing x Examples of protocols
Rules may define sequence of message exchanges Protocol may define statechange in endpoint, e.g., file system state change Protocols can be layered
IP, TCP, TLS (was SSL), HTTP, Kerberos
11
Network Enabled Services
x Implementation of a protocol that defines a
set of capabilities
x Examples: FTP and Web servers
FTP Server FTP Protocol Telnet Protocol
Protocol defines interaction with service All services require protocols Not all protocols are used to provide services (e.g. IP, TLS)
Web Server HTTP Protocol TLS Protocol TCP Protocol IP Protocol
12
TCP Protocol IP Protocol
Application Programmer Interface
x A specification for a set of routines to facilitate
application development
x Spec often languagespecific (or IDL)
Refers to definition, not implementation E.g., there are many implementations of MPI Routine name, number, order and type of arguments; mapping to language constructs Behavior or function of routine GSS API (security), MPI (message passing)
13
x Examples
Software Development Kit
x A particular instantiation of an API x SDK consists of libraries and tools
x Can have multiple SDKs for an API x Examples of SDKs
Provides implementation of API specification
MPICH, Motif Widgets
14
Syntax
x Rules for encoding information, e.g.
x Distinct from protocols
XML, Condor ClassAds, Globus RSL X.509 certificate format (RFC 2459) Cryptographic Message Syntax (RFC 2630) One syntax may be used by many protocols (e.g., XML); & useful for other purposes E.g., Condor ClassAds > XML > ASCII Important to understand layerings when comparing or evaluating syntaxes
15
x Syntaxes may be layered
A Protocol can have Multiple APIs E.g., TCP/IP
x TCP/IP APIs include BSD sockets, Winsock,
System V streams, ... x The protocol provides interoperability: programs using different APIs can exchange information x I don't need to know remote user's API
Application WinSock API Application Berkeley Sockets API TCP/IP Protocol: Reliable byte streams
16
An API can have Multiple Protocols E.g., Message Passing Interface
x MPI provides portability: any correct
program compiles & runs on a platform x Does not provide interoperability: all processes must link against same SDK
E.g., MPICH and LAM versions of MPI
Application MPI API LAM SDK LAM protocol TCP/IP Different message formats, exchange sequences, etc.
17
Application MPI API MPICHP4 SDK MPICHP4 protocol TCP/IP
Back to Grids: The Programming & Systems Problems
x Approaches to problem solving
x Structuring and writing programs
Data Grids, distributed computing, peertopeer, collaboration grids, ... Abstractions, tools
Programming Problem x Enabling resource sharing across distinct institutions
Resource discovery, access, reservation, allocation; authentication, authorization, policy; communication; fault detection and notification; ... Systems Problem
18
Back to Grids: The Programming & Systems Problems
x The programming problem
x The systems problem
Facilitate development of sophisticated applns Facilitate code sharing Requires prog. envs: APIs, SDKs, tools Facilitate coordinated use of diverse resources Facilitate infrastructure e.g., sharing: certificate authorities, info services Requires systems: protocols, services E.g., port/service/protocol for accessing information, allocating resources
19
Aspects of the Programming Problem
x Need for abstractions and models to add to
speed/robustness/etc. of development components developed by others
x Need for code/tool sharing to allow reuse of code
E.g., OO abstractions, MPI for messaging
x Primary need is for standard programming
E.g., MPI allows reuse of message passing E.g., standard profilers, debuggers
environments: APIs and SDKs
20
Aspects of the Systems Problem
x Need for interoperability when different groups
want to share resources
x Need for shared infrastructure services to avoid
Diverse components, policies, mechanisms E.g., standard notions of identity, means of communication, resource descriptions
repeated development, installation
x Need standard protocols, services, syntax
21
E.g., one port/service for remote access to computing, not one per tool/application E.g., Certificate Authorities: expensive to run
I.e., Standard APIs and Protocols are Both Important: For Different Reasons
x Standard APIs/SDKs are important
x Standard protocols are important
They enable application portability But w/o standard protocols, interoperability is hard (every SDK speaks every protocol?) Enable crosssite interoperability Enable shared infrastructure But w/o standard APIs/SDKs, application portability is hard (different platforms access protocols in different ways)
22
Grid "Architecture"
x We now proceed to analyze Grid systems
with respect to standards x Identify key areas where protocols, services, APIs, and SDKs can occur x Result is a layered protocol architecture x We assert this can be useful as a means of describing and structuring Grid Forum activities
23
Layered Grid Architecture (By Analogy to Internet Architecture)
Application
"Specialized services": user or appln specific distributed services "Managing multiple resources": ubiquitous infrastructure services "Sharing single resources": negotiating access, controlling use "Talking to things": communication (Internet protocols) & security "Controlling things locally": Access to, & control of, resources
24
User Collective Resource Connectivity Fabric
Transport Internet Link Application
Internet Protocol Architecture
Protocols, Services, and Interfaces Occur at Each Level
Applications Languages/Frameworks User Service APIs and SDKs User Services Collective Service APIs and SDKs Collective Services Resource APIs and SDKs Resource Services Connectivity APIs
Connectivity Protocols User Service Protocols
Collective Service Protocols
Resource Service Protocols
Fabric Layer
25
Local Access APIs and Protocols
An Aside on Terminology
x Is this an "architecture" or just a
"categorization" or "taxonomy"?
x Becomes more architectural if/as we define
A matter of opinion (c.f. IAB: "Many members of the Internet community would argue that there is no architecture") Our opinion: it is somewhere in between, but is useful regardless
"necessary" pieces at each level x Note that protocols says nothing about SDKs/APIs architecture (& vice versa)
26
Important Points
x We build on Internet protocols
x "Layering" here is conceptual, does not imply
Communication, routing, name resolution, etc.
constraints on who can call what
Protocols/services/APIs/SDKs will, ideally, be largely selfcontained But some things are fundamental: e.g., communication and security But, advantageous for higherlevel functions to use common lowerlevel functions
27
Example: User Portal
Appln User Collective Resource Connect Fabric Web Portal Source code discovery, application configuration
API SDK Lookup Protocol Source Code Repository
Brokering, coallocation, certificate authorities
API
Access to data, access to computers, access to network performance data Communication, service discovery (DNS), authentication, authorization, delegation Storage systems, schedulers
28
SDK Access Protocol Compute Resource
Example: HighThroughput Computing System
Appln User Collective Resource Connect Fabric High Throughput Computing System Dynamic checkpoint, job management, failover, staging Brokering, certificate authorities
API
SDK Cpoint Protocol Checkpoint Repository
API
Access to data, access to computers, access to network performance data Communication, service discovery (DNS), authentication, authorization, delegation Storage systems, schedulers
29
SDK Access Protocol Compute Resource
Standards, Again: Intergrid Protocols and Grid APIs
x One or many protocols?
x One or many APIs and SDKs?
No one "right" protocol for any one function But: interoperability requires that we define and commit to core "Intergrid" protocols Definition: "A resource is Gridenabled if it speaks Intergrid protocols" Many APIs, SDKs, programming models can target Intergrid protocols But: code sharing requires standards So, e.g., "standard Grid collaboration APIs"
30
Questions for the Grid Forum
x Is the "Grid architecture" described here a
useful framework?
x Would it be a useful discipline for us to try to
Could it be made more useful? Are there things that it fails to capture or misrepresents?
place GF efforts in this context
E.g., be clear whether we are defining a protocol, service, API, SDK, syntax (or something else: which is fine, too) E.g., explain (and argue about) where in the stack different pieces fit
31
Questions for the Grid Forum
x Are some things easier, or more important, to
standardize than others?
x I would suggest that
Protocols vs. APIs vs. syntax Connectivity vs. resource vs. collective vs. user layer protocols/services/APIs/SDKs Items lower in the stack tend to have broader impact, but standards useful at all levels Size of community effected (e.g., number of adopters) is the key figure of merit We should ask explicitly for such an analysis as part of a WG charter
32
Questions for the Grid Forum
x Can we define core "intergrid protocols"?
x Possible approaches
I.e., instantiate (lower) layers in the diagram We have avoided it until now (implies choice) Until we do, interoperability is difficult Avoid seeking consensus, instead standardize where it makes sense and where we can; rely on sense of "best practice" emerging Or, create an architecture WG, charged with defining requirements for "core protocols"?? I think latter is better, unsure if it can work
33
Summary
x Grids are about [largescale] sharing
x Well defined architecture can help
Hence require standard protocols to enable interoperability and shared infrastructure And, of course standard APIs and SDKs to enable portability & code sharing Both important; but very different
understanding & progress
Provides a framework for figuring out where the pieces fit Facilitates asking questions such as "where are standards particularly important?"
34
Questions?
35