L’erasure code, c’est aussi le RAID5, qui permet de perdre un disque dur sans perdre ses données. Du point de vue de l’utilisateur, le concept est simple et utile, mais pour la personne qui est chargée de concevoir le logiciel qui fait le travail, c’est un casse-tête. On trouve des boîtiers RAID5 à trois disques dans n’importe quelle boutique : quand l’un d’eux cesse de fonctionner, on le remplace et les fichiers sont toujours là. On pourrait imaginer ça avec six disques dont deux cessent de fonctionner simultanément. Mais non : au lieu d’avoir recours à une opération XOR, assimilable en cinq minutes, il faut des corps de Galois, un bon bagage mathématique et beaucoup de calculs. Pour corser la difficulté, dans un système de stockage distribué tel que Ceph, les disques sont souvent déconnectés temporairement pour cause d’indisponibilité réseau.
Début 2013, j’ai commencé à développer sur Ceph. D’abord parce que c’est un logiciel libre, mais aussi parce que j’ai été attiré par l’ambiance amicale et enjouée de l’équipe. Pendant quelque semaines, j’ai erré dans le projet, découvrant la base de code et me rendant utile en écrivant des tests. À la recherche d’un sujet de travail qui bénéficie à Cloudwatt ( fournisseur d’informatique en nuage ), j’ai été convaincu par Christopher Liljenstolpe d’ajouter l’erasure code dans Ceph. Avec l’accord de Daniel Pays, mon manager, j’ai proposé, lors du premier Ceph Developer Summit, d’en prendre la responsabilité. Samuel Just, lead developer de l’équipe chargée du cœur de Ceph, aurait légitimement pu me conseiller de trouver un sujet moins ambitieux. De même, à diverses reprises, Sage Weil avait mentionné le fait que ce problème était difficile à résoudre. L’avis avisé du fondateur du projet, qui travaille quotidiennement au code depuis dix ans, aurait dû me mettre la puce à l’oreille.
La plupart des développeurs de Ceph sont employés par Intank, et leur agenda est plutôt chargé. Pour me donner toutes les chances, ils ont accepté ma présence lors des mêlées quotidiennes. J’y racontais mes travaux de la journée et posais des questions – la plupart assez naïves. Cela permettait à Sam ou à Sage de m’orienter dans la bonne direction. Plus j’avançais, plus m’apparaissait l’immensité de la tâche. Il fallait trouver une abstraction commune pour la réplication des données et l’erasure code. En procédant par modifications incrémentales, et avec la vision de Sam, j’ai fini par progresser. Mais fin juillet, après un cycle de développement de trois mois, je n’en voyais toujours pas le bout.
Les mathématiques de l’erasure code m’échappent totalement, mais ce ne fut guère une entrave, grâce aux travaux de James S. Plank, chercheur à l’université du Tennessee. Parmi les librairies logiciel libre disponibles, j’ai choisi la sienne (jerasure), parce qu’il en continuait le développement et promettait d’y intégrer ses résultats de recherche publiés début 2013 (promesse tenue fin janvier 2014). En coopération avec Andreas-Joachim Peters, qui travaille au CERN sur ces sujets depuis plusieurs années, nous sommes parvenus à fournir un plugin jerasure fonctionel dans Ceph dès octobre 2013. Il est actuellement utilisé tel quel.
Peu de temps avant le deuxième Ceph Developer Summit, qui s’est tenu début août 2013, j’ai vu avec surprise apparaître l’erasure code sur la roadmap publiée par Inktank : l’échéance était fixée au premier trimestre 2014. Cette promesse marketing s’est traduite courant août par un engagement de l’équipe-cœur de Ceph. Ce qui était au départ une initiative individuelle était devenu un projet à plusieurs : à défaut d’être résolus, les problèmes étaient dès lors partagés. Loin de Los Angeles où les détails se discutaient dans les locaux d’Inktank, je spéculais sur les personnes qui s’attèleraient à la tâche. David Zafman, dont j’avais pu apprécier le travail méticuleux sur des sujets difficiles, me paraissait le candidat le plus probable. Joao Eduardo Luis avait beaucoup à faire avec les moniteurs et, de toute façon, l’essentiel du travail était à faire dans les OSDs. Greg Farnum peut-être, si la finition de la géo-réplication ne durait pas trop longtemps ? J’avais tout faux.
Car au fil des mois, tout le monde s’y est mis, y compris Sage Weil sur tout les fronts, John Wilkins pour la documentation, Mark Nelson pour les benchmarks, Kyle Bader pour l’architecture, Ian Colle pour l’organisation cohérente de ces efforts, et certainement d’autres, invisibles du public. Dans un esprit agile, chacun se voyait attribuer des objectifs pour les sprints de quinze jours. Mais les bornes en étaient régulièrement dépassées et la liste des modifications proposées s’enrichissait constament de nouveaux sujets. Plusieurs fois par semaine je passais quelque heures à commenter le code proposé par les uns et les autres, relevant des problèmes ou suggérant des changements. Symétriquement on se penchait sur mon travail pour le critiquer. Des douzaines de modifications étaient ainsi assemblées tout les jours. La palme revient à Samuel Just qui a accompli l’effort le plus intense dont le point culminant a été une imposante série de patchs en février 2014. En la contemplant, je me suis senti tout petit.
Inktank réunit une rare palette de talents, et c’est un privilège de pouvoir travailler avec eux au quotidien. Le revers de la médaille est qu’il est difficile de trouver sa place. Le plugin d’erasure code était un travail relativement indépendant qui ne requérait pas d’interactions fréquentes. Pendant que j’y mettais la dernière main, je faisais l’effort de lire les patchs se rapportant de près ou de loin à l’erasure code pour trouver une façon d’y participer. À partir du mois de novembre, le plugin jerasure étant terminé, j’ai entrepris de régler les problèmes pouvant surgir lors d’une utilisation réelle des pool erasure codés. Un exercice rendu difficile par le fait qu’il n’était pas encore possible d’instancier un tel pool, David et Sam étant en pleine refonte. Cela m’a amené à mieux comprendre la librairie crush, modifiée pendant cette période par Sage pour les besoins de l’erasure code. Je suis aussi entré dans le moniteur avec Joao pour travailler sur les commandes de création et approcher les concepts de Paxos.
Durant le dernier cycle de développement, tout ce qui rendait exceptionnellement difficile l’ajout de l’erasure code dans Ceph a été résolu, et le code fut assemblé, non sans quelques rebondissements. À la veille du FOSDEM, à Bruxelles, Joao et moi apprenons que le feature freeze est repoussé de quinze jours. Une nouvelle qui permettrait de terminer les codes pyramidaux et de prendre en compte les critiques exprimées par Andreas lors du meetup Ceph qui avait eu lieu dans la journée. Mais la semaine suivante, raisonnablement, je me consacrais à l’ajout de fonctionnalités plus modestes. Après le feature freeze, la chasse aux bugs a commencé avec une rare intensité, et un sentiment d’accomplissement s’est imposé : nous avions dépassé l’objectif.
Je suis content de pouvoir désormais compter sur Ceph pour stocker à moindre coût les films que je partage avec mes amis grâce à l’erasure code, même s’il m’arrive encore de tomber sur des bugs. Il faudra quelque mois pour finaliser cette première version et gagner la confiance des utilisateurs mais, au bout du compte, tout le monde aura une technologie de stockage indestructible et bon marché. J’espère m’attaquer à un autre sujet en 2015 et, cette fois, j’essaierai de viser moins haut. Ou alors la magie du logiciel libre engendrera de nouveau une équipe éphémère, le temps d’un projet aux ambitions démesurées.
Un grand merci à Christophe Courtaut pour nos discussions et son travail sur Ceph.