Как хранить 3 000 000 картинок и 100 000 файлов?

Question

[Serafim]

Дано:

• Три сервера, следующей конфигурации:
  
  4-х ядерный процессор AMD Athlon II X4 640
  
  16 ГБ оперативной памяти
  
  14 жестких дисков, два по 250 Гб объединенных в raid-1 (hardware) для ОС и софта, двенадцать по 2 Тб объединенных в raid-6 (mdadm) для самого хранилища, т.е. фактически с учетом издержек на raid и файловую систему доступно 19 Тб пространства)
  
  итого порядка 57 Тб пространства в сумме
  
• Существующие данные:
  
  3 000 000 картинок, средний размер около 1 Мб (преимущественно это фотографии и скриншоты)
  
  100 000 разношерстных файлов, средний размер очень условно 150 Мб, на деле от 100 Кб до 4 Гб
  
  итого около 18 Тб данных
  
• Программное обеспечение:
  
  операционная система: Debian 6
  
  текущая система хранения данных: mogilefs
  

Надо:

1. Простой (к примеру основанный на HTTP) интерфейс CRUD-операции с объектами в хранилище (можно без U). Требования работать с хранилищем как с обычным локальным разделом (POSIX-совместимая файловая система) нет, но если такое тоже достижимо — будет хорошо.
   
2. Возможность прочитать фрагмент объекта (необходимо для псевдостримминга видео).
   
3. Иметь избыточность данных (raid не решает задачи, когда вышел из строя весь сервер или с сервером потеряна связь), т.е. один объект должен храниться как минимум на двух серверах.
   
4. Иметь возможность разнести сервера по разным (двум) дата-центрам.
   
5. Крайне желательно, чтобы система не требовала отдельного сервера для хранения meta-данных (так называемый name-сервер), т.к. это создает дополнительную точку отказа.
   
6. Система должна иметь возможность анализировать свое состояние, т.е. проверять наличие необходимого числа копий для объектов, в идеале проверка консистентности объектов (но это накладывает определенные требования, такие как вычисление контрольной суммы для объектов и хранение трех копий, для возможности чтения с кворумом, поэтому это не требование, а пожелание к системе).
   
7. Система должна иметь возможность перераспределить объекты между хранилищами, т.е. когда появится четвертый сервер, то данные должны быть равномерно перераспределены между всеми серверами.
   
8. Совсем идеально иметь возможность установить ttl для объекта (т.е. чтобы по прошествии заданного времени объект был удален или помечен как удаленный).
   
9. Система должна уметь удалять объекты, т.е. когда объект удаляется или помечается как удаленных, он действительно должен быть удален, допускается это делать с задержкой.
   
10. Решение должно быть полностью программным, никакого дополнительного оборудования или замена существующего.
    

Что уже пробовали:

• MogileFS. Данное решение было выбрано около 3-лет назад и используется сейчас, в принципе оно отвечает ряду требований, но сложность его сопровождения (на деле это набор perl-скриптов) и отсутствие поддержки остальных требований заставило меня задуматься и поискать альтернативы.
  
• GridFS (mongodb). Очень медленно и сыро, я не буду детально расписывать что не так с гридфс, отмечу что тестировал его полтора года назад, возможно сейчас с ним все намного лучше, поэтому просто просьба этот вариант не предлагать, я о нем знаю.
  

Просьба к сообществу

Буду благодарен услышать ваши предложения относительно выбора программного обеспечения для хранилища отвечающего указанным выше требованиям. Отдельно интересует услышать об опыте работы с Elliptics (ioremap.net, elliptics.ru) из описании на сайтах складывается впечатление, что это практически «серебряная пуля», но отсутствии сведений о реальном использовании вызывают опасение использовать данное решение в бою. Спасибо.

Answer 1

[qxfusion]

Посмотрите в сторону OCFS2 (распределенная, без мета сервера, проверено в продакшене, без «волшебных грибов») + DRDB (создание RAID over Network) — для DRDB рекомендую использовать или 2x10Gbps (дуплетом) или 1x40Gbps учитывая объемы.

По поводу разделения на 2 ДЦ — в DRDB это возможно, хотя сама OCFS2 это позволяет.

Консистентность решается средства ФС, НО если есть деградация сети — то можно получить колоссальную просадку IOPS.

По поводу перераспределения — тут увы не скажу, но скорее нет чем да, как вариант можно использовать Cassandra но при переносе в любом случае будет потеря IOPS за счет циклом миграции и пересчета кольца.

Я бы лично для OCFS2 рекомендовал сменить ОС на RHEL/OEL/CloudLinux/CentOS — т.к. там она работает хорошо, а вот с другими ОС…

Comments

[Serafim]

Если я правильно понял, то это «raid-1 по сети», как хранилище для xen-образов думаю это идеальное бюджетное решение, но для указанной задачи оно совершенно не подходит, т.к. отсутствует шардинг, т.е. я не смогу сохранить 25 Тб данных.

[qxfusion]

Я не понимаю причем тут 25TB данных и шардинг. Вы хотите получить (1) отказоустойчивость — ее обеспечивает DRDB как RAID1 через сеть (2) распределенность — тут OCFS2

[Serafim]

Возможно я не правильно вас понял. На каждом узле у меня доступно по 19 Тб пространства, при использовании DRDB я получаю те же 19 Тб (только в трех копиях, т.к. raid-1 это просто зеркало), следовательно я не смогу записать 25 (места не хватит), а вот при использовании хранилища, которое поддерживает шардинг, мне доступны все 19х3=57 Тб пространства и я сам волен управлять политикой избыточности (для не самых важных объектов мне хватит двух копий, для важных трех), и случае двух копии я смогу записать 57/2 = 28,5 Тб данных (а не 19Тб как во варианте с рейдом по сети).

[qxfusion]

А что Вам мешает управлить пространством в UNIX стиле?
т.е. Вы далаете 2 раздела: (1) mission critical — DRDB(RAID1)+OCFS2 (2) default — OCFS2 итого будет 19TB (2x19TB@DRDB-RAID1) + 19TB (default) = 38TB ~место под метаданные (не более 5%) т.е. физически будет доступно около 36TB
далее понтируете в точку например /mnt/netfs/critical/ для критических данных и /mnt/netfs/default/ для обычных данных
критичные данные ВСЕГДА будут иметь 2 копию, обычные НЕ будут ее иметь
OCFS2 позволяет Вам получить обычную ФС которая будет «размазана» по нескольким нодам, также Вы можете добавлять новые ноды для увеличения пространства. ФС умеет работать с блоками файлов (как pNFS4)

[Serafim]

ваш сценарий не подходит из-за двух причин:
1. как минимум две копии должно быть у любого объекта, вариант с одним экземпляром объекта в хранилище не рассматривается, просто для очень важных объектов необходимо три копии (чтобы была возможность читать с кворумом).
2. что мне делать когда появится четвертый сервер?)

итого, нужен шардинг (буква P в CAP теореме), решения без него не удовлетворяют условиям задачи.
но вам, все равно большое спасибо, т.к. у меня была задача (о которой я здесь не упоминал) по созданию общего хранилища для образов виртуальных машин и вы навели меня на отличное решение.

[qxfusion]

1) Вы противоречите сами себе, но ничего, для 3 копий — DRDB можно растянуть на 3 сервера, для обычных на 2 — делаем тогда комбинированный RAID тогда будет доступно — 19*3 = 57TB/(2+3)*2 = 22.8TB доступно, с учетом накладных затрат где-то 21TB
2) тоже самое — если БЫ Вы захотели увеличить например RAID5 или RAID6 увеличение просто-так невозможно, соответственно количество серверов должно расти пропорционально количеству нодов в корзине

Если так нужно САР — то смотрите в сторону Riak — скорее всего выбере именно его.

Answer 2

[liveder]

riak?

Comments

[Serafim]

Эдакий mongodb на erlang'е? Спасибо за наводку, посмотрю что за зверь такой.

[qxfusion]

у Basho Riak есть только 1 проблема — это вероятность «split-brain» в случае сетевых проблем, а так сама БД очень гибках — с множеством backend моделей для физического хранения данных.

Answer 3

[Влад Животнев]

Elliptics используется, вполне себе работает. Яндекс, Nokia.
Действительно, в данном случае — он является решением. Можно попробовать pohmelfs натянуть на него, но он плохо работает.

Только за обновлениями следить нужно.

Answer 4

[Александр]

>отдельно интересует услышать об опыте работы с Elliptics
специально пойду в субботу слушать про это чудо.

Comments

[Александр]

поделюсь информацией в понедельник

[Serafim]

большое спасибо :)
(вроде он-лайн трансляция тоже будет, но личное участие конечно не сравнится, поэтому если возможно уточните про 8-ой пункт — ttl для объектов)

[Александр]

вот что я от туда вынес
Однозначно стоит попробовать

[Serafim]

среди минусов elliptics забыли указать ещё один: беда с документацией :) на официальных сайтах только общая информация, в репозитории инструкция по его сборке из исходников, но не слова о том, как сконфигурировать кластер. к слову, вчера в radio-t (в чате) bobuk сказал, что документацию к нему пишут, осталось только понять какими темпами и когда она будет опубликована

[Александр]

и еще, как сказал один из разработчиков, слабое коммунити
хотя проекту уже несколько лет.

Они это поняли, так как маил-ру начал пиарить на разных Конференциях своего тарантула и быстро организовали небольшое, но сильное коммунити, которое им помогает с багфиксами…

теперь это поняли и Яндексовцы…

и его еще тяжело отлаживать, так как его писал хакер (в понятие высокопрофессиональный программист) и не заморачивался на описаниях ошибок…

[Алексей Ашурок]

Основные минусы Elliptics, как уже сказали — документация и поддержка.
С доками полный аллес капут, настолько что товарищ, писавший обертку-интерфейс для php в конце концов начал забивать на чтение огрызков доки, письма авторам и тупо начал ковырять код, выдирая оттуда параметры навроде «как указать этой хреновине с каким modification-time сохранить этот файлик».
Ну а поддержка — есть 2 ноды, они работают. Как мониторить их состояние — не особо понятно. Да, есть тулза, показывающая состояние, но что с этим еще можно сделать — непонятно. В итоге сидим и думаем, а не отказаться ли от него в сторону чего-нибудь еще.

Answer 5

[yurtaev]

Может пригодится – «Как мы строили распределенное хранилище файлов для веба и что из этого получилось»

Comments

[Serafim]

Вы автор (или имеете отношение к авторам) этой презентации? Если да, то подскажите — сколько у вас сейчас документов в монге, если нет — то спасибо за ссылку.

[yurtaev]

Я не автор, но вы можете попробовать призвать его сюда Ramm

[Данила Штань]

Привет, на видео записано моё выступление, кстати мы планируем попробовать давать свой кластер для публики за разумную денежку. Подробности — тут: unistorage.ru

Я отвечу здесь на вопросы, которые тредстартер задавал в личку.

> Сколько объектов в вашем mongodb (gridfs) кластере.
Уникальных объектов (в нашей системе ресайз картинки, реэнкодинг видео и т.д. порождает новый объект) — больше 10 млн.

> Что из себя представляет сам кластер (в общих чертах какое железо и сколько машин).
Основной репликасет — две машины в конфигурации 1xX3430, 8gb, 8x2tb raid6 (железный)
Оффсайт бэкапы — конфигурация особо не важна, член репликасета с нулевым приоритетом.

> Как монга относитится к распределению узлов кластера по разным дата-центрам (т.е. не самая стабильная сеть и возможные долговременные потери связи между узлами).
Мы в таком режиме не используем (оффсайт реплика есть, но она в режиме write-only и оплога хватает, чтобы всегда быть ок).
Но вообще подозреваю, что особых проблем быть не должно. Единственная тонкость — до последнего времени стандартным методом в монговских драйверах было «fire and forget». Т.е. ты не мог быть уверен, получая «ок» из запроса, что объект уже доступен хотя бы другим сессиям, не говоря уж про фсинк на диск или репликацию. Сейчас по-умолчанию стоит «safe» режим, когда при создании документа метод в драйвере не вернет результат, пока данные реально не разойдутся по серверам.

> При удалении документа из монги, она фактически место на диске освобождает? или база постоянно пухнет?
Место на диске — не освобождает. Место в датафайлах — освобождается. При активном удалении и перезаписи периодически требует компактить базу. Мы решаем этот вопрос в основном тем, что не удаляем данные. :)

[Serafim]

> Основной репликасет — две машины в конфигурации 1xX3430, 8gb, 8x2tb raid6 (железный)
Т.е. на каждой машине 8х2-4=12 Тб, хотя скорее ближе к 11 Тб. Термин «репликасет» говорит о том, что один сервер является полной копией второго, верно? Тогда получается для хранения доступно всего лишь 11 Тб, а что вы будете делать когда надо будет сохранить 20 Тб, про то что в монге есть шардинг я слышал, но вот в деле не видел не укого, вы пробовали с ним работать? И вопрос еще вопрос про реплику: «на запись» доступен только один из серверов — мастер, а второй только на чтение? в случае сбоя с мастером, смена роли происходит автоматически? если да, то как об этом узнает приложение, ведь оно должно теперь «аплоадить» данные на другой хост.

> Место на диске — не освобождает. Место в датафайлах — освобождается. При активном удалении и перезаписи периодически требует компактить базу. Мы решаем этот вопрос в основном тем, что не удаляем данные. :)
В моем кейсе такой вариант (не удалять) не приемлем, я правильно понял, что при удалении данные просто помечаются как удаленные, но фактически место остается занятым, и правильно ли я понял что «компактить базу» это как раз и производить физическое удаление данных, если так, то один момент — в момент «компактиния» (простите за это слово) база лочится или с ней происходят другие не хорошие вещи?

[Данила Штань]

про то что в монге есть шардинг я слышал, но вот в деле не видел не укого, вы пробовали с ним работать?

пробовали. с учетом нашего юзкейса (в основном — выборка по ключу единственного индекса) — не вижу, где может быть проблема.

И вопрос еще вопрос про реплику: «на запись» доступен только один из серверов — мастер, а второй только на чтение? в случае сбоя с мастером, смена роли происходит автоматически? если да, то как об этом узнает приложение, ведь оно должно теперь «аплоадить» данные на другой хост

Об этом стоит почитать в документации монгодб. Если коротко — на запись доступен только primary, failover и выбор нового primary происходит автоматически. Приложению сообщаются сразу все адреса всех машин репликасета, оно внутри разбирается, куда писать, откуда читать.

В моем кейсе такой вариант (не удалять) не приемлем

А что за кейс такой? Есть у меня определенные сомнения.

я правильно понял, что при удалении данные просто помечаются как удаленные, но фактически место остается занятым, и правильно ли я понял что «компактить базу» это как раз и производить физическое удаление данных

Нет, на «помеченное» место вполне пишутся новые данные. Т.е. происходит то, что в ФС называется «фрагментация» данных, что приводит к снижению скорости чтения. «компактить базу» — это проводить «дефрагментацию».

в момент «компактиния» (простите за это слово) база лочится или с ней происходят другие не хорошие вещи?

лочится. поэтому компактим секондари (слейвы), потом заставляем мастер стать слейвом (другой слейв станет мастером) и компактим его. процедура происходит без перерыва в обслуживании.

[Serafim]

> А что за кейс такой? Есть у меня определенные сомнения.
А-ля рапидфайлс, пользователь загружает файл (до 4Гб) получает на него линк, файл удаляет спустя 30-суток с момента последнего запроса этого файла (данный сервис работает без какой-либо рекламы и ограничении в скорости, поэтому пользуется очень большой популярностью и ротация файлов там очень большая, в интернетах он неизвестен, т.к. загружать в него файлы могут только клиенты одного регионального (но крупного) провайдера (но скачивать может кто угодно)).

[Данила Штань]

Ну надо смотреть на скорость ротации, конечно. Но провести процедуру компакта раз в полгода с небольшой деградацией производительности/надежности мне не кажется проблемой.

Answer 6

[netherneon]

@Serafim Поведайте на чем остановились? Проблема которую вы затронули актуальна и по сей день... :)

Comments

[Serafim]

В проекте который описан в сабже приняли решение использовать то, что хорошо знаем - MogileFS (на серверах RAID не используется, избыточность достигается тем, что MogileFS сам раскладывает требуемое кол-во копий файлов на разных узлах). В другом проекте, который реализуем сейчас иследуем Swift и Elliptics, решение еще не принято, MogileFS не рассматриваем из-за единой точки отказа - база мета-данных (какой файл где лежит).

[Паша Андреев]

Serafim есть новости?