Merge branch 'master' of https://baltig.infn.it/cnaf/annual-report/ar2018

build.sh

@@ -71,34 +71,40 @@ cd ${builddir}
 #link_pdf additional additional.pdf
 
 build_from_source user-support main.tex *.PNG
-#build_from_source ams ams.tex  AMS_nuovo.pdf  contributors.pdf  He-MC.pdf  He-MC.tiff  input_output.jpg  production_jobs.jpg
-#build_from_source alice alice.tex *.png *.eps
-#build_from_source atlas    atlas.tex
-#build_from_source borexino borexino.tex
-#build_from_source cms report-cms-feb-2018.tex cms-jobs.eps tier-1-sr-2017.eps
+build_from_source ams AMS-report-2019.tex  AMS_nuovo.pdf  contributors.pdf  He-MC.pdf  input_output.jpg  production_jobs.jpg
+build_from_source alice main.tex *.png 
+build_from_source atlas    atlas.tex
+build_from_source borexino Borexino_CNAFreport2018.tex
+build_from_source cms report-cms-feb-2019.tex tier1-jobs-2018.pdf tier1-readiness-2018.pdf
+link_pdf belle Cnaf-2019-5.0.pdf
 #build_from_source cosa      cosa.tex  biblio.bib beegfs.PNG
-#build_from_source cnprov cnprov.tex
-#build_from_source cta      cta.tex  *.eps
-#build_from_source cuore    cnaf_cuore.tex cnaf_cuore.bib
-#build_from_source cupid    cupid.tex cupid.bib 
-#link_pdf dampe    dampe.pdf
-#link_pdf darkside ds.pdf
+build_from_source cnprov cnprov.tex
+build_from_source cta CTA_annualreport_2018_v1.tex *.eps
+link_pdf cuore cuore.pdf
+build_from_source cupid    main.tex cupid-biblio.bib 
+build_from_source dampe    main.tex *.jpg *.png
+link_pdf darkside ds-annual-report-2019.pdf
 #build_from_source eee eee.tex  EEEarch.eps  EEEmonitor.eps  EEEtracks.png  ELOGquery.png  request.png
 #build_from_source exanest   exanest.tex  biblio.bib monitoring.PNG storage.png
-build_from_source test TEST.tex  test.eps
 #build_from_source fazia fazia.tex
+build_from_source fermi fermi.tex
+build_from_source gamma gamma.tex
+build_from_source icarus report_2018.tex *.png
 #build_from_source gerda    gerda.tex *.pdf
 #build_from_source glast 	glast.tex 
-#link_pdf juno juno.pdf
+link_pdf juno juno-annual-report-2019.pdf
 build_from_source km3net km3net.tex compmodel.png  threetier.png
+build_from_source na62 main.tex 
 build_from_source newchim repnewchim18.tex fig1.png
-#build_from_source lhcb lhcb.tex *.jpg
-#build_from_source lhcf  lhcf.tex
-#build_from_source limadou  limadou.tex
+build_from_source lhcb lhcb.tex *.png
+build_from_source lhcf  lhcf.tex
+build_from_source limadou limadou.tex
 #build_from_source lowcostdev lowcostdev.tex *.jpg
 #build_from_source lspe lspe.tex biblio.bib lspe_data_path.pdf
 build_from_source virgo AdV_computing_CNAF.tex
+build_from_source xenon main.tex xenon-computing-model.pdf
 
+build_from_source sc18 SC18.tex *.png
 
 #build_from_source mw-esaco     mw-esaco.tex *.png
 #build_from_source mw-kube      mw-kube.tex
@@ -107,27 +113,28 @@ build_from_source virgo AdV_computing_CNAF.tex
 #build_from_source mw-iam       mw-iam.tex
 
 #build_from_source na62	 na62.tex
-#link_pdf padme padme.pdf
+link_pdf padme 2019_PADMEcontribution.pdf
 #build_from_source xenon xenon.tex  xenon-computing-model.pdf
-#build_from_source sysinfo  sysinfo.tex pres_rundeck.png deploy_grafana.png
+build_from_source sysinfo  sysinfo.tex *.png
 #link_pdf virgo VirgoComputing.pdf
 
-#build_from_source tier1 tier1.tex
+build_from_source tier1 tier1.tex *.png
 #build_from_source flood theflood.tex *.png
-#build_from_source farming farming.tex
+build_from_source HTC_testbed HTC_testbed_AR2018.tex
+build_from_source farming ARFarming2018.tex *.png *.jpg
 #build_from_source dynfarm dynfarm.tex 
-#build_from_source storage storage.tex *.png Huawei_rack.JPG
+build_from_source storage storage.tex 
 #build_from_source seagate seagate.tex biblio.bib  *.png *.jpg
 #build_from_source dataclient dataclient.tex
 #build_from_source ltpd ltpd.tex *.png
-#build_from_source net net.tex *.png
+build_from_source net main.tex *.png
 #build_from_source ssnn1 ssnn.tex *.jpg
 #build_from_source ssnn2 vmware.tex *.JPG *.jpg
 
 #build_from_source infra Chiller.tex  chiller-location.png
-
+build_from_source audit Audit-2018.tex
 #build_from_source cloud_cnaf cloud_cnaf.tex *.png
-#build_from_source srp SoftRel.tex ar2017.bib
+build_from_source dmsq dmsq2018.tex ar2018.bib
 #build_from_source st StatMet.tex sm2017.bib
 build_from_source ds_eoscpilot ds_eoscpilot.tex 
 build_from_source ds_eoschub ds_eoschub.tex 
@@ -141,7 +148,7 @@ build_from_source sdds-xdc SDDS-XDC.tex *.PNG
 build_from_source sdds-deep SDDS-DEEP.tex *.PNG
 build_from_source PhD_DataScience_2018 PhD-DataScience-2018.tex 
 
-#build_from_source pett pett.tex bibliopett.bib
+build_from_source pett pett.tex bibliopett.bib
 #build_from_source iso iso.tex 27001.png  biblioiso.bib
 
 pdflatex ${topdir}/cnaf-annual-report-2018.tex \

cnaf-annual-report-2018.tex

@@ -144,32 +144,35 @@ Introducing the sixth annual report of CNAF...
 %\includepdf[pages=1, pagecommand={\thispagestyle{empty}}]{papers/experiment.pdf}
 \cleardoublepage
 \ia{User and Operational Support at CNAF}{user-support}
-%\ia{ALICE computing at the INFN CNAF Tier 1}{alice}
-%\ia{AMS-02 data processing and analysis at CNAF}{ams}
-%\ia{The ATLAS experiment at the INFN CNAF Tier 1}{atlas}
-%\ia{The Borexino-SOX experiment at the INFN CNAF Tier 1}{borexino}
-%\ia{The Cherenkov Telescope Array}{cta}
-%\ia{The CMS experiment at the INFN CNAF Tier 1}{cms}
-%\ia{CSES-Limadou at CNAF}{limadou}
-%\ia{CUORE experiment}{cuore}
-%\ia{CUPID-0 experiment}{cupid}
-%\ia{DAMPE data processing and analysis at CNAF}{dampe}
-%\ia{DarkSide-50 experiment at CNAF}{darkside}
+\ia{ALICE computing at the INFN CNAF Tier1}{alice}
+\ia{AMS-02 data processing and analysis at CNAF}{ams}
+\ia{The ATLAS experiment at the INFN CNAF Tier 1}{atlas}
+\ia{The Borexino experiment at the INFN-CNAF}{borexino}
+\ia{The Cherenkov Telescope Array}{cta}
+\ia{The CMS experiment at the INFN CNAF Tier 1}{cms}
+\ia{The Belle II experiment at CNAF}{belle}
+\ia{CSES-Limadou at CNAF}{limadou}
+\ia{CUORE experiment}{cuore}
+\ia{CUPID-0 experiment}{cupid}
+\ia{DAMPE data processing and analysis at CNAF}{dampe}
+\ia{DarkSide program at CNAF}{darkside}
 %\ia{The EEE Project activity at CNAF}{eee}
-\ia{TEST FOR COMMITTEE}{test}
+\ia{The \emph{Fermi}-LAT experiment}{fermi}
 %\ia{Fazia: running dynamical simulations for heavy ion collisions at Fermi energies}{fazia}
-%\ia{The Fermi-LAT experiment}{glast}
+\ia{GAMMA experiment}{gamma}
+\ia{ICARUS}{icarus}
 %\ia{The GERDA experiment}{gerda}
-%\ia{Juno experimenti at CNAF}{juno}
+\ia{Juno experimenti at CNAF}{juno}
 \ia{The KM3NeT neutrino telescope network and CNAF}{km3net}
-\ia{The NEWCHIM activity at CNAF for the CHIMERA and FARCOS devices}{newchim}
-%\ia{LHCb Computing at CNAF}{lhcb}
-%\ia{The LHCf experiment}{lhcf}
+\ia{LHCb Computing at CNAF}{lhcb}
+\ia{The LHCf experiment}{lhcf}
 %\ia{The LSPE experiment at INFN CNAF}{lspe}
-%\ia{The NA62 experiment at CERN}{na62}
-%\ia{The PADME experiment at INFN CNAF}{padme}
-%\ia{XENON computing activities}{xenon}
+\ia{The NA62 experiment at CERN}{na62}
+\ia{The NEWCHIM activity at CNAF for the CHIMERA and FARCOS devices}{newchim}
+\ia{The PADME experiment at INFN CNAF}{padme}
+\ia{XENON computing model}{xenon}
 \ia{Advanced Virgo computing at CNAF}{virgo}
+
 %
 % to keep together the next part title with its chapters in the toc
 %\addtocontents{toc}{\newpage}
@@ -180,18 +183,19 @@ Introducing the sixth annual report of CNAF...
 \addcontentsline{toc}{part}{The Tier 1 and Data center}
 \addtocontents{toc}{\protect\mbox{}\protect\hrulefill\par}
 %\includepdf[pages=1, pagecommand={\thispagestyle{empty}}]{papers/datacenter.pdf}
-%\ia{The INFN Tier 1 data center}{tier1}
-%\ia{The computing farm}{farming}
-%\ia{Data management and storage systems}{storage}
+\ia{The INFN Tier-1}{tier1}
+\ia{The INFN-Tier1: the computing farm}{farming}
+\ia{Data management and storage systems}{storage}
 %\ia{Evaluation of the ClusterStor G200 Storage System}{seagate}
 %\ia{Activity of the INFN CNAF Long Term Data Preservation (LTDP) group}{ltpd}
-%\ia{The INFN Tier 1: Network}{net}
+\ia{The INFN-Tier1: Network and Security}{net}
 %\ia{Cooling system upgrade and Power Usage Effectiveness improvement in the INFN CNAF Tier 1 infrastructure}{infra}
 %\ia{National ICT Services Infrastructure and Services}{ssnn1}
 %\ia{National ICT Services hardware and software infrastructures for Central Services}{ssnn2}
-%\ia{The INFN Information System}{sysinfo}
-%\ia{CNAF Provisioning system: On the way to Puppet 5}{cnprov}
-
+\ia{The INFN Information System}{sysinfo}
+\ia{CNAF Provisioning system: Puppet 5 upgrade}{cnprov}
+\ia{Evaluating Migration of INFN–T1 from
+CREAM-CE/LSF to HTCondor-CE/HTCondor}{HTC_testbed}
 
 \cleardoublepage
 \thispagestyle{empty}
@@ -200,18 +204,19 @@ Introducing the sixth annual report of CNAF...
 \addtocontents{toc}{\protect\mbox{}\protect\hrulefill\par}
 %\includepdf[pages=1, pagecommand={\thispagestyle{empty}}]{papers/research.pdf}
 \cleardoublepage
+\ia{Internal Auditing INFN for GDPR compliance}{audit}
 %\ia{Continuous Integration and Delivery with Kubernetes}{mw-kube}
 %\ia{Middleware support, maintenance and development}{mw-software}
 %\ia{Evolving the INDIGO IAM service}{mw-iam}
 %\ia{Esaco: an OAuth/OIDC token introspection service}{mw-esaco}
 %\ia{StoRM Quality of Service and Data Lifecycle support through CDMI}{mw-cdmi-storm}
 %\ia{A low-cost platform for space software development}{lowcostdev}
-%\ia{Overview of Software Reliability literature}{srp}
+\ia{Comparing Data Mining Techniques for Software Defect Prediction}{dmsq}
 %\ia{Summary of a tutorial on statistical methods}{st}
 %\ia{Dynfarm: Transition to Production}{dynfarm}
 %\ia{Official testing and increased compatibility for Dataclient}{dataclient}
-\ia{Common software lifecycle management in external projects: Placeholder}{ds_devops_pe}
-\ia{EOSC-hub: Placeholder}{ds_eoschub}
+%\ia{Common software lifecycle management in external projects: Placeholder}{ds_devops_pe}
+%\ia{EOSC-hub: Placeholder}{ds_eoschub}
 \ia{EOSCpilot - Interoperability aspects and results}{ds_eoscpilot}
 \ia{Cloud@CNAF Management and Evolution}{ds_cloud_c}
 \ia{INFN CorporateCloud: Management and evolution}{ds_infn_cc}
@@ -225,7 +230,7 @@ Introducing the sixth annual report of CNAF...
 \addtocontents{toc}{\protect\mbox{}\protect\hrulefill\par}
 %\includepdf[pages=1, pagecommand={\thispagestyle{empty}}]{papers/transfer.pdf}
 \cleardoublepage
-%\ia{External projects and Technology transfer}{pett}
+\ia{External Projects and Technology Transfer}{pett}
 %\ia{The ISO 27001 Certification}{iso}
 %\ia{COmputing on SoC Architectures: the COSA project at CNAF}{cosa}
 %\ia{The ExaNeSt project - activities at CNAF}{exanest}
@@ -237,8 +242,8 @@ Introducing the sixth annual report of CNAF...
 \addtocontents{toc}{\protect\mbox{}\protect\hrulefill\par}
 %\includepdf[pages=1, pagecommand={\thispagestyle{empty}}]{papers/additional.pdf}
 \cleardoublepage
-
 \ia{Infrastructures and Big Data processing as pillars in the XXXIII PhD couse in Data Sciece and Computation}{PhD_DataScience_2018}
+\ia{The annual international conference of high performance computing: SC18 from INFN point of view}{sc18}
 
 \phantomsection
 \addcontentsline{toc}{chapter}{Organization}

contributions/HTC_testbed/HTC_testbed_AR2018.tex

+\documentclass[a4paper]{jpconf}
+\usepackage[english]{babel}
+% \usepackage{cite}
+\usepackage{biblatex}
+%\bibliographystyle{abnt-num}
+
+%%%%%%%%%% Start TeXmacs macros
+\newcommand{\tmtextit}[1]{{\itshape{#1}}}
+\newenvironment{itemizedot}{\begin{itemize} \renewcommand{\labelitemi}{$\bullet$}\renewcommand{\labelitemii}{$\bullet$}\renewcommand{\labelitemiii}{$\bullet$}\renewcommand{\labelitemiv}{$\bullet$}}{\end{itemize}}
+%%%%%%%%%% End TeXmacs macros
+
+\begin{document}
+
+\title{Evaluating Migration of INFN--T1 from CREAM-CE/LSF to
+HTCondor-CE/HTCondor}
+\author{Stefano Dal Pra$^1$}
+\address{$^1$ INFN-CNAF, viale Berti-Pichat 6/2, 40127 Bologna, Italy}
+\ead{stefano.dalpra@cnaf.infn.it}
+
+
+\begin{abstract}
+  The Tier--1 datacentre provides computing resources for a variety of HEP and
+  Astrophysics experiments, organized in Virtual Organization submitting their
+  jobs to our computing facilities through Computing Elements, acting as Grid
+  interfaces to the Local Resource Manager. We planned to phase--out our
+  current LRMS (IBM/Platform LSF 9.1.3) and CEs (CREAM) to adopt HTCondor as a
+  replacement of LSF and HTCondor--CE instead of CREAM. A small cluster has
+  been set up to practice the management and evaluate a migration plan to a
+  new LRMS and CE set. This document reports about our early experience on
+  this. 
+\end{abstract}
+
+\section{Introduction}
+
+The INFN-T1 currently provides a computing power of about 400KHS06, 35000
+slots on one thousand physical Worker Nodes. These resources are accessed
+through Grid by 24 Grid VOs and locally by 25 user groups.
+
+The IBM/Platform LSF 9.1.3 batch system arbitrate access to all the competing
+users groups, both Grid and local, according to a \tmtextit{fairshare} policy,
+designed to prevent underutilization of the available resources or starvation
+of lower priority groups, while ensuring a medium--term share proportional to
+configured quotas.
+
+The CREAM--CEs act as frontend for Grid users to the underlying LSF batch
+system, submitting their jobs on behalf of them. This setup has proven to be
+an effective solution for several years. However, the compatibility between
+CREAM and HTCondor seems to be less tight than with LSF. Moreover, active
+development of CREAM has recently ceased and thus we cannot expect new
+versions to be released, nor better HTCondor support to be implemented by an
+officiale development team. We decided to migrate our batch system solution
+from LSF to HTCondor, thus we need to also change our CEs. We have selected
+HTCondor-CE as a natural choice, because it is maintained by the same
+development team of HTCondor. Following we provide a report about our
+experience with HTCondor and HTCondor--CE.
+
+\section{The HTCondor cluster}
+
+To get acquainted with the new batch system and CEs, to evaluate how these can
+work together, how other components, such as monitoring, provisioning and
+accounting systems can be integrated with HTCondor and HTCondor--CE and
+finally to devise a reasonable migration plan, a simple small HTCondor 8.6.13
+cluster has been set up during spring 2018. A HTCondor--CE was soon added, in
+late April. HTCondor is a very mature opensource product, deployed at several
+major Tier-1 for years, thus we already know that it will certainly fit our
+use cases. The HTCondor--CE, on the other hand, is a more recent product, and
+a number of issues might be too problematic for us to deal with. Our focus is
+about ensuring that this CE implementation can be a viable solution for us.
+
+\subsection{The testbed}
+
+The test cluster consists of:
+\begin{itemizedot}
+  \item a HTCondor-CE on top of
+  
+  \item a HTCondor \ Central Manager and Collector
+  
+  \item 3 Worker Nodes (Compute Nodes, in HTCondor terms), 16 slot each.
+\end{itemizedot}
+
+\subsection{HTCondor--CE Installation and setup}
+
+The first CE installation was a bit tricky. The RPMs were available from OSG
+repositories only, meaning that a number of default settings and dependencies
+were unmet for EGI standards. Short after however, HTCondor--CE RPMs were made
+available on \ the same official repository of HTCondor.
+
+\subsubsection{Setup}
+
+To setup the configuration for the HTCondor and HTCondor--CE puppet modules
+are available. Unfortunately the puppet system at our site is not compatible
+with these modules as they depend on \tmtextit{hiera}, which is not supported
+at our site. These were later adapted to make them compatible with our
+configuration management system. In the meanwhile, the setup was finalized
+looking at the official documentation.
+
+\subsubsection{Configuration.}
+
+The first configuration was completed manually. The main documentation
+source for the HTCondor--CE is that of the OSG website~\cite{OSGDOC},
+which refers to a tool \tmtextit{osg-configure} not present on the
+general HTCondor--CE release.  Because of this the setup was completed
+by trial and error. Once a working setup was obtained, a set of
+integration notes were added to a public wiki~\cite{INFNWIKI}.  This
+should help other non OSG users to get some supplementary hint to
+complete their installation.
+
+\subsubsection{Accounting}
+
+As of 2018, the official EGI accounting tool, APEL~\cite{APEL}, has no support for
+HTCondor--CE. On the other hand, INFN--T1 has a custom accounting tool in
+place for several years now~\cite{DGAS}. Thus, it's all about finding a suitable way to
+retrieve from HTCondor the same information that we retrieve from CREAM--CE
+and LSF.
+
+A working way to do so has been by using python and the \tmtextit{python
+bindings}, a set of api interfaces to the HTCondor daemons. These can be used
+to query the SCHEDD at the CE and retrieve a specified set of data\quad about
+recently finished jobs, which are subsequently inserted to our local
+accounting database. A noticeable fact to note, is that the grid information
+(User DN, VO, etc.) are directly available together with all the needed
+accounting data. This simplifies the accounting problem, as it is no more
+necessary to collect grid data separately from the BLAH component and then
+look for matches with the corresponding grid counterpart.
+
+This solution have been used during the 2018 to provide accounting for
+HTCondor--CE testbed cluster.
+
+\subsection{Running HTCondor--CE}
+
+After some time to become confident with the main configuration tasks the
+testbed begun working with jobs submitted by the 4 LHC experiments from
+September 2018. The system proved to be stable and smooth, being able to work
+unattended. This confirms that this system can be a reliable substitute for
+CREAM--CE and LSF.
+
+\subsection{Running HTCondor}
+
+The HTCondor batch system is a mature product with a large user base. We have
+put less effort at investigating it deeply. We already know that most or all
+of needed features will work well. Rather, some effort have been put on
+dealing with configuration management.
+
+\subsubsection{Configuration management}
+
+Eventhoutgh a standard base of puppet classes have been adapted to our
+management system, an additional python tool have been written to improve
+flexibility and readiness. The tool works by reading and enforcing on each
+node of the cluster a set of configuration directives written on text files
+accessible from a shared filesystem. The actual set and the read order depends
+on the host role and name. Doing so, a large cluster can be quite easily
+managed as a collection of set of host sets. The tool is quite simple and
+limited but it can be improved as needed when more complex requirements should
+arise.
+
+\subsection{The migration plan}
+
+After using the testbed cluster a possible plan for a smooth migration have
+been devised:
+\begin{itemizedot}
+  \item Install and setup a new HTCondor cluster, with a few more HTCondor--CE
+  and an initial small set of Worker Nodes
+  \item Enable the LHC VOs on the new cluster
+  \item Add more WN to the new cluster gradually
+  \item Enable other Grid VOs
+  \item Finally, enable submission from local submissions. These are made from
+  a heterogenous set of users, with a potentially rich set of individual needs
+  and can require a considerable administrative effort to meet all of them.
+\end{itemizedot}
+
+\subsection{Conclusion}
+
+A testbed cluster based on HTCondor--CE on top of HTCondor batch system has
+been deployed to evaluate these as a substitute for CREAM--CE and LSF. The
+evaluation as mostly focused on the HTCondor--CE, as it is the most recent
+product. Apart for a few minor issues, mainly related to gaps in the available
+documentation, The CE proved to be a stable component. the possibility to
+perform accounting has been verified.
+
+Using the described testbed we have
+
+\section*{References}
+\begin{thebibliography}{9}
+\bibitem{OSGDOC} \url{https://opensciencegrid.org/docs/compute-element/install-htcondor-ce/}
+\bibitem{INFNWIKI} \url{http://wiki.infn.it/progetti/htcondor-tf/htcondor-ce_setup}
+
+\bibitem{DGAS} S. Dal Pra, ``Accounting Data Recovery. A Case Report from
+  INFN-T1'' Nota interna, Commissione Calcolo e Reti dell'INFN, {\tt CCR-48/2014/P}
+\bibitem{APEL} \url{https://wiki.egi.eu/wiki/APEL}
+\end{thebibliography}
+
+\end{document}

contributions/atlas/atlas.tex

+\documentclass[a4paper]{jpconf}
+\usepackage{graphicx}
+\begin{document}
+\title{The ATLAS Experiment at the INFN CNAF Tier-1}
+
+\author{Alessandro De Salvo$^1$,  Lorenzo Rinaldi$^2$}
+
+\address{$^1$ INFN Sezione di Roma-1, piazzale Aldo Moro 2, 00185 Roma, Italy,\\ $^2$ Universit\`a di Bologna e INFN, via Irnerio 46, 40126 Bologna, Italy}
+
+\ead{alessandro.desalvo@roma1.infn.it, lorenzo.rinaldi@bo.infn.it}
+
+\begin{abstract}
+The ATLAS experiment at LHC was fully operating in 2017. In this contribution we describe the ATLAS computing activities performed in the Italian sites of the Collaboration, and in particular the utilisation of the CNAF Tier-1.
+\end{abstract}
+
+\section{Introduction}
+
+   
+ATLAS \cite{ATLAS-det} is one of two general-purpose detectors at the Large Hadron Collider (LHC). It investigates a wide range of physics, from the search for the Higgs boson and standard model studies to extra dimensions and particles that could make up dark matter. Beams of particles from the LHC collide at the centre of the ATLAS detector making collision debris in the form of new particles, which fly out from the collision point in all directions. Six different detecting subsystems arranged in layers around the collision point record the paths, momentum, and energy of the particles, allowing them to be individually identified. A huge magnet system bends the paths of charged particles so that their momenta can be measured. The interactions in the ATLAS detectors create an enormous flow of data. To digest the data, ATLAS uses an advanced trigger system to tell the detector which events to record and which to ignore. Complex data-acquisition and computing systems are then used to analyse the collision events recorded. At 46 m long, 25 m high and 25 m wide, the 7000-tons ATLAS detector is the largest volume particle detector ever built. It sits in a cavern 100 m below ground near the main CERN site, close to the village of Meyrin in Switzerland.
+More than 3000 scientists from 174 institutes in 38 countries work on the ATLAS experiment.
+ATLAS has been taking data from 2010 to 2012, at center of mass energies of 7 and 8 TeV, collecting about 5 and 20 fb$^{-1}$ of integrated luminosity, respectively. During the complete Run-2 phase (2015-2018) ATLAS collected and registered at the Tier-0 147 fb$^{-1}$ of integrated luminosity at center of mass energies of 13 TeV.
+The experiment has been designed to look for New Physics over a very large set of final states and signatures, and for precision measurements of known Standard Model (SM) processes. Its most notable result up to now has been the discovery of a new resonance at a mass of about 125 GeV \cite{ATLAS higgs}, followed by the measurement of its properties (mass, production cross sections in various channels and couplings). These measurements have confirmed the compatibility of the new resonance with the Higgs boson, foreseen by the SM but never observed before.
+
+
+
+\section{The ATLAS Computing System}
+
+ 
+ 
+ The ATLAS Computing System \cite{ATLAS-cm} is responsible for the provision of the software framework and services, the data management system, user-support services, and the world-wide data access and job-submission system. The development of detector-specific algorithmic code for simulation, calibration, alignment, trigger and reconstruction is under the responsibility of the detector projects, but the Software and Computing Project plans and coordinates these activities across detector boundaries. In particular, a significant effort has been made to ensure that relevant parts of the “offline” framework and event-reconstruction code can be used in the High Level Trigger. Similarly, close cooperation with Physics Coordination and the Combined Performance groups ensures the smooth development of global event-reconstruction code and of software tools for physics analysis.
+
+\subsection{The ATLAS Computing Model}
+The ATLAS Computing Model embraces the Grid paradigm and a high degree of decentralisation and sharing of computing resources. The required level of computing resources means that off-site facilities are vital to the operation of ATLAS in a way that was not the case for previous CERN-based experiments. The primary event processing occurs at CERN in a Tier-0 Facility. The RAW data is archived at CERN and copied (along with the primary processed data) to the Tier-1 facilities around the world. These facilities archive the raw data, provide the reprocessing capacity, provide access to the various processed versions, and allow scheduled analysis of the processed data by physics analysis groups. Derived datasets produced by the physics groups are copied to the Tier-2 facilities for further analysis. The Tier-2 facilities also provide the simulation capacity for the experiment, with the simulated data housed at Tier-1s. In addition, Tier-2 centres provide analysis facilities, and some provide the capacity to produce calibrations based on processing raw data. A CERN Analysis Facility provides an additional analysis capacity, with an important role in the calibration and algorithmic development work. ATLAS has adopted an object-oriented approach to software, based primarily on the C++ programming language, but with some components implemented using FORTRAN and Java. A component-based model has been adopted, whereby applications are built up from collections of plug-compatible components based on a variety of configuration files. This capability is supported by a common framework that provides common data-processing support. This approach results in great flexibility in meeting both the basic processing needs of the experiment, but also for responding to changing requirements throughout its lifetime. The heavy use of abstract interfaces allows for different implementations to be provided, supporting different persistency technologies, or optimized for the offline or high-level trigger environments.
+The Athena framework is an enhanced version of the Gaudi framework that was originally developed by the LHCb experiment, but is now a common ATLAS-LHCb project. Major
+design principles are the clear separation of data and algorithms, and between transient (in-memory) and persistent (in-file) data. All levels of processing of ATLAS data, from high-level trigger to event simulation, reconstruction and analysis, take place within the Athena framework; in this way it is easier for code developers and users to test and run algorithmic code, with the assurance that all geometry and conditions data will be the same for all types of applications ( simulation, reconstruction, analysis, visualization).
+One of the principal challenges for ATLAS computing is to develop and operate a data storage and management infrastructure able to meet the demands of a yearly data volume of O(10PB) utilized by data processing and analysis activities spread around the world.  The ATLAS Computing Model establishes the environment and operational requirements that ATLAS data-handling systems must support and provides the primary guidance for the development of the data management systems.
+The ATLAS Databases and Data Management Project (DB Project) leads and coordinates ATLAS activities in these areas, with a scope encompassing technical data bases (detector production, installation and survey data), detector geometry, online/TDAQ databases, conditions databases (online and offline), event data, offline processing configuration and bookkeeping, distributed data management, and distributed database and data management services. The project is responsible for ensuring the coherent development, integration and operational capability of the distributed database and data management software and infrastructure for ATLAS across these areas.
+The ATLAS Computing Model defines the distribution of raw and processed data to Tier-1 and Tier-2 centres, so as to be able to exploit fully the computing resources that are made available to the Collaboration. Additional computing resources are available for data processing and analysis at Tier-3 centres and other computing facilities to which ATLAS may have access. A complex set of tools and distributed services, enabling the automatic distribution and processing of the large amounts of data, has been developed and deployed by ATLAS in cooperation with the LHC Computing Grid (LCG) Project and with the middleware providers of the three large Grid infrastructures we use: EGI, OSG and NorduGrid. The tools are designed in a flexible way, in order to have the possibility to extend them to use other types of Grid middleware in the future.
+The main computing operations that ATLAS have to run comprise the preparation, distribution and validation of ATLAS software, and the computing and data management operations run centrally on Tier-0, Tier-1s and Tier-2s. The ATLAS Virtual Organization allows production and analysis users to run jobs and access data at remote sites using the ATLAS-developed Grid tools.
+The Computing Model, together with the knowledge of the resources needed to store and process each ATLAS event, gives rise to estimates of required resources that can be used to design and set up the various facilities. It is not assumed that all Tier-1s or Tier-2s are of the same size; however, in order to ensure a smooth operation of the Computing Model, all Tier-1s usually have broadly similar proportions of disk, tape and CPU, and similarly for the Tier-2s.
+The organization of the ATLAS Software and Computing Project reflects all areas of activity within the project itself. Strong high-level links are established with other parts of the ATLAS organization, such as the TDAQ Project and Physics Coordination, through cross-representation in the respective steering boards. The Computing Management
+Board, and in particular the Planning Officer, acts to make sure that software and computing developments take place coherently across sub-systems and that the project as a whole meets its milestones. The International Computing Board assures the information flow between the ATLAS Software and Computing Project and the national resources and their Funding Agencies.
+
+
+
+\section{The role of the Italian Computing facilities in the global ATLAS Computing}
+
+Italy provides Tier-1, Tier-2 and Tier-3 facilities to the ATLAS collaboration. The Tier-1, located at CNAF, Bologna, is the main centre, also referred as “regional” centre. The Tier-2 centres are distributed in different areas of Italy, namely in Frascati, Napoli, Milano and Roma. All 4 Tier-2 sites are considered as Direct Tier-2 (T2D), meaning that they have an higher importance with respect to normal Tier-2s and can have primary data too. They are also considered satellites of the Tier-1, also identified as nucleus. The total of the Tier-2 sites corresponds to more than the total ATLAS size at the Tier-1, for what concerns disk and CPUs; tape is not available in the Tier-2 sites. A third category of sites is the so-called Tier-3 centres. Those are smaller centres, scattered in different places in Italy, that nevertheless contributes in a consistent way to the overall computing power, in terms of disk and CPUs. The overall size of the Tier-3 sites corresponds roughly to the size of a Tier-2 site. The Tier-1 and Tier-2 sites have pledged resources, while the Tier-3 sites do not have any pledge resource available.
+In terms of pledged resources, Italy contributes to the ATLAS computing as 9\% of both CPU and disk for the Tier-1. The share of the Tier-2 facilities corresponds to 7\% of disk and 9\% of CPU of the whole ATLAS computing infrastructure. The Italian Tier-1, together with the other Italian centres, provides both resources and expertise to the ATLAS computing community, and manages the so-called Italian Cloud of computing. Since 2015 the Italian Cloud does not only include Italian sites, but also Tier-3 sites of other countries, namely South Africa and Greece.
+The computing resources, in terms of disk, tape and CPU, available in the Tier-1 at CNAF have been very important for all kind of activities, including event generation, simulation, reconstruction, reprocessing and analysis, for both MonteCarlo and real data. Its major contribution has been the data reprocessing, since this is a very I/O and memory intense operation, normally executed only in Tier-1 centres. In this sense CNAF has played a fundamental role for the fine measurement of the Higgs [3] properties in 2018 and other analysis. The Italian centres, including CNAF, have been very active not only in the operation side, but contributed a lot in various aspect of the Computing of the ATLAS experiment, in particular for what concerns the network, the storage systems, the storage federations and the monitoring tools. The Tier-1 at CNAF has been very important for the ATLAS community in 2018, for some specific activities:
+
+\begin{itemize}
+\item improvements on the WebDAV/HTTPS access for StoRM, in order to be used as main renaming method for the ATLAS files in StoRM and for http federation purposes;
+\item improvements of the dynamic model of the multi-core resources operated via the LSF resource management system and simplification of the PanDA queues, using the Harvester service to mediate the control and information flow between PanDA and the resources.
+\item network troubleshooting via the Perfsonar-PS network monitoring system, used for the LHCONE overlay network, together with the other Tier-1 and Tier-2 sites;
+\item planning, readiness testing and implementation of the HTCondor batch system for the farming resources management.
+\end{itemize}
+
+\section{Main achievements of ATLAS Computing centers in Italy}
+
+The Italian Tier-2 Federation runs all the ATLAS computing activities in the Italian cloud supporting the operations at CNAF, the Italian Tier-1 centre, and the Milano, Napoli, Roma1 and Frascati Tier-2 sites. This insures an optimized use of the resources and a fair and efficient data access.  The computing activities of the ATLAS collaboration have been constantly carried out over the whole 2018, in order to analyse the data of the Run-2 and produce the Monte Carlo data needed for the 2018 run.
+ 
+The LHC data taking started in April 2018 and, until the end of the operation in December 2018, all the Italian sites, the CNAF Tier-1 and the four Tier-2s, have been involved in all the computing operations of the collaboration: data reconstruction, Monte Carlo simulation, user and group analysis and data transfer among all the sites. Besides these activities, the Italian centers have contributed to the upgrade of the Computing Model both from the testing side and the development of specific working groups. ATLAS collected and registered at the Tier-0 ~60.6 fb$^{-1}$ and ~25 PB of raw and derived data, while the cumulative data volume distributed in all the data centers in the grid was of the order of ~80 PB. The data has been replicated with an efficiency of 100\% and an average throughput of the order of ~13 GB/s during the data taking period, with peaks above 25 GB/s. For just Italy, the average throughput was of the order of 800 MB/s with peaks above 2GB/s. The data replication speed from Tier-0 to the Tier-2s has been quite fast with a transfer time lower than 4 hours. The average number of simultaneous jobs running on the grid has been of about 110k for production (simulation and reconstruction) and data analysis, with peaks over 150k, with an average CPU efficiency up to more than 80\%. The use of the grid for analysis has been stable on ~26k simultaneous jobs, with peaks around the conferences’ periods to over 40k, showing the reliability and effectiveness of the use of grid tools for data analysis.
+ 
+The Italian sites contributed to the development of the Xrootd and http/webdav federation. In the latter case the access to the storage resources is managed using the http/webdav protocol, in collaboration with the CERN DPM team, the Belle2 experiment, the Canadian Corporate Cloud ant the RAL (UK) site. The purpose is to build a reliable storage federation, alternative to the Xrootd one, to access physics data both on the grid and on cloud storage infrastructures (like Amazon S3, MicroSoft Azure, etc). The Italian community is particularly involved in this project and the first results have been presented to the WLCG collaboration.
+ 
+The Italian community also contributes to develop new tools for distributed data analysis and management. Another topic of interest is the usage of new computing technologies: in this field the Italian community contributed to the development and testing of muon tracking algorithms in the ATLAS High Level Trigger, using GPGPU. Other topics in which the Italian community is involved are the Machine Learning/Deep Learning for both analysis and Operational Intelligence and their applications to the experiment software and infrastructure, by using accelerators like GPGPU and FPGAs.
+ 
+The contribution of the Italian sites to the computing activities in terms of processed jobs and data recorded has been of about 9\%, corresponding to the order of the resource pledged to the collaboration, with very good performance in term of availability, reliability and efficiency. All the sites are always in the top positions in the ranking of the collaboration sites.
+ 
+Besides the Tier-1 and Tier-2s, in 2018 also the Tier-3s gave a significant contribution to the Italian physicists community for the data analysis. The Tier-3s are local farms dedicated to the interactive data analysis, the last step of the analysis workflow, and to the grid analysis over small data sample. Several italian groups set up a farm for such a purpose in their universities and, after a testing and validation process performed by the distributed computing team of the collaboration, all have been recognized as official Tier-3s of the collaboration.
+
+
+
+\section{Impact of CNAF flooding incident on ATLAS computing activities}
+
+
+
+The ATLAS Computing Model was designed to have a sufficient redundancy of the available resources in order to tackle emergency situations like the flooding occurred on November 9th 2017 at CNAF.  Thanks to the huge effort of the whole community of the CNAF,  the operativity of the data centre restarted gradually from the second half of February 2018. A continuous interaction between ATLAS distributed computing community and CNAF people was needed to bring the computing operation fully back to normality. The deep collaboration was very successful and after one month the site was almost fully operational and the ATLAS data management and processing activities were running smoothly again. Eventually, the overall impact of the incident was limited enough, mainly thanks to the relatively quick recovery of the CNAF data center and to the robustness of the computing model.
+
+
+
+
+
+\section*{References}
+\begin{thebibliography}{9}
+
+\bibitem{ATLAS-det} The ATLAS Computing Technical Design Report ATLAS-TDR-017;
+CERN-LHCC-2005-022, June 2005
+
+\bibitem{ATLAS higgs} Observation of a new particle in the search for the Standard Model Higgs boson with the ATLAS detector at the LHC, the ATLAS Collaboration, Physics Letters B, Volume 716, Issue 1, 17 September 2012, Pages 1–29
+
+\bibitem{ATLAS-cm} The evolution of the ATLAS computing model; R W L Jones and D Barberis 2010 J. Phys.: Conf. Ser. 219 072037 doi:10.1088/1742-6596/219/7/072037
+
+
+
+
+
+
+\end{thebibliography}
+
+\end{document}
+
+
+
+
+
+

contributions/audit/Audit-2018.tex

+\documentclass[a4paper]{jpconf}
+\bibliographystyle{iopart-num}
+
+\begin{document}
+\title{Internal Auditing INFN for GDPR compliance}
+\author{V.~Ciaschini, P.~Belluomo}
+\address{INFN CNAF, Viale Berti Pichat 6/2, 40127, Bologna, Italy}
+\address{INFN sezione di Catania, Via Santa Sofia 64, 95123, Catania, Italy}
+
+\begin{abstract}
+With the General Data Protection Regulation (GDPR) coming into
+force, INFN had to decide how to implement its principles and
+requirements.  To monitor their application and in general INFN's
+compliance with GDPR, INFN created a new group, called ``Compliance
+Auditing,'' whose job is to be internal auditors for all structures.
+This article describes the startup activity for the group.
+\end{abstract}
+
+\section{Compliance Auditing Group}
+\subsection{Rationale for creation}
+When discussing GDPR application during the Commissione Calcolo e Reti
+(CCR) 2018 workshop in Rimini, it became clear that setting up
+a set of rules and assuming that all parts of INFN would correctly
+follow them was not, by itself, enough.  Indeed it was necessary to
+comply with the duty of vigilance, which in turn required periodic
+checkups.
+
+To counteract this worries, and to vigilate on its proper application,
+it was soon proposed to create a team which would take the
+name of ``compliance auditors,'' whose job was to act as internal
+auditors for all of INFN structures to check on the proper
+application of the regulations as implemented by INFN.
+
+
+\subsection{Startup Activity}
+Following the proposal of the group creation, the first task to solve
+was how to staff it.  Two people, who had previous experience with the
+setup of ISO compliance structures for some of INFN sections
+volunteered, Patrizia Belluomo (Lead auditor, Sezione di Catania) and
+Vincenzo Ciaschini (CNAF).
+
+The first activity undertaken by the group was a collection, followed
+by the study of all the norms applicable to INFN's implementation of
+GDPR, like the text of the normative itself, other applicable Italian
+legislation, the documents describing INFN's implementation, and
+several INFN regulations that, while not specifically talking about
+GDPR, still governed issues that were related to it, e.g data
+retention policies.
+
+We also had to decide how to structure the audits.  We decided to
+implement it according to well-known quality assurance principles.  To
+apply these principles, we ended up deciding on a set of arguments
+that would be investigated during the audits, and a set of questions
+that could, but not necessarily would, be asked during the audits
+themselves, to act as a set of guidelines and to permit INFN
+structures to prepare properly.
+
+When the group was formally approved, these procedures were
+presented at the CCR workshop in Pisa in October, and an indicative
+calendar for the audits created and sent to the structures as a
+proposal on when they would be audited.
+
+Due to budget limitations, it was also decided that, at least for the
+first year, most of the audits would be done by telepresence, with
+on-site audits reserved for the sections that had, or would have, the
+most critical data, i.e: the structures that hosted or would host
+INFN's Sistema Informativo.
+
+The rest of the year was devoted to refine this organization and
+prepare the formal documentation that would be the output of the
+audits and the procedures that we would follow during the audits,
+which began in earnest in 9 January 2019, but that would be out of
+scope for 2018's Annual Report. 
+\end{document}