

<HTML><BODY><div>А вот давайте попробуем пообсуждать здесь. Может такой формат больше народу подойдёт.</div><div> </div><div>В этом релизе у нас появляется автоматический фейловер «на борту» Тарантула — RAFT.</div><div> </div><div>Это прекрасное событие, однако у него есть некоторые недостатки:<br><br>- Беспроблемные гарантированные выборы возможны только если число участников выборов нечётное. Или число кворума больше половины числа участников на 1. Для 2 — это 2. Для 3 это 2. Для 4 это 3.</div><div> </div><div>Кроме того ещё несколько вводных в виде F.A.Q:</div><div> </div><div>Q: Для чего пользователи ставят репликасет в нескольких ДЦ?</div><div>A: Чтобы при недоступности одного (или нескольких) ДЦ сервис продолжал работу.</div><div> </div><div>Q: Если сервис располагается в X датацентрах, умерли все кроме одного последнего. Хочет ли пользователь чтоб его сервис был доступен клиентам?</div><div>A: Безусловно</div><div> </div><div>Q: Какая инсталляция по нескольким ДЦ самая популярная?</div><div>A: Инсталляция на 2 независимых ДЦ (минимальный случай резервирования, экономически самый дешёвый)</div><div> </div><div> </div><div>Если порефлексировать над этими вводными, то мы можем сформулировать требования к «идеальному» фейловеру:</div><div> </div><div>- Работоспособность сервиса должна сохраняться «до последнего ДЦ»</div><div>- Из предыдущего пункта следует необходимость поддержки «режима деградации» — по аналогии с режимом деградациии в RAID: отключили винчестер, избыточность исчезла, но RAID продолжает работу</div><div>- Работоспособность сервиса не должна «предпочитать» чётные/нечётные числа, а должна сохраняться при снижении числа работоспособных узлов от N до 1.</div><div> </div><div> </div><div>Исходя из перечисленного, я вижу RAFT — это только подузел такого механизма, а над ним действуют какие-то правила, которые плавно снижают кворум, выводя из игры недоступные узлы, вплоть до 1 (кворума нет, остался последний боец).</div><div> </div><div>Очевидно (мне очевидно, я могу ошибаться), что такой фейловер невозможен, если только сами узлы будут решать кто главный: рано или поздно ситуация что кластер разделился на две независимые половины, каждая со своим главным — произойдёт.</div><div> </div><div>Если взглянуть на многие пользовательские сервисы, то увидим, что пользователи заходят на них через одну точку входа: на mail.ru — через адрес mail.ru. На сервис банка — через адрес банка. И так далее. Возможно, если разместить stateful мониторы в этих точках, то подобный фейловер можно реализовать?</div><div> </div><div>Есть у кого-то мысли как построить подобный фейловер?</div><div> </div><div data-signature-widget="container"><div data-signature-widget="content"><div>--<br>Дмитрий Обухов</div></div></div></BODY></HTML>