Une panne d’Apache Kafka se produit lorsqu’un cluster Kafka ou certains de ses composants échouent, entraînant une interruption ou une dégradation du service. Kafka est conçu pour gérer le streaming de données à haut débit et les messages tolérants aux pannes, mais il peut échouer pour diverses raisons, notamment des défaillances de l’infrastructure, des mauvaises configurations et des problèmes opérationnels. Les pannes de Kafka peuvent survenir pour plusieurs raisons :
Pourquoi les pannes de Kafka surviennent
Défaillance du courtier
Une charge de données excessive ou un matériel surdimensionné peut rendre un courtier non réactif, une panne matérielle due à un crash du disque dur, une épuisement de la mémoire ou des problèmes réseau du courtier.
Problèmes de ZooKeeper
Kafka s’appuie sur Apache ZooKeeper pour gérer les métadonnées du cluster et l’élection du leader. Les pannes de ZooKeeper (en raison de partitions réseau, de mauvaises configurations ou d’épuisement des ressources) peuvent perturber les opérations de Kafka. Les problèmes de ZooKeeper peuvent être évités si le cluster a été configuré en mode KRaft avec la version ultérieure 3.5 d’Apache Kafka.
Mauvaise configuration des sujets
Des facteurs de réplication insuffisants ou une configuration incorrecte des partitions peuvent entraîner une perte de données ou des interruptions de service lorsqu’un courtier échoue.
Partitions réseau
Les échecs de communication entre les courtiers, les clients ou ZooKeeper peuvent réduire la disponibilité ou provoquer des scénarios de cerveau divisé.
Mauvaise configuration
Des paramètres de cluster mal configurés (politiques de rétention, allocation de réplicas, etc.) peuvent entraîner un comportement inattendu et des échecs.
Surchargé
Une augmentation soudaine du trafic des producteurs ou des consommateurs peut surcharger un cluster.
Corruption des données
La corruption des logs Kafka (due à des problèmes de disque ou à un arrêt brutal) peut entraîner des problèmes de démarrage ou de récupération des données.
Surveillance et alerte inadéquates
Si les signaux d’alerte précoce (comme des pics d’utilisation du disque ou une latence élevée) ne sont pas reconnus et traités, des problèmes mineurs peuvent entraîner des échecs complets.
Les sauvegardes des sujets et des configurations Apache Kafka sont importantes pour la reprise après sinistre car elles nous permettent de restaurer nos données et paramètres en cas de défaillance matérielle, de problèmes logiciels ou d’erreur humaine. Kafka ne dispose pas d’outils intégrés pour la sauvegarde des sujets, mais nous pouvons y parvenir en utilisant quelques méthodes.
Comment sauvegarder les sujets et les configurations de Kafka
Il existe plusieurs façons de sauvegarder les sujets et les configurations.
Consommateurs Kafka
Nous pouvons utiliser les consommateurs Kafka pour lire les messages du sujet et les stocker dans un stockage externe tel que HDFS, S3 ou un stockage local. En utilisant des outils de consommation Kafka fiables tels que le kafka-console-consumer.sh intégré ou des scripts consommateurs personnalisés, tous les messages du sujet peuvent être consommés depuis le décalage le plus ancien. Cette procédure est simple et personnalisable mais nécessite un grand espace de stockage pour les sujets à haut débit et peut perdre des métadonnées telles que les horodatages ou les en-têtes.
Kafka Connect
En diffusant les messages des sujets vers le stockage objet en utilisant des outils tels que Kafka Connect. Nous pouvons configurer Kafka Connect avec un connecteur cible (par exemple, Connecteur de destination S3, Connecteur de destination JDBC, etc.), configurer le connecteur pour lire à partir de sujets spécifiques et écrire vers la destination de sauvegarde. Bien sûr, nous devons avoir une configuration supplémentaire pour Kafka Connect.
Réplication de cluster
La fonction de mise en miroir de Kafka nous permet de gérer des répliques d’un cluster Kafka existant. Elle consomme des messages d’un cluster source en utilisant un consommateur Kafka et republie ces messages vers un autre cluster Kafka, qui peut servir de sauvegarde en utilisant un producteur Kafka intégré. Nous devons nous assurer que le cluster de sauvegarde est dans une région physique ou cloud séparée pour la redondance. Peut atteindre une réplication transparente et prendre en charge des sauvegardes progressives mais entraîne des frais opérationnels plus élevés pour maintenir le cluster de sauvegarde.
Copies au niveau du système de fichiers
Les sauvegardes au niveau du système de fichiers, telles que la copie des répertoires de journaux Kafka directement depuis les courtiers Kafka, peuvent être effectuées en identifiant le répertoire de journal Kafka (log.dirs dans server.properties). Cette méthode permet de préserver les décalages et les données de partition. Cependant, elle nécessite des processus de restauration méticuleux pour assurer la cohérence et éviter d’éventuels problèmes.
Configurations et métadonnées de Kafka
En termes de configuration Kafka, nous pouvons spécifier des métadonnées sur les sujets, le contrôle d’accès (ACL), le fichier server.properties de tous les courtiers, et le répertoire de données ZooKeeper (tel que défini par le paramètre dataDir dans la configuration de ZooKeeper). Ensuite, enregistrer la sortie dans un fichier pour référence. Nous devons nous assurer que tous les paramètres personnalisés (par exemple, log.retention.ms, num.partitions) soient documentés. En utilisant le script intégré kafka-acls.sh, toutes les propriétés acl peuvent être consolidées dans un fichier plat.
Conclusion
Les pratiques discutées ci-dessus conviennent principalement aux clusters déployés sur site et limités à des nœuds à un chiffre configurés dans le cluster. Cependant, les fournisseurs de services gérés gèrent les meilleures pratiques opérationnelles pour faire fonctionner la plateforme, donc nous n’avons pas besoin de nous inquiéter de détecter et de résoudre les problèmes.
En lisant cet article, j’espère que vous obtiendrez des informations pratiques et des stratégies éprouvées pour faire face aux pannes d’Apache Kafka dans les déploiements sur site.
Source:
https://dzone.com/articles/avoid-kafka-outages-with-topic-and-configuration-backups