Chaque année, Google organise l'événement Google Summer of Code, où les principaux projets OpenSource trouvent de nouveaux développeurs talentueux parmi les étudiants. En 2019, notre projet CRIU a réussi non seulement à passer le tour de qualification, mais aussi à attirer plusieurs jeunes développeurs à la fois. Pourquoi tout cela et comment les travaux sur CRUI se sont déroulés dans le cadre du GSoC - lire sous le chat.
Chez Virtuozzo, nous avons un petit projet déjà très populaire appelé CRIU. Il s'agit d'un utilitaire système assez complexe et d'un ensemble de correctifs du noyau (la plupart d'entre eux, d'ailleurs, ont déjà été acceptés dans l'arborescence principale du noyau), avec lesquels vous pouvez faire des choses comme, par exemple, la migration en direct des conteneurs ou mettre à jour le noyau sans redémarrer les applications.
Nous avons commencé ce projet en 2011. Et malgré le fait que l'utilitaire a initialement posé beaucoup de questions et que certains considéraient sa mise en œuvre impossible, CRIU s'est progressivement transformé en un outil mature. À ce jour, plus d'une centaine et demi de contributeurs de plusieurs dizaines d'entreprises, dont des géants tels que Google et IBM, ont réussi à y participer. Malgré cela, la recherche de nouveaux membres se poursuit et cette année, nous avons finalement atteint Google Summer of Code (GSoC).
GSoC est un événement annuel parrainé par Google visant à attirer les étudiants vers divers projets open source. D'une part, des équipes de projets ouverts cherchent à participer à l'événement, et d'autre part, des étudiants qui souhaitent contribuer au développement de la communauté et prouver leur professionnalisme sur des projets réels.
Pour entrer dans l'équipe GSoC, il est nécessaire de soumettre une candidature spécifiant la description du projet, plusieurs sujets sur lesquels les étudiants peuvent travailler et une liste de soi-disant «mentors» - des participants actifs au projet qui aideront l'étudiant dans son travail difficile. Les étudiants doivent sélectionner un ou plusieurs projets et envoyer leur curriculum vitae aux mentors.
Au milieu de l'année scolaire, Google examine les candidatures des équipes et sélectionne les projets qui y participeront, et plus près des vacances d'été, les équipes choisissent les étudiants avec lesquels elles sont prêtes à travailler, après quoi Google procède au filtrage final et répartit les étudiants selon les équipes. En été, le travail commence, qui dure trois mois. Tous les 30 jours, les étudiants soumettent des rapports intermédiaires et leurs mentors évaluent les résultats et font des recommandations pour la poursuite (ou la fin) du travail.
Optimisation de la mémoire et implémentation des journaux binaires
J'avoue qu'en 2019, ce n'était pas notre première tentative d'entrer dans le GSoC. Jusqu'à présent, nous n'avons pas pu passer par l'étape de sélection des projets de Google. Mais nous n'avons pas abandonné (en général, ce n'est pas difficile de soumettre une candidature), et finalement, tout a fonctionné - Google a reconnu le développement de notre projet comme important et a publié CRUI au GSoC.
Nous avions beaucoup de sujets pour les étudiants, un plus beau et plus complexe. Une agréable surprise a été le fait que pour chacun d'eux dans la communauté, il y avait des artistes. Il y avait des gens qui connaissaient les problèmes exprimés et étaient prêts à travailler comme mentor. Au stade de la candidature des étudiants, nous avons reçu tout un «concours» - 2 étudiants ont postulé pour chacun des sujets et presque tous avaient de merveilleuses données d'entrée. La sélection finale nous a permis d'obtenir deux étudiants qui ont abordé des sujets d'optimisation du code de préservation de la mémoire du processus en cours, ainsi que la mise en œuvre de journaux binaires.
Étant donné que CRIU est un système de migration d'application en direct, il a un tel mode de fonctionnement lorsque la mémoire que le processus utilise est lue et écrite dans des fichiers image en parallèle avec l'exécution du processus lui-même. Nous appelons cela «l'opération du cœur vivant» du processus, car il continue de fonctionner sans s'arrêter. Avant le cycle GSoC, toute la mémoire était tirée dans des tuyaux à l'aide de l'appel système vmsplice, qui a fait du bruit à un moment donné, puis le processus a continué à s'exécuter, et CRIU a lentement vidé cette mémoire dans des fichiers (ou dans un canal réseau s'il s'agissait d'une migration en direct). En principe, c'est une approche qui fonctionne, mais le problème était que la mémoire située dans les tuyaux est effectivement verrouillée (mlock) et que le noyau ne peut pas la décharger sur le disque (swap-out) si nécessaire.
D'un point de vue architectural, nous voulions remplacer les tuyaux pour copier la mémoire en petites portions en appelant process_vm_readv. Cette innovation est apparue dans le noyau Linux il n'y a pas si longtemps (au fait, cet appel a un frère jumeau appelé process_vm_writev). Mais en même temps, cela vous permet de faciliter et d'accélérer considérablement, par exemple, le travail de l'utilitaire strace et des débogueurs, qui peuvent être piqués dans la mémoire des processus pour résoudre d'autres tâches.
Le travail sur l'optimisation a été compliqué par le fait que le code pour travailler avec la mémoire de processus est l'un des principaux de l'utilitaire et doit donc être absolument fiable. Toute erreur dans l'enregistrement des pages peut conduire le processus à recevoir un état incohérent de ses objets internes (dont CRIU, bien sûr, ne "sait" rien) et après la récupération, il tombera sans aucun diagnostic clair.
La deuxième difficulté de ce développement était que le travail avec la mémoire est impliqué dans presque toutes les fonctionnalités du CRIU. Ce sont les procédures habituelles de restauration des points de contrôle, ce sont ses différentes versions optimisées, par exemple le pré-vidage ou la lazy-restore. Une fois au cours de la semaine de rapport suivante, nous avions même prévu de «renvoyer» l'étudiant du projet, mais, heureusement, nous ne l'avons pas fait et nous avons maintenant l'optimisation tant attendue dans notre branche devel.
La deuxième tâche dans le cadre de GSoC 2019 a été le développement et la mise en œuvre des journaux dits binaires. Voici la chose: lorsque CRIU fonctionne, l'utilitaire écrit des messages sur son travail dans un fichier (ou sur l'écran, mais encore mieux dans un fichier). L'importance de ces messages est énorme! Si la procédure de sauvegarde ou de restauration pour une raison quelconque ne se termine pas avec succès, la seule façon de comprendre la raison est d'analyser chaque étape de manière aussi détaillée que possible, et pour cela, vous avez besoin d'informations sur l'utilitaire. Idéalement, les procédures nécessitent les journaux et fichiers image les plus détaillés, le cas échéant. En pratique, ces exigences sont difficiles à satisfaire.
Pour obtenir les journaux les plus détaillés, CRIU fournit un mode approprié, et la grande majorité des utilisateurs (et peut-être même tous) l'activent toujours. Mais la quantité d'informations générées par criu dans le processus est si énorme que la journalisation elle-même commence à affecter sensiblement la vitesse du système. Une petite recherche a montré que nous passons 90% de notre temps à nous connecter aux opérations de formatage de sortie - c'est-à-dire aux «mêmes»% d,% 08s,% .2f et autres modificateurs de la famille de fonctions printf. La désactivation des journaux réduit le temps d'enregistrement et de restauration des processus de 10 à 30%, selon la taille des processus eux-mêmes.
Afin de désactiver l'utilisation d'une telle quantité de ressources système pour la journalisation, mais pour laisser les journaux aussi informatifs que possible, nous avons décidé de nous débarrasser du formatage et d'enregistrer les données binaires dans les fichiers journaux. Après tout, vous pouvez les formater plus tard, si nécessaire. Le deuxième étudiant a fait face à cette tâche, dont les correctifs ont également déjà été acceptés dans la branche de développement.
Et pas seulement au GSoC
Soit dit en passant, un autre fait intéressant de participer au GSoC est qu'un troisième étudiant est venu vers nous qui a exprimé le désir de résoudre le problème de l'anonymisation. Après tout, il est souvent impossible d'obtenir des fichiers image car ils contiennent des informations secrètes que l'utilisateur ne veut à juste titre partager avec personne - le contenu de la mémoire, les fichiers avec lesquels le processus travaille, le contenu des files d'attente dans les connexions réseau, etc. Afin de résoudre ce problème, nous avons soumis une fonctionnalité appelée «anonymisation des images» dans l'application, mais Google ne l'a pas acceptée.
Néanmoins, le sujet n'a pas perdu de sa pertinence, et l'étudiant qui a voulu s'y engager dans le cadre du GSoC a finalement décidé de travailler sur la question de manière indépendante, en dehors de l'événement Google.
Conclusion
Ce fut, bien sûr, une expérience positive en participant au GSoC. Notre outil CRIU, que nous aimons et apprécions beaucoup, a reçu quelques impulsions de développement plus puissantes, il est devenu encore plus mature et pratique. Alors à qui cela peut être utile, utilisez-le avec plaisir!
D'un autre côté, nous étions convaincus que la question de la participation à de tels événements est une question de persévérance et de confiance dans notre projet. Si vous avez besoin de développeurs, ne vous fatiguez pas de soumettre des applications et de formuler de nouveaux sujets intéressants. Vous pouvez trouver des contributeurs complètement inattendus d'un autre pays ou même d'une autre entreprise.