Una interrupción de Apache Kafka ocurre cuando un clúster de Kafka o algunos de sus componentes fallan, lo que resulta en una interrupción o degradación del servicio. Kafka está diseñado para manejar flujos de datos y mensajería de alto rendimiento y tolerancia a fallos, pero puede fallar por diversas razones, incluidas fallos de infraestructura, configuraciones incorrectas y problemas operativos.
Por qué ocurre una interrupción de Kafka
Fallo del Broker
Cargas de datos excesivas o hardware sobredimensionado hacen que un broker se vuelva no responsivo, fallos de hardware debido a un fallo en el disco duro, agotamiento de memoria o problemas de red del broker.
Problemas de ZooKeeper
Kafka depende de Apache ZooKeeper para gestionar los metadatos del clúster y la elección de líderes. Los fallos de ZooKeeper (debido a particiones de red, configuraciones incorrectas o agotamiento de recursos) pueden interrumpir las operaciones de Kafka. Los problemas de ZooKeeper pueden omitirse si el clúster se ha configurado en modo KRaft con la versión 3.5 posterior de Apache Kafka.
Configuración Incorrecta del Tema
Factores de replicación insuficientes o una configuración incorrecta de particiones pueden causar pérdida de datos o interrupciones del servicio cuando un broker falla.
Particiones de Red
Fallos de comunicación entre brokers, clientes o ZooKeeper pueden reducir la disponibilidad o causar escenarios de “cerebro dividido”.
Configuración Incorrecta
La configuración incorrecta de un clúster (políticas de retención, asignación de réplicas, etc.) puede provocar un comportamiento inesperado y fallos.
Sobrecarga
Un aumento repentino en el tráfico de productores o consumidores puede sobrecargar un clúster.
Corrupción de Datos
La corrupción de registros de Kafka (debido a problemas de disco o apagado abrupto) puede causar problemas al iniciar o recuperar datos.
Monitoreo y Alertas Inadecuados
Si las señales de advertencia temprana (como picos en el uso de disco o latencias largas) pasan desapercibidas y sin resolver, problemas menores pueden provocar fallos completos.
Las copias de seguridad de los temas y configuraciones de Apache Kafka son importantes para la recuperación ante desastres, ya que nos permiten restaurar nuestros datos y ajustes en caso de fallo de hardware, problemas de software o errores humanos. Kafka no tiene herramientas integradas para la copia de seguridad de temas, pero podemos lograrlo utilizando un par de métodos.
Cómo hacer copias de seguridad de temas y configuraciones de Kafka
Existen múltiples formas de hacer copias de seguridad de temas y configuraciones.
Consumidores de Kafka
Podemos usar consumidores de Kafka para leer mensajes del tema y almacenarlos en almacenamiento externo como HDFS, S3 o almacenamiento local. Usando herramientas de consumidor de Kafka confiables como el kafka-console-consumer.sh incorporado o scripts de consumidores personalizados, se pueden consumir todos los mensajes del tema desde el desplazamiento más antiguo. Este procedimiento es simple y personalizable, pero requiere un almacenamiento grande para temas de alto rendimiento y podría perder metadatos como marcas de tiempo o encabezados.
Conexión de Kafka
Al transmitir mensajes desde temas a Almacenamiento de Objetos utilizando herramientas como Kafka Connect. Podemos configurar Kafka Connect con un conector de salida (por ejemplo, Conector de Salida S3, Conector de Salida JDBC, etc.), configurar el conector para leer de temas específicos y escribir en el destino de respaldo. Por supuesto, necesitamos tener una configuración adicional para Kafka Connect.
Replicación de Clúster
La función de espejado de Kafka nos permite gestionar réplicas de un clúster de Kafka existente. Consume mensajes de un clúster fuente utilizando un consumidor de Kafka y republica esos mensajes a otro clúster de Kafka, que puede servir como respaldo utilizando un productor de Kafka integrado. Debemos asegurarnos de que el clúster de respaldo esté en una región física o en la nube separada para redundancia. Se puede lograr replicación sin interrupciones y soportar copias de seguridad incrementales, pero con un mayor costo operativo para mantener el clúster de respaldo.
Copias a Nivel de Sistema de Archivos
Las copias de seguridad a nivel de sistema de archivos, como copiar los directorios de registro de Kafka directamente desde los brokers de Kafka, pueden realizarse identificando el directorio de registro de Kafka (log.dirs en server.properties). Este método permite la preservación de los desplazamientos y los datos de las particiones. Sin embargo, requiere procesos meticulosos de restauración para garantizar la consistencia y evitar posibles problemas.
Configuraciones y Metadatos de Kafka
En cuanto a la configuración de Kafka, podemos especificar metadatos sobre temas, control de acceso (ACL), archivo server.properties de todos los brokers y el directorio de datos de ZooKeeper (como se define por el parámetro dataDir en la configuración de ZooKeeper). Posteriormente, guardar la salida en un archivo para referencia. Necesitamos asegurarnos de que todas las configuraciones personalizadas (por ejemplo, log.retention.ms, num.partitions) estén documentadas. Utilizando el script integrado kafka-acls.sh, todas las propiedades de acl pueden consolidarse en un archivo plano.
Lo Esencial
Las prácticas discutidas anteriormente son principalmente adecuadas para clústeres implementados localmente y limitados a nodos de un solo dígito configurados en el clúster. Sin embargo, los proveedores de servicios gestionados manejan las mejores prácticas operativas para ejecutar la plataforma, por lo que no es necesario preocuparse por detectar y solucionar problemas.
Al leer este artículo, espero que obtenga ideas prácticas y estrategias comprobadas para abordar las interrupciones de Apache Kafka en implementaciones locales.
Source:
https://dzone.com/articles/avoid-kafka-outages-with-topic-and-configuration-backups