GMA Testbed

Introduction

As part of the work of the Grid Forum Performance Working Group, we are developing a Grid Monitoring Architecture (GMA) testbed. The purpose of this testbed is to allow us to test the compatibility of protocol implementations, evaluate the protocols, schemas, and tools we are recommending, and to demonstrate the monitoring systems we are developing.

There is a GMA testbed mailing list and information on how to subscribe to the testbed mailing list is available on the home page

Architecture

The GMA testbed is still in the formative stages so there is no definitive architecture, components, or protocols. Some of the participants are following the GMA architecture (described in document GWD-Perf-6-1) and using the XML protocols specified in the document "A Simple XML Producer-Consumer Protocol" (GWD-Perf-8-2), but this is not required. At the current time, the only component that we need to standardize and require that everyone use is a directory service accessed using the Lightweight Directory Access Protocol (LDAP) and the format of the data in the directory service. This LDAP server is used to store information about the producers of events, consumers of events, and the schemas of the events. If we do not all use this LDAP server, it will be very difficult to locate producers and consumers written by other groups to interact with. The current schema for this information is specified in the document "Simple LDAP Schemas for Grid Monitoring" (GWD-Perf-13-1) and this document will be discussed at GGF-2 in July.

Directory Service

One of the main components of our testbed is a directory service that is accessed using LDAP. LDAP is a protocol for accessing directory services and it also assumes a certain structure to the data in the directory service. LDAP data is organized in a hierarchy, typically based around organizations and sub-organizations. The document GWD-Perf-13-1 includes an overview of LDAP and their are several good reference books available:
  1. T. Howes and M. Smith, LDAP: Programming Directory-Enabled Applications with Lightweight Directory Access Protocol. MacMillan Technical Publishing, 1997.
  2. T. Howes, M. Smith, and G. Good, Understanding and Deploying LDAP Directory Services. MacMillan Technical Publishing, 1999.
Our directory service contains information about producers of events, consumers of events, and event schemas. The format of this data is specified in GWD-Perf-13-1. At the current time, our directory service consists of a single server running on port 1389 and port 1636 on the host mds.nas.nasa.gov. Port 1389 can be used for insecure access or secure access (Start TLS - see IETF RFC 2830) and port 1636 can be used for secure access using the SSL/TLS protocols. The data in this directory service is readable by anyone, but is only writable by people who have been given permission to write into the server and who authenticate to the server using a user ID and a password. We suggest that you only provide your user ID and password over a secure connection. The schema specified in GWD-Perf-13-1 has been loaded into this server so modifications to the data that do not satisfy this schema (or the default LDAP schemas) will be denied.

There are several ways to access this data. OpenLDAP (www.openldap.org) provides an open source implementation of client and server LDAP tools (our LDAP server is, in fact, an OpenLDAP server). The ldapsearch command can be used to search the directory, the ldapadd command can be used to add objects to the directory, the ldapmodify command can be used to modify objects in the directory, and the ldapdelete command can be used to delete objects from the directory. An example insecure search of the contents of our directory is:

> ./ldapsearch -x -h mds.nas.nasa.gov -p 1389 -b "o=Grid" -s sub "(objectclass=eventSchema)"
version: 2

#
# filter: (objectclass=eventSchema)
# requesting: ALL
#

# UptimeCPULoad, Performance Working Group, GridForum, Grid
dn: eventName=UptimeCPULoad, ou=Performance Working Group, o=GridForum, o=Grid
objectClass: eventSchema
eventName: UptimeCPULoad
description: An event describing the CPU load on a computer system as measured
  by the UNIX uptime command.
inputNameSpace: http://www.gridforum.org/Performance/Events
outputNameSpace: http://www.gridforum.org/Performance/EventParameters

# Ping, Performance Working Group, GridForum, Grid
dn: eventName=Ping, ou=Performance Working Group, o=GridForum, o=Grid
objectClass: eventSchema
eventName: Ping
description: An event describing the result of a Unix ping.
inputNameSpace: http://www.gridforum.org/Performance/Events
outputNameSpace: http://www.gridforum.org/Performance/EventParameters

# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2

This search specified simple authentication (-x), a host (-h) of mds.nas.nasa.gov, a port of 1389 (-p), the position to start the search or the search base of o=Grid (-b "o=Grid"), a search scope of the subtree rooted at the base (-s sub), and a search filter that specifies that all objects that have an objectclass of eventSchema should be returned ("(objectclass=eventSchema)"). A warning: ldapsearch is temperamental about the format of the search filter and it may just not return any objects to you instead of reporting an error. For example, a filter of "&(objectclass=eventSchema)" will return no results but have no errors.

This same search can be accomplished using a URL for the LDAP server:

ldapsearch -H "ldap://mds.nas.nasa.gov:1389" -b "o=Grid" -s sub "(objectclass=eventSchema)" -x
If you have OpenLDAP clients that have been built with OpenSSL, our LDAP server can be accessed over a secure connection with Start TLS using:
ldapsearch -H "ldap://mds.nas.nasa.gov:1389" -b "o=Grid" -s sub "(objectclass=eventSchema)" -x -Z
The -Z specifies Start TLS. A secure connection over SSL can be used with:
ldapsearch -H "ldaps://mds.nas.nasa.gov:1636" -b "o=Grid" -s sub "(objectclass=eventSchema)" -x
The URL specifies the LDAP over SSL protocol, ldaps, and the port 1636.

OpenLDAP also provides C LDAP client libraries so that you can call LDAP client functions directly from your code. See the documentation or man pages that are provided by OpenLDAP for further information about both the command line programs and the client library. There are also LDAP command line programs and client libraries provided by commercial LDAP vendors and these should work just fine with our LDAP server.

Another approach is to use a GUI to access the LDAP server. One free GUI that Warren likes and recommends was written by Jarek Gawor of the Globus group. It can be downloaded from Jarek's LDAP page. This GUI can be used to search, browse, or modify an LDAP directory. It can even by used to change your password after you are given an ID. One problem we have found with this browser is that it doesn't seem to be able to access our LDAP server using a SSL connection. We are working with the creator of this software to determine where the problem may be. We recommend using a browser such as this to make your life much easier when you are examining or modifying the contents of a LDAP server by eye. Such a tool is not useful, of course, when your programs need to access a LDAP server.

The LDAP server for the GMA testbed is maintained by Warren Smith (wwsmith@arc.nasa.gov). Any problems, questions, or requests for write access should be directed to him.

Participants

Several groups have expressed interest in the GMA testbed, but the testbed is still in the early stages so the exact participants are evolving. The best way to get up-to-date information about participants is to browse the data in the LDAP directory service to see who has event producers or consumers in the testbed.

This page is the responsibility of:
Dan Gunter - DSD staff

Last modified: Mon Feb 12 13:28:14 PST 2001