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

功能驗證-不太好用的重新命名修正程式

貢獻者
PDF

在功能驗證方面、我們發現裝有NFSv3儲存設備掛載的Kafka叢集無法執行像分割區重新分佈等Kafka作業、而裝在NFSv3上的另一個叢集搭配修正程式、則可執行相同的作業、而不會造成任何中斷。

驗證設定

設定會在AWS上執行。下表顯示驗證所使用的不同平台元件和環境組態。

平台元件 環境組態

ConFluent Platform 7.2.1版

  • 3個zookeepers–T3.xlarge

  • 4個代理伺服器–R3.xlarge

  • 1 x Grafana–T3.xlarge

  • 1個控制中心–T3.xLarge

  • 3個製造商/消費者

所有節點上的作業系統

RHEL8.7或更新版本

NetApp Cloud Volumes ONTAP 執行個體

單節點執行個體–M5.2xLarge

下圖顯示此解決方案的架構組態。

此映像顯示AWS拓撲、其中包含三個子網路、分別具有監控者swarm、Kafka叢集和CVO執行個體的VPC。

架構流程

  • *運算*我們使用四節點的Kafka叢集、其中三節點的zookeeper集合體執行於專屬伺服器上。

  • *監控*我們使用兩個節點來搭配Prometheus-Grafana。

  • 工作負載。*為了產生工作負載、我們使用了一個獨立的三節點叢集、可產生和使用此Kafka叢集。

  • * Storage。*我們使用單節點NetApp Cloud Volumes ONTAP 支援執行個體、並將兩個500GB GP2 AWS-EBS磁碟區附加至執行個體。然後、這些磁碟區會透過LIF以單一NFSv4.1磁碟區的形式、公開給Kafka叢集。

所有伺服器都會選擇Kafka的預設屬性。對zookeeper swarm也是如此。

測試方法

  1. 更新 -is-preserve-unlink-enabled true 至Kafka磁碟區、如下所示：

    aws-shantanclastrecall-aws::*> volume create -vserver kafka_svm -volume kafka_fg_vol01 -aggregate kafka_aggr -size 3500GB -state online -policy kafka_policy -security-style unix -unix-permissions 0777 -junction-path /kafka_fg_vol01 -type RW -is-preserve-unlink-enabled true
[Job 32] Job succeeded: Successful

  2. 建立了兩個類似的Kafka叢集、其差異如下：

    • *叢集1.*執行正式作業功能ONTAP 的後端NFS v4.1伺服器9.12.1版是由NetApp CVO執行個體代管。已在代理商上安裝RHEL 8.7/RHEL 9.1。

    • *叢集2.*後端NFS伺服器是手動建立的通用Linux NFSv3伺服器。

  3. 兩個Kafka叢集都建立了示範主題。

    叢集1：

    此螢幕快照顯示在叢集1上建立的示範主題。

    叢集2：

    此螢幕快照顯示在叢集2上建立的示範主題。

  4. 資料已載入這兩個叢集的新建立主題。這是使用預設Kafka套件隨附的生產商perf-test工具組來完成：

    ./kafka-producer-perf-test.sh --topic __a_demo_topic --throughput -1 --num-records 3000000 --record-size 1024 --producer-props acks=all bootstrap.servers=172.30.0.160:9092,172.30.0.172:9092,172.30.0.188:9092,172.30.0.123:9092

  5. 已使用Telnet:對每個叢集的Broker 1執行健全狀況檢查。

    • 遠端登入 172.30.0.160 9092

    • 遠端登入 172.30.0.198 9092

      下一個快照會顯示兩個叢集上的代理程式健全狀況檢查是否成功：

    此螢幕快照顯示兩家代理商成功進行健全狀況檢查的讀出結果。

  6. 為了觸發故障情況、導致使用NFSv3儲存磁碟區的Kafka叢集當機、我們在兩個叢集上都開始重新指派磁碟分割。磁碟分割重新指派是使用執行 kafka-reassign-partitions.sh。詳細程序如下：

    1. 若要重新指派Kafka叢集中某個主題的分割區、我們會產生建議的重新指派組態Json（這是針對兩個叢集執行）。

      kafka-reassign-partitions --bootstrap-server=172.30.0.160:9092,172.30.0.172:9092,172.30.0.188:9092,172.30.0.123:9092 --broker-list "1,2,3,4" --topics-to-move-json-file /tmp/topics.json --generate

    2. 然後儲存產生的重新指派Json /tmp/reassignment- file.json。

    3. 實際的分割區重新指派程序是由下列命令觸發：

      kafka-reassign-partitions --bootstrap-server=172.30.0.198:9092,172.30.0.163:9092,172.30.0.221:9092,172.30.0.204:9092 --reassignment-json-file /tmp/reassignment-file.json –execute

  7. 重新指派完成幾分鐘後、代理商的另一項健全狀況檢查顯示、使用NFSv3儲存磁碟區的叢集發生錯誤的重新命名問題、並已當機、而使用NetApp ONTAP NFSv4.1儲存磁碟區的叢集1則可在不中斷營運的情況下繼續進行修正作業。

    此螢幕擷取畫面顯示當機代理程式的輸出。

    • 叢集1-Broler-1處於作用中狀態。

    • Cluster2-Broker 1已死機。

  8. 查看Kafka記錄目錄後、很明顯、使用NetApp ONTAP 支援NFSv3的叢集1儲存磁碟區搭配修復程式時、會有乾淨的分割區指派、而使用一般NFSv3儲存設備的叢集2則不會因為錯誤的重新命名問題而導致當機。下圖顯示叢集2的分割區重新平衡、導致NFSv3儲存設備發生不實的重新命名問題。

    此快照顯示叢集2當機的記錄輸出。

    下圖顯示使用NetApp NFSv4.1儲存設備重新平衡叢集1的乾淨分割區。

    此螢幕快照顯示成功指派叢集1的乾淨分割區的記錄輸出、然而