Accueil > La Newsletter de RESINFO > Newsletter 14 > GT ZFS : Interview de Michel Le Cocq
GT ZFS : Interview de Michel Le Cocq
Interview de Michel Le Cocq
J’ai été contacté pour réaliser une interview dans le cadre du GT-ZFS dont je suis l’animateur et fondateur pour la Newsletter #14 ResInfo.
Une biographie
Je suis ingénieur de recherche bap E au CNRS et affecté actuellement à l’IPGP (Institut de Physique du globe de Paris).
Mon parcours Professionnel en tant qu’Administrateur Système Réseau.
J’ai débuté il y a 19 ans suite à l’obtention d’un poste d’Ingénieur d’étude à l’université Paris 13 où j’ai exercé pendant 7 ans pour 2 entités CNRS (LAGA-LIPN) et collaboré avec les Réseaux Métiers via Mathrice, réseau très actif des informaticiens de laboratoires de l’INSMI dans l’administration de la PLM (Plateforme en Ligne pour les Mathématiques).
Très vite je suis devenu ingénieur de recherche CNRS à l’ENS CACHAN où j’étais responsable de l’équipe système du Laboratoire Spécification et Vérification pendant 3 ans puis j’ai rejoint l’IPGP depuis 2013 en tant que responsable de l’architecture système et réseau de l’équipe de Sismologie où l’activité de recherche découle de l’analyse de signaux sismiques.
Depuis 7 ans je suis le Fondateur et Responsable du Service Mutualisé de Virtualisation de l’IPGP et j’administre le Système d’information de l’Observatoire Géoscope avec en plus comme mission la restructuration du Centre de Données de l’Institut.
Mon implication dans ResInfo se fait à plusieurs niveaux.
Tout d’abord en tant que membre du comité de pilotage du réseau métier Respire : RESeau Parisien d’Informaticiens pour la Recherche et l’Enseignement. Ce Réseau permet de rassembler les agents Administrateurs Système Réseau de Paris et proche banlieue, mon expérience professionnelle m’a montré l’importance des réseaux métier surtout pour les nouveaux entrants. Ainsi j’ai pu constater qu’il n’y avait pas jusque là de réseau d’informaticiens sur la Région Parisienne, la distance pouvant être un frein à ce type de rencontre, nous nous sommes rencontrés fin 2019 avec les membres du copil actuel et d’autres représentants de réseaux actif pour décider de sa création. Les objectifs de ce réseau sont la formation, l’échange, le lien social et le rapprochement local des agents.
Je m’implique dans l’organisation de Josy (DNS, Orchestration) et une prochaine ANF (Ilas - Initiation Linux pour les Administrateurs Système).
Je participe aux CA de ResInfo et je suis fondateur et animateur du Groupe de Travail Resinfo sur ZFS.
Mon historique autour de ZFS.
Pour revenir au sujet principal de cette interview, j’ai plongé dans l’univers de ZFS en 2007 suite à une présentation commerciale d’OpenSolaris et de son système de virtualisation. Nous recherchions à l’époque une solution de virtualisation à Paris13 avec le responsable du Cluster Loic Gouarin (aujourd’hui Groupe Calcul ‘entre autre’). Je co-gérais avec lui à l’époque ce cluster.
Je n’ai pas eu le temps de mettre cette solution en place sur Paris13, mais par la suite j’ai déployé une solution de stockage ZFS au LSV à l’ENS Cachan suite à son intégration dans FreeBSD 7 en 2008. J’y ai fait quelques erreurs d’implémentation et d’architecture. Suite à cette expérience que j’ai partagée avec Francis Hulin-Hubard (aujourd’hui directeur technique du Lip6), j’ai beaucoup échangé sur ce système de fichier avec différents collègues et autres acteurs de ZFS.
Après avoir participé à la première conférence Européenne sur Open ZFS qui a eu lieu à Paris en mai 2014, j’ai commencé à utiliser ZFS à l’IPGP tout d’abord en tant que backup pour un système NetApp que j‘ai par la suite complètement remplacé par une solution libre ZFS que je détaillerai plus loin.
J’ai utilisé de même cette solution de stockage dans le cadre de l’installation des systèmes de Virtualisation du Centre de Données IPGP.
J’ai initié le service mutualisé de virtualisation de l’IPGP. J’en suis le fondateur et le directeur technique. Suite à mon implication dans la création de plusieurs plateformes de virtualisation, deux au centre de donnée et une en Sismologie, j’ai décidé d’ouvrir cette dernière à d’autre équipes. Aujourd’hui 7 équipes sont clients utilisateurs de cette plateforme basée sur un stockage ZFS.
Pourquoi ce GT ?
Durant l’été 2020 j’ai pris part au CA de ResInfo pour Respire (en visio à l’époque cause covid). Lors de ce CA, j’ai pu assister à la présentation du GT Ceph. Cette présentation m’a amenée à proposer avec un collègue de Respire (Philippe Hamy) la constitution du GT-ZFS. Je suis responsable et animateur de ce Groupe de Travail depuis 2021.
Le groupe de travail ZFS c’est donné pour mission principale de regrouper une documentation francophone la plus utile possible pour la communauté ASR. Il prévoit de fournir des documentations techniques, des conseils, des tutoriels, des démonstrations et des formations … Nous essayons de rassembler sur notre documentation l’ensemble des bonnes pratiques à adopter.
Il est facile de mettre en place un système de stockage ZFS, mais tout aussi facile de faire de mauvais choix dès la réalisation du devis jusqu’à la phase d’implémentation. Nous tâchons de vous aider dans ces différentes phases via notre documentation et nos conseils.
Comment nous contacter ?
L’ensemble des membres du GT-ZFS sont actifs sur la liste stockage https://groupes.renater.fr/sympa/info/stockage, cette dernière rassemble l’ensemble des discussions concernant le stockage quel qu’en soit son type.
L’ensemble des membres du GT-ZFS sont présents sur plusieurs listes (ASR/stockage/virtualisation…) et nous redirigeons les interlocuteurs vers le GT quand cela le concerne.
Nous avons une liste de diffusion interne dédiée au copil zfs-copil@listes.resinfo.org (entre membres du GT), tout le monde peut nous y contacter mais les mails sont soumis à modération. Nous préférons centraliser les discutions ouvertes sur la liste stockage puis faire des mails plus ciblés ensuite.
Nous communiquons en interne sur le chat IN2P3 #gt-zfs ou l’on peut éventuellement inviter d’autres membres pour discutions.
Notre fonctionnement.
Nous organisons des réunions (uniquement en visio vue notre éclatement géographique), environ tous les 2 mois en fonction de nos disponibilités. Il y a aussi des séances de travail plus intenses en plus petits groupes comme pour la rédaction de notre documentation ou la réalisation de notre Poster pour les Jres 2022 à Marseille : https://hal.archives-ouvertes.fr/hal-03740132
Notre documentation est basée sur Sphinx et hébergée sur un git à l’IN2P3. https://resinfo-gt.pages.in2p3.fr/zfs/doc
Nous réalisons régulièrement dans nos régions des présentations dont le thème est proche de ZFS.
Une question qui revient souvent, est : OpenZFS ou Ceph ?
Selon moi ce n’est pas le même niveau. Il est facile de mettre en place un Ceph via l’interface Proxmox ou un ZFS via un FreeNAS. Mais ce n’est pas une implémentation que je recommande. Ce genre d’implémentation est-t-elle réparable en cas de coup dur ? Concernant Ceph, j’ai trop entendu on a cassé notre Ceph … pour récupérer nos données on a dû faire appel a un prestataire externe. Nous n’avons pas tous les mêmes moyens, selon moi ZFS est l’étape (libre) intermédiaire avant de passer à des stockages tel que Ceph. Je reparle de moyens, mais cette fois humain, une architecture Ceph est très complexe et il ne faut pas la laisser reposer sur une seule personne sous peine de perdre les connaissances techniques. Pour moi Ceph est le vrai stockage d’avenir de masse par excellence, mais il faut y mettre les moyens (humains et financiers). Il faut bien faire attention avant de se lancer dans tel ou tel techno, il est important de maîtriser cette dernière avant la passer en production.
Pourquoi ne pas utiliser du stockage propriétaire ?
C’est une question de coût. Il faut choisir si l’on préfère mettre de l’argent dans son stockage propriétaire ou dans les formations des agents et le temps de mise en place d’une solution libre. Il m’est arrivé d’hériter de solution de stockage propriétaires, j’ai pu constater quand la fin de garantie du matériel arrive, que la solution est souvent de partir sur une nouvelle baie ou autre et de ‘jeter’ l’ancienne (recommandation des fournisseurs … ).
Si l’on part sur une solution libre qu’elle qu’elle soit, vous avez la possibilité de designer vos solutions de façon à les faire évoluer par des remplacements successifs d’éléments. Vous pouvez également utiliser le matériel en fin de vie comme backup secondaire ou autre. Mais tout cela dépend des marchés et des sources de financement de vos moyens de stockage.
Mon cas d’utilisation à l’IPGP.
Aujourd’hui à l’IPGP notre solution de stockage mutualisé est basée sur 2 serveurs offrant le rôle de serveur de fichier NFS sur IP flottantes. Ces derniers sont connectés chacun en double attachement à 3 baies de disques. Ainsi lors des phases de mise à jour ou autre il m’est facile de basculer un volume correspondant a une baie d’un serveur à l’autre. Le temps de dispos est quasi continu. Cette solution est sauvegardée via des transferts propre à ZFS vers un autre serveur sur lequel est connecté une autre baie massive distincte. Le tout aujourd’hui représente au total 1Po.
J’offre ainsi du stockage pour nos utilisateurs, leurs projets, les machines virtuelles et les sauvegardes.
Nous utilisons également au sein de notre solution de virtualisation des solutions de transfert et sauvegardes de machines virtuelles entre hôte pour celles dont le stockage n’est pas exportés en NFS mais hébergé sur l’hôte en local (pour des questions de taille de disponibilité et de vitesse d’accès). Nous utilisons ZFS pour assurer une réplication de ces données entre hôtes. Le système de transfert incrémentales ZFS nous permet d’assurer un état à un instant snapshot-1 du disque d’une machine virtuelle disponible rapidement.
Et la suite concernant le GT-ZFS ?
Nous prévoyons d’organiser prochainement peut-être une Josy ou Jtech, voir même une ANF en 2024 peut-être.
Et te concernant ?
Peut-être une formation Ceph ;-) …