Александр Кудымов - Любовь и честность в интерфейсах | HappyDev'12
My talk on LeoFS, HappyDev 2014
-
Upload
alex-chistyakov -
Category
Technology
-
view
690 -
download
2
description
Transcript of My talk on LeoFS, HappyDev 2014
Устройство 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● [email protected]● http://twitter.com/noatbaksap● http://meetup.com/DevOps-40