Виртуализация уровня операционной системы в Linux (так, называемые контейнеры) опирается на изоляцию ресурсов и на управление их использованием. Пространства имен в Linux (linux namespaces) тот инструмент, который позволяет изолировать ресурсы друг от друга на уровне имен. Например, именами процессов являются их идентификаторы (PIDs), которые можно организовать таким образом, что процессы никогда не могут узнать о существовании друг друга. Об этом и других интересных вещах рассказывается в презентации.
Linux Control Groups (Контрольные группы) -- механизм, позволяющий управлять группами процессов в Linux и их ресурсами. Это мощный инструмент о котором знают далеко не все. Презентация дает краткий обзор.
Виртуализация уровня операционной системы в Linux (так, называемые контейнеры) опирается на изоляцию ресурсов и на управление их использованием. Пространства имен в Linux (linux namespaces) тот инструмент, который позволяет изолировать ресурсы друг от друга на уровне имен. Например, именами процессов являются их идентификаторы (PIDs), которые можно организовать таким образом, что процессы никогда не могут узнать о существовании друг друга. Об этом и других интересных вещах рассказывается в презентации.
Linux Control Groups (Контрольные группы) -- механизм, позволяющий управлять группами процессов в Linux и их ресурсами. Это мощный инструмент о котором знают далеко не все. Презентация дает краткий обзор.
Повышаем отказоустойчивость без дорогих решенийLenvendo
Презентация технического директора "Ленвендо" Виталия Гаврилова на конференции Failover Conference, 10 апреля 2015 года.
Компания "Ленвендо" занимается развитием и поддержкой онлайн-проектов.
Сегодня «Ленвендо» отвечает за работу ресурсов «Эльдорадо», «Связной», HomeMe, Газпромбанк, Два берега, oodji.
Мы в Avito уже более года используем Kubernetes в качестве платформы для микросервисов.
За это время мы столкнулись с рядом проблем, с которыми может столкнуться каждый, кто использует эту платформу.
В докладе поделюсь опытом решения проблем и настройки кластера для обеспечения его эффективной работы.
Настройка kubernetes: tips and tricks / Михаил Прокопчук (Avito)Ontico
HighLoad++ 2017
Зал «Пекин+Шанхай», 7 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/2967.html
Мы в Avito уже более года используем Kubernetes в качестве платформы для микросервисов.
За это время мы столкнулись с рядом проблем, с которыми может столкнуться каждый, кто использует эту платформу.
В докладе поделюсь опытом решения проблем и настройки кластера для обеспечения его эффективной работы (низкий и стабильный latency для сервисов, использование ресурсов CPU, RAM): настройки аппаратного обеспечения (сеть, CPU), ОС, настройки самих инфраструктурных компонентов kubernetes и о том, что и как необходимо мониторить.
Вторая лекция раздела NoSQL курса "Базы данных" в Технополисе.
Содержание: CAP теорема, распределённые транзакции, отношение happens-before, протокол Raft.
Как и зачем создавать NginX-модуль — теория, практика, профит. Часть 2 / Васи...Ontico
HighLoad++ 2017
Зал Дели + Калькутта, 7 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/2940.html
Почти год назад я выступил с докладом 'Как и зачем создавать NginX-модуль - теория, практика, профит'. У меня не получилось рассказать обо всех возможностях Nginx и, уверяю вас, в этом докладе у меня это тоже не получится - тема слишком большая!
Сразу перейдем к делу. "Так что нового будет в этом докладе?" - спросите вы. В нем будут ответы на вопросы, на которые я не успел ответить в прошлом году, а именно:
- Как и зачем создавать upstream-модули?
...
"YT — новая платформа распределённых вычислений". Максим Бабенко, Яндекс. Yandex
На протяжении трёх лет мы проектировали, разрабатывали и внедряли YT — новую платформу для хранения и обработки больших объёмов данных. Она создавалась как альтернатива MapReduce-подобной системы, которая используется в Яндексе с 2008 года. При этом требовалось повысить её эффективность, доступность и масштабируемость. Задачу усложнял огромный объём унаследованного кода клиентов, с которыми необходимо было сохранить совместимость, а также наличие общепризнанных открытых альтернатив (например, платформы Hadoop). Поскольку YT изначально проектировалась по принципу «больше чем MapReduce», в её дизайне выделяется набор компонент, допускающих повторное использование: подсистема распределённого консенсуса и репликации состояния, дерево метаданных, blob-хранилище и другие. В докладе я дам краткий обзор архитектуры новой системы, расскажу о нескольких ключевых компонентах, а также поделюсь опытом, полученным в процессе разработки и внедрения. В завершение, перечислю приоритетные направления дальнейшего развития YT.
Модным ныне словом «виртуализация» сейчас называют различные обёртки аппаратной виртуализации, однако этот термин намного старше и более всеохватывающий. На уровне ознакомления с технологией мы поговорим о виртуализации ресурсов в кластере и на примере pacemaker.
Франкенштейнизация Voldemort или key-value данные в Одноклассниках. Роман Ан...odnoklassniki.ru
A talk from jokerconf.com conference.
"Frankenstaining of Voldemort" or "key-value storage evolution at Odnoklassniki"
В докладе освещены Java-технологии хранения данных, обслуживающие десятки миллионов пользователей и работающие на сотнях серверов.
На примере социальной сети "Одноклассники" мы рассмотрим эволюцию хранилищ данных с высоким уровнем конкурентного доступа и с соблюдением требования постоянной доступности.
Мы разберём сильные и слабые стороны каждого из решений, начиная от технологии master-slave репликации на основе Berkeley DB и заканчивая симбиозом распределенных хранилищ Voldemort и Cassandra.
Тюним память и сетевой стек в Linux: история перевода высоконагруженных серве...Ontico
В процессе обновления высоконагруженных серверов раздачи видео (40Gbit/s с каждого сервера) со старого OpenSuSE 10.2 на новый CentOS 7 (время между релизами — 7 лет) мы столкнулись с рядом проблем — необъяснимый свопинг и запуски OOM killer, неравномерное распределение нагрузки по ядрам, обрывы соединений, скачки системной нагрузки на CPU.
В докладе будет рассказано о том, как мы боролись с этими проблемами и какие технологии для этого использовали.
Повышаем отказоустойчивость без дорогих решенийLenvendo
Презентация технического директора "Ленвендо" Виталия Гаврилова на конференции Failover Conference, 10 апреля 2015 года.
Компания "Ленвендо" занимается развитием и поддержкой онлайн-проектов.
Сегодня «Ленвендо» отвечает за работу ресурсов «Эльдорадо», «Связной», HomeMe, Газпромбанк, Два берега, oodji.
Мы в Avito уже более года используем Kubernetes в качестве платформы для микросервисов.
За это время мы столкнулись с рядом проблем, с которыми может столкнуться каждый, кто использует эту платформу.
В докладе поделюсь опытом решения проблем и настройки кластера для обеспечения его эффективной работы.
Настройка kubernetes: tips and tricks / Михаил Прокопчук (Avito)Ontico
HighLoad++ 2017
Зал «Пекин+Шанхай», 7 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/2967.html
Мы в Avito уже более года используем Kubernetes в качестве платформы для микросервисов.
За это время мы столкнулись с рядом проблем, с которыми может столкнуться каждый, кто использует эту платформу.
В докладе поделюсь опытом решения проблем и настройки кластера для обеспечения его эффективной работы (низкий и стабильный latency для сервисов, использование ресурсов CPU, RAM): настройки аппаратного обеспечения (сеть, CPU), ОС, настройки самих инфраструктурных компонентов kubernetes и о том, что и как необходимо мониторить.
Вторая лекция раздела NoSQL курса "Базы данных" в Технополисе.
Содержание: CAP теорема, распределённые транзакции, отношение happens-before, протокол Raft.
Как и зачем создавать NginX-модуль — теория, практика, профит. Часть 2 / Васи...Ontico
HighLoad++ 2017
Зал Дели + Калькутта, 7 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/2940.html
Почти год назад я выступил с докладом 'Как и зачем создавать NginX-модуль - теория, практика, профит'. У меня не получилось рассказать обо всех возможностях Nginx и, уверяю вас, в этом докладе у меня это тоже не получится - тема слишком большая!
Сразу перейдем к делу. "Так что нового будет в этом докладе?" - спросите вы. В нем будут ответы на вопросы, на которые я не успел ответить в прошлом году, а именно:
- Как и зачем создавать upstream-модули?
...
"YT — новая платформа распределённых вычислений". Максим Бабенко, Яндекс. Yandex
На протяжении трёх лет мы проектировали, разрабатывали и внедряли YT — новую платформу для хранения и обработки больших объёмов данных. Она создавалась как альтернатива MapReduce-подобной системы, которая используется в Яндексе с 2008 года. При этом требовалось повысить её эффективность, доступность и масштабируемость. Задачу усложнял огромный объём унаследованного кода клиентов, с которыми необходимо было сохранить совместимость, а также наличие общепризнанных открытых альтернатив (например, платформы Hadoop). Поскольку YT изначально проектировалась по принципу «больше чем MapReduce», в её дизайне выделяется набор компонент, допускающих повторное использование: подсистема распределённого консенсуса и репликации состояния, дерево метаданных, blob-хранилище и другие. В докладе я дам краткий обзор архитектуры новой системы, расскажу о нескольких ключевых компонентах, а также поделюсь опытом, полученным в процессе разработки и внедрения. В завершение, перечислю приоритетные направления дальнейшего развития YT.
Модным ныне словом «виртуализация» сейчас называют различные обёртки аппаратной виртуализации, однако этот термин намного старше и более всеохватывающий. На уровне ознакомления с технологией мы поговорим о виртуализации ресурсов в кластере и на примере pacemaker.
Франкенштейнизация Voldemort или key-value данные в Одноклассниках. Роман Ан...odnoklassniki.ru
A talk from jokerconf.com conference.
"Frankenstaining of Voldemort" or "key-value storage evolution at Odnoklassniki"
В докладе освещены Java-технологии хранения данных, обслуживающие десятки миллионов пользователей и работающие на сотнях серверов.
На примере социальной сети "Одноклассники" мы рассмотрим эволюцию хранилищ данных с высоким уровнем конкурентного доступа и с соблюдением требования постоянной доступности.
Мы разберём сильные и слабые стороны каждого из решений, начиная от технологии master-slave репликации на основе Berkeley DB и заканчивая симбиозом распределенных хранилищ Voldemort и Cassandra.
Тюним память и сетевой стек в Linux: история перевода высоконагруженных серве...Ontico
В процессе обновления высоконагруженных серверов раздачи видео (40Gbit/s с каждого сервера) со старого OpenSuSE 10.2 на новый CentOS 7 (время между релизами — 7 лет) мы столкнулись с рядом проблем — необъяснимый свопинг и запуски OOM killer, неравномерное распределение нагрузки по ядрам, обрывы соединений, скачки системной нагрузки на CPU.
В докладе будет рассказано о том, как мы боролись с этими проблемами и какие технологии для этого использовали.
В рамках магистерского курса "Параллельные вычисления" на кафедре КСПТ прочитал лекцию "Actor Model":
* Actor Model
* Futures and Promises
* Примеры систем
Фреймворк Akka и его использование в ЯндексеVadim Tsesko
Доклад с JPoint 2014 (http://javapoint.ru).
Краткое содержание:
* Actor Model на примере Akka
* Происхождение
* Концепции и API
* Примеры кода
* Примеры систем в Яндекс
* Конвейерная обработка данных
* Реактивные иерархические системы
* Опыт разработки и эксплуатации
* Подводные камни
* Проблемы и некоторые решения
* Дополнительные тулы
Moscow Exchange Test Automation of a Backup System at TMPA-2014 (Trading Syst...Iosif Itkin
Tools & Methods of Program Analysis (TMPA-2014)
Conference in Kostroma, November 14-15
Рассмотрена задача автоматизации тестирования программного комплекса с двухуровневым резервированием. Предложен подход на основе описания комплекса как системы конечных автоматов, тогда тестовые сценарии есть пути на графе переходов конечного автомата. На основе этого подхода создано инструментальное средство, позволяющее находить всевозможные пути графа (возможные сценарии осуществления переходов, порождающие управляющие bash-скрипты в операционной системе Linux). Предусмотрено исполнение порожденных скриптов в рамках инфраструктуры автоматизированного тестирования. Инструментальное средство позволяет проверить исправность работы системы резервирования
Дмитрий Меньшиков "Топ-10 фейлов на реальном highload проекте"Fwdays
- как ошибка выбора идентификатора пользователя, обнаруженная после запуска проекта, чуть не стоила 2 лет разработки
- как мы боролись с перегруженным mysql когда даже включение binlog убивает сервер
- почистил партицию mysql под нагрузкой - получи мертвый сервер
- как верстальщик поменял верстку серча и уложил продукт на 4 часа
- ошибка в ядре php которая привела даунтайм на несколько часов
- как незнание особенностей работы GC у redis обошлось в $50к чистой прибыли
- добавлением или удалением серверов из пула memcached инвалидировали весь кэш (кривые настройки php клиента Memcache/Memcached)
- как поправив тест потерять 2 миллиона пользовательских писем
- как релиз одного проекта крэшил хелсчеки соседнего проекта
- самый большой фейл с системами очередей и статистикой: ивенты терялись годами
JS Fest 2018. Максим Климишин. Распределенные данные: CRDT-структуры данных в JSJSFestUA
Почему распределенные данные это сложно и как начать использовать последние разработки в поддержании консистентности данных в браузерах и мобильных клиентах, используя JS.
Кластеры баз данных делаем сложные вещи просто / Андрей Тихонов (Avito)Ontico
Порой в процессе развития высоконагруженного проекта наступает момент, когда необходимо масштабирование. Возможно, ваш проект впервые упёрся в производительность железа (и таким образом перешёл в разряд высоконагруженных); возможно, это уже не первое масштабирование — не важно. Какие же проблемы могут возникнуть?
Во-первых, если вы увеличиваете количество бэкенд-серверов, и, соответственно, количество рабочих процессов, то с ростом количества одновременных клиентских подключений вырастают и накладные расходы на базах данных.
Во-вторых, достаточно быстро может кончиться ресурс in-memory баз данных. Потребуется создать (либо увеличить) кластер, а это каждый раз влечёт за собой необходимость модифицировать логику приложения.
В-третьих, чем больше серверов, тем больше вероятность, что один из них выйдет из строя. Поэтому неплохо задуматься о том, как обеспечить отказоустойчивость, а это, опять же, потребует модифицировать логику приложения.
В этом докладе я расскажу, как и какими инструментами можно легко решить все вышеперечисленные проблемы: уменьшить накладные расходы от большого количества подключений к базам данных, создать/модифицировать кластер БД прозрачно для приложения, а также прозрачно добавить устойчивость к падениям серверов БД.
План доклада:
- Введение. Методы масштабирования БД: репликация, шардирование.
- Создаём шардированные кластеры in-memory БД прозрачно для приложений: Twemproxy, Redis-proxy, Mcrouter.
- Уменьшаем накладные расходы от большого количества одновременных подключений на PostgreSQL с помощью PgBouncer.
- Создаём шардированный кластер PostgreSQL с помощью PL/Proxy.
- Добавляем прозрачную для приложения отказо�
1. Distributed Commit
Курс «Базы данных»
Цесько Вадим Александрович
http://incubos.org
@incubos
Computer Science Center
23 сентября 2013 г.
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
1 / 65
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. Distributed Commit
Two-Phase Commit Protocol
Фазы
Commit-request (voting)
Координатор пытается подготовить участников
транзакции
Каждый участник отвечает Yes или No
Commit
Координатор принимает решение на основе ответов
Все сказали Yes ⇒ commit, No ⇒ abort
Координатор отправляет решение участникам
Участники применяют решение
Предусловие
Если нет сбоев
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
4 / 65
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
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. Distributed Commit
Two-Phase Commit Protocol
Ограничения
Блокирующийся протокол
Если координатор исчезнет, то некоторые участники
могут не закончить транзакцию:
Участник отправил координатору Yes
Координатор упал
Участник ожидает commit или rollback
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
8 / 65
9. Distributed Commit
Two-Phase Commit Protocol
Поведение при сбоях
Пример ситуации:
Реплика выполнила commit и упала вместе с
координатором
Система не может восстановить результат
транзакции:
Только умершие 2 ноды знают точный результат
Pessimistic abort невозможен — упавшая реплика
могла сделать commit
Pessimistic commit невозможен — изначальное
решение могло быть abort
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
9 / 65
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
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. 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. 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. Happens-before
Lamport timestamps
Анализ
Невозможно точно синхронизировать время3
Если процессы не общаются, то между их
событиями нет отношения порядка
Обеспечивается лишь частичный порядок
3
Хотя см. http://research.google.com/archive/spanner.html
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
15 / 65
16. Happens-before
Vector clocks
Vector clocks
Цель
Ввести частичный порядок событий в
распределённой системе
Обнаружить нарушения причинно-следственных
связей
Определение
Векторные часы в системе с N процессами — это
массив N логических часов по одному на процесс
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
16 / 65
17. Happens-before
Vector clocks
Правила обновления массива часов
Изначально все часы выставлены в 0
При каждом событии процесс инкрементирует
свои логические часы на 1
Перед отправкой сообщения процесс:
Инкрементирует свои логические часы
Отправляет весь вектор вместе с сообщением
При получении сообщения процесс:
Инкрементирует свои логические часы
Обновляет свой вектор, беря покомпонентный
максимум с присланным вектором
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
17 / 65
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. 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
protocol 4 .
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. Raft
Введение
Ссылки
Replicated State Machines5
Ongaro D., Ousterhout J. In Search of an
Understandable Consensus Algorithm. 2013.
Diego Ongaro. Raft lecture 6 (Raft user study)
Diego Ongaro. Paxos lecture 7 (Raft user study)
Множество реализаций8
5
http://en.wikipedia.org/wiki/State_machine_replication
http://www.youtube.com/watch?v=YbZ3zDzDnrw
7
http://www.youtube.com/watch?v=JEpsBg0AO6o
8
https://ramcloud.stanford.edu/wiki/display/logcabin/LogCabin
6
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
21 / 65
22. Raft
Введение
Replicated State Machines
Работают на множестве узлов
Вычисляют идентичные копии одного и того же
состояния
Устойчивы к падению узлов
Реплицированный лог (последовательность
команд)
Решаемые задачи: выбор лидера, хранилище
конфигураций и др.
Примеры: Chubby (GFS), ZooKeeper in HDFS, ...
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
22 / 65
23. Raft
Введение
Особенности Raft
Strong Leader
Клиенты общаются только с лидером
Данные только от лидера к репликам
Leader Election
Cлучайные таймеры
Membership changes
Joint consensus
Формальна описана и доказана безопасность
Производительность на уровне аналогов
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
23 / 65
24. Raft
Введение
Алгоритм работы лидера
1
2
3
4
5
Получить команду от клиента
Добавить в локальный лог
Доставить команду другим узлам
При успехе применить команду к своему автомату
Вернуть ответ автомата клиенту
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
24 / 65
25. Raft
Введение
Свойства протокола
Безопасность: никогда не вернёт некорректный
результат
non-Byzantine fault tolerance9
Учитывает ненадёжную сеть
Доступность
Пока работают и могут общаться большинство узлов
Узлы останавливаются и снова подключаются
Независимость от абсолютного времени
Команда выполняется при ответе от
большинства — устойчивость к медленным узлам
9
http://en.wikipedia.org/wiki/Byzantine_fault_tolerance
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
25 / 65
27. Raft
Кластер
Кластер
Несколько узлов (3, 5, ...)
Узёл в одном из трёх состояний: leader, follower,
candidate
В нормальном режиме: 1 лидер и n − 1
последователей
Последователи пассивны: отвечают на RPC от
лидера и кандидатов
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
27 / 65
29. Raft
Кластер
Семестры
Время разбивается на семестры (terms)
неопределённой длины10
Семестры нумеруются последовательно
Каждый семестр начинается с выбора лидера
Если кандидат выигрывает выборы, то он служит
лидером до конца семестра
Если никто не победил на выборах, начинается
новый семестр
Инвариант
В каждом семестре не больше одного лидера
10
Аналог логических часов
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
29 / 65
31. Raft
Кластер
Обнаружение устаревшей информации
Каждый узел хранит текущий семестр
Текущий семестр каждый раз передаётся в
запросах
Если текущий семестр меньше пришедшего,
выбираем пришедший
Если кандидат или лидер — step down
Если пришедший семестр меньше текущего, то
отвергаем запрос
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
31 / 65
32. Raft
Кластер
RPC
RequestVote — кандидат просит отдать ему голос
AppendEntries — лидер реплицирует команды +
heartbeat
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
32 / 65
33. Raft
Выбор лидера
Условия запуска
Follower не получает heartbeat в течение election
timeout
Follower увеличивает текущий семестр
Переходит в состояние кандидата
Параллельно отправляет всем RequestVote
Перезапросы до получения ответа или окончания
выборов
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
33 / 65
34. Raft
Выбор лидера
Условия останова
Follower выиграл выборы (набрал большинство
голосов)
Каждый узел голосует единожды за семестр (FIFO)
Новый лидер начинает рассылать всем heartbeats
Другой узел стал лидером
Кандидат получил AppendEntries с семестром ≥
текущего
Кандидат переходит в состояние follower (step down)
Наступил таймаут, а победителя всё нет
Никто не набрал большинства голосов
Кандидат переходит в состояние follower (step down)
Random election timeout
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
34 / 65
36. Raft
Репликация лога
Committed Entry
Гарантируется, что будет выполнена всеми
автоматами
В простейшем случае — если подтверждена
запись большинством (см. записи 1-7)
Лидер пересылает индекс последнего коммита в
AppendEntries — followers коммитят
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
36 / 65
37. Raft
Репликация лога
Log Matching Property
Если у двух записей в разных логах совпадают индекс
и семестр, то:
Они содержат одинаковую команду
Лидер создаёт не больше одной записи с одним
индексом и семестром
Записи в логе не перемещаются
Логи идентичны во всех предшествующих записях
Лидер с AppendEntries пересылает индекс и семестр
предыдущей записи
Follower отвергает запрос, если не совпадает
Шаг индукции
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
37 / 65
39. Raft
Репликация лога
Пояснения
a-b — не хватает записей
c-d — лишние записи
e-f — оба случая
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
39 / 65
40. Raft
Репликация лога
Разрешение конфликтов
Замена конфликтов на followers записями лога
лидера
Лидер помнит nextIndex для каждого follower —
изначально следующий за последним в логе
Используется RPC AppendEntries Consistency
Check
Если ошибка, то nextIndex - 1 и retry
Если совпадение, то удаляется хвост и добавляются
записи лога лидера
Автоматическая сходимость логов
Лидер никогда не удаляет и не перезаписывает
записи в собственном логе
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
40 / 65
41. Raft
Корректность
Проблема
Лидер закоммитил несколько записей
Последователь был недоступен
Лидер ушёл с радаров
Последователь стал новым лидером
Последователь перезаписал всем логи
В результате разные автоматы выполнили разный
набор команд
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
41 / 65
42. Raft
Корректность
Решение
Расширим протокол:
Ограничение на узлы, которые могут стать
лидером
Ограничение на записи, которые считаются
закоммичеными
Обеспечиваем:
Лидер любого семестра содержит все записи,
закоммиченые в предыдущих семестрах
Записи направлены только от лидера к
последователям
Лидеры никогда не перезатирают записи в своём
логе
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
42 / 65
43. Raft
Корректность
Ограничение на выбор лидера
Всё так же нужно собрать голоса большинства
Но можно стать лидером, только если наш лог не
менее свежий, чем у каждого голосующего
RequestVote RPC содержит информацию о
последней записи в логе
Лог новее, если семестр старше или индекс
больше (лог длиннее)
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
43 / 65
45. Raft
Корректность
Случай 1
Наиболее популярный
Лидер реплицирует запись из текущего семестра
Запись закоммичена, как только подтвердит
большинство
Лидером могут стать только те, у кого есть эта
запись
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
45 / 65
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. 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. 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. Raft
Изменение конфигурации кластера
Изменение конфигурации кластера
Предполагали, что состав узлов статичен
Но иногда нужно заменять сервера или изменять
уровень репликации
В идеале — без downtime
И автоматически — исключить человеческий
фактор
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
50 / 65
52. Raft
Изменение конфигурации кластера
Проблема
Проблема
Возможно одновременное существование двух лидеров
для одного семестра в двух подкластерах
Решения:
2PC: сначала выключаем старую конфигурацию,
возможен downtime
Raft: промежуточная конфигурация (joint
consensus)
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
52 / 65
53. Raft
Изменение конфигурации кластера
Идея
Комбинация двух конфигураций:
Записи реплицируются серверам в обеих
конфигурациях
Сервер из любой конфигурации может стать
лидером
Нужно собрать большинство в каждой
конфигурации по-отдельности
При этом без downtime
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
53 / 65
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. Raft
Изменение конфигурации кластера
Особенности
Если лидер входит в Cold , но не в Cnew , то должен
выйти из кластера (реплицирует, но не входит в
большинство)
Новые сервера могут быть пустыми — вначале
добавляем как неголосующих, но реплицируем на
них логи
Удаление серверов, которые не в курсе, что их
удаляют, может снизить производительность
кластера — инициируют безнадёжные выборы
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
56 / 65
57. Raft
Оптимизации
Log Compaction
Подходы:
Очистка логов — перемещаем «живые» записи в
голову и очищаем мёртвый хвост
Инкрементально и эффективно
Определение живых записей может быть сложным
Слепки — состояние системы периодически
сохраняется на stable storage, а лог сбрасывается
Менее эффективно (неинкрементально)
Просто
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
57 / 65
59. Raft
Оптимизации
Snapshotting: Нюансы
Нужно решить, когда создавать слепки —
например, при достижении логом определённого
размера
Copy-on-write для асинхронной записи слепков +
functional data structures/fork()
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
59 / 65
60. Raft
Клиент
Проблема
Команда может применяться несколько раз
Лидер получил команду, закоммитил и умер, не
успев ответить
Клиент делает перезапрос
Идемпотентность
Клиент присваивает командам уникальные
последовательные номера
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
60 / 65
61. Raft
Клиент
Проблема
Протухшее чтение
У лидера есть все закоммиченые изменения
Но в начале семестра он не знает, кто из них
закоммичен
Вначале он должен закоммитить запись из нового
семестра
Решение
no-op в начале семестра
Heartbeat с большинством кластера перед ответом
на read
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
61 / 65
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. Заключение
Библиотечка
Библиотечка
Think Distributed: A Distributed Systems Podcast13
Наборы открытых данных для курсовой работы14
13
14
http://thinkdistributed.io/
Via @pulser: http://www.hackathon.spb.ru/#!datasets/c1miv
Цесько В. А. (CompSciCenter)
Distributed Commit
23 сентября 2013 г.
63 / 65
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