INFNGrid Constanza Project: Status Report A.Domenici, F.Donno, L.Iannone, G.Pucciani, H.Stockinger

CNAF, 6 December 2004

WP3-WP5 FIRB meeting

Constanza: outline of the project status (1)

● 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 (2)

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

RCS: use cases

● Check lfn/ldb consistency

● List/check replica status

● Register/unregister files/DBs

● Update files

● Update DBs

● Manage RCS settings

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.

RCS: main scenario for DB update● 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 Architecture● 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 for DB Synchronization

● 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: Oracle to MySQL bridge using streams based log extraction

● 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 Architecture for File Synchronization

● 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: current implementation

● 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: how it works, till now (1)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 LDatasets;+------+------+--------+---------+--------+------------+| LId | type | GRCSid | version | master | status |+------+------+--------+---------+--------+------------+| lfn1 | flat | 1 | 0 | NULL | up-to-date || lfn2 | flat | 1 | 0 | NULL | up-to-date |+------+------+--------+---------+--------+------------+

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 |+---------+------+--------+---------+------------+

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:

1. The GRCS server on pcgridtest2:8080

2. The LRCS1 server onpcgridtest2:8081

3. The LRCS2 server on pcgrdtest2:8082

4. 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.

5. 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

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]$ ./grcsserver -h pcgridtest2 -p 8080[....]10: connection from 212.189.152.148:4GRCS: received blocking update request for: LId = lfn1 source file = src1 Version of the source file is: 0 Version of the lfn is: 0GRCS: checkVersion: ok. current quorum is: 2GRCS: checkQuorum: ok.GRCS: in upd_routine_synchGRCS: LRCSs found: pcgridtest2:8081 pcgridtest2:8082GRCS: try to lock all replicas locking replica src11GRCS: replica src11 locked locking replica src12GRCS: replica src12 lockedGRCS: update all replicasGRCS: replica src11 updatedGRCS: replica src12 updatedGRCS: unlock all replicasGRCS: replica src11 unlockedGRCS: replica src12 unlockedupd_routine_synch is about to terminate correctly(UpdOp joined Update routine)GRCS: update operation terminates correctlyrequest 10 served

[gianni@pcgridtest2 server]$ ./lrcsserver -h pcgridtest2 -p 8081My endpoint: http:/pcgridtest2:8081Master socket = 30: connection from 212.189.152.148:4LRCS::prepUpdReplica: lfn = lfn1 repl = src11LRCS: replica src11 lockedrequest 0 served1: connection from 212.189.152.148:4LRCS::updateReplica: lfn = lfn1 org = src11 newv = src1request 1 served2: connection from 212.189.152.148:4LRCS::clearPreparation: lfn = lfn1 repl = src11request 2 served