Le groupe informatique au L.L.R. Paulo Mora de Freitas Congrès du L.L.R., mai 2004, Paris.

L’informatique au L.L.R. Introduction Équipement Avec les tendances annoncées aux Journées Informatiques IN2P3/DAPNIA lors de la semaine dernière. L’informatique au L.L.R. Introduction Équipement Organisation du groupe Personnel Service Développement Conclusions

L’informatique au L.L.R. : le cadre ~100 personnes au laboratoire 15 personnes dans le groupe, dont 5 font du service Activités et besoins informatiques partout => 100 utilisateurs tous profils confondus

Profil physicien Calcul Développement Tendance DATAGRID : autant de grilles que d’expériences, voire plusieurs grilles par expérience. Profil physicien Calcul Évolution des plateformes : Sun, HP => PC Linux Utilisation des fermes de calcul du CCIN2P3 (CMS, Babar, FLC, Astroparticules) Utilisation des sites « remote » (Babar, Phenix, H1) Mais aussi : moyens locaux importants (puissance de calcul, volume d’espace disque, vitesse réseau) Développement Demandeurs de développements spécifiques on-line et off-line (nos « clients ») Développeurs de code spécifique à leurs expériences: besoin de support et encadrement dans des évolutions techniques de taille (Ex : F77 -> OO) Le temps des règles de codage fleuve est dépassé. On est maintenant conscient que seul ce qui peut automatiquement généré et/ou contrôlé est utilisable . Le langage qui monte : python. On a besoin d’un langage gros grain, évitant aux utilisateurs/développeurs de ne pas se plonger dans le C++.

Profil ITA Informatique Administration Électronique Mécanique réseau,sauvegardes,achats,sécurité informatique, développements (PC Windows et Linux) Administration Comptabilité, achats, gestion personnel (PC Windows) Électronique Conception et simulation des cartes (PC Windows, SUN-Solaris) Banques de tests, acquisition de données, contrôle (PC Windows ou Linux, VME, etc.) Mécanique conception et simulation des pièces, Catia (PC Windows)

Besoins communs : Postes de travail (PC Windows/Linux, Mac,TX) Aujourd’hui, pas de choix possible entre windows, linux et MacosX : il faut supporter les trois. Coté GUI, la seule solution pour satisfaire les utilisateurs : faire du windows sur windows, du mac sur mac, du gtk sur gnome, … peut-être XML peut permettre d’avoir une description commune unique. Besoins communs : Postes de travail (PC Windows/Linux, Mac,TX) Bureautique (Office, StarOffice, Acroread...) Imprimantes (A3/A4, N&B/couleur) Accès au réseau pour : Transfert de données et de logiciels Recherche d’information (Web) Communication (mail, vidéoconférence) Accès aux imprimantes Environnement sécurisé Support pour l’achat, la configuration, l’installation et la maintenance du matériel informatique, des logiciel et consumables

Équipements collectifs Serveurs de calcul dédiés (différentes versions du système, logiciels) par groupe de taille important au laboratoire (CMS, Babar) 1 serveur pour usage en commun Serveurs pour assurer des services Web, mail, DNS, Intranet, imprimantes Serveur de fichiers Serveur de sauvegarde Visioconférence 2 lignes Numeris ->2 connexions Codec simultanées VRVS: 1 poste public, et plusieurs PC équipés

Organisation du groupe Depuis toujours une organisation « matricielle » Même responsable de groupe depuis sa création il y a presque 30 ans (M.Rumpf) Nouveau responsable de groupe depuis le 1er avril 2003 : Occasion pour essayer de dépasser une gestion du type « familiale » vers un management plus proche d’une S.S.I.I. avec une « démarche qualité » (DQ) Réunions de groupe mensuelles

Personnel Taille constante depuis des années 8 IR, 4 IE, 3 techniciens Pyramide d’age + politique du CNRS : gros problèmes à moyen terme problème lourd du service sur embaucher pour étaler la bosse

Pyramide des ages

L’activité « Service » 1/3 du groupe : M.Bachelerie, J.Doublet, M.Maubras, C.Roy*, B.Taklifi Mouvance TX => PC dans tous les groupes 1 à 2 postes par personne : croissance importante en nombre et en complexité Problèmes spécifiques Électronique (Cadence sur SUN) Liberté d’achat des groupes de physique : MAC Sensés partir à la retraite d’ici quelques années

Parc informatique au L.L.R. : Postes de travail 143 PC (62 Linux, 81 Windows) Calcul Service 3 Serveurs biprocesseurs PC/Linux : CMS, Babar, LABO 5 Serveurs PC/Linux : Web, mail, Intranet, DNS, TiNa, Modems, 1 serveur PC/Windows NAS 15 Mac 5 TX 6 imprimantes (1 serveur Impr.) 1 HP-UX J282 LABO 1 SUN Solaris CAO 1 SUN Solaris Babar 7 SUN Solaris CAO 14 modems ~ 200 machines

Nouvelle configuration : Rack 1 Gbits/s Réseau Ecole PC 100 Mbits/s 1 Gbits/s serveurs TINA PC 1 Gbits/s 1 Gbits/s 100 Mbits/s 1 Gbits/s B2000 1 Gbits/s PC 100 Mbits/s SWITCH 1 Gbits/s 100 Mbits/s

Management côté service Interface utilisateurs : Une interface unique via message à support-info@poly.in2p3.fr pour : Améliorer le temps de réponse Garder de traces (DQ) Analyse postérieur pour création des FAQ Établissement de procédures (DQ) pour : L’arrivée et le départ de personnel Mouvement de matériel Un correspondant informatique par expérience ou groupe Réunions « utilisateurs » mensuelles avec compte – rendu (DQ) En interne : Réunions d’avancement hebdomadaires Database du matériel informatique (J.Doublet) Développements d’outils spécifiques en amont (D.Decotigny) ET APRES ???

L’activité « Développement » CMS GRID: unique labo IN2P3 I.Semeniouk Production Monte Carlo AM.Gaillac OVAL D.Chamont Traitement faisceau test H4 I.Semeniouk Appui aux activités mécanique + électronique J.Gilly, M.Cerutti Babar/Geant4 P.Mora de Freitas FLC Simulation du modèle détecteur G.Musat, P.Mora de Freitas Acquisition de données banc de tests S.Chollet GLAST Fuzzy Clustering G.Musat ROOT IO U.Berthon H1 Graphique offline M.Cerutti Cadre d’analyse en ROOT U.Berthon Phenix Acquisition de données bras Nord S.Chollet EVOLUTION IMPORTANTE DES COMPETENCES

Ventilation des efforts de développement – mai 2004

Compétences A VOUS DE JOUER ! Temps réel Architecture des systemes d'acquisition et contrôle Banc test de cartes électroniques Developpement de drivers Programmation Microcontrolleurs – DSP LabView Théorie (ordonnancement) Calcul scientifique Packages Hautes Energies (Geant4, Root, CLHEP, ORCA, Gaudi…) Modélisalition de données Systèmes de base de données Programmation SQL Objectivity XML ROOT Java LabView Technologies « Web » (HTML, PHP, etc) Méthodologie objet (UML) Test Logiciel Remaniement Logiciel Compétences Temps réel Offline (Simulation, reconstruction, analyse) Génie logiciel (modélisation et management de projets) Modélisation et management de données Interface home - machine (IHM) A VOUS DE JOUER !

Management côté développement Peu de personnes par projets (trop de projets par labo ?). Il faut répartir les forces et découper les gens en morceaux. Management côté développement Avant : Organisation « matricielle » mais agents attachés aux expériences Temps d’attachement relativement flou Tendance à garder l’agent via plusieurs petits projets au long du temps Difficulté à rationaliser l’emploie des connaissances et acquis en fonction des besoins Transition vers : Ventilation de l’activité des agents dans des projets et missions Optimisation des ressources (attachement aux projets en fonction des compétences maîtrisées par l’agent) Meilleur amortissement des efforts de formation et recyclage Besoins dans cette évolution Une maîtrise des compétences (DQ) Le développement d’une « culture » dans l’évolution de cahiers de charge (il faut déjà les avoir!!!) (DQ) « jouer le jeu » Apparition d’un support aux infrastructures/outils de développement transverse aux experiences (traduit la plus grande utilisation d’outils de dévelopement). Les développeurs ne se contente plus de développer, mais fournissent un service aux physiciens qui développent. Outils commerciaux (hors jeux à cause des grosses collaborations internationales ou tout le monde ne peut pas s’aligner et payer pour le choix centralisé) ou développement interne (trop lourde) ? ni l’un ni l’autre : open source, mais il faut contribuer vraiment au code. Nombreux outils et de plus en plus transitoires. On ne peut plus suivre. Deux approches : 1. ceux qui prechent pour une architecture hyper-flexible, hyper-ouverte, hyper-modulaire (Open-Scientist); 2. ceux qui pensent qu’on ne peut pas être complètement et suffisamment flexible pour suivre, et qu’il faut s’en tenir à quelques choix forts, et s’appuyer sur un seul environnement contraint (ROOT). LCG n’a pas arbitré clairement.

conclusion Visibilité dans collaborations Groupe fait face Menaces stratégie d’acquis des connaissances réutilisables Groupe fait face à l’évolution du service (non sans peine) à l’évolution des techniques à l’évolution du management et du besoin d’une démarche qualité Menaces Problème des effectifs Explosion de la complexité côté service Sous utilisation des compétences