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

Дано:
  • Три сервера, следующей конфигурации:

    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) из описании на сайтах складывается впечатление, что это практически «серебряная пуля», но отсутствии сведений о реальном использовании вызывают опасение использовать данное решение в бою. Спасибо.
  • Вопрос задан
  • 6891 просмотр
Пригласить эксперта
Ответы на вопрос 6
qxfusion
@qxfusion
Посмотрите в сторону OCFS2 (распределенная, без мета сервера, проверено в продакшене, без «волшебных грибов») + DRDB (создание RAID over Network) — для DRDB рекомендую использовать или 2x10Gbps (дуплетом) или 1x40Gbps учитывая объемы.

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

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

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

Я бы лично для OCFS2 рекомендовал сменить ОС на RHEL/OEL/CloudLinux/CentOS — т.к. там она работает хорошо, а вот с другими ОС…
Ответ написан
@inkvizitor68sl
Linux-сисадмин с 8 летним стажем.
Elliptics используется, вполне себе работает. Яндекс, Nokia.
Действительно, в данном случае — он является решением. Можно попробовать pohmelfs натянуть на него, но он плохо работает.

Только за обновлениями следить нужно.
Ответ написан
Комментировать
akalend
@akalend
программирую
>отдельно интересует услышать об опыте работы с Elliptics
специально пойду в субботу слушать про это чудо.
Ответ написан
netherneon
@netherneon
@Serafim Поведайте на чем остановились? Проблема которую вы затронули актуальна и по сей день... :)
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы