опыт построения и эксплуатации большого файлового...

20
Опыт построения и эксплуатации большого фалового хранилища Даниил Подольский Git in Sky

Upload: daniel-podolsky

Post on 06-Apr-2017

479 views

Category:

Software


1 download

TRANSCRIPT

Опыт построения и эксплуатации большого фаилового хранилищаДаниил ПодольскийGit in Sky

илиНочью через лес

Фаиловое хранилище – что это и зачем оно• Файл: именованный кусок данных,

слишком большой для того, чтобы обращаться с ним, как с одним куском

• Краеугольный камень здорового питания современного обмена данными. Так уж получилось.

• Файловое хранилище – место, где хранятся файлы

• Файловое хранилище – место, откуда отдаются файлы

Большое фаиловое хранилище – пришла беда откуда не ждали• Много байтов? Нет.• Много файлов? Нет.• Много обновлений? Теплее...• Проблема управления? Тепло!• «Большое» - описание ситуации, а не

сущности!

Парадокс фаилового хранилища• Файловое хранилище не нужно. От

слова «совсем»• В бизнес-требованиях не написано

«хранить файлы»– Даже когда написано – это ошибка

• В бизнес требованиях написано «отдавать файлы»

• Но отдать можно лишь то, что имеешь

10 лет под кроватью• Setup.Ru как источник

неограниченного количества разнообразных файлов

• Картинки и разметка – что хранить, а что генерировать

• Постоянные обновления – до 20М файлов в сутки

2012, начало:rsync, обезьяны! Как оно было• Локальная EXT4• До 6М файлов• SSD для горячего контента• HDD для объемного контентаПроблемы• Eventual отказоустойчивость• Никакой статистики

2012, лето:а они как ломанули!..Как оно было• 6.5М файловПроблемы• 6 часов на обход дерева – контент менялся

быстрее, чем мы его синхронизировалиРешение• Файлы – в базу!• Большие файлы – в BLOB• Самописная master-master репликация

2103, весна:поиски начала концаКак оно было• 25М файловПроблемы• Длинные транзакции, автоинкремент и проблемы

синхронизации• Контент меняется быстрее, чем мы его

синхронизируемРешение• Меняем бизнес-логику для преодоления проблем

eventual consistency

2103, осень:кто съел процессорКак оно было• 50М файловПроблемы• Долгий joinРешение• Materialized views

2014, весна:нам некуда больше жатьКак оно было• 120М файловПроблемы• Контент перестал помещаться на дискРешение• Большие файлы были вынесены на leofs

хранилище

2015, начало:все свободны, всем - спасибоКак оно было• 400М файловПроблемы• Расширение кластера leofs привело к его

разрушению• Rakuten помощь оказать не смогРешение• Паниковать!• Пробовать iSCSI квази-СХД.• Паниковать!!!

2015, весна:бесконечность не пределКак оно было• 450М файловПроблемы• На leofs заканчивается место. Расширение

невозможно• Rakuten помощь оказать не смог• Индексы PostgreSQL перестали помещаться в

памятьРешение• Разработать собственное хранилище на базе

NoSQL СУБД

Чему мы научились• Отказоустойчивость – это «отдавать» и

«обновлять», но традиционные хранилища – такие хранилища…

• «Ничто не заменит кубы», или файловый кеш

• Распределенные системы хранения – блеск и нищета дешевого кластера– Мерзость eventual consistency– Ужас strong consistency– Беспросветность ребалансинга– А еще оно тормозит

Чему еще мы научились• Хорошо, когда файлы мелкие –

тогда они не файлы.• PostgreSQL BLOB – не делай так

больше• Материализация view – иногда без

этого никак• Самописная репликация – road to hell• Удалять файлы придется• Java лучше, чем Erlang

Чему мы НЕ научились• Большая отказоустойчивая СХД:

немного слишком дорого• Распределенные POSIX-

совместимые файловые системы: созданы под другие задачи

Нет у революции конца• Кластерная NoSQL СУБД• Самописный чанкинг• Самописное версионирование• Самописный dedup (rolling

checksum)• Самописные транзакции• Ну и сжатие на уровне чанкаЭто работает!

Немного цифр• 1.5М сайтов• 450М файлов• 6Т данных – 18Т с избыточностью• 1.5К запросов в секунду

Все-такиНочью через лес

• 2Т лимит, или почему не получился бесшовный переезд

• 3 часа на рестарт ноды• 60 часов на ребалансинг

Вопросы?