Multiple servers

Often it is the case that the data that an application wants to access is spread over multiple data servers as in this schematic:
The client application thus needs to know (or determine from some external source) on which server any given data file is located. It can then access those files directly with URL's like:

root://kan001//data/aaaFile.root
root://kan002//data/bbbFile.root

While this may work for small systems with few users, it has some disadvantages:

• If users know statically where files are located it doesn't easily permit load balancing by moving files between servers or by replicating them to spread the load.
• If an external catalog is read by the client in order to determine which server has the file, any changes to that catalog must be synchronized with what actually happens to the files on disk.
• If the file isn't actually on disk, but is retrieved from somewhere else when the client asks for it (e.g. mass storage, discussed in later examples), there is no easy way to manage the disk space to insure that it is used efficiently and uniformly.

The xrootd system provides a method for solving these problems via its "open load balancer" component. This provides a method for providing transparent access data servers as show in this schematic:
In addition to the dataservers an additional machine (the "redirector") is added. It does not need to have any disk space itself as its sole role is to redirect the client dynamically to an actual data server machine which can serve the requested file. Thus client applications open all files via the redirector "kanrdr":

root://kanrdr//data/aaaFile.root
root://kanrdr//data/bbbFile.root

The redirection to the appropriate dataserver will take place automatically (with the proper server configuration, discussed below) and hence the user running the application doesn't need to know anything about the actual layout of the data over the data servers. Note also that after redirection the client is reading directly from the data server to which it was redirected. It does need the redirector any longer (at least until it needs to open a different file).

To accomplish this a second daemon, the olbd, must be started on both the redirector and each of the dataservers as show in the figure above.

Configuration of an xrootd/olbd system

Let's jump right to a working configuration and then explain it. As an example we take a redirector (called "kanrdr") and two data servers (called "kan001" and "kan002") with files "aaaFile.root" and "bbbFile.root" as above.

For the redirector we use a config file:

#
# redirector.cf 
#
# xrootd
xrootd.fslib /opt/xrootd/lib/libXrdOfs.so
xrootd.export /data
odc.manager kanrdr 3121
odc.trace redirect
# olbd
olb.port 3121
olb.allow host kanrdr.slac.stanford.edu
olb.allow host kan001.slac.stanford.edu
olb.allow host kan002.slac.stanford.edu

and for the data servers we use:

#
# dataserver.cf 
#
# xrootd
xrootd.fslib /opt/xrootd/lib/libXrdOfs.so
xrootd.export /data
oss.readonly
odc.manager kanrdr 3121
# olbd
olb.port 3121
olb.subscribe kanrdr 3121

As in the earlier examples, the actual path the to the libXrdOfs.so may depend on your installation. (And you should obviously substitute your machine names for kanrdr/kan001/kan002.)

It is then possible to start the xrootd and olbd servers on each of the machines.

On dataserver kan001:

xrootd -t -l kan001.xrdlog -c dataserver.cf &
olbd -s   -l kan001.olblog -c dataserver.cf &

On dataserver kan002:

xrootd -t -l kan002.xrdlog -c dataserver.cf &
olbd -s   -l kan002.olblog -c dataserver.cf &

And on the redirector kanrdr:

xrootd -r -l kanrdr.xrdlog -c redirector.cf &
olbd -m   -l kanrdr.olblog -c redirector.cf &

This should give you a working system capable of providing (readonly) access to data files on two servers transparently masqueraded behind a single redirector machine.

Testing the example load balanced system

Once the system is running we can try to open one of the files, for example:

root [1] myfile = TFile::Open("root://kanrdr//data/aaafile.root");

The first thing you will see is in the (redirector) kanrdr.xrdlog file:

040817 09:19:21 004 XrootdXeq: User logged in as elmer.317:17@noric15
040817 09:19:21 004 odc_Locate: user=elmer.317:17@noric15 wait  5 path=/data/aaafile.root
040817 09:19:26 004 odc_Locate: user=elmer.317:17@noric15 redirected to kan001.slac.stanford.edu 0 path=/data/aaafile.root

and then in the (dataserver) kan001.xrdlog file you should see:

040817 09:19:26 004 XrootdXeq: User logged in as elmer.317:16@noric15

which would mean that the client has been successfully and automatically redirected to kan001, the actual location of the file. You should then be able to do operations on the file like:

root [2] myfile->ls();
XTNetFile**             root://kanrdr//data/aaafile.root
 XTNetFile*             root://kanrdr//data/aaafile.root
  KEY: TF1      fooHist;1       gaus
  KEY: TF1      barHist;1       gaus

Similarly, opening the other file in the client:

root [3] myfile2 = TFile::Open("root://kanrdr//data/bbbfile.root");

will result in the following in the (redirector) kanrdr.xrdlog file:

050404 01:59:01 353 XrootdXeq: elmer.8870:12@noric04 login
050404 01:59:01 353 odc_Locate: elmer.8870:12@noric04 asked to wait 5 by kanrdr path=/data/aaafile.root
050404 01:59:06 353 odc_Locate: elmer.8870:12@noric04 redirected to kan001.slac.stanford.edu:1094 by kanrdr path=/data/aaafile.root

etc. etc. Your client will be redirected and connect itself to kan002, the actual location of the requested file.

In both cases the client need only connect to (and know about) the redirector machine. Everything else happens dynamically.

Explanation of the config files and command line options used

(Coming soon...)