Skip to main content
NetApp Solutions
Se proporciona el idioma español mediante traducción automática para su comodidad. En caso de alguna inconsistencia, el inglés precede al español.

Información general y validación del rendimiento en AWS

Colaboradores

Se realizó una prueba de rendimiento de un clúster Kafka con capa de almacenamiento montada en NFS de NetApp en el cloud de AWS. Los ejemplos de pruebas comparativas se describen en las siguientes secciones.

Kafka en el cloud de AWS con Cloud Volumes ONTAP de NetApp (pareja de alta disponibilidad y nodo único)

Se realizó una prueba de rendimiento de un clúster de Kafka con Cloud Volumes ONTAP de NetApp (pareja de alta disponibilidad) en el cloud de AWS. Esta evaluación comparativa se describe en las siguientes secciones.

Configuración de la arquitectura

En la siguiente tabla se muestra la configuración del entorno de un clúster de Kafka con NAS.

Componente de plataforma Configuración del entorno

Kafka 3.2.3

  • 3 zookeepers – t2.pequeño

  • 3 servidores de broker: i3en.2xlarge

  • 1 x Grafana – c5n.2xgrande

  • 4 x productor/consumidor — c5n.2xgrande *

Sistema operativo en todos los nodos

RHEL8.6

Instancia de Cloud Volumes ONTAP de NetApp

Instancia de par DE ALTA DISPONIBILIDAD – m5dn.12xLarge x 2 node Single Node Instance - m5dn.12xLarge x 1 node

Configuración de ONTAP para volúmenes del clúster de NetApp

  1. Para el par de alta disponibilidad de Cloud Volumes ONTAP, hemos creado dos agregados con tres volúmenes en cada agregado de cada controladora de almacenamiento. Para el nodo único de Cloud Volumes ONTAP, creamos seis volúmenes en un agregado.

    Esta imagen muestra las propiedades de aggr3 y aggr22.

    Esta imagen muestra las propiedades de aggr2.

  2. Para mejorar el rendimiento de red, hemos habilitado redes de alta velocidad para el par de alta disponibilidad y el nodo único.

    Esta imagen muestra cómo activar redes de alta velocidad.

  3. Hemos observado que el ONTAP NVRAM tenía más IOPS, por lo que hemos cambiado el IOPS a 2350 para el volumen raíz de Cloud Volumes ONTAP. El disco del volumen raíz en Cloud Volumes ONTAP tenía un tamaño de 47 GB. El siguiente comando ONTAP es para el par de alta disponibilidad, y el mismo paso es aplicable para el único nodo.

    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::*>

    Estas imágenes muestran la forma de modificar las propiedades del volumen.

En la figura siguiente se muestra la arquitectura de un clúster Kafka basado en NAS.

  • Compute. utilizamos un clúster Kafka de tres nodos con un conjunto de zoomkeeper de tres nodos que se ejecuta en servidores dedicados. Cada agente tenía dos puntos de montaje NFS en un único volumen de la instancia de Cloud Volumes ONTAP a través de un LIF dedicado.

  • Supervisión. utilizamos dos nodos para una combinación Prometheus-Grafana. Para generar cargas de trabajo, utilizamos un clúster de tres nodos independiente que podía producir y consumir este clúster Kafka.

  • Almacenamiento. utilizamos una instancia Cloud Volumes ONTAP de par de alta disponibilidad con un volumen GP3 de 6 TB AWS-EBS montado en la instancia. El volumen se exportó después al agente de Kafka con un montaje NFS.

En esta figura, se muestra la arquitectura de un clúster Kafka basado en NAS.

Configuraciones de pruebas de rendimiento de OpenMessage

  1. Para obtener un mejor rendimiento NFS, se necesitan más conexiones de red entre el servidor NFS y el cliente NFS, que se pueden crear utilizando nconnect. Monte los volúmenes NFS en los nodos de broker con la opción nconnect ejecutando el siguiente comando:

    [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. Compruebe las conexiones de red en Cloud Volumes ONTAP. El siguiente comando ONTAP se usa desde el nodo único de Cloud Volumes ONTAP. El mismo paso es aplicable al par de alta disponibilidad de 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. Utilizamos el siguiente Kafka server.properties En todos los agentes de Kafka para el par de alta disponibilidad de Cloud Volumes ONTAP. La log.dirs la propiedad es diferente para cada agente, y las propiedades restantes son comunes para los corredores. Para corredura1, el log.dirs el valor es el siguiente:

    [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 ~]#
    • Para corredura2, la log.dirs el valor de la propiedad es el siguiente:

      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
    • Para corredura3, el log.dirs el valor de la propiedad es el siguiente:

      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. Para el nodo único de Cloud Volumes ONTAP, el Kafka servers.properties Es lo mismo que para el par de alta disponibilidad de Cloud Volumes ONTAP, a excepción de la log.dirs propiedad.

    • Para corredura1, el log.dirs el valor es el siguiente:

      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
    • Para corredura2, la log.dirs el valor es el siguiente:

      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
    • Para corredura3, el log.dirs el valor de la propiedad es el siguiente:

      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 carga de trabajo en el OMB se configura con las siguientes propiedades: (/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

    La messageSize puede variar para cada caso de uso. En nuestra prueba de rendimiento, utilizamos 3K.

    Utilizamos dos controladores distintos, Sync o Throughput, de OMB, para generar la carga de trabajo en el clúster Kafka.

    • El archivo yaml utilizado para las propiedades del controlador Sync es el siguiente (/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
    • El archivo yaml utilizado para las propiedades del controlador de rendimiento es el siguiente (/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

Metodología de las pruebas

  1. Se aprovisionó un clúster de Kafka según las especificaciones descritas anteriormente con Terraform y Ansible. Terraform se utiliza para crear la infraestructura con instancias de AWS para el clúster de Kafka y Ansible crea el clúster de Kafka.

  2. Se activó una carga de trabajo de OMB con la configuración de carga de trabajo descrita anteriormente y el controlador de sincronización.

    Sudo bin/benchmark –drivers driver-kafka/kafka- sync.yaml workloads/1-topic-100-partitions-1kb.yaml
  3. Se activó otra carga de trabajo con el controlador de rendimiento con la misma configuración de carga de trabajo.

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

Observación

Se utilizaron dos tipos distintos de controladores para generar cargas de trabajo con el fin de llevar a cabo una prueba de rendimiento de una instancia de Kafka que se ejecuta en NFS. La diferencia entre los controladores es la propiedad log flush.

En un par de alta disponibilidad de Cloud Volumes ONTAP:

  • Rendimiento total generado de forma coherente por el controlador Sync: ~1236 Mbps.

  • Rendimiento total generado para el controlador de rendimiento: Pico de ~1412 Mbps.

Para un único nodo Cloud Volumes ONTAP:

  • Rendimiento total generado de forma consistente por el controlador Sync: ~ 1962MBps.

  • Rendimiento total generado por el controlador de rendimiento: Pico de ~1660 MB

El controlador Sync puede generar un rendimiento constante a medida que los registros se vacíen en el disco al instante, mientras que el controlador de rendimiento genera ráfagas de rendimiento a medida que los registros se envían al disco de forma masiva.

Estos números de rendimiento se generan para la configuración de AWS determinada. Para requisitos de rendimiento más altos, los tipos de instancias se pueden escalar verticalmente para mejorar los números de rendimiento. El rendimiento total o la tasa total es la combinación de la tasa de producción y del consumidor.

Aquí se presentan cuatro gráficos diferentes. Controlador de rendimiento de par CVO-ha. Controlador de sincronización de pares CVO-ha. Controlador de rendimiento de nodo único CVO. Controlador CVO-Single Node Sync.

Asegúrese de comprobar el rendimiento del almacenamiento al realizar el rendimiento o sincronizar las pruebas de rendimiento del controlador.

Este gráfico muestra el rendimiento en la latencia, IOPS y rendimiento.