Skip to main content
NetApp Solutions
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Présentation des performances et validation dans AWS

Contributeurs
PDF

Les performances dans le cloud AWS ont été évaluées sur un cluster Kafka avec la couche de stockage montée sur NetApp NFS. Les exemples de benchmarking sont décrits dans les sections suivantes.

Kafka dans le cloud AWS avec NetApp Cloud Volumes ONTAP (paire haute disponibilité et nœud unique)

Un cluster Kafka avec NetApp Cloud Volumes ONTAP (paire haute disponibilité) a été testé sur banc d'essai pour la performance dans le cloud AWS. Cette analyse comparative est décrite dans les sections suivantes.

Installation architecturale

Le tableau suivant présente la configuration environnementale d'un cluster Kafka utilisant un NAS.

Composant de plate-forme Configuration de l'environnement

Kafka 3.2.3

  • 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

RHEL8.6

Instance NetApp Cloud Volumes ONTAP

Instance de paire HAUTE DISPONIBILITÉ – m5dn.12xLarge x 2 nœuds instance de nœud unique - m5dn.12xLarge x 1 nœud

Configuration de NetApp Cluster volume ONTAP

  1. Pour la paire haute disponibilité Cloud Volumes ONTAP, nous avons créé deux agrégats avec trois volumes sur chaque agrégat de chaque contrôleur de stockage. Pour le seul nœud Cloud Volumes ONTAP, nous créons six volumes dans un agrégat.

    Cette image illustre les propriétés de aggr3 et aggr22.

    Cette image illustre les propriétés d'aggr2.

  2. Afin d'améliorer les performances réseau, nous avons activé une mise en réseau haut débit pour la paire haute disponibilité et le nœud unique.

    Cette image montre comment activer la mise en réseau haut débit.

  3. Nous avons constaté que la mémoire NVRAM de ONTAP offrait plus d'IOPS. Nous avons donc remplacé le nombre d'IOPS par un nombre de 2350 pour le volume racine Cloud Volumes ONTAP. La taille du disque de volume racine dans Cloud Volumes ONTAP était de 47 Go. La commande ONTAP suivante s'applique à la paire HA, et la même étape s'applique à un seul nœud.

    statistics start -object vnvram -instance vnvram -counter backing_store_iops -sample-id sample_555
kafka_nfs_cvo_ha1::*> statistics show -sample-id sample_555
Object: vnvram
Instance: vnvram
Start-time: 1/18/2023 18:03:11
End-time: 1/18/2023 18:03:13
Elapsed-time: 2s
Scope: kafka_nfs_cvo_ha1-01
    Counter                                                     Value
    -------------------------------- --------------------------------
    backing_store_iops                                           1479
Object: vnvram
Instance: vnvram
Start-time: 1/18/2023 18:03:11
End-time: 1/18/2023 18:03:13
Elapsed-time: 2s
Scope: kafka_nfs_cvo_ha1-02
    Counter                                                     Value
    -------------------------------- --------------------------------
    backing_store_iops                                           1210
2 entries were displayed.
kafka_nfs_cvo_ha1::*>

    Cette image montre comment modifier les propriétés du volume.

La figure suivante illustre l'architecture d'un cluster Kafka basé sur NAS.

  • 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 NFS sur un seul volume de l'instance Cloud Volumes ONTAP 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 avons utilisé un cluster séparé à trois nœuds qui était capable de produire et de consommer sur ce cluster Kafka.

  • Stockage nous avons utilisé une instance Cloud Volumes ONTAP à paire haute disponibilité avec un volume GP3 AWS-EBS de 6 To monté sur l'instance. Le volume a ensuite été exporté vers le courtier Kafka avec un montage NFS.

Cette figure illustre l'architecture d'un cluster Kafka basé sur NAS.

Configurations de test OpenMessage

  1. Pour améliorer les performances NFS, nous avons besoin d'un plus grand nombre de connexions réseau entre le serveur NFS et le client NFS, qui peuvent être créées à l'aide de nconnect. Montez les volumes NFS sur les nœuds de courtier avec l'option nconnect en exécutant la commande suivante :

    [root@ip-172-30-0-121 ~]# cat /etc/fstab
UUID=eaa1f38e-de0f-4ed5-a5b5-2fa9db43bb38/xfsdefaults00
/dev/nvme1n1 /mnt/data-1 xfs defaults,noatime,nodiscard 0 0
/dev/nvme2n1 /mnt/data-2 xfs defaults,noatime,nodiscard 0 0
172.30.0.233:/kafka_aggr3_vol1 /kafka_aggr3_vol1 nfs defaults,nconnect=16 0 0
172.30.0.233:/kafka_aggr3_vol2 /kafka_aggr3_vol2 nfs defaults,nconnect=16 0 0
172.30.0.233:/kafka_aggr3_vol3 /kafka_aggr3_vol3 nfs defaults,nconnect=16 0 0
172.30.0.242:/kafka_aggr22_vol1 /kafka_aggr22_vol1 nfs defaults,nconnect=16 0 0
172.30.0.242:/kafka_aggr22_vol2 /kafka_aggr22_vol2 nfs defaults,nconnect=16 0 0
172.30.0.242:/kafka_aggr22_vol3 /kafka_aggr22_vol3 nfs defaults,nconnect=16 0 0
[root@ip-172-30-0-121 ~]# mount -a
[root@ip-172-30-0-121 ~]# df -h
Filesystem                       Size  Used Avail Use% Mounted on
devtmpfs                          31G     0   31G   0% /dev
tmpfs                             31G  249M   31G   1% /run
tmpfs                             31G     0   31G   0% /sys/fs/cgroup
/dev/nvme0n1p2                    10G  2.8G  7.2G  28% /
/dev/nvme1n1                     2.3T  248G  2.1T  11% /mnt/data-1
/dev/nvme2n1                     2.3T  245G  2.1T  11% /mnt/data-2
172.30.0.233:/kafka_aggr3_vol1   1.0T   12G 1013G   2% /kafka_aggr3_vol1
172.30.0.233:/kafka_aggr3_vol2   1.0T  5.5G 1019G   1% /kafka_aggr3_vol2
172.30.0.233:/kafka_aggr3_vol3   1.0T  8.9G 1016G   1% /kafka_aggr3_vol3
172.30.0.242:/kafka_aggr22_vol1  1.0T  7.3G 1017G   1% /kafka_aggr22_vol1
172.30.0.242:/kafka_aggr22_vol2  1.0T  6.9G 1018G   1% /kafka_aggr22_vol2
172.30.0.242:/kafka_aggr22_vol3  1.0T  5.9G 1019G   1% /kafka_aggr22_vol3
tmpfs                            6.2G     0  6.2G   0% /run/user/1000
[root@ip-172-30-0-121 ~]#

  2. Vérifiez les connexions réseau dans Cloud Volumes ONTAP. La commande ONTAP suivante est utilisée à partir du nœud Cloud Volumes ONTAP unique. La même étape s'applique à la paire haute disponibilité Cloud Volumes ONTAP.

    Last login time: 1/20/2023 00:16:29
kafka_nfs_cvo_sn::> network connections active show -service nfs* -fields remote-host
node                cid        vserver              remote-host
------------------- ---------- -------------------- ------------
kafka_nfs_cvo_sn-01 2315762628 svm_kafka_nfs_cvo_sn 172.30.0.121
kafka_nfs_cvo_sn-01 2315762629 svm_kafka_nfs_cvo_sn 172.30.0.121
kafka_nfs_cvo_sn-01 2315762630 svm_kafka_nfs_cvo_sn 172.30.0.121
kafka_nfs_cvo_sn-01 2315762631 svm_kafka_nfs_cvo_sn 172.30.0.121
kafka_nfs_cvo_sn-01 2315762632 svm_kafka_nfs_cvo_sn 172.30.0.121
kafka_nfs_cvo_sn-01 2315762633 svm_kafka_nfs_cvo_sn 172.30.0.121
kafka_nfs_cvo_sn-01 2315762634 svm_kafka_nfs_cvo_sn 172.30.0.121
kafka_nfs_cvo_sn-01 2315762635 svm_kafka_nfs_cvo_sn 172.30.0.121
kafka_nfs_cvo_sn-01 2315762636 svm_kafka_nfs_cvo_sn 172.30.0.121
kafka_nfs_cvo_sn-01 2315762637 svm_kafka_nfs_cvo_sn 172.30.0.121
kafka_nfs_cvo_sn-01 2315762639 svm_kafka_nfs_cvo_sn 172.30.0.72
kafka_nfs_cvo_sn-01 2315762640 svm_kafka_nfs_cvo_sn 172.30.0.72
kafka_nfs_cvo_sn-01 2315762641 svm_kafka_nfs_cvo_sn 172.30.0.72
kafka_nfs_cvo_sn-01 2315762642 svm_kafka_nfs_cvo_sn 172.30.0.72
kafka_nfs_cvo_sn-01 2315762643 svm_kafka_nfs_cvo_sn 172.30.0.72
kafka_nfs_cvo_sn-01 2315762644 svm_kafka_nfs_cvo_sn 172.30.0.72
kafka_nfs_cvo_sn-01 2315762645 svm_kafka_nfs_cvo_sn 172.30.0.72
kafka_nfs_cvo_sn-01 2315762646 svm_kafka_nfs_cvo_sn 172.30.0.72
kafka_nfs_cvo_sn-01 2315762647 svm_kafka_nfs_cvo_sn 172.30.0.72
kafka_nfs_cvo_sn-01 2315762648 svm_kafka_nfs_cvo_sn 172.30.0.72
kafka_nfs_cvo_sn-01 2315762649 svm_kafka_nfs_cvo_sn 172.30.0.121
kafka_nfs_cvo_sn-01 2315762650 svm_kafka_nfs_cvo_sn 172.30.0.121
kafka_nfs_cvo_sn-01 2315762651 svm_kafka_nfs_cvo_sn 172.30.0.121
kafka_nfs_cvo_sn-01 2315762652 svm_kafka_nfs_cvo_sn 172.30.0.121
kafka_nfs_cvo_sn-01 2315762653 svm_kafka_nfs_cvo_sn 172.30.0.121
kafka_nfs_cvo_sn-01 2315762656 svm_kafka_nfs_cvo_sn 172.30.0.223
kafka_nfs_cvo_sn-01 2315762657 svm_kafka_nfs_cvo_sn 172.30.0.223
kafka_nfs_cvo_sn-01 2315762658 svm_kafka_nfs_cvo_sn 172.30.0.223
kafka_nfs_cvo_sn-01 2315762659 svm_kafka_nfs_cvo_sn 172.30.0.223
kafka_nfs_cvo_sn-01 2315762660 svm_kafka_nfs_cvo_sn 172.30.0.223
kafka_nfs_cvo_sn-01 2315762661 svm_kafka_nfs_cvo_sn 172.30.0.223
kafka_nfs_cvo_sn-01 2315762662 svm_kafka_nfs_cvo_sn 172.30.0.223
kafka_nfs_cvo_sn-01 2315762663 svm_kafka_nfs_cvo_sn 172.30.0.223
kafka_nfs_cvo_sn-01 2315762664 svm_kafka_nfs_cvo_sn 172.30.0.223
kafka_nfs_cvo_sn-01 2315762665 svm_kafka_nfs_cvo_sn 172.30.0.223
kafka_nfs_cvo_sn-01 2315762666 svm_kafka_nfs_cvo_sn 172.30.0.223
kafka_nfs_cvo_sn-01 2315762667 svm_kafka_nfs_cvo_sn 172.30.0.72
kafka_nfs_cvo_sn-01 2315762668 svm_kafka_nfs_cvo_sn 172.30.0.72
kafka_nfs_cvo_sn-01 2315762669 svm_kafka_nfs_cvo_sn 172.30.0.72
kafka_nfs_cvo_sn-01 2315762670 svm_kafka_nfs_cvo_sn 172.30.0.72
kafka_nfs_cvo_sn-01 2315762671 svm_kafka_nfs_cvo_sn 172.30.0.72
kafka_nfs_cvo_sn-01 2315762672 svm_kafka_nfs_cvo_sn 172.30.0.72
kafka_nfs_cvo_sn-01 2315762673 svm_kafka_nfs_cvo_sn 172.30.0.223
kafka_nfs_cvo_sn-01 2315762674 svm_kafka_nfs_cvo_sn 172.30.0.223
kafka_nfs_cvo_sn-01 2315762676 svm_kafka_nfs_cvo_sn 172.30.0.121
kafka_nfs_cvo_sn-01 2315762677 svm_kafka_nfs_cvo_sn 172.30.0.223
kafka_nfs_cvo_sn-01 2315762678 svm_kafka_nfs_cvo_sn 172.30.0.223
kafka_nfs_cvo_sn-01 2315762679 svm_kafka_nfs_cvo_sn 172.30.0.223
48 entries were displayed.
 
kafka_nfs_cvo_sn::>

  3. Nous utilisons Kafka suivant server.properties Dans tous les courtiers Kafka de la paire HA Cloud Volumes ONTAP. Le log.dirs la propriété est différente pour chaque courtier, et les autres propriétés sont communes aux courtiers. Pour broker1, le log.dirs la valeur est la suivante :

    [root@ip-172-30-0-121 ~]# cat /opt/kafka/config/server.properties
broker.id=0
advertised.listeners=PLAINTEXT://172.30.0.121:9092
#log.dirs=/mnt/data-1/d1,/mnt/data-1/d2,/mnt/data-1/d3,/mnt/data-2/d1,/mnt/data-2/d2,/mnt/data-2/d3
log.dirs=/kafka_aggr3_vol1/broker1,/kafka_aggr3_vol2/broker1,/kafka_aggr3_vol3/broker1,/kafka_aggr22_vol1/broker1,/kafka_aggr22_vol2/broker1,/kafka_aggr22_vol3/broker1
zookeeper.connect=172.30.0.12:2181,172.30.0.30:2181,172.30.0.178:2181
num.network.threads=64
num.io.threads=64
socket.send.buffer.bytes=102400
socket.receive.buffer.bytes=102400
socket.request.max.bytes=104857600
num.partitions=1
num.recovery.threads.per.data.dir=1
offsets.topic.replication.factor=1
transaction.state.log.replication.factor=1
transaction.state.log.min.isr=1
replica.fetch.max.bytes=524288000
background.threads=20
num.replica.alter.log.dirs.threads=40
num.replica.fetchers=20
[root@ip-172-30-0-121 ~]#

    • Pour broker2, le log.dirs la valeur de la propriété est la suivante :

      log.dirs=/kafka_aggr3_vol1/broker2,/kafka_aggr3_vol2/broker2,/kafka_aggr3_vol3/broker2,/kafka_aggr22_vol1/broker2,/kafka_aggr22_vol2/broker2,/kafka_aggr22_vol3/broker2

    • Pour broker3, le log.dirs la valeur de la propriété est la suivante :

      log.dirs=/kafka_aggr3_vol1/broker3,/kafka_aggr3_vol2/broker3,/kafka_aggr3_vol3/broker3,/kafka_aggr22_vol1/broker3,/kafka_aggr22_vol2/broker3,/kafka_aggr22_vol3/broker3

  4. Pour le seul nœud Cloud Volumes ONTAP, Kafka servers.properties Est identique à celui de la paire haute disponibilité Cloud Volumes ONTAP, à l'exception du log.dirs propriété.

    • Pour broker1, le log.dirs la valeur est la suivante :

      log.dirs=/kafka_aggr2_vol1/broker1,/kafka_aggr2_vol2/broker1,/kafka_aggr2_vol3/broker1,/kafka_aggr2_vol4/broker1,/kafka_aggr2_vol5/broker1,/kafka_aggr2_vol6/broker1

    • Pour broker2, le log.dirs la valeur est la suivante :

      log.dirs=/kafka_aggr2_vol1/broker2,/kafka_aggr2_vol2/broker2,/kafka_aggr2_vol3/broker2,/kafka_aggr2_vol4/broker2,/kafka_aggr2_vol5/broker2,/kafka_aggr2_vol6/broker2

    • Pour broker3, le log.dirs la valeur de la propriété est la suivante :

      log.dirs=/kafka_aggr2_vol1/broker3,/kafka_aggr2_vol2/broker3,/kafka_aggr2_vol3/broker3,/kafka_aggr2_vol4/broker3,/kafka_aggr2_vol5/broker3,/kafka_aggr2_vol6/broker3

  5. La charge de travail dans l'OMB est configurée avec les propriétés suivantes : (/opt/benchmark/workloads/1-topic-100-partitions-1kb.yaml).

    topics: 4
partitionsPerTopic: 100
messageSize: 32768
useRandomizedPayloads: true
randomBytesRatio: 0.5
randomizedPayloadPoolSize: 100
subscriptionsPerTopic: 1
consumerPerSubscription: 80
producersPerTopic: 40
producerRate: 1000000
consumerBacklogSizeGB: 0
testDurationMinutes: 5

    Le messageSize peuvent varier selon les utilisations. Lors de notre test de performance, nous avons utilisé 3 Ko.

    Nous avons utilisé deux pilotes différents, Sync ou Throughput, d'OMB pour générer la charge de travail sur le cluster Kafka.

    • Le fichier yaml utilisé pour les propriétés du pilote Sync est le suivant (/opt/benchmark/driver- kafka/kafka-sync.yaml):

      name: Kafka
driverClass: io.openmessaging.benchmark.driver.kafka.KafkaBenchmarkDriver
# Kafka client-specific configuration
replicationFactor: 3
topicConfig: |
  min.insync.replicas=2
  flush.messages=1
  flush.ms=0
commonConfig: |
  bootstrap.servers=172.30.0.121:9092,172.30.0.72:9092,172.30.0.223:9092
producerConfig: |
  acks=all
  linger.ms=1
  batch.size=1048576
consumerConfig: |
  auto.offset.reset=earliest
  enable.auto.commit=false
  max.partition.fetch.bytes=10485760

    • Le fichier yaml utilisé pour les propriétés du pilote Throughput est le suivant (/opt/benchmark/driver- kafka/kafka-throughput.yaml):

      name: Kafka
driverClass: io.openmessaging.benchmark.driver.kafka.KafkaBenchmarkDriver
# Kafka client-specific configuration
replicationFactor: 3
topicConfig: |
  min.insync.replicas=2
commonConfig: |
  bootstrap.servers=172.30.0.121:9092,172.30.0.72:9092,172.30.0.223:9092
  default.api.timeout.ms=1200000
  request.timeout.ms=1200000
producerConfig: |
  acks=all
  linger.ms=1
  batch.size=1048576
consumerConfig: |
  auto.offset.reset=earliest
  enable.auto.commit=false
  max.partition.fetch.bytes=10485760

Méthodologie de test

  1. Un cluster Kafka a été provisionné selon la spécification décrite ci-dessus à l'aide de Terraform et Ansible. Terraform est utilisé pour créer l'infrastructure à l'aide d'instances AWS pour le cluster Kafka et Ansible y intègre le cluster Kafka.

  2. Une charge de travail OMB a été déclenchée avec la configuration de la charge de travail décrite ci-dessus et le pilote Sync.

    Sudo bin/benchmark –drivers driver-kafka/kafka- sync.yaml workloads/1-topic-100-partitions-1kb.yaml

  3. Une autre charge de travail a été déclenchée avec le pilote de débit avec la même configuration de charge de travail.

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

Observation

Deux types de pilotes différents ont été utilisés pour générer des charges de travail afin de tester les performances d'une instance Kafka fonctionnant sur NFS. La différence entre les pilotes est la propriété log flush.

Pour une paire Cloud Volumes ONTAP HA :

  • Débit total généré de manière cohérente par le pilote de synchronisation : environ 1236 Mbit/s.

  • Débit total généré pour le pilote de débit : pic de ~1412 Mbit/s.

Pour un seul nœud Cloud Volumes ONTAP :

  • Débit total généré de manière cohérente par le pilote Sync : ~ 1962 Mbit/s.

  • Débit total généré par le pilote de débit : pic d'environ 1660 Mbit/s.

Le pilote de synchronisation peut générer un débit constant lorsque les journaux sont immédiatement transmis au disque, tandis que le pilote de débit génère des pics de débit lorsque les journaux sont validés sur le disque en bloc.

Ces valeurs de débit sont générées pour la configuration AWS appropriée. Pour des besoins de performances plus élevés, il est possible de renforcer l'évolutivité des types d'instances et de les ajuster davantage pour obtenir un meilleur débit. Le débit total ou le taux total est la combinaison du taux de production et du taux de consommation.

Quatre graphiques différents sont présentés ici. Pilote de débit CVO-HA pair. Pilote de synchronisation de paire CVO-HA. Pilote de débit de nœud CVO unique. Pilote CVO-Single Node Sync.

Vérifiez le débit de stockage lorsque vous effectuez une évaluation du débit ou du pilote de synchronisation.

Ce graphique présente les performances en termes de latence, d'IOPS et de débit.