Software Links
Getting Started
- Doc Structure
- A Globus Primer
- Globus Is Modular!
- Quickstart
- Installing GT
- Platform Notes
- Migrating from GT2
- Migrating from GT3
Reference
- PDF version
- Best Practices
- Coding Guidelines
- API docs
- Public Interfaces
- Resource Properties
- Samples
- Glossary
- Performance Studies
Common Runtime
Security
Data Mgt
Information Svcs
Execution Mgt
Table of Contents
This guide contains advanced configuration information for system administrators working with the WS MDS Index Service. It provides references to information on procedures typically performed by system administrators, including installation, configuring, deploying, and testing the installation.
![[Important]](/docbook-images/important.gif) | Important |
|---|---|
This information is in addition to the basic Globus Toolkit prerequisite, overview, installation, security configuration instructions in the GT 4.1.1 System Administrator's Guide. Read through this guide before continuing! |
The Index Service is built and installed as part of a default GT 4.1.1 installation. For basic installation instructions, see GT 4.1.1 System Administrator's Guide. No extra installation steps are required for this component.
![[Note]](/docbook-images/note.gif) | Note |
|---|---|
The aggregation source used to collect data can be changed from default, as detailed in the "Defining the Aggregator Sources" section below. |
For a basic installation, the index service itself does not need any configuration changes from default; a default Index Service is available and automatically "registers" with the following GT web services based resources to allow monitoring and discovery: CAS, RFT, and GRAM4 (click the links for information about what data is sent and how to change it).
| Note |
|---|---|
Auto-registration is turned on by default in GT 4.1.1. See the per service links above for information about configuring this capability. |
In order for information to appear in the index, the source of that information must be registered to the Index Service. Information sources are registered using tools like mds-servicegroup-add(1). Each registration has a limited lifetime; mds-servicegroup-add should be left running in the background so that it can continue to refresh registrations. Depending on administration preference, it may be run on the same host as the index, on the same host as a member resource, or on any other host(s).
The Index Service is built on WS MDS Aggregator Framework and can use any Aggregator Sources Reference
to collect information. In the most common case, the index service
uses the QueryAggregatorSource to gather resource
property values from the registered resource using one of the three
WS-Resource Properties operations to poll for information; the
polling method used depends on the configuration element supplied
in the registration content.
Two other aggregator sources are supplied with the distribution:
the SubscriptionAggregatorSource, which gathers
resource property values through subscription/notification, and the
ExecutionAggregatorSource, which executes an external
program to gather information.
The aggregation source used to collect data can be changed from
default by editing the aggregatorSources parameter in the JNDI
service configuration. See
$GLOBUS_LOCATION/etc/globus_wsrf_mds_index/jndi-config.xml:
<resource name="configuration"
type="org.globus.mds.aggregator.impl.AggregatorConfiguration">
<resourceParams>
<parameter>
<name> factory</name>
<value>org.globus.wsrf.jndi.BeanFactory</value>
</parameter>
<parameter>
<name>aggregatorSource</name>
<value>org.globus.mds.aggregator.impl.QueryAggregatorSource
org.globus.mds.aggregator.impl.SubscriptionAggregatorSource
org.globus.mds.aggregator.impl.ExecutionAggregatorSource
</value>
</parameter>
</resourceParams>
This parameter specifies one or more Java classes that may be used to collect data for the Index. By default it is set to use the QueryAggregatorSource, SubscriptionAggregatorSource, and ExecutionAggregatorSource. Details of the supplied sources are in the Aggregator Sources Reference.
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 jndi-config.xml file:
<parameter> <name>publishAggregatorConfiguration</name> <value>false</value> </parameter>
By default, this option is disabled and the aggregator configuration information is published.
The Index Service is deployed into the Globus container by default during the standard toolkit installation.
The WS MDS Index Service has been tested to work without any additional setup when deployed into Tomcat. Please follow these Deploying into Tomcat to deploy GT4 services into Tomcat. Note: please complete any prerequisite service configuration steps before you deploy into Tomcat.
The entire content of the default index service in a deployment can be seen by executing the following command, which will dump the entire RP set of the service:
wsrf-query -a -z none -s https://127.0.0.1:8443/wsrf/services/DefaultIndexService/
The security considerations for the Aggregator Framework also apply to the 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: An index service entry has AggregatorConfig data but an empty AggregatorData entry.
Solution: There is probably something wrong with the registration. For example, a registration that uses QueryAggregatorSource aggregator source may have incorrect values for the resource's hostname or port number or a misspelled resource property name, or the remote resource may impose security restrictions that prevent the queries from the index from working. You can use the standard toolkit resource property query tools (such as wsrf-get-properties) to verify that the remote resource is responding.