Een Apache Kafka-storing treedt op wanneer een Kafka-cluster of enkele van zijn componenten falen, resulterend in onderbreking of degradatie van de service. Kafka is ontworpen om hoge doorvoer, fouttolerante gegevensstromen en berichtenverkeer aan te kunnen, maar het kan om verschillende redenen falen, waaronder infrastructuurstoringen, verkeerde configuraties en operationele problemen.
Waarom er Kafka-storingen optreden
Brokerstoring
Een overmatige gegevensbelasting of te grote hardware kan ervoor zorgen dat een broker niet meer reageert, hardwarestoring door een harde schijfcrash, geheugenuitputting of netwerkproblemen van de broker.
ZooKeeper-problemen
Kafka vertrouwt op Apache ZooKeeper om clustermetadata en leiderverkiezing te beheren. ZooKeeper-storingen (als gevolg van netwerkpartities, verkeerde configuratie of resource-uitputting) kunnen de werking van Kafka verstoren. De ZooKeeper-problemen kunnen worden weggelaten als het cluster is geconfigureerd in KRaft-modus met de latere versie 3.5 van Apache Kafka.
Verkeerde configuratie van het onderwerp
Onvoldoende replicatiefactoren of onjuiste partitieconfiguratie kunnen leiden tot gegevensverlies of serviceonderbrekingen wanneer een broker uitvalt.
Netwerkpartities
Communicatiestoringen tussen brokers, clients of ZooKeeper kunnen de beschikbaarheid verminderen of split-brain scenario’s veroorzaken.
Verkeerde configuratie
Verkeerd geconfigureerde clusterinstellingen (retentiebeleid, replicatoewijzing, enz.) kunnen leiden tot onverwacht gedrag en storingen.
Overbelasting
Een plotselinge toename van producenten- of consumentenverkeer kan een cluster overbelasten.
Datacorruptie
Kafka-logcorruptie (als gevolg van schijfproblemen of abrupte afsluiting) kan opstart- of gegevensherstelproblemen veroorzaken.
Ondoende monitoring en waarschuwingen
Als vroege waarschuwingssignalen (zoals pieken in schijfgebruik of lange latentie) onopgemerkt blijven en niet worden aangepakt, kunnen kleine problemen leiden tot volledige storingen.
Back-ups van Apache Kafka-onderwerpen en configuraties zijn belangrijk voor rampenherstel omdat ze ons in staat stellen onze gegevens en instellingen te herstellen in geval van hardwarestoringen, softwareproblemen of menselijke fouten. Kafka heeft geen ingebouwde tools voor onderwerpback-up, maar we kunnen dit bereiken met behulp van een paar methoden.
Hoe Apache Kafka-onderwerpen en configuraties te back-uppen
Er zijn meerdere manieren waarop we onderwerpen en configuraties kunnen back-uppen.
Kafka-consumenten
We kunnen Kafka-consumenten gebruiken om berichten van het onderwerp te lezen en ze op te slaan in externe opslag zoals HDFS, S3 of lokale opslag. Door betrouwbare Kafka-consumententools te gebruiken zoals de ingebouwde kafka-console-consumer.sh of aangepaste consumentenscripts, kunnen alle berichten vanaf de vroegste offset worden geconsumeerd. Deze procedure is eenvoudig en aanpasbaar, maar vereist veel opslag voor onderwerpen met een hoog doorvoervermogen en kan metadata zoals tijdstempels of headers verliezen.
Kafka Connect
Door berichten van onderwerpen naar Object Storage te streamen met behulp van tools zoals Kafka Connect. We kunnen Kafka Connect opzetten met een sink-connector (bijv. S3 Sink-connector, JDBC Sink-connector, enz.), de connector configureren om van specifieke onderwerpen te lezen en naar de back-upbestemming te schrijven. Natuurlijk hebben we een extra opstelling nodig voor Kafka Connect.
Clusterreplicatie
De spiegelfunctie van Kafka stelt ons in staat om replica’s van een bestaande Kafka-cluster te beheren. Het verbruikt berichten van een brondcluster met behulp van een Kafka-consument en publiceert die berichten opnieuw naar een ander Kafka-cluster, dat kan dienen als een back-up met behulp van een ingebedde Kafka-producent. We moeten ervoor zorgen dat het back-upcluster zich in een aparte fysieke of cloudregio bevindt voor redundantie. Kan naadloze replicatie bereiken en ondersteunt incrementele back-ups, maar heeft een hogere operationele overhead om het back-upcluster te onderhouden.
Kopieën op bestandsniveau
Bestandsysteemback-ups, zoals het kopiëren van Kafka-logboekmappen rechtstreeks van de Kafka-brokers, kunnen worden uitgevoerd door de Kafka-logboekmap te identificeren (log.dirs in server.properties). Deze methode maakt het mogelijk om offsets en partitiegegevens te behouden. Het vereist echter zorgvuldige herstelprocessen om consistentie te waarborgen en potentiële problemen te vermijden.
Kafka-configuraties en metadata
Wat betreft Kafka-configuratie, kunnen we metadata specificeren over onderwerpen, toegangsbeheer (ACL), het server.properties-bestand van alle brokers, en de ZooKeeper-gegevensmap (zoals gedefinieerd door de dataDir-parameter in de configuratie van ZooKeeper). Vervolgens het uitvoer naar een bestand opslaan ter referentie. We moeten ervoor zorgen dat alle aangepaste instellingen (bijv. log.retention.ms, num.partitions) gedocumenteerd zijn. Met behulp van het ingebouwde script kafka-acls.sh kunnen alle acl-eigenschappen worden geconsolideerd in een plat bestand.
Belangrijkste punten
De besproken praktijken zijn voornamelijk geschikt voor clusters die on-premises zijn geïmplementeerd en beperkt zijn tot clusters geconfigureerd met een enkel cijfer. Echter, beheerde serviceproviders hanteren de operationele beste praktijken voor het draaien van het platform, dus hoeven we ons geen zorgen te maken over het detecteren en oplossen van problemen.
Door dit artikel te lezen, hoop ik dat je praktische inzichten en bewezen strategieën zult opdoen om Apache Kafka-storingen aan te pakken in on-premises implementaties.
Source:
https://dzone.com/articles/avoid-kafka-outages-with-topic-and-configuration-backups