Comments 22
Какое будет поведение в случае split brain? два лидера? или есть какие-то механизмы для обработки такой ситтуации?
Split brain ситуации тут не может быть, т.к. Все операции выполняется только при наличии кворума — минимум половина машин плюс одна должны согласовать решение. Таким образом два мастера существовать не смогут, у одного будет недостаточно последователей для формирования кворума и выполнения операций.
я просто пытаюсь разобраться. То есть при четном количестве машин network split ровно пополам — приведет к отказу всего зоопарка?
Кворум будет повышен до ближайшего нечетного вверх (N/2 + 1, например для 4 будет 4/2 + 1 = 3, т.е. столько же сколько и для 5, 5/2 + 1 = 3 )
это понятно, я о другом спрашивал, например 10 машин, network split на дву сети в каждой из которых по 5 машин. Ни в одной половине не будет N/2+1 то есть кворума (который как я понял — 6). вопросы --1) что будет с существующим лидером? 2) Возможна ли будет вообще запись в zookeeper? 3) чтение тоже требует кворума? если да — означает ли это что и чтение будет недоступно? 4) как это будет выглядеть с клиентской стороны — ошибки? разрыв соединений?
Да, будет потеря кворума:
1. ничего, он превратиться в кандидата и начнутся выборы
2. нет, запись будет невозможна
3. чтение никогда не требует кворума и чтение всегда с той машины, куда ты прицепился. для работы с таким развлившимся кворумом можно подключаться в readonly режиме.
4. ошибки да (на память не помню что именно прилетит). Разрыв соединения zk не страшен, при подключении создается сессия, которая реплицирутся на все сервера кворума, по этому при переподключении клиент указывает свою сессию и с точки зрения клиентского кода происходит просто небольшая задержка.
1. ничего, он превратиться в кандидата и начнутся выборы
2. нет, запись будет невозможна
3. чтение никогда не требует кворума и чтение всегда с той машины, куда ты прицепился. для работы с таким развлившимся кворумом можно подключаться в readonly режиме.
4. ошибки да (на память не помню что именно прилетит). Разрыв соединения zk не страшен, при подключении создается сессия, которая реплицирутся на все сервера кворума, по этому при переподключении клиент указывает свою сессию и с точки зрения клиентского кода происходит просто небольшая задержка.
Кипарис из YT не так пригоден для внедрения внутри Яндекса, как Zookeeper?
Кипарис — отличная технология для хранения метаданных. И она тоже используется. Хотя и имела существенные отличия.
Не будет ли сильным нарушением NDA рассказать ключевые отличия Кипариса от Zookeeper'а и Etcd? Или лучше надеяться, что на YaC'е в этом году расскажут немного больше?
упс, промазал habrahabr.ru/company/yandex/blog/234335/#comment_7898419
Ну etcd мало что могу сказать, я его ни у кого в проде не видел. а по возможностям и по свойствам raft-а должно быть очень похоже на zk.
Про YT думаю расскажут разработчики, правда я не знаю когда они это собираются делать.
Про YT думаю расскажут разработчики, правда я не знаю когда они это собираются делать.
Да, похоже ровной в той же мере, как яблоко похоже на яблоню :)
RAFT имеет ряд преимуществ:
1) Академически доказан и реализован по теоретическим выкладкам (можно ли реализовать PAXOS прочтя алгоритм? Конечно же нет)
2) Решительно проще, чем PAXOS и не требует костылей, чтобы он вел себя адекватно во всех случаях
3) Etcd не содержит богоморезкой явы (зачем она в таком сугубо системном инструменте?)
Иными словами, как раз в случае RAFT не нужно быть семь пядей во лбу, чтобы сказать, что произойдет с кластером в той или иной ситуации, а достаточно изучить и понять короткую пдфку.
RAFT имеет ряд преимуществ:
1) Академически доказан и реализован по теоретическим выкладкам (можно ли реализовать PAXOS прочтя алгоритм? Конечно же нет)
2) Решительно проще, чем PAXOS и не требует костылей, чтобы он вел себя адекватно во всех случаях
3) Etcd не содержит богоморезкой явы (зачем она в таком сугубо системном инструменте?)
Иными словами, как раз в случае RAFT не нужно быть семь пядей во лбу, чтобы сказать, что произойдет с кластером в той или иной ситуации, а достаточно изучить и понять короткую пдфку.
У raft изменения размеров кластера предусмотрено протоколом, у zk, кажется, такого не было.
Также радует, что за счёт простоты raft'а есть воз и маленькая тележка его имплементаций и систем поверх него (всякие etcd, consul, hydrabase, influxdb).
Те же etcd и consul довольно просты с т. з. клиента http (etcd и consul), dns и rpc (consul) против написание zk-enabled оберток для сервисов (особенно, когда они не на яве), хотя там тоже есть strong ordering, cas операции, сессии (для leader election), watch'и (через http long-polling).
Правда, пока сложно сказать насколько оно production ready, всё молодые проекты.
Также радует, что за счёт простоты raft'а есть воз и маленькая тележка его имплементаций и систем поверх него (всякие etcd, consul, hydrabase, influxdb).
Те же etcd и consul довольно просты с т. з. клиента http (etcd и consul), dns и rpc (consul) против написание zk-enabled оберток для сервисов (особенно, когда они не на яве), хотя там тоже есть strong ordering, cas операции, сессии (для leader election), watch'и (через http long-polling).
Правда, пока сложно сказать насколько оно production ready, всё молодые проекты.
Да, а еще референсная реализация на няшном Go вообще возносит raft на олимп :)
Я искреннее уверен, что в скором будущем многие сервисы (тот же http, dns) станут намного более распределенными, но при этом очень управляемыми.
DNS хоть и распределенный сервис by design, но, например, такая задача как замена мастера, когдау тебя сотни тысяч доменных зон — становится адом и кошмаром. Ну, конечно, есть те, кто используют SQL движки под DNS и думают, что решили проблему даже не достойны упоминания — это треш =)
Я искреннее уверен, что в скором будущем многие сервисы (тот же http, dns) станут намного более распределенными, но при этом очень управляемыми.
DNS хоть и распределенный сервис by design, но, например, такая задача как замена мастера, когдау тебя сотни тысяч доменных зон — становится адом и кошмаром. Ну, конечно, есть те, кто используют SQL движки под DNS и думают, что решили проблему даже не достойны упоминания — это треш =)
А при чем тут paxos? Zab не есть paxos и точно так же довольно прост. Есть даже pdf, предлагаю сначала изучить предмет разговора поподробнее.
В проде ZK используется достаточно давно.
Другая большая лекция по ЗуКиперу от сотрудников Яндекса: www.lektorium.tv/lecture/14880
Насколько я помню, там поподробнее, для первого знакомства самое то!
Насколько я помню, там поподробнее, для первого знакомства самое то!
Видно, что человек знает свою тему, но доклады ему вести не стоит. Посмотрел видео, советую лучше читать статью.
Я правильно понимаю, что Zookeeper решает примерно такие же задачи, как и микросовтовский Active Directory?
Sign up to leave a comment.
В чем польза ZooKeeper для админов и разработчиков. Семинар в Яндексе