Project

General

Profile

LCG-France » Discussion orientation française DPM »

EOS comme alternative à DPM

Etude prospective pour LCG-France

LCG-FR Tech Meeting, 19 Juin 2020
Jean-Michel BARBET, SUBATECH
Denis PUGNERE, IP2I

Description

Home page : https://eos.web.cern.ch/
Présentations générales : http://indico4.twgrid.org/indico/event/4/session/15/contribution/50/material/slides/0.pdf
https://indico.cern.ch/event/862873/contributions/3724453/attachments/1980065/3296994/CERN_IT_Disk_Storage_Services.pdf
LCG-FR Annecy Mai 2019 :
https://indico.in2p3.fr/event/19056/contributions/71529/attachments/53588/69905/EOS-Alice-LCGFR-Annecy-2019.pdf

Fonctionnalités

Fonctionnalités nécessaires aux expériences

Fonctionnalités présentes

  • Liste à compléter :
  • Authentifications : GSI, Kerberos, Tokens (Alice)
  • Protocoles : HTTP, WebDAV, CIFS, FUSE, XRoot, gsiFTP
  • Third-party copy
  • Publication dans un système d’information (espace total, utilisé par groupes)
  • Acces-Control (ACLs)
  • Quotas
  • Groupes
  • Audit (liste des fichiers présents, contrôles de cohérences, fichiers fantômes ou endommagés) : Outil « ns-inspect » (à utiliser sur une copie offline du namespace)
  • Travail en cours sur un « EOS fsck »
  • <à compléter>

Fonctionnalités manquantes

?

Exploitables par les expériences ?

Authentifications : GSI, Kerberos, Token (Alice)
Accès HTTP
Third-party copy
Prochainement : Tokens : Tokens are the new Proxies : https://indico.cern.ch/event/862873/contributions/3724464/attachments/1981808/3300626/EOS_2020_WS_Token_are_the_new_Proxies.pdf

Techno exploitable par les expériences ?

Oui, tout le stockage au CERN est sous EOS.

Sites ALICE ayant EOS en production : ALICE::CERN::EOS, ALICE::JINR::EOS, ALICE::ZA_CHPC::EOS, ALICE::Kosice::EOS, ALICE::UPB::EOS, ALICE::ORNL::EOS, ALICE::LBL_HPCS::EOS, ALICE::RRC_KI_T1::EOS, ALICE::Subatech::EOS, ALICE::KISTI_GSDC::EOS, ALICE::NIHAM::EOS, …

CMS : Fermilab LHC Physics Center (LPC) : https://indico.cern.ch/event/862873/contributions/3724438/attachments/1981031/3298965/EOS_at_Fermi_LPC_2020.pdf

EOS status at IHEP : https://indico.cern.ch/event/862873/contributions/3724466/attachments/1980812/3298534/EOS_status_at_IHEP-2020.pdf

Interopérabilité avec le Data Management System des expériences

niveau d'interopérabilité avec le Data Management System des expériences
(ex. : déclaration et recovery automatique des fichiers perdus, gestion des fichiers temporairement indisponibles) ? <à décrire ou compléter>

Exemple d’équivalent DPM/EOS d’un dump des méta-données pour lister tous les fichiers stockés dans un disk-server :

DPM :

dpm-disk-to-dpns -s lyostorage15.in2p3.fr:/gridcms1
dpm-list-disk -s lyostorage15.in2p3.fr -f /gridcms1

EOS :
eos fs dumpmd 213 --path

Aspects Techniques

EOS et xrootd

Pour EOS, xrootd n’est pas simplement un protocole d’accès aux données. EOS est une application construite à l’aide de xrootd dans le sens où EOS utilise les capacités de communication apportées par xrootd. Même la base de données QuarkDB est construite au dessus de xrootd.

A comparer avec :

xrootd « natif » : pas de « namespace » = pas de structure arborescente, pas de d’ACLs, de modèles de réplication interne, la résolution de l’emplacement des fichiers est conservée en cache en mémoire mais il n’y a pas de persistence.
DPM : xrootd n’a été ajouté que par la suite comme un protocole d’accès aux données (xrootd door) et xrootd n’est pas utilisé comme mécanisme de communication entre les processus de DPM.

Le « namespace » 

Cache mémoire + BD clé/valeur redondante : QuarkDB (nécessite 3 serveurs distincts, cumulable avec une autre fonction : manager ou serveur disque)
After the hangover:QuarkDB and the new namespace :
https://indico.cern.ch/event/862873/contributions/3724439/attachments/1980153/3297179/ns-final.pdf

JBOD, RAID , RAID non hardware

EOS peut fonctionner en mode JBOD ou en s’appuyer sur des groupes de disques (volumes virtuels) protégés par du RAID matériel ( ou logiciel : c’est moins fréquent). A noter que des expériences avec ZFS ont engendré des problèmes.

Mode ‘PLAIN’

EOS stocke chacun des fichiers dans les filesystems des disk-servers comme DPM.
La sécurité des fichiers repose sur le RAID (matériel / logiciel) du serveur, on crée une partition ou un volume, on le formate par le système et on le fait prendre en compte par EOS.
SUBATECH : les filesystems sont de l’XFS (partitions de 30 TB max) sur des volumes RAID6 (contrôleurs PERC de Dell) allant jusqu’à 14 disques de 8TB (112TB).
IP2I : les filesystems sont aussi sur des partitions RAID6 de 12 disques, formatés en XFS tant que tous les contrôleurs ne supportent pas le JBOD. Dans le futur, bascule possible vers le mode JBOD avec l’utilisation du mode ‘RAIN’ d’EOS.

Mode Erasure coding / RAIN

Modèles disponibles :
  • replica : 2 ou 3
  • RAIN : n+2 (raid6), n+3 (archive)
    CERN : modèles EC utilisés ou envisagés : EC4+2, EC8+4, EC10+2

En mode replica, chaque fichier est répliqué le nombre de fois indiqué (2 replicas par défaut) sur différents disk-servers, de manière à ce que la perte d’un disk-server n’entraine pas une indisponibilité du fichier.

Impact sur la quantité de disque disponible par rapport à la quantité brute du mode replica=2 : nécessité de +100% capacité supplémentaire.

En mode RAIN ou erasure coding, chaque fichier est découpé en chunck, les chuncks (+ les chuncks de parité) sont répartis sur un ensemble de disk-servers.

Impact sur la quantité de disque disponible par rapport à la quantité brute :
  • mode RAIN raid6 (4+2 par défaut) nécessité de +50% capacité supplémentaire.
  • mode RAIN raid6 (8+2) nécessité par exemple de +25% capacité supplémentaire.
  • mode RAIN archive (5+3) nécessité par exemple de +60% capacité supplémentaire.

IP2I : Quand tous les contrôleurs des disk-servers (FST) supporteront le mode JBOD, je considérerai l’utilisation du mode RAIN (n+2). L’avantage est que les données restent disponibles même en cas de défaillance d’un disk-server (voir ci-dessous).

Erasure Coding for Online/Offline in the EOS Open Storage system :
https://indico.cern.ch/event/862873/contributions/3724472/attachments/1981287/3299541/EOS_2020_WS_EC_Presentation.pdf

Redondance locale ou distribuée

Redondance au niveau des managers et du « namespace » : possibilité d’avoir plusieurs managers. Un seul a les droits d’écriture dans le namespace (création de fichiers par ex.). Bascule automatique du manager « maître ». Sécurité et disponibilité du « namespace » : base de données noSQL redondante (3 instances, reste fonctionnel avec 2 instances).

Redondance pour les fichiers : replicas dans des endroits géographiquement distincts ou au sein d’un même site (replica ou rain). Faisabilité du rain géographiquement distribué : En théorie oui mais attention aux latences entre sites.

Impact de la perte d'un disque, d'un serveur
Perte d’un disque dans un RAID6 : reconstruction (voir ci-dessous), perte d’un disque en JOBD : selon le modèle de réplication. Un « drain » du disque déclenche une re-réplication pour conserver le niveau de réplication des fichiers.
Perte d’un serveur : si RAID6 et pas de réplication au sein de EOS, les données sont inaccessibles (perdues si le serveur ne peut être redémarré). EN JOBD, il faut prévoir de la redondance (RAIN ou erasure-coding) et répartir les « chunks » sur autant de serveurs que nécessaire. Dans ce cas la perte d’un serveur n’affecte pas la disponibilité des données.

Caching pour accès distant

intégré ou à ajouter (ex.: xcache)

Intégration EOS / Xcache semble en bonne voie :
https://indico.egi.eu/event/4698/sessions/3456/attachments/10627/12217/XDC_Overview_Storage_workshop_EGI.pdf

Possibilité de/compatibilité avec stockage fédéré ou distribué

A pilot project deploying EOS for the distributed storage between Korea and Thailand :
https://indico.cern.ch/event/862873/contributions/3724457/attachments/1979109/3295062/20200204KS_DS.pdf

Mascetti, L & Jericho, D & Hsu, C-Y. (2017). Global EOS: exploring the 300-ms-latency region. Journal of Physics: Conference Series. 898. 062029. 10.1088/1742-6596/898/6/062029.

Geo-tagging

Les filesystems sont dotés d’une étiquette geotag, les clients peuvent l’être via des règles sur les managers EOS. Il s’ensuit des préférences de placement ou de lecture…

Expériences avec Jean-Claude CHEVALEYRE entre Nantes et Clermont

Vision infrastructure

Quel mode de migration est envisageable (progressif ou big bang) ?

Est-il possible de commencer avec un petit cluster EOS et déplacer progressivement les données de DPM vers ce cluster ? Les serveurs disque DPM libérés pourraient être intégrés au cluster EOS.
Autre hypothèse : cohabitation des deux systèmes jusqu’à disparition de DPM. Ou encore demander aux expériences de vider le stockage DPM et tout réinstaller sous EOS. Dans tous les cas, l’installation des manager EOS peut se faire très en avance de phase.

IP2I : Opération prévue (non définitive, peut varier) :
Provisionning des serveurs de métadonnées + quelques serveurs de disques (~20% de la capacité totale de DPM)
ALICE : Petit stockage * mise a disposition du stockage d’EOS à l’expérience, déclaration * migration du stockage de l’ancien stockage XROOTD vers EOS par l’expérience * sortie de production de l’ancien stockage XROOTD
CMS et autres : * mise a disposition du stockage d’EOS aux expériences, déclarations * transfert au fil de l’eau des datasets, 1 par 1 * transfert des fichiers des utilisateurs * draining de DPM disk-servers, ré-installation en EOS, puis intégration dans EOS * sortie de production de l’ancien stockage

Problématiques liées à la déclaration de plusieurs SE-endpoints / site ?

Mutualisation du système de stockage pour plusieurs expériences (LHC et non LHC?). Question posée par JM dans le EOS-Community Forum :
https://eos-community.web.cern.ch/t/a-single-eos-instance-for-all-lhc-vos/335

Type de serveurs ? différents ou pas de DPM ? Pourquoi ?

Le système de stockage EOS utilise le même type de serveurs DAS que DPM. Le passage d’ensembles RAID à du JOBD a un impact.

Quand on utilise le mode raid standard (EOS ‘PLAIN’) le comportement des flux et I/O disques est identique EOS vs. DPM.

Quand on utilise le mode JBOD (donc avec utilisation du mode RAIN qui créée des chunks) cela créée un overhead de trafic entre les disk-servers qui se répartissent les chunks entre eux.
Il y a un impact aussi sur la CPU des disk-servers qui doit calculer le CRC des chunks.

Passage à l'échelle : taille individuelle des disques et volumétrie totale du site

Il est vrai que les temps de reconstruction des gros ensembles RAID en cas de perte ou de remplacement de disque tend à être pénalisant (observé : 1 semaine pour la reconstruction d’un disque de 8TB dans un RAID6 de 100TB). Avec du JOBD, cet inconvénient est reporté au niveau des capacités de déplacement/duplication de données au sein de EOS. L’expérience du CERN a montré que la volumétrie d’un système de stockage EOS peut aller assez loin (jusqu’à ~100 PB)

Gros serveurs ou plein de serveurs ?

Problématiques de dimensionnement :
- nombre de serveurs si choix JOBD et erasure coding (EC 10+2 = 12 serveurs min)
- Capacités CPU de chaque serveur, nombre de processus xrootd-fst ?
- Réseau : bande passante par serveur (bonding d’interfaces 10Gbits/s?), cluster entier.

Monitoring

Interne au site : Utilisation des commandes CLI pour afficher l ‘état du stockage, du namespace, des filesystems, des statistiques d’E/S.

SUBATECH : plugins nagios « maison » pour surveiller : les services EOS, le cluster QuarkDB, l’état des « filesystems »
Accès à des statistiques via xrood : Commandes xdr
ALICE : publication dans Monalisa via le plugin « eos_apmond »

Publication dans le BDII : OK via RPM : glite-info-provider-SE_xrootd-1.2.1-1.noarch
Compatibilité outils WLCG (CRIC) : OK
Compatibilité outils EGI (VAPOR?) : NOK

Coûts (financier, humain, matériel)

De migration

Besoin de formation
Opérationnels
Prévoir au minimum 2 managers, 3 nœuds QDB
RAM importante sur le manager (cache du namespace), SSD conseillé pour QDB.
Taille du SSD pour QDB : https://quarkdb.web.cern.ch/quarkdb/docs/master/disk-space
Possibilité de combiner manager et serveur QDB, 3ème serveur QDB sur un serveur
Machines vituelles ? Attention à la latence d'accès aux méta-données
Prévoir sauvegarde de QDB (Subatech : pour 1.5PB : QDB=32GB, Backup : 10GB compressé)
Vis-à-vis des VO

Estimation MATINFO

Devrait être proche de ce qui est nécessaire pour un cluster DPM.

Communauté de développement

Maturité
Support proposé :
Documentation : http://eos-docs.web.cern.ch/eos-docs/
Community Forum : https://eos-community.web.cern.ch/
Mail: eos-support@cern.ch Abonnement avec compte CERN via : https://egroups.cern.ch/

Workshop annuel : Dernier : Février 2020 : https://indico.cern.ch/event/862873/