- Doc Structure
- A Globus Primer
- Globus Is Modular!
- Installing GT
- Platform Notes
- Migrating from GT2
- Migrating from GT3
- PDF version
- Best Practices
- Coding Guidelines
- API docs
- Public Interfaces
- Resource Properties
- Performance Studies
Table of Contents
This guide contains advanced configuration information for system administrators working with WS MDS Aggregator Framework. It provides references to information on procedures typically performed by system administrators, including installation, configuring, deploying, and testing the installation.
This information is in addition to the basic Globus Toolkit prerequisite, overview, installation, security configuration instructions in GT 4.1.1 System Administrator's Guide. Read through this guide before continuing!
The Aggregator Framework is built and installed as part of the standard Globus Toolkit installation procedure: GT 4.1.1 System Administrator's Guide.
The Aggregator Framework does not have its own service side configuration, although services which are based on the framework have their own service side configuration options (such as MDS Index and MDS Trigger") which are documented in the per-service documentation.
Registrations to a working Aggregator Framework are configured for the mds-servicegroup-add(1) tool. This tool takes an XML configuration file listing registrations, and causes those registrations to be made.
In general, configuration of aggregator services involves configuring the service to get information from one or more sources in a Grid. The mechanism for doing this is defined by (inherited from) the Aggregator Framework and described in this section.
Configuring an Aggregating Service Group to perform a data aggregation is performed by specifying an AggregatorContent object as the content parameter of a ServiceGroup add method invocation. An AggregatorContent object is composed of two xsd:any arrays: AggregatorConfig and AggregatorData:
- The AggregatorConfig xsd:any array is used to specify parameters that are to be passed to the underlying AggregatorSource when the ServiceGroup add method is invoked. These parameters are generally type-specific to the implementation of the AggregatorSource and/or AggregatorSink being used.
- The AggregatorData xsd:any array is used as the storage location for aggregated data that is the result of message deliveries to the AggregatorSink. Generally, the AggregatorData parameter of the AggregatorContent is not populated when the ServiceGroup add method is invoked, but rather is populated by message delivery from the AggregatorSource.
The following links provide information for configuring the three types of aggregator sources provided by the Globus Toolkit:
An aggregator sink may require sink-specific configuration (the MDS Trigger Service requires sink-specific configuration; the MDS Index Service does not). See the documentation for the specific aggregator service being used for details on sink-specific documentation.
It is now possible to disable the publishing of the aggregator configuration along with the aggregated data. The following optional parameter can be added to the AggregatorConfiguration section of the service
<parameter> <name>publishAggregatorConfiguration</name> <value>false</value> </parameter>
By default, this option is disabled and the aggregator configuration information is published.
The Aggregator Framework is a software framework used to create services. To test that the Aggregator Framework is working, deploy and test a service (such as WS MDS Index Service.
By default, the aggregator sources do not use authentication credentials -- they retrieve information using anonymous SSL authentication or no authentication at all, and thus retrieve only publicly-available information. If a user or administrator changes that configuration so that a service's aggregator source uses credentials to acquire non-privileged data, then that user or administrator must configure the service's aggregator sink to limit access to authorized users.
Problem: I was able to successfully register an aggregator entry with mds-servicegroup-add, but the aggregator isn't collecting data for the registration.
Solution: The fact that the registration was successful does not mean that there are no errors in the registration parameters. Verify that details such as resource EPRs, resource property names, and queries are accurate, and check the container logs for the aggregator service and (if applicable) the remote service for more information.
Problem: I was able to successfully register an aggregator entry with mds-servicegroup-add, and the aggregator collected information for this entry for a while, but then the entry disappeared.
Solution: make sure that mds-servicegroup-add is still running. Registrations time out; mds-servicegroup-add refreshes them periodically.