MDS is a collection of monitoring services and related interfaces that collect and act on recent state information from information sources in a Grid. It is based on WSRF and WS-Notification specifications and built on the Java WS Core. You should be familiar with configuring information for Java WS Core and have a basic understanding of WSRF and web services, especially resource properties.

MDS includes an Index Service, which collects information and then advertises it as resource properties (which can then be queried or subscribed to using standard WSRF and WS-N interfaces) and a Trigger Service, which collects information and can be configured to perform actions when certain user-specified conditions are met. The Index and Trigger Services are built upon a common framework, the Aggregator Framework, which handles the collection of data. The interface for configuring how these services collect their information is the same.

1.1. Admin use cases

Some common administrative uses of WS MDS:

Use the MDS Index Service to monitor certain GT WSRF services (this is the default).
Chain MDS Index Services to create a hierarchy throughout a VO, with information aggregated in a central Index Service.
Use MDS Trigger Service to send an email when a condition on a grid resource is met (such as being notified when a service goes down).

2. Default configuration

After a default installation of GT version, the container includes a default Index Service, which should be visible when starting the container, like the following:

...
https://localhost:8443/wsrf/services/DefaultIndexService
...

These WSRF-based services automatically register themselves with the default Index Service running in the same Globus container:

Check the links to see what information is captured for each service and how to configure that information.

This means that without any further configuration, the default Index Service is already monitoring these services.

2.1. Simple usage

A typical example of using the default Index Service is with the wsrf-query Java WS Core command. For example:

$GLOBUS_LOCATION/bin/wsrf-query -s https://localhost:8443/wsrf/services/DefaultIndexService '/*'

displays all the resource properties collected by the default Index Service on your local host.

You can also use an XPath query to drill down your search as well as other Java WS Core commands such as wsrf-get-property and wsrf-get-properties. For more information, review the User's Guide.

2.2. Toggle automatic registration of GT WS components

To turn off (or on, depending on your situation) automatic registration of these components, edit the jndi-config.xml file of the component.

For example, the jndi config file for GRAM4 is at $GLOBUS_LOCATION/etc/gram-service/jndi-config.xml.

Find the following JNDI resource:

<resource name="mdsConfiguration" 
          type="org.globus.wsrf.impl.servicegroup.client.MDSConfiguration">
          <resourceParams>
             <parameter> 
                <name>reg</name>
                <value>true</value>
             </parameter>
             <parameter> 
                <name>factory</name>
                <value>org.globus.wsrf.jndi.BeanFactory</value>
             </parameter>
          </resourceParams>
</resource>

To configure the automatic registration of GRAM4 to the default MDS Index Service, change the value of the parameter <reg> as follows:

true turns on auto-registration; this is the default.
false turns off auto-registration.

2.3. Overview of a typical deployment

A typical deployment of MDS will enable a project to:

discover needed data from services in order to make job submission or replica selection decisions;
evaluate the status of Grid services for a project testbed;
be notified when disks are full or other error conditions happen;
visualize the state of services.

MDS should be deployed in a distributed fashion. Some components should be deployed central to a VO, while others should be deployed on individual resources.

In order to deploy a project or VO-wide WS MDS setup, we recommend the following steps (which we will expand on later):

	Note
	The services deployed do not need to be run on the same host or be at the same location.

Set up a hierarchy of Indexes with one as the central (VO) index to which all other Index Services are registered (see Section 3.1, “Building a Hierarchy of DefaultIndexServices”below):
- If you want to set up a site-wide Index Service with all services and resources for the project at that site registered to it, including those provided by Ganglia or Hawkeye, please see Section 1, “Registering a WSRF service to an Index Service” and Section 2.3, “Configuring custom information providers” under 'Advanced Configuration'.
- If you want to deploy an Index Service to act as the centralized data source for the VO to collect information about all of the resources in the VO, please see Section 1, “Deploying MDS into a Virtual Organization (VO)” (in addition to Section 3.1, “Building a Hierarchy of DefaultIndexServices”).
Set up WebMDS to view the contents of a central Index Service in a web browser (please see Section 3.2, “Visualizing Index Service with WebMDS” below).
Deploy a Trigger Service notification script to alert interested parties about changes in the status of the VO (please see Section 3.3, “Setting up email notifications via the Trigger Service”).

3. Getting started

This section will show you how to set up a basic hierarchy that monitors other GT web services (in Advanced Configuration, you will learn how to monitor almost any Grid resource). You will learn how to create a hierarchy of index services, use WebMDS to monitor from a web browser and set up a Trigger Service to be notified if any of the services go down.

3.1. Building a Hierarchy of DefaultIndexServices

This example shows how to configure the DefaultIndexService so that it will register itself to an upstream DefaultIndexService. By chaining such upstream registrations between hosts, it is possible to build a hierarchical virtual organization with a complete aggregate data view at the root level.

1. Change to the $GLOBUS_LOCATION/etc/globus_wsrf_mds_index directory.
2. Open the file hierarchy.xml and add one or more upstream entries using the URL to DefaultIndexService(s) you wish to register to. Example syntax for an upstream entry is as follows:
```
<upstream>https://vo-host:8443/wsrf/services/DefaultIndexService</upstream>
```
Please note that if a secure container is targeted, you must set the correct service URL (https protocol, right port number) in the upstream entry. Note: The defaultIndexService(s) you enter here will be higher in the hierarchy than the current one
2.a (This step is optional) Change the default upstream registration settings (if desired) in the upstream.xml file:
```
<ServiceGroupRegistrationParameters
   xmlns="http://mds.globus.org/servicegroup/client" >


   
   <RefreshIntervalSecs>600</RefreshIntervalSecs>


   <Content xsi:type="agg:AggregatorContent"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:agg="http://mds.globus.org/aggregator/types">

      <agg:AggregatorConfig xsi:type="agg:AggregatorConfig">
         <agg:GetResourcePropertyPollType
            xmlns:wssg="http://docs.oasis-open.org/wsrf/sg-2">
            
            <agg:PollIntervalMillis>600000</agg:PollIntervalMillis>

            
            <agg:ResourcePropertyName>wssg:Entry</agg:ResourcePropertyName>

         </agg:GetResourcePropertyPollType>
      </agg:AggregatorConfig>
      <agg:AggregatorData/>
   </Content>

</ServiceGroupRegistrationParameters>
```
The two settings of note here are the RefreshIntervalSecs and the PollIntervalMillis parameters.
RefreshIntervalSecs
This parameter specifies that the local DefaultIndexService will attempt to refresh the registration made to the upstream DefaultIndexService every (n) seconds. If the upstream DefaultIndexService is a high level or root-level member of a VO hierarchy, or is intended to support a large number of registrants, it may be desirable to set the refresh interval to be a larger value so that the overall amount of registration traffic is reduced. Note that setting the RefreshIntervalSecs to a larger value will not affect the relative "freshness" of the aggregated data from each registrant; rather, this is controlled by the PollIntervalMillis parameter of the GetResourcePropertyPollType element.
PollIntervalMillis
The GetResourcePropertyPollType element contained within the AggregatorConfig element specifies that the upstream DefaultIndexService should poll the local DefaultIndexService "Entry" resource property every (n) milliseconds, based on the value of this parameter. Alter this parameter in order to control the interval upon which data from the downstream (local) DefaultIndexService is refreshed in the upstream DefaultIndexService.
3. Start the container by running:
```
$ ./bin/globus-start-container
```

When the DefaultIndexService is first activated, it will read the contents of the hierarchy.xml file and attempt to make an upstream registration for each upstream entry found within that file. The service will make each registration according to the parameters found in the upstream.xml file. Any errors or warnings during the registration process will be written to the container log. If successful, the "Entry" resource property of the upstream Index will contain a child element for the downstream (local) Index, and a copy of the downstream Index "Entry" resource property will be cached within that element.

3.2. Visualizing Index Service with WebMDS

WebMDS is built and installed as part of a default GT installation and you only need to deploy the servlet to view the contents of the DefaultIndexService (in the local container) via a web browser.

To visualize the Index Service:

Deploy the servlet into a servlet container such as Tomcat. For more information see the Deploying section in the WebMDS Admin Guide.
Point your web browser at http://your-tomcat-host:your-tomcat-port/webmds
Click on the link labelled "A list of resources registered to the local default index service".

For more detailed information about changing the look of WebMDS and more advanced configuration, see the WebMDS Admin Guide.

3.3. Setting up email notifications via the Trigger Service

Deploy the Trigger Service to notify interested parties about certain configured changes in the status of the resources that an Index Service is monitoring. This can be useful for receiving emails about a service going down, etc. For a basic tutorial to get you started with the Trigger Service, see Trigger Service - Easy HowTo .

Prev		Next
Building and Installing	Home	Deploying