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.

Funktionale Validierung – Korrektur von Silly-Umbenennung

Beitragende
PDFs

Für die funktionale Validierung haben wir gezeigt, dass ein Kafka-Cluster mit einem NFSv3-Mount für Storage Kafka-Vorgänge wie Partitionsumverteilung nicht ausführen kann, während ein anderer Cluster, der auf NFSv4 mit der Korrektur gemountet ist, die gleichen Operationen ohne Unterbrechungen durchführen kann.

Einrichtung der Validierung

Das Setup läuft auf AWS. Die folgende Tabelle zeigt die verschiedenen Plattformkomponenten und Umgebungskonfigurationen, die für die Validierung verwendet werden.

Plattformkomponente Umgebungskonfiguration

Confluent Platform Version 7.2.1

  • 3 x Zookeeper – t3.xlarge

  • 4 x Broker-Server – r3.xlarge

  • 1 x Grafana – t3.xlarge

  • 1 x Leitstelle – t3.xlarge

  • 3 x Hersteller/Verbraucher

Betriebssystem auf allen Knoten

RHEL8.7oder höher

NetApp Cloud Volumes ONTAP Instanz

Single-Node-Instanz – M5.2xLarge

Die folgende Abbildung zeigt die Architekturkonfiguration dieser Lösung.

Diese Bilder zeigen die AWS-Topologie mit einer VPC, die drei private Subnetze mit einem Producer-Swarm, dem Kafka-Cluster und einer CVO-Instanz enthält.

Architekturfluss

  • Compute. Wir nutzten einen vier-Knoten-Kafka-Cluster mit einem drei-Knoten-Zookeeper-Ensemble, das auf dedizierten Servern lief.

  • Monitoring. für eine Prometheus-Grafana-Kombination haben wir zwei Knoten verwendet.

  • Workload. zur Generierung von Workloads haben wir ein separates Cluster mit drei Nodes verwendet, das die Produktion und Nutzung aus diesem Kafka-Cluster ermöglicht.

  • Speicher. Wir verwendeten eine NetApp Cloud Volumes ONTAP-Instanz mit einem einzigen Node, wobei zwei 500 GB GP2 AWS-EBS Volumes an die Instanz angeschlossen waren. Diese Volumes wurden dann dem Kafka Cluster als einzelnes NFSv4.1-Volume über eine LIF offengelegt.

Die Standardeigenschaften von Kafka wurden für alle Server ausgewählt. Das gleiche wurde für den Zookeeper Schwarm getan.

Methodik des Testens

  1. Aktualisierung -is-preserve-unlink-enabled true Zum kafka-Band wie folgt:

    aws-shantanclastrecall-aws::*> volume create -vserver kafka_svm -volume kafka_fg_vol01 -aggregate kafka_aggr -size 3500GB -state online -policy kafka_policy -security-style unix -unix-permissions 0777 -junction-path /kafka_fg_vol01 -type RW -is-preserve-unlink-enabled true
[Job 32] Job succeeded: Successful

  2. Zwei ähnliche Kafka-Cluster wurden mit dem folgenden Unterschied erstellt:

    • Cluster 1. der Backend-NFS v4.1-Server mit produktionsbereitem ONTAP Version 9.12.1 wurde von einer NetApp CVO-Instanz gehostet. RHEL 8.7/RHEL 9.1 wurden auf den Brokern installiert.

    • Cluster 2. der Backend NFS Server war ein manuell erstellter generischer Linux NFSv3 Server.

  3. Auf beiden Kafka-Clustern wurde ein Demothema erstellt.

    Cluster 1:

    Dieser Screenshot zeigt das Demo-Thema, das auf Cluster 1 erstellt wurde.

    Cluster 2:

    Dieser Screenshot zeigt das Demo-Thema, das auf Cluster 2 erstellt wurde.

  4. In diese neu erstellten Themen wurden für beide Cluster Daten geladen. Dies wurde mit dem Producer-perf-Test Toolkit durchgeführt, das im Standard-Kafka-Paket enthalten ist:

    ./kafka-producer-perf-test.sh --topic __a_demo_topic --throughput -1 --num-records 3000000 --record-size 1024 --producer-props acks=all bootstrap.servers=172.30.0.160:9092,172.30.0.172:9092,172.30.0.188:9092,172.30.0.123:9092

  5. Für Broker-1 wurde für jeden der Cluster eine Integritätsprüfung über Telnet durchgeführt:

    • telnet 172.30.0.160 9092

    • telnet 172.30.0.198 9092

      Eine erfolgreiche Integritätsprüfung für Broker auf beiden Clustern wird im nächsten Screenshot angezeigt:

    Dieser Screenshot zeigt die Anzeige für eine erfolgreiche Integritätsprüfung auf beiden Brokern.

  6. Um die Fehlerbedingung auszulösen, die einen Absturz von Kafka-Clustern mit NFSv3-Storage-Volumes verursacht, haben wir bei beiden Clustern den Prozess der Partitionsumzuordnung initiiert. Die Partitionsumverteilung wurde mit durchgeführt kafka-reassign-partitions.sh. Der detaillierte Prozess sieht wie folgt aus:

    1. Um die Partitionen für ein Thema in einem Kafka-Cluster neu zuzuweisen, haben wir die vorgeschlagene Neuzuweisung von config JSON generiert (dies wurde für beide Cluster durchgeführt).

      kafka-reassign-partitions --bootstrap-server=172.30.0.160:9092,172.30.0.172:9092,172.30.0.188:9092,172.30.0.123:9092 --broker-list "1,2,3,4" --topics-to-move-json-file /tmp/topics.json --generate

    2. Die generierte Neuzuweisung JSON wurde dann in gespeichert /tmp/reassignment- file.json.

    3. Der eigentliche Vorgang der Partitionsumverteilung wurde durch den folgenden Befehl ausgelöst:

      kafka-reassign-partitions --bootstrap-server=172.30.0.198:9092,172.30.0.163:9092,172.30.0.221:9092,172.30.0.204:9092 --reassignment-json-file /tmp/reassignment-file.json –execute

  7. Nach ein paar Minuten, als die Neuzuweisung abgeschlossen war, zeigte eine weitere Integritätsprüfung der Broker, dass Cluster mit NFSv3-Storage-Volumes ein albernes Problem hatten und abgestürzt waren, während Cluster 1 mit NetApp ONTAP NFSv4.1-Storage-Volumes mit der Korrektur den Betrieb ohne Unterbrechungen fortsetzte.

    Dieser Screenshot zeigt die Ausgabe eines abgestürzten Brokers.

    • Cluster1-Broker-1 ist aktiv.

    • Cluster2-Broker-1 ist tot.

  8. Bei der Überprüfung der Kafka-Protokollverzeichnisse wurde deutlich, dass Cluster 1 mit NetApp ONTAP NFSv4.1-Storage-Volumes mit der Korrektur eine saubere Partitionszuweisung hatte, während Cluster 2 mit generischem NFSv3-Storage nicht auf alberne Probleme beim Umbenennen zurückzuführen war, was zum Absturz führte. Das folgende Bild zeigt den Partitionsausgleich von Cluster 2, was zu einem dummen Umbenennungsproblem auf NFSv3 Storage führte.

    In diesem Screenshot wird die Protokollausgabe für Cluster 2 abstürzt.

    Das folgende Bild zeigt eine saubere Partition Rebalancing von Cluster 1 mit NetApp NFSv4.1 Storage.

    In diesem Screenshot wird die Protokollausgabe für eine erfolgreiche Zuweisung einer sauberen Partition für Cluster 1 angezeigt, wobei