Distributed Commit
Курс «Базы данных»
Цесько Вадим Александрович
http://incubos.org
@incubos
Computer Science Center
23 се...
Содержание
1 Distributed Commit
2 Happens-before
3 Raft
4 Заключение
Цесько В. А. (CompSciCenter) Distributed Commit 23 се...
Distributed Commit Two-Phase Commit Protocol
Two-Phase Commit Protocol
Distributed atomic commitment protocol
commit или a...
Distributed Commit Two-Phase Commit Protocol
Фазы
Commit-request (voting)
Координатор пытается подготовить участников
тран...
Distributed Commit Two-Phase Commit Protocol
Предположения
Выделенный координатор
Stable storage1
+ write-ahead log (WAL)
...
Distributed Commit Two-Phase Commit Protocol
Диаграмма
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г....
Distributed Commit Two-Phase Commit Protocol
Оптимизации
Presumed abort/commit: работает при
восстановлении, экономим на л...
Distributed Commit Two-Phase Commit Protocol
Ограничения
Блокирующийся протокол
Если координатор исчезнет, то некоторые уч...
Distributed Commit Two-Phase Commit Protocol
Поведение при сбоях
Пример ситуации:
Реплика выполнила commit и упала вместе ...
Distributed Commit Three-Phase Commit Protocol
Three-Phase Commit Protocol
Назначение как у 2PC
Неблокирующийся — ограниче...
Distributed Commit Three-Phase Commit Protocol
Диаграмма
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 ...
Distributed Commit Three-Phase Commit Protocol
Анализ
Вторая фаза доносит решение до всех участников
⇒ состояние можно вос...
Happens-before Lamport timestamps
Lamport timestamps
Цель
Определить порядок событий в распределённой
системеa
a
Lamport, ...
Happens-before Lamport timestamps
Формализация
C(x) — время события x
∀a∀b(a = b ⇒ C(a) = C(b))
Для различия событий в раз...
Happens-before Lamport timestamps
Анализ
Невозможно точно синхронизировать время3
Если процессы не общаются, то между их
с...
Happens-before Vector clocks
Vector clocks
Цель
Ввести частичный порядок событий в
распределённой системе
Обнаружить наруш...
Happens-before Vector clocks
Правила обновления массива часов
Изначально все часы выставлены в 0
При каждом событии процес...
Happens-before Vector clocks
Пример
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 18 / 65
Happens-before Vector clocks
Формализация
VC(x) — векторные часы события x
VC(x)z — компонента векторных часов процесса z
...
Raft Введение
Мотивация
There are significant gaps between the description of the
Paxos algorithm and the needs of a real-w...
Raft Введение
Ссылки
Replicated State Machines5
Ongaro D., Ousterhout J. In Search of an
Understandable Consensus Algorith...
Raft Введение
Replicated State Machines
Работают на множестве узлов
Вычисляют идентичные копии одного и того же
состояния
...
Raft Введение
Особенности Raft
Strong Leader
Клиенты общаются только с лидером
Данные только от лидера к репликам
Leader E...
Raft Введение
Алгоритм работы лидера
1 Получить команду от клиента
2 Добавить в локальный лог
3 Доставить команду другим у...
Raft Введение
Свойства протокола
Безопасность: никогда не вернёт некорректный
результат
non-Byzantine fault tolerance9
Учи...
Raft Введение
Подсистемы
Выбор лидера
Репликация лога
Безопасность/корректность
Цесько В. А. (CompSciCenter) Distributed C...
Raft Кластер
Кластер
Несколько узлов (3, 5, ...)
Узёл в одном из трёх состояний: leader, follower,
candidate
В нормальном ...
Raft Кластер
Состояния узла
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 28 / 65
Raft Кластер
Семестры
Время разбивается на семестры (terms)
неопределённой длины10
Семестры нумеруются последовательно
Каж...
Raft Кластер
Семестры: Пример
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 30 / 65
Raft Кластер
Обнаружение устаревшей информации
Каждый узел хранит текущий семестр
Текущий семестр каждый раз передаётся в
...
Raft Кластер
RPC
RequestVote — кандидат просит отдать ему голос
AppendEntries — лидер реплицирует команды +
heartbeat
Цесь...
Raft Выбор лидера
Условия запуска
Follower не получает heartbeat в течение election
timeout
Follower увеличивает текущий с...
Raft Выбор лидера
Условия останова
Follower выиграл выборы (набрал большинство
голосов)
Каждый узел голосует единожды за с...
Raft Репликация лога
Формат лога
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 35 / 65
Raft Репликация лога
Committed Entry
Гарантируется, что будет выполнена всеми
автоматами
В простейшем случае — если подтве...
Raft Репликация лога
Log Matching Property
Если у двух записей в разных логах совпадают индекс
и семестр, то:
Они содержат...
Raft Репликация лога
Но может быть так
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 38 / 65
Raft Репликация лога
Пояснения
a-b — не хватает записей
c-d — лишние записи
e-f — оба случая
Цесько В. А. (CompSciCenter) ...
Raft Репликация лога
Разрешение конфликтов
Замена конфликтов на followers записями лога
лидера
Лидер помнит nextIndex для ...
Raft Корректность
Проблема
Лидер закоммитил несколько записей
Последователь был недоступен
Лидер ушёл с радаров
Последоват...
Raft Корректность
Решение
Расширим протокол:
Ограничение на узлы, которые могут стать
лидером
Ограничение на записи, котор...
Raft Корректность
Ограничение на выбор лидера
Всё так же нужно собрать голоса большинства
Но можно стать лидером, только е...
Raft Корректность
Коммиты
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 44 / 65
Raft Корректность
Случай 1
Наиболее популярный
Лидер реплицирует запись из текущего семестра
Запись закоммичена, как тольк...
Raft Корректность
Коммиты
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 46 / 65
Raft Корректность
Случай 2
Лидер коммитит запись из предыдущего семестра
Лидер семестра 2 создал запись по индексу 2,
отре...
Raft Корректность
Ограничение на коммиты
Пока новый лидер не закоммитит запись из
текущего семестра, он считает предыдущие...
Raft Timing and availability
Timing and availability
Timing requirement
broadcastTime electionTimeout MTBF
Типичные значен...
Raft Изменение конфигурации кластера
Изменение конфигурации кластера
Предполагали, что состав узлов статичен
Но иногда нуж...
Raft Изменение конфигурации кластера
Ситуация
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 51 / 65
Raft Изменение конфигурации кластера
Проблема
Проблема
Возможно одновременное существование двух лидеров
для одного семест...
Raft Изменение конфигурации кластера
Идея
Комбинация двух конфигураций:
Записи реплицируются серверам в обеих
конфигурация...
Raft Изменение конфигурации кластера
Joint Consensus
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 5...
Raft Изменение конфигурации кластера
Алгоритм
Запрос лидеру на смену конфигурации с Cold на
Cnew
Сохраняет в лог Cold,new ...
Raft Изменение конфигурации кластера
Особенности
Если лидер входит в Cold, но не в Cnew , то должен
выйти из кластера (реп...
Raft Оптимизации
Log Compaction
Подходы:
Очистка логов — перемещаем «живые» записи в
голову и очищаем мёртвый хвост
Инкрем...
Raft Оптимизации
Snapshotting
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 58 / 65
Raft Оптимизации
Snapshotting: Нюансы
Нужно решить, когда создавать слепки —
например, при достижении логом определённого
...
Raft Клиент
Проблема
Команда может применяться несколько раз
Лидер получил команду, закоммитил и умер, не
успев ответить
К...
Raft Клиент
Проблема
Протухшее чтение
У лидера есть все закоммиченые изменения
Но в начале семестра он не знает, кто из ни...
Raft Проект
Альтернативное домашнее задание
Проект akka-raft:
Open-source Raft implementation
Scala
Akka Extension
Paramet...
Заключение Библиотечка
Библиотечка
Think Distributed: A Distributed Systems Podcast13
Наборы открытых данных для курсовой ...
Заключение Homework: Feature request 1
Homework: Feature request 1
Key-Value API (кто ещё не)
Данные не влезают в память (...
Заключение Вопросы?
Вопросы?
http://incubos.org/contacts/
Общие вопросы — в Twitter: @incubos
Вопросы по лекциям — в комме...
Upcoming SlideShare
Loading in …5
×

2013 09 23_db_lecture_02

2,001 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,001
On SlideShare
0
From Embeds
0
Number of Embeds
1,558
Actions
Shares
0
Downloads
7
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

2013 09 23_db_lecture_02

  1. 1. Distributed Commit Курс «Базы данных» Цесько Вадим Александрович http://incubos.org @incubos Computer Science Center 23 сентября 2013 г. Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 1 / 65
  2. 2. Содержание 1 Distributed Commit 2 Happens-before 3 Raft 4 Заключение Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 2 / 65
  3. 3. Distributed Commit Two-Phase Commit Protocol Two-Phase Commit Protocol Distributed atomic commitment protocol commit или abort (rollback) Переживает (некоторые) временные сбои Полагается на логгирование для восстановления Восстановление — бОльшая часть логики протокола Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 3 / 65
  4. 4. Distributed Commit Two-Phase Commit Protocol Фазы Commit-request (voting) Координатор пытается подготовить участников транзакции Каждый участник отвечает Yes или No Commit Координатор принимает решение на основе ответов Все сказали Yes ⇒ commit, No ⇒ abort Координатор отправляет решение участникам Участники применяют решение Предусловие Если нет сбоев Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 4 / 65
  5. 5. Distributed Commit Two-Phase Commit Protocol Предположения Выделенный координатор Stable storage1 + write-ahead log (WAL) Узлы не умирают навсегда Данные в WAL не теряются и не портятся Любые два узлы могут общаться Внимание Если полностью уничтожить узел, можно потерять данные 1 http://en.wikipedia.org/wiki/Stable_storage Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 5 / 65
  6. 6. Distributed Commit Two-Phase Commit Protocol Диаграмма Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 6 / 65
  7. 7. Distributed Commit Two-Phase Commit Protocol Оптимизации Presumed abort/commit: работает при восстановлении, экономим на логгировании, используем статистику и ожидания Tree two-phase commit protocol (Nested/Recursive 2PC): агрегация в узлах дерева, экономнее используем сеть Dynamic two-phase commit: идём по дереву в одну сторону, динамический выбор координатора, быстрее освобождаем ресурсы Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 7 / 65
  8. 8. Distributed Commit Two-Phase Commit Protocol Ограничения Блокирующийся протокол Если координатор исчезнет, то некоторые участники могут не закончить транзакцию: Участник отправил координатору Yes Координатор упал Участник ожидает commit или rollback Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 8 / 65
  9. 9. Distributed Commit Two-Phase Commit Protocol Поведение при сбоях Пример ситуации: Реплика выполнила commit и упала вместе с координатором Система не может восстановить результат транзакции: Только умершие 2 ноды знают точный результат Pessimistic abort невозможен — упавшая реплика могла сделать commit Pessimistic commit невозможен — изначальное решение могло быть abort Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 9 / 65
  10. 10. Distributed Commit Three-Phase Commit Protocol Three-Phase Commit Protocol Назначение как у 2PC Неблокирующийся — ограничение сверху на commit/abort Лучше ведёт себя при сбоях2 2PC фаза Commit разбивается на 2 фазы — получаем 3PC 2 http://the-paper-trail.org/blog/ consensus-protocols-three-phase-commit/ Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 10 / 65
  11. 11. Distributed Commit Three-Phase Commit Protocol Диаграмма Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 11 / 65
  12. 12. Distributed Commit Three-Phase Commit Protocol Анализ Вторая фаза доносит решение до всех участников ⇒ состояние можно восстановить при сбое реплики Phase 3 = 2PC Commit При сбое координатора состояние восстанавливается с помощью реплик: Phase 1 (кто-то не получил Can commit?) ⇒ спокойно делаем abort Phase 2 (кто-то получил preCommit) ⇒ доводим транзакцию до commit Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 12 / 65
  13. 13. Happens-before Lamport timestamps Lamport timestamps Цель Определить порядок событий в распределённой системеa a Lamport, L. Time, Clocks, and the Ordering of Events in a Distributed System. 1978 Правила: Каждый процесс имеет счётчик Инкремент перед каждым событием Значение счётчика вместе с каждым сообщением При получении сообщения Cself = max(Cself , Csender ) Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 13 / 65
  14. 14. Happens-before Lamport timestamps Формализация C(x) — время события x ∀a∀b(a = b ⇒ C(a) = C(b)) Для различия событий в разных процессах часто добавляют PID Отношение happens-before: → Clock consistency: a → b ⇒ C(a) < C(b) Strong clock consistency: C(a) < C(b) ⇒ a → b — только через Vector Clocks Но верно, что C(a) ≥ C(b) ⇒ a → b Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 14 / 65
  15. 15. Happens-before Lamport timestamps Анализ Невозможно точно синхронизировать время3 Если процессы не общаются, то между их событиями нет отношения порядка Обеспечивается лишь частичный порядок 3 Хотя см. http://research.google.com/archive/spanner.html Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 15 / 65
  16. 16. Happens-before Vector clocks Vector clocks Цель Ввести частичный порядок событий в распределённой системе Обнаружить нарушения причинно-следственных связей Определение Векторные часы в системе с N процессами — это массив N логических часов по одному на процесс Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 16 / 65
  17. 17. Happens-before Vector clocks Правила обновления массива часов Изначально все часы выставлены в 0 При каждом событии процесс инкрементирует свои логические часы на 1 Перед отправкой сообщения процесс: Инкрементирует свои логические часы Отправляет весь вектор вместе с сообщением При получении сообщения процесс: Инкрементирует свои логические часы Обновляет свой вектор, беря покомпонентный максимум с присланным вектором Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 17 / 65
  18. 18. Happens-before Vector clocks Пример Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 18 / 65
  19. 19. Happens-before Vector clocks Формализация VC(x) — векторные часы события x VC(x)z — компонента векторных часов процесса z VC(x) < VC(y) ⇔ ∀z[VC(x)z ≤ VC(y)z] ∧ ∃z [VC(x)z < VC(y)z ] x → y ⇔ VC(x) < VC(y) VC(x) < VC(y) ⇒ C(x) < C(y) Отношение happens-before антисимметрично и транзитивно Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 19 / 65
  20. 20. Raft Введение Мотивация There are significant gaps between the description of the Paxos algorithm and the needs of a real-world system... and the final system will be based on an unproven protocol4 . Raft Протокол консенсуса для реплицированных автоматов Более простой, понятный и реализуемый чем Paxos Демонстрирует логику рассуждений 4 Chandra T. D., Griesemer R., Redstone J. Paxos made live: an engineering perspective. 2007 Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 20 / 65
  21. 21. Raft Введение Ссылки Replicated State Machines5 Ongaro D., Ousterhout J. In Search of an Understandable Consensus Algorithm. 2013. Diego Ongaro. Raft lecture6 (Raft user study) Diego Ongaro. Paxos lecture7 (Raft user study) Множество реализаций8 5 http://en.wikipedia.org/wiki/State_machine_replication 6 http://www.youtube.com/watch?v=YbZ3zDzDnrw 7 http://www.youtube.com/watch?v=JEpsBg0AO6o 8 https://ramcloud.stanford.edu/wiki/display/logcabin/LogCabin Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 21 / 65
  22. 22. Raft Введение Replicated State Machines Работают на множестве узлов Вычисляют идентичные копии одного и того же состояния Устойчивы к падению узлов Реплицированный лог (последовательность команд) Решаемые задачи: выбор лидера, хранилище конфигураций и др. Примеры: Chubby (GFS), ZooKeeper in HDFS, ... Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 22 / 65
  23. 23. Raft Введение Особенности Raft Strong Leader Клиенты общаются только с лидером Данные только от лидера к репликам Leader Election Cлучайные таймеры Membership changes Joint consensus Формальна описана и доказана безопасность Производительность на уровне аналогов Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 23 / 65
  24. 24. Raft Введение Алгоритм работы лидера 1 Получить команду от клиента 2 Добавить в локальный лог 3 Доставить команду другим узлам 4 При успехе применить команду к своему автомату 5 Вернуть ответ автомата клиенту Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 24 / 65
  25. 25. Raft Введение Свойства протокола Безопасность: никогда не вернёт некорректный результат non-Byzantine fault tolerance9 Учитывает ненадёжную сеть Доступность Пока работают и могут общаться большинство узлов Узлы останавливаются и снова подключаются Независимость от абсолютного времени Команда выполняется при ответе от большинства — устойчивость к медленным узлам 9 http://en.wikipedia.org/wiki/Byzantine_fault_tolerance Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 25 / 65
  26. 26. Raft Введение Подсистемы Выбор лидера Репликация лога Безопасность/корректность Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 26 / 65
  27. 27. Raft Кластер Кластер Несколько узлов (3, 5, ...) Узёл в одном из трёх состояний: leader, follower, candidate В нормальном режиме: 1 лидер и n − 1 последователей Последователи пассивны: отвечают на RPC от лидера и кандидатов Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 27 / 65
  28. 28. Raft Кластер Состояния узла Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 28 / 65
  29. 29. Raft Кластер Семестры Время разбивается на семестры (terms) неопределённой длины10 Семестры нумеруются последовательно Каждый семестр начинается с выбора лидера Если кандидат выигрывает выборы, то он служит лидером до конца семестра Если никто не победил на выборах, начинается новый семестр Инвариант В каждом семестре не больше одного лидера 10 Аналог логических часов Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 29 / 65
  30. 30. Raft Кластер Семестры: Пример Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 30 / 65
  31. 31. Raft Кластер Обнаружение устаревшей информации Каждый узел хранит текущий семестр Текущий семестр каждый раз передаётся в запросах Если текущий семестр меньше пришедшего, выбираем пришедший Если кандидат или лидер — step down Если пришедший семестр меньше текущего, то отвергаем запрос Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 31 / 65
  32. 32. Raft Кластер RPC RequestVote — кандидат просит отдать ему голос AppendEntries — лидер реплицирует команды + heartbeat Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 32 / 65
  33. 33. Raft Выбор лидера Условия запуска Follower не получает heartbeat в течение election timeout Follower увеличивает текущий семестр Переходит в состояние кандидата Параллельно отправляет всем RequestVote Перезапросы до получения ответа или окончания выборов Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 33 / 65
  34. 34. Raft Выбор лидера Условия останова Follower выиграл выборы (набрал большинство голосов) Каждый узел голосует единожды за семестр (FIFO) Новый лидер начинает рассылать всем heartbeats Другой узел стал лидером Кандидат получил AppendEntries с семестром ≥ текущего Кандидат переходит в состояние follower (step down) Наступил таймаут, а победителя всё нет Никто не набрал большинства голосов Кандидат переходит в состояние follower (step down) Random election timeout Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 34 / 65
  35. 35. Raft Репликация лога Формат лога Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 35 / 65
  36. 36. Raft Репликация лога Committed Entry Гарантируется, что будет выполнена всеми автоматами В простейшем случае — если подтверждена запись большинством (см. записи 1-7) Лидер пересылает индекс последнего коммита в AppendEntries — followers коммитят Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 36 / 65
  37. 37. Raft Репликация лога Log Matching Property Если у двух записей в разных логах совпадают индекс и семестр, то: Они содержат одинаковую команду Лидер создаёт не больше одной записи с одним индексом и семестром Записи в логе не перемещаются Логи идентичны во всех предшествующих записях Лидер с AppendEntries пересылает индекс и семестр предыдущей записи Follower отвергает запрос, если не совпадает Шаг индукции Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 37 / 65
  38. 38. Raft Репликация лога Но может быть так Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 38 / 65
  39. 39. Raft Репликация лога Пояснения a-b — не хватает записей c-d — лишние записи e-f — оба случая Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 39 / 65
  40. 40. Raft Репликация лога Разрешение конфликтов Замена конфликтов на followers записями лога лидера Лидер помнит nextIndex для каждого follower — изначально следующий за последним в логе Используется RPC AppendEntries Consistency Check Если ошибка, то nextIndex - 1 и retry Если совпадение, то удаляется хвост и добавляются записи лога лидера Автоматическая сходимость логов Лидер никогда не удаляет и не перезаписывает записи в собственном логе Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 40 / 65
  41. 41. Raft Корректность Проблема Лидер закоммитил несколько записей Последователь был недоступен Лидер ушёл с радаров Последователь стал новым лидером Последователь перезаписал всем логи В результате разные автоматы выполнили разный набор команд Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 41 / 65
  42. 42. Raft Корректность Решение Расширим протокол: Ограничение на узлы, которые могут стать лидером Ограничение на записи, которые считаются закоммичеными Обеспечиваем: Лидер любого семестра содержит все записи, закоммиченые в предыдущих семестрах Записи направлены только от лидера к последователям Лидеры никогда не перезатирают записи в своём логе Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 42 / 65
  43. 43. Raft Корректность Ограничение на выбор лидера Всё так же нужно собрать голоса большинства Но можно стать лидером, только если наш лог не менее свежий, чем у каждого голосующего RequestVote RPC содержит информацию о последней записи в логе Лог новее, если семестр старше или индекс больше (лог длиннее) Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 43 / 65
  44. 44. Raft Корректность Коммиты Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 44 / 65
  45. 45. Raft Корректность Случай 1 Наиболее популярный Лидер реплицирует запись из текущего семестра Запись закоммичена, как только подтвердит большинство Лидером могут стать только те, у кого есть эта запись Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 45 / 65
  46. 46. Raft Корректность Коммиты Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 46 / 65
  47. 47. Raft Корректность Случай 2 Лидер коммитит запись из предыдущего семестра Лидер семестра 2 создал запись по индексу 2, отреплицировал на S1 и S2 и упал S5 стал лидером в семестре 3 (собрал голоса у S3 и S4) Записал запись в свой лог по индексу 2 и упал S1 стал лидером в семестре 4 (голоса от S2 и S3) Отреплицировал запись по индексу 2 на S3 Незакоммичена несмотря на большинство S5 может стать лидером (его лог новее чем S2, S3 и S4) и распространить своё значение по индексу 2 Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 47 / 65
  48. 48. Raft Корректность Ограничение на коммиты Пока новый лидер не закоммитит запись из текущего семестра, он считает предыдущие записи незакоммичеными См. случай 3 — после этого S5 не может стать лидером См. доказательство корректности11 11 Safety proof and formal specification for Raft: http: //raftuserstudy.s3-website-us-west-1.amazonaws.com/proof.pdf Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 48 / 65
  49. 49. Raft Timing and availability Timing and availability Timing requirement broadcastTime electionTimeout MTBF Типичные значения: broadcastTime: 0.5-20 ms electionTimeout: 10-500 ms MTBF: month Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 49 / 65
  50. 50. Raft Изменение конфигурации кластера Изменение конфигурации кластера Предполагали, что состав узлов статичен Но иногда нужно заменять сервера или изменять уровень репликации В идеале — без downtime И автоматически — исключить человеческий фактор Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 50 / 65
  51. 51. Raft Изменение конфигурации кластера Ситуация Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 51 / 65
  52. 52. Raft Изменение конфигурации кластера Проблема Проблема Возможно одновременное существование двух лидеров для одного семестра в двух подкластерах Решения: 2PC: сначала выключаем старую конфигурацию, возможен downtime Raft: промежуточная конфигурация (joint consensus) Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 52 / 65
  53. 53. Raft Изменение конфигурации кластера Идея Комбинация двух конфигураций: Записи реплицируются серверам в обеих конфигурациях Сервер из любой конфигурации может стать лидером Нужно собрать большинство в каждой конфигурации по-отдельности При этом без downtime Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 53 / 65
  54. 54. Raft Изменение конфигурации кластера Joint Consensus Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 54 / 65
  55. 55. Raft Изменение конфигурации кластера Алгоритм Запрос лидеру на смену конфигурации с Cold на Cnew Сохраняет в лог Cold,new и реплицирует Каждый сервер сохраняет Cold,new в лог и сразу начинает использовать Лидер упал — новый лидер из Cold,new или Cold, но не Cnew Успешно закоммитили — лидером может стать только Cold,new Лидер сохраняет в лог Cnew и реплицирует и т. д. Cold и Cnew не могут одновременно принимать решения Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 55 / 65
  56. 56. Raft Изменение конфигурации кластера Особенности Если лидер входит в Cold, но не в Cnew , то должен выйти из кластера (реплицирует, но не входит в большинство) Новые сервера могут быть пустыми — вначале добавляем как неголосующих, но реплицируем на них логи Удаление серверов, которые не в курсе, что их удаляют, может снизить производительность кластера — инициируют безнадёжные выборы Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 56 / 65
  57. 57. Raft Оптимизации Log Compaction Подходы: Очистка логов — перемещаем «живые» записи в голову и очищаем мёртвый хвост Инкрементально и эффективно Определение живых записей может быть сложным Слепки — состояние системы периодически сохраняется на stable storage, а лог сбрасывается Менее эффективно (неинкрементально) Просто Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 57 / 65
  58. 58. Raft Оптимизации Snapshotting Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 58 / 65
  59. 59. Raft Оптимизации Snapshotting: Нюансы Нужно решить, когда создавать слепки — например, при достижении логом определённого размера Copy-on-write для асинхронной записи слепков + functional data structures/fork() Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 59 / 65
  60. 60. Raft Клиент Проблема Команда может применяться несколько раз Лидер получил команду, закоммитил и умер, не успев ответить Клиент делает перезапрос Идемпотентность Клиент присваивает командам уникальные последовательные номера Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 60 / 65
  61. 61. Raft Клиент Проблема Протухшее чтение У лидера есть все закоммиченые изменения Но в начале семестра он не знает, кто из них закоммичен Вначале он должен закоммитить запись из нового семестра Решение no-op в начале семестра Heartbeat с большинством кластера перед ответом на read Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 61 / 65
  62. 62. Raft Проект Альтернативное домашнее задание Проект akka-raft: Open-source Raft implementation Scala Akka Extension Parameterized by Akka FSM Extended with API (spray-based) Use Case: etcd12 implementation 12 https://github.com/coreos/etcd Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 62 / 65
  63. 63. Заключение Библиотечка Библиотечка Think Distributed: A Distributed Systems Podcast13 Наборы открытых данных для курсовой работы14 13 http://thinkdistributed.io/ 14 Via @pulser: http://www.hackathon.spb.ru/#!datasets/c1miv Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 63 / 65
  64. 64. Заключение Homework: Feature request 1 Homework: Feature request 1 Key-Value API (кто ещё не) Данные не влезают в память (>= 4 ГБ) Используйте открытые источники данных Стресстест в виде shell-скрипта Скачали Распаковали Запустили Storage (Xmx1G) Залили в Storage Срок реализации до 2013-10-14 Hints: mmap(), дисковый кэш, ... Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 64 / 65
  65. 65. Заключение Вопросы? Вопросы? http://incubos.org/contacts/ Общие вопросы — в Twitter: @incubos Вопросы по лекциям — в комментариях: http://incubos.org/blog/ Частные вопросы — в почту vadim.tsesko@gmail.com Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 65 / 65

×