Ну etcd мало что могу сказать, я его ни у кого в проде не видел. а по возможностям и по свойствам raft-а должно быть очень похоже на zk.
Про YT думаю расскажут разработчики, правда я не знаю когда они это собираются делать.
Да, будет потеря кворума:
1. ничего, он превратиться в кандидата и начнутся выборы
2. нет, запись будет невозможна
3. чтение никогда не требует кворума и чтение всегда с той машины, куда ты прицепился. для работы с таким развлившимся кворумом можно подключаться в readonly режиме.
4. ошибки да (на память не помню что именно прилетит). Разрыв соединения zk не страшен, при подключении создается сессия, которая реплицирутся на все сервера кворума, по этому при переподключении клиент указывает свою сессию и с точки зрения клиентского кода происходит просто небольшая задержка.
Split brain ситуации тут не может быть, т.к. Все операции выполняется только при наличии кворума — минимум половина машин плюс одна должны согласовать решение. Таким образом два мастера существовать не смогут, у одного будет недостаточно последователей для формирования кворума и выполнения операций.
master-master/cyclic есть в hbase, но это асинхронный процесс. идея в целом проста: все операции попдают в лог операций (HLog), по мере достижения определенных условий (время, размер) он ротируется и становится доступным для процесса репликации. это HLog передается в кластера-подписчики, которые применяют последовательно операции, сохраненные в этом HLog. Конфликты обновлений разрешаются просто по времени, т.к. это eventual система. Конечно, атомарные изменения будут работать только в пределах одного кластера, и при репликации превратяться в просто Put. blog.cloudera.com/blog/2012/07/hbase-replication-overview-2/
HA Namenode сделана почти так-же, только nfs хранилище заменили системой из 3+ процессов JournalNode, которые обеспечивают две вещи:
1. Только один писатель в хранилище
2. Запись должна состояться на большинстве нод (quorum > N/2+1)
Остальное осталось без изменений, все так же NameNode две штуки, одна — active, другая — standby
Теоретически, можно попробовать поднять федерацию с 2-3 парами NN, где в каждом ДЦ приложения будут работать только со своей парой NN, а DN будут у них общие, но такое решение прозрачным не назовешь.
Ну и MapReduce в таком режиме работать без правок планировщика не будет, т.к. в ванильном MR нет прямой возможности запустить задачи только в текущем DC, задачи запустяться там, где есть данные. В итоге reduce фаза может начать обмениваться данными через медленный канал.
В MapR есть какая-то поддержка нескольких датацентров, но я не гуру в этом дистрибутиве.
PS: кстати, название протокола в статье есть.
Про YT думаю расскажут разработчики, правда я не знаю когда они это собираются делать.
1. ничего, он превратиться в кандидата и начнутся выборы
2. нет, запись будет невозможна
3. чтение никогда не требует кворума и чтение всегда с той машины, куда ты прицепился. для работы с таким развлившимся кворумом можно подключаться в readonly режиме.
4. ошибки да (на память не помню что именно прилетит). Разрыв соединения zk не страшен, при подключении создается сессия, которая реплицирутся на все сервера кворума, по этому при переподключении клиент указывает свою сессию и с точки зрения клиентского кода происходит просто небольшая задержка.
после нг дойду, щас в отпуске :)
это развитие hive, существенно быстрее работает.
(хотя еще сильно альфа)
blog.cloudera.com/blog/2012/07/hbase-replication-overview-2/
HA Namenode сделана почти так-же, только nfs хранилище заменили системой из 3+ процессов JournalNode, которые обеспечивают две вещи:
1. Только один писатель в хранилище
2. Запись должна состояться на большинстве нод (quorum > N/2+1)
Остальное осталось без изменений, все так же NameNode две штуки, одна — active, другая — standby
Теоретически, можно попробовать поднять федерацию с 2-3 парами NN, где в каждом ДЦ приложения будут работать только со своей парой NN, а DN будут у них общие, но такое решение прозрачным не назовешь.
Ну и MapReduce в таком режиме работать без правок планировщика не будет, т.к. в ванильном MR нет прямой возможности запустить задачи только в текущем DC, задачи запустяться там, где есть данные. В итоге reduce фаза может начать обмениваться данными через медленный канал.
В MapR есть какая-то поддержка нескольких датацентров, но я не гуру в этом дистрибутиве.