Confluent-Leistungsvalidierung
Änderungen vorschlagen
PDFs
Wir haben die Überprüfung mit Confluent Platform für Tiered Storage auf NetApp ONTAP durchgeführt. Die Teams von NetApp und Confluent haben gemeinsam an dieser Verifizierung gearbeitet und die dafür erforderlichen Testfälle ausgeführt.
Confluent-Setup
Für das Setup haben wir drei Zookeeper, fünf Broker und fünf Testserver mit 256 GB RAM und 16 CPUs verwendet. Für den NetApp -Speicher haben wir ONTAP mit einem AFF A900 HA-Paar verwendet. Der Speicher und die Broker wurden über 100-GbE-Verbindungen verbunden.
Die folgende Abbildung zeigt die Netzwerktopologie der Konfiguration, die für die Überprüfung des mehrstufigen Speichers verwendet wird.
Die Tool-Server fungieren als Anwendungsclients, die Ereignisse an Confluent-Knoten senden oder von diesen empfangen.
Confluent-Tiered-Storage-Konfiguration
Wir haben die folgenden Testparameter verwendet:
confluent.tier.fetcher.num.threads=80 confluent.tier.archiver.num.threads=80 confluent.tier.enable=true confluent.tier.feature=true confluent.tier.backend=S3 confluent.tier.s3.bucket=kafkabucket1-1 confluent.tier.s3.region=us-east-1 confluent.tier.s3.cred.file.path=/data/kafka/.ssh/credentials confluent.tier.s3.aws.endpoint.override=http://wle-mendocino-07-08/ confluent.tier.s3.force.path.style.access=true bootstrap.server=192.168.150.172:9092,192.168.150.120:9092,192.168.150.164:9092,192.168.150.198:9092,192.168.150.109:9092,192.168.150.165:9092,192.168.150.119:9092,192.168.150.133:9092 debug=true jmx.port=7203 num.partitions=80 num.records=200000000 #object PUT size - 512MB and fetch 100MB – netapp segment.bytes=536870912 max.partition.fetch.bytes=1048576000 #GET size is max.partition.fetch.bytes/num.partitions length.key.value=2048 trogdor.agent.nodes=node0,node1,node2,node3,node4 trogdor.coordinator.hostname.port=192.168.150.155:8889 num.producers=20 num.head.consumers=20 num.tail.consumers=1 test.binary.task.max.heap.size=32G test.binary.task.timeout.sec=3600 producer.timeout.sec=3600 consumer.timeout.sec=3600
Zur Überprüfung haben wir ONTAP mit dem HTTP-Protokoll verwendet, aber auch HTTPS funktionierte. Der Zugriffsschlüssel und der geheime Schlüssel werden in der Datei mit dem angegebenen Namen gespeichert. confluent.tier.s3.cred.file.path Parameter.
NetApp Speichercontroller – ONTAP
Zur Überprüfung haben wir eine einzelne HA-Paarkonfiguration in ONTAP konfiguriert.
Verifizierungsergebnisse
Zur Verifizierung haben wir die folgenden fünf Testfälle durchgeführt. Bei den ersten beiden handelte es sich um Funktionstests und bei den restlichen drei um Leistungstests.
Korrektheitstest des Objektspeichers
Dieser Test führt mithilfe von API-Aufrufen grundlegende Vorgänge wie „Get“, „Put“ und „Delete“ im Objektspeicher aus, der für den mehrstufigen Speicher verwendet wird.
Korrektheitstest der Tiering-Funktionalität
Dieser Test überprüft die End-to-End-Funktionalität des Objektspeichers. Es erstellt ein Thema, erzeugt einen Ereignisstrom zum neu erstellten Thema, wartet darauf, dass die Broker die Segmente im Objektspeicher archivieren, verbraucht den Ereignisstrom und überprüft, ob der verbrauchte Strom mit dem erzeugten Strom übereinstimmt. Wir haben diesen Test mit und ohne Fehlerinjektion im Objektspeicher durchgeführt. Wir haben einen Knotenausfall simuliert, indem wir den Service Manager-Dienst in einem der Knoten in ONTAP gestoppt und überprüft haben, ob die End-to-End-Funktionalität mit dem Objektspeicher funktioniert.
Benchmark für den Tier-Abruf
Dieser Test validierte die Leseleistung des mehrstufigen Objektspeichers und überprüfte die Range-Fetch-Leseanforderungen unter hoher Last von Segmenten, die durch den Benchmark generiert wurden. In diesem Benchmark hat Confluent benutzerdefinierte Clients entwickelt, um die Tier-Fetch-Anfragen zu erfüllen.
Arbeitslastgenerator zum Produzieren und Konsumieren
Dieser Test erzeugt durch die Archivierung von Segmenten indirekt Schreibarbeitslast im Objektspeicher. Die Lesearbeitslast (gelesene Segmente) wurde aus dem Objektspeicher generiert, als Verbrauchergruppen die Segmente abgerufen haben. Diese Arbeitslast wurde durch ein TOCC-Skript generiert. Dieser Test überprüfte die Leistung beim Lesen und Schreiben im Objektspeicher in parallelen Threads. Wir haben mit und ohne Fehlerinjektion im Objektspeicher getestet, wie wir es für den Korrektheitstest der Tiering-Funktionalität getan haben.
Generator für die Aufbewahrungsarbeitslast
Dieser Test prüfte die Löschleistung eines Objektspeichers unter einer hohen Themenaufbewahrungsarbeitslast. Der Aufbewahrungsaufwand wurde mithilfe eines TOCC-Skripts generiert, das viele Nachrichten parallel zu einem Testthema produziert. Das Testthema war die Konfiguration mit einer aggressiven größen- und zeitbasierten Aufbewahrungseinstellung, die dazu führte, dass der Ereignisstrom kontinuierlich aus dem Objektspeicher gelöscht wurde. Anschließend wurden die Segmente archiviert. Dies führte zu zahlreichen Löschungen im Objektspeicher durch den Broker und zur Erfassung der Leistung der Löschvorgänge im Objektspeicher.
Einzelheiten zur Überprüfung finden Sie im "Zusammenfließend" Webseite.