Un serveur de données au format ROOT. Xrootd Un serveur de données au format ROOT. Jean-Yves Nief – CCIN2P3

Historique Projet initié dans le cadre de BaBar en début d’année. Abandon du format Objectivity au profit d’un format de type ROOT (fin de la production au format Objectivity en fin Décembre). Nécessité d’adopter un système d’accés performant aux données ayant les avantages de celui existant avec Objectivity, mais aucun des inconvénients. Aucun système existant d’accés aux données satisfaisant (en particulier NFS). Xrootd - 01/12/03 - CC-IN2P3

Motivations. Objectifs. Accés très performants aux fichiers distribués (serveurs multithreadés) sur de nombreux serveurs. Compatibilité arrière avec rootd. Adaptable à l’augmentation de la demande côté client (volume de données, nbre d’accés): « scalabilité » Tolérance aux erreurs (hardware, réseau etc…). Intégration d’un système de stockage de masse. Configurable dynamiquement. Choix du protocole de sécurité. Xrootd - 01/12/03 - CC-IN2P3

Compatibilité avec rootd. xrootd Application xrootd XTNetFile Fichier ROOT Compatible avec rootd TNetFile rootd XTNetFile hérite de TNetFile. Progrès: pertes de connection avec le serveur xrootd géré par XTNetFile. Xrootd - 01/12/03 - CC-IN2P3

« Scalabilité ». Tolérance aux erreurs. Le volume de données et nbre d’accés aux données peuvent être tels que un serveur ne suffit pas.  architecture distribuée (plusieurs serveurs).  mise dans un pool commun de fichiers régulièrement accédés par de nombreux utilisateurs (accés transparent).  « scalabilité ». Plusieurs serveurs  multiplication des pbs potentiels (hardware, réseau). La perte d’un serveur doit être transparente à l’utilisateur  robustesse. Solution: répartition de charge dynamique. Xrootd - 01/12/03 - CC-IN2P3

Répartition de charge dynamique (dlb). Serveurs de données xrootd dlbd xrootd dlbd xrootd dlbd (etc…) (3) souscription xrootd dlbd Serveurs de redirection (etc…) (2) (1) Quel serveur possède le fichier f ? Réponse du serveur: « host » Le client contact directement « host » qui possède f. Client Xrootd - 01/12/03 - CC-IN2P3

Interfaçage avec un système de stockage de masse. Volume accessible peut être tel que tous les fichiers ROOT ne peuvent être sur disque. Gestion de la présence sur disque d’un fichier transparente pour l’utilisateur. Gestion de l’espace disque transparente pour l’utilisateur. Solution: staging dynamique. Interfaçage avec le MSS de son choix: HPSS, Castor … Protocole de transfert des données au choix: RFIO, pftp ... Xrootd - 01/12/03 - CC-IN2P3

Staging dynamique. MSS (HPSS, Castor etc..) xrootd dlbd Client (5) (4) (3) (3) « host » désigné pour accéder f. « host » possède-t’il f ? non? alors: (4) Interrogation du MSS: possède-t’il f ? oui? alors: (5) Transfert vers le disque attaché à « host » (protocole: RFIO, pftp etc…) Client Xrootd - 01/12/03 - CC-IN2P3

Sécurité. Permet le choix du protocole d’authentification entre client et serveur: Kerberos. AFS Kerberos. GSI. …. Scénario possible: accés aux données à partir d’une machine sur le WAN (analyse à partir d’un portable perso). Xrootd - 01/12/03 - CC-IN2P3

Configuration dynamique des serveurs. Evolution des ressources hardware au cours du temps (nouveaux systèmes de fichiers attachés aux serveurs, régulation de l’activité entre MSS et disque etc…) Serveurs configurables dynamiquement sans interruption de service pour l’utilisateur. faisable grâce à la répartition de charge dynamique. Xrootd - 01/12/03 - CC-IN2P3

Conclusion. Xrootd en cours de déploiement au CC (BaBar). Encore en test (staging dynamique OK, tests en charge à effectuer). DLB déjà mis en production, mais pour Objectivity: aucun problème rencontré. Xrootd solution d’accés avec un fort potentiel: Robustesse. Scalabilité. Workshop « ROOT Users » @ SLAC: 25, 26 et 27 Février 2004. Xrootd - 01/12/03 - CC-IN2P3