fbpx

IL BLOG DEGLI RHCE ITALIANI

Kafka Cluster Community 5.5 su RHEL o CentOS

Fabio Felici
Fabio Felici
RHCSA

Introduciamo kafka


Apache Kafka è una piattaforma di streaming distribuita.

In Kafka la comunicazione tra client e server avviene con un protocollo TCP agnostico di linguaggio semplice e ad alte prestazioni . Questo protocollo ha una versione e mantiene la compatibilità con le versioni precedenti. E’ presente un client Java per Kafka, ma i client sono disponibili in molti linguaggi.

Ecco una descrizione di alcuni dei più noti casi d’uso di Apache Kafka


Messaggistica: Kafka funziona bene come sostituto di un broker di messaggi più tradizionale. I broker di messaggi vengono utilizzati per una serie di motivi. Rispetto alla maggior parte dei sistemi di messaggistica, Kafka offre un throughput, una partizione, una replica e una tolleranza agli errori migliori che lo rendono una buona soluzione per le applicazioni di elaborazione dei messaggi su larga scala.

Monitoraggio dell’attività del sito Web: Il caso d’uso originale di Kafka era di poter ricostruire una pipeline di tracciamento delle attività degli utenti come un insieme di feed di sottoscrizione e pubblicazione in tempo reale. Ciò significa che l’attività del sito è pubblicata su argomenti centrali con un argomento per tipo di attività.

Metrica: Kafka viene spesso utilizzato per i dati di monitoraggio operativo. Ciò comporta l’aggregazione delle statistiche dalle applicazioni distribuite per produrre feed centralizzati di dati operativi.

Aggregazione di log: Molte persone usano Kafka in sostituzione di una soluzione di aggregazione dei registri. L’aggregazione dei log in genere raccoglie i file di log fisici dai server e li mette in una posizione centrale (un file server o forse HDFS) per l’elaborazione. Kafka estrae i dettagli dei file e fornisce un’astrazione più pulita dei dati di registro o di eventi come flusso di messaggi. Ciò consente un’elaborazione a latenza inferiore e un supporto più semplice per più origini dati e consumo di dati distribuiti.

Elaborazione del flusso: Molti utenti di Kafka elaborano i dati nell’elaborazione di pipeline costituite da più fasi, in cui i dati di input non elaborati vengono consumati dagli argomenti di Kafka e quindi aggregati, arricchiti o altrimenti trasformati in nuovi argomenti per ulteriori consumi o ulteriori elaborazioni. Ad esempio, una pipeline di elaborazione per raccomandare articoli di notizie potrebbe sottoporre a scansione il contenuto dell’articolo dai feed RSS e pubblicarlo su un argomento “articoli”; un’ulteriore elaborazione potrebbe normalizzare o deduplicare questo contenuto e pubblicare il contenuto dell’articolo pulito su un nuovo argomento.

Sourcing di eventi: Il sourcing degli eventi è uno stile di progettazione dell’applicazione in cui le modifiche di stato vengono registrate come una sequenza di record ordinata per tempo. Il supporto di Kafka per dati di registro archiviati molto grandi lo rende un eccellente backend per un’applicazione costruita in questo stile.

Salva registro: Kafka può servire come una sorta di commit-log esterno per un sistema distribuito. Il registro aiuta a replicare i dati tra i nodi e funge da meccanismo di ri-sincronizzazione per i nodi non riusciti per ripristinare i loro dati. La funzione di compattazione dei registri in Kafka aiuta a supportare questo utilizzo.

Una piattaforma di streaming ha tre elementi chiave:


Kafka è generalmente usato per due grandi classi di applicazioni:


Per capire come Kafka fa queste cose, immergiamoci ed esploriamo le capacità di Kafka dal basso verso l’alto.

Innanzitutto alcuni concetti:

Kafka ha cinque API principali:

Otteniamo il software


Importiamo la chiave

$ sudo rpm --import https://packages.confluent.io/rpm/5.5/archive.key

Creiamo un file con le informazioni della repository /etc/yum.repos.d/confluent.rep e aggiungiamo il testo riportato sotto.

[Confluent.dist]
name=Confluent repository (dist)
baseurl=https://packages.confluent.io/rpm/5.5/7
gpgcheck=1
gpgkey=https://packages.confluent.io/rpm/5.5/archive.key
proxy=http://10.48.20.107:80
enabled=1
[Confluent]
name=Confluent repository
baseurl=https://packages.confluent.io/rpm/5.5
gpgcheck=1
gpgkey=https://packages.confluent.io/rpm/5.5/archive.key
proxy=http://10.48.20.107:80
enabled=1

Procediamo ad installare il nostro software community di Kafka.

$ sudo yum clean all && sudo yum install confluent-community-2.12

Se l’installazione è andata a buon fine lanciando il comando riportato sotto otterremo la stessa lista di pacchetti.

$ rpm -qa | grep confluent
confluent-rest-utils-5.5.0-1.noarch
confluent-schema-registry-5.5.0-1.noarch
confluent-kafka-2.12-5.5.0-1.noarch
confluent-common-5.5.0-1.noarch
confluent-kafka-connect-storage-common-5.5.0-1.noarch
confluent-kafka-rest-5.5.0-1.noarch
confluent-ksqldb-5.5.0-1.noarch
confluent-kafka-connect-jdbc-5.5.0-1.noarch
confluent-community-2.12-5.5.0-1.noarch
confluent-kafka-connect-s3-5.5.0-1.noarch
confluent-kafka-connect-elasticsearch-5.5.0-1.noarch
confluent-hub-client-5.5.0-1.noarch

Configurazione del cluster


Adesso andiamo a configurare la parte zookeeper editando il file /etc/kafka/zookeeper.properties con le configurazione qui sotto.

tickTime=2000
dataDir=/var/lib/zookeeper/
clientPort=2181
initLimit=5
syncLimit=2
server.1=zoo1:2888:3888
server.2=zoo2:2888:3888
server.3=zoo3:2888:3888
autopurge.snapRetainCount=3
autopurge.purgeInterval=24

Sostituire/Eliminare/Aggiungere, a seconda della nostra installazione i parametri dei server ( zoo1, zoo2, zoo3 ) con i nostri host.

Questa configurazione è per un cluster a tre nodi. Questo file di configurazione dovrebbe essere identico per tutti i nodi cluster. tickTimedataDirclientPortsono tutti impostati sui valori tipici di un singolo server.  L’initLimitsyncLimit gestiscono quanto tempo seguenti server zookeeper possono prendere per inizializzare con l’attuale leader e per quanto tempo possono essere sincronizzati con il leader. In questa configurazione, un follower può richiedere 10000 ms per l’inizializzazione e può non essere sincronizzato per un massimo di 4000 ms in base tickTime all’impostazione impostata su 2000ms.

server.*proprietà impostano l’appartenenza all’insieme. Il formato è:

server.<myid>=<hostname>:<leaderport>:<electionport>

In un ambiente di produzione, sono richiesti più broker. Durante l’avvio i broker si registrano in ZooKeeper per diventare membri del cluster.

Passare al file delle proprietà di Apache Kafka (/etc/kafka/server.properties) e personalizzare quanto segue:

zookeeper.connect=zookeeper:2181
############################# Server Basics #############################

# The ID of the broker. This must be set to a unique integer for each broker.
#broker.id=0
broker.id.generation.enable=true

Configurare il modo in cui altri broker e client comunicano con il broker utilizzando listeners e facoltativamente advertised.listeners.

Passare al file delle proprietà del proxy REST Confluent (/etc/kafka-rest/kafka-rest.properties) e personalizzare quanto segue:

zookeeper.connect=zookeeper:2181

Passare al file delle proprietà dello Schema Registry (/etc/schema-registry/schema-registry.properties) e specificare le seguenti proprietà:

# Specify the address the socket server listens on, e.g. listeners = PLAINTEXT://your.host.name:9092
listeners=http://0.0.0.0:8081

# The host name advertised in ZooKeeper. This must be specified if your running Schema Registry
# with multiple nodes.
host.name=192.168.50.1

# List of Kafka brokers to connect to, e.g. PLAINTEXT://hostname:9092,SSL://hostname2:9092
kafkastore.bootstrap.servers=PLAINTEXT://hostname:9092,SSL://hostname2:9092

Questa configurazione è per un cluster multi-nodo a tre nodi. Per ulteriori informazioni, consultare Running Schema Registry in Production.

Eseguire lo start dei servizi confluent


Lo start dei servizi, va eseguito in ordine:


Importante: Eseguire lo start nell’ordine precedente, per lo stop fare lo stesso ma in ordine inverso

# systemctl start confluent-zookeeper.service
# sleep 5

# systemctl start confluent-kafka.service
# sleep 10

# systemctl start confluent-kafka-connect.service

# systemctl start confluent-schema-registry.service

# systemctl start confluent-kafka-rest.service

# systemctl start confluent-ksqldb.service

Disinstallare kafka

< br />

Eseguire questo comando per rimuovere Confluent Platform, dove si trova confluent-platform-2.12 (Confluent Platform) o confluent-community-2.12 (Confluent Platform utilizzando solo i componenti Confluent Community).

$ sudo yum autoremove <component-name>

Ad esempio, eseguire questo comando per rimuovere Confluent Community:

$ sudo yum autoremove confluent-community-2.12

L’output dovrebbe essere simile a:

Loaded plugins: fastestmirror, langpacks
Resolving Dependencies
--> Running transaction check
---> Package confluent-community-2.12.noarch 0:5.5.0-0.1.cp2 will be erased
...
Removed:
confluent-community-2.12.noarch 0:5.5.0-0.1.cp2

Dependency Removed:
confluent-common.noarch 0:5.5.0-0.1.cp2 confluent-control-center.noarch 0:5.5.0-0.1.cp2
confluent-kafka-2.12.noarch 0:5.5.0-0.1.cp2 confluent-kafka-connect-elasticsearch.noarch 0:5.5.0-0.1.cp2
confluent-kafka-connect-jdbc.noarch 0:5.5.0-0.1.cp2 confluent-kafka-connect-jms.noarch 0:5.5.0-0.1.cp2
confluent-kafka-connect-replicator.noarch 0:5.5.0-0.1.cp2 confluent-kafka-connect-s3.noarch 0:5.5.0-0.1.cp2
confluent-kafka-connect-storage-common.noarch 0:5.5.0-0.1.cp2 confluent-kafka-mqtt.noarch 0:5.5.0-0.1.cp2
confluent-kafka-rest.noarch 0:5.5.0-0.1.cp2 confluent-ksql.noarch 0:5.5.0-0.1.cp2
confluent-rebalancer.noarch 0:5.5.0-0.1.cp2 confluent-rest-utils.noarch 0:5.5.0-0.1.cp2
confluent-schema-registry.noarch 0:5.5.0-0.1.cp2

Complete!

Ogni tool in se ha un mondo dietro, l’unico modo per saperne sempre di più è formarti, formarti e formarti costantemente. Il mondo si evolve velocemente, non farti lasciare indietro!

Info about author
Fabio Felici

Fabio Felici

Prenota subito il tuo corso ufficiale Red Hat

GUARDA I CORSI