La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

Perché scegliere NetApp NFS per i workload Kafka?

12/13/2023 Collaboratori

PDF

Ora che esiste una soluzione per il problema del ridenominazione sciocco nello storage NFS con Kafka, è possibile creare solide implementazioni che sfruttano lo storage NetApp ONTAP per il carico di lavoro Kafka. Questo non solo riduce significativamente l'overhead operativo, ma offre anche i seguenti vantaggi ai cluster Kafka:

Utilizzo ridotto della CPU per i broker Kafka. l'utilizzo dello storage NetApp ONTAP disaggregato separa le operazioni di i/o dei dischi dal broker e riduce così l'impatto della CPU.
Tempi di recovery più rapidi per i broker. poiché lo storage NetApp ONTAP disaggregato è condiviso tra i nodi dei broker Kafka, una nuova istanza di calcolo può sostituire un broker difettoso in qualsiasi momento in una frazione del tempo rispetto alle implementazioni Kafka convenzionali senza ricostruire i dati.
Efficienza dello storage. con il provisioning del layer di storage dell'applicazione tramite NetApp ONTAP, i clienti possono sfruttare tutti i vantaggi dell'efficienza dello storage forniti con ONTAP, come compressione dei dati in linea, deduplica e compaction.

Questi vantaggi sono stati testati e validati in casi di test di cui discutiamo in dettaglio in questa sezione.

Riduzione dell'utilizzo della CPU sul broker Kafka

Abbiamo scoperto che l'utilizzo complessivo della CPU è inferiore rispetto alla controparte DAS quando abbiamo eseguito carichi di lavoro simili su due cluster Kafka separati che erano identici nelle specifiche tecniche ma differivano nelle tecnologie di storage. Non solo l'utilizzo complessivo della CPU è inferiore quando il cluster Kafka utilizza lo storage ONTAP, ma l'aumento dell'utilizzo della CPU ha dimostrato un gradiente più delicato rispetto a un cluster Kafka basato su DAS.

Configurazione architetturale

La seguente tabella mostra la configurazione ambientale utilizzata per dimostrare un utilizzo ridotto della CPU.

Componente della piattaforma	Configurazione dell'ambiente
Tool di benchmarking Kafka 3.2.3: OpenMessaging	3 zookeeper – t2.small 3 server di broker – i3en.2xlarge 1 x Grafana – c5n.2xlarge 4 x Produttore/Consumer — c5n.2xlarge
Sistema operativo su tutti i nodi	RHEL 8.7 o versione successiva
Istanza di NetApp Cloud Volumes ONTAP	Istanza a nodo singolo – M5.2xLarge

Componente della piattaforma

Configurazione dell'ambiente

Tool di benchmarking Kafka 3.2.3: OpenMessaging

3 zookeeper – t2.small
3 server di broker – i3en.2xlarge
1 x Grafana – c5n.2xlarge
4 x Produttore/Consumer — c5n.2xlarge

Sistema operativo su tutti i nodi

RHEL 8.7 o versione successiva

Istanza di NetApp Cloud Volumes ONTAP

Istanza a nodo singolo – M5.2xLarge

Tool di benchmarking

Lo strumento di benchmarking utilizzato in questo caso di test è "OpenMessaging" framework. OpenMessaging è indipendente dal vendor e dal linguaggio; fornisce linee guida di settore per finanza, e-commerce, IoT e big data; aiuta a sviluppare applicazioni di messaggistica e streaming su sistemi e piattaforme eterogenee. La figura seguente mostra l'interazione dei client OpenMessaging con un cluster Kafka.

Questa immagine mostra l'interazione dei client OpenMessaging con un cluster Kafka.

Compute. abbiamo utilizzato un cluster Kafka a tre nodi con un ensemble di zookeeper a tre nodi in esecuzione su server dedicati. Ciascun broker disponeva di due mount point NFSv4.1 su un singolo volume sull'istanza CVO di NetApp attraverso una LIF dedicata.
Monitoring. abbiamo utilizzato due nodi per una combinazione Prometheus-Grafana. Per la generazione dei carichi di lavoro, abbiamo un cluster a tre nodi separato che può produrre e consumare da questo cluster Kafka.
Storage. abbiamo utilizzato un'istanza NetApp Cloud Volumes ONTAP a nodo singolo con sei volumi AWS-EBS GP2 da 250 GB montati sull'istanza. Questi volumi sono stati quindi esposti al cluster Kafka come sei volumi NFSv4.1 attraverso LIF dedicate.
Configurazione. i due elementi configurabili in questo test case erano i broker Kafka e i carichi di lavoro OpenMessaging.
- Broker config. per i broker Kafka sono state selezionate le seguenti specifiche. Abbiamo utilizzato il fattore di replica di 3 per tutte le misurazioni, come evidenziato di seguito.

Questa immagine mostra le specifiche selezionate per i broker Kafka.

OpenMessaging benchmark (OMB) workload config. sono state fornite le seguenti specifiche. Abbiamo specificato un tasso di produzione target, evidenziato di seguito.

Questa immagine mostra le specifiche selezionate per la configurazione del carico di lavoro del benchmark OpenMessaging.

Metodologia di test

Sono stati creati due cluster simili, ciascuno con un proprio set di benchmark di sciami di cluster.
- Cluster 1.* cluster Kafka basato su NFS.
- Cluster 2.* cluster Kafka basato su DAS.

Utilizzando un comando OpenMessaging, carichi di lavoro simili sono stati attivati su ciascun cluster.

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

La configurazione del tasso di produzione è stata aumentata in quattro iterazioni e l'utilizzo della CPU è stato registrato con Grafana. Il tasso di produzione è stato impostato sui seguenti livelli:
- 10,000
- 40,000
- 80,000
- 100,000

Osservazione

L'utilizzo dello storage NetApp NFS con Kafka offre due vantaggi principali:

È possibile ridurre l'utilizzo della CPU di quasi un terzo. l'utilizzo complessivo della CPU con carichi di lavoro simili è stato inferiore per NFS rispetto agli SSD DAS; i risparmi variano dal 5% per velocità di produzione inferiori al 32% per velocità di produzione superiori.
Una riduzione di tre volte nella deriva di utilizzo della CPU a velocità di produzione più elevate. come previsto, si è verificata una deriva verso l'alto per l'aumento dell'utilizzo della CPU con l'aumento dei tassi di produzione. Tuttavia, l'utilizzo della CPU sui broker Kafka che utilizzano DAS è aumentato dal 31% per il tasso di produzione inferiore al 70% per il tasso di produzione più elevato, un aumento del 39%. Tuttavia, con un backend di storage NFS, l'utilizzo della CPU è aumentato dal 26% al 38%, con un aumento del 12%.

Questo grafico illustra il comportamento di un cluster basato su DAS.

Questo grafico illustra il comportamento di un cluster basato su NFS.

Inoltre, con 100,000 messaggi, DAS mostra un utilizzo della CPU maggiore rispetto a un cluster NFS.

Questo grafico illustra il comportamento di un cluster basato su DAS con 100,000 messaggi.

Questo grafico illustra il comportamento di un cluster basato su NFS con 100,000 messaggi.

Recupero più rapido del broker

Abbiamo scoperto che i broker Kafka si ripristinano più velocemente quando utilizzano lo storage NetApp NFS condiviso. Quando un broker si blocca in un cluster Kafka, questo broker può essere sostituito da un broker sano con lo stesso ID broker. Dopo aver eseguito questo test case, abbiamo scoperto che, nel caso di un cluster Kafka basato su DAS, il cluster ricostruisce i dati su un nuovo broker sano aggiunto, il che richiede tempo. Nel caso di un cluster Kafka basato su NetApp NFS, il broker che sostituisce continua a leggere i dati dalla directory di log precedente e a ripristinarli molto più velocemente.