RLS: System Administrator's Guide
Overview
>RLS Server (globus-rls-server)
RLS Server Configuration file (globus-rls-server.conf)
RLS Server (globus-rls-server)
The RLS server (globus-rls-server) can be configured as either
or both of the following:
- Location Replica Catalog (LRC) server, which
manages Logical FileName (LFN) to Physical
FileName (PFN) mappings in a database.
Note: Ifglobus-rls-serveris configured as an LRC server, the RLI servers that it sends updates to should be added to the database usingglobus-rls-admin.
- Replica Location Index (RLI) server, which manages mappings of LFNs to LRC servers.
Clients wishing to locate one or more physical filenames associated with a logical filename should first contact an RLI server, which will return a list of LRCs that may know about the LFN. The LRC servers are then contacted in turn to find the physical filenames.
Note: RLI information may be out of date, so clients should be prepared to get a negative response when contacting an LRC (or no response at all if the LRC server is unavailable.)
This page contains the following topics:
Synopsis
[ -B lrc_update_bf ] [ -b maxbackoff ] [ -C rlscertfile ] [ -c conffile ] [ -d ] [ -e rli_expire_int ] [ -F lrc_update_factor ] [ -f maxfreethreads ] [ -I true|false [ -i idletimeout ] [ -K rlskeyfile ] [ -L loglevel ] [ -l true|false ] [ -M maxconnections ] [ -m maxthreads ] [ -N ] [ -o lrc_buffer_time ] [ -p pidfiledir ] [ -r true|false ] [ -S rli_expire_stale ] [ -s startthreads ] [ -t timeout ] [ -U myurl ] [ -u lrc_update_ll ] [ -v ]
LRC to RLI Updates
Two methods exist for LRC servers to inform RLI servers of their LFNs.
- By default, the LFNs are sent from the LRC to the RLI.
This can be time consuming if the number of LFNs is large, but does give the RLI an exact list of the LFNs known to the LRC, and it allows wildcard searching of the RLI.
- Alternatively, Bloom filters may be sent, which are highly compressed summaries of the LFNs; however they do not allow wildcard searching, and they will generate more "false positives" when querying an RLI.
Please see below for more on Bloom filters.
globus-rls-admin can
be used to manage the list of RLIs that an LRC server updates.
This includes partitioning LFNs among multiple RLI servers.
A softstate algorithm is used in both update modes: periodically the LRC server sends its state (LFN information) to the RLI servers it updates.
The RLI servers add these LFNs to their index, or update a timestamp if the LFNs were already known. RLI servers expire information about LFN,LRC mappings if they haven't been updated for a period longer than the softstate update interval.
The following options in the Configuration file control the softstate algorithm when an LRC updates an RLI by sending LFNs:
Updates to an LRC (new LFNs or deleted LFNs) normally don't propagate
to RLI servers until the next softstate update (controlled by options lrc_update_ll and lrc_update_bf.
However,
by enabling "immediate update" mode (set lrc_update_immediate to
true),
an LRC will send updates to an RLI within lrc_buffer_time seconds.
If updates are done with LFN lists, then only the LFNs that have been added or deleted to the LRC are sent. If Bloom filters are used, then the entire Bloom filter is sent.
When immediate updates are enabled, the interval between softstate
updates is multiplied by lrc_update_factor as long
as no updates have failed (LRC and RLI are considered to be in sync).
This can greatly reduce the number of softstate updates an LRC needs
to send to an RLI.
Incremental updates are buffered by the LRC server
until either 200 updates have accumulated (when LFN lists are used),
or lrc_buffer_time seconds have passed since
the last update.
Bloom filter updates
A Bloom filter is an array of bits. Each LFN is hashed multiple times and the corresponding bits in the Bloom filter are set.
Querying an RLI to verify if an LFN exists is done by performing the same hashes, and checking if the bits in the filter are on. If not, then the LFN is known not to exist. If they're all on, then all that's known is that the LFN probably exists.
The size of the Bloom filter (as a multiple of the number of LFNs) and the number of hash functions, control the false positive rate. The default values of 10 and 3 give a false positive rate of approximately 1%.
The advantage of Bloom filters is their efficiency. For example, if the LRC has 1,000,000 LFNs in its database, with an average length of 20 bytes, then 20,000,000 bytes must be sent to an RLI during a softstate update (assuming no partitioning). The RLI server must perform 1,000,000 updates to its database to create new LFN,LRC mappings, or update timestamps on existing entries. With Bloom filters, only 1,250,000 bytes are sent (10 x 1,000,000 bits / 8), and there are no database operations on the RLI (Bloom filters are maintained entirely in memory). A comparison of the time to perform a 1,000,000 LFN update took 20 minutes sending all the LFNs, and less than 1 second using a Bloom filter. However as noted before, Bloom filters do not support wild card searches of an RLI.
Note: An LRC server can update some RLIs with Bloom filters, and others with LFNs. However an RLI server can only be updated using one method.
The following options in the Configuration file control Bloom filter updates:
rli_bloomfilter true|falserli_bloomfilter_dir none|default|pathnamelrc_bloomfilter_numhash Nlrc_bloomfilter_ratio Nlrc_update_bf seconds
Log messages
globus-rls-server uses syslog to log errors and other
information (facility LOG_DAEMON) when it's running in normal (daemon)
mode.
If the -d option (debug) is specified, then log messages
are written to stdout.
Signals
The server will reread its configuration file if it receives a HUP signal.
It will wait for all current requests to complete and shut down cleanly
if sent any of the following signals: INT, QUIT or TERM.
Options (globus-rls-server)
The following table describes the command line options available for globus-rls-server:
-b maxbackoff |
Maximum time (in seconds) that globus-rls-server will
attempt to reopen the socket it listens on after an I/O error. |
-C rlscertfile |
Name of X.509 certificate file that identifies the
server; sets environment variable X509_USER_CERT. |
-c conffile |
Name of configuration file for server. The default is |
-d |
Enable debugging. Server will not detach from controlling terminal
and log messages will be written to stdout rather than syslog.
For additional logging verbosity set loglevel (see |
-e rli_expire_int |
Interval (seconds) at which an RLI server should expire stale entries. |
-F lrc_update_factor |
If lrc_update_immediate mode is on, and the LRC server
is in sync with an RLI server (an LRC and RLI are synced if there
have been no failed updates since the last full softstate update),
then the interval between RLI updates for this server ( lrc_update_ll )
is multipled by lrc_update_factor. |
-f maxfreethreads |
Maximum number of idle threads server will leave running. Excess threads are terminated. |
-I true|false |
Turns LRC to RLI immediate update mode on ( The default value is
|
-i idletimeout |
Seconds after which idle client connections are timed out. |
-K rlskeyfile |
Name of X.509 key file. Sets environment variable X509_USER_KEY. |
-L loglevel |
Sets log level. By default this is 0, which means only errors
will be logged. Higher values mean more verbose logging. |
-l true|false |
Configure whether server is an LRC server. Default is |
-M maxconnections |
Maximum number of active connections. Should be small enough to prevent server from running out of open file descriptors. The default
value is |
-m maxthreads |
Maximum number of threads server will start up to support simultaneous requests. |
-N |
Disable authentication checking. This option is intended for debugging. Clients
should use the URL |
-o lrc_buffer_time |
LRC to RLI updates are buffered until either the buffer is full or this much time (in seconds) has elapsed since the last update. The default value is
|
-p pidfiledir |
Directory where PID files should be written. |
-r |
Configure whether server is an RLI server. The default value is |
-S rli_expire_stale |
Interval (in seconds) after which entries in the RLI database are considered stale (presumably because they were deleted in the LRC.) Stale entries are not returned in queries. |
-s startthreads |
Number of threads to start up initially. |
-t timeout |
Timeout (in seconds) for calls to other RLS servers (in other words, for LRC calls to send an update to an RLI.) A
value of The default value is |
-U myurl |
URL for this server. |
-u lrc_update_ll |
Interval (in seconds) between lfn-list LRC to RLI updates. |
-v |
Show version and exits. |