2014.12.06 03 Александр Чистяков — Устройство object storage на примере LeoFS
0 likes286 views
Документ описывает опыт использования системы объектного хранения leofs в компании Git in Sky для управления более чем 100 млн пользовательскими файлами. Основное внимание уделяется архитектуре leofs, проблемам и решениям, связанным с отказоустойчивостью и производительностью, а также процессу развертывания системы. Автор делится графиками нагрузки и выводами о применимости nosql без замены rdbms.
2014.12.06 03 Александр Чистяков — Устройство object storage на примере LeoFS
- 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 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. Домашняя работа ● Найдите на графике момент отказа*: * я и сам не найду
- 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