Grid Computing Outline

1. Grid Computing Outline • Grid examples and virtual organizations • RPC, RMI • Web Services and Globus Toolkit • Condor Page 1

2. What is “Grid Computing” Grid computing is way of organizing computing resources • So that they can be flexibly and dynamically allocated and accessed • Central processors, storage, network bandwidth, databases, applications, sensors and so on The objective of grid computing is to share information and processing capacity so that it can be more efficiently exploited • Offer QOS guarantees (security, workflow and resource management, fail-over, problem determination, … ) Page 2

3. Elements of Grid Computing • Resource sharing • Computers, data, storage, sensors, networks, … • Sharing always conditional: issues of trust, policy, negotiation, payment, … • Coordinated problem solving • Beyond client-server: distributed data analysis, computation, collaboration, … • Dynamic, multi-institutional virtual organizations • Community overlays on classic org structures • Large or small, static or dynamic Page 3

4. Virtual Organizations • A set of individuals and/or institutions defined by a set of sharing rules • The sharing is highly controlled, with resource providers and consumers defining clearly and carefully just what is shared An example: the set of application service providers, storage service providers, cycle providers and consultants engaged by a car manufacturer to plan for a new factory Another example: industrial consortium building a new aircraft Page 4

5. Online Access to Scientific Instruments Advanced Photon Source wide-area dissemination desktop & VR clients with shared controls real-time collection archival storage tomographic reconstruction DOE X-ray grand challenge: ANL, USC/ISI, NIST, U.Chicago Page 5

6. ~PBytes/sec ~100 MBytes/sec Offline Processor Farm ~20 TIPS There is a “bunch crossing” every 25 nsecs. There are 100 “triggers” per second Each triggered event is ~1 MByte in size ~100 MBytes/sec Online System Tier 0 CERN Computer Centre ~622 Mbits/sec or Air Freight (deprecated) Tier 1 FermiLab ~4 TIPS France Regional Centre Germany Regional Centre Italy Regional Centre ~622 Mbits/sec Tier 2 Tier2 Centre ~1 TIPS Caltech ~1 TIPS Tier2 Centre ~1 TIPS Tier2 Centre ~1 TIPS Tier2 Centre ~1 TIPS HPSS HPSS HPSS HPSS HPSS ~622 Mbits/sec Institute ~0.25TIPS Institute Institute Institute Physics data cache ~1 MBytes/sec 1 TIPS is approximately 25,000 SpecInt95 equivalents Physicists work on analysis “channels”. Each institute will have ~10 physicists working on one or more channels; data for these channels should be cached by the institute server Pentium II 300 MHz Pentium II 300 MHz Pentium II 300 MHz Pentium II 300 MHz Tier 4 Physicist workstations Data Grids forHigh Energy Physics Image courtesy Harvey Newman, Caltech Page 6

7. Network for EarthquakeEngineering Simulation • NEESgrid: national infrastructure to couple earthquake engineers with experimental facilities, databases, computers, & each other • On-demand access to experiments, data streams, computing, archives, collaboration NEESgrid: Argonne, Michigan, NCSA, UIUC, USC Page 7

8. Components for authentication in virtual organization environments • Single sign on – access to multiple resources after logging in just once • Delegation – a program can access the resources that a user is authorized to access • Integration with various local security solutions – for example, local Unix security • Trust relationships – between individual users and resources; between resources and user groups; between virtual and real organizations Page 8

9. RPC and RMI • Remote Procedure Call (RPC) • Extends the client/server concept by making the definition of an interface more formal, clarifying rules for parameter passing, adding capabilities for locating services, etc. • RMI (Remote Method Invocation) is RPC applied to objects. Page 9

10. Conventional Procedure Call Steps steps: push myparm onto stack push return address onto stack branch to address of mysub /* allocate stack space for local vars */ get myparm from stack, calculate ret val push return value onto stack /* fix stack */ branch to return address get ret val from stack assign to myretval fix stack main() { … myretval = mysub(myparm); … } int mysub(int myparm) { /* calculate return value */ return(returnvalue); Page 10

11. Conventional Procedure Call Steps • Parameter passing in a local procedure call: the stack before the call to read • The stack while the called procedure is active Page 11

12. Steps of RPC • There is no stack or local shared memory with remote procedure call! Everything has to be done with message passing. With RPC steps: /* using local procedure call mechanisms where needed */ main() { ... myretval = myrpcstub(myparm); /* local procedure call */ ... } Page 12

13. Steps of RPC – Client view int myrpcsub(int myparm) { /* client side view */ /* calculate return value */ pack myparm into a network-neutral format /* serverstub */ send message to myrpcserver with myparm--------> receive message unpack parameter retval = mysub(myparm) pack retval into message receive return message <----------------------- send retval back unpack return value from message return(returnvalue); } • Notice - you can't pass pointers, only pass by value Page 13

14. Client and Server Stubs • Principle of RPC between a client and server program. Page 14

15. Steps of RPC 2-8 • Steps involved in doing remote computation through RPC Page 15

16. Steps of a Remote Procedure Call • Client procedure calls client stub in normal way • Client stub builds message, calls local OS • Client's OS sends message to remote OS • Remote OS gives message to server stub • Server stub unpacks parameters, calls server • Server does work, returns result to the stub • Server stub packs it in message, calls local OS • Server's OS sends message to client's OS • Client's OS gives message to client stub • Stub unpacks result, returns to client Page 16

17. RPC and array parameters • A procedure • The corresponding message. In this example, the whole contents of the array is passed as a parameter! Page 17

18. RPC Semantics in presence of failure Some bad things that could happen: • The sent request could get lost (the server never executes it) • The server could crash and partially executes the request • The response could get lost (the server executes the whole request, but the network fails in some way) • The acknowledgement of the response by the client could get lost Page 18

19. RPC Semantics in presence of failure Exactly once • The result is returned to the calling application exactly once • Requires that the client buffer the request until the response is received – have to number the requests so that you can tell them apart • Requires that the server buffer the result until the client confirms that the result has been received – have to also number the responses so that you can tell them apart • The server must ensure that the same request from the client is idempotent – the same request delivers the same response and has no additional affect on the system, even if it arrives more than one time • How long do you wait for a response?? Page 19

20. RPC Semantics in presence of failure Some other choices: • At most once • At least once • One of many Page 20

21. How does the client locate the server? • Could be located at compile time • The server address is embedded into the source • Could be located at run time • Could be a command line parameter to the client program. The user needs to know the complete address of the server. • Could be located using a lookup by name • The server registers a name into a name or directory service. The client must call the directory service before contacting the server for the first time to get its address • Could be located using a lookup by type or capability • The server register by capability into a directory service. The client calls the directory service before contacting the server for the first time. The client selects a server to use. Page 21

22. Binding a Client to a Server • An interface file is used to define the interface between • the client and the server – and can used to “register” the service 2-15 Page 22

23. Distributed Objects • Common organization of a remote object with client-side proxy. 2-16 Page 23

24. Java Remote Method Invocation (RMI) • Remote Method Invocation (RMI) is Java’s implementation of object-to-object communication among Java objects to realize a distributed computing model. • RMI allows us to distribute our objects on various machines, and invoke methods on the objects located on remote sites. Page 24

25. 5. 3. 3. 2. XYZ Implementation XYZ Client Stub Stub 1. uses implements XYZ interface Client Host Server Host RMI-based Distributed System 4. Page 25

26. Steps in RMI-based Application 1. Design the interface for the service. 2. Implement the methods specified in the interface. 3. Generate the stub and the skeleton. 4. Register the service by name and location. 5. Use the service in an application. Page 26

27. Compile and Register Commands rmiregistry Finds object by name Stores object by name rmic 5. 3. 3. 2. XYZ Client Skeleton XYZ Implementation Stub 1. uses implements XYZ interface Client Host Server Host Page 27

28. More Details • Once the object (or service) is registered, a client can look up that service. • A client (application) receives a reference that allows the client to use the service (call the method). • Syntax of calling is identical to a call to a method of another object in the same program. Page 28

29. Partial Example: Temperature Service • Create a distributed system using RMI model for networking (remote access). • Basically this program will download the weather (temperature) information from the site: • http://iwin.nws.noaa.gov/iwin/us/traveler.html Page 29

30. Defining Remote Interface import java.rmi.*; // the interface extends Remote interface // any class implementing Remote can be accessed remotely security permitting public interface TemperatureServer extends Remote { // specify methods that can be called remotely // each method “throws RemoteException” } Page 30

31. Implementing the Remote Interface import java.rmi.*; import java.rmi.server.*; import java.net.*; // others as needed TemperatureServerImpl extends UnicastRemoteObject implements TemperatureServer { Page 31

32. TemperatureServerImpl (contd.) • It implements the service method and returns the weather data gathered. • The main method instantiates an object for the service, and registers it with rmiregistry. Page 32

33. Temperature Client import java.rmi.*; // import other packages constructor calls a private method getRemoteTemp which takes care of lookup of remote object and access. In this application it also displays the information. Page 33

34. Client • There is no difference between the local and remote call. Page 34

35. Web Services • A client/server system • Concept similar to Remote Procedure Call (RPC), Remote Method Invocation (RMI), only applied over HTTP • Extensive use of XML to define the interface and other components of the environment Page 35

36. Web Services Page 36

37. Web Services Architecture The Web Services Architecture is specified and standardized by the World Wide Web Consortium, the same organization responsible for XML, HTML, CSS, etc. Page 37

38. Recent Changes to Grid Standards • Introduction of Web Services Resource Framework (WSRF), January, 2004 • Web services vendors recognized the importance of standard for Grids but would not adopt them as they was defined (summer 2003) • Globus Alliance teamed up with Web services architects and came up with WSRF • Add the ability to create, address, inspect, discover, and manage stateful resources Page 38

39. Grid computing broader context • The NSF Middleware Initiative funded large portions of the Globus Toolkit development • The NSF NMI release includes many tools besides the Globus Toolkit. Page 39

40. Globus Toolkit Services • Data Services include • Replica Management • Base Services include • Managed Job Service • Index Service • Reliable FTP • Many documents define GT Security Services Page 40

41. UofA Grid Computing Possibilities • Cyberinfrastructure for Environmental Water Resource Management Building on the Resources of the Great Plains Network • Ralph Davis, UA Geosciences, large collaboration • The vision is a grid computing system that allows various users access at multiple levels, and facilitates large-scale database management, rapid processing of image data, and seamless integration of complex, dispersed data sets and model applications. • Real-time measurement, accurate modeling, effective decision support systems Page 41

42. UofA Grid Computing Possibilities • Recent Acxiom proposal: Self-Regulation of the Acxiom Grid Environment • Computational chemistry: exploit 10,000 computers to screen 100,000 compounds in an hour • DNA computational scientists visualize, annotate, & analyze terabyte simulation datasets • Environmental scientists share volcanic activity sensing data that has been collected from a widely dispersed sensor grid Page 42

43. UofA “Grid” for Sharing Digital Map Data • GeoStor digital map data delivery system • http://www.cast.uark.edu/cast/geostor/ • Contains all publicly available geographic data for the state of Arkansas • Oracle database is used for access to metadata and some maps Page 43

44. UofA “Grid” for Sharing Digital Map Data GeoSurf • A Java based product • User queries and downloads data from GeoStor • User specifies geographic clip boundaries, projection, data format • Current system asks user to submit email address to system for processing – an online link is emailed to the user • Could be a Grid service Page 44