1. Foreword *

2. Project Overview *

3. Workplan *

4. Costs evaluation *

5. Management and Organization *

6. Summary *

7. References *

8. APPENDIX A: Experiments’ Computing Documents *

9. APPENDIX B: Financial requests for 2000 and 2001 *

10. APPENDIX C: Personnel *

2. Foreword

High Energy Physics Experiments have always requested state of the art computing facilities to efficiently perform the analysis of large data samples and some of the ideas born inside the community to enhance the user friendliness of all the steps in the computing chain have been successful also in other contexts: one striking example is the World Wide Web.

The previous generation of experiments for the electron positron collider, LEP, has proven the effectiveness of the computing farms based on commodity components in providing low cost solutions to the LEP experiments needs and farms of this type are now very popular and distributed in most INFN sites and world-wide.

Recently in the US the concept of Grid computing has been proposed as a new advance to build on top of internet and the WEB. The Grid make profit of the increasingly high bandwidth which connect the various computing resources of the scientific communities to make them transparently available to the users. This is achieved by a new software infrastructure, the Grid middleware, that once developed will provide standard tools to run applications and to manage and access very large data sets distributed in remote nodes.

1. The Grid concept

The Grid idea is well described in an already famous book: "The Grid: Blueprint for a New Computing Infrastructure" Edited by I. Foster and C. Kesselman, Morgan Kaufmann, 1999

(ISBN 1-55860-475-8).

Several US Grid related Projects where started in these last two years, the most relevant ones for this proposal are:

Globus^[1]

The Globus project is developing basic software services for computations that integrate geographically distributed computational and information resources. Globus concepts are being tested on a global scale on the GUSTO testbed.

Condor^[2]

The goal of the Condor project is to develop, implement, deploy, and evaluate mechanisms and policies that support High Throughput Computing (HTC) on large collections of separately owned and distributed computing resources.

The Particle Physics Data Grid^[3]

It "has two long-term objectives. Firstly the delivery of an infrastructure for very widely distributed analysis of particle physics data at multi-petabyte scales by hundreds to thousands of physicists and secondly the acceleration of the development of network and middleware infrastructure aimed broadly at data-intensive collaborative science".

The GriPhyn project^[4]

The GriPhyN (Grid Physics Network) collaboration proposes an ambitious program of computer science and application science research designed to enable the creation of Petascale Data Grids, systems designed to support the collaborative analysis, by large communities, of Petabyte-scale scientific data collections.

NASA's Information Power Grid^[5]

NASA's Information Power Grid (IPG) is a testbed that provides access to a Grid; a widely distributed network of high performance computers, stored data, instruments, and collaboration environments. The IPG is one component of an effort by the university, commercial, and government computer science communities to define, develop and build Grids that will enable routine use of widely distributed resources for the diverse purposes of research and education, engineering, design, and development.

 

2. Objectives of the INFN-Grid project

The objectives of the INFN-Grid project are to develop and deploy for INFN a prototype computational and data Grid capable to efficiently manage and provide effective usage of the large commodity components-based clusters and supercomputers distributed in the INFN nodes of the Italian research network GARR-B.

These geographically distributed resources, so far normally used by a single site, will be integrated using the Grid technology to form a coherent high throughput computing facility transparently accessible to all INFN users.

The INFN national Grid will be integrated with European and worldwide similar infrastructures being established by ongoing parallel activities in all major European countries, in US and Japan.

The scale of the computational, storage and networking capacity of the prototype INFN-Grid will be determined by the needs of the LHC experiments. These include the experimental activities for physics, trigger and detector studies and the run of applications at a sufficient scale to test the scalability of the possible computing solutions to very large amount of distributed data (PetaBytes), very large amount of CPU’s (thousands) and very large number of users.

The development of the new components of Grid technology will be done by the INFN-Grid project, whenever possible, in collaboration with international partners through specific European or international projects. A proposal for the first of such kind of projects, DATAGRID,^[6] has been submitted the 8^th of May for the European Union IST program EU-RN2, asking for 10 M€ funding and has received a very positive evaluation by referees.

The 20^th of July the European Union IST direction has formally invited the project to negotiate the final contract along the lines indicated in the proposal : 3 years development plan and ~ 10M€ funding.

The MONARC^[7] Phase-3 project current activities are another important component of the INFN-Grid project, as they will provide guidance for the developments of the computing models of the LHC experiments. The INFN-Grid will investigate the current ideas for the computing models, based on the MONARC proposed hierarchical architecture of Tier1-TierN Regional Centers. The investigation will be performed using real applications on real Center prototypes, fulfilling at the same time the real computing needs of the experiments.

The project will encourage the diffusion of the Grid technologies in other Italian scientific research sectors (ESA/ESRIN, CNR, Universities), addressing the following points:

• develop collaborations with those Italian scientific partners to address problems which are common to the research sectors;
• promote the integration of the research computing resources into one national research Grid.

1. Project Overview

The INFN-Grid Project is the framework for efficiently connecting:

• The developments of the middleware performed by participants to the DATAGrid European project.
• The extra developments needed for INFN specific purposes
• The setting up of the prototypes of the Italian part of the distributed computing system for the 4 LHC experiments Alice, Atlas , Cms, Lhc-b and Virgo. The most relevant components of this system are the prototypes of the Regional Centers for the 4 LHC experiments and Virgo.
• The step by step testing of the middleware with the "real-life" application of the experiments, which is needed in order to make sure that the middleware will truly respond to the practical requirements of the experiments. The only possible testbeds for such testing activities are the prototypes mentioned above. An extension of the middleware tests will be provided by APE.
• further extensions of the middleware tests provided by currently running or ready to run experiments such as Compass and Argo.

In the following chapters a detailed description of the work plan and needed resources will be given. Whenever necessary a clear distinction will be done between INFN and European Grid project, in order to make clear budget and resources separation.

1. The LHC Collaborations and Grid project

The LHC collaborations have stated they strongly support the Grid project. They recognize that the functionality promised by the Grid middleware are needed for deploying the efficient system of distributed computing that they are planning for and which is assumed in their Computing Technical Proposals.

There is a general consensus, of LHC experiments, on the advantages of a common project where the prototyping of each experiment computing architecture is discussed within a common framework. This concept has been expressed at the Computing Model Panel of the LHC Computing Review. The Italian LHC groups share the same opinion.

Common projects are also addressed by the MONARC collaboration (Phase III), discussing possible computing scenarios and aiming at providing detailed simulation of regional centres architectures.

There is also general consensus that all the members of the collaboration will be allowed to use the Grid tools for running the applications of the experiments, irrespective if their country is participating to DATAGrid or not. Of course all the Italian members of LHC collaborations will be granted full access to the Grid tools, Italian RC prototypes and local Grid infrastructure, regardless if they are subscribing or not to this INFN-Grid project.

 

2. Building the INFN-Grid in the context of an European and World-wide Grid

The term "Grid" refers to distributed, high performance/throughput computing and data handling infrastructure that incorporates geographically and organizationally dispersed, heterogeneous resources that are persistent and supported. A computing and data Grid is based on a set of services for obtaining information about Grid components, locating and scheduling resources, communicating, accessing code and data, measuring performance, authenticating users and resources, ensuring the privacy of communications, and so forth^[1][6]. The Grid services define the Grid architecture and the way the applications will use the Grid. How to proceed in building the Grid? What is involved?

The Grid users can be classified in the following way:

Class	purpose	Make use of	concerns
End user	Solve problems	Applications	Transparency, performance
Application developers	Develop applications	Programming models and tools	Ease of use, performance
Tools developers	Develop tools Programming models	Grid services	Adaptivity, exposure of performance, security
Grid developers	Provide basic Grid services	Local system services	Local simplicity, connectivity, security
System administration	Manage Grid resources	Management tools	Balancing local and global concerns

To address the above questions we have to consider the computing requirements of the new experiments , the existing applications willing to run on the Grid, the scalability in terms of resources, data and users and network connectivity and services. The focus of HEP Grid is on the huge quantity of data and the large number of users geographically distributed. Computational infrastructure, like other infrastructure, is fractal or self-similar at different scales but what is good at local scale is probably not appropriate at wide area level. Therefore scale is one of the major drivers for the technique used to implement HEP Grid services.

We also have to consider that the application developers will choose programming models based on a wide spectrum of programming paradigm: Java, CORBA, Grid-enabled model and others possibly available in the future. All these applications will have to interface the Grid services in different ways.

There is much discussion on what programming model is appropriate for a Grid environment, although it is clear that many models will be used. One approach to define services and programming models is to start from HEP use-cases, analyze them in terms of computing needs, data and network access, and identify Grid services and tools and design the appropriate testbed to test prototypes.

3. Grid architecture

The models proposed so far for Grid structure, integrating resources (computing, data, network, instruments..), services and applications are based on network schema, aiming to be as simple as possible, supporting broad deployment and focused on application performance.

Due to the strong requirement of the INFN-Grid to be finalized to the LHC and other new experiment (Virgo, ….) computing prototyping, we first make some general observations regarding goals and principles:

• Support HEP applications (high throughput)
• Enable sharing at multiple levels in the infrastructure avoiding redundancy, promote interoperation, and maximize opportunities of reuse.
• Address the specific requirements of high throughput applications but also those of high performance applications wherever necessary, either via the provision of alternative services and interfaces or via the definition of translucent interfaces that allow specialized control of a single service.
• Leverage and contribute to standard wherever possible, i.e. use standards when they exist.

The components of the Grid architecture can be represented in Table 2.1.

Grid Fabric includes resources-specific and site-specific mechanism which enable or facilitate the creation of higher-level distributed Grid services. They might include:

Grid Common Services or middleware provide resource-independent and application-independent functionality. They might include Information Service, Authentication, Authorization, resource location and allocation …….WP1 of this project titled "Evaluation of Globus Toolkit" will cover this Grid component.

Application-oriented Grid Services or toolkit provide more specialized services and components for various application classes. Almost all these services are included in the EU-Project:

• WP2.1 includes most of them: High Throughput Broker, Real time and scheduled workload management, co-reservation and co-allocation of multiple resources….
• WP2.2 Data Management data access and data mover.
• WP2.3 Grid Monitoring Services covers all the monitoring issue.

Applications: as already said HEP application will be implemented following different programming models; some of them already exist , other have defined specific data models and will be based on specific databases (ROOT or Objectivity…). Programming models could be based on Java, CORBA or other commercial technologies. Finally specific Grid aware applications will be implemented in term of various application toolkit components, Grid services and Grid fabric mechanism.

That said, from the analysis of the use cases different classes of applications could emerge: traditional applications, client/server batch applications, client/server interactive applications and finally Grid-enabled applications. For all these applications suitable Grid services are to be identified in order to run efficiently on the Grid. The present proposal should put special emphasis on this issue through the analysis of use cases in order to model Grid services on the requirements of different types of applications, in order to complement what is done within the DataGrid project.

1. Grid services exploitation

Since one of the most important goal of the project is to develop prototypes for applications and computing models (regional centers) of LHC and other new experiments, Grid services and Grid programming models will be investigated starting from experiment’s use cases. This approach has also the objective to exploit the development of the project to offer efficient and transparent access to distributed data and computing facilities to the large and geographically distributed physics community.

The work should flow through the following steps:

• Experiments identify the use-cases.
• Use cases are analyzed to define specifications of the Grid services.
• Prototype development will be scheduled on WP’s deliverables
• Grid services will be validated through use-case application-prototypes experimented on the most realistic Grid testbed.

Technical work must be organized between application-users, application-developers and Grid services developers.

Each or few use cases must have an application’s user that is responsible of the application-prototypes and the validation process has to be carry out by a specified group consisting of one application-developer and one developer of each Grid-service involved.

WP Testbed will take care of the coordination of the prototype and Grid services test phase.

1. INFN-Grid additions to the tools and services developed in DataGrid

The INFN-Grid project will be planned in order to fully integrate services and tools developed in DATAGrid in order to meet the requirements of INFN Experiments and to harmonize its activities with them. In addition to that INFN-Grid will develop specific workplans concerning:

• Validating and adapting Grid basic services (like the ones provided by GLOBUS) on top of which specific application oriented services (middleware) will be developed.
• Addressing INFN computing needs, not included in DATAGrid, some of them synchronized with experiment computing schedule. This will bring to develop intermediate releases of Grid services optimizing the specific application computing.
• National testbed deployment characterized by the INFN collaborations requirements mostly in terms of computing, data and network capacity, and computing model. The national testbed will interconnect the other national testbeds through the European Grid providing altogether the necessary size (data, computing, network and users) to test and validate middleware, application prototyping and the development of LHC experiment computing models.

Testbed activities will include the workload management for individual analysis tasks, the data management in the distributed Italian scenario, the monitoring of the INFN resources, the standardization of INFN Farms distributed in different INFN sites and mass storage tests suited for the INFN site distributed activities. The network layout is foreseen to be provided by GARR in collaboration with the present project.

1. The role of INFN-Grid in the INFN Computing

The INFN-Grid project will provide the middleware and the testbeds for running the physics applications of the large experiments which foresee the distributed analysis of huge amounts of data: not only LHC experiments, but also VIRGO and APE fall in this category and are fully participating to the project. Of course all the INFN experiments that are in the conditions of taking benefit of this INFN-Grid project are welcome and will be encouraged in joining for the specific activities of their interest: ARGO and COMPASS have already expressed their interest.

The project will also be beneficial for the other INFN computing activities. In fact some of the most innovative techniques under evaluation for the Grid middleware were already considered by the INFN projects developed within the framework of Computing Committee (CC). Large synergies will be possible between INFN IT Services and Grid related activities: the internal developments will profit of state of the art technology evaluated and selected by large international collaborations that include top level computing scientists also in US and Japan.

Example of activities where large synergies are possible include:

• Study of solutions for Information Service systems. A Directory Service based on LDAP protocol is currently investigated by a CC project to provide fast access to information concerning INFN people, mail addresses, etc. and by GLOBUS to make publicly available the static and dynamic status of Grid node resources.
• CONDOR as a tool for distributed computing. CONDOR is already used in INFN for supporting distributed simulation activities and it is also a component of GLOBUS
• Networking: this is a domain where the expertise of CC and CNAF can be effectively confronted and enhanced in the common activities with other European partners to plan, integrate, run and monitor the HEP applications in the Grid European testbed.
• Security: the traditional expertise of the CC group can be used to enable an INFN certification authority to issue certificates that can be recognized worldwide by the Grid community.
• Farms standardization: the ongoing debate and experimentation in INFN will profit of the international forum and expertise since this is one of the major developments foresee in the European project.

1. The role of INFN-Grid for the Computing of LHC Experiments

The needs of the LHC experiments for computing infrastructures (h/w and s/w) in the years 2001-2003 will be almost fully requested in the framework of the INFN-Grid project. The successful development of the Grid tools will be verified step by step using the widest possible variety of physics applications of the experiments, which will be run in a production style, aiming both at producing the physics results the experiment want and at using as much as possible the available middleware. Thus in principle all the computing activities of the experiments will be connected to the Grid which will finally provide the infrastructure for the distributed running of all of them.

Only the developments of detector related s/w and of the algorithmic parts of the experiment s/w will stay separate from the Grid project. The development of CORE s/w will instead have many points of contact with the Grid developments.

Whence we propose all the computing h/w of the experiments except the one related to standard s/w development and to on-line on-site applications to be funded in the framework of the INFN-Grid project for the years 2001-2003. Some online activities will also be covered by INFN-Grid (typically remote monitoring).

The activities performed in the framework of the MONARC project for its Phase-3 are also naturally falling within INFN-Grid, given their character of common project of the LHC experiments aimed at the definition of the common aspects of their computing models. The MONARC simulation program could provide a valuable tool for complementing the prototypes in planning for the LHC Grid implementation.

The computing people of the LHC experiments involved in the INFN-Grid project are working at the Grid since the Grid is the instrument they are using for implementing the computing application of their experiments. Therefore their contribution to the INFN-Grid project is to be counted as fully contained within the fraction of their time devoted to their LHC experiment.

Only a fraction of the end-users and of the application developers (see 2.2) of the LHC experiments are members of this INFN-Grid project; this fraction works in INFN-Grid with the purpose of granting the Grid infrastructure is developed according to the needs of their experiment, of assuring the integration in Grid of the applications of the experiment and of contributing to the design of the LHC computing system.

2. LHC Regional Center Prototypes, activities foreseen for 2001-2003 and resources needed

The Computing Model that LHC Experiments are developing is based on MONARC studies, as well as on their own evaluations. The key elements of the architecture are based on an hierarchy of computing resources and functionalities (Tier0, Tier1, Tier2, etc.), on an hierarchy of data samples (RAW, ESD, AOD, TAG, DPD) and on an hierarchy of applications (reconstruction, re-processing, selection, analysis) both for real and simulated data.

The hierarchy of applications requires a policy of authorization, authentication and restriction based again on a hierarchy of entities like the "Collaboration", the "Analysis Groups" and the "final users".

The LHC Experiments Computing Design requires a distribution of the applications and of the data among the distributed resources. In this respect the correlation with Grid initiatives is clearly very strong. Grid-like applications are such applications that are run over the wide area network, i.e. include Regional Centres (Tier-n) using several computing and data resources with network links over the wide area network where each of the single computing resources can itself be a network of computers.

Within this framework the Computing Project is seen as a detector component, whose goal is to provide the efficient means for the analysis and potential physics discovery to all the LHC Physicists.

In the discussions, within the Computing Model Panel of the LHC Computing Review, all LHC Collaborations agreed that is mandatory to reach, by 2003, a prototyping scale of the order of 10% of the final size foreseen in operation by 2006. To reduce the prototype scale could be a serious risk for the system. The experience has clearly shown that scaling by an order of magnitude can raise up unexpected problems with the system incapable to fulfil its requirements. This would represent a disaster for the LHC Physics program.

All Italian LHC groups have therefore as target a prototype size, for 2003, about 10% of the 2006 one. At the same time each group has an activity program, for the next three years, which will involve considerable resources for simulation, reconstruction and analysis of the simulated data. The prototype will provide these resources.

The motivation for the testbed-planned capacities is therefore twofold:

• to perform a system test with real tasks in realistic size;
• to give an appropriate and cost effective answer to LHC computing needs in the next three years.

Moreover the simulation process, involving event generation, reconstruction and analysis will represent a very suitable environment to reproduce the system in its full operation activity.

In the following only a short description of Experiments’ activities and needs are given. Appendix A (Chap. 8) reports the detailed plans of the Experiments.

Based on the latest figures from ALICE simulation and reconstruction codes, it is estimated that the overall computing needs of ALICE are around 2100 KSPECint95 of CPU and 1600 TB of disk space. The global computing resources foreseen to be installed in Italy are 450 KSI95 of CPU and 400 TB of disk space. In spite of the fact that these numbers are affected by a very large error because neither the code nor the algorithms are in their final form we are confident that the figures presented are not far from the final ones. They are certainly adequate to estimate our computing needs in the next three years.

These numbers take into account that the contribution to the ALICE computing infrastructure will be shared mainly among France, Germany and Italy, where the Italian collaboration to ALICE in terms of people is close to the sum of France and Germany together.

The plan is to reach by 2003 a capacity of 45 KSI95 and 40 TB of disk (10% of the final size). These resources will allow performing the prototype tests at a realistic scale and, at the same time, will provide the adequate resources for the simulation and analysis tasks planned by the Italian groups of ALICE in the next three years.

Two different ALICE projects will be involved in the Grid activity. The first is connected with the Physics Data Challenges whose first milestone is the Physics Performance Report. This is a complete report on the physics capabilities and objectives of the ALICE detector that will be assessed thanks to a virtual experiment involving the simulation, reconstruction and analysis of a large sample of events. The first milestone for the Physics Performances Report when the data will have to be simulated and reconstructed is due by the end of 2001. The specific purpose in this case is to obtain the necessary information, from detector physics performances, to establish priorities in the physics program and in the experiment set-up. The Physics Data Challenges will be repeated with a larger number of events regularly to test the progress of the simulation and reconstruction software. The simulations will be devoted to study the detector Physics performances. Careful studies of the dielectron and the dimuon trigger are necessary for instance to fully understand and optimise their efficiency and rejection power. A large emphasis will be given to interactive distribute data analysis for which special codes will be developed and that it is expected to use a very large spectrum of the services offered by the Grid.

A second activity is linked with the ALICE Mass Storage project. In this context already two data challenges have been run, and third one is foreseen in the first quarter of 2001 involving quasi-online transmission of raw data to remote centres and remote reconstruction. Other data challenges aiming at higher data rates and more complicated data duplication schemas are planned at the rhythm of one per year. The foreseen milestones are as follows.

1. Physics Data Challenges:

1. October 2000 Production Version of AliRoot
2. July 2001 Production, reconstruction and analysis of 10⁶ Events.
3. End 2001 First Physics Performance Report.
4. End 2002 Production, reconstruction and analysis of 3 x 10⁶ Events.
5. End 2003 Production, reconstruction and analysis of 7 x 10⁶ Events.

2. Computing Data Challenges:

1. Beginning of year 2001: Alice Data Challenge III, with the involvement of the Regional Centres.
2. Further ADCs with increasing complexity are foreseen in the years 2002 (5%), 2003 (10%), 2004 (25%), 2005 (50%).

Current estimation of the CPU power to simulate a central event are around 2250 KSI95/s while to reconstruct it 90 KSI95/s are needed. The storage required for a simulated event before digitisation is 2.5 GB and the storage required for a reconstructed event is 4 MB.

In order to optimise the utilisation of the resources, signal and background events will be simulated separately and then combined, so that to produce a sample of 10⁶ events will require the full simulation of only 10³ central events. The reconstruction will be performed on the full data sample. The table below reports the CPU and storage needs to simulate and reconstruct the required number of events. In the table below it is assumed an amount of CPU that, if used for full year, at 100% efficiency, will provide the needed capacity. The corresponding amount of disk space is also indicated.

ALICE Simulation	2001	2002	2003
Events	1.0E+06	2.0E+06	4.0E+06
Needed CPU (SI95) (assuming 12 months time and 100% efficiency)	3000	6000	12000
Needed disk (TB)	6.5	13	26

Adding a 50% factor for the analysis and taking into account a 30% inefficiency related to the availability of the computers, we believe that the prototype scale proposed in the table below is just adequate for the needs of the foreseen simulation activity.

The consumable and manpower costs have not been evaluated yet.

The last column represents the integral achieved in year 2003.

The evaluation of the costs of the needed resources has been done according to the following table:

1. ATLAS

The estimations currently being made in the ATLAS collaboration evaluate at ~1000 KSI95 the computing power needed outside the Tier0 in 2006. These estimations are of course affected by a large error, however they are the best ATLAS can provide at this time and are the ones which have been presented at the LHC Computing Review taking place in these days. The secondary storage needs of a Tier1 Regional Center are estimated ~200 TB in 2006.

The Milestones for ATLAS computing include:

• Mock Data Challenge 1 (MDC1) in the first half of year 2002, testing the full new software chain on the scale of at least ~10⁶ events (10⁶ coming out of Level3 trigger, thus for simulating the working of Level2, which is the minimal goal, a factor 10 more events have to be fully simulated), distributed as widely as possible and making use of as much Grid as possible. Different trigger condition will be simulated and a significant subset of the Physics TDR plots will be reproduced.
• MDC2 in the first half of year 2003 on the scale of ~10⁸ events, testing also the distributed analysis Grid procedures and involving all the Regional Center prototypes.

The activities of specific interest for the Italian ATLAS community from 2001 include:

• Trigger studies for the muon system: a capacity of ~5000 SI95 and ~ 3TB disk should be in place already at start 2001 for allowing results to be available at mid 2001 for the trigger TDR.
• GEANT4 simulation of QCD jets for studying the background to b/t physics and to the t identification: 10⁶ events to be simulated in 6 months time starting in mid-2001 will require ~2000 SI95 and ~2TB disk.

The detailed ATLAS milestones 2001-2003 for physics and trigger studies have still to be agreed by the collaboration (see ATLAS document in the Appendix): the activities of Italian groups in 2002-2003 will also depend from these agreements, the participation to MDC2 is however already decided.

The table below provides a first preliminary evaluation of the target capacity to be reached each year by the ATLAS Regional Center prototypes. It is assumed 80-90% of the total capacity will be located in the two Tier1 sites, while the rest will be allocated to 3-7 Tier3 sites. The breakdown of the CPU acquisitions between the different years could be somewhat revised subject to the final setting of the ATLAS computing Milestones

Capacity targets for the INFN Testbed ATLAS
	units	2001	2002	2003	Total
CPU capacity	SI95	5,000	3,000	12,000	20,000
Disk capacity	TBytes	5	5	10	20
Tape storage (backups)	TBytes	10	10	20	40
Material Cost	ML	650	270	510	1430
Outsourcing	ML	200	300	600	1100
Total costs	ML	850	570	1110	2530
Total costs	K€	425	285	555	1265

The last column represents the integral achieved in year 2003.

The ATLAS baseline model for implementing the Tier1 Regional Center relays on manpower outsourcing, for system management and operation, from available Consorzi di Calcolo: a first evaluation of the cost of this outsourcing is ~500Ml for the 3 years. The additional cost of housing is estimated ~200Ml for the 3 years. These ~700 Ml are estimated assuming the Tier1 prototypes are implemented dividing the capacity between two different sites: a single site option would allow a saving roughly estimated in ~300Ml over the three years. The consumable costs (electrical power etc.) for keeping this computing capacity up and running in the Tier1 for the full three years is estimated ~400Ml.

CMS has also adopted the twofold motivation of the testbed capacities:

• A Regional Centres prototype of about 10% of the final (2006) System by year 2003.
• A "real needs applications" approach via the High Level Trigger studies and Physical studies to be due by year 2003.

Milestones settled by CMS are related to both the above approaches:

• Data challenge: ~1% in 2000 (ORCA), ~5% in 2002, ~20% in 2004.
• HLT studies: 2000, 2001, and 2002.
• 2001: DAQ TDR
• 2002: SW/Computing TDR
• 2003: Physics TDR (~ 5% data challenge results and 10% scaling demonstration)
• 2004: Stress test (20% data challenge)

Some of the global CMS Collaboration resources expected by year 2006 are as follow:

• Total CPU power of the order of 1.7x10⁶ SpecInt95.
• Total disk storage larger than 700 TBytes.

The 10% realization by year 2003 of Tier-1 and Tier-2 Centres are in the plans of current INFN-Grid project for CMS Italy. To reach this goal CMS has adopted a slowly growing approach that consists to procure and put in operation some 20% in year 2001, 30% in year 2002 and 50% in year 2003 of the resources necessary to build the 10% final system prototype.

On the other hand, Italian CMS collaboration is strongly involved in the simulation and analysis of the necessary data to define the High Level Trigger algorithms and the Physical studies.

CMS is already exploiting now (2000) the simulation and reconstruction software for the off-line analysis of the Trigger and Physical channels. For the nearest time goals the deep study and optimization of the Trigger algorithms is the driving effort.

The rejection factor that the CMS Trigger has to provide against the background reactions is as large as 10⁶-10⁷. The High level Trigger (level2 and 3) have to provide a rejection factor of the order of 10³ in the shortest time possible and with the larger possible efficiency without depressing the searched signal.

The process of simulation and study has a planned schedule that will improve the statistical accuracy during the next three years. The number of events to be simulated increase of an order of magnitude during the three year project program, but the requested resources only increase of a factor two per year, taking into account the better efficiency and the learn management of the resources themselves.

CMS Italy (INFN) is strongly (and in many fields with a leading role) involved in this process of simulation and study, contributing with al least the 20% of the effort (both with computing resources and physics analysis competences).

Both the approaches to the prototyping phase lead to the same amount of resources needed. This scenario has the benefit of going to the prototype of Regional Centres (Tier-1 and Tier-2's) using the resources for "REAL" activities and physical results.

A preliminary deliverable plan for the two approaches can be summarized as follow:

2001	–Tier-n first implementation –Network connection –Main centers in the Grid	–HLT studies as of 106-107 events/channel –Coordination of OO databases –Network tests on "ad hoc" links and "data mover" tests –All disk option storage
2002	–Tier1 dimension is doubled –Tier0 Centre is connected (Network and first functionality's) –Grid extension including the EU project	–Physics studies in preparation of the TDR and 5% data challenge for Computing TDR –OO distributed databases (remote access) –Performance Tests –Mass storage studies
2003	–Infrastructure completion –Functionality tests and CMS Integration	–Final studies for Physics TDR and preparation for 2004 data challenge – Data challenge –Full integration with CMS Analysis and Production

A preliminary table with the most demanding resources required to CMS Italy prototype and production activities follows:

The last column represents the integral achieved in year 2003.

Preliminary cost estimates for the above resources are as following (it should be stressed that Personnel, consumables and WAN cost are NOT included in the table, as well as the local infrastructure support and network integration)

The last column represents the integral cost for years 2001-2003.

1. LHCb

The current baseline LHCb computing model is based on a distributed multi-tier regional centre model following that described by MONARC. We assume in this scenario that regional centres (Tier 1) have significant CPU resources and a capability to archive and serve large data sets for all production activities, both for analysis of real data and for production and analysis of simulated data. At present we also assume that the production centre will be responsible for all production processing phases i.e. for generation of data, and for the reconstruction and production analysis of these data.

The Italian regional centre requirements for supporting user analysis and simulation have been estimated to be of the order of 100kSI95 CPUs and 80 TB of disks. The plan is to reach by 2003, the order of 20kSI95 and 0.7 TB of disks. These resources will allow to perform the prototype tests on a significative size, continue on-going detector and low level trigger optimisation, and begin signal and background Monte Carlo event simulations for physical studies.

The last column represents the integral achieved in the year 2003.

1. Other Experiments and Projects

Expressions of interest have been presented by several experiments and projects. All the experiments are obviously welcome to take part in the Grid activities, but in this proposal only a couple of "non-LHC" projects: APE and VIRGO are considered full main partners in the development of the Grid project.

Also ARGO and COMPASS have shown significant interest in the test-bed activity, offering the opportunity to add new requirements to the project. Persons from those experiments will take part to the project and inject their specific needs in the WP activities.

1. APE

A test case for the Grid project is the analysis of Lattice QCD data.

At the end of the year 2000, several APEmille installation will be up and running in several sites in Italy, Germany, France and the UK, for an integrated peak performance of about 1.5 Tflops.

These machines will be used for numerical simulations of QCD on the lattice, with the physics goals of an accurate analysis of the low-lying hadrons in full QCD, and an investigation of the phenomenology of the weak interaction of heavy quarks systems.

In the following years, a new generation of machines will gradually become available. A major player in this field will presumably be the new generation APE project, apeNEXT that will give an increase of a factor ten in performance, reaching the level of 5 to 10 Tflops. The coordinated use of several machines running on the same physical problem, will help accumulate large statistics made available to a wide community of users to perform independent investigations.

We shall then see the trend to have a large computer installation running Lattice QCD code as the analogous of a particle accelerator. In this analogy, the lattice field configurations are equivalent to the collision events, collected and analyzed by experiments. The relevant point for Grid is that the amount of data to be stored and analyzed is of comparable size as a large experiment. Typical figures for the database size are of 25 TByte in the year 2000-2003 for APEmille up to 1 PByte in the years 2003-2006 for apeNEXT.

The activities will than be that of operating a storage systems supporting such a database, presumably distributed on a small number of sites. A farm of processors will be set up to retrieve configurations from the databasebase and process them. This will also mean that a network infrastructure and the middle-ware to allow physicists to perform remote analysis will have to be developed. All these points may represent, within Grid, a Lattice QCD specific test-bed to be set up quite rapidly, based on a couple of APEmille sites with about 5 TByte of data customizing the relevant middle-ware (presumably Globus based) to allow Lattice QCD analysis.

This preliminary program should heavily leverage on the investment made on Grid-like techniques by our experimental colleagues and concentrate on the specific features of Lattice QCD analysis. The experience gained in this effort would be precious to sustain a smooth analysis of apeNEXT configurations as they become available.

2. VIRGO

The scientific goal of the Virgo project is the detection of gravitational wave in a frequency bandwidth from few Hertz up to 10 kHz. Virgo is an observatory that has to operate and take data continuously in time. The data production rate of the instrument is ~ 4 Mbyte/s including the control signals of the interferometers, the data from the environmental monitor system and the main interferometer signals. Raw data will be available for off-line processing from the Cascina archive and from a mirror archive in the computer center of the IN2P3 of Lyon (France). The reconstructed data h(t), plus a reduced data set of the monitoring system, define the so called reduced data set. The production rate of the reduced data is expected of the order of 200 kbyte/s.

The off line analysis cases that are most demanding from the point of view of computational cost and storage are the following:

• the search of the binary coalescent signals
• the search of the continuous gravitational wave signals

We propose to approach these problems in the framework of the Grid project.

1. The inspiraling binary search

The search for the inspiraling binary g.w. signal is based on the well established technique of the matched filter.

This method correlates the detector output with a bank of templates chosen to represent possible signals with a sufficient accuracy over the desired range of parameter space.

The computing load is distributed over different processors dealing with different families of template. Then, the output is collected in order to perform the statistical tests and extract the candidates.

The computational cost and the storage requirements are non linear functions of the coordinates of the parameter space so that the optimization of the sharing of the computation resources and the efficiency of the job fragmentation will be the crucial point of the test.

The goal of the test bed is the application of the analysis procedure on the data generated by the Virgo central interferometer. The output of this test is essential in order to implement on line triggers for the binary search signal.

The preliminary target is the search of signals generated by binary star system with a minimum mass of 0,25 Solar Masses at the 91% of Signal to Noise Ratio (SNR).

2. The pulsar search

The case of pulsar signal search is more demanding for computational resources. The procedure of the signal search is performed by analyzing the data stored in a relational data base of short FFTs derived from the h(t) quantity. The search method is basically hierarchical so that the definition and control of the job granularity is characterized by a higher level of complexity.

The goal of the Grid test bed is to optimize the full analysis procedure on the data generated by the Virgo central interferometer. We plan to limit the search to the frequency interval 10 Hz - 1.25 kHz and the computation will cover 2 month of data taking.

3. Computational resources and links.

Let us now list the needs for the total computational power and storage to be hierarchically distributed in the Virgo INFN sections and laboratories of the collaboration and structured in the classes of computer centers

Concerning the network links we notice that

1. the laboratory in Cascina has to become a node of the network backbone
2. we need dedicated bandwidths for the transmission of the reduced data set to the Tiers and to perform intensive distributed analysis
3. the international link should permit the reception and transmission of the reduced set of data to Europe, USA and Japan, and, at least in the future, the transfer of a relevant fraction of the raw data in France.

In conclusion, for test beds dedicated links connecting Virgo-Cascina, Roma1, Napoli, Perugia and Firenze must be foreseen.

Finally, we report in the Table the total capacity needed for the Virgo test beds at the end of 2001 and the final target for the off line analysis of Virgo.

2. Workplan

The following chapters will describe the work packages details and the resources needed to accomplish the various tasks.

The general philosophy of the work plan is to take into account the following main activities:

1. Initial tests of the Globus Toolkit.
2. Interoperability with the European DataGrid Project.
3. Real use of the applications defined by the experiments.
4. National Testbed definition and deployment.

The first activity or work package is already started, will probably end-up after 6 months of tests and will inject in the second work package (at European level as well) the necessary information on how much of Globus Toolkit can be used and how many changes and improvements have to be done.

The second activity is fundamentally centered on the adaptation of the European work packages deliverables to the national infrastructure. This includes also all the eventually necessary modifications and additions which will be done for the INFN-Grid scope.

Requirements and Applications to be tested "on the Grid" will be delivered by the third activity which will start from the experiments wishes and needs and after having filtered them will inject the requirements in the second and fourth activity. Moreover this work package will provide the applications that will be tested on the Grid infrastructure.

The fourth activity is devoted to the definition of the national testbed and is also intended to take care of the physical implementation of such an infrastructure.

2. Work Package 1 – Installation and Evaluation of the Globus toolkit

1. General Description of the Package

In order to create and deploy usable Grids, a framework providing basic services and functionalities is necessary.

The toolkit provided by the Globus project has been identified as a possible candidate for this "software infrastructure" for several reasons:

• The Globus "layered bag of services" model is suitable to support a wide variety of applications and programming models: developers of tools or applications can select only the specific tools they need
• Services are distinct and have well-defined interfaces, therefore they can be integrated into applications or tools in an incremental fashion
• The Globus toolkit has already been used with success in several projects of different disciplines. Other Grid projects (i.e. PPDG, NASA IPG) have chosen Globus as basic infrastructure
• The current research activities of the Globus team (i.e. data Grids, advance reservation, end-to-end QoS, …) are considered of much interest for this project
• Contacts with the Globus core team are already in place, and good and productive relations may be established.

The goal of this work package is to evaluate Globus as a distributed computing framework: Globus mechanisms will be evaluated for robustness, ease of use, effectiveness and completeness, in order to find which services can be useful for the middleware work packages of the INFN-Grid project and of the DataGrid project (the European Grid project).

Modifications and extensions needed to correct any Globus shortcomings will be identified.

Work in this work package will be coordinated with the similar activities that are going to be performed also by other members of the European Grid project (i.e. Cern), in order to share the acquired experience, to avoid the duplication of the same activities, etc…

1. Work plan

Activities in this work package will investigate the functionalities of the Globus toolkit, to evaluate which services can be used, what is necessary to integrate/modify, what is missing and therefore must be found somewhere else, or must be developed.

In particular Globus services for security, information, resource management, data migration, fault monitoring, execution environment management will be investigated.

Some activities have already been started, and there is already an experience with the Globus toolkit by some members contributing to this work package. Therefore it is foreseen that the described activities can be performed in a short period (6 months).

The results of this evaluation will be considered to plan and schedule the future work. For example, if the activities of this work package will prove that Globus can be used as a framework providing basic Grid functionalities, it will be necessary to widely deploy Globus in all INFN sites in order to build the infrastructure for the INFN-Grid, it could be necessary to modify and extend the software to correct the identified shortcomings, etc...

1. Task 1.1 Globus deployment

In order to widely deploy Globus in a successful way, it is very important to reduce the complexity for installation and maintenance, limiting the manpower required for these operations. Local administrators, responsible to install Globus on local resources, will be provided with specific tools, documentation, operational procedures, etc…

A group of "central" Globus administrators will implement and maintain a central software repository (for example using AFS): they will install Globus for all the considered platforms, test and install new software releases, install the required patches, develop tools and documentation to enable local administrators to quasi-automatically install the software on the local resources, etc…

Local administrators will only be responsible to deploy Globus on the local machines. These activities will require limited manpower, thanks to the tools and the documentation provided by the "central" team.

2. Task 1.2 Security

The Grid Security Infrastructure (GSI) service, focusing on authentication, will be evaluated.

The single sign-on mechanisms for all Grid resources provided by GSI will be tested between different administrative domains, each one using different security solutions, mechanisms and policies (such as one-time passwords and kerberos).

Activities for this task will also include the integration of some existing applications with the GSI authentication mechanisms, using the gss-api.

Since the Grid Security Infrastructure is based on public key technology, that relies upon certificates, a "local" Certification Authority responsible to issue these certificates must be implemented. The relations (i.e. CA hierarchy) between this Certification Authority and other Certification Authorities (for example those ones implemented by other partners of the DataGrid project) must be investigated, defined and implemented.

3. Task 1.3 Information Service

The Grid Information Service (GIS), formerly known as Metacomputing Directory Service (MDS) will be analyzed.

Using LDAP as standard protocol, GIS provides information on system components of the dynamic Grid environment (i.e. architecture type, amount of memory, load of a computer, network bandwidth and latency, …) in a common interface. This information can then be accessed and used by various components (for example by a resource broker, for resource discovery).

Activities for this task have already been started, in particular with the implementation of a national GIS server.

Tests on performance and scalability (increasing the number of agents that produce useful information and the number of components that access and use that information) will be performed. The related results will be used to decide and establish the most suitable architecture for reliable and redundant access to the GIS in the multi-site INFN environment (How many GIS servers have to be considered ? Where do these servers have to be installed ? How the information can be replicated ? …).

Tools and interfaces (in particular web user interfaces) addressed to Grid users and administrators must be developed, to support the various operations related to the Globus GIS service: browsing the information servers, adding, deleting, modifying information, etc…

Tests will also be performed on the possibility and suitability to generalize the GIS schema, integrating the default information with other required information (i.e. agents that automatically provide the GIS with specific information on resource characteristics and status, information on replicas of data, …).

4. Task 1.4 Resource Management

The GRAM (Globus Resource Allocation Management), that is the Globus service for resource allocation and process management, will be analyzed and evaluated.

In the Globus resource manager architecture, each GRAM is responsible for a set of resources operating under the same site-specific allocation policy, often implemented by an existing resource management system.

Activities in this task will be done in an incremental fashion, starting with simple scenarios.

As first step, the Globus functionalities for job submission on remote resources that don’t rely upon resource management systems will be evaluated.

The functionalities of GRAM in conjunction with different (local) resource management systems (in particular LSF and Condor) will be investigated, to evaluate if GRAM could be a possible uniform interface to different resource managers. Demonstrations showing submitting jobs via Globus which run on remote systems using different underlying resource managers, complete with file staging, forwarding of output, etc… without the need for direct human intervention will be performed.

For these tests the INFN Condor WAN pool will be interfaced to Globus as a "single" resource.

It will be necessary to evaluate how the resource requests expressed in terms of Globus RSL (Resource Specification Language) are translated in the resource description languages of the specific resource management systems considered.

It will also be necessary to evaluate if and how each local GRAM is able to provide the Grid Information Service with information on characteristics and status of the local resources.

5. Task 1.5 Data Access and Migration

The GASS (Global Access to Secondary Storage) APIs, that allow programs that use the C standard I/O library to open and subsequently read and write files located on remote computers, will be analyzed, considering the possible file access patterns. The capabilities, performance, ease of use of the GASS services will be evaluated and compared with other solutions, such as distributed file systems. Some existing applications will be adapted to use these APIs, to verify if GASS mechanisms can be a viable and suitable solution to access remote data.

Moreover, tests will be performed to evaluate the functionalities, performance and robustness of the Globus tools for data migration. In particular the GASS service and GSIFTP (an FTP which works with the Globus authentication system and allows high speed file transfers with fully adjustable TCP window sizes) will be evaluated in LAN and WAN environments, and compared with other tools and services, such as FTP.

6. Task 1.6 Fault Monitoring

The Globus HBM (HeartBeat Monitor) service, providing simple mechanisms for monitoring the health and status of a distributed set of processes, will be analyzed, evaluating its scalability, accuracy, completeness, overhead and flexibility.

This service for fault detection will be evaluated not only for controlling Globus system processes (as it has been originally designed), but it will also be analyzed if it is suitable for monitoring other processes implementing particular services (i.e. http server daemons) and also for application processes associated with "user" computations.

Using the provided API, specific data collectors will be implemented: in the beginning these data collectors should simply detect and notify about failures of processes that have identified themselves to the HBM. Fault recovery mechanisms, such as automatic restart of crashed daemon processes, will be implemented later.

7. Task 1.7 Execution Environment Management

Tools are needed to set up the environment in which code must actually execute: binaries have to be staged, runtime libraries have to be located and/or instantiated, environment variables and other state needed must be established, etc…

The Globus Executable Management (GEM) service will be tested, in order to evaluate whether it is able to provide some of these functionalities, required when a code migration strategy (the application is moved where the computation will be performed) must be considered.

Table .1 – List of the Deliverables for WP1

Deliverable	Description	Delivery Date
D1.1	Tools, documentation and operational procedures for Globus deployment	6 Months
D1.2	Final report on suitability of the Globus toolkit as basic Grid infrastructure	6 Months

 

Table .2– List of the Milestones for WP1

Milestone	Description	Date
M1.1	Basic development Grid infrastructure for the INFN-Grid	6 Months

 

2. Resources

Only the resources required for the described activities, that will last for the year 2000, are listed in the following tables. As described above, the resources necessary for the next years will be better identified after this first evaluation of the Globus toolkit.

1. Work Package 2 – Integration with DATAGrid and Adaptation to the National Grid Project

This package has to deal with the integration of the DATAGrid project developments and the necessary modifications to meet the Italian INFN needs and configuration. For this purpose the WP is split into sub packages.

1. Task 2.1 - Workload Management

1. General Description

The goal of this task is to define and implement a suitable architecture able to assign computing tasks to the available Grid resources, taking into account many factors, pertaining to the tasks themselves and to the available resources:

• Type, size and destination of output data
• Availability and suitability of dynamic and heterogeneous resources (CPUs, network, storage)
• Knowledge of existing (previously submitted) tasks in the system
• Global and local constraints (i.e. policies governing how resources dedicated to a particular experiment should be prioritized, policies governing when "external" users can access local resources, etc…)

For this purpose the middleware produced within the DataGrid project will be adapted and deployed, in order to build a reliable workload management system, able to meet the requirements of the future experiments.

Moreover, existing technology base developed under other Grid related projects (in particular Globus and Condor) will be integrated and extended, also profiting from the considerable experience with the use, deployment and support of these software systems (in particular it is worth to remark the many years experience with the Condor system, and the collaboration between INFN and the Condor Team of University of Wisconsin, Madison). These activities are strictly related with the DataGrid project, and will provide useful inputs and solutions for the research and development performed in this European project.

The man-months and personnel participation include INFN contribution to DATAGrid project in workload management activities.

1. Work plan

Activities in this task will start with the simplest scenarios that require limited and simple services, considering in the beginning simple implementation strategies. More complex environments will be considered in an incremental fashion.

The production of simulated data is typically a scheduled task, and the characteristics and requirements of these jobs are known in advance: these are usually CPU bound applications, with a limited I/O rate. Monte Carlo production is typically performed by "traditional" applications that perform their I/O activities on the executing machine storage system. They usually just need as input small card files describing the characteristics of the events to be generated and geometry files describing the detector to be simulated, that can be staged in the executing machine without a significant cost.

Therefore for Monte Carlo production the goal is to build a system able to optimize just the usage of all available CPUs, maximizing the overall throughput. Code migration (moving the application where the processing will be performed) will be considered as implementation strategy.

For Monte Carlo production dedicated PC farms, distributed in different sites, will be considered, but it will also be investigated if it is suitable to exploit idle CPU cycles of general purpose workstations as well.

Bookkeeping, accounting and logging services must be implemented in this framework. Moreover, it must be possible to define policies and priorities on resource usage.

A simple language for submitting jobs, removing/suspending jobs, and monitor their state will be made available in this phase.

The workload management system for Monte Carlo production will be deployed considering elements of Condor and Globus Grid architectures (it is foreseen that this work will be coordinated with the research and development activities performed in the DataGrid project).

For what concerning Condor, some activities at hand are:

• How Condor can be used for dedicated Grid resources (and not only to exploit idle CPU cycles of a collection of a separately owned and distributed computing resources)
• How Condor’s ClassAds and matchmaker system could be used and augmented to implement a more general Grid matchmaking system.

About Globus, important issues to be investigated as WP1 follow-up are:

• How to use and augment the Resource Specification Language (RSL) in order to be able to define all the information needed by the workload management system
• Evaluate and in case modify some existing high throughput brokers, such as the High Throughput Broker developed by the Globus team
• Design and implement a high throughput broker, if the existing ones are not able to provide all the necessary functionalities.

The interconnection of Globus and Condor must be investigated as well.

Tests on how a Globus client can submit jobs to a Condor pool and vice versa how a Condor machine can submit jobs to a Globus Grid are already on going.

It will also be investigated if Personal Condor can be a suitable broker for Globus resources.

A comparison of different local resource management systems (LSF, PBS, etc…) will also be performed.

Reconstruction of real/simulated data is the process where raw data are processed, and ESD (Event Summary Data) are produced.

Production analysis includes Event Selection (samples of ESD of most interest to a specific physics group are selected) and Physics Object Creation (the selected ESD data are processed, and the AOD, the Analysis Object Data, are created).

These are again scheduled activities, driven by the experiment and/or by physics groups that typically will be performed in the Tier 1 Regional Center possibly distributed in different sites.

For these kinds of applications the goal is again the maximization of throughput. Besides code migration, data migration (moving the data where the processing will be performed) must be considered as a possible implementation strategy: it could be profitable to move the data that must be process to remote farms, able to provide largest CPU resources, but it must be considered that the required data sets usually have a non negligible size, and therefore the cost for moving them must be taken into account.

Again, the services that must be considered in the workload management system for these applications are bookkeeping, accounting, logging, the possibility to define policies and priorities on resource usage.

These jobs process selected AOD data to prepare more refined private data samples together with analysis plots and histograms.

User analysis is typically a "chaotic", non-predictable activity, driven by the single physicist.

Moreover, the goal is typically the minimization of latency of the submitted jobs, instead of the maximization of the overall throughput.

The new HEP applications are based on Object Oriented programming paradigms, and Object Oriented client/server architectures, such as Corba/ORB, Java/RMI, Objectivity/DB, Espresso, Root, etc. These applications split data from CPU, and therefore it is not strictly necessary that the input/output data reside on the local storage system of the executing machine. Therefore for these client/server applications remote data access (accessing data remotely) must be considered as another possible implementation strategy, besides data migration and code migration. Network is an important resource and must be taken into account to deliver optimal workload, in order to minimize application elapsed time.

Advance reservation and co-allocation of resource mechanism and strategies will be studied and tested in collaboration with the Data Grid project.

Security mechanisms for authorization and authentication must also be considered as services to manage user analyses, besides bookkeeping, accounting, logging, and the possibility to define policies and priorities on resource usage.

Since the complexity and the details of the workload management system must be hidden to users, a "high level" graphical user interface (in particular a Web Interface) for task management, allowing physicists to easily perform the various activities, is required.

There will be at least 3 PC connected via a Fast Ethernet switch for each site belonging to this WP. Since these equipments will be used for all the middleware WP (WP1, WP2.1 WP2.2, WP2.3) then it will be included in the testbed WP.

It will be necessary to buy enough licenses for LSF, to evaluate the performance of the different local resource manager. It is assumed that for each machine included in the testbed of the WP the same number of LSF software licenses will be available. It is assumed that, to do an extensive evaluation using farms with a high number of nodes, the necessary software licenses will be provided by the experiments or by the computing fabric WP.

1. Task 2.2 - Data Management

The Data Management task in the INFN-Grid project is strongly correlated to the DATAGrid WP2 on one side, and to the High-Energy Physics Applications (DATAGrid WP8) on the other.

Let's remind the tasks of the european WP:

2.1 Data Access and Migration

2.2 Replication

2.3 MetaData Management

2.4 Security and Transparent Access

2.5 Query Optimization and Access Pattern Management

2.6 Coordination

and the deliverables:

D1: A system capable of managing replicas and metadata at the file level

D2: A system capable of securely and transparently managing dataset queries and replicas

D3: Demonstration of an efficient production system

In the context of INFN-Grid the work should concentrate on data access in a situation where several sites hold data samples which may or may not be replicated. The experiments use cases will concern mostly simulated data, produced in Italy as well as elsewhere. Data will be stored on disk, either in Objectivity or with other systems.

Assuming that Data Replication and Migration is mainly handled by the European project and considering that, for Regional Centers prototyping, Data Access, MetaData definition and management are crucial issues.

We propose to define the following sub-tasks in INFN-Grid:

Task 2.2.1: Wide Area Data Location: assuming that data are resident in different sites, build a service which allows any user to know automatically in which site/storage and possibly file data are; such a service will relieve the user from the burden of consulting data catalogs before executing his jobs

Task 2.2.2: MetaData Definition and Mapping to Real Data: define the attributes which fully characterize a dataset in an abstract way and the methods of mapping the abstract description to the actual one; it should be noted that such a task, although implicitly present in the european project needs a localization onto the italian case, because the underlying storage layer might be completely different.

Task 2.3.3: Data Query Evaluation: build a service capable to evaluate in the national distributed context how and when a query can be satisfied, returning codes which should be captured by user programs and guide their completion.

 

Table .9– List of the Deliverables for WP2.2

Deliverable	Description	Delivery Date
D2.2.1	Definition of requirements for a Data Location Broker (DLB)	5/2001
D2.2.2	Definition of a metadata syntax	7/2001
D2.2.3	Prototype of a DLB using metadata	12/2001
D2.2.4	Replica Management at file level	12/2001

 

Table .10– List of the Milestones for WP2.2 year 2001

Milestone	Description	Date
M2.2.1	Capability to access replicated data at file level using a simple abstract description	12/2001

 

Table .11 – Personnel Contribution to the WP2.2 Task

Sede	Cognome	Nome	DataGrid	INFN-Grid	Esperimento
BARI	Silvestris	Lucia		0.3	CMS
	Zito	Giuseppe	0.3	0.5	CMS
PISA	Arezzini	Silvia		0.3	IT
	Controzzi	Andrea		0.5	CMS
	Donno	Flavia	0.5	0.2	IT
	Schifano	Fabio		0.2	APE
ROMA	Barone	Luciano M.	0.3	0.3	CMS
	Lonardo	Alessandro		0.3	APE
	Michelotti	Andrea		0.3	APE
	Organtini	Giovanni		0.2	CMS
	Rossetti	Davide	0.3	0.2	APE

 

Materials for WP 2.2

There will be at least 3 or 4 PC connected via a Fast Ethernet switch for each site belonging to this WP. Since this WP will be used for all the middleware WP (WP1, WP2.1 WP2.2, WP2.3) then it will be included in the testbed WP.

Consumables for WP 2.2

No specific SW license is envisaged for WP 2.2 in year 2001.

2. Task 2.3 – Grid Application Monitoring

1. General Description

The Application Monitoring task in the INFN-Grid project is strongly correlated to the DATAGrid WP3.

The purpose of this task is to deliver methodologies and mechanisms for monitoring applications in Grid environments. The possibility to monitor distributed computing components is a crucial issue for enabling high-performance distributed computing. Monitoring data are needed in such environments for several activities such as performance analysis, performance tuning, scheduling, fault detection, QoS application adaptation, etc….

Some key issue of a monitoring service in a Grid environment include:

• scalability
• discovery of data
• validity of information

Scalability is very important because of the high number of resources and users working at the same time in the system: the intrusiveness of monitoring mechanisms should be limited and efficient coordination mechanism developed, otherwise resources could be consumed by the monitoring facilities themselves. With many resources involved by a single application, appropriate mechanisms to discover and understand the characteristics of the information that are available are needed. Finally, in many cases performance information are effective for a short lifetime, during which they can be used.

Monitoring services developed within the European Grid project will be adapted to specific needs of the future experiments. Moreover, existing technologies developed in other Grid related projects will be examined as well, in order to verify its integrability and usefulness in the project. Exploitation of recent agent technologies will also be explored, since their capability to cope with systems’ heterogeneity and to deploy user customized procedures on remote sites seems to be very adequate to Grid environments.

1. Work plan

A requirements analysis should be performed as first task to evaluate peculiar needs of Grid environments and in particular INFN ones. This work should also monitor other Grid related project, in order to understand the different views of the problem. Existing tools and technologies for monitoring will be analyzed with respect of the requirements aforementioned.

An appropriate monitoring architecture will be defined for INFN, taking into account localized monitoring mechanisms able to collect information on different resources. Directory services will be exploited to enable location and/or access to information. The task will strongly rely on the development of similar services by the DataGrid project and in particular of:

• measurement services
• data collection
• data repository services
• data discovery

Starting from raw data collected by the measurement service, appropriate algorithms, methodologies and mechanisms should be developed to build higher level informations. Effective tools for visualizing this data should be also developed, in order to quickly and effectively perform activities such as performance tuning, fault detection, etc.

Integration with existing Grid environments will be performed, as well as extensive testing of usability and of effectiveness. Informations and data collected by this task could affect some implementation issues of previous tasks.

1. Resources

Materials for WP 2.3

There will be at least 3 PC connected via a Fast Ethernet switch for each site belonging to this WP. Since this WP will be used for all the middleware WP (WP1, WP2.1 WP2.2, WP2.3) then it will be included in the testbed WP.

Consumables for WP 2.3

No specific SW license is envisaged for WP 2.3 in year 2001.

 

Table .14 – Personnel Contribution to the WP2.3 Tasks (FTE)

Sede	Cognome	Nome	DataGrid	INFN-Grid	Esperimento
BOLOGNA	Galli	Domenico	0.3	0.3	LHCb
	Marconi	Umberto	0.3	0.3	LHCb
CATANIA	La Corte	Aurelio	0.4	0.4	IT
	Tomarchio	Orazio	0.4	0.4	IT

 

Not enough effort is available today inside INFN for all the work related to this task but actions have been taken to find the missing manpower.

2. Task 2.4 - Computing Fabric & Mass Storage

Commodity components like pcs and switched base LANs are mature to form inexpensive and powerful computing fabrics and they are almost ready to be used in real production environments. Nevertheless basic questions concerning how to design a fabric of thousands nodes balancing computing power and efficient storage access or how to control and monitor the basic components of the system, are still open. Moreover there is now the need to integrate the fabric controls and the monitor systems into a Grid environment. This WP 2, task 4 of the INFN-Grid project wants to address problems like these adding a technological tracking task to follow and to test, with real use case, the evolution of the basic constituents of a fabric: microprocessor architectures, motherboard and IO busses, LANs and SANs (System Area Network), storage systems, etc.

The Computing Fabric Task has been then broken down in two subtasks:

• Fabric Design
• Fabric Management (DataGrid)

Crucial fabric design aspects include:

• Overall architecture and fabric setup;
• Interconnection Networks;
• Communication protocols for high speed networks
• Storage Systems
• Microprocessor Technology

Effective local site management and problem tracing should include items like:

• Configuration management and automatic software installation;
• System monitoring;
• Dynamic System Partition
• Problem management.

Grid integration provide a means to publish all the information that the local management, monitor and problem tracing system, can collect.

INFN-Grid Task4 will develop a software toolkit and a design guide to produce, in a very effective way, efficient computing fabrics. The fabric management functions and the integration into a Grid environment will be developed in the DataGrid WP4 framework that is strongly related to the INFN-Grid Task.

1. Work Plan

Our work plan can be broken down in few subtasks.

Task 2.4.1 and 2.4.2 should start within the year 2000 in order to define the proper farm architecture before 2001. We plan to have the following small scale demonstrators:

• NFS connection topology: a) disk servers based farm (Legnaro); b) Distributed disks based farm (CNAF)
• Interconnection Networks: a) Gigabit Ethernet (Genova), b) Myrinet (Lecce), c) Infiniband (2001, Legnaro)
• Storage Systems: Fibre Channel, SCSI, Ultra ATA and Serial ATA (Padova)

1. Resources