- Compact style
- Indico style
- Indico style - inline minutes
- Indico style - numbered
- Indico style - numbered + minutes
- Indico Weeks View
The first EOS workshop is in preparation to bring together the EOS community.
The two days event at CERN is organized to provide a platform for exchange between developers, users and sites running EOS.
The EOS development teams will present the current state of the art, best practices and the future road map.
We aim to discuss in particular architecture and status of
and three associated core projects
We warmly invite sites to present their current deployment, operational experiences, possible future deployment plans and input for improvements.
We encourage experiment representatives to share their view on future in (physics) storage and their usage of EOS.
Hands-on sessions are foreseen to enable exchange of information between operation teams at different sites and the development teams.
The first day will finish with a social dinner (at your expenses).
The workshop participation will be without fee. Free coffee breaks will be provided.
If you are interested in joining the EOS community - this is the perfect occasion!
Please register yourself to the workshop here. Don't forget to submit an abstract if you want to share your experience/ideas within the EOS community.
We hope to see many of you in February!
Your CERN EOS team.
An Introduction to the EOS workshop.
This is a quick recap of the EOS community, a who-is-who and our communcation platforms.
This presentation will give a brief introduction to EOS and the Aquamarine release version.
This presentation summarizes the current EOS service deployment at CERN.
Introduction to the CERNBox Service at CERN for those who do not know it yet.
The Web Application Open Platform Interface (WOPI) protocol allows to integrate collaborative editing with Office Online applications in CERNBOX/EOS.
Impressed by CERN’s EOS filesystem providing a POSIX-like capability on top of a tried and tested large scale storage system, AARNet runs multiple EOS clusters, the most interesting being a three site single namespace running replicas across 65ms. This filesystem is used for user data delivered via ownCloud, FileSender and an internally developed tool for fast parallel bundled uploads.
Currently the filesystem is 2 petabytes, split between Perth, Melbourne and Brisbane in Australia, and the current plans are to grow it well into the tens of petabytes within the next year.
AARNet has tried multiple scale out filesystems over the years in order to get true geographic replication and a single namespace across the Australian continent, but so far only EOS has had the capability of delivering within reasonable constaints.”
This talk will cover some of the first hand experiences with running, maintaining, and debugging issues found along the way.
The Copernicus Programme of the European Union with its fleet of Sentinel satellites will generate up to 10 terabyte of Earth Observation (EO) data per day once in full operational capacity. These data, combined with other geo-spatial data sources, form the basis of many JRC knowledge production activities. In order to handle this big amount of data and their processing, the JRC Earth Observation Data and Processing Platform (JEODPP) was implemented. This platform is built upon commodity hardware. It consists of processing servers amounting to a total of currently 500 cores and 8 TB of RAM using 10 Gb/s ethernet connectivity to access the EOS storage back-end. The EOS instance is running on currently 10 storage servers with a total gross capacity of 1.4 petabyte, with a scaling-up foreseen in 2017. EOS was deployed on the JEODPP thanks to the CERN-JRC collaboration. In conjunction with HTCondor as workload manager EOS allows for optimal load distribution during massive processing. The processing jobs are containerised with Docker technology to support different requirements in terms of software libraries and processing tools.
This presentation details the JEODPP platform with emphasis on its EOS instance, using the FUSE client on the processing servers for all data access tasks. Low-level I/O benchmarking and real-world applications of EO data processing tasks show a good scalability of the storage system in a cluster environment. Issues encountered during data processing and service set-up are also described together with their current solutions.
A wide range of detector commissioning, calibration and data analysis tasks is carried out by members of the Compact Muon Solenoid (CMS) collaboration using dedicated storage resources available at the CMS CERN Tier-2 centre.
Relying on the functionalities of the EOS storage technology, the optimal exploitation of the CMS user and group resources has required the introduction of policies for data access management, data protection, cleanup campaigns based on access pattern, and long term tape archival.
The resource management has been organised around the definition of working groups and the delegation to an identified responsible of each group composition.
In this contribution we illustrate the user and group storage management, and the development and operational experience at the CMS CERN Tier-2 centre in the 2012-2016 period.
XRootD is a distributed, scalable system for low-latency file access. It is the primary data access framework for the high-energy physics community and the backbone of EOS. One of the latest developments in the XRootD client has been to incorporate metalink and segmented file transfer technologies. We also report on the implementation of the signed requests and ZIP archive support.
We will review our experience from 5 years of EOS in production and introduce a generic architectural evolution.
CERN has been developing and operating EOS as a disk storage solution successfully for over 6 years. The CERN deployment provides 140 PB of storage and more than 1.4 billion replicas distributed over two computer centres. Deployment includes four LHC instances, a shared instance for smaller experiments and since a couple of years ago an instance for individual user data as well. The user instance represents the backbone of the CERNBOX service for file sharing. New use cases like synchronisation and sharing, the planned migration to reduce AFS usage at CERN and the continuous growth has brought EOS to new challenges.
Recent developments include the integration and evaluation of various technologies to do the transition from a single active in-memory namespace to a scale-out implementation distributed over many meta-data servers. The new architecture aims to separate the data from the application logic and user interface code, thus providing flexibility and scalability to the namespace component. The aim of the new design is to address the two main challenges of the current in-memory namespace: reducing the the boot-up time of the namespace and removing the dependency between the namespace size and the amount of RAM required to accommodate it. In order to achieve all this, we've developed an in-house solution for the back-end that combines interesting concepts from already existing projects like Redis, RocksDB, XRootD as well as state of the art consensus protocol like Raft.
This presentation details the basic concepts and the technology used to develop the key-value backend and the namespace interface modifications required to accomodate both the old and the new implementations. Futhremore, we explain the necessary steps to configure the new setup and the implications it has on the service availability and deployment process. Last but not least, we present some preliminary performance metrics of the new system that represent the basis for comparison with the request rates that we currenty observe in production.
quarkdb will soon become the storage backend for the EOS namespace. Implemented on top of rocksdb, a Key-Value store developed by Facebook, quarkdb offers a redis-compatible API and high availability through replication.
In this talk, I will go through some design decisions of quarkdb, and detail how replication is achieved through the raft consensus algorithm.
The CITRINE release provides a completely re-engineered scheduling algorithm for geographic-aware file placement. The presentation will highlight key concepts of scheduling tree, proxy groups, file sticky-ness ...
During 2016 the usage and scope of EOS at CERN and outside has been evolving towards usage as a POSIX like filesystem. The presentation will highlight the current state and improvements done during the last year. We will introduce the next generation (reimplementation) of the FUSE client in EOS which might overcome most limitations and non POSIX behaviour adding dedicated server side support to handle leases and client cache management.
We have added a similar mechanism as AFS/Kerberos to bind user applications to user credentials when interacting with EOS over FUSE. In this presentation we will describe the implementation and its integration into the login mechanism in interactive and batch nodes at CERN.
This talk will present the devops workflow used to validate and deploy new eos-fuse releases to the CERN computing infrastructure.
In this short presentation, we'll show a live demo of setting up and operating a quarkdb cluster. We demonstrate what happens during a failover, how node "resilvering" works, and show that adding or removing nodes on-the-fly does not impact availability.
In this session we will go through the steps to setup a CITRINE instance with the new quarkdb backend and explain migration from BERYL to CITRINE.
The goal of this talk is to share experience installing and using EOS storage at small cluster/sites for local users or students. Simple cluster setup contains FreeIPA (kerberos and ldap) as authentification with own Certificate authority, SLURM queuing system, CVMFS for software distribution, EOS as storage for data and home directories. For easy development and issue tracker GitLab is used. It also includes own indico site for management of meetings. There are 3 clusters installed already (Dubna, Russia - Hybrilit cluster, iThemba Labs and Slovakia - SPSEKE).
We will present our recent experiences with integrating EOS into Invenio digital library framework and how EOS allows data repository services such as Zenodo to handle large files in an efficient and scalable manner. Invenio v3, the underlying framework for a number of data preservation repositories such as CERN OpenData, CERN Document Server and Zenodo, was completely rebuilt from ground-up during 2016. In particular, Invenio's file handling layer was completely revamped in order to support multiple storage backends via PyFilesytem library as well as handling of large files. We will present both the Invenio layer and the benefits and obstacles we encounterd using EOS, as well as the XRootDPyFS plugin for PyFilesystem which provides access to EOS over XRootD for any Python application.
There are many large scientific projects in Institute of High Energy Physics (IHEP), such as BESIII, JUNO, LHAASO and so on. These experiments have a huge demand for massive data storage. EOS as an open source distributed disk storage system provides good solution. IHEP now has deployed two EOS instances. One is used for batch computing, and another for public usage (Owncloud+EOS). In this presentation, we will introduce our deployment status, and discuss our future plans in EOS.
In our talk we will cover development and implementation of federated data storage prototype for WLCG centers of different levels and university clusters within one Russian National Cloud. The prototype is based on computing resources located in Moscow, Dubna, St.-Petersburg, Gatchina and Geneva. This project intends to implement a federated distributed storage for all kind of operations with access from Grid centers, university clusters, supercomputers, academic and commercial clouds. The efficiency and performance of the system are demonstrated using synthetic and experiment-specific tests including real data processing and analysis workflows from ATLAS and ALICE experiments. We will present topology and architecture of the designed system and report performance and statistics for different access patterns.
A brief introduction to the EOS workflow engine.
The CERN Tape Archive (CTA) will provide EOS instances with a tape backend. It inherits from the CASTOR's tape system, but will provide a new request queuing system which will allow more efficient tape resource utilization.
In this presentation we will present CTA's architecture and the project's status.
The IT Storage group at CERN develops the software responsible for archiving to tape the custodial copy of the physics data generated by the LHC experiments. This software is code named CTA (the CERN Tape Archive).
It needs to be seamlessly integrated with EOS, which has become the de facto disk storage system provided by the IT Storage group for physics data.
CTA and EOS integration requires parallel development of features in both software that needs to be synchronized and systematically tested on a specific distributed development infrastructure for each commit in the code base.
This presentation describes the full continuous integration work flow that deploys and orchestrates all the needed services in docker containers on our specific kubernetes infrastructure.
An introduction how to use the EOS REST API for management and user interfaces.
The talk describes a graphical interface under implementation to help administering an EOS cluster.
MINIO is a GO implementation of an Amazon S3 compatible server exporting a filesystem with an elegant browser interface. We will demonstrate how you get a user-private AWS S3 compatible server exporting files from your EOS instance in few minutes.
Demonstration and deployment of a simplified CERNBox service instance.