Технологии хранения и обработки больших объёмов...
TRANSCRIPT
Big Data’15Лекция VII: консенсус в распределенной системе
Дмитрий Барашев[email protected]
Computer Science Center
31 марта 2015
1/66
Этот материал распространяется под лицензией
Creative Commons ”Attribution - Share Alike” 3.0http://creativecommons.org/licenses/by-sa/3.0/us/deed.ru
сверстано в онлайн LATEX редакторе
Pa
peeriapapeeria.com
2/66
Сегодня в программе
Вступление
Two-Phase Commit
Paxos
Raft
3/66
Сегодня в программе
Вступление
Two-Phase Commit
Paxos
Raft
4/66
Репликация, согласованность,отказоустойчивость
▶ Репликация позволяет масштабировать систему▶ Репликация ставит задачи:
▶ реплики должны быть согласованы▶ в случае сбоя реплика должнавосстановиться
5/66
Нужны ответы на вопросы
▶ Я согласован?▶ Есть предложение. Все согласны?▶ Извините, я что-то заснул. Что я пропустил?
6/66
Я согласован?
▶ Узлу надо как-то понимать, в каком онсостоянии
7/66
Векторные часы
▶ У кажого узла есть номер, собственный счетчики вектор известных ему значений счетчиковдругих узлов
▶ Получается матрица, где▶ строка i – сведения узла i о часах другихузлов
▶ диагональный элемент Vii - актуальныепоказания часов узла i
▶ столбец j – сведения других узлов о часахузла j
8/66
Векторные часы: правила
▶ Когда на узле происходит событие, онувеличивает собственный счетчик иприсваивает событию векторную метку
▶ Если узел i посылает сообщение узлу j, онувеличивает счетчик в своей позиции ипосылает весь свой вектор вместе с сообщением
▶ Если узел j принимает сообщение от узла i, онувеличивает счетчик в своей позиции,сравнивает векторы поэлементно и беретмаксимум
9/66
Векторные часы: сравнение событий
▶
Vi > Vj, if ∀kVi[k] >= Vj[k], ∃m : Vi[m] > Vj[m]
▶ Если векторная метка Va > Vb для событий a и bто a→ b
▶ Если вектора несравнимы то событияконкурентны
10/66
Векторные часы: пример
11/66
Векторные часы: использование
▶ Клиент может использовать часы, чтобы бытьуверенным в монотонном возрастанииполучаемых значений
▶ Узел может использовать часы, чтобы решить,что делать со значениями – взять свою версию,чужую или разрешить конфликт
12/66
Задача консенсуса
▶ Консенсус – процесс принятия единого решениягруппой участников
▶ Подтверждать или нет транзакцию▶ Синхронизация часов▶ Выбор узла-координатора какого-то болеевысокоуровневого протокола
▶ Решение перейти к какой-то следующей фазеалгоритма
13/66
Реплицируемый журнал
▶ Каждая реплика имеет свою копию журналаопераций
▶ в журнал записываются изменениясостояния системы
▶ В случае сбоя реплика читает журнал,применяет операции ⇒ восстанавливается
▶ Если у реплик одинаковое начальное состояниеи одинаковый журнал то они будут согласованы
14/66
Достижение консенсуса
▶ Новые значения дописываются в конец журнала▶ Могут ли компоненты распределённой системыдоговариться о новом значении?
▶ Цель: достигать консенсунс по каждомузаписываемому значению
15/66
Действующие лицаКлиент посылает системе запросы иждёт ответы. На-
пример, просит записать новое значение встроку таблицы
Инициаторproposer
принимает запрос клиента и делает системепредложение с полученным значением
Выборщикacceptor/voter
отдает или не отдает свой голос за утвержде-ние предложения
Кворумquorum
группа выборщиков, необходимая для утвер-ждения предложения
Исполнительlearner
узнаёт об утверждении предложенного зна-чения и предпринимает по этому поводу дей-ствия, например, записывает значение в стро-ку и/или посылает ответ клиенту
Процесс программный код, участник системы, выпол-няющий одну или несколько ролей
16/66
Желательные свойства алгоритмаконсенсуса
▶ Могут быть утверждены только внесённыепредложения
▶ В очередной раунд голосования может бытьутверждено только одно предложение
▶ Если исполнитель узнал об утверждениипредложения, значит оно действительно былоутверждено
▶ Если предложение утверждено, то исполнителирано или поздно об этом узнают
▶ Если какое-то предложение внесено, токакое-то предложение будет утверждено
17/66
Что может быть проще?
1 List log = new ArrayList();
2 List<Learner> learners = new ArrayList<>();
3
4 synchronized void propose(Object value) {
5 log.add(value);
6 for (Learner l : learners) {
7 l.notify(value);
8 }
9 }
18/66
Распределённая реальность сложнее▶ Процессы могут падать▶ Хуже того, они могут восстанавливаться и сноваприсоединяться к системе
▶ Сообщения посылаются асинхронно,доставляются Почтой России могут бытьпереставлены местами, доставлены созначительным опозданием или не доставленывовсе
но зато:
▶ Процессы соблюдают протокол, если сообщениядоставляются, то неповреждёнными, и любойпроцесс может послать сообщение любому
19/66
Сегодня в программе
Вступление
Two-Phase Commit
Paxos
Raft
20/66
Two-Phase Commit1 в целом
▶ Простой и линейный, состоит из двух фаз▶ Кворум состоит из всех выборщиков▶ Плохо переживает сбои, рассчитывает что сетьработает и что узлы восстанавливаются послесбоев
▶ Используется там, где требуется строгаясогласованность
▶ например в распределённых реляционныхБД
12PC, двухфазное подтверждение21/66
2PC: участники и цель
▶ Координатор транзакции, часто специальнообученная компонента
▶ Участники транзакции, часто экземплярыреляционной СУБД. У участника есть надежныйопережающий журнал2
▶ Цель: выполнить и подтвердитьраспределённую ACID транзакцию
2write-ahead log22/66
Фаза ”приготовились”▶ До старта протокола каждый участниквыполняет локальную транзакцию со своимиданными
▶ Когда распределённая транзакция готоваподтвердиться, координатор рассылает всемучастникам сообщение ”приготовиться”
▶ Участник может подтвердить локальнуютранзакцию ⇒ обычно блокирует ресурсы,записывает информацию в redo-log, посылаеткоординатору ACK
▶ ∀ участника ∃ ACK ⇒ начинается фаза”подтверждение”
▶ ∃ участник, не приславший ACK ⇒ координаторначинает фазу ”откат”
23/66
Фаза ”подтверждение”
▶ Координатор рассылает участникам сообщение”подтверждаемся”
▶ Участник подтверждает локальную транзакциюи посылает координатору уведомление
▶ Собрали уведомления со всех участников ⇒транзакция подтверждена
24/66
Фаза ”откат”
▶ Координатор посылает всем сообщение”откатываемся”
▶ Узлы откатывают действия локальнойтранзакции используя свои средства отката(undo журнал)
25/66
Сбои участника
▶ Участник упал при подготовке ⇒ координатороткатит транзакцию
▶ Участник упал при подтверждении ⇒ емупридется восстановить данные транзакции изredo журнала и таки подтвердить
▶ остальные будут ждать
26/66
Сбои координатора
▶ Координатор падает при подготовке ⇒печально, потому что некоторые участники ужемогли ответить ACK и заблокировать ресурсы
▶ Надеемся что координатор восстановится▶ Если нет, то участники могут выбрать другогокоординатора
▶ что усложняет протокол▶ Или подготовившиеся участники могут сделатьоткат, при потере связи с координатором
▶ главное чтоб координатор в это время неожил
27/66
Сбои координатора
▶ Координатор падает при подтверждении ⇒печально, но терпимо, потому что все ужеготовы
▶ Если координатор не восстановится, то один изучастников может закончить фазуподтверждения
28/66
Сегодня в программе
Вступление
Two-Phase Commit
Paxos
Raft
29/66
История
“Раскопки на острове Паксос показали, чтоместный парламент работал в условияхчастичной доступности депутатов иотсутствия единого секретаря. Депутатынадолго уезжали и забывали своисообщения, но тем не менее поддерживалисвои записи о законодательных актах всогласованном состоянии.
– из статьи Лесли Лэмпорта ”30/66
Предположения
▶ Выборщики могут выбывать из строя▶ Выборщики с надежным долговременнымхранилищем могут присоединяться снова
▶ Выборщики не устраивают диверсий▶ Выборщики могут посылать друг другусообщения
▶ Сообщения доставляются асинхронно, занеопределённое время, могут быть перепутаны,потеряны или дублированы
▶ Если сообщение доставлено, то оно доставленонеповреждённым
31/66
Идея 1: простейший случай
▶ Всё работает без сбоев и один инициаторделает одно предложение
▶ Выборщики (хотя бы один), очевидно, должныего утвердить
Что делать если инициаторов более одного?
32/66
Идея 1: простейший случай
▶ Всё работает без сбоев и один инициаторделает одно предложение
▶ Выборщики (хотя бы один), очевидно, должныего утвердить
Что делать если инициаторов более одного?
32/66
Идея 2: кворум
▶ Предложений > 1 а утвердить надо одно. Нужнаполитика определения победителя.
▶ Самое простое: утверждается предложение, закоторое проголосовал кворум – большеполовины выборщиков
▶ в этом случае у предложения точно большеголосов чем у конкурентов
▶ Но сообщения доставляются не мгновенно
33/66
Что-то пошло не так
P1 P2 A1 A2 A3
Propose V1Accept
Propose V2AcceptPropose V2
×▶ Не хочется навсегда зависнуть без кворума
34/66
Идея 3: Выбор другого предложения
▶ Будем генерировать возрастающие номерапредложений
▶ Пока значение не утверждено, разрешимвыборщику принимать новые предложения
▶ Но когда значение утверждено, разрешим емупринимать только новые предложения сутвержденным значением
Откуда выборщик знает что предложениеутверждено?
35/66
Идея 3: Выбор другого предложения
▶ Будем генерировать возрастающие номерапредложений
▶ Пока значение не утверждено, разрешимвыборщику принимать новые предложения
▶ Но когда значение утверждено, разрешим емупринимать только новые предложения сутвержденным значением
Откуда выборщик знает что предложениеутверждено?
35/66
Идея 4: Инициатор делает правильныепредложения
▶ Об утверждении может узнать инициатор▶ Инициатор связывается с кворумом▶ Если уже было утверждено значение, то этотоже сделал кворум
▶ У двух кворумов есть общий выборщик ⇒ онможет рассказать инициатору всю правду обутверждении
Но как его, общего, найти?
36/66
Идея 4: Инициатор делает правильныепредложения
▶ Об утверждении может узнать инициатор▶ Инициатор связывается с кворумом▶ Если уже было утверждено значение, то этотоже сделал кворум
▶ У двух кворумов есть общий выборщик ⇒ онможет рассказать инициатору всю правду обутверждении
Но как его, общего, найти?
36/66
Идея 5: Инициатор всех обзванивает
▶ Просто спросить у всех выборщиков из кворума,какое последнее значение каждый из нихутвердил
▶ Если никто ничего не утверждал значит можнодавать своё значение
▶ Если кто-то участвовал в утверждении, то он обэтом скажет и сообщит значение и номерпредложения
▶ Надо выбрать предложение с наибольшимномером
▶ На это нужно некоторое время
Что если в это время кто-то из кворума получитзапоздалое предложение с меньшим номером?
37/66
Идея 5: Инициатор всех обзванивает
▶ Просто спросить у всех выборщиков из кворума,какое последнее значение каждый из нихутвердил
▶ Если никто ничего не утверждал значит можнодавать своё значение
▶ Если кто-то участвовал в утверждении, то он обэтом скажет и сообщит значение и номерпредложения
▶ Надо выбрать предложение с наибольшимномером
▶ На это нужно некоторое времяЧто если в это время кто-то из кворума получитзапоздалое предложение с меньшим номером?
37/66
Идея 6: Выборщик дает обещание
▶ Получив предложение с номером n выборщикдает обещание игнорировать предложения сномером m < n
38/66
Алгоритм
▶ Фаза 1 (подготовка): Инициатор рассылаетпредложения кворуму и собирает с выборщиковобещания и утвержденные значения
▶ Фаза 2 (утверждение): Инициатор выбираетзначение и просит выборщиков его утвердить
39/66
Фаза 1
▶ Инициатор выбирает номер предложения ирассылает кворуму запрос подготовки с этимномером
▶ Если выборщик получил запрос подготовки сномером n
▶ n больше номера всех предложений в ранеепринятых запросов подготовки? Если нет, тоигнорируй это предложение (или ответь NACK),если да, то обещай игнорировать всебудущие с номером < n
▶ у тебя есть утвержденное предложение?верни инициатору его номер и его значение
40/66
Фаза 2
▶ Инициатор получил ответы от всего кворума.Если никто не вернул ранее утвержденноезначение, инициатор волен предложить своё.Если утверждённые значения есть, инициатордолжен предложить значение с максимальнымномером предложения. Запрос утвержденияснова рассылается всему кворуму.
▶ Если выборщик получил запрос утверждения сномером n то он его утверждает, если только неуспел уже поучаствовать в Фазе 1 дляпредложения с номером > n
41/66
Критика
▶ Paxos считается сложным для понимания▶ хотя Leslie Lamport замечает что в описаниинет ни одной формулы сложнее чем n >m
▶ Ванильный Paxos рассчитан на утверждениеодного значения; в реальности журнал состоитиз многих значений и Paxos не специфицируеткак с ними обращаться
▶ нет уверенности что Multi-Paxos работает▶ попытки оптимизаций и модификаций дляпоследовательности значений приводят кпоявлению доморощенных недоказанныхпротоколов
42/66
Сегодня в программе
Вступление
Two-Phase Commit
Paxos
Raft
43/66
Цели
▶ Такие же гарантии и производительность как уPaxos
▶ Ориентация на практические системы▶ Доступность для понимания программистами
44/66
Ключевые особенности
▶ Приемом запросов, формированием журнала,его репликацией и утверждением записейзанимается выделенный лидер
▶ Лидер выбирается надолго▶ В случае падения лидера выбирается новый
45/66
Действующие лица
Несколько процессов, каждый из которых водин момент времени играет одну из ролей
Лидерleader
Отвечает за прием запросов, фор-мирование журнала и общение сведомыми
Кандидатcandidate
Может стать новым ведущим вслучае начала перевыборов
Ведомыйfollower
Принимает от ведущего командына добавление записей в журнал
В нормальном состоянии 1 ведущий, всеостальные ведомые
46/66
Переходы между ролями
Ведомый
Кандидат
Ведущий
47/66
Поколения жизни
▶ Время жизни системы поделено нанепересекающиеся поколения неопределённойдлины
▶ Поколения нумеруются монотонновозрастающими номерами
▶ На каждом сервере свой счетчик поколений (вобычном состоянии значения равны)
▶ В начале поколения выбирается ведущий▶ Ведущий сохраняется в течении всегопоколения
▶ Поколение заканчивается когда кто-тоинициирует выборы ведущего
48/66
Записи в журнале
▶ Записи в журнале нумеруются поколением вкотором они созданы и порядковым номером(индексом)
▶ Запись может быть записана, утверждена иприменена
49/66
Записи в журнале
50/66
Гарантии
Безопасностьвыборов
в каждом поколении выбирается не болееодного ведущего
Ведущийтолько на-ращиваетжурнал
записи в журнале ведущего никогда не пе-ретираются и не удаляются (у ведомых нетак)
Идентич-ность жур-налов
если в двух журналах есть запись с оди-наковым индексом и номером поколениято эти журналы идентичны от начала и доэтой записи включительно
Полнотажурналаведущего
если запись утверждена в каком-то поко-лении, то она будет в журналах лидеровпоследующих поколений
Безопасностьпримене-ния
если лидер применил запись с неким ин-дексом, то никакой другой сервер не при-менит другую запись с таким же индексом
51/66
Выборы ведущего
▶ Пока ведущий жив, он посылает сигналыпульса3 ведомым
▶ Если ведомый не получил пульса от ведущего втечении какого-то времени (election timeout), онувеличивает свой счетчик поколений,становится кандидатом и рассылает всемучастникам запрос о выборе ведущего(предлагая себя)
▶ Выборы можно выиграть, проиграть или свестивничью
3heartbeat52/66
Победа в выборах▶ Надо получить голоса от кворума серверов изтого же поколения
▶ Если ведущий на самом деле умер, то всесервера перейдут в новое поколение и утвердятпервого же попавшегося кандидата в качествеведущего. Тот должен послать всем пульс иутвердить тем самым своё лидерство
▶ Если ведущий на самом деле жив, то кандидатубудет отказано: нет кворума да и вообще, приживом то ведущем…(см. дальше)
▶ Если два кандидата конкурируют то победиттот кто соберет кворум. Для предотвращенияконкуренции используются случайные значенияelection timeout
53/66
Репликация журнала
▶ При поступлении новой записи от клиентаведущий:
▶ записывает её в свой журнал▶ рассылает запись ведомым▶ после успешной репликации и утвержденияприменяет запись и отвечает клиенту
▶ Если ведомый не отвечает, ему будутдозваниваться бесконечно
54/66
Подтверждение записи
▶ Простейший случай: если реплицируется записьиз текущего поколения, то она утверждаетсякак только кворум производит запись.
▶ Ведущий применяет утвержденную запись▶ В сообщении пульса ведущий сообщает индекспоследней утверждённой записи; ведомыйвправе применить у себя локально все записидо неё включительно
55/66
Проверка согласованности
▶ Вместе с реплицируемой записью ведущийпосылает поколение и индекс предыдущейзаписи
▶ Если ведомый находит у себя предыдущуюзапись, то он принимает новую
▶ А иначе отказывается
56/66
Возможные случаи
57/66
Что делать с отказавшимися
▶ Переслать им значение предыдущей записи икоординаты записи перед ней
▶ Делать так до тех пор пока не найдётся самаяпоздняя общая запись
▶ Потом пройти в обратную сторону и сделатьсуффикс его журнала идентичным суффиксуведущего
58/66
Безопасность
▶ Пока что схема уязвима▶ Например, ведомый может проспать несколькоутвержденных записей, потом стать лидером иначать портить журналы своим неполным
▶ Сделаем такую политику выборов иподтверждения, чтоб ведущим мог стать толькотот, у кого полный журнал
59/66
Ограничения в выборе▶ Не позволим выбирать ведущим того, у кого вжурнале нет всех утвержденных записей
▶ Кандидат включает в запрос о выборекоординаты последней записи своего журнала
▶ Отношение «свежесть» между журналами:лексикографическое сравнение пар (поколение,индекс) последних записей журналов. Еслижурнал выборщика свежее, кандидатуотказывают.
▶ Записи утверждаются кворумом и кандидатобращается к кворуму⇒ если у кандидата неткакой-то утвержденной записи то его журнал,скорее всего, будет менее свежим чем журналкого-то из кворума
60/66
Еще не всё
▶ Утверждённые, казалось бы, записи могут бытьпереписаны!
61/66
Ограничения в утверждении
▶ Ведущий не может считать утвержденнымизаписи из предыдущих поколений до тех порпока он не утвердил одну запись из своегопоколения
▶ Когда это сделано, кандидат с неполнымжурналом не сможет стать ведущим
62/66
Занавес
▶ Существуют алгоритмы достижения консенсусаи согласованного журнала
▶ Алгоритмы работают в тяжёлых условиях:ненадёжные процессоры и сеть, надёжнотолько хранилище
▶ Paxos известен давно и широко применяется, нострадает от некоторой абстрактности
▶ Raft появился недавно и ориентирован напонимание и однозначность реализации
64/66
Литература I
Consensus protocols: Two-phase commit, 2008.
Tushar D Chandra, Robert Griesemer, and JoshuaRedstone.Paxos made live: an engineering perspective.In Proceedings of the twenty-sixth annual ACMsymposium on Principles of distributed computing,pages 398–407. ACM, 2007.Ben Johnson.Raft: Understandable distributed consensus.http://thesecretlivesofdata.com/raft/.Leslie Lamport.Paxos made simple.ACM Sigact News, 32(4):18–25, 2001.
65/66
Литература II
Diego Ongaro and John Ousterhout.In search of an understandable consensusalgorithm.Draft of October, 7, 2013.
66/66