- Indico style
- Indico style - inline minutes
- Indico style - numbered
- Indico style - numbered + minutes
- Indico Weeks View
Il modulo web di registrazione dell'identità digitale sarà l'interfaccia con la quale il nostro ente inizierà la fase di riconoscimento e accreditamento di una nuova identità, mentre un portale web permetterà ad identità già registrate di accedere a una serie di servizi: modificare le informazioni del proprio profilo, richiedere l'ospitalità, richiedere accesso al territorio, richiedere accesso a risorse informatiche e altro.
Nella presentazione saranno illustrati i flussi logici e le tecnologie coinvolte per la realizzazione e l’implementazione.
Sui nostri server di posta le mail degli utenti sono memorizzate su storage hard drive e tipicamente successivamente con backup su nastro. Questo espone potenzialmente a rischi di violazione della confidenzialita' delle mail dal momento che sono memorizzate in chiaro su supporto magnetico e in piu' di una locazione fisica diversa. Nel nostro ente sono gia' successi in passato incidenti che hanno esposto informazioni confidenziali presenti in mail personali. La tecnologia da me adottata non consente a nessuno di potere accedere alle mail in chiaro, nemmeno ai sistemisti che gestiscono il server di posta. Il valore aggiunto di questa tecnologia e' che non e' necessario che il mittente cripti volutamente la mail perche' questa sia cifrata su dico, dal momento che il server stesso effettua questa operazione per default. Un servizio di posta di questo tipo potrebbe essere concepito come servizio centralizzato di mail con un importante valore di sicurezza aggiunto per amministrazioni che hanno dati particolaremnte sensibili come la Presidenza INFN oppure AC, o in generale per tutte le amministrazioni INFN
Da un anno circa si effettuano presso i LNGS le scansioni di sicurezza con OpenVAS su tutte le macchine della rete locale: PC desktop e portatili degli utenti, macchine gestite dagli esperimenti e macchine del servizio calcolo e reti.
Ogni vulnerabilita' rilevata e' comunicata all'amministratore della macchina che, spesso, chiede il supporto al Servizio stesso per la risoluzione del problema.
Si vogliono presentare dei dati statistici sui risultati delle scansioni: quante macchine sono state scansionate per ciascuna tipologia, quante di queste hanno presentato vulnerabilita' gravi, medie o leggere, e quali sono le
vulnerabilita' piu' frequenti; quanto cambiano i risultati se si utilizzano metodi diversi per le scansioni; quanti utenti hanno risposto alla richiesta di correzione delle vulnerabilita'; quante vulnerabilita' sono state effettivamente corrette e quante nuove vulnerabilita' sono emerse tra una scansione e la successiva...
Infine, quanto impegno e' richiesto al Servizio calcolo per organizzare le scansioni e gestire l'interazione con gli utenti.
In questa presentazione vorrei coprire diversi aspetti del mondo microsoft.
In dettaglio:
- questioni legati al licensing dei prodotti, sia sistemi operativi che office, contratti open
- vorrei aggiornare sullo stato di office 365 e di alcuni strumenti in particolare che reputo interessanti quali microsoft teams per gestire il lavoro di gruppo
- vorrei poi parlare di strumenti evoluti per installazione e gestione dei software piu' comuni installati dagli utenti.
Un cavo a 100 fibre ottiche e' il mezzo trasmissivo tra laboratori esterni e sotterranei dei LNGS. Questo cavo, che costituisce un'infrastruttura essenziale per la rete LAN e gli esperimenti dei LNGS e' stato posato negli anni '80 e inizia a mostrare segni di invecchiamento. Tale cavo e' posato lungo uno dei due tunnel autostradali del traforo del Gran Sasso e risulta quindi potenzialmente vulnerabile in caso di incidente grave. La posa di un nuovo cavo di collegamento e' stata inserita, su richiesta del Servizio Calcolo e Reti dei LNGS, nel PON infrastrutture FARO2030 ed e' stata di recente finanziata.
Il nuovo cavo multifibra, che sara' lungo circa 8Km, sara' installato nell'altro tunnel autostradale e seguira' quindi un percorso completamente differente rispetto al cavo attuale. La nuova infrastruttura di rete garantira' la connettivita' tra i due siti nei prossimi decenni e, operando in ridondanza rispetto a quella attuale, consentira' di realizzare soluzioni tecnologiche avanzate per aumentare l'affidabilita' dei servizi di rete dei LNGS.
Il DG INFN ha incaricato un gruppo di lavoro di preparare la documentazione per una gara INFN al fine di centralizzare l'acquisto di pc portatili e desktop, con lo scopo di evitare i prodotti di solito presenti nelle convenzioni consip, mai in grado di soddisfare le necessita' dei dipendenti INFN.
In questa (breve) presentazione si vuole mostrare il risultato di questo lavoro e preparare i responsabili calcolo a cioche comportera
in futuro per gli acquisti di questo tipo di materiale
INFN Corporate Cloud (INFN CC) è una piattaforma cloud dedicata alla comunità INFN. Basata su OpenStack, la piattaforma è distribuita geograficamente su tre sedi INFN (Bari, CNAF, LNF), con i servizi fondamentali ridondati in modo da garantire la loro continuità e la tolleranza ai singoli malfunzionamenti locali.
Ciascuno dei siti infatti espone gli endpoint dei servizi pubblici attraverso un LoadBalancer, che indirizza il traffico sui servizi locali, usando gli endpoint remoti solo come backup in caso di fallimenti. Tuttavia, questo meccanismo non è sufficiente nel caso di irraggiungibilità di un intero sito. Per gestire questa situazione è stata progettata una soluzione basata su un servizio DNS, anch'esso ridondato tra le tre sedi, associato un servizio di monitoring proattivo basato su Zabbix. Nel caso in cui si verifichino fallimenti dei servizi core, questa soluzione provvede alla correzione dinamica delle informazioni nel DNS, prevenendo la ricerca di una risorsa irraggiungibile da parte di un client.
Il servizio DNS è implementato attraverso PowerDNS, scelto per la possibilità di avere un database SQL come backend. Per il backend del DNS è stato realizzato un cluster basato su Percona Server, soluzione che supporta nativamente la ridondanza geografica. PowerDNS implementa inoltre un’interfaccia web con API REST, usata estensivamente per realizzare un client customizzato per poter sfruttare funzionalità quali l’aggiornamento di un recordset, la disabilitazione di un record o l’inserimento di commenti, opzioni importanti dal punto di vista di INFN-CC ma non presenti nel client rilasciato con PowerDNS. Ad esempio, quando il check di monitoring rileva che una risorsa non è disponibile, l’indirizzo IP corrispondente viene disabilitato, rendendolo irrisolvibile da un client. Contestualmente viene inserito un commento che viene conservato nel server PowerDNS. Questo commento torna utile sia per avere un riscontro delle operazioni effettuate sul record, sia per l’eventuale riabilitazione dell’indirizzo IP, poichè per evitare conflitti con eventuali operazioni di manutenzione programmata, il check riabilita automaticamente una entry solo se era stata disabilitata dal sistema di monitoring.
Una panoramica completa delle opzioni implementate e del loro utilizzo verrà mostrata nella presentazione, mostrando come questa soluzione di fault tolerance basato su monitoring e aggiornamento dinamico del DNS può essere generalizzato anche per esigenze di alta affidabilità non necessariamente legate ad infrastrutture cloud, fornendo uno strumento semplice ma efficace per il failover di risorse ridondate geograficamente.
INFN-Pisa sin dalla sua nascita come sito GRID ha esplorato la strada per disaccoppiare le esigenze amministrative dei nodi di calcolo da quelle computazionali derivanti dal framework applicativo dell'utente.
Questo approccio si è reso necessario sostanzialmente per due motivi:
- risorse HW in comune fra ambienti fortemente diversi quali il mondo GRID e quello HPC in virtù delle collaborazioni con partner tecnologi prima (AMD) istituzionali poi (Dip. Ingegneria Aerospaziale di UniPi)
- grande eterogeneità delle risorse HW data dalla alternanza di varie generazioni di Farm e Cluster
Per evitare il costo in termini computazionali di tecnologie di virtualizzazione negli anni sono state messe in campo varie soluzioni di virtualizzazione leggera. In un primo momento utilizzando soluzioni completamente fatte in casa basate su chroot. Sostituite poi con docker non appena questo nuovo strumento si è affacciato sulla scena. L'approccio è stato quello di utilizzare questi due "strumenti" per simulare una macchina virtuale all'interno della quale mettere l'ambiente operativo dell'utente. Utilizzando questo meccanismo nel 2016 l'intero parco computazionale di INFN-Pisa (HTC e HPC) era gestito attraverso container docker.
Nonostante l'estrema flessibilità offerta da docker si aveva comunque una corrispondenza rigida 1:1 fra il "bare metal" è l'ambiente visto dal job utente (Worker Node/Job Slot). Questo sostanzialmente dovuto al fatto che il demone LSF gira all'interno del container.
Nel 2017 si è iniziata una attività di R&D per superare tale vincolo con l'idea di muovere l'infrastruttura in un'ottica di tipo cloud. L'idea fondamentale si poggia su i seguenti punti:
La prima implementazione del nuovo paradigma è stata messa in produzione nell'estate del 2017 per le risorse della Farm di Analisi Interattiva (FAI), permettendo di scegliere all'utente se lavorare in ambiente Scientific Linux 6 o CentOS 7.
Ad oggi l'approccio è stato esteso a tutte le risorse HTC incluse le risorse GRID permettendo di far coesistere sulla solita infrastruttura job (grid) che utilizzando CentOS7 (CMS) con quelli che usano SL6.
Il passo successivo consiste nell'estendere questo approccio alla parte HPC permettendo un utilizzo elastico delle risorse e di fatto eliminando la distinzione fra le due tipologie di infrastruttura.
La soluzione implementata si basa su configurazioni standard di LSF (nel nostro caso usiamo la versione 7 update 6) e quindi risulta del tutto trasparente all'utenza incluso il MW grid.
ISOLPHARM is an INFN patented methodology for the production of high specific activity radionuclides by means of the ISOL technique at the SPES facility of INFN-LNL laboratory. In the context of the ISOLPHARM collaboration, ISOLPHARM_Ag is a two-year INFN activity to study and demonstrate, as a proof of principle, the production and use of a particularly promising silver isotope (111Ag). The radionuclides of 111Ag would then allow the study of their possible application as a radiopharmaceutical precursor. To predict the production and release of 111Ag from the ISOLPHARM primary target, the execution of a set of specific MonteCarlo simulations is needed.
We present the advanced Cloud-based computing infrastructure that was designed and implemented to allow users to submit their FLUKA and Geant4 based simulation jobs on Cloud (in particular the CloudVeneto infrastructure) and then collect the produced data.
This is a generic MonteCarlo environment that enhances the simulation's execution by parallelizing its code. Our solution fully takes advantage of the Kubernetes (K8S) capabilities achieving the required level of flexibility and control by implementing a specific K8S operator.
While presenting the ISOLPHARM_Ag computing architecture, we will focus on how we implemented the K8S operator to provide a common mechanism to parallelize FLUKA and Geant4 simulations on Cloud.
L'esperimento PADME (Positron Annihilation into Dark Matter Experiment), installato presso la Beam Test Facility dell'anello DAFNE ai Laboratori Nazionali di Frascati dell'INFN, è pensato per individuare la presenza di fotoni oscuri prodotti nelle annichilazioni di positroni su bersaglio fisso secondo il processo e+e- → γA' misurando la massa mancante dello stato finale. La prima fase di presa dati dell’esperimento è iniziata il 4 ottobre 2018 e si è conclusa a fine febbraio 2019 avendo raccolto circa 5x10^12 interazioni di positrone su bersaglio, per un totale di 280 TB di dati “raw”. Per tenere sotto controllo in tempo reale lo stato del sistema di acquisizione dati e la qualità degli eventi raccolti è stato sviluppato un sistema di monitor on-line interamente scritto in JavaScript e diviso in due parti: un server, che utilizza una serie di template per organizzare i dati provenienti dal sistema di DAQ in pagine suddivise in semplici tabelle numeriche, e un client, eseguito su un generico browser web, che riceve in maniera selettiva e asincrona dal server le pagine e ne crea una rappresentazione grafica utilizzando la libreria grafica Plotly. I vantaggi del sistema sono da una parte l’estrema semplicità nella configurazione del server per l’aggiunta di nuove pagine e/o tabelle, dall’altra il fatto che la presentazione grafica è interamente demandata al client, cosa che consente al sistema di funzionare anche in presenza di numerosi client distribuiti geograficamente. Questa presentazione descriverà i dettagli tecnici del sistema di monitor evidenziandone i punti di forza e i possibili sviluppi.
The XENON project is dedicated to the direct search of dark matter at LNGS.
XENON1T was the largest double-phase TPC ever built and operated so far, with 2 t of active xenon, decommissioned in December 2018. In the context of rare event search detectors, the amount of data (in the form of raw waveform) was significant: order of 1 PB/year, including both Science and Calibration runs. The next phase of the experiment, XENONnT, is under construction at LNGS, with a 3 times larger TPC and correspondingly increased data rate. Its commissioning is expected by the end of 2019.
We describe the computing model of the XENON experiments, with details of the data transfer and management, the massive raw data processing, and the production of Monte Carlo simulation.
All these topics are addressed using in the most efficient way the computing resources spread mainly in the US and EU, thanks to the OSG and EGI facilities, including those available at CNAF.
The Jiangmen Underground Neutrino Observatory (JUNO) is a 20 kton multi-purpose underground neutrino detector which was proposed in order to determine, as its primary goal, the neutrino mass hierarchy. The large fiducial volume, together with the excellent energy resolution foreseen, would allow to perform also a series of important measurements in the field of neutrinos and astro-particle physics.
To address the mass hierarchy issue, the JUNO detector will be surrounded by a cluster of nuclear power plants at a distance of around 50 km. The resulting reactor antineutrino flux gives the possibility to determine the neutrino mass hierarchy with a significance level of 3-4$\sigma$, with six years of running JUNO. The measurement of the antineutrino spectrum with excellent energy resolution will lead also to a precise determination of the solar neutrino oscillation parameters, $sin^2 \theta_{12}$ and $\Delta m^2_{21}$, with an accuracy below 1\%.
The JUNO characteristics make it a suitable detector not only for neutrinos coming from the power plants, but also for neutrinos generated inside the Sun, or during supernovae explosions, or even in the Eart's crust and atmosphere. Other topics of interest potentially accessible to JUNO include the search for sterile neutrinos, proton decay and dark matter annihilation.
Data taking is expected to start in 2021.
In this paper the computing model is discussed taking into account different choices. The computing resources for the simulations have been evaluated, together with the resources needed for the data management.
The ALICE Experiment has been designed to study the physics of strongly interacting matter and the Quark–Gluon Plasma with heavy-ion collisions at the CERN LHC. A major upgrade of the ALICE detectors and computing farm is currently ongoing. The new farm, within the O2 (Offline-Online) computing project, will consist of almost 2000 nodes enabled to readout and process on-the-fly over 27 Tb/s of raw data.
To increase the efficiency of computing farm operations a general purpose real time streaming processing system has been developed. The system had been designed to lay on features like high-performance, high-availability, modularity and open source. Its core component is represented by Apache Kafka that ensures high throughput, data pipelines and fault tolerance services. A monitoring task, in addition to Kafka, uses Telegraf as a metric collector, Apache Spark for complex aggregation, InfluxDB as a time-series database and Grafana as visualization tool. A logging tasks is based on Elasticsearch stack for log collection, storage and display.
The O2 farm takes advantage of this system to handle metrics coming from operating system, network, custom hardware and in-house software. A prototype version of the system is currently running at CERN and has been successfully deployed also by the ReCaS Datacenter at INFN Bari for both monitoring and logging.
L'analisi dati usando tecnologie di Machine e Deep Learning comporta l'uso di framework sempre più evoluti e potenti. Spesso tali framework sono anche in grado di sfruttare in modo molto efficiente hardware specializzato come reti a bassa latenza e/o GPU.
Il progetto H2020 DEEP-HybridDataCloud ha l’obiettivo di realizzare una piattaforma completa che integra sviluppi ai livelli di IaaS, di PaaS e di SaaS per fornire in modo semplice e trasparente dei framework di analisi in grado di supportare applicazioni di Machine Learning (ML) e Deep Learning (DL) per l'utente finale.
Il vantaggio delle tecnologie che verranno descritte è quello di avere una soluzione portabile e flessibile per supportare i deployment di analisi complesse su infrastrutture completamente diverse (Cloud private, pubbliche, cluster HPC, singoli host fisici, etc) senza richiedere agli utenti finali complesse conoscenze informatiche.
Durante il talk saranno mostrate in particolare le funzionalità supportate dalla prima release ufficiale del progetto insieme a qualche informazione sulle prossime funzionalità in programma.
Insight è un modulo software della Riada che estende le funzionalità di Jira e Jira Service Desk Atlassian consentendo di gestire risorse o asset di svariata natura all'interno di diverse organizzazioni.
Consente di definire strutture di asset personalizzate nonché definire relazioni tra oggetti e sfruttare l'ereditarietà padre-figlio tra diversi tipi di oggetto.
L'integrazione tra Jira e Insight rende possibile l'associazione tra issue e asset consentendo quindi di capire quali problematiche sono associate a determinati oggetti e viceversa, estendendo le funzionalità all'interno dei Workflow.
Tra le funzionalità offerte ci sono: Automazione, Gestione dei permessi, Importazione, Esportazione, Integrazione in Confluence, Reportistica, generazione Label e QR Code, Insight API.
Technology tracking C3S working group: status report
Tech-Watch HEPiX working group: tecnology update sulla evoluzione di server e CPU
Tech-Watch HEPiX working group: tecnology update sulla evoluzione dello storage
Update sulle attivita' del working group di Benchmarking di HEPiX
Resoconto dell'ultimo workshop di HEPiX tenutosi al San Diego Supercomputer Center
25-29 marzo 2019
L'espansione del mondo IOT ha determinato l'evoluzione di sistemi SoC o SBC a basso costo, che attualmente raggiungono prestazioni tali da poterli valutare come sostituti dei sistemi tradizionali per lo svolgimento di specifici compiti.
Come esempio, la presentazione mostra i test e la messa in produzione di sistemi a basso costo, basati su CPU ARM o Intel, per la realizzazione dei seguenti servizi di rete e di storage:
delocalizzazione di server radius per l'autenticazione 802.1x dei MAC address connessi agli switch di rete (il singolo radius server viene localizzato in prossimita' dello switch)
monitor ambientale
disk server basato su filesystem di rete scalabile (ad esempio GlusterFS)
cluster di server di database non relazionali (Cassandra e MongoDB) e test di performance
possibili altre future applicazioni
Lustre is the de-facto Storage solution in HPC, several Top 500 sites including NERSC, LLNL,ORNL are using or consider to deploy it over new storage hardware technologies such as fast NVMe SSD, 3D Xpoint SSD or proprietary Burst Buffers solutions. During my staying at SLAC for 3 years I deployed a High performance storage solution based on Lustre/ZFS for the US DoE LCLS project, which is the world’s first hard X-ray free-electron laser. The solution is based on a high performance storage prototype using NVMe SSD technology which will be eventually used for the LCLS II evolution where data taking will move from 120Hz to 1MHz, thus the need of even higher performance storage capabilities. Several clients (data reduction pipelines nodes) will need to access data from the DAQ system at a very high rate with locking contention. The prototype I realized is able to saturate 100GB/s with a bunch of clients reading and writing to a limited number of Lustre Object Storage servers and can scale up linearly just adding more storage nodes.
This presentation will provide a view on the status of new 400G switches and optics, quickly explaining the merchant silicon trends and moving to the optics market analysis and the trends which have leveraged the new 400G. The last part will cover the available optics/switches today along with the key features and what to expect for the near future.
The CMS experiment has been designed with a two-level trigger system: the L1 Trigger, hardware based, and the High Level Trigger (HLT), a streamlined version of the CMS event reconstruction software running on a computer farm. During its “Phase 2” the LHC will reach a luminosity of $7\times 10^{34}\,cm^{-2}s^{-1}$, with an average of 200 simultaneous collisions (pile-up), and the L1 output rate will increase up to 750 kHz. All of this will present an unprecedented challenge to the HLT, requiring a processing power larger than today by a factor 20.
This exceeds by far the expected speed-up for conventional CPUs, demanding an alternative approach both in algorithm design and hardware selection. On one hand industry and HPC have been using heterogeneous computing platforms achieving higher throughput and better energy efficiency by matching each job to the most appropriate architecture. On the other hand, deep learning based techniques are widely spreading also in the context of event reconstruction and may ease handling specific data-oriented tasks, such as seed and track selection.
The reliable use of a heterogeneous platform at the CMS HLT, involving also the integration of machine learning based solutions, requires the assessment of performance and characteristics, which can be attained by running a prototype in production during Run 3. Its integration in the CMS reconstruction software depends upon improvements to its framework and scheduling, tailoring the algorithms to fit the different architectures. This presentation will describe the results of the development and the characteristics of the system, along with its future perspectives.
Large international scientific collaborations will face in the near future unprecedented computing challenges. Processing and storing multi-PetaByte datasets require a global federated infrastructure of distributed computing resources. The current systems have proven to be mature and capable of meeting the experiment goals, by allowing timely delivery of physics results. However, substantial manual interventions from experts and shifters is needed to efficiently operate such heterogeneous infrastructures. On the other hand, logging information from computing services and systems is being archived and becoming available on big data solutions such as ElasticSearch, Hadoop, no-SQL database, etc. We plan to exploit such wealth of information to increase the level of automation in computing operations by using adequate techniques, such as machine learning (ML), tailored to solve specific problems. ML models applied to the prediction of data placements and access pattern can be used to increase the efficiency of resource exploitation and the overall throughput of the experiment distributed computing infrastructures. Time-series applications can be used to estimate the time needed to complete certain tasks, such as processing a certain number of events, or transferring a certain amount of data. Anomaly detection techniques can be employed to predict system failures, leading for example to network congestion. Recording and analysing shifter actions can be used to automatise tasks such as creating tickets to computing centers, or suggesting possible solutions to typical issues. We discuss how the use of common state-of-the-art technologies across experiments can be the key to build general solutions that can be pulled into the various scientific domains and used across different experiments.
Machine Learning (ML) has proven to be of great value in a variety of Software Engineering tasks, such as software defects prediction and estimation and test code generation. To accomplish these tasks, datasets (e.g. features represented by software metrics) have to be collected for the various modules (such as files, classes and functions) and properly preprocessed before the application of machine learning techniques. These activities are essential to manage missing values and/or removal inconsistencies amongst data.
Typically, new projects or projects with partial historical data may lack some features' data, e.g. defect data are not included. Their datasets are called unlabelled datasets and are the vast majority of software datasets. The extraction of the complete set of features (defectiveness included) and the labelling of the various instances imply effort and time. In literature there exist various approaches to build a prediction model on unlabelled datasets that entail a high number of permutations that is extremely time consuming. Cloud computing infrastructure, GPU-equipped resources and adequate ML framework can give the chance to overcome this problem.
In this study, we are going to present the analysis of existing software unlabelled datasets by implementing models in different available frameworks, such as TensorFlow and Keras, and running in Python and R. Recently, as a work in progress, we started to explore the application onto a large code base like the full software stack of the CMS experiment at the LHC collider at CERN. We have evaluated these frameworks by considering three aspects: extensibility, hardware utilization and speed. We intend to reduce the distance between theory and practice by providing strengths and limitations of the considered frameworks to enable users to assess suitability according to their requirements.
La prima barriera da superare per un giovane Fisico delle Alte Energie è l'apprendimento degli strumenti software, a volte molto specifici, di supporto al proprio lavoro. Storicamente questa formazione è affidata ai colleghi più anziani, che forniscono supporto, appunti ed esempi: la produttività purtroppo ne risente, dal momento che le basi fornite sono spesso non sufficientemente solide.
ALICE e LHCb hanno iniziato ad affrontare il problema rispettivamente nel 2014 e nel 2015, creando gruppi di lavoro specifici per la documentazione ed organizzando eventi di formazione. Nel 2017 i due esperimenti hanno individuato gli argomenti comuni (come Git, Bash, Python) e hanno iniziato ad organizzare eventi di formazione congiunti, condividendo insegnanti, documentazione e studenti.
Questo contributo vuole illustrare come i volontari di LHCb e ALICE (e SHiP dal 2018) lavorano per ottenere questo risultato, denominato "Starterkit", oramai noto ed apprezzato all'interno delle collaborazioni. Si metterà l'accento sulla struttura organizzativa leggera ed efficace, la vicinanza alla comunità degli utenti e l'impatto sulla produttività. Si concluderà con una doverosa riflessione sulla sostenibilità dell'iniziativa e sulle resistenze incontrate.
Research organisations are moving to new models of sharing publications and data among communities in order to overcome limitations of current publishing systems: free and open access, data and publication associations, etc.
INFN and other organisations, both public and private, have signed a global initiative launched by Science Europe, named Plan S, aimed at moving the state funded research works in open repositories or journal available to all.
In this context, we have updated the pilot of the INFN Open Access Repository, that is operational since 2014, to a version that is compliant with Plan S requirements. Starting from Zenodo code, that powers the EC flagship repository with the same name, developed by CERN in the context of the OpenAIRE series of projects, we customised the implementation to add
features useful for INFN.
These include the integration with INFN-AAI for the authentication, configurable look and feel, data migration from previous repository and some fixes. Additionally, we have developed yaml files describing all micro services behind Zenodo for an automated deployment on a Kubernetes-based
infrastructure.
The repository is open for testing by all INFN staff and associated researchers and people from other organisations are also investigating it, already. We are currently preparing a Conceptual Design Report for the updater repository for evaluation by the INFN management and we will report
on it.
This talk is about sharing our recent experiences in providing data analytics platform based on Apache Spark for High Energy Physics (HEP), building applications on top of it and exploring its usage in some use case scenarios.
Apache Spark is an analytics framework especially aimed at managing big data, with a strong traction and the support of a large user base. At CERN, the issue of distributing large scale computations has been tackled deploying both Hadoop service(s) to on-premise clusters with Spark running on YARN and on OpenStack Cloud infrastructure(s) with Spark running on Kubernetes.
Meanwhile, CERN provides a web platform, called SWAN (Service for Web-based ANalysis), where users can write and run their analyses in the form of (jupyter) notebooks, seamlessly accessing the data and software they need without having them
on their machine.
The first part of the presentation talks about the integrations between Spark, Hadoop with YARN and OpenStack with Kubernetes that together brought a truly Unified Analytics Platform, enabling scaled, distributed HEP data processing. Furthermore, we will discuss how SWAN has become the interface of such Analytics Platform, providing submission and monitoring capabilities for Spark computations.
The second part will focus on evolutions in exploiting analytics infrastructure, namely new developments in ROOT analytics framework - Distributed RDataFrame and PyRDF - which through SWAN allow interactive, parallel and distributed analysis on large physics datasets stored on EOS that can be easily monitored and shared with others.
In questa sessione sarà data una introduzione generale sul contesto Europeo ed i progetti in cui l’INFN è coinvolto per lo sviluppo di tecnologie innovative per lo storage ed il computing in infrastrutture distribuite. Verranno presentate le tecnologie oggetto delle DEMO successive: DODAS per istanziazione dinamica di cluster HTCondor, creazione di sistemi di Caching on demand e flessibili su risorse cloud, orchestrazione mesos/k8s su GPU e l’uso di spark/Hadoop per l’inferenza di reti neurali. Le tecnologie presentate sono sviluppate con il contributo dei progetti Europei H2020 eXtreme-DataCloud (XDC) e DEEP-HybridDataCloud (DEEP) che verranno brevemente presentati. Sarà inoltre presentato per la prima volta il progetto Europeo IoTwins che farà uso di molte delle tecnologie oggetto di questa sessione. Le demo si svolgeranno in parallelo nel resto della sessione e continueranno durante il coffe-break nell’area sponsor.
(INFN-CC + Perugia/Bari)
(con riferimento a piccoli esperimenti tipo GR2) (su k8s)
In questa demo verranno presentati alcuni dei tool sviluppati nell'ambito del progetto DEEP-Hybrid-Datacloud, un progetto H2020 che ha come obiettivo lo sviluppo e l’implementazione di tecnologie cloud che consentano un accesso facile e trasparente a risorse eterogenee in ambiente cloud e HPC, con un particolare focus sull'automazione del deployment di tool per il Deep Learning e il Machine learning, per diversi contesti applicativi.
Uno degli obiettivi del progetto è permettere agli utenti finali di sfruttare in maniera semplice e trasparente risorse hardware specializzate come GPU e Infiniband a supporto del processamento di grandi moli di dati (Big Data) con tecniche ML/DL.
Attraverso la PaaS di DEEP è possibile richiedere il deployment di applicazioni su macchine virtuali o docker container specificando, tra le risorse necessarie, il numero di GPU. La richiesta di deployment è espressa tramite un TOSCA template.
In particolare, per le applicazioni di tipo ML/DL è stato sviluppato un framework, DEEPaaS (DEEP as a Service), per fornire l'accesso "as a service" ai modelli di ML.
Nella demo verrà mostrato come è possibile fare il deployment di un modello per la classificazione delle piante attraverso una semplice interfaccia web, l'Orchestrator Dashboard, che guida l'utente nella definizione dei requisiti e consente il monitoraggio del deployment.
Dietro le quinte, la PaaS gestisce il complesso workflow necessario per soddisfare la richiesta dell'utente: l'Orchestrator seleziona il sito e il servizio migliore per il deployment tra quelli disponibili, considerando anche il supporto per le GPU. In questo caso, il deployment verrà automaticamente schedulato su un cluster Mesos e il servizio verrà fatto partire come docker container gestito dal framework Marathon. Una volta completato il deployment, l'Orchestrator restituisce l'endpoint attraverso il quale il servizio è accessibile. L'utente potrà visualizzarlo sulla dashboard come output del proprio deployment.
Il servizio mette a disposizione una semplice web ui per fare inferenza e/o training.
La costante ricerca di innovazione nelle aree di sistemi distribuiti, calcolo, processamento dati e reti è un'attività core dell'INFN, è richiesta dalla costante evoluzione delle tecnologie e delle necessità degli esperimenti di fisica ed è alla base del successo internazionale dell'Ente in questi campi.
L'evento WhatNext Tech, organizzato in collaborazione con il Workshop CCR 2019, è un'occasione per esaminare innovative tecnologie informatiche di punta che, pur già offerte ed applicate con successo nell'industria, ancora non hanno ampia diffusione o conoscenza al nostro interno, con l'obiettivo di valutare possibili adozioni per i nostri casi d'uso.
La partecipazione a WhatNext Tech è aperta a dipendenti ed associati INFN ma richiede registrazione e partecipazione attiva, sotto forma di preparazione personale da effettuarsi prima degli incontri al Workshop CCR.
In questa parte dell’evento WhatNext Tech verrà effettuata la presentazione a tutti delle idee selezionate dai vari tavoli durante la sessione precedente, seguita da discussione.
La fase finale di WhatNext Tech, definita di consolidamento e conclusione e che porterà alla preparazione di eventuali proposte operative per il management INFN, avverrà in autunno 2019.
Per maggiori informazioni e per la registrazione a WhatNext Tech, vedere https://agenda.infn.it/e/WhatNextTech
Cosa cambia, come gestire la transizione e con quale supporto, disponibile.
Come gestire con HTCondor alcune operazioni tipiche (fairshare e limiti di uso
risorse, eccetera).
I servizi di storage sono una componente fondamentale della INFN Corporate Cloud, infrastruttura che usa CEPH e Swift per l’accesso al disco da parte del middleware OpenStack e dell’utente finale.
L’architettura distribuita di INFN-CC, assieme alle caratteristiche dell’hardware utilizzato, richiedono una attenta pianificazione del deployment dello storage, ma permettono l'implementazione di soluzioni estremamente interessanti e la definizione di diversi livelli di QoS e policy di replica geografica per diversi set di dati. In particolare, per quel che riguarda CEPH, si possono definire pool di block device da replicare remotamente per la realizzazione di strategie di Disaster Recovery.
L’adozione della tecnologia Erasure Coding su CEPH, ma anche su Swift, ci permette di ridurre in maniera drammatica il costo dello storage su sistemi che sono già economicamente competitivi non necessitando di costosi controller RAID.
Proponiamo una descrizione dettagliata dell’implementazione dello storage su INFN-CC, dei problemi incontrati, delle soluzioni adottate e delle performance ottenute. Verranno, inoltre presentati vari esempi di utilizzo che ne sfruttano appieno le possibilità.
La finalità di questa attività è la realizzazione di servizi di sync & share (s&s) per la comunità INFN, in due diverse modalità.
Nel primo caso è stata sviluppata una soluzione in grado di offrire un servizio s&s “personale” (as a Service) su disco criptato per necessità particolari. In questo schema, chi ne fa richiesta ottiene un sistema (di cui diventa amministratore) che può utilizzare per erogare a sua volta un servizio di personal storage ad un piccolo gruppo di lavoro, e la chiave di criptazione non è nota allo staff INFN-CC (fornitore).
La seconda tipologia consiste in un sistema di personal storage robusto e affidabile in grado di offrire agli utenti della comunità INFN un servizio di sync & share per l’utilizzo quotidiano.
La soluzione è stata dimensionata per soddisfare le richieste di ~10K utenti, immagazzinare 100/200M file per uno spazio di storage complessivo di 100/200TB, e per avere un costo per TB relativamente basso.
Il setup, interamente ospitato dall’ambiente OpenStack di INFN-CC, è basato su ownCloud ed è completamente automatizzato con Docker Compose.
In particolare, il tutto è stato ideato con alta disponibilità geografica, sfruttando la distribuzione sul territorio dell’infrastruttura INFN-CC.
L’implementazione delle due soluzioni e le relative architetture e tecnologie coinvolte verranno descritte nel dettaglio, insieme ai test di funzionamento e scalabilità.
Panoramica della configurazione di cloud@cnaf, con descrizione di problematiche e soluzioni tecniche adottate
The Cloud Area Padovana, deployed in 2014, was able to satisfy the computational and storage demands of several INFN research projects, mainly related to HEP and nuclear physics. Its resources were spread between two different sites: the INFN Padova Unit and the INFN Legnaro National Labs.
The Padova data centre also hosted and operated since 2015 an independent IaaS cloud managing network, storage and computing resources owned by 10 departments of the University of Padova, supporting a broader range of scientific and engineering disciplines.
These two clouds shared only a limited set of ICT services and tools (mainly for configuration, monitoring and accounting), whereas their daily operations and maintenance were carried out separately by INFN and University personnel.
At the end of 2017 we planned to merge the two infrastructures in order to optimize the use of resources (both human and ICT) and to avoid useless duplication of services.
The result of this integration, finalized in 2018, is a single (but distributed in two sites) cloud infrastructure named CloudVeneto.it. It now provides almost 2000 computational cores, 4 GPUs and about 300 TB of storage, and is used by about 250 users belonging to more than 70 projects.
La varietà di tipi di risorse esistenti in un moderno data center, nonché dei modi di gestirle, vanno ben oltre le capacità espressive del classico software di "monitoring di infrastruttura" o di “asset management”. In particolare, l'esigenza di implementare il Regolamento UE 2016/679 e le misure di sicurezza AgID, che richiedono di ottemperare a numerosi nuovi adempimenti, mette in luce il problema di incrociare informazioni provenienti da fonti diverse, elaborarle automaticamente e restituire diverse viste, eventualmente anche in formati diversi, sia human readable che machine-readable.
Queste considerazioni hanno spinto il Servizio Calcolo di INFN-BARI e il centro ReCaS-Bari a sviluppare un framework leggero e flessibile, facilmente configurabile e adattabile a varie esigenze, che facilitasse la raccolta delle informazioni estremamente eterogenee, l'analisi dei dati raccolti e la successiva fase di sintesi e fruizione programmatica e non.
A titolo di esempio, nell’attuale stato di sviluppo l'applicazione si interfaccia con l'infrastruttura di rete, con i servizi di farming (Foreman, Puppet), con il sistema di ticketing (Gitlab), con OpenVAS, restituendo vari prodotti finali molto diversi tra loro: il mapping dinamico della posizione dei server nei relativi rack, l'elenco dinamico degli host on line arricchito dalle informazioni presenti su Foreman/Puppet e sugli switch di rete, un report dettagliato dello stato di OpenStack, la configurazione automatica di un task di OpenVAS su tutti e soli gli host rilevati, e, infine, produce un certo numero di documenti successivamente editabili, ai fini della redazione del Documento di Valutazione dei Rischi.
L'esposizione di un'API autenticata predispone l'applicazione a essere utilizzata come “backend”, al fine di permettere la creazione di web views oppure di reports in formato ad esempio DOC o JSON, o anche di utilizzare l’applicazione come “proxy” su più siti, al fine di raccoglierne i dati in un'istanza centrale e incrociare le informazioni a livello, ad esempio, di “federazione” di siti, come nel caso di INFN-CC.
Il Tier1 usa da tempo docet, uno strumento sviluppato dall'INFN per tenere traccia di tutti gli asset in sala calcolo.
Lo scarso affetto dimostrato da molti utenti, unito al fatto che da tempo non c'e' sviluppo attivo del prodotto, ci ha spinto a cercare qualcosa di alternativo, che descriveremo in questa presentazione.
Panoramica introduttiva delle terminologie e delle tecniche impiegate dal machine learning.
Presentazione delle nozioni principali, per chi sia incuriosito e desideri iniziare ad interessarsi di ML, per aiutare a distinguere se una tecnica usa o meno ML, e di che tipo.
A huge increase of both storage and computing requirements are foreseen for the HL-LHC era (factor ~20 for the storage, and ~30x for CPUs) and new kind of resource are covering a crescent amount of needs (e.g. private or public cloud and HPC facilities). Thus CMS experiment has been pushed towards evaluating an evolution for the optimization of the amount of space that is managed centrally and the CPU efficiency of the jobs that run on “storage-less” resources.
In particular “Tier2” sites layer, for the most part, can be instrumented to read data from a remote source eventually enabling the use of a geographically distributed cache storage based on unmanaged resources, with a consequent reduction of the operational efforts for maintaining managed custodial storages and increasing the flexibility of the system. The cache system will appear as distributed and shared file system populated with the most requested data; in case of missing information data access will fallback to the remote access.
Moreover in a possible future scenario where a data-lake model will be implemented, a protection layer against a central managed storages might be a key factor along with the control on data access latency. The cache storages used for such a layer will be by definition "non-custodial", thus reducing the overall operational costs.
The objective of this contribution is to present the first integration experience of an INFN federation of cache servers spanning over the CNAF Tier-1, Bari and Legnaro Tier-2s that provided unmanaged storages organized under a common namespace with the use of XCache technology. The results in terms of performances on real CMS experiment workflows will be shown. In addition first studies on CMS metadata regarding the analysis jobs access pattern over Italian Tier2’s will be presented, leading to an estimation of the possible improvements provided by the introduction of the proposed solution at production scale for the italian Tier2’s.
Furthermore the Proof-of-Concept deployment of a “smart decision service” platform to enable AI based cache operations will be shown. The objective is to enable ML-based management of the Cache content in order to reduce costs in term of hardware but also to optimize the operational costs thanks to the intelligence.
Future plans and evolution toward the direction of building Data Lakes prototypes in the context of the IDDLS and ESCAPE funded projects will be presented.
L'esperienza maturata amministrando i sistemi di storage in Grid ha dimostrato che l'infrastruttura di rete distribuita WLCG è molto performante per quanto riguarda le esigenze degli esperimenti LHC; tuttavia, un numero eccessivo di siti può portare ad inefficienze nella gestione dell’intero sistema, sia per la necessità di un maggior numero di manodopera specializzata che per un onere maggiore nelle operazioni centrali dell’esperimento. D'altra parte, l'analisi degli utenti è spesso basata su cluster ospitati in siti di piccole dimensioni come i Tier3, pertanto è importante fornire un accesso ai dati dinamico ed efficiente anche in tali siti. Entrambi questi requisiti possono essere soddisfatti da Tier3 diskless, ma dotati di una cache di dati locale.
I Tier2 di ATLAS italiani che utilizzano il sistema di storage DPM (Disk Pool Manager), grazie al core DOME (Disk Operation Management Engine) disponibile nelle ultime versioni del DPM, hanno realizzato un prototipo di un sistema che soddisfa i requisiti sopra indicati, basandosi sulla possibilità di implementare storage pool volatili che si comportano come cache.
Grazie alle connessioni veloci ed affidabili tra i diversi siti Tier2, è stato, infatti, possibile implementare una configurazione in cui un sito primario, Napoli, rappresenta un singolo punto di ingresso per l'intero sistema di archiviazione che include aree disco situate in siti remoti (Roma1 e Frascati). I sistemi di storage remoti sono stati quindi configurati come volatili con la funzione di cache locale grazie a meccanismi di accesso a zone. Queste cache possono essere popolate a partire dagli altri pool dello stesso sistema o da aree dati esterne, utilizzando meccanismi ancora in fase di esame sia in termini di scalabilità che di prestazioni.
Con un tale sistema, in un Tier3 i job di analisi di fisica degli utenti sarebbero in grado di accedere a dati memorizzati localmente, dispensando però l'amministratore del sito locale dalla gestione di un sistema di storage completo e rendendo il sito trasparente rispetto alle operazioni centrali dell’esperimento. Inoltre, il DPM in caching mode si integra facilmente in siti già grid-enabled, si configura anche in modo "lightweight", installando solamente un sistema di dischi gestiti da un DPM pool node, ed automaticamente risulta multiprotocollo, pur essendo in grado di essere raggruppato in federazioni di tipo HTTPS/WebDAV o Xrootd.
Data from the Advanced VIRGO interferometer are processed by running search pipelines for a number of expected signals, the most prominent being coalescing compact binaries but also including continuous waves, burst events and detector characterisation studies. Some of the processing needs to be done with as low as possible latency, in order to be able to provide triggers for other observatories, while deep searches are run offline on external computing centres. Thus, data needs also to be reliably and promptly distributed from the EGO site to computer centres in Europe and the US for further analysis and archival storage.
Two of the defining characteristics of Advanced VIRGO computing are the heterogeneity of the activities and the need to interoperate with the LIGO observatories. A very wide array of analysis pipelines differing in scientific target, implementation details and running environment assumptions have to be allowed to run ubiquitously and uniformly on dedicated resources and, in perspective, on heterogeneous infrastructures.
The current status, possible strategies and outlook are discussed.
The computing model of the AMS and DAMPE Cosmic Ray experiments is designed to cope with several TB of ROOT files produced for every year of mission. Periodically the reprocessing of the full dataset is needed and on yearly base a massive MonteCarlo production of the various CR species bust me run. The data analysis is, typically, performed on reduced ntuples by tens of users. Both the data production and the data analysis are run in the ~ 5 computing centers of the collaboration without any grid-like framework. Recently we started exploiting technical solutions provided by Dynamic On Demand Analysis Service, DODAS developed in the context of projects such as INDIGO-DataCloud, EOSC-hub and XDC in order to seamlessly access cloud resources both commercial (Deutsche Telekom, Google-Cloud) and on premises (Cloud@ReCas, and Cloud@CNAF). The work is progressing toward a larger federation which includes many and different IaaS’s into a single DODAS provided pool of resources. A concrete example is the ongoing initiative to include AMS2 compute resouces hosted at ASI. Results of this activity will be shown including the experience and perspectives of the experiments both on computing and data handling. We will include also a wish lists for the future
La rete CHNet nasce all'interno dell'Istituto Nazionale di Fisica Nucleare come sinergia tra i vari gruppi di lavoro che mettono a disposizione le proprie strumentazioni nell'ambito dei beni culturali. Analisi come la fluorescenza a raggi X, la colorimetria, la datazione con il radiocarbonio o la tomografia permettono di determinare l'autenticità o la datazione di un'opera, lo stato e la composizione dei materiali o, nel caso di ricostruzioni storiche, il luogo di origine di un artefatto.
In questo scenario il CNAF di Bologna è impegnato a implementare una infrastruttura in grado di gestire e rendere disponibili i dati derivanti da queste analisi. Il Digilab è un insieme di servizi Cloud in grado di gestire il caricamento, la classificazione, la condivisione e la visualizzazione dei dati estratti attraverso servizi che utilizzano moderni protocolli web come HTTP, WebDav e OpenID Connect. L'infrastruttura Cloud è basata sulla piattaforma di file sharing open-source Nextcloud, mentre per la gestione, l'autenticazione e l'autorizzazione degli utenti ci si è affidati al servizio INDIGO-IAM sviluppato al CNAF. La piattaforma, ancora in fase di sviluppo, attualmente offre due servizi: un modulo per l'assegnazione di metadati ai dati di analisi e un'applicazione per la visualizzazione dei risultati derivanti da analisi di tipo XRF (X-Ray flourescence). Entrambi gli strumenti, implementati in HTML5/SCSS/CSS/Typescript, sono integrati nella piattaforma Cloud ma possono essere anche fruiti singolarmente.
In view of the LHC Run3 starting in 2021, the ALICE experiment is preparing a major upgrade including the construction of an entirely new inner silicon tracker (the Inner Tracking System) and a complete renewal of its Online and Offline systems (O²).
In this context, one of the requirements for a prompt calibration of external detectors and a fast offline data processing is to run online the reconstruction of tracks in the Upgraded ITS.
To cope with the specification of the O² and with the foreseen peak Pb-Pb interaction rate of 50 kHz, the algorithms involved are being implemented exploiting common parallelisation technologies, such as SIMD and multithreading on CPUs and offloading workloads on GPUs, via CUDA, OpenCL and HIP.
Other detectors such as Time Projection Chamber (TPC) and the Transition Radiation Detector (TRD) are moving in the same direction. The target is to have the entire online reconstruction pipeline running on GPUs.
In this contribution I will show the state of the art, the results and the the future developments of the software for the reconstruction in ITS. I will also cover the strategies adopted in writing GPU code in a scenario where vendor lock-in is not an option. Finally, I will also introduce “alidock”, a tool we created, capable to provide consistent, customizable and GPU-aware environment for development and runtime.