Gm to arex migration
From NorduGrid
Contents |
Migration from Grid-Manager to A-REX
ARC 0.8 includes the A-REX component, the next generation ARC job management service (see technical documentation). This component is an optional replacement of the previous Grid Manager component. It is possible to have both the Grid Manager and the A-REX deployed in the same box and by a simple service start/stop change between the two at any time. The A-REX is configured to share the same gridftp-based job submission interface the Grid Manager is using as well.
In order to be able to turn on the A-REX component, we assume that you have already successfully built and installed all the A-REX prerequisities and the full ARC 0.8rc1 bundle including the A-REX itself.
Why migrate?
The job handling code of A-REX is essentially a refactored Grid Manager, and so from a system administrator's point of view there are not many visible changes. But for ARC developers the new code structure makes like much easier. This means that future new features will only be added to A-REX and only essential bug fixes will be ported to Grid Manager. There are already some features which are not in the Grid Manager (see below). From a user's point of view there will also not (yet) be much difference in the execution efficiency of jobs, in other words jobs will not complete any faster on sites running A-REX. The most visible change will be in the improved logging of information concerning the job.
In summary, migrating to A-REX will lead to improved developer support, access to new features over time and easier debugging of problems for users.
(Almost) NO configuration changes
When replacing the Grid Manager with A-REX no additional configuration is necessary. A-REX understands the exact same configuration as the Grid Manager, it takes all the configuration parameters from the same arc.conf file used also by the Grid Manager.
The only configuration parameter you may wish to change is the "debug" parameter which specifies a log level. The Grid Manager accepts values from 0 (no logging) to 3 (VERBOSE), but A-REX uses values 0 (FATAL) to 5 (DEBUG). To maintain the same log level in A-REX you can usually add 2 to the previous Grid Manager level. This parameter also controls the logging level of the downloader and uploader executables to the job.id.errors files in the control directory (in the Grid Manager this was not changeable).
If you install any of the Grid Manager or A-REX in an unusual location, make sure pluginpath="/opt/nordugrid/lib" in arc.conf points to the actual location of plugins. When unsure, simply remove this line - a correct path will be picked up automatically.
Full Compatibility
Any computing element utilising the pre-configured A-REX as distributed with the v0.8 release is fully compatible with any other ARC service and client. This is because the WS-inteface of A-REX is turned off and A-REX is configured to use the gridftp-based job submission interface of the Grid Manager.
Note on the Cache
The A-REX can use files cached by the Grid Manager and vice versa. However, A-REX always uses a port number in URLs even if not specified in the job description, and so if a URL without a specified port number was cached by the Grid Manager, it will not be used by A-REX since the URL with the port number added will be mapped to a different cache filename. For example:
| Service | URL | Cache filename |
|---|---|---|
| Grid Manager | http://localhost/data/file1 | /pathtocache/data/a8/a8d4ca5a55f6b65a1ddca9e9e1c102cf176459 |
| A-REX | http://localhost:80/data/file1 | /pathtocache/data/82/5bdc761499a3985aab6c93d25283f8732de0b9 |
Therefore after migration many cache files may be downloaded again even though it appears they are in the cache. The old files will be automatically cleaned up after some time as they will no longer be used.
Turning on/off A-REX
The A-REX service, as it is distributed with the v0.8, offers an out-of-the-box full replacement for the Grid Manager component. You can decide which one to run and it is possible to swap between them any time. It is important that you run only one of them at the same time: either A-REX or the Grid Manager.
To turn on A-REX first make sure that the Grid Manager is not running:
/etc/init.d/grid-manager status
Stop the Grid Manager:
/etc/init.d/grid-manager stop
Start A-REX
${ARC_LOCATION}/etc/init.d/a-rex start
Stop A-REX (e.g. if needed for maintenance)
${ARC_LOCATION}/etc/init.d/a-rex stop
Additional A-REX features
The following features are only available in A-REX.
Web Service Interface
A-REX is a very powerful component, a next generation job execution service. For example, it provides a standard-compliant Web Service interface to handle job submission/management. The WS interface of A-REX is however disabled in the v0.8 distribution. If you are interested to experiment with A-REX advanced features, a configuration file (arex_service-secure.xml.example located in $ARC_LOCATION/share/doc/arc) is provided which should be loaded into A-REX through the arched daemon (see the technical documentation for details):
arched -c arex_service-secure.xml.example
Cache cleaning logging configuration
A-REX gives the option of changing the logging level of the cache-clean tool, through the parameter cacheloglevel in the configuration file. Similar to the "debug" parameter, this one takes values from 0 (FATAL) to 5 (DEBUG).
Data Validation
For input files downloaded from an indexing service (eg LFC or RLS), metadata (file size, checksum) from these files is compared to metadata reported by the service hosting the physical replica of the file (eg SRM or GridFTP). If the metadata differs then the replica is not downloaded. This only applies to data downloaded to cache, for which stricter checks are needed.
Separate limits for transfer shares
It is possible to specify a separate limit for one or several transfer shares. For such share this limit will be used instead of the default in "maxloadshare"
