Les versions récentes de Podman, Buildah et CRI-O ont commencé à tirer parti d'une nouvelle fonctionnalité du noyau, les montages de superposition volatile. Cette fonctionnalité vous permet de monter un système de fichiers superposé avec un indicateur lui indiquant de ne pas se synchroniser avec le disque.
Si vous avez besoin d'un rappel sur l'utilisation et les avantages des supports de superposition, consultez mon article de l'été dernier.
Qu'est-ce que la synchronisation et pourquoi est-ce important ?
Sous Linux, lorsque vous écrivez dans un fichier ou un répertoire, le noyau n'écrit pas instantanément les données sur le disque. Au lieu de cela, il met en mémoire tampon un tas d'écritures, puis enregistre périodiquement les données sur le disque pour augmenter les performances. C'est ce qu'on appelle une synchronisation . Le problème avec ceci est qu'un processus pense les données ont été enregistrées lorsque l'écriture est terminée, mais ce n'est vraiment pas avant que le noyau ne synchronise ces données. Cela signifie que si vous avez écrit des données et que le noyau a planté, il est possible que les données n'aient jamais été enregistrées.
Pour cette raison, de nombreux systèmes de fichiers se synchronisent régulièrement et les outils peuvent demander que la synchronisation se produise souvent. Lorsqu'une synchronisation se produit, le noyau arrête de traiter les données avec un verrou et synchronise toutes les données sur le disque. Bien sûr, cela entraîne de moins bonnes performances. Si vous avez un processus qui provoque fréquemment des synchronisations, les performances de votre travail peuvent vraiment être affectées. Certains outils comme RPM demandent une synchronisation après l'écriture de chaque fichier sur le disque, ce qui entraîne le vidage de toutes les pages sales de ce fichier, et c'est une surcharge considérable.
[ Vous débutez avec les conteneurs ? Découvrez ce cours gratuit. Déploiement d'applications conteneurisées :présentation technique. ]
Les conteneurs n'ont peut-être pas besoin d'être synchronisés
Dans le monde des conteneurs, nous avons de nombreux cas d'utilisation où nous ne nous soucions pas de savoir si les données sont enregistrées. Si le noyau plantait, nous n'utiliserions de toute façon pas les données écrites.
Lorsque vous faites un buildah bud ou podman build , l'image du conteneur est écrite sur un point de montage de superposition, souvent à l'aide de DNF ou YUM. Si le noyau plantait au milieu de la création d'une image, le contenu écrit sur la couche de superposition serait inutile et devrait être nettoyé par l'utilisateur. Tout ce qui n'a pas été écrit serait simplement supprimé. Lorsque la construction est terminée, cependant, la couche de superposition est compressée dans un ensemble d'images qui peut ensuite être synchronisé sur le disque.
Un autre cas d'utilisation pour les montages de superposition volatile consiste à exécuter Podman avec le --rm drapeau. Le --rm indique à Podman de détruire le conteneur et le point de montage de superposition lorsque le conteneur est terminé. Un plantage du conteneur laisserait du contenu dont l'utilisateur a déjà indiqué qu'il n'avait aucune utilité, il n'y a donc aucune raison de se soucier de savoir si une écriture a réussi.
Dans le monde Kubernetes, CRI-O est le moteur de conteneur. Kubernetes est presque toujours configuré pour supprimer tous les conteneurs au démarrage. Fondamentalement, il veut commencer avec un état propre. Cela signifie que si le noyau tombait en panne alors que les données étaient en cours d'écriture sur le montage de superposition, ces données seraient détruites dès le démarrage du système. Il est également sûr d'utiliser de telles configurations avec des conteneurs avec état, car les données sont généralement écrites sur des volumes externes qui ne seront pas affectés par l'indicateur "volatile" lors de l'exécution.
Ajout d'une option volatile
L'ingénieur de l'équipe de conteneurs, Giuseppe Scrivano, a remarqué ces cas d'utilisation et a pensé que nous pourrions améliorer les performances en ajoutant une option volatile au système de fichiers de superposition du noyau Linux et a implémenté ce comportement. Par conséquent, les nouvelles versions de Buildah, Podman et CRI-O utiliseront par défaut l'indicateur volatile dans ces cas d'utilisation et, espérons-le, obtiendront de meilleures performances.
Notez que tous les volumes montés dans le conteneur continueront d'avoir le comportement de synchronisation par défaut des systèmes de fichiers typiques, vous n'avez donc pas à vous soucier de perdre des données écrites sur le stockage permanent.
Le graphique ci-dessous montre comment le nombre d'IOPS en écriture est réduit dans un conteneur qui exécute yum install -y texlive sur une machine avec 16 Go de RAM. De plus, lorsque le conteneur s'exécute avec l'indicateur volatile activé, son horloge murale est également affectée et se termine plus rapidement.
Les pages modifiées seront éventuellement écrites sur le stockage une fois que le taux de modification ou le délai d'expiration de l'inode aura expiré, car ces paramètres ne sont pas affectés par l'indicateur de montage volatil.
Récapitulez
Avec la technologie des conteneurs, nous repoussons constamment les limites de ce que le système Linux peut gérer et expérimentons de nouveaux cas d'utilisation. L'ajout d'une option volatile au système de fichiers de superposition du noyau contribue à augmenter les performances, permettant aux conteneurs de continuer à évoluer et à offrir de plus grands avantages.
[ Téléchargement gratuit :Aide-mémoire sur les commandes avancées de Linux. ]