Un’interruzione di Apache Kafka si verifica quando un cluster Kafka o alcuni dei suoi componenti falliscono, causando un’interruzione o un degrado del servizio. Kafka è progettato per gestire streaming e messaggistica di dati ad alta capacità e tollerante ai guasti, ma può fallire per una varietà di motivi, tra cui guasti dell’infrastruttura, misconfigurazioni e problemi operativi.
Perché si verifica un’interruzione di Kafka
Guasto del Broker
Un carico di dati eccessivo o hardware sovradimensionato può causare l’assenza di risposta di un broker, guasti hardware dovuti a crash del disco rigido, esaurimento della memoria o problemi di rete del broker.
Problemi di ZooKeeper
Kafka si affida a Apache ZooKeeper per gestire i metadati del cluster e l’elezione del leader. I guasti di ZooKeeper (a causa di partizioni di rete, misconfigurazione o esaurimento delle risorse) possono interrompere le operazioni di Kafka. I problemi di ZooKeeper possono essere omessi se il cluster è stato configurato in modalità KRaft con la versione 3.5 successiva di Apache Kafka.
Misconfigurazione dei Topic
Fattori di replica insufficienti o configurazioni di partizione improprie possono causare perdita di dati o interruzioni del servizio quando un broker fallisce.
Partizioni di Rete
I guasti di comunicazione tra broker, client o ZooKeeper possono ridurre la disponibilità o causare scenari di split-brain.
Misconfigurazione
Le impostazioni del cluster misconfigurate (politiche di retention, allocazione delle repliche, ecc.) possono portare a comportamenti inattesi e guasti.
Sovraccarico
Un improvviso aumento del traffico dei produttori o dei consumatori può sovraccaricare un cluster.
Corruzione dei Dati
La corruzione dei log di Kafka (causata da problemi di disco o spegnimenti improvvisi) può causare problemi di avvio o di recupero dei dati.
Monitoraggio e Notifiche Inadeguate
Se i segnali di allerta precoci (come picchi nell’uso del disco o alta latenza) non vengono riconosciuti e affrontati, problemi minori possono portare a guasti completi.
I backup dei topic e delle configurazioni di Apache Kafka sono importanti per il ripristino da disastri perché ci permettono di ripristinare i nostri dati e le impostazioni in caso di guasti hardware, problemi software o errori umani. Kafka non dispone di strumenti integrati per il backup dei topic, ma possiamo ottenere questo utilizzando un paio di metodi.
Come eseguire il backup dei Topic e delle Configurazioni di Kafka
Ci sono diversi modi che possiamo seguire per eseguire il backup dei topic e delle configurazioni.
Consumatori Kafka
Possiamo utilizzare i consumatori Kafka per leggere i messaggi dal topic e memorizzarli in storage esterni come HDFS, S3 o storage locale. Utilizzando strumenti affidabili di consumatori Kafka come il kafka-console-consumer.sh integrato o script di consumatori personalizzati, tutti i messaggi dal topic possono essere consumati dal precedente offset. Questa procedura è semplice e personalizzabile ma richiede un grande spazio di archiviazione per i topic ad alta velocità e potrebbe perdere metadati come timestamp o intestazioni.
Kafka Connect
Trasmettendo i messaggi dai topic all’Object Storage utilizzando strumenti come Kafka Connect. Possiamo configurare Kafka Connect con un connettore sink (ad esempio, S3 Sink Connector, JDBC Sink Connector, ecc.), configurare il connettore per leggere da specifici topic e scrivere nella destinazione di backup. Naturalmente, è necessaria una configurazione aggiuntiva per Kafka Connect.
Replicazione del Cluster
La funzione di replica di Kafka ci consente di gestire repliche di un esistente cluster Kafka. Consuma messaggi da un cluster di origine utilizzando un consumatore Kafka e ripubblica quei messaggi su un altro cluster Kafka, che può fungere da backup utilizzando un produttore Kafka integrato. È necessario assicurarsi che il cluster di backup sia in una regione fisica o cloud separata per la ridondanza. Può raggiungere una replica senza interruzioni e supportare backup incrementali ma richiede un overhead operativo maggiore per mantenere il cluster di backup.
Copie a Livello di Filesystem
I backup a livello di filesystem, come copiare le directory dei log di Kafka direttamente dai broker di Kafka, possono essere eseguiti identificando la directory dei log di Kafka (log.dirs in server.properties). Questo metodo consente la conservazione degli offset e dei dati delle partizioni. Tuttavia, richiede processi di ripristino meticolosi per garantire la coerenza ed evitare potenziali problemi.
Configurazioni e metadati di Kafka
Per quanto riguarda la configurazione di Kafka, possiamo specificare metadati sui topic, controllo degli accessi (ACL), il file server.properties di tutti i broker e la directory dei dati di ZooKeeper (come definito dal parametro dataDir nella configurazione di ZooKeeper). Successivamente, salvare l’output in un file per riferimento. Dobbiamo assicurarci che tutte le impostazioni personalizzate (ad es. log.retention.ms, num.partitions) siano documentate. Utilizzando lo script integrato kafka-acls.sh, tutte le proprietà acl possono essere consolidate in un file piatto.
Conclusione
Le pratiche discusse sopra sono principalmente adatte per cluster distribuiti in locale e limitati a un numero di nodi a cifra singola configurati nel cluster. Tuttavia, i fornitori di servizi gestiti gestiscono le migliori pratiche operative per eseguire la piattaforma, quindi non dobbiamo preoccuparci di rilevare e risolvere problemi.
Leggendo questo articolo, spero che acquisirai conoscenze pratiche e strategie comprovate per affrontare le interruzioni di Apache Kafka nelle distribuzioni in locale.
Source:
https://dzone.com/articles/avoid-kafka-outages-with-topic-and-configuration-backups