5. Предыстория
● HighLoad 2012 – https://clck.ru/9Lutd (не я)
● DevConf 2014 – https://clck.ru/9Lutw (уже я)
● Клиент – Setup.ru (конструктор сайтов)
● 100+ млн. пользовательских файлов
●Метаинформация в PostgreSQL
● Сами файлы – в PostgreSQL через LO API
6. Наше время
● Проект на Perl (был когда-то такой язык)
● Хостинг – Hetzner (лучше уж Perl)
● Текущая конфигурация машин в Hetzner не
имеет дисков достаточного объема (8
терабайт - максимум)
●Мы должны были уметь хранить больше
чем 8Тб файлов уже вот прямо вчера
7. Как быть?
● Делегировать эту задачу Amazon
● Построить свой Amazon:
● Elliptics
● OpenStack Swif
● Ceph Object Gateway
● Riak CS
● LeoFS
8. Общее для всех
● HTTP REST или Amazon S3 интерфейс
● Автоматическая репликация
● Автоматическая отказоустойчивость
● Легкое добавление новых узлов
9. Устройство любого object storage
● Узлы, на которых хранятся данные
● Узлы, на которых хранятся метаданные
●Маршрутизаторы запросов к первым двум
● Background workers
● Как я уже говорил однажды в Омске:
Любой* NoSQL – несколько локальных
хранилищ + роутер запросов к ним
*не любой
10. Надо сделать выбор
● Erlang – как Python, только лучше*
●Mnesia и LevelDB – как SQLite, только лучше*
● DuckDuckGo – как Yandex, только лучше*
● Интегрированный механизм кэширования
лучше*, чем его отсутствие
● LeoFS: Erlang, Mnesia, LevelDB, не Yandex,
интегрированное кэширование
*не лучше
11. Последствия выбора
● Примерно как у свадьбы, только развестись
гораздо сложнее
● Помехи при выборе:
● Эффект Даннинга-Крюгера
● Ошибка выживших
● Недостаточность и плохое качество
информации о решении в Интернете
12. Устройство LeoFS
● LeoFS manager – хранит метаданные
● LeoFS storage – хранит данные
● LeoFS gateway – маршрутизирует запросы и
кэширует контент локально
● LeoFS manager – единая точка отказа
● Поэтому их делают два: master и slave
13. Устройство LeoFS
● LeoFS manager использует Mnesia
● LeoFS storage использует LevelDB
●Mnesia – распределенная СУБД из
стандартной поставки Erlang
● LevelDB – key-value storage, разработана в
Google, представляет собой LSM-tree
14. Устройство LeoFS
● Внутренние процессы:
● LevelDB нужно компактить*
● При добавлении/удалении нод нужно
перестраивать кольцо маршрутизации
●Можно временно включать/выключать
узел
● К счастью, все это делается вручную
* не всем
15. Развертывание LeoFS
● Для развертывания чего угодно я
использую Ansible
● Playbooks для LeoFS: https://clck.ru/9Lx73
● (По ссылке старая версия, сейчас все
переделано на установку через роли)
16. То, ради чего все затевалось
● Отказоустойчивость:
● В конфигурационном файле задается
количество реплик и
● Количество успешных операций
● Чтения
● Записи
● Удаления
17. Как это выглядит у нас
● Данные хранятся на 5 узлах, 8
потребителей
●
18. Что мы храним
● Все хранимые объекты больше 64 килобайт
● Всего хранится 7 терабайт таких объектов
● Только 15-20% запросов идет в LeoFS,
объекты размером менее 64К по-
прежнему отдаются из PostgreSQL
19. Домашняя работа
● Найдите на графике момент отказа*:
* я и сам не найду
23. Плюсы
● 12 июня – начало выбора технологии
● Через пару дней – начало внедрения
● К августу развернут параллельный
“старому” новый сторадж на LeoFS
● В сентябре переезд полностью состоялся
● В августе умер один из пяти узлов –
заменили целиком, юзеры не заметили
25. Подводные камни
● Клиентские библиотеки S3 все плохого
качества
● При отказе узла latency еще возрастает
● Если на gateways включено кэширование на
диск, и на диске кончается место – latency
возрастает неимоверно
● Балансировка контента не автоматически
(и это плюс)
26. Границы применимости
●Мы храним статический контент
●Мы никогда не модифицируем, всегда –
новый URL
●Мы никогда не удаляем контент
● Наши пользователи лояльно относятся к
latency (это обусловлено тем, что
существует два типа контента)
27. Выводы
● Нельзя просто так взять и заменить
RDBMS (FS, whatever) на NoSQL
28. Спасибо за внимание!
● С вами был Александр Чистяков
● Из компании Git in Sky
● http://gitinsky.com
● alex@gitinsky.com
● http://twitter.com/noatbaksap
● http://meetup.com/DevOps-40