Solution NetApp pour le problème de renommage stupide des charges de travail NFS vers Kafka
Suggérer des modifications
PDF
Kafka est construit avec l'hypothèse que le système de fichiers sous-jacent est compatible POSIX : par exemple, XFS ou Ext4. Le rééquilibrage des ressources Kafka supprime les fichiers pendant que l'application les utilise encore. Un système de fichiers compatible POSIX permet de procéder à la dissociation. Cependant, il ne supprime le fichier qu'une fois que toutes les références au fichier ont disparu. Si le système de fichiers sous-jacent est connecté au réseau, le client NFS intercepte les appels de dissociation et gère le flux de travail. Étant donné qu'il existe des ouvertures en attente sur le fichier en cours de dissociation, le client NFS envoie une demande de changement de nom au serveur NFS et, lors de la dernière fermeture du fichier dissocié, émet une opération de suppression sur le fichier renommé. Ce comportement est communément appelé renommage idiot NFS et il est orchestré par le client NFS.
Tout courtier Kafka utilisant le stockage d’un serveur NFSv3 rencontre des problèmes en raison de ce comportement. Cependant, le protocole NFSv4.x dispose de fonctionnalités permettant de résoudre ce problème en permettant au serveur d'assumer la responsabilité des fichiers ouverts et non liés. Les serveurs NFS prenant en charge cette fonctionnalité facultative communiquent la capacité de propriété au client NFS au moment de l'ouverture du fichier. Le client NFS cesse alors la gestion de la dissociation lorsqu'il y a des ouvertures en attente et permet au serveur de gérer le flux. Bien que la spécification NFSv4 fournisse des directives pour la mise en œuvre, jusqu'à présent, il n'existait aucune implémentation de serveur NFS connue prenant en charge cette fonctionnalité facultative.
Les modifications suivantes sont nécessaires pour que le serveur NFS et le client NFS résolvent le problème de renommage stupide :
-
Modifications apportées au client NFS (Linux). Au moment de l'ouverture du fichier, le serveur NFS répond avec un indicateur, indiquant la capacité à gérer la dissociation des fichiers ouverts. Les modifications côté client NFS permettent au serveur NFS de gérer la dissociation en présence de l'indicateur. NetApp a mis à jour le client NFS Linux open source avec ces modifications. Le client NFS mis à jour est désormais généralement disponible dans RHEL8.7 et RHEL9.1.
-
Modifications apportées au serveur NFS. Le serveur NFS garde une trace des ouvertures. La dissociation d'un fichier ouvert existant est désormais gérée par le serveur pour correspondre à la sémantique POSIX. Lorsque la dernière ouverture est fermée, le serveur NFS lance alors la suppression effective du fichier et évite ainsi le processus de renommage stupide. Le serveur ONTAP NFS a implémenté cette capacité dans sa dernière version, ONTAP 9.12.1.
Grâce aux modifications ci-dessus apportées au client et au serveur NFS, Kafka peut profiter en toute sécurité de tous les avantages du stockage NFS connecté au réseau.