Objectivity Conditions DB per Dati R18(b,c):
installation, updates & maintenance

REPOSITORY DEGLI SNAPSHOTS & TRASFERIMENTO

Un link utile informativo sugli snapshots.

Il server bbr-serv01 viene destinato a server di importazione degli snapshots per il DB per dati R18(b,c,d);
essi vengono messi in /data/snapshots :

[bbrobjy@bbr-serv01 snapshots]$ ls -tlr
drwxr-xr-x 3 bbrxfer bbrepro 4096 Dec 15 23:38 master
-rwxr-xr-x 1 bbrxfer bbrepro 885 Dec 16 12:15 transfer

Il file transfer e' uno script perl per il trasferimento da SLAC ad altro sito, p.es. al CNAF.
Nella sua esecuzione ci si connette a slac (p.es. su una macchina yakut) e si va in /nfs/objyserv03/objy/databases/snapshots/
Li' sotto /master/full si prende tipicamente la versione current. Essa viene rilasciata settimanalmente (al giovedi').
Nel caso specifico si e' copiata la versione del 15-dec-05.

Lo snapshot full del DB master viene cosi' trasferito in /data/snapshots/master/ (e rinominato, nel caso in esame, Full_20051215).

TEST RELEASE E CREAZIONE DI UNA FEDERAZIONE

A) ATTIVAZIONE PRELIMINARE DEI SERVIZI DI OBJECTIVITY

Bisogna assicurarsi che siano attivi i 3 servizi di Objectivity (lockserver,AMS,PUD).
In relazione alla creazione della federazione e' in realta' strettamente necessario:
1) l'AMS server deve girare su qualsiasi macchina ospiti o debba ospitare una federazione;
2) il demone PUD deve girare su ogni macchina in cui c'e' una federazione ma anche sulla macchina dove si opera lo scaricamento dello snaphot.

Per la loro attivazione (prima PUD poi AMS !):
1) cd $BFROOT/RepTools/ams_slac, srtpath, ./StartAMS, ./StartAMS -s ooams-3a, ./StartAMS -s ooams -3b
2) cd $BFROOT/RepTools/PUD, srtpath , ./BdbAdminDaemon -start

B) PREPARAZIONE DELLA TEST RELEASE E DELLA CONFIGURAZIONE

In /home/bbrobjy/FedSetup si e' creata una test release 18.3.1c (la piu' recente disponibile):

srtpath 18.3.1c
newrel -t 18.3.1c cond18_srv01_a
con la convenzione che:
- '18' indica che e' per cond18boot,
- 'srv01' indica che e' ospitata sul server bbr-serv01,
- 'a' indica che e' la prima federazione fatta sulla stessa macchina (si usera' b,c,... per le successive).
Si noti che in questo caso si ha gia' a disposizione una federazione cond_18 sul server bbr-datamove06: /home/bbrobjy/FedSetup/COND18_04_a;
ad essa punta cond18boot attualmente.

Nella test release si copiano 4 files di configurazione
(p.es. da bbr-fe02 in /home/bbrobjy/FedSetup/PdFarmScripts/CreateFederation
oppure daIN /home/bbrobjy/FedSetup/CnafScripts/CreateFederation):

setup_con
bbobjy_con
Auth_CON.cmd (per la verita' inutile)
FileConfig_forCON.bfc

I file setup_con & Auth_CON.cmd restano cosi' come sono (il secondo in realta' e' addirittura inutile).

Il file bbobjy_con viene rinominato .bbobjy e opportunamente editato; nel nostro caso esso appare cosi':

FD_NUMBER=18311
LOCK_HOST=bbr-datamove05
AMS_HOST=bbr-serv01
JNL_HOST=bbr-serv01
FDB_DIR=/data/srv01/con/con18_a
JNL_DIR=/data/srv01/con/journal/con18_a
GLOBAL_DB_DIR = $(BFROOT)/Bdb/Production/global/export
FDB_LOCAL_NAME = "master-core"

Si noti che l'FD_NUMBER e' stato scelto cosi':
- "18" sta per cond18
- "31" sta per serv01 (si ricordi che per un datamoveXY con XY=1,...,21)
- "1" sta per 1 (prima federazione sul bbr-serv01)

L'indicazione degli host, p.es. quello del lockserver puo' essere sovrascritto (cambiato) col comando oochange.

Si noti anche che per congelare un CDB (p.es. quello a cui punta cond18boot) si cambia opportunamente il "local name".
P.es. da "master-core" a "analysis18-core" come spiegato qui

Attenzione: bisogna verificare che $BFROOT/Bdb/Production/global/export sia lo stesso: se ne controlla la checksum con:
ssh noric01.slac.stanford.edu
md5sum $BFROOT/Bdb/Production/global/export/global.bdb
Nel caso specifico si e' verificato che si tratta dello stesso file.
Tuttavia bisogna tener d'occhio, una tantum, gli annunci di Wilko (update pacchetto Bdb)

Si noti che in /data si avra' avuto cura di aver creato la directory srv01 nonche' le sottodirectory con/con18_a & con/journal/con18_a.
E' proprio in queste directory che viene creata la federazione!

A fine installazione si avra' infatti:
[bbrobjy@bbr-serv01 con18_a]$ ls -tlr
-rw-r--r-- 1 bbrobjy bbrepro 218 Dec 16 15:18 BaBar.BOOT
-rw-rw-r-- 1 bbrobjy bbrepro 1114112 Dec 16 15:19 global.bdb
-rw-rw-rw- 1 bbrobjy bbrepro 2015232 Dec 16 15:20 management.bdb
drwxrwsr-x 16 bbrobjy bbrepro 4096 Dec 16 15:37 configuration
drwxrwsr-x 14 bbrobjy bbrepro 4096 Dec 31 12:45 conditions
-rw-rw-rw- 1 bbrobjy bbrepro 4849664 Dec 31 14:11 BaBar.FDB
Dove:
[bbrobjy@bbr-serv01 conditions]$ ls -tlr
drwxrwsr-x 2 bbrobjy bbrepro 4096 Dec 31 11:02 anal-core
drwxrwsr-x 2 bbrobjy bbrepro 4096 Dec 31 11:02 analysis14-core
drwxrwsr-x 2 bbrobjy bbrepro 4096 Dec 31 11:03 analysis16-core
drwxrwsr-x 2 bbrobjy bbrepro 4096 Dec 31 11:04 simu-core
drwxrwsr-x 2 bbrobjy bbrepro 4096 Dec 31 11:04 simu6-core
drwxrwsr-x 2 bbrobjy bbrepro 4096 Dec 31 11:04 simu8-core
drwxrwsr-x 2 bbrobjy bbrepro 4096 Dec 31 12:44 master-core
drwxrwsr-x 3 bbrobjy bbrepro 4096 Dec 31 12:44 core
drwxrwsr-x 3 bbrobjy bbrepro 4096 Dec 31 12:44 opr-core
drwxrwsr-x 3 bbrobjy bbrepro 4096 Dec 31 12:45 repro-core
drwxrwsr-x 3 bbrobjy bbrepro 4096 Dec 31 12:45 repro2-core
drwxrwsr-x 3 bbrobjy bbrepro 4096 Dec 31 12:45 repro3-core
[bbrobjy@bbr-serv01 configuration]$ ls -tlr
drwxrwsr-x 3 bbrobjy bbrepro 4096 Dec 16 15:35 bdb
drwxrwsr-x 3 bbrobjy bbrepro 4096 Dec 16 15:35 dch
drwxrwsr-x 3 bbrobjy bbrepro 4096 Dec 16 15:35 dct
drwxrwsr-x 3 bbrobjy bbrepro 4096 Dec 16 15:36 drc
drwxrwsr-x 3 bbrobjy bbrepro 4096 Dec 16 15:36 emc
drwxrwsr-x 3 bbrobjy bbrepro 4096 Dec 16 15:36 emt
drwxrwsr-x 3 bbrobjy bbrepro 4096 Dec 16 15:36 fct
drwxrwsr-x 3 bbrobjy bbrepro 4096 Dec 16 15:36 glt
drwxrwsr-x 3 bbrobjy bbrepro 4096 Dec 16 15:36 ifr
drwxrwsr-x 3 bbrobjy bbrepro 4096 Dec 16 15:36 l3d
drwxrwsr-x 3 bbrobjy bbrepro 4096 Dec 16 15:36 orc
drwxrwsr-x 3 bbrobjy bbrepro 4096 Dec 16 15:37 svt
drwxrwsr-x 4 bbrobjy bbrepro 4096 Dec 16 15:37 top
drwxrwsr-x 3 bbrobjy bbrepro 4096 Dec 16 15:37 trg

FileConfig_forCON.bfc va invece editato nelle prime righe:
#: Declare the File Servers and File Systems
FileSystem: bbr-serv01 /data/srv01/con/con18_a 3333 200000 Metadata-S
FileSystem: bbr-serv01 /data/srv01/con/con18_a 3333 200000 NonEvent-S
FileSystem: bbr-serv01 /data/srv01/con/con18_a 3333 200000 NonEvent1-S
FileSystem: bbr-serv01 /data/srv01/con/con18_a 3333 200000 NonEvent2-S
FileSystem: bbr-serv01 /data/srv01/con/con18_a 3333 200000 NonEvent3-S
FileSystem: bbr-serv01 /data/srv01/con/con18_a 3333 200000 NonEvent4-S

C) CONFIGURAZIONE ED IMPORT DEL DATABASE

Si procede sempre come utente bbrobjy e nella directory ~/FedSetup/cond18_srv01_a

Prima di tutto bisogna settare OO_FD_BOOT con setboot:
[bbrobjy@bbr-serv01 cond18_srv01_a]$ setboot
set OO_FD_BOOT as /data/srv01/con/con18_a/BaBar.BOOT

(mentre ovviamente non bisogna fare cond18boot che avrebbe l'effetto di settare OO_FD_BOOT a bbr-datamove04::/kanga/d1/dm04/con18_a/BaBar.BOOT)

Nel caso in cui si stia creando una federazione su una macchina diversa da quella dove risiede lo snapshot, bisogna fare in modo che
la prima macchina veda localmente la directory dello snapshot: o si fa un rsync dello snapshot oppure si monta un'area NFS con lo snapshot.

Si comincia controllando l'output del comando (innocuo)
gmake database.config

A questo punto si eseguono uno alla volta le linee di comando elencate in setup_con fino al comando di BdbDmnImport escluso:

gmake database.import BYPASS_LOAD=yes MINSPACE=0
... e se ne controlla l'effetto con oodumpcatalog;

gmake database.load BYPASS_CONDITIONS_LOAD=yes BYPASS_CONFIG_LOAD=y
... e se ne controlla l'effetto con oodumpcatalog;
Si verifichi che sia disponibile sul server la versione di root in $BFROOT/package/root a cui punta la test release in uso.

BdbFileConfigLoader -prod -f FileConfig_forCON.bfc
ecco che qui si usa il file di configurazione opportunamente editato in precedenza.

BdbDmnImport -verbose -scp -replace /data/snapshots/master/Full_20051215/Configuration.tdf
...che dura alcuni minuti e produce un logfile che rinominiamo opportunamente:
mv Configuration.log Configuration.log-16dec05

BdbDmnImport -verbose -scp -replace /data/snapshots/master/Full_20051215/Conditions.tdf
...che dura alcune ore e produce un logfile che rinominiamo opportunamente:
mv Conditions.log Conditions.log-31dec05

A schermo compare alla fine:

[...]
> BdbDistribution attach /data/srv01/con/con18_a/conditions/repro-core/legacy/trk/trk000600-000700/con_trk_trk00065E.bdb 1630 -host bbr-serv01
Attaching con_trk_trk00065E ...
> ooattachdb -notitle -quiet -db con_trk_trk00065E -id 1630 -filepath /data/srv01/con/con18_a/conditions/repro-core/legacy/trk/trk000600-000700/con_trk_trk00065E.bdb -host bbr-serv01 /data/srv01/con/con18_a/BaBar.BOOT 2> /tmp/con_trk_trk00065E-11032.err
Import Conditions completed at 31-Dec-2005 14:11:16

Per una qualche nostra diagnostica, quello che si puo' controllare e' che NON vi sia un file .err alla fine della procedura.

Perche' abbiamo usato il -replace pur trattandosi di uno snaphost full?
Tale opzione e' innocua se non c'e' nulla da rimpiazzare: e' ovviamente essenziale se si carica uno snapshot incrementale.

D) NOTA IN CASO DI SNAPSHOT INCREMENTALE

In quest'ultimo caso, cioe' nel caso del caricamento dello snapshot incrementale se l'opzione -replace non dovesse funzionare
bisogna prima cancellare i DBID che si vogliono rimpiazzare una volta marcati "read-write"; cio' e' possibile con i comandi:
cat /data/snapshots/[snapshot-incrementale]/*.tdf | grep ^DATAB | awk -F DBID '{print $2}' | awk '{print $1}' | xargs -i oochangedb -quiet -id {} -readwrite
cat /data/snapshots/[snapshot-incrementale]/*.tdf | grep ^DATAB | awk -F DBID '{print $2}' | awk '{print $1}' | xargs -i oodeletedb -catalogonly -force -id {}
Nota Bene: e' del tutto normale vedere qualche messaggio di "errore" in corrispondenza a file nuovi.

Per capire meglio cosa fa questo comando: questa e' l'ultima riga in un file .tdf che contiene la parola DATABASE:
DATABASE cfg_trg_trg000000 DBID 47 FILE cfg_trg_trg000000.bdb DIR /objy/databases/production/master/configuration/trg/trg004000-004100 ROOT ecc. ecc.
Il primo comando di AWK taglia ogni riga con DATAB(ASE) e la riproduce a partire da dopo DBID quindi:
47 FILE cfg_trg_trg000000.bdb DIR ecc.. ecc..
Il secondo AWK stampa semplicemente il primo campo della riga tagliata, cioe' proprio "47"!

L'execute utility "xargs" passa i numeri della lista appena costruita al comando "oodeletedb" ("-i" implica tutti, uno alla volta), nell'argomento {} dell'opzione "-id" del comando stesso!

Il comando "oodeletedb" cancella un database da una federazione;
- l'opzione "-catalogonly" si riferisce alla cancellazione dal solo global catalog (senza cancellazione del database file)
- l'opzione "-force" permette di saltare la richiesta di conferma per l'esecuzione;
- l'opzione "-id" dichiara per quale DBID debba avvenire la cancellazione.

Fatto questa operazione, vanno ripetuti i 2 comandi di BdbDmnImport!

Infine vanno marcati "readonly" i database rimpiazzati:
cat /data/snapshots/[snapshot-incrementale]/*.tdf | grep ^DATAB | awk -F DBID '{print $2}' | awk '{print $1}' | xargs -i oochangedb -quiet -id {} -readonly

Concretamente:

Si importa lo snapshot incrementale lanciando lo script transfer:
/data/snapshots/transfer /nfs/objyserv03/objy/databases/snapshot2/master/analysis/current /data/snapshots/master/analysis-20060109/
dove il primo path passato come parametro individua il path a SLAC ed il secondo individua la directory local dove si vuole trasferirlo.

Come bbrobjy in /home/bbrobjy/FedSetup/cond18_srv01_a si fa "srtpath"
e si setta:
setenv OO_FD_BOOT /data/srv01/con/con18_a/BaBar.BOOT
Si verifica che i demoni PUD e AMS sono running:
con "ps -Hu bbrobjy" si controlla che fra i processi attivi vi sia almeno un "perl" ed un "ooams".

Here is a brief description of the path analogy between the 2 servers hosting the CDB for cond18boot:

Paths on 2 different servers
bbr-serv01 bbr-datamove04
/data /kanga/d2/
/data/srv01 /kanga/d2/dm04

Anche a SLAC hanno a disposizione un paio di federazioni per ciascun condXXboot, una running una di rincalzo.
Ogni federazione e' sparsa su 3 servers (nel catalogo ogni pezzo ha il suo path specificato);
ed su ogni server girano 4 demoni AMS.
I journals vivono su server appositi ed il server ed il path e' specificato nel BOOT file
tuttavia questo era utile una volta quanto gli utenti usavano di piu' scrivere nei database
mentre oggi il journal server non e' importante.

molto piu' importante e' il lockserver; ogni condXXboot ha il suo lockserver.
Anche al CNAF bisogna fare cosi'.
L'overload (CPU load) al lockserver si verifica ogni tanto a SLAC; un lockserver con hyperthreading potrebbe aiutare ad evitare la saturazione del carico sulla singola CPU
Quindi il lockserver dovrebbe avere un hardware di buona qualita'.

Invece a Slac non usano, almeno per ora, avere piu' lockserver per ciascun condXXboot.
Al CNAF dato il carico potrebbe bastare avere un lockserver per ogni condXXboot.
Sarebbe anche interessante pero' monitorare il carico su(i) lockserver per capire esattamente se si ha un collo di bottiglia.

A SLAC Wilko ha implementato un sistema che per updatare il condDB senza dover fare un apposito outage.
La logica e' la seguente:
STEP-0) scripting di trasferimento sul server ospitante il condDB (con eventuale automatismo di download da SLAC)
STEP-1)scripting di lock della federazione
STEP-2) si aspetta che si esauriscano tutte le transizioni attive sulla federazione per eseguire lo scripting che sostituisce i file .tdf vecchi con quelli nuovi;
quest'ultima operazione dovrebbe durare pochi minuti poiche' non si usa "BdbDmnImport -replace" bensi' un banale "mv".

Lo script che fa il caricamento dello snapshot

BdbDmnImport -verbose -scp -replace /data/snapshots/master/analysis-20060109/Configuration.tdf

$BFROOT/local/bin/file.csh

Come root in /soft/bfroot/dist/releases/analysis-30:
[root@bbr-mngserv analysis-30]# cd database/export

[root@bbr-mngserv export]# cp schema.dmp /home/bbrobjy/schema-ana30.dmp

[root@bbr-mngserv export]#chown bbrobjy:bbrepro /home/bbrobjy/schema-ana30.dmp

[bbrobjy@bbr-mngserv.cr.cnaf.infn.it ~]scp schema-ana30.dmp bbrobjy@bbr-datamove04:/home/bbrobjy/schema-ana30.dmp

[bbrobjy@bbr-datamove04 ~]$ srtpath 18.0.4
[bbrobjy@bbr-datamove04 ~]$ ooschemaupgrade -infile schema-ana30.dmp /kanga/d1/dm04/con18_a/BaBar.BOOT
Objectivity/DB (TM) Schema Upgrade Utility, Version 8.0.9
[...]
Schema loaded from file "schema-ana30.dmp" to Federated Database "/kanga/d1/dm04/con18_a/BaBar.BOOT".

Back to main page.

Last update: 4-Jan-2006