ZooKeeper cluster: кто-нибудь?

[timeau]

Здорово, отцы!
Люблюсь некоторое время с сим "чюдом", и что-то в конец запутался. Если кто связывался, ткните носом.
Дано: амазоновское облако. Поднимаем стек из 5 машин (стек 1) для организации на них ZooKeeper'ного кластера. Все проходит нормально, кластер слепливается без проблем, солары и кафки используют его в хвост и гриву. Пока полное счастье.
Спустя какое-то время поднимаем второй стек из 5 машин. Скрипт на каждой из них "обнюхивает" активные ноды, лепит из них конфигурацию для стека номер 2, машины одна за одной сначала прилепляются в виде observer'ов, потом конвертятся в participant'ов. Кластер какое-то время работает на 10 машинах.
После первый стек уже нафиг не нужен, и он спиливается: его ноды переводятся сначала в observer'ов, а потом стек тупо удаляется. Последний шаг - вычищение старых IP из стека 1 из конфигурации кластера. Лепота. Все работает.
Через день-два-неделю (не столь важно) поднимаем кластер номер 3. Желание простое: присоседить новый стек к кластеру точно также, как присоединяли стек номер 2. Первая машина стека 3 успешно запускает сервис ZooKeeper'a, подсоединяется к кластеру в роли observer'а и... Не может стать participant'ом. Команда reconfig через "zkCli" возвращает код ошибки. В логах ZooKeeper'a наблюдаю обращение к машине из стека номер 1, который давно снесли нахрен и вычистили!
{code}
2019-04-02 17:37:27,960 [myid:2557] - WARN [QuorumPeer[myid=2557]
(plain=/0:0:0:0:0:0:0:0:2181)(secure=disabled):QuorumCnxManager@660] -
Cannot open channel to 2336 at election address /XX.XX.XX.11:3888
java.net.NoRouteToHostException: No route to host (Host unreachable)
{code}
Анекдот в том, что такое случается не каждый раз, а в среднем 2 раза из 3. Иногда все проходит пучком.
Традиционный русский вопрос: что делать? Откуда он берет "старые" IP-адреса, если из однозначно нет в конфигурации кластера? Ну даже если они где-то закешились, кластер-то должен знать, что эти адреса "мертвые"?
В общем, буду признателен за помощь.

[zVlad]

Пара народных мудростей:
- кошка скреб на свой хребет, и
- спасение утопающих дело самих.

Если на обидились объясните, пожалуйста, страсть к созданию и удалению стеков и кластеров вообще.

[Sergunka]

Здорово, отцы!
Люблюсь некоторое время с сим "чюдом", и что-то в конец запутался. Если кто связывался, ткните носом.
Дано: амазоновское облако. Поднимаем стек из 5 машин (стек 1) для организации на них ZooKeeper'ного кластера. Все проходит нормально, кластер слепливается без проблем, солары и кафки используют его в хвост и гриву. Пока полное счастье.
Спустя какое-то время поднимаем второй стек из 5 машин. Скрипт на каждой из них "обнюхивает" активные ноды, лепит из них конфигурацию для стека номер 2, машины одна за одной сначала прилепляются в виде observer'ов, потом конвертятся в participant'ов. Кластер какое-то время работает на 10 машинах.
После первый стек уже нафиг не нужен, и он спиливается: его ноды переводятся сначала в observer'ов, а потом стек тупо удаляется. Последний шаг - вычищение старых IP из стека 1 из конфигурации кластера. Лепота. Все работает.
Через день-два-неделю (не столь важно) поднимаем кластер номер 3. Желание простое: присоседить новый стек к кластеру точно также, как присоединяли стек номер 2. Первая машина стека 3 успешно запускает сервис ZooKeeper'a, подсоединяется к кластеру в роли observer'а и... Не может стать participant'ом. Команда reconfig через "zkCli" возвращает код ошибки. В логах ZooKeeper'a наблюдаю обращение к машине из стека номер 1, который давно снесли нахрен и вычистили!
{code}
2019-04-02 17:37:27,960 [myid:2557] - WARN [QuorumPeer[myid=2557]
(plain=/0:0:0:0:0:0:0:0:2181)(secure=disabled):QuorumCnxManager@660] -
Cannot open channel to 2336 at election address /XX.XX.XX.11:3888
java.net.NoRouteToHostException: No route to host (Host unreachable)
{code}
Анекдот в том, что такое случается не каждый раз, а в среднем 2 раза из 3. Иногда все проходит пучком.
Традиционный русский вопрос: что делать? Откуда он берет "старые" IP-адреса, если из однозначно нет в конфигурации кластера? Ну даже если они где-то закешились, кластер-то должен знать, что эти адреса "мертвые"?
В общем, буду признателен за помощь.

А что мешает запустить сразу кластер из 15 машин? А все остатки декомисовать...

[timeau]

Если на обидились объясните, пожалуйста, страсть к созданию и удалению стеков и кластеров вообще.

Я не уверен, что именно было написано выше, особенно про кошку, похоже на бред. Отквотированнное имеет смысл, потому отвечу.
Согласно policy, мы не имеем права хранить стек дольше 1 месяца. Это предел, вызванный установкой патчей и прочими атрибутами безопасности. Реально многое завязано на Team City, когда запуск нового стека обусловлен элементарной зависимостью одного от другого, и потому смена стеков происходит раз в 7-10 дней.
Мне просто надоело (да и начальство озаботилось, что есть гуд), что после смены стеков что-то надо подпиливать, подковыривать и т.д. Надо, чтобы все ротейтилось само, без нашего участия от слова "совсем". Вот и выяснили "слабое звено", с которым и боремся.
Могу добавить, что после удаления observer'а сразу начинаются выборы, а я лично этого вообще понять не могу, ибо observer'ы есть прибалтийские неграждане: работать должны, а голосовать - нет. Но с ними, с observer'ами, считаются, и я опечален.

А что мешает запустить сразу кластер из 15 машин? А все остатки декомисовать...

А нахрен он нужен, на 15 машин-то? В нормальной ситуации должно работать 5. И они должны сохранять все записанные в них данные, ежу понятно.

[Sergunka]

А что мешает запустить сразу кластер из 15 машин? А все остатки декомисовать...

А нахрен он нужен, на 15 машин-то? В нормальной ситуации должно работать 5. И они должны сохранять все записанные в них данные, ежу понятно.

Тогда к чему все эти эксперименты? Из моего опыта с Амазоном они там любят что-то из бекапа восстанавливать возможно какие-то таблицы Вы хоть и почиститли, но они восстановили походу.

[timeau]

Тогда к чему все эти эксперименты?

Не понял... Что значит "к чему?"? Я ж вроде объяснил.

Из моего опыта с Амазоном они там любят что-то из бекапа восстанавливать возможно какие-то таблицы Вы хоть и почиститли, но они восстановили походу.

Знаете, Сергунька, я бы все-таки предпочел более технически продвинутый разговор, чем "они какие-то таблицы почистили". Будьте добры, если не в курсе, не засоряйте тему.

[mavr]

Традиционный русский вопрос: что делать? Откуда он берет "старые" IP-адреса, если из однозначно нет в конфигурации кластера? Ну даже если они где-то закешились, кластер-то должен знать, что эти адреса "мертвые"?
В общем, буду признателен за помощь.

Ктож вам ответит?
У вас кластер похоже поднимается чем то своим а не AWS средствами.
Скрипты для конфигурирования всего этого огорода тоже свои.

[timeau]

У вас кластер похоже поднимается чем то своим а не AWS средствами.

А причем тут скрипты? Используется обычный salt. Какое это отношение к запоминанию ZooKeeper'ом старых адресов имеет?

[Sergunka]

У вас кластер похоже поднимается чем то своим а не AWS средствами.

А причем тут скрипты? Используется обычный salt. Какое это отношение к запоминанию ZooKeeper'ом старых адресов имеет?

Вам надо запостись терпением и логами какие ошибки выдает ваш кластер. После чего идти сдаваться в приличное место видимо https://stackoverflow.com/ с описанием всего процесса от и до включая логи. За одно проверьте у Вашего лигал департамента можете ли Вы публиковать логи?

[uncle_Pasha]

Могу добавить, что после удаления observer'а сразу начинаются выборы, а я лично этого вообще понять не могу, ибо observer'ы есть прибалтийские неграждане: работать должны, а голосовать - нет.

Вы уверены, что он читает тот конфиг который вы думаете он читает, и в том формате, что понимается той версией, что сейчас работает?

[timeau]

Вам надо запостись терпением и логами какие ошибки выдает ваш кластер.

Сергунька,
а Вы читали исходный пост? Фрагмент лога прямо там.

После чего идти сдаваться в приличное место видимо https://stackoverflow.com/ с описанием всего процесса от и до включая логи.

Очень хочется съязвить, но не буду: скажу лишь, что я в не настолько уж дальней деревне живу. Вот топик, запостил еще до этого.

За одно проверьте у Вашего лигал департамента можете ли Вы публиковать логи?

Спасибо, тоже давно сделано

Ну так по делу-то можете что-нибудь сказать? Или следующая рекомендация будет о соблюдении fat-free диеты?

Вы уверены, что он читает тот конфиг который вы думаете он читает, и в том формате, что понимается той версией, что сейчас работает?

100%. Гарантирую.

[Sergunka]

Хорошо, обычно всеж народ пишет, что нужно посмотреть конфиг фалы на каждом сервере

zoo.cfg under $ZOOKEEPER_HOME/conf

типо тут больше деталей

https://stackoverflow.com/questions/401 ... ter-on-aws

Просто тупо вручную установить сервера пробовали?

[mavr]

У вас кластер похоже поднимается чем то своим а не AWS средствами.

А причем тут скрипты? Используется обычный salt. Какое это отношение к запоминанию ZooKeeper'ом старых адресов имеет?

К непосредственно возникновению вашей проблемы скорее всего никакого.
К пониманию вашей проблемы сторонними людьми прямое.
Что такое "добавить новый стэк в Zookeeper" я например практически не понимаю.
Про скрипты вы начали сами.

А насчет адресов. Какие адреса имеют новые ноды когда возникает ошибка? Не пересекаются с теми адресами которые уже имели удаленные ноды?

[timeau]

Хорошо, обычно всеж народ пишет, что нужно посмотреть конфиг фалы на каждом сервере

Большое спасибо за ответы, Сергунька, но давайте на этом и закончим, если не возражаете.

Что такое "добавить новый стэк в Zookeeper" я например практически не понимаю.

Нда? Вот почему-то анекдот про Ржевского и кормление лошади с руки вспоминается... Ну ладно. Я попробую объяснить, а Вы попробуйте перефразировать, если сумеете.
Есть кластер, основанный на стеке 1, состоящем из трех машин 1-1, 1-2, 1-3. Запускается новый стек 2 с машинами 2-1, 2-2, 2-3. И эти машины 2-Х подсоединяются к кластеру, в котором становится 6 машин из 2 стеков. Вот только честно: неужто это дико сложно?

А насчет адресов. Какие адреса имеют новые ноды когда возникает ошибка? Не пересекаются с теми адресами которые уже имели удаленные ноды?

Это 100% по делу. Нет, не пересекаются, особенно в Амазоне. Он раздает адреса весьма щедро, в отличие от GCP (Google Cloud Platform). Но даже в случае пересечения самое плохое, что могло бы случиться, это обращение к вновь образованным нодам, на которых зверушка еще не запущена. Этого не наблюдал ни разу.

Наткнулся на непонятную (снова?) вещь: любое изменение структуры кластера приводит к перевыборам. Ну как на Украине, чесслово, сорри, не удержался. Хотя почему удаление неголосующего нода приводит к обсуждению "царя горы" - мне совершенно непонятно.
Завтра попробую перезапустить сервисы ZooKeeper'а на всех нодах существующего кластера по очереди. Интересно, это выбьет из них дурь, т.е. знания об ушедшем кластере?

[mavr]

Что такое "добавить новый стэк в Zookeeper" я например практически не понимаю.

Нда? Вот почему-то анекдот про Ржевского и кормление лошади с руки вспоминается... Ну ладно. Я попробую объяснить, а Вы попробуйте перефразировать, если сумеете.
Есть кластер, основанный на стеке 1, состоящем из трех машин 1-1, 1-2, 1-3. Запускается новый стек 2 с машинами 2-1, 2-2, 2-3. И эти машины 2-Х подсоединяются к кластеру, в котором становится 6 машин из 2 стеков. Вот только честно: неужто это дико сложно?

Это не сложно, это ... странно.
Этот "стэк" существует только в вашем представлении и к делу совершенно не относится.
Ни zookeeper про эти стэки понятия не имеет ни AWS ни мы.
Было три ноды. Добавили еще три. Три старых хотите удалить. Кластер один. Никаких новых и/или множественных кластеров нет.

А насчет адресов. Какие адреса имеют новые ноды когда возникает ошибка? Не пересекаются с теми адресами которые уже имели удаленные ноды?

Это 100% по делу. Нет, не пересекаются, особенно в Амазоне. Он раздает адреса весьма щедро.

Еслив чего, то AWS их раздает ровно с той щедростью с которой вы (или кто то у вас) ему выделили в соответствующей VPC подсетке.

Наткнулся на непонятную (снова?) вещь: любое изменение структуры кластера приводит к перевыборам. Ну как на Украине, чесслово, сорри, не удержался. Хотя почему удаление неголосующего нода приводит к обсуждению "царя горы" - мне совершенно непонятно.

Ну наверное потому что так написана логика кластера

[timeau]

Этот "стэк" существует только в вашем представлении и к делу совершенно не относится.
Ни zookeeper про эти стэки понятия не имеет ни AWS ни мы.

Вы либо не понимаете, о чем идет речь, либо закусили удила. Потому будьте добры, покиньте этот топик. Спасибо за Ваши ответы.

[kostik78]

Конфигурацию кластера как меняете - через Dynamic reconfiguration или по старинке: изменение файлов и рестар one-by-one ?

[timeau]

Конфигурацию кластера как меняете - через Dynamic reconfiguration или по старинке: изменение файлов и рестар one-by-one ?

Динамически: либо через zkCli, либо вообще через "kazoo".
Нынче впервые нашли workaround: если перед присоединением нового стека к кластеру активные ноды (к которым будем прицепляться) рестартануть по одному через используемый supervisor, то проблема уходит. Пока, я думаю, поживем так, а там или ишак подохнет, или падишах умрет. То есть кластер реально "помнит" всех своих бывших членов (и пиписек в виде observer'ов), независимо от того, живы ли они. И ведь в логах видно, как с этими "уходящими" нодами кластер прощается: "GOODBYE XX.XX.XX.11!" А все оказывается по фигу: все равно коннектится к ним. Очень похоже на багу в "r3.5.4-beta"
Да, рестарт одного только лидера кластера нифига не дает.

[Sergunka]

Нынче впервые нашли workaround: если перед присоединением нового стека к кластеру активные ноды (к которым будем прицепляться) рестартануть по одному через используемый supervisor, то проблема уходит.

Ну и чем это оличается

Просто тупо вручную установить сервера пробовали?

P.S. Честно говоря я давно такого хамского атитьюда в разделе не видел

[timeau]

P.S. Честно говоря я давно такого хамского атитьюда в разделе не видел

А я столь безграмотного...
Всего хорошего, Сергунька!

[Sergunka]

К слову сказать подобный баг зафайлин аж пять лет назад

The problem we are facing is that one zookeeper server in the quorum falls apart, and never becomes part of the cluster until we restart zookeeper server on that node.

https://issues.apache.org/jira/browse/Z ... %20host%22

Все никак не пофиксят.

[timeau]

К слову сказать подобный баг зафайлин аж пять лет назад

The problem we are facing is that one zookeeper server in the quorum falls apart, and never becomes part of the cluster until we restart zookeeper server on that node.

https://issues.apache.org/jira/browse/Z ... %20host%22

Все никак не пофиксят.

Это не то, что у нас. Я могу несколько раз подключить любое кол-во уже работавших в кластере серверов back and forth в пределах кворума, никаких проблем. Проблема в том, что впервые подключаемые members пытаются присоединиться к уже отключенным nodes, которых уже нет в кластере.

[kostik78]

К слову сказать подобный баг зафайлин аж пять лет назад

The problem we are facing is that one zookeeper server in the quorum falls apart, and never becomes part of the cluster until we restart zookeeper server on that node.

https://issues.apache.org/jira/browse/Z ... %20host%22

Все никак не пофиксят.

Это не то, что у нас. Я могу несколько раз подключить любое кол-во уже работавших в кластере серверов back and forth в пределах кворума, никаких проблем. Проблема в том, что впервые подключаемые members пытаются присоединиться к уже отключенным nodes, которых уже нет в кластере.

Честно говоря не видел этого никогда Но я так активно ноды не дергал у ZK туда и обратно. Он слишком фраджайл к изменениям и нетворку и как правило на него завязан лидер елекшен других сервисов. Так что как говорится, работает - не хай трогать

[timeau]

Так что как говорится, работает - не хай трогать

У нас без вариантов