Инкрементная совместная ребалансировка приводит к неравномерно сбалансированным разъемам - PullRequest
0 голосов
/ 31 октября 2019

Мы сталкиваемся с множеством неравномерно сбалансированных разъемов на нашей установке, начиная с обновления до Kafka 2.3 (также с Kafka connect 2.3), которое должно включать в себя новую Инкрементную совместную ребалансировку в Kafka connect, объясненную здесь: https://cwiki.apache.org/confluence/display/KAFKA/KIP-415%3A+Incremental+Cooperative+Rebalancing+in+Kafka+Connect

ПустьЯ немного объясню нашу настройку, мы развертываем несколько кластеров Kafka Connect, чтобы вывести тему Kafka на HDFS. Для каждого hdfs-коннектора создается один кластер соединений, что означает, что в любой момент в кластере соединений работает только один соединитель. Эти кластеры развернуты поверх Kubernetes со случайно выбранными ips в частном опросе.

Давайте рассмотрим пример. Для этого hdfs-коннектора мы создали кластер соединений с 20 рабочими. В этом кластере должно быть запущено 40 задач, поэтому мы можем рассчитывать на 2 задачи на одного работника. Но, как показано в приведенной ниже команде, при запросе API подключения через некоторое время коннектор выглядит действительно неуравновешенным, некоторые рабочие даже не работают вообще, хотя одна из них взяла на себя ответственность за 28 задач.

bash-4.2$ curl localhost:8083/connectors/connector-name/status|jq '.tasks[] | .worker_id' | sort |uniq -c
  ...
      1 "192.168.32.53:8083"
      1 "192.168.33.209:8083"
      1 "192.168.34.228:8083"
      1 "192.168.34.46:8083"
      1 "192.168.36.118:8083"
      1 "192.168.42.89:8083"
      1 "192.168.44.190:8083"
     28 "192.168.44.223:8083"
      1 "192.168.51.19:8083"
      1 "192.168.57.151:8083"
      1 "192.168.58.29:8083"
      1 "192.168.58.74:8083"
      1 "192.168.63.102:8083"

Здесь мы ожидаем, что используется весь опрос рабочих, а через некоторое время разъем равномерно сбалансирован. Мы ожидаем, что у нас будет что-то вроде:

bash-4.2$ curl localhost:8083/connectors/connector-name/status|jq '.tasks[] | .worker_id' | sort |uniq -c
  ...
      2 "192.168.32.185:8083"
      2 "192.168.32.53:8083"
      2 "192.168.32.83:8083"
      2 "192.168.33.209:8083"
      2 "192.168.34.228:8083"
      2 "192.168.34.46:8083"
      2 "192.168.36.118:8083"
      2 "192.168.38.0:8083"
      2 "192.168.42.252:8083"
      2 "192.168.42.89:8083"
      2 "192.168.43.23:8083"
      2 "192.168.44.190:8083"
      2 "192.168.49.219:8083"
      2 "192.168.51.19:8083"
      2 "192.168.55.15:8083"
      2 "192.168.57.151:8083"
      2 "192.168.58.29:8083"
      2 "192.168.58.74:8083"
      2 "192.168.59.249:8083"
      2 "192.168.63.102:8083"

Второй результат был фактически достигнут путем ручного убийства некоторых работников, и немного удачи (мы не нашли надлежащего способа навязать равномерный баланс по всемуподключите кластер на данный момент, это больше процесс попытки и неудачи, пока соединитель не будет равномерно сбалансирован.

Кто-нибудь уже сталкивался с этой проблемой и удалось решить ее должным образом?

...