Table of Contents
This guide contains information of interest to developers working with the RLS. It provides reference information for application developers, including APIs, architecture, procedures for using the APIs and code samples.
Features New in GT 4.0
- Bulk exists API to check existence of LFN, PFN or LRC entries.
globus-rls-cliexists and bulk exists commands.- Rename and bulk rename API to rename LFN or PFN entries in LRC. Renaming LFNs causes an LRC to RLI update to reflect changes at the RLI.
globus-rls-clirename and bulk rename commands.globus-rls-aggregatorsource.plscript that queries an RLS site's statistics and returns a well-formed XML record for use as a MDS aggregator source.
Other Supported Features
- Comprehensive C and Java library for catalog manipulation, index queries, and administrative tasks.
- Command line (
globus-rls-cli) tool for client operations on catalogs and indexes. - Command line (
globus-rls-admin) tool for administrative tasks.
Deprecated Features
- None
Tested platforms for RLS include most 32-bit flavors of Linux and UNIX, including RedHat, Solaris, and others.
Protocol changes since GT 3.2
- None
API changes since GT 3.2
globus_result_t globus_rls_client_lrc_exists_bulk (globus_rls_handle_t *h, globus_list_t *keylist, globus_rls_obj_type_t objtype, globus_list_t **str2bulk_list)added to support bulk exists on the LRC catalog.globus_result_t globus_rls_client_rli_exists_bulk (globus_rls_handle_t *h, globus_list_t *keylist, globus_rls_obj_type_t objtype, globus_list_t **str2bulk_list)added to support bulk exists on the RLI index.globus_result_t globus_rls_client_lrc_renamelfn (globus_rls_handle_t *h, char *oldname, char *newname)added to support rename of LFN in the LRC catalog.globus_result_t globus_rls_client_lrc_renamelfn_bulk (globus_rls_handle_t *h, globus_list_t *str2_list, globus_list_t **str2bulk_list)added to support bulk rename of LFNs in the LRC catalog.globus_result_t globus_rls_client_lrc_renamepfn (globus_rls_handle_t *h, char *oldname, char *newname)added to support rename of PFN in the LRC catalog.globus_result_t globus_rls_client_lrc_renamepfn_bulk (globus_rls_handle_t *h, globus_list_t *str2_list, globus_list_t **str2bulk_list)added to support bulk rename of PFNs in the LRC catalog.ArrayList org.globus.replica.rls.RLSClient.LRC.existsBulk(ArrayList strlist, int objtype)added to support bulk exists on the LRC catalog.ArrayList org.globus.replica.rls.RLSClient.RLI.existsBulk(ArrayList strlist, int objtype)added to support bulk exists on the RLI index.void org.globus.replica.rls.RLSClient.LRC.renameLFN(String name, String newname)added to support rename of LFN in the LRC catalog.ArrayList org.globus.replica.rls.RLSClient.LRC.renameLFNBulk(ArrayList str2list)added to support bulk rename of LFNs in the LRC catalog.void org.globus.replica.rls.RLSClient.LRC.renamePFN(String name, String newname)added to support rename of PFN in the LRC catalog.ArrayList org.globus.replica.rls.RLSClient.LRC.renamePFNBulk(ArrayList str2list)added to support bulk rename of PFNs in the LRC catalog.
Exception changes since GT 3.2
- None
Schema changes since GT 3.2
- None
RLS depends on the following GT components:
- globus_core
- globus_common
- globus_io
- globus_gssapi_gsi
- globus_usage
RLS depends on the following 3rd party software:
- RDBMS: MySQL, PostgreSQL, or Oracle
- ODBC manager: iODBC
- ODBC driver: MyODBC, psqlODBC, or Oracle
Security recommendations include:
- Dedicated User Account: It is recommended that users create a dedicated user account for installing and running the RLS service (e.g.,
globusas recommended in the general GT installation instructions). This account may be used to install and run other services from the Globus Toolkit. - Key and Certificate: It is recommended that users do not use their hostkey and hostcert for use by the RLS service. Create a containerkey and containercert with permissions
400and644respectively and owned by theglobususer. Change therlskeyfileandrlscertfilesettings in the RLS configuration file ($GLOBUS_LOCATION/etc/globus-rls-server.conf) to reflect the appropriate filenames. - LRC and RLI Databases: Users must ensure security of the RLS data as maintained by their chosen database management system. Appropriate precautions should be made to protect the data and access to the database. Such precautions may include creating a user account specifically for RLS usage, encrypting database users' passwords, etc.
- RLS Configuration: It is recommended that the RLS configuration file (
$GLOBUS_LOCATION/etc/globus-rls-server.conf) be owned by and accessible only by the dedicated user account for RLS (e.g.,globusaccount per above recommendations). The file contains the database user account and password used to access the LRC and RLI databases along with important settings which, if tampered with, could adversely affect the RLS service.
The Replica Location Service design consists of two components. Local Replica Catalogs (LRCs) maintain consistent information about logical-to-physical mappings on a site or storage system. The Replica Location Indexes (RLIs) aggregate state information contained in one or more LRCs and build a global, hierarchical distributed index to support discovery of replicas at multiple sites. LRCs send summaries of their state to RLIs using soft state update protocols. The server consists of a multi-threaded front end server and a back-end relational database, such as MySQL or PostgreSQL. The front end server can be configured to act as an LRC server and/or an RLI server. Clients access the server via a simple string-based RPC protocol. The client APIs support C, Java and Python. The APIs contain operations to create and delete mappings, associate attributes with mappings, and perform queries.
Detailed information on the architecture and design can be found in A Framework for Constructing Scalable Replica Location Services and Performance and Scalability of a Replica Location Service.
The semantics and syntax of the APIs for the component, along with descriptions of domain-specific structured interface data, can be found in the public interface guide.
This section provides examples illustrating the basic usage of the client interfaces supported by the RLS. Using the client API, developers may create client applications that interact with the RLS server to perform replica location operations.
Developing in C
Client applications developed in C must do both of the following:
- Include the client header file at
$GLOBUS_LOCATION/include/globus_rls_client.h. - Link to the client shared library at
$GLOBUS_LOCATION/lib/libglobus_rls_client_gcc32dbgpthr.
For C language example code, click here.
Developing in Java
Client applications developed in Java must do all of the following:
- Include the RLS Jar,
$GLOBUS_LOCATION/lib/rls.jar, in the CLASSPATH. - Import the RLS Package
org.globus.replica.rls.*. - Depend on the client shared library via the Java Native Interface (JNI).
For Java language example code, click here.
To run the RLS server in debug mode, use the -d option
along with the -L num option (e.g.,
$GLOBUS_LOCATION/bin/globus-rls-server -d -L 3). The
-d option instructs the RLS server to direct log output to
stdout, while the -L num
option sets the log level where a higher num results in
more detailed output.
Information on troubleshooting can be found in the FAQ.
For additional details, see the RPC Protocol Description.