# Presentation: 355074

## Information Servicesand Monitoring Projects

-             Jennifer M. Schopf             James Magowan
-           Argonne National Lab	                   IBM UK
- LCG Workshop
- March 13, 2002

## Resource Discovery/Monitoring

- Large numbers of distributed sensors with different properties, varying status
- Need different views of this information, depending on community membership, security constraints, intended purpose, sensor types, etc

**R**

**R**

**R**

**R**

**R**

**R**

**?**

**?**

**R**

**R**

**R**

**R**

**R**

**R**

**R**

**R**

**R**

**?**

**?**

**R**

**R**

**R**

**R**

**R**

*dispersed users*

**VO-A**

**VO-B**

* **network*

## Grid Monitoringand Information Services

- System information is critical to operation of the grid and construction of applications
- We need:
- Systems that work through failures
- Interoperablity between grids
- Agreements/standards to allow continued use of local monitoring (if it already exists)

## Overview

- Framework
- MDS - Globus information service
- R-GMA - EDG WP-3 information service
- Coordination and Schema Work
- PPDG/GriPhyN joint monitoring effort
- GLUE-schema effort
- Schema work in GGF

## Metacomputing Directory Service (MDS)

- Globus Information Service
- Used by iVDGL, GriPhyN, PPDG, EDG, NMI, Grads, etc.
- Requirements and characteristics
- Uniform, flexible access to information
- Scalable, efficient access to dynamic data
- Access to multiple information sources
- Decentralized maintenance
- Secure information provision
- Main contact John McGee (mcgee@isi.edu)

## MDS Architecture

- Resources run a standard information service (GRIS) that speaks LDAP and provides information about the resource
- GIIS provides a “caching” service
- Resources register with GIIS
- GIIS pulls information when requested by a client (when out of date)
- GIIS provides the collective-level indexing/searching function

**GIIS**
- Cache contains info from A and B

- GRIS register with GIIS
- GIIS requests info
- from GRIS services

- Client 1

- Client 2

- Client 1requests  infodirectly from resources.

- Client 2 uses GIIS for searching
- collective information.

**Notes:**
GIIS is an index node. Index nodes can be designed and optimized for various requirements

## Protocols

- MDS protocols based on LDAP
- Dynamic Registration via Reg. Protocol (GRRP)
- soft-state protocol
- Resource Inquiry via Info. Protocol (GRIP)
- Co-located with resource on network
- Resource Discovery (via GRIP or other)
- Using GRIP allows resource/directory hierarchy
- Also well defined interfaces to add new sensor data

## Soft-state Registration

- Periodic notification
- “Service/resource is available”
- Expected-frequency metadata
- Automatic directory construction
- Add new resources to directory
- Invite resources to join new directory
- Self-cleaning
- Reduce occurrence of “dead” references

## MDS-2 Implementation

- Grid Information Service (GRIS)
- Provides resource description
- Modular content gateway
- Grid Index Information Service (GIIS)
- Provides aggregate directory
- Hierarchical groups of resources
- NOTE: EDG Ftree
- flexible backend for MDS by EDG WP3
- currently in EDG testbed installation of MDS

## What’s next for MDS (core)

- MDS 2.2 expected in April 2002
- Will harden the 2.1 code
- Additional performance improvements
- Address some of the packaging difficulties that occurred with 2.1
- Notification is currently not included in MDS 2.2 because it was not required as part of the use cases gathered by the joint monitoring group
- The following release will likely be the OGSA-ified version, currently under discussion, and will include notification

## What next for MDS Monitoring

- Leading the effort to have common schemas between EDG and US projects
- Defining additional information providers in cooperation with sensor developers
- One example - GridFTP logging data
- source address, file name, file size, number of parallel streams, TCP buffer size, start and end timestamps, total time consumed, aggregate bandwidth achieved, read/write
- www-unix.mcs.anl.gov/~vazhkuda/GridFTP-Information-Provider/

## Overview

- Framework
- MDS - Globus information service
- _R-GMA - EDG WP-3 information service_
- Coordination and Schema Work
- PPDG/GriPhyN joint monitoring effort
- GLUE-schema effort
- Schema work in GGF

## Introduction

- Europe
- European DataGrid Project
- DataTAG
- CrossGrid (new)
- GMA
- from GGF Perf Working Group
- several implementations
- R-GMA
- Implications of OGSA
- EDG TestBeds

## Grid Monitoring Architecture (GMA)

- We use it not only for monitoring but also as the basis of an information system

- Consumer

- Producer

- Registry

-  register

- lookup

- We have chosen a relational implementation

## R-GMA

- Not a general distributed RDBMS system, but a way to use the relational model in a distributed environment where ACID properties are not generally important.
- Producers announce:	SQL “CREATE TABLE”			    publish:	SQL “INSERT”
- Consumers    collect:	SQL “SELECT”

## Table Example

*The round trip time from RAL to Lyon as measured pinger was 500 ms on the 9**th** November at 11:00. *:
- (RAL, Lyon, Pinger, 1500, 001-11-09T11:00Z)
*A set of such tuples could be stored in a table:*
- NetworkMonitor(NM1, NM2, Tool, Measurement, Time/Date)
*Any structured data can be represented in tables in this manner**.*
*Complex queries can be formulated with SQL. *

## Power behind R-GMA

- The set of tables producers publish constitute a global relational schema
- Individual producers contribute “views” on this global virtual database
- Views can themselves be expressed in SQL
- Queries against the global schema have to be matched with suitable producers
- This soon becomes complicated due to issues of soundness and completeness of producers so we need a mediator.

## Schema and views I

**0.5**

**ALICE**

**GLA**

**UK**

**19055811022002**

**0.4**

**CDF**

**GLA**

**UK**

**19055711022002**

**0.3**

**CDF**

**RAL**

**UK**

**19055611022002**

**1.6**

**ATLAS**

**RAL**

**UK**

**Timestamp**

**Load**

**Facility**

**Site **

**Country**

**19055611022002**

**0.9**

**ALICE**

**CERN**

**CH**

**19055511022002**

**0.6**

**CDF**

**CERN**

**CH**

**CPULoad (Global View)**

**19055511022002**

**0.6**

**CDF**

**CERN**

**CH**

**19055611022002**

**1.6**

**ATLAS**

**CERN**

**CH**

**CPULoad (Producer3)**

## Schema and Views II

- WHERE Country = ‘UK’ AND Site = ‘RAL’

- WHERE Country = ‘UK’ AND Site = ‘GLA’

- SELECT load FROM CPULoad WHERE Site=‘GLA’

- SELECT load FROM CPULoad WHERE Facility=‘CDF’

## Example

**SELECT S.Name, C.Name, N.Measurement**
**FROM NetworkMonitor N, ComputingElement C, StorageElement S**
**WHERE S.NM = N.NM1 AND C.NM = N.NM2 AND MEASUREMENT < 1000**

## OGSA - Future

- OGSA and GMA originate from GGF
- R-GMA is conceptually close to OGSA
- OGSA - replaces resources with services
- OGSA has an index for locating services
- R-GMA might (eventually) use OGSA index to provide the functionality needed for the Schema/Registry
- In the short term the R-GMA Registry and Schema will instead be OGSA services
- Notification (Source and Sink) - may provide some of the functionality we require for R-GMA
- We plan to be quick off the mark with this work

## R-GMA Architecture

**Notes:**
This is admittedly a VERY busy slide
Red are lightweight API’s in Java or C++ Yellow are Servlets that run the business logic
A user writes sensor code to collect or measure information
She uses the Producer API to anounce the producer with an SQL create table statement
This triggers a chain of event by which the ProducerServlet to which the API connects registers the existence if the Information Producer in the Registry and the characteristics of the table in the Schema.
The User publishes information by means of an SQL insert statement, this makes the information available in a circular buffer on the ProducerServlet
A User who is looking for information (maybe to process it further and republish it!) uses the Consumer API to collect information by issuing an SQL select statement. This triggers a chain of events by which the Consumer Servlet to which the Consumer API connects contacts the registry to find out which Producers exist that can answer this query and contacts the ProducerServlet(s) serving those Producers to request information.
We can get either the latest inserted row or get data streamed to the Consumer (through the ConsumerServlet)
Registry and Servlet are “hidden” from the user.
We also have a DBProducer which uses a Database as a persistence medium
The Archiver API enables a user to collect data from a number of Producers and republish all this information in a central place. We use the DBProducer to do that.
CircularBufferProducer publish only one table
DataBaseProducer can naturally publish more than one table

## EDG Testbeds

- Existing testbed contains MDS, Ftree and R-GMA
- R-GMA will be used in upcoming testbeds to feed information into MDS
- Minimum disruption, Resource Broker
- Use existing backend scripts
- Test R-GMA with proper workload
- Gain experience in configuring R-GMA

## TestBed 2

- SE

- Info Provider Script

- CE

- Info Provider Script

- ..........

- Resource Broker

- MDS

- MDS

- MDS

- R-GMA
- Producer

- R-GMA
- Producer

- R-GMA

## DataGrid Testbed 2

- The main info services will be R-GMA
- Security - via Spitfire Mechanism (EDG WP2)
- Shift towards Web Services
- More powerful Mediator
- GRM/Prove using R-GMA as transport
- Improved documentation

## Summary

- Moving towards R-GMA from Ftree and MDS
- R-GMA to initially feed into MDS
- Using GMA from GGF
- Relational view of the world
- As powerful as the mediator
- Very similar to upcoming OGSA
- servlets not web services at the moment
- move towards Web Services and OGSA

## Overview

- Framework
- MDS - Globus information service
- R-GMA - EDG’s information service
- _Coordination and Schema Work_
- PPDG/GriPhyN joint monitoring effort
- GLUE-schema effort
- Schema work in GGF

## Joint Monitoring ProjectPPDG/GriPhyN/iVDGL

- PPDG
- Delivery of end-to-end applications and integrated production systems
- GriPhyN
- Virtual Data for Data Grids - resource management, security, fault tolerance research in support of virtual data
- iVDGL
- Create, operate and evaluate international research lab for data-intensive science
- All using common Grid middleware
- Globus, Condor, etc.

## How can we coordinate our efforts?

- October 2001 formed the joint PPDG/GriPhyN/iVDGL monitoring working group
- Cross-cutting effort between experiments to have a common framework
- Co-chairs: Jennifer Schopf, Brian Tierney
- www.mcs.anl.gov/~jms/pg-monitoring
- mail to pg-monitoring@mcs.anl.gov

## Charter

- The goal of this group is to coordinate the monitoring effort between GriPhyN/iVDGL and PPDG. There is a large body of work involving monitoring systems for distributed or Grid resources, and we plan to leverage heavily from them whenever possible.

## Gather Use Cases and Requirements

- Defined a template
- 19 use cases from ~9 groups
- Roughly 4 categories
- Health of system
- System upgrade evaluation
- Resource selection
- Application specific progress
- Working on requirements document now

## Deploy a Common Framework

- MDS GIIS for joint project use
- Possibility of using WP-4 network monitoring framework (currently under discussion)?
- Need for joint schemas at the Grid level- see GLUE-schema work in JTB

## GLUE-Schema Effort

- Part of HICB/JTB GLUE framework
- To address need to common schemas between projects
- framework independent
- something to translate into, not a requirement within fabric layer
- Co-chairs: Cristina Vistoli  and Brian Tierney
- maillist: glue-schema@hicb.org
- www.hicb.org/glue/glue-schema/schema.html

## Problems with Schema’s

- Naming MetaData implies a structure, e.g. relational, hierarchical, etc
- Attribute/Measurement units
- Attribute/Measurement naming
- Object/Entity naming
- Representation of a schema (LDAP, SQL, XML, CIM, etc)
- A lot of schemas out there
- information, monitoring, scheduling, accounting, security, and more!

## Goal

- Define a minimum common schema requirement for interoperability
- Compute Elements, Network Elements, Storage Elements
- EDG, DataTag, PPDG, GriPhyN, iVDGL, etc.!
- Proposed first step: creation of a table comparing some of the initial approaches
- First draft sent to mailing list Monday

## Example

## Overview

- Framework
- MDS - Globus information service
- R-GMA - EDG WP-3 information service
- Coordination and Schema Work
- PPDG/GriPhyN joint monitoring effort
- GLUE-schema effort
- _Schema work in GGF_

## DAMED WG

- Discovery And Monitoring Event Description Working Group
- Chairs
- Jennifer Schopf, ANL
- James Magowan, IBM
- Dammed if we do
- Not everyone will be happy
- Dammed if we don’t
- Never reach our goal of seamless interoperability of grids (one big grid e.g. internet)

## Charter

- Define a basic set of monitoring event descriptions
-  information (attributes) associated with a particular data element
-  conventions for the representation of the value associated with it.
- Develop standard representations of the most widely used measurement values (the "top N".)
- Emergence of a set of conventions and recommendations that will ease the task of defining richer, domain-specific schemas

## Milestones

- Research existing schemas
- draft of comparison of some schemas currently in process
- Completion by April 2002
- Develop "English" descriptions for the "top N" monitoring elements.
- Completion by May 2002
- Map English definitions to basic technologies including LDAP, SQL, XML.
- Draft for discussion by GGF-5

## Simple Steps

- Links to current Grid schema effort
- Units and names for basic top n attributes/Measurements
- More complex entities involving more than one measurement/attribute.
- Solve Entity Identity Problems

## How to get involved

- Subscribe to mailing list
- damed - damed-wg@gridforum.org
- WebSite
- http://www-didc.lbl.gov/damed
- EDG input through WP3 to DAMED
- wp3 (EDG) - edgschemas@jiscmail.ac.uk

## Other efforts

- DataTAG WP4 (Ghiselli, Vistoli)
- http://datatag.web.cern.ch/datatag/
- Distributed Monitoring Framework (Tierney), Web 100
- http://www-didc.lbl.gov/DMF/
- Network Weather Service (Wolski)
- http://nws.cs.ucsb.edu/
- PingER (Cotrell)
- http://www-iepm.slac.stanford.edu/pinger/
- CrossGrid WP3
- http://www.crossgrid.org/
- HENP working group in Internet2
- http://www.internet2.edu/henp/
- PyGMA (LBL), NASA-GMA (Smith, NASA Ames)
- and more!

## Additional Information

- MDS
- www.globus.org/gt2/mds2.1/
- PPDG/GriPhyN/iVDGL joint effort
- www.mcs.anl.gov/~jms/pg-monitoring/
- Glue-schema
- www.hicb.org/glue/glue-schema/schema.html
- R-GMA
- hepunx.rl.ac.uk/grid/wp3/
- damed-wg
- http://www-didc.lbl.gov/damed