本繁體中文版使用機器翻譯，譯文僅供參考，若與英文版本牴觸，應以英文版本為準。

本地AFF A900的效能概述與驗證

08/18/2025

PDF

在本地，我們使用具有ONTAP 9.12.1RC1 的NetApp AFF A900儲存控制器來驗證 Kafka 叢集的效能和擴展性。我們使用了與先前的ONTAP和AFF分層儲存最佳實踐相同的測試平台。

我們使用 Confluent Kafka 6.2.0 來評估AFF A900。該叢集有八個代理節點和三個 zookeeper 節點。為了進行效能測試，我們使用了五個 OMB 工作節點。

此圖顯示輸入/輸出對話框或表示書面內容

儲存配置

我們使用NetApp FlexGroups 實例為日誌目錄提供單一命名空間，從而簡化復原和配置。我們使用 NFSv4.1 和 pNFS 來提供對日誌段資料的直接路徑存取。

客戶端調優

每個客戶端使用以下命令掛載FlexGroup實例。

mount -t nfs -o vers=4.1,nconnect=16 172.30.0.121:/kafka_vol01 /data/kafka_vol01

此外，我們增加了 max_session_slots``從預設 `64`到 `180。這與ONTAP中的預設會話槽限制相符。

Kafka 代理調優

為了最大限度地提高測試系統的吞吐量，我們顯著增加了某些關鍵線程池的預設參數。對於大多數配置，我們建議遵循 Confluent Kafka 最佳實踐。此調整用於最大化儲存的未完成 I/O 的並發性。這些參數可以進行調整以符合您的代理程式的運算資源和儲存屬性。

num.io.threads=96
num.network.threads=96
background.threads=20
num.replica.alter.log.dirs.threads=40
num.replica.fetchers=20
queued.max.requests=2000

工作負載產生器測試方法

我們對吞吐量驅動程式和主題配置使用了與雲端測試相同的 OMB 配置。

使用 Ansible 在AFF叢集上設定了FlexGroup實例。

---
- name: Set up kafka broker processes
  hosts: localhost
  vars:
    ntap_hostname: 'hostname'
    ntap_username: 'user'
    ntap_password: 'password'
    size: 10
    size_unit: tb
    vserver: vs1
    state: present
    https: true
    export_policy: default
    volumes:
      - name: kafka_fg_vol01
        aggr: ["aggr1_a", "aggr2_a", "aggr1_b", "aggr2_b"]
        path: /kafka_fg_vol01
  tasks:
    - name: Edit volumes
      netapp.ontap.na_ontap_volume:
        state: "{{ state }}"
        name: "{{ item.name }}"
        aggr_list: "{{ item.aggr }}"
        aggr_list_multiplier: 8
        size: "{{ size }}"
        size_unit: "{{ size_unit }}"
        vserver: "{{ vserver }}"
        snapshot_policy: none
        export_policy: default
        junction_path: "{{ item.path }}"
        qos_policy_group: none
        wait_for_completion: True
        hostname: "{{ ntap_hostname }}"
        username: "{{ ntap_username }}"
        password: "{{ ntap_password }}"
        https: "{{ https }}"
        validate_certs: false
      connection: local
      with_items: "{{ volumes }}"

ONTAP SVM 上已啟用 pNFS。

vserver modify -vserver vs1 -v4.1-pnfs enabled -tcp-max-xfer-size 262144

工作負載由吞吐量驅動程式觸發，使用與Cloud Volumes ONTAP相同的工作負載配置。請參閱“穩態性能 “ 以下。工作負載使用的複製因子為 3，這表示在 NFS 中維護了三個日誌段副本。
```
sudo bin/benchmark --drivers driver-kafka/kafka-throughput.yaml workloads/1-topic-100-partitions-1kb.yaml
```
最後，我們使用積壓完成了測量，以衡量消費者趕上最新消息的能力。 OMB 透過在測量開始時暫停消費者來建立積壓。這會產生三個不同的階段：積壓創建（僅生產者的流量）、積壓消耗（消費者密集的階段，其中消費者追趕主題中錯過的事件）和穩定狀態。請參閱“極致效能與探索儲存極限 ”獲取更多資訊。

穩態性能

我們使用 OpenMessaging Benchmark 評估了AFF A900 ，以提供與 AWS 中的Cloud Volumes ONTAP和 AWS 中的 DAS 類似的比較。所有效能值代表生產者和消費者層級的 Kafka 叢集吞吐量。

Confluent Kafka 和AFF A900的穩定狀態效能為生產者和消費者實現了超過 3.4GBps 的平均吞吐量。 Kafka 叢集中的訊息超過 340 萬條。透過以每秒位元組數為單位視覺化 BrokerTopicMetrics 的持續吞吐量，我們可以看到AFF A900支援的出色穩定狀態效能和流量。

此圖顯示了代理網路吞吐量。

這與按主題傳遞的訊息的視圖非常一致。下圖提供了按主題的細分情況。在測試的配置中，我們看到四個主題中每個主題有近 90 萬個訊息。

此圖顯示了代理網路吞吐量。

極致效能與探索儲存極限

對於AFF，我們也使用積壓功能對 OMB 進行了測試。當 Kafka 叢集中累積了大量事件積壓時，積壓功能會暫停消費者訂閱。在此階段，僅發生生產者流量，產生提交到日誌的事件。這最接近地模擬了批次或離線分析工作流程；在這些工作流程中，消費者訂閱已啟動，並且必須讀取已從代理快取中逐出的歷史資料。

為了了解此配置中儲存對消費者吞吐量的限制，我們測量了僅生產者階段，以了解 A900 可以吸收多少寫入流量。請參閱下一節“尺寸指南「來了解如何利用這些數據。

在本次測量的僅生產者部分，我們看到了高峰值吞吐量，突破了 A900 效能的極限（當其他代理資源未飽和地為生產者和消費者流量提供服務時）。

此圖顯示輸入/輸出對話框或表示書面內容

我們將此測量的訊息大小增加到 16k，以限制每個訊息的開銷並最大化 NFS 掛載點的儲存吞吐量。

messageSize: 16384
consumerBacklogSizeGB: 4096

Confluent Kafka 叢集實現了 4.03GBps 的峰值生產者吞吐量。

18:12:23.833 [main] INFO WorkloadGenerator - Pub rate 257759.2 msg/s / 4027.5 MB/s | Pub err     0.0 err/s …

OMB 完成填入事件積壓日誌後，消費者流量重新啟動。在積壓工作消耗的測量過程中，我們觀察到所有主題的峰值消費者吞吐量超過 20GBps。儲存 OMB 日誌資料的 NFS 磁碟區的組合吞吐量接近 ~30GBps。

尺寸指南

亞馬遜網路服務提供 "尺寸指南"用於 Kafka 叢集大小調整和擴展。

此大小提供了一個有用的公式來確定 Kafka 叢集的儲存吞吐量需求：

對於複製因子為 r 的 tcluster 叢集產生的聚合吞吐量，代理儲存收到的吞吐量如下：

t[storage] = t[cluster]/#brokers + t[cluster]/#brokers * (r-1)
          = t[cluster]/#brokers * r

這可以進一步簡化：

max(t[cluster]) <= max(t[storage]) * #brokers/r

使用此公式，您可以根據 Kafka 熱層需求選擇合適的ONTAP平台。

下表解釋了具有不同複製因子的 A900 的預期生產者吞吐量：

複製因子	生產者吞吐量 (GPps)
3（測量）	3.4
2	5.1
1	10.2