Bonjour
La perte des disques m’a donné à réfléchir, et il me semble utile de démarrer une discussion (si ce n’est pas déjà fait - elle
relève en fin du conseil de labo) sur les évolutions souhaitables de notre dispositif informatique. En gros, je pense que
nous vivons encore sur une architecture construite il y a 15 ans pour les besoins de l’époque et améliorée par ajouts, et
qu’il serait utile d’analyser vers quoi nous voulons/pouvons aller.
Le système est pour l’essentiel construit sur deux idées : nous devons mettre une machine à disposition de chaque
utilisateur, chacun ayant ses propres données ; cette machine n’est pas dédiée, donc les données sont délocalisées par
rapport aux machines (disques partagés). J'appellerai cette partie la fonction “travail d’enseignement recherche” (_ter_ en abrégé).
A cela s’est ajoutée une partie consacrée au travail d’administration (_ta_) qui est maintenant dans Etamine, et une partie
programmation intense (_pi_) qui est dans les clusters de calcul.
Ce sont les disques partagés qui ont eu une défaillance et ont été difficiles à restaurer. Xavier et Marisol se sont rendu
compte que ces disques étaient utilisés pour des besoins de _ter_ auxquels ils ne résistent pas et qu’il faudrait mettre des
quotas pour pouvoir sauvegarder efficacement (je n’ai pas une bonne connaissance de la partie _ta_, il y aura peut-être à
ajouter). Pendant la restauration, beaucoup de collègues ont pu continuer à travailler, parce qu’ils sont très souvent sur
leur machine perso et que leurs données ne sont pas sur les disques partagés.
Il y a donc deux points en évolution :
1/ La politique des machines. La maintenance du parc consomme du temps de travail et des crédits, alors que nous
sommes progressivement passés à la domination du portable (133 clients Linux selon l’Intranet, mais ce n’est peut-être pas
à jour). Certains caveats s’imposent : si l’on change quelque chose, il faut faire très attention à ne pas mettre en difficulté
les thésards les moins bien lotis ; et les portables posent des problèmes de sécurité (virus). Néanmoins, ils sont massivement
utilisés à la place des machines labo et recèlent beaucoup de données.
2/ L’architecture des données _ter_. les données de travail courantes ne devraient pas dépasser 20 Go pour une seule
personne, mais cela ne signifie pas que les collègues qui dépassent stockent des données qui n’ont rien à faire au labo,
simplement que le stockage a des fonctions différentes qui sont toutes concentrées sur l’espace propre. Parallèlement
aux limitations, je pense qu’il faut chercher des espaces de stockage différents selon la fonction, avec différents supports,
modes de sauvegarde et restauration, et sans doute modes de partage de propriété - mais ne voyez pas un espace de
stockage par fonction. Nous pouvons aussi choisir de ne pas prendre en charge certaines fonctions.
J’essaye d’inventorier les fonctions. Pour l’instant, je vois :
- un ensemble de données actives propres à l'utilisateur qui doit pouvoir être restauré en 24h maxi sans intervention manuelle
(3h serait mieux, mais c’est peut être trop drastique ?). Cette contrainte impose des limitations, et le reste va dans des espaces
distincts.
- une fonction d'archivage des données de travail sur machine perso. J’insiste toujours, et je suis loin d’être le seul, pour
que les thésards respectent les règles de sécurité de base par rapport aux défaillances de disques durs, vols de portables et autres
calamités : qu’ils aient une copie à jour de tout ce qu’ils ont fait et qu’elle ne soit pas dans les mêmes locaux. Le besoin existe aussi
pour les permanents. Un mirroring sur les données actives (par unison ou autre) peut peut-être suffire si l’on n’y inclut pas les grosses
données ou le système. S’il y a besoin de plus, il faut sans doute une solution spécifique.
- une fonction de stockage des données d’expérience. Nous avons de plus en plus de travaux qui utilisent de gros volumes
de données (gros corpus, données d’apprentissage, résultats de calculs sur des séries de problèmes tests). Ils sont souvent
sur les comptes perso. Marisol m’a parlé d’un compte avec 10000 fichiers et, sauf erreur, l’essentiel est un corpus. On ne peut pas dire
à un thésard de se débrouiller seul avec ça. De plus, ces données pourraient utilement être partagées entre plusieurs collègues
quand elles sont publiques (et ça gagnerait de la place). Il faut sans doute des procédures de sauvegarde différentes, peut-être
aussi imposer l'utilisation de BDs plutôt que de fichiers.
- un espace de données partagées. Nous sommes bien équipés pour la gestion des versions de code ou de publications, mais
cela comporte une recopie sur chaque compte. Michael avait fait des acrobaties sur TAL pour que je puisse travailler
sur le même corpus que Ivan et partager une page web publique avec Sylvie, mais nous offrons peu de ce coté. En même temps, d’autres
services prennent de plus en plus de place : Dropbox, Google docs et Google Drive, Github pour la publication du source, d’autres
sans doute. J’utilise pas mal Overleaf. Tout cela est très commode. Nous n’avons ni maitrise, ni visibilité sur la pérennité de ces données
(durée de vie des compagnies, changement de politique, de propriétaire) ou leur sécurité. Nous perdons aussi faute de partage la
disposition d’outils ou de résultats qui devraient rester au labo.
Les réponses s’incluent dans un contexte en évolution constante : des outils se développent au niveau régional (Maggi) ou national
(plate-forme de calcul au CNRS, téléconférences dans Renater) et des logiciels deviennent disponibles (je viens de regarder sur
Framasoft, beaucoup de choses sont installables). Il y a sans doute des évolutions à prévoir.
Cordialement
François
