INFNGrid Constanza Project: Status Report

1. INFNGrid Constanza Project: Status Report A.Domenici, F.Donno, L.Iannone, G.Pucciani, H.Stockinger WP3-WP5 FIRB meeting CNAF, 6 December 2004

2. Constanza: deployment of a RCS for files and databases. A requirements document has been drafted with requirements list, use cases and basic scenarios (under constanza/docs/requirements of the INFNForge cvs site). A design document is used to keep track of the design work flow, including details on the architecture and interaction diagrams (constanza/docs/design). A basic architecture has been already implemented, assuming a simple environment. Some features still need to be added. Constanza: outline of the project status (1)

3. An important review of the requirements and the designed architecture has been recently done to fit the needs of the LCG 3D CERN project (http://lcg3d.cern.ch/) where we work as part of the Technology Evaluation Tasks Working Group. Main focus on heterogeneus DB update Constanza: outline of the project status (2)

4. Check lfn/ldb consistency List/check replica status Register/unregister files/DBs Update files Update DBs Manage RCS settings RCS: use cases

5. RCS: main scenario for files update • Users get replicas and work on them independently: conflicts may arise. RCS discovers them and the first update request arrived is satisfied. • Replicas are updated according to two protocols: synch (with quorum selection) or asynch single-master. • “Current” update-mechanism: simple file replacement.

6. As stated in the LCG-3D project proposal (http://lcg3d.cern.ch/talks/3D-proposal.ppt) two levels of replicas exist. Initially, updates can only be done at the master level. The RCS is responsible for a reliable propagation of logs to the secondary replicas. Update of the master replica and actual application of the log to the secondary replicas is not a concern of the RCS. RCS: main scenario for DB update

7. GRCS: main component and interface to the end-user. LRCSs: communicate with the GRCS and with each other to implement the Update Protocol. RCC: a strictly consistent catalog to store metadata about replicas and general RCS status information. External Components: the general interface towards replicas has different meanings for Files and DBs update. RCS Architecture

8. LogGenerator: provide logs containing update information coming from the Master level. DBUpdater: provide a mechanism to apply logs to the secondary replicas. Note: this two components are out of the scope of the RCS. They provide services to the RCS and are strictly tied with the technology used for the DBs. RCS Architecture for DB Synchronization

9. Application of Oracle streams to MySQL is the first goal to test the beahviour of our RCS for heterogeneus DB synchronization although a first test could be done with a homogeneus technology. A study of the Streams features of Oracle and the compatibility issues beetwen Oracle and MySQL sql dialects as regards the LFC database schema and its application to the RCS is the subject of Laura's thesis. RCS: Oracle to MySQL bridge using streams based log extraction

10. Local Lock Server: it should provide a way to lock/unlock physical replicas, avoiding external access that might be dangerous for consistency. RMS: we'll start without RMS integration although requirements have been placed on a future RMS that could provide consistency features. RCS Architecture for File Synchronization

11. Currently a simple architecture for the file based scenario exists. Migration towards DB synchronization is in place and is our main concern as a mid term goal. The two architectures just seen are similar, so both File and DB update features can be provided by the RCS. Independent servers for GRCS and LRCSs have been implemented using gSOAP for communication features and C++ for core implementation. RCC is still a GRCS local singleton class that acts as an interface to the MySQL backend but it will work with its own independent server soon. Features like GSI security and multithreaded servers for each component are planned to be added as soon as the simple architecture is nearly completed and a prototype is running. RCS: current implementation

12. RCS: how it works, till now (1) mysql> select * from LDatasets; +------+------+--------+---------+--------+------------+ | LId | type | GRCSid | version | master | status | +------+------+--------+---------+--------+------------+ | lfn1 | flat | 1 | 0 | NULL | up-to-date | | lfn2 | flat | 1 | 0 | NULL | up-to-date | +------+------+--------+---------+--------+------------+ The test environment: mysql> select * from GRCSs; +--------+-------+-----------------------------+--------+ | GRCSid | name | address | status | +--------+-------+-----------------------------+--------+ | 1 | GRCS1 | pcgridtest2.pi.infn.it:8080 | up | | 2 | GRCS2 | pcgridtest3.pi.infn.it:8080 | down | +--------+-------+-----------------------------+--------+ mysql> select * from LRCSs; +--------+-------+-----------------------------+--------+ | LRmysql> select * from LRCSs; +--------+------+------------------+--------+ | LRCSid | name | address | status | +--------+------+------------------+--------+ | 1 | LRCS | pcgridtest2:8081 | up | | 2 | LRCS | pcgridtest2:8082 | up | +--------+------+------------------+--------+ mysql> select * from Replicas; +---------+------+--------+---------+------------+ | fileURL | LId | LRCSid | subtype | status | +---------+------+--------+---------+------------+ | src11 | lfn1 | 1 | | up-to-date | | src12 | lfn1 | 2 | | up-to-date | | src21 | lfn2 | 1 | | up-to-date | | src22 | lfn2 | 2 | | up-to-date | +---------+------+--------+---------+------------+

13. RCS: how it works, till now (2) First of all we have to create tables for the RCC and load data into the GRCSs table. As a simple demonstration we start: • The GRCS server on pcgridtest2:8080 • The LRCS1 server on pcgridtest2:8081 • The LRCS2 server on pcgrdtest2:8082 • Then we use the client CLI to register 2 LRCSs, 2 logical files and 2 replicas for each logical file and get/set the quorum. • Now we can use the same CLI to update (synch protocol blocking mode) a logical file with a modified replica. Note: updates are simulated, no file transfers at all

14. [gianni@pcgridtest2 server]$ ./grcsserver -h pcgridtest2 -p 8080 [....] 10: connection from 212.189.152.148:4 GRCS: received blocking update request for: LId = lfn1 source file = src1 Version of the source file is: 0 Version of the lfn is: 0 GRCS: checkVersion: ok. current quorum is: 2 GRCS: checkQuorum: ok. GRCS: in upd_routine_synch GRCS: LRCSs found: pcgridtest2:8081 pcgridtest2:8082 GRCS: try to lock all replicas locking replica src11 GRCS: replica src11 locked locking replica src12 GRCS: replica src12 locked GRCS: update all replicas GRCS: replica src11 updated GRCS: replica src12 updated GRCS: unlock all replicas GRCS: replica src11 unlocked GRCS: replica src12 unlocked upd_routine_synch is about to terminate correctly (UpdOp joined Update routine) GRCS: update operation terminates correctly request 10 served RCS: how it works, till now (3) [gianni@pcgridtest2 script]$ ./update.sh remote endpoint: http://pcgridtest2:8080 updated lfn lfn1 with src src1 in blocking mode update result = Ok [gianni@pcgridtest2 server]$ ./lrcsserver -h pcgridtest2 -p 8081 My endpoint: http:/pcgridtest2:8081 Master socket = 3 0: connection from 212.189.152.148:4 LRCS::prepUpdReplica: lfn = lfn1 repl = src11 LRCS: replica src11 locked request 0 served 1: connection from 212.189.152.148:4 LRCS::updateReplica: lfn = lfn1 org = src11 newv = src1 request 1 served 2: connection from 212.189.152.148:4 LRCS::clearPreparation: lfn = lfn1 repl = src11 request 2 served