Tarantool discussions archive
 help / color / mirror / Atom feed
* [Tarantool-discussions] Мозгоштурм: Фейловер с режимом деградации
@ 2021-08-14 16:13 Дмитрий Обухов via Tarantool-discussions
  2021-08-15  7:56 ` Konstantin Osipov via Tarantool-discussions
  0 siblings, 1 reply; 4+ messages in thread
From: Дмитрий Обухов via Tarantool-discussions @ 2021-08-14 16:13 UTC (permalink / raw)
  To: tarantool-discussions

[-- Attachment #1: Type: text/plain, Size: 4142 bytes --]


А вот давайте попробуем пообсуждать здесь. Может такой формат больше народу подойдёт.
 
В этом релизе у нас появляется автоматический фейловер «на борту» Тарантула — RAFT.
 
Это прекрасное событие, однако у него есть некоторые недостатки:

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

[-- Attachment #2: Type: text/html, Size: 4667 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Tarantool-discussions]  Мозгоштурм: Фейловер с режимом деградации
  2021-08-14 16:13 [Tarantool-discussions] Мозгоштурм: Фейловер с режимом деградации Дмитрий Обухов via Tarantool-discussions
@ 2021-08-15  7:56 ` Konstantin Osipov via Tarantool-discussions
  0 siblings, 0 replies; 4+ messages in thread
From: Konstantin Osipov via Tarantool-discussions @ 2021-08-15  7:56 UTC (permalink / raw)
  To: Дмитрий
	Обухов
  Cc: tarantool-discussions

* Дмитрий Обухов via Tarantool-discussions <tarantool-discussions@dev.tarantool.org> [21/08/15 03:02]:

Сначала надо реализовать изменение конфигурации как часть
протокола Рафт, и реализовать raft learner расширение протокола,
описанное в PhD.

Проблему чётного числа узлов нужно решать именно с помощью raft
learners (non-voting nodes).

Режим автоматического уменьшения размера кворума описан в PhD и
был реализован, по сути это автоматическая инициация configuration
change после длительной недоступности одного узла. 

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

-- 
Konstantin Osipov, Moscow, Russia

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Tarantool-discussions] Говорят у нас проблемы с почтой
  2020-11-26 16:39 [Tarantool-discussions] Говорят у нас проблемы с почтой Timur Safin
@ 2020-11-26 16:40 ` Тимур Сафин
  0 siblings, 0 replies; 4+ messages in thread
From: Тимур Сафин @ 2020-11-26 16:40 UTC (permalink / raw)
  To: tarantool-discussions

[-- Attachment #1: Type: text/plain, Size: 439 bytes --]

C и на @tarantool.org доходит. Давайте проверим посылку от @corp.mail.ru?
 
From: Tarantool-discussions <tarantool-discussions-bounces@dev.tarantool.org> On Behalf Of Timur Safin
Sent: Thursday, November 26, 2020 7:39 PM
To: tarantool-discussions@dev.tarantool.org
Subject: [Tarantool-discussions] Говорят у нас проблемы с почтой
 
Давайте проверим!
 
 

[-- Attachment #2: Type: text/html, Size: 41402 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Tarantool-discussions] Говорят у нас проблемы с почтой
@ 2020-11-26 16:39 Timur Safin
  2020-11-26 16:40 ` Тимур Сафин
  0 siblings, 1 reply; 4+ messages in thread
From: Timur Safin @ 2020-11-26 16:39 UTC (permalink / raw)
  To: tarantool-discussions

[-- Attachment #1: Type: text/plain, Size: 40 bytes --]

Давайте проверим!
 
 

[-- Attachment #2: Type: text/html, Size: 36940 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-08-15  7:56 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-14 16:13 [Tarantool-discussions] Мозгоштурм: Фейловер с режимом деградации Дмитрий Обухов via Tarantool-discussions
2021-08-15  7:56 ` Konstantin Osipov via Tarantool-discussions
  -- strict thread matches above, loose matches on Subject: below --
2020-11-26 16:39 [Tarantool-discussions] Говорят у нас проблемы с почтой Timur Safin
2020-11-26 16:40 ` Тимур Сафин

Tarantool discussions archive

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://lists.tarantool.org/tarantool-discussions/0 tarantool-discussions/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 tarantool-discussions tarantool-discussions/ https://lists.tarantool.org/tarantool-discussions \
		tarantool-discussions@dev.tarantool.org.
	public-inbox-index tarantool-discussions

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git