MDS Deployment and Configuration

Introduction

The Meta Directory Service (MDS) is a special problem for Grid deployment since it is designed to publish information that is unique to a particular machine, site, or grid. The deployment problem has changed with the adoption of the Grid Packaging Technology (GPT) as the deployment mechanism for the Globus Toolkit. This paper summarizes a discussion held with John McGee of ISI. This discussion focused on the final configuration solution and intermediate solutions that could be implemented now.

A description of the various configuration files for MDS can be found here. The configuration focuses on three areas:

GRIS Configuration: This configuraion has two parts. The first part defines what information providers are available. The second part defines which GIIS's need the information
GIIS Configuration: This configuration requires a list of GRIS's that are sending information and a schema defining how the ldif objects sent by the GRIS's should be organinzed.
SLAPD Backend Configuration: This configuration defines what backends are used by the slapd service.

Deployment Methods in a Package Environment

Using packages for deployment requires a change in deployment methods.

Adding functionality to a component needs to be done by adding additional packages.
Localization of files to add host specific information needs to be done using pre/post install scripts.
Pre/post install scripts and the templates the used need to be deployed as setup packages that are seperate from the packages containing the source code and installed binaries

Deploying Information Providers

Each GRIS manages a set of information providers that are defined in the configuration file grid-info-resource-ldif.conf. Currently the MDS deploys a default set of information providers, but the design of MDS allows for other information providers to be added on a site or grid basis. To actually implement this though takes some thought.

The final solution

grid-info-resource-ldif.conf needs to go through two sets of converions. As illustrated by the following diagram

The information providers start with a set of template files that are deployed via packages with an overall GRIS configuration tool. The tool allows a user to select a set of information providers and then generates a setup package containing a grid-info-resource-ldif.conf.in file which defines the set. After this setup package is installed, a post install script is run to localize the file to the host. A similar solution would need to be provided for the file grid-info-resource.schema.

Interim Solution

In the meantime procedures for assembling a set of information providers and for defining a new information provider needs to be written. From this grid-centric GRIS setup packages can then be created.

Deploying GRIS to GIIS Registration Information

Both the GRIS and the GIIS need to be able to know who to talk to. This information is contained in the following files:

grid-info-resource-register.conf: Lists the GIIS servers to which this GRIS will register directly.
grid-info-site-policy.conf: Controls acceptance of incoming GRIS registrations

For a typical virtual organization the identity of the GIIS's are known beforehand. This information can thus be included in a GRIS setup package created by the organization. Unfortunately the identity of all of the GRIS's cannot always be known beforehand. The file grid-info-site-policy.conf is designed to accept regular expressions such as wildcards so that a set of GRIS's can be identified. Unfortunately these expressions are currently based on the DNS of the GRIS.

Final Solution

Add the list of GIIS's to the setup package created by the GRIS configuration tool. Change the format of the file grid-info-site-policy.conf so that the expressions are based on the GSI distinguished name. In this way GRIS's can be registered by the virtual organisation distinguished name.

Interim Solution

Virtual organizations need a tool that will manage the list of GRIS's in the grid-info-site-policy.conf file. Some perfomance measurements are also need to see what effect large GRIS lists will have.

Deploying SLAPD Backends

The slapd demon is designed so that backend can be added and removed without recompiling the demon. The file grid-info-slapd.conf is used by slapd to identify these backends. Ideally the backends should be deployed as separate packages. Unfortunately this is not possible because of the grid-info-slapd.conf which has to list all of the backends the slapd demon should load.

Final Solution

The slapd demon needs to be modified so that a separate configuration file for each backend is read. This is similar to what is done for the xinetd demon.

Interim Solution

Seperate sets of backends need to run there own slapd demon. For example the MDS backends are deployed seperately from the Network Weather Service backend. If both sets are deployed on the same host then two slapd demons need to run.

Michael Bletzinger

Last modified: Tue Mar 19 17:47:36 CST 2002