Кластер Akka с одним главным узлом, рабочими узлами и некластерными клиентскими узлами - PullRequest
Новая
       64

Кластер Akka с одним главным узлом, рабочими узлами и некластерными клиентскими узлами

1 голос
/ 19 июня 2020

Итак, я создаю кластер akka с 2.6.6, и я настраиваю главный узел, который будет начальным узлом и рабочими узлами, которые могут динамически выходить или входить в кластер. У меня также есть "клиентские" узлы, которые должны общаться с главным узлом, возможно, с маршрутизатором, но не с рабочими напрямую.

Проблема в том, что иногда, если слишком много рабочих уходит из-за выключения, не покидая должным образом кластер провайдер отключения разделенного мозга не выбирает главный узел в качестве лидера и, следовательно, отключает его, а также прямо сейчас "клиентские" узлы также являются частью кластера и также будут отключены в том случае, что не должно происходить.

Есть ли способ привязать лидера к главному узлу, но все еще иметь автоматическое отключение для рабочих, но не отключать клиентские узлы?

РЕДАКТИРОВАТЬ:

Может быть, немного больше структурированный, это то, что мне нравится делать sh:

  • Главный узел никогда не выключается автоматически, в случае сбоя он будет перезапущен вручную доступно
  • Нерабочие клиентские узлы никогда не выключаются, но попробуйте повторно подключиться к главному узлу на неопределенное время, если мастер кивает е нет в наличии

1 Ответ

2 голосов
/ 19 июня 2020

Предполагая, что вы используете преобразователь с разделенным мозгом с открытым исходным кодом (бывший коммерческий Lightbend), стратегия static-quorum кажется подходящей.

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

Есть еще одно использование этой роли. Определив роль для нескольких (например, 7) стабильных узлов в кластере и используя ее в конфигурации stati c -quorum, вы сможете динамически добавлять и удалять другие узлы без этой роли и по-прежнему принимать правильные решения о том, что узлы, которые нужно продолжать работать, и какие узлы отключать в случае сетевых разделов. Преимущество этого подхода по сравнению с контрольным большинством (описанным ниже) заключается в том, что вы не рискуете разделить кластер на два отдельных кластера, т. Е. Разделенный мозг *. Вы по-прежнему должны соблюдать правило не запускать слишком много узлов с этой ролью, как описано выше. Кроме того, существует риск отключения всех узлов в случае сбоя, когда в кластере недостаточно узлов с этой ролью, как описано выше.

Это может быть выполнено следующим образом в application.conf: 

akka.cluster.split-brain-resolver.active-strategy=static-quorum

akka.cluster.split-brain-resolver.static-quorum {
  # one leader node at a time
  quorum-size = 1
  role = "leader"
}

akka.cluster.roles = [ ${AKKA_CLUSTER_ROLE} ]

Затем вы должны указать роль кластера для каждого экземпляра через переменную среды AKKA_CLUSTER_ROLE (установив ее на leader на вашем ведущем узле и worker или client в зависимости от ситуации) .

Поскольку узлы должны согласовывать стратегию SBR, лучшее, что вы можете сделать, - это иметь клиентские узлы d ie, если лидер уйдет.

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

...