Given by Geoffrey C. Fox at Second DATORR Meeting Sandia National Laboratory on February 15-16 1999. Foils prepared February 20 1999
Outside Index
Summary of Material
Second Meeting of DATORR Group |
Desktop Access to Remote Resources |
This Presentation contains Motivating and Overview Remarks at Start of Meeting |
Followed by Summary of Working Group on Remote Resources |
Outside Index Summary of Material
An International HPCC/HPCN Community Activity to establish Interoperability Standards |
Second Working Group Meeting Sandia February 15,16 99 |
http://www-fp.mcs.anl.gov/~gregor/datorr |
datorr@mcs.anl.gov |
Thanks to Sandia -- Judy Beiriger, ... |
and to Argonne -- Gregor von Laszewski |
This presentation consists of two merged documents |
Firstly the overview given at start of meeting and |
Secondly the material prepared during discussion and wrap up of "Remote Resources" working group |
Very many machines, platforms, Operating Systems |
Though a good/necessary thing, using them in changing environment becomes difficult for users. |
Goal:
|
Datorr will help metacomputing but goals are focussed on a subset of issues and aimed at establishing interoperability standards -- reference implementations may follow but are not direct goal |
Seamless Interface |
Database1 |
Database2 |
User View |
System View |
2 working groups at |
last meeting |
3rd working groups was |
a particular service -- security |
Desktop
|
Which submit "tasks" to: |
Remote Resources in multi-tier systems
|
We are roughly defining properties and methods of those distributed objects associated with computing services -- these include jobs and resources |
This could lead to CORBA facilities or Java frameworks for computing services which was motivation for interest by Java Grande Forum at www.javagrande.org |
At a recent meeting at Argonne organized by NCSA Alliance, Datorr appeared to be very relevant to building reusable "Problem Solving Environment" tools a.k.a. components for domain specific "workbenchs" |
Identification and documentation of existing relevant projects |
Set of meetings leading to agreement on common standards |
International community input such as SC98 BoF |
Preliminary documents (on web) leading to (draft) final proposed standards
|
Selected community projects e.g. reference implementations |
What is the current state?
|
Where do we have to expand/focus? |
Most importantly workshop participants agreed that it was indeed useful to define common interoperable interfaces |
Mailing List datorr@mcs.anl.gov |
http://www-fp.mcs.anl.gov/~gregor/datorr |
Proceedings of first workshop available |
32 (15 more to add!) Existing Projects surveyed covering metacomputing, distributed scheduling, seamless interface, particular tools and technologies in areas such as resource management/monitoring/collaboration/security
|
http://www-fp.mcs.anl.gov/~gregor/datorr |
http://www-fp.mcs.anl.gov/~gregor/datorr/report/datorr-report.html |
http://www-fp.mcs.anl.gov/~gregor/datorr/report/datorr-security.html |
First we should have an update from nifty projects which were not discussed at the first meeting |
Then we should break into working groups in areas which aren't too controversial so we lay a solid foundation for future Datorr activities |
Suggested topics:
|
Globus |
Condor |
Legion |
Netsolve, Ninf |
GRD (Genias/Raytheon) |
NOW Millenium (UCB) |
Ninja (as services) |
Jini |
DoD Gateway, DRM (in planning phase) |
Dutch ASCI (Bal) |
Harness |
TOP500 and other Linpack registration and publication services |
PetaSIM and other performance estimators (Jim Browne, Warwick, Saltz at Maryland) |
CPUs |
System Architecture |
Databases |
Software -- libraries, licenses, applications, versions |
Network QoS, Bandwidth |
Storage
|
Visualization |
Memory |
Event Handlers |
Peripherals such as instruments |
Printers |
Cost: Money (accounting) and User Pleasure |
Extensibility |
Resource management (temporal versus spatial)
|
Services imply resources and vice versa |
Queue Length depends on dynamic issues
|
Express user needs, preferences, bank balance |
Language to compose resources into constraints etc.
|
Look up and discovery |
Security characteristics are difficult to express |
How to express standard?
|
Separate control path (discover resource) from data path (how you use) |
Standard should specify nature of API |
So access method is part of resource definition
|
High Level Principles?
|
Hierarchical definitions |
is user's bank balance a resource? |
A Legion is a resource
|
Note Globus could refuse to let you ask what machines where in its resource pool |
What is architecture of a resource
|
Sometimes discovery is trivial -- you remember your money is stored under your bed etc. |
What resources will the real world define
|
What is on our list
|
Discovery is not performance critical -- can use standards even if non optimal |
How does one query resource list |
Need both required and optional arguments |
Should document why certain things are there e.g. maybe some fields only there for some special computers |
Look into relationships with MIME types |
A given resource will have multiple XML descriptions depending on type of query
|
So need to specify types of query to define what one needs to define a resource |
Grand Challenge in XML is (courtesy of NPACI/UCB) distinguish Tera T90 old SP new SP, cluster of PC's WS's |
Ninja's list of interesting resources is broader but less detailed than Datorr |
Do we support multiple network interface cards reflecting different uses of system |
Identify successes and failures of previous systems |
A unifying concept is www.datorr.org which web site will support registration , lookup and display of world's compute resources
|
Scope of www.datorr.org is "computing" as the commodity market is not addressing
|
www.datorr.org appears a more modern "better" model than Globus Legion etc.
|
We should build into the initial prototype a "generic" or "simple" interface which is a low level API by which remote resource returns to www.datorr.org (perhaps in system dependent XML which could be later standardized) status information |
We should build an elegant web display of the information returned by the "generic" interface |
What is the subset? One suggestion is
|
After we decided that this is too hard -- do this later |
As part of this discussion, we discussed issues such as:
|
What is query mechanism?
|
Goal: Need XML definition of resources according to previous principles |
Choose a subset -- implement quickly e.g. one month |
Test or evaluate it (also a month)
|
Iterate process extending subset to other resources |
DATORR 1.0 at SC99 does not preclude DATORR 1.1 etc. later (i.e. must be extensible) |
SC99 demo of its use at www.datorr.org should include task definition (the other working group) |
Specify a given collection of computers: subset of
|
include multiprocessor nodes (include digital SMP's) and node linkage |
Query XML database for "linpack" performance |
Must build on the XML base infrastructure supporting extensibility, multiple views, hierarchy |
Registration service to add resources to www.datorr.org comes together with lookup service |
Identify "people" with responsibilities
|
An important initial activity is building XML base infrastructure supporting extensibility, multiple views, hierarchy |
What other projects teach us
|
XML Architecture
|
www.datorr.org design principles
|
www.datorr.org hosting and implementation
|
Project Description
|
XML specifications of prototype (Around April 1 start)
|
Testing and Evaluation of both XML and Website (also April 1)
|
Study and implementation of "generic" datorr interface and its "managerial level" web display (later than April 1)
|
Access method, security, scheduling including current load |
storage, database an other non compute resources |
Access mechanism as opposed to lookup/registration mechanism |
Full range of www.datorr.org services
|
Legion Globus Condor ... use www.datorr.org |
Download interface to remote resource with query |
Legion Globus etc. supply different interfaces to given remote resources |
Use of "generic" www.datorr.org interface to get machine status by working scientists |