Бесконечность – не предел: Как мы масштабируем единое хранилище Яндекса на десятки эксабайт
Доклад принят в программу конференции
Целевая аудитория
Тезисы
В Яндексе все сервисы используют общую инфраструктуру хранения данных, в центре которой находится единое объектное хранилище - MDS. Например, в нем хранят свои данные Я. Диск, Почта, Музыка, а также оно лежит в основе Yandex Object Storage. В докладе расскажу про эволюцию нашей системы, вызовы, проблемы, как мы их решали и что получилось.
При проектировании и эксплуатации нашего хранилища, мы сталкиваемся с серьезными техническими вызовами: уже сейчас в MDS хранится около 4 ЭБ данных, распределенных по нескольким тысячам серверов и обрабатывает более 1.5M RPS. Также к хранилищу предъявляются высокие требования по доступности и надежности (4 и 11 "девяток").
При этом данных с каждым годом становится все больше, и мы должны уметь масштабироваться на порядки. Архитектурные ограничения старой версии MDS не давали нам этого достичь:
- Централизованный control-plane и стейт кластера мешали дальше наращивать число серверов
- Клиентская репликация в data-plane приводила к проблемам согласованности при отказах
- При поломке железа система часто требовала вмешательство человека, что усложняло эксплуатацию и снижало надежность
В докладе подробно разберу новую архитектуру нашего хранилища и как она решает описанные проблемы:
- Децентрализация - унесли всю сложную логику из control-plane в "умный" дисковый слой и избавились от централизованного состояния кластера
- Self-healing и декларативное управление кластером - автоматизировали починку всех типовых отказов, а декларативное состояние кластером позволяет в целом упростить эксплуатацию системы. Значительно ускорили время реакции на поломку дисков - до нескольких минут.
- Репликация данных на основе Raft - отказались от клиентской кворумной репликации с сложной фоновой синхронизацией в пользу боле простого и надежного алгоритма
Расскажу как себя ведет себя хранилище при отказах и как graceful degradation позволяет нам оставаться доступными при отказе больших частей системы. Поговорим про эксплуатацию, на какие метрики смотрим. Расскажу какие альтернативы рассматривали, что не сработало, и почему не взяли популярное готовое решение (ceph, minio).
Что заберете с собой:
- Принципы проектирования exascale хранилища
- Архитектурные решения: как организовать взаимодействие control и data plane, как реализовать репликацию данных, добиться высокой отказоустойчивости
- Паттерны автоматизации эксплуатации (self-healing, декларативное управление)
- Метрики мониторинга здоровья кластера из тысяч серверов
Старший разработчик в общем сторадже Яндекса и S3.
Видео
Другие доклады секции
Базы данных и системы хранения