Вторая лекция раздела NoSQL курса "Базы данных" в Технополисе.
Содержание: CAP теорема, распределённые транзакции, отношение happens-before, протокол Raft.
Anton Turetckii "What does it take to build a host?"Fwdays
Real hardware in the data center: everything you wanted to know but didn’t know how to ask.
2020: how to build a server if you don’t use clouds
How to get rid of or reduce problems when ordering, allocating, and mounting the hardware
Yes, there are people working in your data center (If you have one)!
What is hidden in between the server’s power button activation and its appearance in your internal system
Automation and its role in the process: do exactly what is necessary and enough!
Архитектура растущего проекта на примере ВКонтакте / Алексей Акулович (ВКонт...Ontico
В докладе я расскажу о проблемах роста, с которыми сталкивался проект как в плане доступа к БД, так и в целом. Как решали, что получалось, как (общетеоретически или практически) можно решать подобные проблемы в других проектах.
Разберем несколько реальных случаев, когда что-то шло не так.
Доклад можно рассматривать и как небольшой экскурс в развитие технической платформы ВК, и как собрание нескольких практических способов для проекта вырасти и стать надежнее.
Первая лекция раздела NoSQL курса "Базы данных" в Технополисе: определения и примеры, классификация СУДБ, что значит Web Scale, hashing, caching, key-value хранилища.
Anton Turetckii "What does it take to build a host?"Fwdays
Real hardware in the data center: everything you wanted to know but didn’t know how to ask.
2020: how to build a server if you don’t use clouds
How to get rid of or reduce problems when ordering, allocating, and mounting the hardware
Yes, there are people working in your data center (If you have one)!
What is hidden in between the server’s power button activation and its appearance in your internal system
Automation and its role in the process: do exactly what is necessary and enough!
Архитектура растущего проекта на примере ВКонтакте / Алексей Акулович (ВКонт...Ontico
В докладе я расскажу о проблемах роста, с которыми сталкивался проект как в плане доступа к БД, так и в целом. Как решали, что получалось, как (общетеоретически или практически) можно решать подобные проблемы в других проектах.
Разберем несколько реальных случаев, когда что-то шло не так.
Доклад можно рассматривать и как небольшой экскурс в развитие технической платформы ВК, и как собрание нескольких практических способов для проекта вырасти и стать надежнее.
Первая лекция раздела NoSQL курса "Базы данных" в Технополисе: определения и примеры, классификация СУДБ, что значит Web Scale, hashing, caching, key-value хранилища.
Alexandr Serbul "The Rust language for a high-load network service - a quick ...Fwdays
In this talk, we will talk about the evolution of the development of a high-load network cluster for sending push notifications using technologies from Unix / bash and PHP to asynchronous non-blocking multithreaded connections based on Rust / Tokio. Let's talk about the intricacies of Rust development, language features, pitfalls, and ways to quickly learn and use it for web developers with LAMP skills. Let's also talk about Go, Java, and the reasons for our technological decisions.
The talk will be useful for developers wishing to master the latest and popular Rust programming language, functional programming, Haskell ideas with PHP / Python / JavaScript web development experience.
Оптимизация high-contention write в PostgreSQL / Александр Коротков, Олег Бар...Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 7 ноября, 11:00
Тезисы:
http://www.highload.ru/2017/abstracts/3030.html
Оптимизация производительности – дело тонкое. Улучшая производительность системы при одной нагрузке, можно запросто ухудшить её при другой нагрузке. Основным мерилом производительности PostgreSQL в среде его разработчиков является pgbench. Как следствие, PostgreSQL стал "pgbench-optimized DBMS" (СУБД, оптимизированная для pgbench).
...
Девять кругов ада или PostgreSQL Vacuum / Алексей Лесовский (PostgreSQL-Consu...Ontico
Если вы сталкивались с PostgreSQL и зашли дальше, чем инструкция по установке, то, скорей всего, коротко познакомились с вакуумом, ну или, как минимум, что-то слышали про него.
Вакуум или по-русски очистка - это важная задача в жизненном цикле постгреса, которая заключается в регулярном освобождении базы данных от, так скажем, "мусора". Вакуум очень важен, его нельзя игнорировать и тем более отключать; более того, ему следует уделять должное внимание. А за кажущейся простотой скрывается довольно сложный и интересный механизм, к работе которого очень часто возникает много вопросов, на которые не всегда можно найти однозначный ответ.
В этом докладе я буду рассказывать про внутреннее устройство вакуума и раскрою следующие вопросы:
1) Что такое автовакуум (вакуум) и заморозка, и как они устроены изнутри.
2) Какие решения принимаются в процессе обработки таблиц и индексов.
3) Какие существуют возможности для управления вакуумом и как эти возможности влияют на работу вакуума.
4) Вакуум и вопрос производительности.
Внутреннее устройство PostgreSQL: временные таблицы и фрагментация памяти / Г...Ontico
Всем известно о существовании временных таблиц в PostgreSQL, но как они устроены, и чем грозит их некорректное использование - не столь очевидно.
На примере одного известного приложения, активно и некорректно использующего временные таблицы, мы расскажем о создаваемой ими проблеме фрагментации памяти.
Что такое фрагментация памяти, по каким признакам можно определить ее наличие, чем она грозит, почему она возникает при активном использовании временных таблиц, и как мы пропатчили PostgreSQL, чтобы ее избежать - обо всем этом можно узнать из нашего доклада.
Хранение данных на виниле / Константин Осипов (tarantool.org)Ontico
В rfc1149 дан исчерпывающий обзор преимуществ голубиной почты для протокола IP: низкая пропускная способность, невысокая надёжность, простая топология сети. Для того чтобы дать адекватный ответ вызовам эпохи мемристоров и квантовых вычислений, Tarantool 1.7 содержит новый движок для хранения данных на классических жёстких дисках и флэш-накопителях: Vinyl. Tarantool известен своей скоростью, и мы постарались не ударить в грязь лицом и на этот раз.
В докладе я расскажу об устройстве нашего нового storage engine:
- как мы объединили in-memory технологию и LSM (log structured merge) деревья для достижения оптимальной производительности и утилизации ресурса накопителя,
- как работает multiversion concurrency control в Vinyl,
- основной компонент в промышленной реализации LSM дерева - merge scheduler, т.е. планировщик слияний и сборки мусора дерева. Я расскажу о подходе, который позволяет максимально снизить износ накопителя, при этом уложиться в заданные рамки производительности запросов.
5 способов деплоя PHP-кода в условиях хайлоада / Юрий Насретдинов (Badoo)Ontico
В дата-центрах нашей компании несколько тысяч серверов, и примерно на половине из них нужно выкладывать PHP-код 2 раза в день. Помимо раскладки на production также не стоит забывать о том, что код нужен на стейджинге, и в стейджинг-кластер у нас входит около 50 машин, код на которых обновляется раз в несколько минут. Также есть «хотфиксы» — небольшие (1-5) наборы файлов, которые выкладываются во внеочередном порядке на все или на выделенную часть серверов, чтобы устранить существующие проблемы на продакшне, не дожидаясь полной выкладки.
В этом докладе я расскажу о том, как мы деплоились в течение 10 лет, о том, какую новую систему для деплоя PHP-кода мы разработали и внедрили в production, а также проведу обзор решений для масштабного деплоя кода на PHP и анализ их производительности.
План доклада:
— Наша старая система деплоя, достоинства и недостатки.
— Существующие решения:
* "svn up" / "git pull".
* rsync.
* phar, hhbc (HHVM-specific), "loop".
* rsync + 2 директории + realpath_root (Rasmus-style).
— Требования для новой системы деплоя.
* быстрый деплой на стейджинг (5-10 секунд на 50 серверов).
* возможность атомарно патчить несколько файлов и быстро их выкладывать (10 секунд на весь кластер).
* совместимость с docker.
* поддержка «долгоиграющих» CLI-скриптов (несколько часов).
* низкое потребление ресурсов на принимающей стороне.
* отсутствие необходимости сбрасывать opcache.
* высокая скорость деплоя на продакшн (1-2 минуты на 1500 серверов).
— MDK — multiversion deployment kit.
— Анализ применимости и производительности способов деплоя.
— Выводы.
Yevgen Lysenko "AWS RDS Aurora Serverless, ECS Fargate and more serverless-pr...Fwdays
Marketing materials and documentation of AWS and other cloud providers do present their Serverless-services as a future of cloud computing, that ought to solve nearly all current problems. Is that so? Is there something marketers and documentation are hiding from us? What are costs and productivity?
Раздатчик музыки непосредственно занимается отдачей байтов аудиопотока многочисленным пользователям https://ok.ru/music. В пике суммарный трафик достигает 100 Гб/с через сотни тысяч соединений, а время до первого байта составляет не больше 100 мс. Предыдущая версия раздатчика на основе файлов и Apache Tomcat не устраивала нас требуемым количеством оборудования и неспособностью утилизировать современное железо. При разработке новой версии мы поставили перед собой цель сохранить внешнюю функциональность сервиса неизменной, но обойтись существенно меньшим количеством машин, сохранив при этом масштабируемость и отказоустойчивость сервиса.
В докладе мы рассмотрим, как различные архитектурные решения помогли нам обеспечить масштабируемость и отказоустойчивость сервиса за счёт распределения и репликации музыкальных треков между нодами. Затем подробно поговорим про устройство отдельной ноды, включая отказоустойчивую подсистему хранения, сетевую подсистему, а также использование подхода reactive streams. Уделим особое внимание собранным граблям и трюкам, позволившим увеличить производительность системы, упростить отладку и эксплуатацию системы.
Доклад ориентирован на разработчиков, которые хотят расширить свой арсенал подходов и инструментов для создания распределённых и/или высоконагруженных систем с интенсивным I/O.
Что нового в nginx? / Максим Дунин (Nginx, Inc.)Ontico
Что нового появилось в nginx за последнее время и для чего всё это нужно?
В докладе - рассказ про основные новые функции в nginx 1.9.x (1.10.x) и 1.11.x. HTTP/2, модуль stream, динамическая загрузка модулей и так далее - зачем всё это нужно и как это использовать.
Читаем CHANGES вместе и разбираем на примерах.
noBackend, или Как выжить в эпоху толстеющих клиентов / Самохвалов НиколайOntico
Набирает обороты мода на парадигму noBackend (см., например, http://nobackend.org/). Название не стоит понимать буквально: backend никуда не делся, просто фокус разработки — особенно на начальном этапе развития нового проекта — сильно смещается в сторону «клиентской части». Это очень понятно и закономерно в эпоху Mobile First и React Ecosystem с её новомодными GraphQL и React Native.
Появляется большой соблазн взять что-то понятное для хранения данных и уже «обвязанное» REST API, максимально отказаться от PHP/Python/Ruby/Java/etc, писать 80% кода «на стороне клиента», минимально заботясь о возне «на стороне сервера». У некоторых возникает и настоящая эйфория — чувство приятное, но очень опасное (прежде всего, если в команде нет сильного backend-опыта).
Этот доклад — компиляция опыта ряда проектов, написанных на React, React Native и Swift и переходящих на парадигму (или же сразу стартанувших с неё) noBackend за счёт PostgreSQL+PostgREST.
Мы обсудим важные вопросы, которые обязан задавать себе каждый, выбравший noBackend-подход (и не обязательно на связке Postgres+PostgREST): безопасность (аутентификация/авторизация; ограничение чтения и — особенно! — модификации «чужих» данных), производительность (нетривиальные запросы а-ля «свежий контент от тех, на кого я подписан»; компромисс между сетевой сложностью и CPU; защита от «домашнего» ddos — ситуации, когда свои же, родные «фронтендеры» кладут «бэкэнд»), масштабируемость и асинхронная обработка задач.
Задача-минимум (для всех): у каждого слушателя остаётся список must-check-вопросов для работы с noBackend-подходом.
Задача-максимум (для тех, кто с Postgres-опытом): разворачивание безопасного, высокопроизводительного и годного для быстрого развития REST API — сегодня же, в день док
Что особенного в СУБД для данных в оперативной памяти / Константин Осипов (Ta...Ontico
Оперативная память становится всё более дешёвой и производительной, что позволяет использовать её для хранения рабочего набора данных всё большего числа приложений. Хранение всех данных в оперативной памяти позволяет сделать их высоко доступными, а алгоритмы для работы с данными либо существенно упростить, либо ускорить, а иногда — и то, и другое.
Тезисы - http://www.highload.ru/2015/abstracts/1964.html
Хайлоад и безопасность в мире DevOps: совместимы ли? / Юрий Колесов (security...Ontico
* Поговорим о рисках, подстерегающих как стартапы, так и устоявшиеся компании, отсортировав их по степени важности.
* Рассмотрим особенности cloud vs bare metal в контексте безопасности.
* Подискутируем о технических методах обеспечения безопасности, постараемся внедрить безопасность не в ущерб хайлоаду.
* Будут примеры как из моей практики, так и показательные из общемировой.
«Секретные» технологии инвестиционных банков / Алексей Рагозин (Дойче Банк)Ontico
Как правило, такое базовое ПО, как языки программирования, системы управления базами данных, брокеры сообщений, используется в разных индустриях и не имеет ярко выраженной бизнес-специализации. Java, Python, MySQL и не только находят применение повсюду, начиная с больших корпораций, заканчивая стратапами и видеоиграми.
Тем не менее, встречаются исключения. В докладе пойдёт речь о технологиях, получивших распространение в инвестиционных банках и не слишком известных за их пределами. Хотя прямого отношения к торговле финансовыми инструментами сами по себе эти технологии не имеют.
Тезисы - http://www.highload.ru/2015/abstracts/1888.html
Flashcache в mamba.ru / Яковлев Александр Юрьевич (ЗАО Мамба)Ontico
Некоторое время назад, когда в очередной раз встал вопрос о производительности большого парка mysql sharding серверов, мы не захотели покупать новые сервера и производить resharding. Мы обнаружили, что компания facebook выпустила в opensource большое количество своих разработок, в том числе и модуль ядра flashcache.
Flashcache — модуль для кэширования блоков блочного устройства, предоставляющий 4 разных режима кэширования.
В данном докладе я расскажу, как мы тестировали, поэтапно проверяя под нагрузкой, 3 из 4 режимов кэширования, сравнивая и выбирая оптимальный. Итогом данной работы стало внедрение данного модуля в нашу архитектуру (фотосервера, сервера БД).
Introduction to MySQL high availability technology: InnoDB Cluster. How to set up a cluster in minutes which will be automatically handling failover and conflicts. Slides in Russian
Модным ныне словом «виртуализация» сейчас называют различные обёртки аппаратной виртуализации, однако этот термин намного старше и более всеохватывающий. На уровне ознакомления с технологией мы поговорим о виртуализации ресурсов в кластере и на примере pacemaker.
Alexandr Serbul "The Rust language for a high-load network service - a quick ...Fwdays
In this talk, we will talk about the evolution of the development of a high-load network cluster for sending push notifications using technologies from Unix / bash and PHP to asynchronous non-blocking multithreaded connections based on Rust / Tokio. Let's talk about the intricacies of Rust development, language features, pitfalls, and ways to quickly learn and use it for web developers with LAMP skills. Let's also talk about Go, Java, and the reasons for our technological decisions.
The talk will be useful for developers wishing to master the latest and popular Rust programming language, functional programming, Haskell ideas with PHP / Python / JavaScript web development experience.
Оптимизация high-contention write в PostgreSQL / Александр Коротков, Олег Бар...Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 7 ноября, 11:00
Тезисы:
http://www.highload.ru/2017/abstracts/3030.html
Оптимизация производительности – дело тонкое. Улучшая производительность системы при одной нагрузке, можно запросто ухудшить её при другой нагрузке. Основным мерилом производительности PostgreSQL в среде его разработчиков является pgbench. Как следствие, PostgreSQL стал "pgbench-optimized DBMS" (СУБД, оптимизированная для pgbench).
...
Девять кругов ада или PostgreSQL Vacuum / Алексей Лесовский (PostgreSQL-Consu...Ontico
Если вы сталкивались с PostgreSQL и зашли дальше, чем инструкция по установке, то, скорей всего, коротко познакомились с вакуумом, ну или, как минимум, что-то слышали про него.
Вакуум или по-русски очистка - это важная задача в жизненном цикле постгреса, которая заключается в регулярном освобождении базы данных от, так скажем, "мусора". Вакуум очень важен, его нельзя игнорировать и тем более отключать; более того, ему следует уделять должное внимание. А за кажущейся простотой скрывается довольно сложный и интересный механизм, к работе которого очень часто возникает много вопросов, на которые не всегда можно найти однозначный ответ.
В этом докладе я буду рассказывать про внутреннее устройство вакуума и раскрою следующие вопросы:
1) Что такое автовакуум (вакуум) и заморозка, и как они устроены изнутри.
2) Какие решения принимаются в процессе обработки таблиц и индексов.
3) Какие существуют возможности для управления вакуумом и как эти возможности влияют на работу вакуума.
4) Вакуум и вопрос производительности.
Внутреннее устройство PostgreSQL: временные таблицы и фрагментация памяти / Г...Ontico
Всем известно о существовании временных таблиц в PostgreSQL, но как они устроены, и чем грозит их некорректное использование - не столь очевидно.
На примере одного известного приложения, активно и некорректно использующего временные таблицы, мы расскажем о создаваемой ими проблеме фрагментации памяти.
Что такое фрагментация памяти, по каким признакам можно определить ее наличие, чем она грозит, почему она возникает при активном использовании временных таблиц, и как мы пропатчили PostgreSQL, чтобы ее избежать - обо всем этом можно узнать из нашего доклада.
Хранение данных на виниле / Константин Осипов (tarantool.org)Ontico
В rfc1149 дан исчерпывающий обзор преимуществ голубиной почты для протокола IP: низкая пропускная способность, невысокая надёжность, простая топология сети. Для того чтобы дать адекватный ответ вызовам эпохи мемристоров и квантовых вычислений, Tarantool 1.7 содержит новый движок для хранения данных на классических жёстких дисках и флэш-накопителях: Vinyl. Tarantool известен своей скоростью, и мы постарались не ударить в грязь лицом и на этот раз.
В докладе я расскажу об устройстве нашего нового storage engine:
- как мы объединили in-memory технологию и LSM (log structured merge) деревья для достижения оптимальной производительности и утилизации ресурса накопителя,
- как работает multiversion concurrency control в Vinyl,
- основной компонент в промышленной реализации LSM дерева - merge scheduler, т.е. планировщик слияний и сборки мусора дерева. Я расскажу о подходе, который позволяет максимально снизить износ накопителя, при этом уложиться в заданные рамки производительности запросов.
5 способов деплоя PHP-кода в условиях хайлоада / Юрий Насретдинов (Badoo)Ontico
В дата-центрах нашей компании несколько тысяч серверов, и примерно на половине из них нужно выкладывать PHP-код 2 раза в день. Помимо раскладки на production также не стоит забывать о том, что код нужен на стейджинге, и в стейджинг-кластер у нас входит около 50 машин, код на которых обновляется раз в несколько минут. Также есть «хотфиксы» — небольшие (1-5) наборы файлов, которые выкладываются во внеочередном порядке на все или на выделенную часть серверов, чтобы устранить существующие проблемы на продакшне, не дожидаясь полной выкладки.
В этом докладе я расскажу о том, как мы деплоились в течение 10 лет, о том, какую новую систему для деплоя PHP-кода мы разработали и внедрили в production, а также проведу обзор решений для масштабного деплоя кода на PHP и анализ их производительности.
План доклада:
— Наша старая система деплоя, достоинства и недостатки.
— Существующие решения:
* "svn up" / "git pull".
* rsync.
* phar, hhbc (HHVM-specific), "loop".
* rsync + 2 директории + realpath_root (Rasmus-style).
— Требования для новой системы деплоя.
* быстрый деплой на стейджинг (5-10 секунд на 50 серверов).
* возможность атомарно патчить несколько файлов и быстро их выкладывать (10 секунд на весь кластер).
* совместимость с docker.
* поддержка «долгоиграющих» CLI-скриптов (несколько часов).
* низкое потребление ресурсов на принимающей стороне.
* отсутствие необходимости сбрасывать opcache.
* высокая скорость деплоя на продакшн (1-2 минуты на 1500 серверов).
— MDK — multiversion deployment kit.
— Анализ применимости и производительности способов деплоя.
— Выводы.
Yevgen Lysenko "AWS RDS Aurora Serverless, ECS Fargate and more serverless-pr...Fwdays
Marketing materials and documentation of AWS and other cloud providers do present their Serverless-services as a future of cloud computing, that ought to solve nearly all current problems. Is that so? Is there something marketers and documentation are hiding from us? What are costs and productivity?
Раздатчик музыки непосредственно занимается отдачей байтов аудиопотока многочисленным пользователям https://ok.ru/music. В пике суммарный трафик достигает 100 Гб/с через сотни тысяч соединений, а время до первого байта составляет не больше 100 мс. Предыдущая версия раздатчика на основе файлов и Apache Tomcat не устраивала нас требуемым количеством оборудования и неспособностью утилизировать современное железо. При разработке новой версии мы поставили перед собой цель сохранить внешнюю функциональность сервиса неизменной, но обойтись существенно меньшим количеством машин, сохранив при этом масштабируемость и отказоустойчивость сервиса.
В докладе мы рассмотрим, как различные архитектурные решения помогли нам обеспечить масштабируемость и отказоустойчивость сервиса за счёт распределения и репликации музыкальных треков между нодами. Затем подробно поговорим про устройство отдельной ноды, включая отказоустойчивую подсистему хранения, сетевую подсистему, а также использование подхода reactive streams. Уделим особое внимание собранным граблям и трюкам, позволившим увеличить производительность системы, упростить отладку и эксплуатацию системы.
Доклад ориентирован на разработчиков, которые хотят расширить свой арсенал подходов и инструментов для создания распределённых и/или высоконагруженных систем с интенсивным I/O.
Что нового в nginx? / Максим Дунин (Nginx, Inc.)Ontico
Что нового появилось в nginx за последнее время и для чего всё это нужно?
В докладе - рассказ про основные новые функции в nginx 1.9.x (1.10.x) и 1.11.x. HTTP/2, модуль stream, динамическая загрузка модулей и так далее - зачем всё это нужно и как это использовать.
Читаем CHANGES вместе и разбираем на примерах.
noBackend, или Как выжить в эпоху толстеющих клиентов / Самохвалов НиколайOntico
Набирает обороты мода на парадигму noBackend (см., например, http://nobackend.org/). Название не стоит понимать буквально: backend никуда не делся, просто фокус разработки — особенно на начальном этапе развития нового проекта — сильно смещается в сторону «клиентской части». Это очень понятно и закономерно в эпоху Mobile First и React Ecosystem с её новомодными GraphQL и React Native.
Появляется большой соблазн взять что-то понятное для хранения данных и уже «обвязанное» REST API, максимально отказаться от PHP/Python/Ruby/Java/etc, писать 80% кода «на стороне клиента», минимально заботясь о возне «на стороне сервера». У некоторых возникает и настоящая эйфория — чувство приятное, но очень опасное (прежде всего, если в команде нет сильного backend-опыта).
Этот доклад — компиляция опыта ряда проектов, написанных на React, React Native и Swift и переходящих на парадигму (или же сразу стартанувших с неё) noBackend за счёт PostgreSQL+PostgREST.
Мы обсудим важные вопросы, которые обязан задавать себе каждый, выбравший noBackend-подход (и не обязательно на связке Postgres+PostgREST): безопасность (аутентификация/авторизация; ограничение чтения и — особенно! — модификации «чужих» данных), производительность (нетривиальные запросы а-ля «свежий контент от тех, на кого я подписан»; компромисс между сетевой сложностью и CPU; защита от «домашнего» ddos — ситуации, когда свои же, родные «фронтендеры» кладут «бэкэнд»), масштабируемость и асинхронная обработка задач.
Задача-минимум (для всех): у каждого слушателя остаётся список must-check-вопросов для работы с noBackend-подходом.
Задача-максимум (для тех, кто с Postgres-опытом): разворачивание безопасного, высокопроизводительного и годного для быстрого развития REST API — сегодня же, в день док
Что особенного в СУБД для данных в оперативной памяти / Константин Осипов (Ta...Ontico
Оперативная память становится всё более дешёвой и производительной, что позволяет использовать её для хранения рабочего набора данных всё большего числа приложений. Хранение всех данных в оперативной памяти позволяет сделать их высоко доступными, а алгоритмы для работы с данными либо существенно упростить, либо ускорить, а иногда — и то, и другое.
Тезисы - http://www.highload.ru/2015/abstracts/1964.html
Хайлоад и безопасность в мире DevOps: совместимы ли? / Юрий Колесов (security...Ontico
* Поговорим о рисках, подстерегающих как стартапы, так и устоявшиеся компании, отсортировав их по степени важности.
* Рассмотрим особенности cloud vs bare metal в контексте безопасности.
* Подискутируем о технических методах обеспечения безопасности, постараемся внедрить безопасность не в ущерб хайлоаду.
* Будут примеры как из моей практики, так и показательные из общемировой.
«Секретные» технологии инвестиционных банков / Алексей Рагозин (Дойче Банк)Ontico
Как правило, такое базовое ПО, как языки программирования, системы управления базами данных, брокеры сообщений, используется в разных индустриях и не имеет ярко выраженной бизнес-специализации. Java, Python, MySQL и не только находят применение повсюду, начиная с больших корпораций, заканчивая стратапами и видеоиграми.
Тем не менее, встречаются исключения. В докладе пойдёт речь о технологиях, получивших распространение в инвестиционных банках и не слишком известных за их пределами. Хотя прямого отношения к торговле финансовыми инструментами сами по себе эти технологии не имеют.
Тезисы - http://www.highload.ru/2015/abstracts/1888.html
Flashcache в mamba.ru / Яковлев Александр Юрьевич (ЗАО Мамба)Ontico
Некоторое время назад, когда в очередной раз встал вопрос о производительности большого парка mysql sharding серверов, мы не захотели покупать новые сервера и производить resharding. Мы обнаружили, что компания facebook выпустила в opensource большое количество своих разработок, в том числе и модуль ядра flashcache.
Flashcache — модуль для кэширования блоков блочного устройства, предоставляющий 4 разных режима кэширования.
В данном докладе я расскажу, как мы тестировали, поэтапно проверяя под нагрузкой, 3 из 4 режимов кэширования, сравнивая и выбирая оптимальный. Итогом данной работы стало внедрение данного модуля в нашу архитектуру (фотосервера, сервера БД).
Introduction to MySQL high availability technology: InnoDB Cluster. How to set up a cluster in minutes which will be automatically handling failover and conflicts. Slides in Russian
Модным ныне словом «виртуализация» сейчас называют различные обёртки аппаратной виртуализации, однако этот термин намного старше и более всеохватывающий. На уровне ознакомления с технологией мы поговорим о виртуализации ресурсов в кластере и на примере pacemaker.
Pconnect: граната в руках обезьяны. Сергей Аверин, Badoo.
Persistent connect. Это всегда преподносится как plug'n'play. В учебниках информации очень мало. Но все всегда думают, что это «просто работает».
- Что это, вообще, такое, зачем было придумано и какие задачи призвано решать.
- О том, как этим всем пользуются, и что получается в итоге.
- О том, как, на самом деле, это работает. Про что не пишут в учебниках.
- Stateful-протоколы, пример с проблемами в mysql.
- В stateless-мире все не так уж солнечно.
- Большинство протоколов просто не рассчитано на pconnect. Баги в C++ софте (которые есть всегда) + pconnect + простоватый протокол = адская смесь. Каким должен быть протокол.
- Мелкие нюансы, из-за которых возникают проблемы.
- Connection pooling — что это и с чем его едят.
- Как со всем этим жить.
Ukraine, Kharkiv, Jave Club. (Day 2)
In this presentation you can find the brief overview of Clloud Computing development vs. desktop app. development. This presentation oriented to persons with general level of knowledge in such topics as:
Amazon AWS, cloud computing, CAP theorem, logical time.
1. CAP. Распределённый сommit.
«Использование баз данных»
Цесько Вадим Александрович
https://incubos.org
@incubos
10 мая 2017 г.
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 1 / 86
2. Содержание
1 Remembrance Inc.
2 CAP theorem
3 Транзакции
4 Distributed Commit
5 Happens-before
6 Raft
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 2 / 86
3. Remembrance Inc. Идея сервиса
Идея сервиса
Never forget, even without remembering!a
a
http:
//ksat.me/a-plain-english-introduction-to-cap-theorem/
Ever felt bad that you forget so much? Don’t worry. Help
is just a phone away!
When you need to remember something, just call
555-55-REMEM and tell us what you need to remember.
For eg., call us and let us know of your boss’s phone
number and forget to remember it. When you need to
know it back, call back the same number 555-55-REMEM
and we’ll tell you what’s your boss’s phone number.
Charges: only $0.1 per request
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 3 / 86
4. Remembrance Inc. Типичный диалог
Типичный диалог
Customer: Hey, can you store my neighbor’s
birthday?
You: Sure... When is it?
Customer: 2nd of Jan
You: (write it down against the customer’s page in
your paper note book) Stored. Call us any time for
knowing your neighbor’s birthday again!
Customer: Thank you!
You: No problem! We charged your credit card with
$0.1
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 4 / 86
5. Remembrance Inc. Растёт нагрузка
Растёт нагрузка
Нужен только блокнот и телефон
Отлично работает
Сарафанное радио
Получили финансирование от YCombinator
Сотни звонков в день
Проблемы подхода
Клиенты висят в очереди на телефоне и злятся
Вы заболели и пропустили рабочий день и день
оповещений
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 5 / 86
6. Remembrance Inc. Масштабируемся
Масштабируемся
Берём жену в долю
У каждого добавочный номер
Клиенты используют всё тот же 555–55-REMEM
АТС балансирует клиентов между сотрудниками
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 6 / 86
7. Remembrance Inc. Проблема
Проблема
Customer: Hey!
You: Glad you called “Remembrance Inc!”. What can
I do for you?
Customer: Can you tell me when is my flight to New
Delhi?
You: Sure... 1 sec, sir. (You look up your notebook.
WOW! There is no entry for "flight date"in
customer’s page!!!)
You: Sir, I think there is a mistake. You never told us
about your flight to Delhi.
Customer: What?! I just called you guys yesterday!
(Cuts the call!)
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 7 / 86
8. Remembrance Inc. Чиним неконсистентность
Чиним неконсистентность
Перед тем как записать что-либо, говорим
партнёру
Таким образом, обновления хранятся у нас обоих
Когда клиент спрашивает, то вся информация под
рукой
Проблемы подхода
Дольше операции обновления, но операций
чтения большинство
Если кто-то из нас заболеет — проблема
недоступности
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 8 / 86
9. Remembrance Inc. Consistent & Available
Consistent & Available
Новая версия алгоритма:
Перед записью говорим партнёру
Партнёр недоступен — отправляем ему email
В начале рабочего дня разбираем почту и
обновляем блокнот
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 9 / 86
10. Remembrance Inc. Partition Tolerance
Partition Tolerance
Жена обиделась, всё-таки пришла на работу, но
решила не сообщать об обновлениях
Можно реализовать partition tolerance, если
решить не принимать запросы, пока не
восстановится связность с женой
Но тогда жертвуем availability
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 10 / 86
11. CAP theorem
CAP theorem
E. Brewer. Towards Robust Distributed Systems, 2000.
Суть
Выберите 2 из 3:
Consistency
Availability
Partition Tolerance
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 11 / 86
12. CAP theorem Пояснения
Пояснения
На самом деле1
:
Невозможность полного обеспечения C, A и P
P in a distributed system is a MUST HAVE
Партиции относительно редки — необязательно
жертвовать C/A при их отсутствии
Выбор различного соотношения C/A для разных
подсистем, запросов, данных, пользователей и т. д.
Свойства непрерывны, а не бинарны
1
http://www.infoq.com/articles/
cap-twelve-years-later-how-the-rules-have-changed
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 12 / 86
13. CAP theorem Latency
Latency
CAP проявляется во время таймаута:
Отменить операцию = снизить доступность
Подтвердить операцию = снизить консистентность
Перезапрос = отложить решение
Бесконечный перезапрос = выбираем
консистентность
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 13 / 86
14. CAP theorem Обработка партиций
Обработка партиций
Обнаружение партиционирования
Не все узлы могут признать партиционирование
Можно подбирать таймауты ⇒ false positives
Ограничение набора возможных
операций/снижение консистентности
Можно запомнить и «отложить» операцию
Yahoo PNUTS: локальный мастер per user +
асинхронная репликация ⇒ меньше задержки
Facebook2
: мастер всегда один, запись в удалённый
мастер и чтение 20 сек из мастера, затем из
локальной реплики
Восстановление консистентности и устранение
ошибок
2
http:
//www.facebook.com/note.php?note_id=23844338919&id=9445547199
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 14 / 86
16. CAP theorem Трюки
Трюки
Вся система недоступна — есть, например,
HTML5 on-client persistent storage
Различные области консистентности при
партициях (primary partition, quorum)
Шардирование
Нет глобальных инвариантов
Но возможен прогресс даже при партициях
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 16 / 86
17. CAP theorem Восстановление консистентности
Восстановление консистентности
Нужно знать инварианты (не всегда очевидно)
Почти то же, что параллельные обновления в
многопоточном программировании
Векторные часы для обнаружения конфликтов
Откат ошибок (желательно иметь лог операций —
см. DVCS)
Commutative Replicated Data Types (CRDTs)34
3
M. Shapiro et al. Conflict-Free Replicated Data Types. 2011
4
M. Shapiro et al. Convergent and Commutative Replicated Data Types.
2011
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 17 / 86
18. CAP theorem Пример: ATM
Пример: ATM
Инвариант: баланс больше 0
Выбираем availability
Связь пропала — лимит на снятие наличных
Операция коммутативна
Связь восстановилась — считаем баланс,
возможно, штраф за overdraft
См. Check kiting5
5
http://en.wikipedia.org/wiki/Check_kiting
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 18 / 86
19. CAP theorem Use Case: Ebay
Use Case: Ebay
Principles for Scaling6
:
Partition Everything
Vertical, horizontal, no session state
Asynchrony Everywhere
Events, multicast
Automate Everything
Adaptive configuration, machine learning
Remember Everything Fails
Failure detection, rollback, graceful degradation
Embrace Inconsistency
Eventual consistency, no distributed transactions
6
Randy Shoup at LADIS 2008, http://www.cs.cornell.edu/projects/
ladis2008/materials/eBayScalingOdyssey%20ShoupTravostino.pdf
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 19 / 86
20. Транзакции Определение
Определение
Транзакция
A unit of work performed against a database, and treated
in a coherent and reliable way independent of other
transactionsa
a
http://en.wikipedia.org/wiki/Database_transaction
Две философии:
ACID7
— focus on consistency
BASE — focus on high availability
7
Name was coined (no surprise) in California in 60’s
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 20 / 86
21. Транзакции ACID-транзакции
ACID-транзакции
Atomicity — «либо всё, либо ничего»
commit/rollback, undo-log, атомарные операции, ...
Consistency — переход из одного «корректного»
состояния в другое
Индексы, ссылки, ограничения, триггеры, ...
Isolation — иллюзия последовательного
выполнения транзакций
Уровни изоляции: Read uncommitted / dirty reads,
Read committed / non-repeatable read, Repeatable
reads / phantom reads, Serializable, MVCC8
, ...
Durability — надёжное долговременное хранение
8
http:
//en.wikipedia.org/wiki/Multiversion_concurrency_control
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 21 / 86
22. Транзакции Распределённый commit
Распределённый commit
Two-phase commit protocol9
Three-phase commit protocol10
Paxos11
Raft12
9
http://en.wikipedia.org/wiki/2PC
10
http://en.wikipedia.org/wiki/3PC
11
http://en.wikipedia.org/wiki/Paxos_(computer_science)
12
https://raft.github.io
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 22 / 86
23. Транзакции ACID in CAP
ACID in CAP
Atomicity
Используется во всех партициях
Упрощает восстановление
Consistency
Невозможна при партиционировании
Запрет некоторых операций
Восстановление инвариантов впоследствии
Isolation
Можно работать только с одной партицией
Либо более слабая корректность, компенсируемая
восстановлением
Durability
Durable history позволяет исправлять ошибки при
восстановлении
Иногда ослабляют из-за дороговизны
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 23 / 86
24. Транзакции BASE
BASE
Dan Pritchett. BASE: An Acid Alternative13
. 2008:
Basically Available
Soft State
Eventually consistent
13
http://queue.acm.org/detail.cfm?id=1394128
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 24 / 86
25. Distributed Commit Two-Phase Commit Protocol
Two-Phase Commit Protocol
Distributed atomic commitment protocol
commit или abort (rollback)
Переживает (некоторые) временные сбои
Полагается на логгирование для восстановления
Восстановление — бОльшая часть логики
протокола
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 25 / 86
26. Distributed Commit Two-Phase Commit Protocol
Фазы
Commit-request (voting)
Координатор пытается подготовить участников
транзакции
Каждый участник отвечает Yes или No
Commit
Координатор принимает решение на основе ответов
Все сказали Yes ⇒ commit, No ⇒ abort
Координатор отправляет решение участникам
Участники применяют решение
Предусловие
Если нет сбоев
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 26 / 86
27. Distributed Commit Two-Phase Commit Protocol
Предположения
Выделенный координатор
Stable storage14
+ write-ahead log (WAL)
Узлы не умирают навсегда
Данные в WAL не теряются и не портятся
Любые два узлы могут общаться
Внимание
Если полностью уничтожить узел, можно потерять
данные
14
http://en.wikipedia.org/wiki/Stable_storage
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 27 / 86
28. Distributed Commit Two-Phase Commit Protocol
Диаграмма
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 28 / 86
29. Distributed Commit Two-Phase Commit Protocol
Оптимизации
Presumed abort/commit: работает при
восстановлении, экономим на логгировании,
используем статистику и ожидания
Tree two-phase commit protocol
(Nested/Recursive 2PC): агрегация в узлах дерева,
экономнее используем сеть
Dynamic two-phase commit: отправляем
решение оставшемуся молчуну, динамический
выбор координатора, быстрее освобождаем
ресурсы
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 29 / 86
30. Distributed Commit Two-Phase Commit Protocol
Ограничения
Блокирующийся протокол
Если координатор исчезнет, то некоторые участники
могут не закончить транзакцию:
Участник отправил координатору Yes
Координатор упал
Участник ожидает commit или rollback
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 30 / 86
31. Distributed Commit Two-Phase Commit Protocol
Поведение при сбоях
Пример ситуации:
Реплика выполнила commit и упала вместе с
координатором
Система не может восстановить результат
транзакции:
Только умершие 2 ноды знают точный результат
Pessimistic abort невозможен — упавшая реплика
могла сделать commit
Pessimistic commit невозможен — изначальное
решение могло быть abort
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 31 / 86
32. Distributed Commit Three-Phase Commit Protocol
Three-Phase Commit Protocol
Назначение как у 2PC
Неблокирующийся — ограничение сверху на
commit/abort
Лучше ведёт себя при сбоях15
2PC фаза Commit разбивается на 2 фазы —
получаем 3PC
15
http://the-paper-trail.org/blog/
consensus-protocols-three-phase-commit/
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 32 / 86
34. Distributed Commit Three-Phase Commit Protocol
Анализ
Вторая фаза доносит решение до всех участников
⇒ состояние можно восстановить при сбое
реплики
Phase 3 = 2PC Commit
При сбое координатора состояние
восстанавливается с помощью реплик:
Phase 1 (кто-то не получил Can commit?) ⇒
спокойно делаем abort
Phase 2 (кто-то получил preCommit) ⇒ доводим
транзакцию до commit
Fail-stop
Неустойчив к network partitioning.
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 34 / 86
35. 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 )
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 35 / 86
36. 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
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 36 / 86
37. Happens-before Lamport timestamps
Анализ
Невозможно точно синхронизировать время16
Если процессы не общаются, то между их
событиями нет отношения порядка
Обеспечивается лишь частичный порядок
16
Хотя см. http://research.google.com/archive/spanner.html
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 37 / 86
38. Happens-before Vector clocks
Vector clocks
Цель
Ввести частичный порядок событий в
распределённой системе
Обнаружить нарушения причинно-следственных
связей
Определение
Векторные часы в системе с N процессами — это
массив N логических часов по одному на процесс
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 38 / 86
39. Happens-before Vector clocks
Правила обновления массива часов
Изначально все часы выставлены в 0
При каждом событии процесс инкрементирует
свои логические часы на 1
Перед отправкой сообщения процесс:
Инкрементирует свои логические часы
Отправляет весь вектор вместе с сообщением
При получении сообщения процесс:
Инкрементирует свои логические часы
Обновляет свой вектор, беря покомпонентный
максимум с присланным вектором
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 39 / 86
41. 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 антисимметрично и
транзитивно
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 41 / 86
42. 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
protocol17
.
Raft
Протокол консенсуса для реплицированных
автоматов
Более простой, понятный и реализуемый чем
Paxos
Демонстрирует логику рассуждений
17
Chandra T. D., Griesemer R., Redstone J. Paxos made live: an engineering
perspective. 2007
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 42 / 86
43. Raft Введение
Ссылки
Replicated State Machines18
Ongaro D., Ousterhout J. In Search of an
Understandable Consensus Algorithm. 2013.
Diego Ongaro. Raft lecture19
(Raft user study)
Diego Ongaro. Paxos lecture20
(Raft user study)
Множество реализаций21
18
http://en.wikipedia.org/wiki/State_machine_replication
19
http://www.youtube.com/watch?v=YbZ3zDzDnrw
20
http://www.youtube.com/watch?v=JEpsBg0AO6o
21
https://raft.github.io/#implementations
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 43 / 86
44. Raft Введение
Replicated State Machines
Работают на множестве узлов
Вычисляют идентичные копии одного и того же
состояния
Устойчивы к падению узлов
Реплицированный лог (последовательность
команд)
Решаемые задачи: выбор лидера, хранилище
конфигураций и др.
Примеры: Chubby, ZooKeeper, etcd, Consul, ...
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 44 / 86
45. Raft Введение
Особенности Raft
Strong Leader
Клиенты общаются только с лидером
Данные только от лидера к репликам
Leader Election
Cлучайные таймеры
Membership changes
Joint consensus
Формальна описана и доказана безопасность
Производительность на уровне аналогов
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 45 / 86
46. Raft Введение
Алгоритм работы лидера
1 Получить команду от клиента
2 Добавить в локальный лог
3 Доставить команду другим узлам
4 При успехе применить команду к своему автомату
5 Вернуть ответ автомата клиенту
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 46 / 86
47. Raft Введение
Свойства протокола
Безопасность: никогда не вернёт некорректный
результат
Non-Byzantine22
fault tolerance23
Учитывает ненадёжную сеть
Доступность
Пока работают и могут общаться большинство узлов
Узлы останавливаются и снова подключаются
Независимость от абсолютного времени
Команда выполняется при ответе от
большинства — устойчивость к медленным узлам
22
http://en.wikipedia.org/wiki/Byzantine_fault_tolerance
23
https://c3.nasa.gov/dashlink/resources/624/
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 47 / 86
49. Raft Кластер
Кластер
Несколько узлов (3, 5, ...)
Узёл в одном из трёх состояний
Leader
Follower
Candidate
В нормальном режиме: 1 лидер и n − 1
последователей
Последователи пассивны: отвечают на RPC от
лидера и кандидатов
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 49 / 86
51. Raft Кластер
Семестры
Время разбивается на семестры (terms)
неопределённой длины24
Семестры нумеруются последовательно
Каждый семестр начинается с выбора лидера
Если кандидат выигрывает выборы, то он служит
лидером до конца семестра
Если никто не победил на выборах, начинается
новый семестр
Инвариант
В каждом семестре не больше одного лидера
24
Аналог логических часов
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 51 / 86
53. Raft Кластер
Обнаружение устаревшей информации
Каждый узел хранит текущий семестр
Текущий семестр каждый раз передаётся в
запросах
Если текущий семестр меньше пришедшего,
выбираем пришедший
Если кандидат или лидер — step down
Если пришедший семестр меньше текущего, то
отвергаем запрос
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 53 / 86
54. Raft Кластер
RPC
RequestVote — кандидат просит отдать ему голос
AppendEntries — лидер реплицирует команды +
heartbeat
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 54 / 86
55. Raft Выбор лидера
Условия запуска
Follower не получает heartbeat в течение election
timeout
Follower увеличивает текущий семестр
Переходит в состояние кандидата
Параллельно отправляет всем RequestVote
Перезапросы до получения ответа или окончания
выборов
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 55 / 86
56. Raft Выбор лидера
Условия останова
Follower выиграл выборы (набрал большинство
голосов)
Каждый узел голосует единожды за семестр (FIFO)
Новый лидер начинает рассылать всем heartbeats
Другой узел стал лидером
Кандидат получил AppendEntries с семестром ≥
текущего
Кандидат переходит в состояние follower (step down)
Наступил таймаут, а победителя всё нет
Никто не набрал большинства голосов
Кандидат переходит в состояние follower (step down)
Random election timeout
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 56 / 86
58. Raft Репликация лога
Committed Entry
Гарантируется, что будет выполнена всеми
автоматами
В простейшем случае — если подтверждена
запись большинством (см. записи 1-7)
Лидер пересылает индекс последнего коммита в
AppendEntries — followers коммитят
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 58 / 86
59. Raft Репликация лога
Log Matching Property
Если у двух записей в разных логах совпадают индекс
и семестр, то:
Они содержат одинаковую команду
Лидер создаёт не больше одной записи с одним
индексом и семестром
Записи в логе не перемещаются
Логи идентичны во всех предшествующих записях
Лидер с AppendEntries пересылает индекс и семестр
предыдущей записи
Follower отвергает запрос, если не совпадает
Шаг индукции
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 59 / 86
60. Raft Репликация лога
Но может быть так
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 60 / 86
61. Raft Репликация лога
Пояснения
a-b — не хватает записей
c-d — лишние записи
e-f — оба случая
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 61 / 86
62. Raft Репликация лога
Разрешение конфликтов
Замена конфликтов на followers записями лога
лидера
Лидер помнит nextIndex для каждого follower —
изначально следующий за последним в логе
Используется RPC AppendEntries Consistency
Check
Если ошибка, то nextIndex - 1 и retry
Если совпадение, то удаляется хвост и добавляются
записи лога лидера
Автоматическая сходимость логов
Лидер никогда не удаляет и не перезаписывает
записи в собственном логе
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 62 / 86
63. Raft Корректность
Проблема
Лидер закоммитил несколько записей
Последователь был недоступен
Лидер ушёл с радаров
Последователь стал новым лидером
Последователь перезаписал всем логи
В результате разные автоматы выполнили разный
набор команд
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 63 / 86
64. Raft Корректность
Решение
Расширим протокол:
Ограничение на узлы, которые могут стать
лидером
Ограничение на записи, которые считаются
закоммичеными
Обеспечиваем:
Лидер любого семестра содержит все записи,
закоммиченые в предыдущих семестрах
Записи направлены только от лидера к
последователям
Лидеры никогда не перезатирают записи в своём
логе
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 64 / 86
65. Raft Корректность
Ограничение на выбор лидера
Всё так же нужно собрать голоса большинства
Но можно стать лидером, только если наш лог не
менее свежий, чем у каждого голосующего
RequestVote RPC содержит информацию о
последней записи в логе
Лог новее, если семестр старше или индекс
больше (лог длиннее)
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 65 / 86
67. Raft Корректность
Случай 1
Наиболее популярный
Лидер реплицирует запись из текущего семестра
Запись закоммичена, как только подтвердит
большинство
Лидером могут стать только те, у кого есть эта
запись
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 67 / 86
69. Raft Корректность
Случай 2
Лидер коммитит запись из предыдущего семестра
Лидер семестра 2 создал запись по индексу 2,
отреплицировал на S1 и S2 и упал
S5 стал лидером в семестре 3 (собрал голоса у S3
и S4)
Записал запись в свой лог по индексу 2 и упал
S1 стал лидером в семестре 4 (голоса от S2 и S3)
Отреплицировал запись по индексу 2 на S3
Незакоммичена несмотря на большинство
S5 может стать лидером (его лог новее чем S2, S3
и S4) и распространить своё значение по
индексу 2
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 69 / 86
70. Raft Корректность
Ограничение на коммиты
Пока новый лидер не закоммитит запись из
текущего семестра, он считает предыдущие
записи незакоммичеными
См. случай 3 — после этого S5 не может стать
лидером
См. доказательство корректности25
25
Safety proof and formal specification for Raft: http:
//raftuserstudy.s3-website-us-west-1.amazonaws.com/proof.pdf
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 70 / 86
71. Raft Timing and availability
Timing and availability
Timing requirement
broadcastTime electionTimeout MTBF
Типичные значения:
broadcastTime: 0.5-20 ms
electionTimeout: 10-500 ms
MTBF: month
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 71 / 86
72. Raft Изменение конфигурации кластера
Изменение конфигурации кластера
Предполагали, что состав узлов статичен
Но иногда нужно заменять сервера или изменять
уровень репликации
В идеале — без downtime
И автоматически — исключить человеческий
фактор
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 72 / 86
74. Raft Изменение конфигурации кластера
Проблема
Проблема
Возможно одновременное существование двух лидеров
для одного семестра в двух подкластерах
Решения:
2PC: сначала выключаем старую конфигурацию,
возможен downtime
Raft: промежуточная конфигурация (joint
consensus)
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 74 / 86
75. Raft Изменение конфигурации кластера
Идея
Комбинация двух конфигураций:
Записи реплицируются серверам в обеих
конфигурациях
Сервер из любой конфигурации может стать
лидером
Нужно собрать большинство в каждой
конфигурации по-отдельности
При этом без downtime
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 75 / 86
76. Raft Изменение конфигурации кластера
Joint Consensus
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 76 / 86
77. Raft Изменение конфигурации кластера
Алгоритм
Запрос лидеру на смену конфигурации с Cold на
Cnew
Сохраняет в лог Cold,new и реплицирует
Каждый сервер сохраняет Cold,new в лог и сразу
начинает использовать
Лидер упал — новый лидер из Cold,new или Cold, но
не Cnew
Успешно закоммитили — лидером может стать
только Cold,new
Лидер сохраняет в лог Cnew и реплицирует и т. д.
Cold и Cnew не могут одновременно
принимать решения
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 77 / 86
78. Raft Изменение конфигурации кластера
Особенности
Если лидер входит в Cold, но не в Cnew , то должен
выйти из кластера (реплицирует, но не входит в
большинство)
Новые сервера могут быть пустыми — вначале
добавляем как неголосующих, но реплицируем на
них логи
Удаление серверов, которые не в курсе, что их
удаляют, может снизить производительность
кластера — инициируют безнадёжные выборы
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 78 / 86
79. Raft Оптимизации
Log Compaction
Подходы:
Очистка логов — перемещаем «живые» записи в
голову и очищаем мёртвый хвост
Инкрементально и эффективно
Определение живых записей может быть сложным
Слепки — состояние системы периодически
сохраняется на stable storage, а лог сбрасывается
Менее эффективно (неинкрементально)
Просто
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 79 / 86
81. Raft Оптимизации
Snapshotting: Нюансы
Нужно решить, когда создавать слепки —
например, при достижении логом определённого
размера
Copy-on-write для асинхронной записи слепков +
functional data structures/fork()
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 81 / 86
82. Raft Клиент
Проблема
Команда может применяться несколько раз
Лидер получил команду, закоммитил и умер, не
успев ответить
Клиент делает перезапрос
Идемпотентность
Клиент присваивает командам уникальные
последовательные номера
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 82 / 86
83. Raft Клиент
Проблема
Протухшее чтение
У лидера есть все закоммиченые изменения
Но в начале семестра он не знает, кто из них
закоммичен
Вначале он должен закоммитить запись из нового
семестра
Решение
no-op в начале семестра
Heartbeat с большинством кластера перед ответом
на read
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 83 / 86
84. Материалы Чтение на ночь
Чтение на ночь
Fallacies of Distributed Computing2627
:
The network is reliable
Latency is zero
Bandwidth is infinite
The network is secure
Topology doesn’t change
There is one administrator
Transport cost is zero
The network is homogeneous
...26
http:
//en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing
27
Arnon Rotem-Gal-Oz. Fallacies of Distributed Computing Explained,
http://www.rgoarchitects.com/Files/fallacies.pdf
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 84 / 86
85. Материалы Библиотечка
Библиотечка
Google. Distributed Systems and Parallel
Computing28
Quora: What are the top startup engineering blogs?29
28
http://research.google.com/pubs/
DistributedSystemsandParallelComputing.html
29
http:
//www.quora.com/What-are-the-top-startup-engineering-blogs
Цесько В. А. (Технополис) CAP. Commit. 10 мая 2017 г. 85 / 86