Le groupe informatique au L.L.R.

1
Le groupe informatiqueau L.L.R.
Paulo Mora de Freitas Congrès du L.L.R., mai
2004, Paris.
2
Linformatique au L.L.R.
Avec les tendances annoncées aux Journées
Informatiques IN2P3/DAPNIA lors de la semaine
dernière.

• Introduction
• Équipement
• Organisation du groupe
• Personnel
• Service
• Développement
• Conclusions

3
Linformatique 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
• gt 100 utilisateurs tous profils confondus

4
Profil physicien
Tendance DATAGRID autant de grilles que
dexpériences, voire plusieurs grilles par
expérience.

• Calcul
• Évolution des plateformes Sun, HP gt 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 despace 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 -gt 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 dun
langage gros grain, évitant aux
utilisateurs/développeurs de ne pas se plonger
dans le C.
5
Profil ITA

• Informatique
• 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)

6
Besoins communs
Aujourdhui, 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 davoir une description commune
unique.

• Postes de travail (PC Windows/Linux, Mac,TX)
• Bureautique (Office, StarOffice, Acroread...)
• Imprimantes (A3/A4, NB/couleur)
• Accès au réseau pour
• Transfert de données et de logiciels
• Recherche dinformation (Web)
• Communication (mail, vidéoconférence)
• Accès aux imprimantes
• Environnement sécurisé
• Support pour lachat, la configuration,
  linstallation et la maintenance du matériel
  informatique, des logiciel et consumables

7
É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 -gt2 connexions Codec simultanées
• VRVS 1 poste public, et plusieurs PC équipés

8
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
  dune S.S.I.I. avec une  démarche qualité  (DQ)
• Réunions de groupe mensuelles

9
Personnel

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

10
Pyramide des ages
11
Lactivité  Service 

• 1/3 du groupe M.Bachelerie, J.Doublet,
  M.Maubras, C.Roy, B.Taklifi
• Mouvance TX gt 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é dachat des groupes de physique MAC
• Sensés partir à la retraite dici quelques années

12
Parc informatique au L.L.R.
Postes de travail
143 PC (62 Linux, 81 Windows)
Service
Calcul
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 Babar
1 SUN Solaris CAO
7 SUN Solaris CAO
14 modems
200 machines
13
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
1 Gbits/s
100 Mbits/s
B2000
1 Gbits/s
PC
100 Mbits/s
SWITCH
1 Gbits/s
100 Mbits/s
14
Management côté service

• Interface utilisateurs
• Une interface unique via message à
• support-info_at_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
• Larrivé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 davancement hebdomadaires
• Database du matériel informatique (J.Doublet)
• Développements doutils spécifiques en amont
  (D.Decotigny)

• ET APRES ???

15
Lactivité  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 danalyse en ROOT
  U.Berthon
• Phenix
• Acquisition de données bras Nord
  S.Chollet

16
Ventilation des efforts dedéveloppement mai
2004
17
Compétences
Architecture des systemes d'acquisition et
contrôle Banc test de cartes électroniques Develop
pement 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

• 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 !

18
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.

• Avant
• Organisation  matricielle  mais agents attachés
  aux expériences
• Temps dattachement relativement flou
• Tendance à garder lagent via plusieurs petits
  projets au long du temps
• Difficulté à rationaliser lemploie des
  connaissances et acquis en fonction des besoins
• Transition vers
• Ventilation de lactivité des agents dans des
  projets et missions
• Optimisation des ressources (attachement aux
  projets en fonction des compétences maîtrisées
  par lagent)
• Meilleur amortissement des efforts de formation
  et recyclage
• Besoins dans cette évolution
• Une maîtrise des compétences (DQ)
• Le développement dune  culture  dans
  lévolution de cahiers de charge (il faut déjà
  les avoir!!!) (DQ)
•  jouer le jeu 

Apparition dun support aux infrastructures/outils
de développement transverse aux experiences
(traduit la plus grande utilisation doutils 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 saligner et payer pour le choix
centralisé) ou développement interne (trop
lourde) ? ni lun ni lautre  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 quon ne
peut pas être complètement et suffisamment
flexible pour suivre, et quil faut sen tenir à
quelques choix forts, et sappuyer sur un seul
environnement contraint (ROOT). LCG na pas
arbitré clairement.
19
conclusion

• Visibilité dans collaborations
• stratégie dacquis 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 dune
  démarche qualité
• Menaces
• Problème des effectifs
• Explosion de la complexité côté service
• Sous utilisation des compétences