アップデート `-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 クラスターが作成されました。

両方の Kafka クラスターにデモ トピックが作成されました。

両方のクラスターの新しく作成されたトピックにデータがロードされました。これは、デフォルトの Kafka パッケージに付属する produced-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

Telnet を使用して、各クラスターのブローカー 1 のヘルス チェックが実行されました。

NFSv3 ストレージ ボリュームを使用する Kafka クラスターがクラッシュする障害状態をトリガーするために、両方のクラスターでパーティションの再割り当てプロセスを開始しました。パーティションの再割り当ては、 kafka-reassign-partitions.sh 。詳細なプロセスは次のとおりです。

再割り当てが完了してから数分後、ブローカーの別のヘルス チェックで、NFSv3 ストレージ ボリュームを使用しているクラスターが不合理な名前変更の問題に遭遇してクラッシュした一方で、修正が適用されNetApp ONTAP NFSv4.1 ストレージ ボリュームを使用しているクラスター 1 は中断することなく操作を継続していることが示されました。

Kafka のログ ディレクトリを確認すると、修正が適用されたNetApp ONTAP NFSv4.1 ストレージ ボリュームを使用する Cluster 1 ではパーティション割り当てが適切に行われていたのに対し、汎用 NFSv3 ストレージを使用する Cluster 2 では、名前変更の問題によってパーティション割り当てが適切に行われず、クラッシュが発生していたことが明らかになりました。次の図は、クラスター 2 のパーティションの再バランスを示しています。これにより、NFSv3 ストレージで名前変更の問題が発生しました。