Устройство object storage

На примере LeoFS

Alexander Chistyakov, Git in Sky

Привет, HappyDev!● Меня зовут Саша● И я – performance engineer● Работаю на должности главного инженера

в компании Git in Sky

Привет, Саша!● Мы – веб разработчики!● Мы – системные администраторы!● Мы – архитекторы!● Мы еще пока не определились!

О чем пойдет речь● “Я вообще думаю, может БД поменять на

что-нибудь NoSQL” © типичный разработчик

● Если не БД – то файловую систему, хотя бы

Предыстория● HighLoad 2012 – https://clck.ru/9Lutd (не я)● DevConf 2014 – https://clck.ru/9Lutw (уже я)● Клиент – Setup.ru (конструктор сайтов)● 100+ млн. пользовательских файлов● Метаинформация в PostgreSQL● Сами файлы – в PostgreSQL через LO API

Наше время● Проект на Perl (был когда-то такой язык)● Хостинг – Hetzner (лучше уж Perl)● Текущая конфигурация машин в Hetzner не

имеет дисков достаточного объема (8 терабайт - максимум)

● Мы должны были уметь хранить больше чем 8Тб файлов уже вот прямо вчера

Как быть?● Делегировать эту задачу Amazon● Построить свой Amazon:● Elliptics● OpenStack Swift● Ceph Object Gateway● Riak CS● LeoFS

Общее для всех● HTTP REST или Amazon S3 интерфейс● Автоматическая репликация● Автоматическая отказоустойчивость● Легкое добавление новых узлов

Устройство любого object storage● Узлы, на которых хранятся данные● Узлы, на которых хранятся метаданные● Маршрутизаторы запросов к первым двум● Background workers● Как я уже говорил однажды в Омске:

Любой* NoSQL – несколько локальных хранилищ + роутер запросов к ним

*не любой

Надо сделать выбор● Erlang – как Python, только лучше*● Mnesia и LevelDB – как SQLite, только лучше*● DuckDuckGo – как Yandex, только лучше*● Интегрированный механизм кэширования

лучше*, чем его отсутствие● LeoFS: Erlang, Mnesia, LevelDB, не Yandex,

интегрированное кэширование

*не лучше

Последствия выбора● Примерно как у свадьбы, только

развестись гораздо сложнее● Помехи при выборе:● Эффект Даннинга-Крюгера● Ошибка выживших● Недостаточность и плохое качество

информации о решении в Интернете

Устройство LeoFS● LeoFS manager – хранит метаданные● LeoFS storage – хранит данные● LeoFS gateway – маршрутизирует запросы и

кэширует контент локально● LeoFS manager – единая точка отказа● Поэтому их делают два: master и slave

Устройство LeoFS● LeoFS manager использует Mnesia● LeoFS storage использует LevelDB● Mnesia – распределенная СУБД из

стандартной поставки Erlang● LevelDB – key-value storage, разработана в

Google, представляет собой LSM-tree

Устройство LeoFS● Внутренние процессы:● LevelDB нужно компактить*● При добавлении/удалении нод нужно

перестраивать кольцо маршрутизации● Можно временно включать/выключать

узел● К счастью, все это делается вручную

* не всем

Развертывание LeoFS● Для развертывания чего угодно я

использую Ansible● Playbooks для LeoFS: https://clck.ru/9Lx73● (По ссылке старая версия, сейчас все

переделано на установку через роли)

То, ради чего все затевалось● Отказоустойчивость:● В конфигурационном файле задается

количество реплик и● Количество успешных операций● Чтения● Записи● Удаления

Как это выглядит у нас● Данные хранятся на 5 узлах, 8

потребителей●

Что мы храним● Все хранимые объекты больше 64

килобайт● Всего хранится 7 терабайт таких объектов● Только 15-20% запросов идет в LeoFS,

объекты размером менее 64К по-прежнему отдаются из PostgreSQL

Домашняя работа● Найдите на графике момент отказа*:

* я и сам не найду

Ура, графики!● Количество запросов к хранилищу:

Еще графики!● Нагрузка на сеть:

И еще графики!● Нагрузка на диск:

Плюсы● 12 июня – начало выбора технологии● Через пару дней – начало внедрения● К августу развернут параллельный

“старому” новый сторадж на LeoFS● В сентябре переезд полностью состоялся● В августе умер один из пяти узлов –

заменили целиком, юзеры не заметили

Минусы● График latency (достаточно неторопливо):

Подводные камни● Клиентские библиотеки S3 все плохого

качества● При отказе узла latency еще возрастает● Если на gateways включено кэширование

на диск, и на диске кончается место – latency возрастает неимоверно

● Балансировка контента не автоматически (и это плюс)

Границы применимости● Мы храним статический контент● Мы никогда не модифицируем, всегда –

новый URL● Мы никогда не удаляем контент● Наши пользователи лояльно относятся к

latency (это обусловлено тем, что существует два типа контента)

Выводы● Нельзя просто так взять и заменить

RDBMS (FS, whatever) на NoSQL

Спасибо за внимание!● С вами был Александр Чистяков● Из компании Git in Sky● http://gitinsky.com● alex@gitinsky.com● http://twitter.com/noatbaksap● http://meetup.com/DevOps-40