# Presentation: 518532

## Seamless Computing:Desktop Access to Remote Systems 

- Dennis Gannon
- IPG Project, NASA Ames
- &
- Indiana University

- Java Grande

## What are we about?

- Buiding Grids-
- scalable, distributed systems of heterogeneous information and information processing resources.
- Common Goals?
- A Simple User interface to Grid Resources/Services
- Discovery
- Access
- Authentication/Authorization
- Scheduling/Leasing

## What is out there?

- Metacomputing Infrastructures
- Legion, Globus, Unicore, ...
- Sun’s Jini Services
- GLUnix
- Distributed Component Systems
- Webflow,  CAT, SciRun, Paws, Arcade
- Metacomputing Infrastructures
- Legion, Globus,
- Scheduler Interfaces
- WebSubmit

## The Information Power Grid(unofficial version)

- Immediate Goals
- build a persistent, significant scale testbed to conduct research on NASA’s future generation information infrastructure.
- Identify and establish collaborations with application communities that will use, validate, and participate in refining the Grid infrastructure and middleware, and that have direct relevance to the NASA mission,
- provide a “global shell” for Grid job execution and workflow management.
- Start with Globus as the initial foundation.
_*More about IPG later if time permits*_

## A Vision of what a User may want

- IPG Application Family
- Aerospace Engineering Systems
- multidiscplinary, collaborative design of complex things.
- System Requirements
- What types of activities must be supported
- User Interface Implications
- A look at some existing Technology

## AES Components

- Design Definition DB
-   - Geometry, Material Specs,
-   - Control Systems, Manufacturing Data,
-   - Maintenance Info

- Performance DB
-    - flow analysis,
-     - handling characteristcs
-     - lifecycle cost simulation

- Tele-immersive
- visualization
- systems

- Flow
- Simulations

- Wind
- Tunnel
- Data Analysis
- Tools

- Structural
- Analysis
- Simulations

## Characteristics of AES 

- The software components must all interoperate
-  with each other and
- a distributed collection of concurrent, collaborating users.
- AES subsystems consist of
- modeling, design and simulation tools.
- experimental devices
- visualization
- Knowledge-based tools

## More Requirements

- Responsiveness:
- must allow interactive composition of heterogeneous collections of models and data
- Data Fusion:
- must be able to "access, mine, join" data from multiple sources.
- Performance Implications: system must be able to analyze users “real time” requests for resources,  estimate required bandwidth/mflops for each, and allocate resources.

## More Requirements

- Collaborations:
- wide area collaborative tools are essential. Must have effective, human centered, modalities.
- multiple stream types: data, video, voice, control must be supported.
- Security & privacy.
- many issues here.  how do you protect data, software and ideas!
- Scalability:
- the prototype AES on Grid must be scalable, hence grid services must also scale.

## What is the “Application”?

- The application =
- the ‘on-the-fly’ composition of a set of these components to solve a design problem.
- Programming = composition

- remote computational
- and data resources

- Wind tunnel

- database

- CFD

- vis

- vis

- vis

## A Closer Look 

- A Closer Look

- The Front-End of Desktop Grid Application Environment

- _Grid Directory_
*search for:*
-     application
-     data source
*search by:*
-      interface type
-      name

- _Grid Shell and Scripting Tool_
- > GridPs
-   ----- ------ -----
- > a.out

- _Resource Monitors_

- Scheduling
- Tools

## Directory Service Issue

- Directory Services
- How do I locate the versions of the components that
- work together
- run on the systems I am authorized to use
- scale to the level of performance I need.
- Do I locate Object by Type Specification?
- Provide to me a service that implements this interface.
- What’s in a URN?
- What sort of metadata exists?
- How do I add a new service to the Grid?

## High-Speed Transparent Access to Data

- Part of Bill Johnston’s taxonomy of IPG issues
- Transparency: Global Naming and Uniform Access
- XML approaches to metadata management
- URN approaches to persistent naming
- SRB (Storage Resource Broker)
-  MDAS/SRB are SDSC’s metadata database
-  WALDO - (Wide Area Large Data Objects)
-  Objectivity

## A Global Shell and Scripting Tool

- The grid provides a global name/file space.
- This extends to a concept of process space via object identity.
- A Shell provides the user context
- in which direct calls can be made on both architectural and application components.
- invoke a scheduler/loader with named objects
- intervene in the execution, e.g. invoke the debugger, stop/kill/migrate execution.
- Invoke applications which grant special services.
- Scripts allow important sequences of activities to be repeated.

## Interface to Performance/Scheduling Views

- How is(are) my job(s) doing?
- Need complete resource utilization information
- compute, I/O, network
- Need complete network weather service interface.
- How do I tell the system about the task requirements?
- Performance contract specfication/negotiation
- (more later)
- What is the resource specfication language?

## Object Composition Tool

- Drag Icons representing application components into a window.
- From the object directory interface
- Compose application by “wiring” (AVS style)
- Webflow,  CAT, SciRun, ...

## Programming by Composition 

- Top-Down requirement Specification
- Example: to compose
- flow data stream from wind tunnel experiment
- large scale CFD simulation + structural model
- collaborative visualization/interactive steering

## Performance Contract

- The boundary conditions:
- 2gbs from wind tunnel, 20 mbs for each visualization collaborator.
- To deliver “real time” visualization requires 200 mbs from each of CFD and experiment database
- cfd performance   X Gflops = 20X mbs output
- cfd code gives P/10 Gflops per processor and requires 10 mbs per processor for input.
- Find a schedule (compute and network resource binding) to give at lease 50% real time.

- The graph defines the
- required components
- and there logical
- interconnect

## Other models of Grid Applications

- Large parallel programs that can be dynamically decomposed into a network of distributable objects.
- The “very large” tasks that require the resources that go beyond a single supercomputer.
- the decomposition must be able to hide huge latency variations
- the scheduling and recomposition/execution must be dynamic and adaptive.

## Meeting Goals

- Find out who is doing what.
- Isolate common needs and plans
- What technology is clearly missing?
- What requires more research?
- Which ideas can be implemented by a collective effort?
- IETF style RFP for the rest?

## More About the IPG Project

- from notes and discussions with William Johnston

## Initial Testbed Objective

- The IPG will provide:
- transparent data access (global naming, location transparent access, content metadata and/or standardized access methods)
- a global file system
- QoS, co-scheduling, and reservation for all services (esp. computational and communications)
- distributed debugging and application performance monitoring

## The IPG: A Multi-layer Design

- Application Problem Solving Environment

- Application Component Architecture

- Grid Architecture Components

- Grid Resources

*Computers              databases   satellites/telescopes/wind tunnels*

*High speed networks and routers*

- security

- authentication

- resource naming

- scheduling

- directory services

- authorization

- Composition tools

- Software repositories

- monitoring

- Global Shell

- shared file/data space

- AES Application components

- collaboration tools

## Next Highest Priority

- These services and capabilities need to be Globus compatible, but in the two year time frame we	also expect that Globus will evolve.
- integrate distributed collaboration services
- provide Grid based visualization tools
- provide common auditing and accounting interfaces for local resources
- provide resource discovery and brokering
- work on numerical algorithms for steeply hierarchical and variable latency memory access
- start implementing infrastructure protection for the testbeds

## Next Highest Priority (cont.)

- provide resource monitoring and autonomous component management
- provide distributed application data location management (i.e. dynamic data caching)
- provide automated, policy-based strong access control
- design and start implementation of NASA-specific problem solving environments
- provide high-speed, location independent access to tertiary storage systems
- provide Grid benchmarking suites and tools

## Long Term IPG Goals & Research

- ultra high-speed computing platform I/O systems and network interfaces
- adaptive compilation and resource driven dynamic linking
- application performance model based resource scheduling
- distributed object, and Java Grande applications & tools
- resource aware application adaptation
- numerical algorithms and libraries optimized for steeply hierarchical and variable latency memory access