Aims of the resource broker
Functionality of the ancestral broker EUROGRID broker
Interoperability architecture (UNICORE-Globus)
Towards a resource description ontology
Relation to the GGF and OGSA
January 17, 2003

Users
Virtual
Organisation
Brokers
System
Brokers
Compute
Resources
Organization
Firewalls

Client
Client
Client
Client
Client
Broker
Service
Broker
Service
VO Layer
Broker
Service
Broker
Service
Broker
Service
Specialist Layer
Broker
Service
Broker
Service
Replication
Broker
Service
Site Layer
Resource
Resource
Resource
Resource
Resource
Resource

We want to broker on Grids controlled by either
UNICORE or Globus. In GRIP we developed two methods
1.
Bifurcation, separate “sub-brokers” for a Globus or a Unicore Grid. This is achieved and is extensible to a limited extent.
2. Constructing an extendable resource broker utilising a Grid Resource Ontology to handle mappings of resource terms.

The API allows two levels of operation:
Resource Checking: Static requirements, capability and capacity.
QoS Checking: Performance vs cost. Tickets can be issued as a “guarantee”.
Protocol can be used symmetrically by Broker.
2 CheckQoS
Execution
NJS
3 CheckQoS_Outcome
User
1 CheckQoS Broker
NJS
4 CheckQoS_Outcome
2 CheckQoS
3 CheckQoS_Outcome
Execution
NJS
1

Bezier
SGI Onyx @ Manchester
Vtk + VizServer
UNICORE
Gateway and NJS
Manchester
Simulation
Data
UNICORE
Gateway and NJS
QMUL
Dirac
SGI Onyx @ QMUL
LB3D with RealityGrid
Steering API
Steering (XML)
Laptop
SHU Conference Centre


VizServer client
Steering GUI

The Mind Electric GLUE web service hosting environment with
OGSA extensions

Single sign-on using UK e-Science digital certificates

1. The Network Job Supervisor (NJS) delegates the
Resource Check to the Broker at the Vsite.
2. The UNICORE brokering track utilises the IDB exactly as for the ancestral broker.
3. The Globus track uses a translator of the QoS check object. The translation service is extendable.
4. The results of the translation are used to drive the
LDAP search and the Globus broker then utilises
MDS to perform this.
UNICORE NJS 4.0 gave much greater power and flexibility in brokering for complex workflows.

NJS
Delegates resource check
Broker
Diagram
Of Broker
Architecture
Unicore Broker
Lookup resources
IDB
Globus Broker
Delegates translation
Uses to drive
LDAP search
Translator
Basic Translator
Filter
Performs
LDAP search
MDS(GRIIS/GRIS)

•A nice feature of Method 1 is that no alteration needs to be made to the client side of UNICORE, thus no alteration for application plugins or “expert” brokers
•Also no alterations need to be made to Globus.
•However the UNICORE description of Grid resources is very different from the MDS-2 description. MDS-2 does not publish software resource and user environment, Unicore does not check dynamic resource, e.g. machine loading.
•The need for resource description translation is thus highlighted.

Resource Discovery
Service
Unicore Broker
Lookup resources
Hierarchical
Grid Search
IDB
Filter
Uses to
Drive MDS
Search
NJS
Delegates resource check
Broker
Delegates translation
Diagram
Of Broker
Architecture
Globus Broker
Uses to drive
MDS search
Other
Brokers
Translator
Filter
Ontology engine Hierarchical
Grid Search
Resource Discovery
Service

•Defines knowledge domain and allows reasoning on this domain.
•If we can create a Grid Resource Ontology, creation of specialist translation classes from basic Grid translator becomes possible.
•IDB at sites can be created via ontology, it contains site specific information which the clients job specification cannot do.
•So brokers take client request formulated in RR space, at each site use translator to convert to RR space, offers come back with capability and QoS.

Client
Gateway
NJS Broker
IDB
TSI/Host GT3
Normal EUROGRID/GRIP Brokering
Client
NJS
Gateway
Broker
NJS NJS R-GMA
Host Host Host
Site-Wide Brokering

Persistent Virtual
Environments
Metascheduling
Service
Workflow
Manager
Clients Other Brokers
Banking
Services
Broker
Chargeable Schedulable
GridServices
Site Feedback
Policy Manager
Resource Usage
Monitor

•Grid Protocol Architecture-RG : Core Grid Functions
•Grid Resource Allocation Agreement Protocol-WG
:advanced reservation, co-allocation
•CIM-based schema-WG : successor to LDAP
•GESA-WG looking at economic issues of scheduling
The recently-formed Semantic Grid RG is very interested in the Grid Resource Ontology idea.
1

•What is the relationship between brokering and scheduling?
•How to deal with legacy (not Grid-aware) schedulers?
•How to relate the ontologies from the application side
(Resource Requestor) to the service provision side
(Resource Provider)?
•How does a broker estimate upper and lower bounds for turnaround time?
•How far does the broker trust information from the service provider. Should it monitor running workflows?
1

A
C
RR space request
RP space
Request referral
RR space request
D
B
RP space sync
RP space
Figure 1: Request from RR space at A mapped into resource providers at B and C, with C forwarding a request formulated in RR space to RP space at D. B and C synchronize at end of workflow before results returned to the initiator A.
January 17, 2003 GRIP First Project Review 1