EOS architectural evolution and strategic development directions

CERN, Esplanade des Particules 1, 1217 Meyrin, Geneva, Switzerland

^* e-mail: georgios.bitzes@cern.ch
^** e-mail: fabio.luchetti@cern.ch
^*** e-mail: andrea.manzi@cern.ch
^**** e-mail: mihai.patrascoiu@cern.ch
^† e-mail: andreas.joachim.peters@cern.ch
^‡ e-mail: michal.simon@cern.ch
^§ e-mail: elvin.alin.sindrilaru@cern.ch

Published online: 16 November 2020

Abstract

EOS [1] is the main storage system at CERN providing hundreds of PB of capacity to both physics experiments and also regular users of the CERN infrastructure. Since its first deployment in 2010, EOS has evolved and adapted to the challenges posed by ever-increasing requirements for storage capacity, user-friendly POSIX-like interactive experience and new paradigms like collaborative applications along with sync and share capabilities.

Overcoming these challenges at various levels of the software stack meant coming up with a new architecture for the namespace subsystem, completely redesigning the EOS FUSE module and adapting the rest of the components like draining, LRU engine, file system consistency check and others, to ensure a stable and predictable performance. In this paper we detail the issues that triggered all these changes along with the software design choices that we made.

In the last part of the paper, we move our focus to the areas that need immediate improvements in order to ensure a seamless experience for the end-user along with increased over-all availability of the service. Some of these changes have far-reaching effects and are aimed at simplifying both the deployment model but more importantly the operational load when dealing with (non/)transient errors in a system managing thousands of disks.