GT 4.2.0 WS Monitoring and Discovery Services (WS MDS) : System Administrator's Guide

Some common administrative uses of WS MDS:

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.

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:

A typical deployment of MDS will enable a project to:

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.

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.

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.

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:

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 .

The following diagrams outlines a VO-wide deployment:

[FIXME better diagram]

To register resources with the Index Service:

The configuration file consists of an optional defaultServiceGroupEPR, an optional defaultRegistrantEPR, and then one or more ServiceGroupRegistrationParameters blocks, each of which represents one registration.

You can use the example configuration at $GLOBUS_LOCATION/etc/globus_wsrf_mds_aggregator/example-aggregator-registration.xml, replacing the EPRs in that file with the EPRs for your resources. It includes many examples of configurations for GRAM, RFT and other situations.

The general syntax of the configuration file is:

<?xml version="1.0" encoding="UTF-8" ?>
<ServiceGroupRegistrations
  xmlns="http://mds.globus.org/servicegroup/client">

  // An optional default service group EPR.
  <defaultServiceGroupEPR>
    // Default service group EPR
  </defaultServiceGroupEPR>

  // An optional default registrant EPR.
  <defaultRegistrantEPR>
    // Default registrant EPR
  </defaultRegistrantEPR>

  // An optional default security descriptor file.
  <defaultSecurityDescriptorFile>
    // Path name of default security descriptor file
  </defaultSecurityDescriptorFile>

  // One or more service group registration blocks:

  <ServiceGroupRegistrationParameters>
    <ServiceGroupEPR>
      // EPR of the service group to register to
    </ServiceGroupEPR>
    <RegistrantEPR>
      // EPR of the entity to be monitored.
    </RegistrantEPR>
    <InitialTerminationTime>
      // Initial termination time
    </InitialTerminationTime>
    <RefreshIntervalSecs>
      // Refresh interval, in seconds
    </RefreshIntervalSecs>
    <Content type="agg:AggregatorContent">
      // Aggregator-source-specific configuration parameters
    </Content>
  </ServiceGroupRegistrationParameters>

</ServiceGroupRegistrations>

The following table describes the different blocks of the file and any parameters:

There are two interfaces available for deploying information providers: UsefulRP and the Execution Aggregator Source.

The UsefulRP framework can be used by any service that runs in a Globus container to create and advertise a resource property. The service code makes a call to a UsefulRP Java method, which in turn reads a configuration file to determine how to generate the resource property (by executing a command, reading a file, calling a Java method, or some combination of those methods). For a real-life example, the GRAM service uses UsefulRP to create and publish a resource property contaning information about the queues that it manages, then registers that resource property to the default Index server running in the same Globus container. End-users can find that information by querying GRAM directly or by querying MDS. Because the Index Service is a WSRF service that runs in the Globus container, it can also publish resource properties using UsefulRP; however, these will be published as separate resource properties rather than added to the same service group as the rest of the index information.

The Execution Aggregator Source is a mechanism for adding information to the resource property / service group used by the Index (or Trigger) service. An Index or Trigger service configured to use the Execution Aggregator Source will execute a program periodically and update its service group with the output of that program.

However, all a sysadmin typically needs to know about aggregator vs. usefulrp is that they require different methods of configuration (outlined in [fixme link to a later section]). The following section lists available information providers that are based on both aggregator and usefulrp.

The following list includes information providers available with a default installation of GT 4.2.0:

WS MDS is frequently used with cluster monitoring systems, such as Ganglia and Hawkeye (for Condor pools). GT 4.2.0 includes information providers for Hawkeye, Ganglia and Nagios. These information providers are based on the GLUE 1.1 schema and UsefulRP to collect information from two sources: the scheduler and the cluster monitoring system. Both sources are merged to form a single output resource property in the GLUE schema (which is used by GRAM4 and accessible via the Index Service).

In general, you simply edit a configuration file to add the correct configuration block, then restart the container. To make it simpler, you can use the mds-gluerp-configure tool to create a configuration file with the correct values.

	Note
	The scheduler does not need to be configured for default providers - GRAM4 already knows the scheduler bundle to use through other means.

For configuration details, follow these links:

The following information applies to Java WS Core and those services built on it.

Logging in the Java WS Core is based on the Jakarta Commons Logging API. Commons Logging provides a consistent interface for instrumenting source code while at the same time allowing the user to plug-in a different logging implementation. Currently we use Log4j as a logging implementation. Log4j uses a separate configuration file to configure itself. Please see Log4j documentation for details on the configuration file format.

   #for debug level logging from org.globus.package.FooClass 
   log4j.category.org.globus.package.name.FooClass=DEBUG
   #for warnings from org.some.warn.package
   log4j.category.org.some.warn.package=WARN
   

The specific logger to edit will be log4j.logger.sysadmin in $GLOBUS_LOCATION/container-log4j.properties. There you can configure the following properties:

log4j.appender.infoCategory=org.apache.log4j.RollingFileAppender
   log4j.appender.infoCategory.Threshold=INFO
   log4j.appender.infoCategory.File=var/containerLog
   log4j.appender.infoCategory.MaxFileSize=10MB
   log4j.appender.infoCategory.MaxBackupIndex=2

Above implies the logging file is rolling with each file size limited to 10MB and the logging information is stored in $GLOBUS_LOCATION/var/containerLog.

The sample log file contains many log entries for various scenarios in the Java WS container.