http://lcg.web.cern.ch/LCG/

Grid Deployment

Enabling Grids for E-sciencE

BDII

2171LDAP

2172LDAP

2173LDAP

2170Port Fwd

Update DB&

Modify DB

2170Port Fwd

Swap DBs

Log File

Producer API

ProducerServlet

GridF

TP

Server

ConsumerServlet

RegistryServlet

Consumer APIGridF

TP

Client

MySQLDB

Grid FTP

R-GMA

The Evolution of the Production Information and The Evolution of the Production Information and Monitoring SystemMonitoring System

GIPProvider

Config File

LDIF File

Plugin

Cache

Improved BDII ArchitectureImproved BDII Architecture

At the time of CHEP 2004, the size of the production system was approximately 30 sites. Currently the production system comprises of nearly 200 sites. Not only is this a 10 fold increase in the number of sites but it is also a 10 fold increase of the amount of data in the information system, from 1Mb to 10Mb. This, as well as more queries, added stress to the BDII[1], which required a few architectural changes to keep pace with the expanding Grid. A port forwarding process was introduced to improve the stability of the BDII during the DB swap process. A third DB was introduced to give an increased period for queries to end before the connection is cut. A facility to modify the DB after the update but before the swap process was added so that the data could be filtered or modified before it is used. This facility enabled the development of the Freedom of Choice for Resources Portal.

Freedom of Choice for Resources PortalFreedom of Choice for Resources Portal

Building upon the new BDII architecture, the FCR Portal[2] was developed to meet a requirement from the VOs. The VO needed to modify the information to their liking, in particular to white list and black list services. The FCR Portal shows the VO manger a view of all the services that the VO is authorised to use. The VO manger can white list and black list the services. This generates an LDIF modify file for the GlueCEAccessControlBaseRule attribute. The BDII can download this file from the portal and use it to modify the DB after it has been populated. The FCR Portal has also been linked with the Site Functional Tests Portal[3] which enables the VO to automatically remove a site if it fails a functional test that is important for the VO.

Generic Information ProviderGeneric Information Provider

The GIPs[1] architecture has been improved and it is now easier to configure. It is now possible to use a script that provides ldif with the GIP. Services can now dynamically provide information about themselves by placing an LDIF file in the GIPs LDIF directory or by placing wrapper scripts in the plugin or providers directory.

Introduction of R-GMAIntroduction of R-GMA

R-GMA[4] has always been available on the production system but until recently never used on a large scale. Before R-GMA could be used, sites needed to ensure that it was properly installed and configured. The SFTs played an important role in ensuring that this happened. A test was developed to ensure that R-GMA was working at the site and the results were displayed on the SFT Portal. After raising awareness of this issue with the sites, the number of sites successfully installing R-GMA increased dramatically.

Initial Application Using R-GMAInitial Application Using R-GMA

The first production use of R-GMA was to monitor data transfer rates from CERN to the Tier 1 centers during Service Challenge 3. The GridFTP R-GMA publisher runs on each GridFTP server and publishes log file entries into R-GMA. The publisher script consists of a daemon process that monitors the log file, reads new entries, parses it and inserts into R-GMA. The parser was developed as a plugin so that that other log files could be monitored with the minimum of development effort. GridView[5], a monitoring and visualization tool, archives R-GMA tuples to a central Oracle database and generates periodic summaries. These summaries are displayed graphically to show, for example, average throughput and aggregate data movement across the sites.

Screen Shot of the Grid View Page

Verification of R-GMAVerification of R-GMA

A testing framework was setup to verify the reliability of R-GMA. The GridFTP log file from the publishing nodes were copied the testing machine. These log files were parsed and the data inserted into a table in a database. An R-GMA Secondary Producer was setup to insert the data found in R-GMA to the same database but a different table. A comparison script periodically compares the two table and an email notification is sent containing the results. The verification test highlighted problems with R-GMA which were investigated and fixed. During the time that this verification test was used, there has been a significant improvement in the reliability of R-GMA.

[1] http://lfield.home.cern.ch/lfield/

[2] https://goc.grid-support.ac.uk/gridsite/bdii/site-apps/FCR-cgi/fcr.cgi

[3] http://lcg-sft.cern.ch:8083/sft/lastreport.cgi

[4] http://hepunx.rl.ac.uk/egee/jra1-uk/

[5] http://gridview.cern.ch/GRIDVIEW/

References:References: