- A Globus Primer
- Globus Is Modular!
- Installing GT
- Platform Notes
- GT Developer's Guide
- GT User's Guide
- Migrating Guides
- GSI C
- GSI Java
- Java WS A&A
- C WS A&A (coming soon)
- Delegation Service
Table of Contents
- 1. Configuration overview
- 2. Default configuration
- 3. Getting started
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.
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).
... 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.
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.
For example, the jndi config file for GRAM4 is at
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.
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):
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”).
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.
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
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
<ServiceGroupRegistrationParameters xmlns="http://mds.globus.org/servicegroup/client" > <!-- Specifies that the registration will be renewed every 600 seconds (= 10 minutes) --> <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"> <!-- Specifies that the upstream index should refresh information every 10 minutes --> <agg:PollIntervalMillis>600000</agg:PollIntervalMillis> <!-- specified that the upstream index should collect the Entry resource properties from this index --> <agg:ResourcePropertyName>wssg:Entry</agg:ResourcePropertyName> </agg:GetResourcePropertyPollType> </agg:AggregatorConfig> <agg:AggregatorData/> </Content> </ServiceGroupRegistrationParameters>
The two settings of note here are the
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
RefreshIntervalSecsto a larger value will not affect the relative "freshness" of the aggregated data from each registrant; rather, this is controlled by the
PollIntervalMillisparameter of the GetResourcePropertyPollType element.
GetResourcePropertyPollTypeelement contained within the
AggregatorConfigelement 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:
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.
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
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.
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 .