My talk on LeoFS, HappyDev 2014

1. Устройство object storage
На примере LeoFS
Alexander Chistyakov, Git in Sky

2. Привет, HappyDev!
●Меня зовут Саша
● И я – performance engineer
● Работаю на должности главного инженера
в компании Git in Sky

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

4. О чем пойдет речь
● “Я вообще думаю, может БД поменять на
что-нибудь NoSQL” © типичный
разработчик
● Если не БД – то файловую систему, хотя бы

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 Swift
● 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. Домашняя работа
● Найдите на графике момент отказа*:
* я и сам не найду

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

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

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

23. Плюсы
● 12 июня – начало выбора технологии
● Через пару дней – начало внедрения
● К августу развернут параллельный
“старому” новый сторадж на LeoFS
● В сентябре переезд полностью состоялся
● В августе умер один из пяти узлов –
заменили целиком, юзеры не заметили

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

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