PandaDataServiceTest

Introduction

This page is meant to provide information on installing the test versions of DQ2 components to support DQ2 v0.2.12 for USATLAS sites. The instructions provide details on installing DQ2 0.2.12 site services and a Local Replica Catalog (LRC).

DQ2 Site Services

System Requirements For Testing

A machine for running DQ2 site-services and the LRC

Testing so far has been on 32-bit SLC3/RHEL3 machines and we are beginning to work with SLC4. At present DQ2 site services is not working with SLC4. The current recommendation is that the LRC be on a 32bit SLC3 machine. The DQ2 site services will occupy around 500MB of disk space while the LRC will occupy ~1.5GB

A gridftp server

This can be an existing gridftp server or you can install a copy of the VDT on your test machine.

Storage

You should have adequate storage resources available to the gridftp server to cache files while testing the DQ2 installation. This should be on the order of 100GB.

Pre-installation Steps

Grid Certificates

Neither DQ2-site services or the LRC require the use of a host certificate for the machine, but your gridftp server will need one. DQ2 requires the use of a user certificate. This certificate must be registered in the CERN VOMS for proper interaction with the BNL FTS server.

TiersOfAtlas entry

Your test site should be listed in the TiersOfATLASCache.py file used by DQ2. You should identify the following information:
  • DQ2 Site NAME (e.g. UTA_TEST, BU_TEST)
  • LRC Contact information ( Host, port, LRC Read account/password )
  • Base URL for storage (host,path e.g. gsiftp://gk02.swt2.uta.edu/ifs1/dq2_test/Storage)

Once you identify this information, please send the data to someone who can modify the TOACache file. Wensheng and Patrick (others may have access as well) can update the file.

FTS Channel

A channel will need to be created within the BNL FTS server to support transfers to your test site. If the gridftp server is different from your production system you should contact Hiro or Wensheng to get the channel created.

Decide on which components to use

Beginning with this release, you have the option of using preinstalled versions of python and MySQL to support DQ2 site services and the LRC (still needs work). The python should be version 2.3.4 or later and MySQL should be 4.0.24 or later.

Expected commands

The installation process expects to find certain commands in $PATH to succeed. The commands are:
  • mysql_config
  • curl-config

Installing

You will need to install pacman. Pacman versions 3.18.5 and 3.19 were used for most test installations. Older versions may be compatible but have not been tested. The latest version is available at: http://physics.bu.edu/pacman/sample_cache/tarballs/pacman-latest.tar.gz

DQ2 site services

If you wish to use an installed version of python you should verify that it is the first python found in $PATH
If you wish to use an installed version of MySQL, you should make sure that the MySQL binaries are in $PATH and $LD_LIBRARY_PATH contains the path to the MySQL libraries or is in the default library search path.

The pacman command to get things rolling is:

 pacman -get http://www.atlas-swt2.org/pacman/DQ2:DQ2-Test 

You will be prompted several times during the installation. The first two questions concerning trusting the pacman cache at UTA and for the VDT components. The next question will ask for your DQ2 Site name. The last two question will ask if you want to install private versions of python and MySQL. If you answer "Y" to these questions, the installation process will download and configure these components. If you wish to use system components you should answer with a "N"

The final messages should be:
Installation has completed
see post_install/README for more information

*Note:*
To setup the installation, you should source:
config/SITE_NAME/environment.sh
This has changed from previous installations.

Post installation Configuration

If you are using a pre-installed version of MySQL, the next section will show you how to make the MySQL server ready for use with DQ2. If pacman installed a version of MySQL this is not necessary. Production servers may need to modify the TOA timeout but this is not expected to be necessary for test installations. An LRC needs to be installed and configured. The post install steps of the LRC will provide information on configuring DQ2 to use the LRC.

MySQL

If you installed a private version of MySQL for DQ2 there are no configuration actions necessary. However, if you used a pre-installed version of MySQL, there are some extra steps needed to make the DQ2 installation functional:
Create an account in MySQL for DQ2 operations
The appropriate mysql syntax should look something like:
GRANT ALL PRIVILEGES ON queued_transfers_XXXXX.* TO dq2user@localhost IDENTIFIED BY 'dqpwd'; 

Notes:
You should replace XXXXX with your DQ2 site name (e.g. UTA_TEST)
The example above assumes that the DB service is installed on the same machine as the DQ2 services. If this is not the case, replace localhost with name of the machine hosting DQ2.
The account/password is not required to be dq2user/dqpwd. You should change these to more appropriate values if your DB service can be access by anyone other than the installer.

Create the database needed by DQ2
The mysql command to use should look like:
CREATE DATABASE IF NOT EXISTS queued_transfers_$DQ2_SITE;
Modify the DQ2 configuration
The file $DQ2_LOCATION/config/$DQ2_SITE/executor_conf.py contains a variable that controls how DQ2 contacts the DB service. The installation will contain the following lines (the second is commented out)
queued_transfers_cat = 'mysql://dq2user:dqpwd@/queued_transfers_XXXX?unix_socket=/data/mysql.sock'
#queued_transfers_cat = 'mysql://dq2user:dqpwd@hostname:3306/queued_transfers_XXXX'

Only one of these forms should be enabled. The first is appropriate if you want to connect to a db service that is local to DQ2 site host AND you are attempting to connect through the file socket. If you use this form, you should verify the username/password AND path to the file socket is correct.

The second form is appropriate when DQ2 must connect to a remote DB service or a local DB service will be used and access is through a TCP port. You should verify that the username/password/hostname are correct for your situation. You should protect this file as read-only to the installation account:
chmod 600 $DQ2_LOCATION/config/$DQ2_SITE/executor_conf.py

Populate the database with tables
This is the first chance to run any code that is DQ2 related. Do the following:
  • Verify that $PATH $LD_LIBRARY_PATH are correct for the versions of python and MySQL
  • Verify that the MySQL server is running
  • Source $DQ2_LOCATION/config/SITE_NAME/environment.sh (This has changed from previous pacman installations)
  • python $DQ2_LOCATION/DQ2/siteservices/executor/classic/RecreateDatabase.py

Starting and Stopping services

Starting DQ2 Services

There is a file created in $DQ2_LOCATION/util/agents.cron that are appropriate for starting/DQ2 services. This file may need to be merged with a crontab generated by the LRC installation. If you are using a pre-installed version of MySQL, you should delete the lines:
# DQ2_MySQL
*/20 * * * * (source $DQ2_SETUP; $DQ2_MYSQL/mysql.sh start > /dev/null 2>&1)
The Fetcher process is configured to run every five minutes but the exact time is randomized to ease the burden on the Central Catalog server.

If you want to run the DQ2 services outside of the crontab file, you should run the following (assuming that your environment is correct):

python $DQ2_LOCATION/DQ2/siteservices/executor/classic/LoggingServer.py
python $DQ2_LOCATION/DQ2/siteservices/executor/classic/SpawnAgents.py
python $DQ2_LOCATION/DQ2/siteservices/executor/classic/AssignAgents.py
You can then run the Fetcher manually with:
 python $DQ2_LOCATION/DQ2/siteservices/executor/classic/Fetcher.py YOUR_SITE_NAME

Stopping Services

Stopping the DQ2 site services is more complicated in v0.2.12. You need to kill a process by hand, run a python script, and then kill two remaining processes.

1.) Remove the crontab if enabled.

2.)First find the process responsible for executing SpawnAgents.py

ps -auxw | grep SpawnAgents

and kill the appropriate process Execute the python script.

3.)Next, kill off the various agents

python $DQ2_LOCATION/DQ2/siteservices/executor/classic/StopAgents.py 

This will kill off the various agents within DQ2. It may take some time, but you should be left with two running processes, The Logger and AssignAgents.

4.) Lastly, You should kill the AssignAgents process, then the Logger process using the same mechanism as SpawnAgents.

Notes:


Major updates:
-- Main.mcguigan - 12 Jan 2007



Responsible: PatrickMcGuigan

Never reviewed

Edit | Attach | Watch | Print version | History: r8 | r6 < r5 < r4 < r3 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r4 - 2007-01-25 - PatrickMcGuigan
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    PanDA All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback