GRIDCC - providing a real-time Grid for distributed instrumentation

advertisement
GRIDCC - providing a real-time Grid for distributed
instrumentation
The GRIDCC Collaboration
Istituto Nazionale di Fisica Nucleare, Legnaro, Italy
Institute Of Accelerating Systems and Applications, Athens, Greece
Brunel University, Uxbridge, UK
Consorzio Interuniversitario per Telecomunicazioni, Italy
Sincrotrone Trieste S.C.P.A., Trieste, Italy
IBM, Haifa, Israel
Imperial College London, London, UK
Istituto di Metodologie per l’Analisi ambientale – Consiglio Nazionale delle Ricerche, Potenza, Italy
Universita degli Studi di Udine, Udine, Italy
Greek Research and Technology Network S.A., Athens, Greece
(Contact for this paper: Peter R Hobson, School of Engineering and Design, Brunel University,
Uxbridge, UB8 3PH, UK
Email: Peter.Hobson@brunel.ac.uk)
Abstract
The GRIDCC project will extend the use of Grid computing to include access to and
control of distributed instrumentation. Access to the instruments will be via an interface
to a Virtual Instrument Grid Service (VIGS). VIGS is a new concept and its design and
implementation, together with middleware that can provide the appropriate quality of
service, is a key part of the GRIDCC development plan. An overall architecture for
GRIDCC has been defined and some of the application areas, which include distributed
power systems, remote control of an accelerator and the remote monitoring of a large
particle physics experiment, are briefly discussed.
Introduction
The goal of GRIDCC [1] is to build a widely distributed system that is able to remotely control
and monitor complex instrumentation that ranges from a set of sensors used by geophysical
stations monitoring the state of the earth to a network of small power generators supplying the
European power grid. These applications introduce requirements for real-time and highly
interactive operation of computing Grid resources. The project is currently in its initial stages
and work is primarily concentrated in the areas of workflow and architecture definition,
refining the use-cases for the applications and the testing and evaluation of existing Grid
middleware to determine whether it meets our requirements.
Architecture
The overall architecture of GRIDCC has now been defined and is shown in Figure 1. The
Virtual Control Room (VCR) is the GRIDCC user interface. It allows users to build complex
workflows which are then submitted to the Execution Service, it can connect to resources
directly and be used to control instruments in real time. The VCR also extends human
interactions with Grid resources through its Multipurpose Collaborative Environment.
Figure 1
The components of the GRIDCC architecture
The Instrument Element of GRIDCC
The Instrument Element (IE) is a collection of services: the Virtual Instrument Grid Service
(VIGS), the Resource Service (RS) and the Local Problem Solver.
The VIGS concept is at the core of GRIDCC, it is shown diagrammatically in Figure 2. The
Access Control Manager (ACM) will identify every user or entity (another VIGS for instance)
and provide the proper authorization protocol. The Instrument Manager (IM) receives
commands from the VCR (or another VIGS). These are then routed to the instruments under the
control of the IM.
IMS
Virtual Instrument Grid
Service
ACCESS
CONTRO
L
Instrument
Instrument
Manager
Manager
Controls
,
Status
Data
Mover
It contains a
Finite State Machine.
FSM reflects the status
of the whole instruments
commanded by the
Instrument Manager
To Grid Farms,
Data storage,
Visualization,
etc.
Virtual Control
Room
Real Instruments or
Set of Instruments
Figure 2
InfoServ
Proxy
Errors, Log
Info,
Monitor, State
Control
Flow
Errors
Flow
Data
Flow
A Schematic of the VIGS concept. The terms are defined in the text.
A Resource Service instructs this manager on the number, type and location of the instruments
it should control: it knows the topology of the instruments, the connection type, their
identification, etc. The Info Service Proxy collects all the information (errors, state and monitor
data) from the instruments and acts as local cache before sending the data to the central
Information Monitoring Service (IMS). The Data Mover Manager moves the data acquired
from the instruments.
Automated problem solving in a Grid environment is a major feature of the project. Two levels
of problem solver are proposed; one to solve problems related to the function of a given
instrument and one to solve system wide problems.
Other Elements of GRIDCC
Compute and Storage Elements (CE & SE) within GRIDCC are similar in function to those in
other Grid projects. However these are extended to encompass the quality of service
requirements that are central to GRIDCC.
The Execution Service (ES) controls the execution of the workflows defined by the user in the
VCR. It maintains the status of the jobs that make up the workflow. It controls the quality of
service by making agreements with the resources available to it whether these be IEs, CEs or
SEs. The ES consists of three services: the Workflow Management System, the Workload
Management System and the Reservation Manager.
GRIDCC requires an all pervasive Information and Monitoring System (IMS). This reports the
status and availability of the resources as well as propagating errors.
Our proposed baseline security architecture has the end-user authenticated at the User Interface
(Control Room) by using their system credentials, (e.g. username/password, and a X.509
Certificate issued by a trusted Certification Authority). The core system, consisting of Control
Rooms (User Interfaces) and VIGSs (Computing Elements), employs a ticket-based
authentication mechanism and symmetric cryptography via centralized Key Distribution
Servers. Authorization is performed at the VIGS level employing local access rules. In Use
Cases requiring secure and accountable interfacing to GSI based Grids (e.g. EGEE/LCG) endusers should pass GSI proxy certificates along with their control messages that trigger the
GridCC – EGEE/LCG interaction.
Applications
From the outset the GRIDCC project team analysed use cases from a wide range of different
applications. The applications are: the High-Energy Physics experiment CMS [2], the particle
accelerator ELETTRA [3], monitoring of distributed electrical power generators [4]
meteorology, analysis of neurophysiological data for migraine detection, and a geophysical
monitoring network. The first three of these are regarded as core applications and are currently
being taken forward to demonstration on actual Grid test-beds.
Current Status of the Project
The overall architecture of GRIDCC has now been determined. We have carried out a
preliminary evaluation of a number of candidate middleware products with data from test-bed
evaluations of RGMA [5], NARADA [6], Sun Message Queue-JMS [7], Globus Toolkit 4.0
WSRF Core [8] being obtained. No final decision has yet been taken on which middleware will
be used and it is likely that for our first application demonstrations (end of project year 1) more
than one will be implemented on our test beds. Progress has been made in defining an overall
framework for the problem solver. Where possible we we have been mindful of the need to
inter-operate with other Grid projects and to adhere to the standards that are emerging in the
world of Web Services.
Our primary goal for the end of the first year of the project (September 2005) is to demonstrate
a number of our applications running within our GRIDCC architecture on dedicated testbeds.
References
[1] http://www.gridcc.org
[2] http://cmsdoc.cern.ch/cms/TRIDAS/Temp/CMS_DAQ_TDR.pdf
[3] http://www.elettra.trieste.it/info/index.html
[4] M Irving, G Taylor, P Hobson, IEEE Power & Energy Magazine March/April 2004, pp 40-44
[5] www.r-gma.org
[6] http://www.naradabrokering.org/
[7] http://www.sun.com/software/products/message_queue/index.xml
[8] http://www.globus.org
Acknowledgement
This project is supported under EU FP6 contract 511382.
Download