Комментарии 10
Вроде нет жёсткого требования разделять мастер и воркер ноды. Так, общая рекомендация, чтобы кластер не тупил, вплоть до oom kill процессов мастера, если рабочий контейнер заберёт все ресурсы. А если несколько мастеров делать, то нечётное число, чтоб не получилось два рабочих кластера из-за потери связи между мастерами, чтоб оставшиеся в меньшинстве поняли, что это они отвалились, а не другие
. А если несколько мастеров делать, то нечётное число, чтоб не получилось два рабочих кластера из-за потери связи между мастерами, чтоб оставшиеся в меньшинстве поняли, что это они отвалились, а не други
Если там рафт внутри, то требование иметь n/2+1 узел в рабочей половинке, разве нет ?
Будет три: два решат, что они рабочая, а один, что он нерабочий. Будет два или четыре: оба решат, что они нерабочая.
Ну, да, но Вы сами говорите, что четное количество
А) не приводит к сплит Брейн
Б) вполне допустимо (просто у нас толерантность к отказу одного узла в случае четырех).
Если верить вики в части рафт, то лидер выбирается большинством. Если чётная сеть разобётся, то большинства ни в одной не будет.
Если чётная сеть разобётся, то большинства ни в одной не будет.
все так, если ровно пополам — конечно, ничего работать не будет. Но, во-первых, какова вероятность такого раздела — раз (а не раздела 3+1), два — повторюсь, у нас толерантность к отказу N/2-1 ноды. Т.е. при прочих равных всегда выгоднее докинуть еще одну ноду до нечетного количества, но, повторюсь, это совершенно не означает, что конфигурации с четным количеством неработоспособны.
Ну кластер из 4 нод, 2 ноды в каждом ДЦ или шкафу, или физхосте. Эмпирически либо отдельные ноды будут отказывать, что к сплиту отношения особо не имеет, либо весь ДЦ, либо связь между ДЦ. Вот в последнем случае у нас оба "подкластера" должны стопнуться, потому что большинства (3 нод) ни в одном не будет. Если же нечетное количество и распределены почти пополам (1+2, 2+3 и т. п.), то в случае пропажи связи между ДЦ выберется мастером нода из того ДЦ, где реально большинство нод
2 ДЦ — это вообще боль, зачем так делать? Если уж делать по уму — уже тащить минимум 3 ДЦ (или 3AZ)? Либо брать риски отказа и в каждом ДЦ делать по отдельному кластеру, а на уровне логики приложения — раскидывание данных и синхронизацию.
Пускай не ДЦ, а физхосты с виртуалкми. Не суть. Суть в том, что чётное число мастеров парализует выборы, если сеть разобьётся ровно попалам.
суть в том, что "делай хорошо — хорошо будет". Вы сами очень верно указали, что отказ половины узлов — это плохо. А как эти узлы распределить по ДЦ/AZ или чему там еще — это задача инженера (архитектора). Например, 6 узлов, распределенных по 3 ДЦ — прекрасное решение, практически никогда не будет ситуации отказа 3 одновременно (а отказ 2 мы как-нибудь переживем, если отвалит один из ДЦ).
Просто разговор становится похож на "а давайте поднимем кластерную систему в сколько угодно узлов (ВМ) на одном единственном гипере" (или на одном физическом узле, или в одной стойке, или в одном ДЦ), а потом будем удивляться, что у нас единая точка отказа )
Конференция DEVOXX UK. Выбираем фреймворк: Docker Swarm, Kubernetes или Mesos. Часть 1