Skip to main content
NetApp Solutions
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Warum NetApp NFS für Kafka-Workloads?

Beitragende
PDFs

Da es jetzt in NFS-Storage mit Kafka eine Lösung für das Problem des unsinnigen Umbenennungen gibt, können Sie robuste Implementierungen erstellen, die NetApp ONTAP-Storage für Ihren Kafka-Workload nutzen. Dies verringert nicht nur den betrieblichen Overhead, sondern bringt auch die folgenden Vorteile für Ihre Kafka-Cluster mit sich:

  • Geringere CPU-Auslastung bei Kafka-Brokern mittels disaggregiertem NetApp ONTAP Storage werden Festplatten-I/O-Operationen vom Broker getrennt und damit der CPU-Bedarf reduziert.

  • Schnellere Recovery-Zeit für Broker. Da disaggregierter NetApp ONTAP-Storage über Kafka-Broker-Nodes hinweg gemeinsam genutzt wird, kann eine neue Compute-Instanz einen fehlerhaften Broker jederzeit und in einem Bruchteil der Zeit ersetzen, die in herkömmlichen Kafka-Implementierungen üblich ist, ohne die Daten neu zu erstellen.

  • Storage-Effizienz. Da die Storage-Ebene der Applikation jetzt über NetApp ONTAP bereitgestellt wird, profitieren Kunden von allen Vorteilen der Storage-Effizienz, die ONTAP bietet, wie Inline-Datenkomprimierung, Deduplizierung und Data-Compaction.

Diese Vorteile wurden in Testfällen, die wir in diesem Abschnitt näher erläutern, getestet und validiert.

Reduzierte CPU-Auslastung beim Kafka-Broker

Wir stellten fest, dass die CPU-Auslastung insgesamt niedriger ist als die des Pendants von das, als wir ähnliche Workloads auf zwei separaten Kafka Clustern ausgeführt hatten, die in den technischen Spezifikationen identisch waren, sich aber in ihren Storage-Technologien unterschieden. Wenn Kafka Cluster ONTAP-Storage verwendet, ist nicht nur die CPU-Auslastung insgesamt geringer, sondern die Steigerung der CPU-Auslastung zeigte auch einen sanfteren Verlauf als in einem das-basierten Kafka Cluster.

Einrichtung der Architektur

In der folgenden Tabelle ist die Umgebungskonfiguration aufgeführt, mit der die Verringerung der CPU-Auslastung demonstriert wird.

Plattformkomponente Umgebungskonfiguration

Kafka 3.2.3 Benchmarking-Tool: OpenMessaging

  • 3 x Zookeeper – t2.small

  • 3 x Broker Server – i3en.2xlarge

  • 1 x Grafana – c5n.2xlarge

  • 4 x Hersteller/Verbraucher — c5n.2xlarge

Betriebssystem auf allen Knoten

RHEL 8.7 oder höher

NetApp Cloud Volumes ONTAP Instanz

Single Node-Instanz – M5.2xLarge

Benchmark-Tool

Das in diesem Testfall verwendete Benchmark-Tool ist das "OpenMessaging" Framework: OpenMessaging ist herstellerneutral und sprachunabhängig; es bietet Branchenrichtlinien für Finanzen, E-Commerce, IoT und Big Data und unterstützt die Entwicklung von Messaging- und Streaming-Anwendungen über heterogene Systeme und Plattformen hinweg. Die folgende Abbildung zeigt die Interaktion von OpenMessaging-Clients mit einem Kafka-Cluster.

Dieses Bild zeigt die Interaktion von OpenMessaging Clients mit einem Kafka Cluster.

  • Compute. Wir benutzten einen drei-Knoten-Kafka-Cluster mit einem drei-Knoten-Zookeeper-Ensemble, das auf dedizierten Servern läuft. Jeder Broker hatte zwei NFSv4.1-Mount-Punkte auf ein einzelnes Volume in der NetApp CVO-Instanz über eine dedizierte LIF.

  • Monitoring. für eine Prometheus-Grafana-Kombination haben wir zwei Knoten verwendet. Zur Generierung von Workloads verfügen wir über ein separates Cluster mit drei Nodes, das in diesen Kafka-Cluster erzeugt und genutzt werden kann.

  • Storage. Wir verwendeten eine NetApp Cloud Volumes ONTAP-Instanz mit einem Node, auf der sechs 250 GB GP2 AWS-EBS Volumes gemountet wurden. Diese Volumes wurden dann über dedizierte LIFs dem Kafka-Cluster als sechs NFSv4.1-Volumes offengelegt.

  • Konfiguration. die beiden konfigurierbaren Elemente in diesem Testfall waren Kafka-Broker und OpenMessaging-Workloads.

    • Broker config. folgende Spezifikationen wurden für die Kafka-Broker ausgewählt. Wir haben den Replikationsfaktor 3 für alle Messungen verwendet, wie unten hervorgehoben wird.

Dieses Bild zeigt die Spezifikationen, die für die Kafka-Broker ausgewählt wurden.

  • OpenMessaging Benchmark (OMB) Workload-Konfiguration. die folgenden Spezifikationen wurden bereitgestellt. Wir haben einen angestrebten Erzeugertarif angegeben, der unten hervorgehoben wurde.

Dieses Bild zeigt die Spezifikationen, die für die OpenMessaging Benchmark Workload-Konfiguration ausgewählt wurden.

Methodik des Testens

  1. Es wurden zwei ähnliche Cluster mit jeweils eigenen Benchmark-Cluster-Schwärmen erstellt.

    • Cluster 1. NFS-basierter Kafka-Cluster.

    • Cluster 2. das-basierter Kafka-Cluster.

  2. Mit einem OpenMessaging-Befehl wurden auf jedem Cluster ähnliche Workloads ausgelöst.

    sudo bin/benchmark --drivers driver-kafka/kafka-group-all.yaml workloads/1-topic-100-partitions-1kb.yaml

  3. Die Konfiguration der Erzeugungsrate wurde in vier Iterationen erhöht, und die CPU-Auslastung wurde mit Grafana aufgezeichnet. Die Erzeugungsrate wurde auf die folgenden Stufen eingestellt:

    • 10,000

    • 40,000

    • 80,000

    • 100,000

Beobachtung

Es gibt zwei Hauptvorteile bei der Nutzung von NetApp NFS-Storage mit Kafka:

  • Sie können die CPU-Nutzung um fast ein Drittel reduzieren. die CPU-Auslastung bei ähnlichen Workloads war bei NFS im Vergleich zu das SSDs niedriger; die Einsparungen reichen von 5 % bei geringeren Produktraten bis zu 32 % bei höheren Produktraten.

  • Eine Verdreifachung der CPU-Auslastung bei höheren Erzeugungsraten. wie erwartet gab es eine Aufwärtsbewegung für die Erhöhung der CPU-Auslastung, da die Erzeugungsraten erhöht wurden. Die CPU-Auslastung bei Kafka-Brokern mit das ist jedoch von 31 % bei der niedrigeren Produktzrate auf 70 % bei der höheren Produktzrate gestiegen, was einer Steigerung um 39 % entspricht. Bei einem NFS Storage Backend stieg die CPU-Auslastung von 26% auf 38%, was einer Steigerung von 12% entspricht.

In diesem Diagramm wird das Verhalten eines das-basierten Clusters dargestellt.

In diesem Diagramm wird das Verhalten eines NFS-basierten Clusters dargestellt.

Außerdem zeigt das bei 100,000 Meldungen eine höhere CPU-Auslastung als ein NFS-Cluster.

Dieses Diagramm zeigt das Verhalten eines das-basierten Clusters bei 100,000 Meldungen.

Dieses Diagramm zeigt das Verhalten eines NFS-basierten Clusters bei 100,000 Meldungen.

Schnellere Broker Recovery

Wir haben herausgefunden, dass Kafka-Broker sich mit Shared-NetApp-NFS-Storage schneller wiederherstellen können. Wenn ein Broker in einem Kafka-Cluster abstürzt, kann dieser Broker durch einen gesunden Broker mit derselben Broker-ID ersetzt werden. Bei diesem Testfall stellten wir fest, dass im Falle eines das-basierten Kafka-Clusters die Daten auf einem neu hinzugefügten fehlerfreien Broker neu erstellt werden, was sehr zeitaufwendig ist. Bei einem NFS-basierten Kafka Cluster von NetApp liest der ersetzende Broker weiterhin Daten aus dem vorherigen Log-Verzeichnis und stellt damit eine wesentlich schnellere Wiederherstellung her.

Einrichtung der Architektur

In der folgenden Tabelle wird die Umgebungskonfiguration für ein Kafka-Cluster mithilfe von NAS gezeigt.

Plattformkomponente Umgebungskonfiguration

Kafka 3.2.3

  • 3 x Zookeeper – t2.small

  • 3 x Broker Server – i3en.2xlarge

  • 1 x Grafana – c5n.2xlarge

  • 4 x Hersteller/Verbraucher — c5n.2xlarge

  • 1 Backup-Kafka-Node – i3en.2xlarge

Betriebssystem auf allen Knoten

RHEL8.7 oder höher

NetApp Cloud Volumes ONTAP Instanz

Single-Node-Instanz – M5.2xLarge

In der folgenden Abbildung ist die Architektur eines NAS-basierten Kafka-Clusters dargestellt.

Diese Abbildung stellt die Architektur eines NAS-basierten Kafka-Clusters dar.

  • Compute. Ein Kafka-Cluster mit drei Knoten mit einem Zookeeper-Ensemble, das auf dedizierten Servern läuft. Jeder Broker verfügt über zwei NFS-Mount-Punkte zu einem einzelnen Volume in der NetApp CVO-Instanz über eine dedizierte LIF.

  • Monitoring. zwei Knoten für eine Prometheus-Grafana Kombination. Zur Generierung von Workloads verwenden wir ein separates Cluster mit drei Nodes, das diesen Kafka-Cluster produzieren und nutzen kann.

  • Storage. Eine NetApp Cloud Volumes ONTAP-Instanz mit einem Node, auf der sechs 250-GB-GP2-AWS-EBS-Volumes gemountet sind. Diese Volumes werden dann über dedizierte LIFs dem Kafka-Cluster als sechs NFS-Volumes offengelegt.

  • Broker-Konfiguration. das einzige konfigurierbare Element in diesem Testfall sind Kafka-Broker. Für die Kafka-Broker wurden folgende Spezifikationen ausgewählt. Der replica.lag.time.mx.ms Wird auf einen hohen Wert gesetzt, da dadurch festgelegt wird, wie schnell ein bestimmter Knoten aus der ISR-Liste entfernt wird. Wenn Sie zwischen schlechten und gesunden Knoten wechseln, möchten Sie nicht, dass diese Broker-ID von der ISR-Liste ausgeschlossen wird.

Dieses Bild zeigt die für die Kafka-Broker ausgewählten Spezifikationen.

Methodik des Testens

  1. Es wurden zwei ähnliche Cluster erstellt:

    • Ein EC2-basiertes, konfluent Cluster.

    • Ein konfluent NetApp NFS-basiertes Cluster.

  2. Ein Standby-Kafka-Node wurde mit einer identischen Konfiguration wie die Nodes aus dem ursprünglichen Kafka-Cluster erstellt.

  3. Auf jedem der Cluster wurde ein Beispielthema erstellt und ungefähr 110 GB Daten wurden von jedem der Broker aufgefüllt.

    • EC2-basierter Cluster. Ein Kafka-Broker-Datenverzeichnis ist zugeordnet /mnt/data-2 (In der folgenden Abbildung: Broker-1 von cluster1 [left Terminal]).

    • NetApp NFS-basierter Cluster. Ein Kafka Broker Datenverzeichnis ist auf NFS Point montiert /mnt/data (In der folgenden Abbildung, Broker-1 von cluster2 [rechtes Terminal]).

      Dieses Bild zeigt zwei Terminalbildschirme.

  4. In jedem Cluster wurde Broker-1 beendet, um einen fehlgeschlagenen Recovery-Prozess für Broker auszulösen.

  5. Nachdem der Broker beendet wurde, wurde die Broker-IP-Adresse dem Standby-Broker als sekundäre IP zugewiesen. Dies war notwendig, da ein Broker in einem Kafka-Cluster wie folgt identifiziert wird:

    • IP-Adresse. wird zugewiesen, indem die fehlgeschlagene Broker-IP dem Standby-Broker neu zugewiesen wird.

    • Broker-ID. Diese wurde im Standby-Broker konfiguriert server.properties.

  6. Bei IP-Zuweisung wurde der Kafka-Dienst auf dem Standby-Broker gestartet.

  7. Nach einer Weile wurden die Serverprotokolle abgerufen, um die Zeit zu prüfen, die für das Erstellen von Daten auf dem Ersatz-Node im Cluster erforderlich war.

Beobachtung

Die Recovery des Brokers Kafka war nahezu neunmal schneller. Die Wiederherstellung eines ausgefallenen Broker-Nodes dauerte bei der Nutzung von NetApp NFS Shared Storage erheblich schneller als bei der Nutzung das-SSDs in einem Kafka Cluster. Bei 1 TB Themdaten betrug die Recovery-Zeit für ein das-basiertes Cluster 48 Minuten. Bei einem Kafka Cluster auf NetApp NFS-Basis dauerte die Recovery weniger als 5 Minuten.

Wir beobachteten, dass der EC2-basierte Cluster 10 Minuten benötigt, um die Wiederherstellung der 110 GB Daten auf dem neuen Broker Node durchzuführen, während der NFS-basierte Cluster die Recovery innerhalb von 3 Minuten abgeschlossen hat. Wir beobachteten auch in den Protokollen, dass Verbraucheroffsets für die Partitionen für EC2 0 waren, während auf dem NFS-Cluster Verbraucheroffsets vom vorherigen Broker abgeholt wurden.

[2022-10-31 09:39:17,747] INFO [LogLoader partition=test-topic-51R3EWs-0000-55, dir=/mnt/kafka-data/broker2] Reloading from producer snapshot and rebuilding producer state from offset 583999 (kafka.log.UnifiedLog$)
[2022-10-31 08:55:55,170] INFO [LogLoader partition=test-topic-qbVsEZg-0000-8, dir=/mnt/data-1] Loading producer state till offset 0 with message format version 2 (kafka.log.UnifiedLog$)

DAS-basierter Cluster

  1. Der Backup-Knoten wurde um 08:55:53,730 gestartet.

    Dieses Bild zeigt die Protokollausgabe für ein das-basiertes Cluster an.

  2. Der Datenneuerstellungsprozess endete um 09:05:24,860. Die Verarbeitung von 110 GB Daten dauerte ca. 10 Minuten.

    Dieses Bild zeigt die Protokollausgabe für ein das-basiertes Cluster an.

NFS-basierter Cluster

  1. Der Backup-Knoten wurde um 09:39:17,213 gestartet. Der Startprotokolleintrag ist unten hervorgehoben.

    Dieses Bild zeigt die Protokollausgabe für ein NFS-basiertes Cluster.

  2. Der Datenneuerstellungsvorgang endete um 09:42:29,115. Die Verarbeitung von 110 GB Daten dauerte ca. 3 Minuten.

    Dieses Bild zeigt die Protokollausgabe für ein NFS-basiertes Cluster.

    Der Test wurde bei Vermittlern mit etwa 1 TB Daten wiederholt, sodass für das etwa 48 Minuten und für NFS 3 Minuten in Anspruch genommen wurden. Die Ergebnisse sind im folgenden Diagramm dargestellt.

    Dieses Diagramm zeigt die Zeit, die für die Wiederherstellung von Vermittlern in Abhängigkeit von der Datenmenge, die auf dem Broker für ein das-basiertes Cluster oder einen NFS-basierten Cluster geladen wird.

Storage-Effizienz

Da die Storage-Ebene des Kafka Clusters über NetApp ONTAP bereitgestellt wurde, verfügen wir über alle Storage-Effizienzfunktionen von ONTAP. Dazu wurde eine beträchtliche Datenmenge in einem Kafka-Cluster mit NFS-Storage, der auf Cloud Volumes ONTAP bereitgestellt wurde, erzeugt. Die ONTAP Funktionen ermöglichten eine deutliche Speicherplatzreduzierung.

Einrichtung der Architektur

In der folgenden Tabelle wird die Umgebungskonfiguration für ein Kafka-Cluster mithilfe von NAS gezeigt.

Plattformkomponente Umgebungskonfiguration

Kafka 3.2.3

  • 3 x Zookeeper – t2.small

  • 3 x Broker Server – i3en.2xlarge

  • 1 x Grafana – c5n.2xlarge

  • 4 x Hersteller/Verbraucher — c5n.2xlarge *

Betriebssystem auf allen Knoten

RHEL8.7 oder höher

NetApp Cloud Volumes ONTAP Instanz

Single Node-Instanz – M5.2xLarge

In der folgenden Abbildung ist die Architektur eines NAS-basierten Kafka-Clusters dargestellt.

Diese Abbildung stellt die Architektur eines NAS-basierten Kafka-Clusters dar.

  • Compute. Wir benutzten einen drei-Knoten-Kafka-Cluster mit einem drei-Knoten-Zookeeper-Ensemble, das auf dedizierten Servern läuft. Jeder Broker hatte zwei NFS-Mount-Punkte zu einem einzelnen Volume auf der NetApp CVO-Instanz über eine dedizierte LIF.

  • Monitoring. für eine Prometheus-Grafana-Kombination haben wir zwei Knoten verwendet. Zur Generierung von Workloads haben wir ein separates Cluster mit drei Nodes verwendet, das für diesen Kafka-Cluster erzeugt und genutzt werden kann.

  • Storage. Wir verwendeten eine NetApp Cloud Volumes ONTAP-Instanz mit einem Node, auf der sechs 250 GB GP2 AWS-EBS Volumes gemountet wurden. Diese Volumes wurden dann über dedizierte LIFs dem Kafka-Cluster als sechs NFS-Volumes offengelegt.

  • Konfiguration. die konfigurierbaren Elemente in diesem Testfall waren die Kafka-Broker.

Die Kompression wurde am Produktionsende ausgeschaltet, wodurch die Produzenten einen hohen Durchsatz erzielen konnten. Die Storage-Effizienz wurde stattdessen von der Computing-Schicht abgefangen.

Methodik des Testens

  1. Ein Kafka-Cluster wurde mit den oben genannten Spezifikationen bereitgestellt.

  2. Auf dem Cluster wurden etwa 350 GB Daten mit dem OpenMessaging Benchmarking-Tool erzeugt.

  3. Nach Abschluss des Workloads wurden mithilfe von ONTAP System Manager und der CLI die Statistiken zur Storage-Effizienz erfasst.

Beobachtung

Bei Daten, die mit dem OMB-Tool generiert wurden, erzielten wir eine Speicherersparnis von ~33 % bei einem Storage-Effizienzverhältnis von 1.70:1. Wie in den folgenden Abbildungen zu sehen, betrug der logische Speicherplatz der erzeugten Daten 420,3 GB und der physische Speicherplatz für die Daten 281,7 GB.

Dieses Bild stellt die Speicherersparnis in VMDISK dar.

Screenshot

Screenshot