La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Pourquoi choisir NetApp NFS pour les charges de travail Kafka ?

12/13/2023 Contributeurs

Maintenant qu'il existe une solution au problème du renommage dans le stockage NFS avec Kafka, vous pouvez créer des déploiements fiables qui exploitent le stockage NetApp ONTAP pour votre charge de travail Kafka. Non seulement cette configuration réduit considérablement la surcharge opérationnelle, mais elle offre également les avantages suivants à vos clusters Kafka :

Utilisation réduite du CPU sur les courtiers Kafka l'utilisation du stockage NetApp ONTAP désagrégée sépare les opérations d'E/S du disque du courtier et réduit ainsi l'empreinte du processeur.
Temps de restauration du courtier plus rapide. comme le stockage ONTAP NetApp désagrégée est partagé entre les nœuds du courtier Kafka, une nouvelle instance de calcul peut remplacer un mauvais courtier à tout moment et en beaucoup moins de temps qu'avec les déploiements Kafka classiques, sans reconstruire les données.
Efficacité du stockage. comme la couche de stockage de l'application est maintenant provisionnée via NetApp ONTAP, les clients peuvent bénéficier de tous les avantages de l'efficacité du stockage fournie avec ONTAP, tels que la compression, la déduplication et la compaction des données à la volée.

Ces avantages ont été testés et validés dans des scénarios de test que nous aborderons en détail dans cette section.

Réduction de l'utilisation du processeur sur le courtier Kafka

Nous avons découvert que l'utilisation globale du processeur était inférieure à celle de son homologue DAS lorsque nous exécutions des charges de travail similaires sur deux clusters Kafka à spermatozoïdes identiques dans leurs spécifications techniques, mais dont les technologies de stockage différaient. Non seulement l'utilisation globale du processeur est inférieure lorsque le cluster Kafka utilise le stockage ONTAP, mais l'augmentation de l'utilisation du CPU s'est avérée plus modérée que dans un cluster Kafka basé sur DAS.

Installation architecturale

Le tableau suivant présente la configuration environnementale utilisée pour démontrer la réduction de l'utilisation du processeur.

Composant de plate-forme	Configuration de l'environnement
Outil de banc d'essai Kafka 3.2.3 : OpenMessaging	3 x zookeepers – t2.small 3 serveurs de broker – i3en.2xlarge 1 x Grafana – c5n.2xlarge 4 x Producteur/consommateur — c5n.2xlarge
Système d'exploitation sur tous les nœuds	RHEL 8.7 ou version ultérieure
Instance NetApp Cloud Volumes ONTAP	Instance à un seul nœud – M5.2xLarge

Composant de plate-forme

Configuration de l'environnement

Outil de banc d'essai Kafka 3.2.3 : OpenMessaging

3 x zookeepers – t2.small
3 serveurs de broker – i3en.2xlarge
1 x Grafana – c5n.2xlarge
4 x Producteur/consommateur — c5n.2xlarge

Système d'exploitation sur tous les nœuds

RHEL 8.7 ou version ultérieure

Instance NetApp Cloud Volumes ONTAP

Instance à un seul nœud – M5.2xLarge

Outil d'évaluation

L'outil d'analyse comparative utilisé dans ce cas d'essai est le "OpenMessaging" structure. OpenMessaging est indépendant du langage et du fournisseur ; il fournit des directives sectorielles pour la finance, le commerce électronique, l'IoT et le Big Data ; il aide également à développer des applications de messagerie et de diffusion en continu sur des systèmes et plates-formes hétérogènes. La figure suivante illustre l'interaction des clients OpenMessaging avec un cluster Kafka.

Cette image illustre l'interaction des clients OpenMessaging avec un cluster Kafka.

Compute. nous avons utilisé un cluster Kafka à trois nœuds avec un ensemble de zoogardien à trois nœuds fonctionnant sur des serveurs dédiés. Chaque courtier disposait de deux points de montage NFSv4.1 sur un seul volume de l'instance NetApp CVO via une LIF dédiée.
Contrôle. nous avons utilisé deux nœuds pour une combinaison Prometheus-Grafana. Pour la génération des charges de travail, nous disposons d'un cluster séparé à trois nœuds qui peut produire et consommer à partir de ce cluster Kafka.
Stockage nous avons utilisé une instance NetApp Cloud Volumes ONTAP à un seul nœud avec six volumes GP2 AWS EBS de 250 Go montés sur l'instance. Ces volumes ont ensuite été exposés au cluster Kafka en tant que six volumes NFSv4.1 via des LIF dédiées.
Configuration. les deux éléments configurables dans ce cas de test étaient les courtiers Kafka et les charges de travail OpenMessaging.
- Broker config. les spécifications suivantes ont été sélectionnées pour les courtiers Kafka. Nous avons utilisé un facteur de réplication de 3 pour toutes les mesures, comme indiqué ci-dessous.

Cette image décrit les spécifications sélectionnées pour les courtiers Kafka.

OpenMessaging benchmark (OMB) configuration de la charge de travail. les spécifications suivantes ont été fournies. Nous avons spécifié un taux d'apporteur cible, mis en surbrillance ci-dessous.

Cette image illustre les spécifications sélectionnées pour la configuration de la charge de travail du banc d'essai OpenMessaging.

Méthodologie de test

Deux grappes similaires ont été créées, chacune ayant son propre ensemble de essaims de grappes de benchmarking.
- Cluster 1. cluster Kafka basé sur NFS.
- Cluster 2. cluster Kafka à base de DAS.
À l'aide d'une commande OpenMessaging, des charges de travail similaires ont été déclenchées sur chaque cluster.
```
sudo bin/benchmark --drivers driver-kafka/kafka-group-all.yaml workloads/1-topic-100-partitions-1kb.yaml
```
La configuration du débit de production a été augmentée en quatre itérations et l'utilisation du processeur a été enregistrée avec Grafana. Le taux de production a été défini sur les niveaux suivants :
- 10,000
- 40,000
- 80,000
- 100,000

Observation

L'utilisation du stockage NFS NetApp avec Kafka présente deux avantages principaux :

Vous pouvez réduire l'utilisation du processeur de près d'un tiers. l'utilisation globale du processeur sous des charges de travail similaires a été plus faible pour NFS que pour les SSD DAS ; les économies vont de 5 % pour des taux de production inférieurs à 32 % pour des taux de production plus élevés.
Une diminution de trois fois de la dérive de l'utilisation du CPU à des taux de production plus élevés. comme prévu, il y a eu une dérive à la hausse de l'augmentation de l'utilisation du CPU au fur et à mesure que les taux de production ont été augmentés. Cependant, le taux d'utilisation du CPU sur les courtiers Kafka qui utilisent le DAS est passé de 31 % pour le taux de production inférieur à 70 % pour le taux de production supérieur, soit une augmentation de 39 %. Cependant, avec un système de stockage NFS back-end, l'utilisation du processeur est passée de 26 à 38 %, soit une augmentation de 12 %.

Ce graphique illustre le comportement d'un cluster DAS.

Ce graphique illustre le comportement d'un cluster basé sur NFS.

De plus, avec 100,000 messages, le DAS affiche une plus grande utilisation du CPU qu'un cluster NFS.

Ce graphique illustre le comportement d'un cluster DAS à 100,000 messages.

Ce graphique illustre le comportement d'un cluster NFS à 100,000 messages.

Une restauration plus rapide des courtiers

Nous avons découvert que les courtiers Kafka accélèrent la restauration lorsqu'ils utilisent un stockage NetApp NFS partagé. Lorsqu'un courtier tombe en panne dans un cluster Kafka, ce courtier peut être remplacé par un courtier sain avec le même ID de courtier. Lors de l'exécution de ce test, nous avons constaté que, dans le cas d'un cluster Kafka basé sur DAS, le cluster reconstruit les données sur un nouveau courtier en état de fonctionnement, ce qui prend du temps. Dans le cas d'un cluster Kafka basé sur NetApp NFS, le courtier qui remplace le système continue à lire les données à partir du précédent répertoire de journaux et restaure beaucoup plus rapidement.