Как хранить 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
Надо:
Простой (к примеру основанный на HTTP) интерфейс CRUD-операции с объектами в хранилище (можно без U). Требования работать с хранилищем как с обычным локальным разделом (POSIX-совместимая файловая система) нет, но если такое тоже достижимо — будет хорошо.
Возможность прочитать фрагмент объекта (необходимо для псевдостримминга видео).
Иметь избыточность данных (raid не решает задачи, когда вышел из строя весь сервер или с сервером потеряна связь), т.е. один объект должен храниться как минимум на двух серверах.
Иметь возможность разнести сервера по разным (двум) дата-центрам.
Крайне желательно, чтобы система не требовала отдельного сервера для хранения meta-данных (так называемый name-сервер), т.к. это создает дополнительную точку отказа.
Система должна иметь возможность анализировать свое состояние, т.е. проверять наличие необходимого числа копий для объектов, в идеале проверка консистентности объектов (но это накладывает определенные требования, такие как вычисление контрольной суммы для объектов и хранение трех копий, для возможности чтения с кворумом, поэтому это не требование, а пожелание к системе).
Система должна иметь возможность перераспределить объекты между хранилищами, т.е. когда появится четвертый сервер, то данные должны быть равномерно перераспределены между всеми серверами.
Совсем идеально иметь возможность установить ttl для объекта (т.е. чтобы по прошествии заданного времени объект был удален или помечен как удаленный).
Система должна уметь удалять объекты, т.е. когда объект удаляется или помечается как удаленных, он действительно должен быть удален, допускается это делать с задержкой.
Решение должно быть полностью программным, никакого дополнительного оборудования или замена существующего.
Что уже пробовали:
MogileFS. Данное решение было выбрано около 3-лет назад и используется сейчас, в принципе оно отвечает ряду требований, но сложность его сопровождения (на деле это набор perl-скриптов) и отсутствие поддержки остальных требований заставило меня задуматься и поискать альтернативы.
GridFS (mongodb). Очень медленно и сыро, я не буду детально расписывать что не так с гридфс, отмечу что тестировал его полтора года назад, возможно сейчас с ним все намного лучше, поэтому просто просьба этот вариант не предлагать, я о нем знаю.
Просьба к сообществу
Буду благодарен услышать ваши предложения относительно выбора программного обеспечения для хранилища отвечающего указанным выше требованиям. Отдельно интересует услышать об опыте работы с Elliptics (ioremap.net, elliptics.ru) из описании на сайтах складывается впечатление, что это практически «серебряная пуля», но отсутствии сведений о реальном использовании вызывают опасение использовать данное решение в бою. Спасибо.
Три сервера, следующей конфигурации:
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
Надо:
Простой (к примеру основанный на HTTP) интерфейс CRUD-операции с объектами в хранилище (можно без U). Требования работать с хранилищем как с обычным локальным разделом (POSIX-совместимая файловая система) нет, но если такое тоже достижимо — будет хорошо.
Возможность прочитать фрагмент объекта (необходимо для псевдостримминга видео).
Иметь избыточность данных (raid не решает задачи, когда вышел из строя весь сервер или с сервером потеряна связь), т.е. один объект должен храниться как минимум на двух серверах.
Иметь возможность разнести сервера по разным (двум) дата-центрам.
Крайне желательно, чтобы система не требовала отдельного сервера для хранения meta-данных (так называемый name-сервер), т.к. это создает дополнительную точку отказа.
Система должна иметь возможность анализировать свое состояние, т.е. проверять наличие необходимого числа копий для объектов, в идеале проверка консистентности объектов (но это накладывает определенные требования, такие как вычисление контрольной суммы для объектов и хранение трех копий, для возможности чтения с кворумом, поэтому это не требование, а пожелание к системе).
Система должна иметь возможность перераспределить объекты между хранилищами, т.е. когда появится четвертый сервер, то данные должны быть равномерно перераспределены между всеми серверами.
Совсем идеально иметь возможность установить ttl для объекта (т.е. чтобы по прошествии заданного времени объект был удален или помечен как удаленный).
Система должна уметь удалять объекты, т.е. когда объект удаляется или помечается как удаленных, он действительно должен быть удален, допускается это делать с задержкой.
Решение должно быть полностью программным, никакого дополнительного оборудования или замена существующего.
Что уже пробовали:
MogileFS. Данное решение было выбрано около 3-лет назад и используется сейчас, в принципе оно отвечает ряду требований, но сложность его сопровождения (на деле это набор perl-скриптов) и отсутствие поддержки остальных требований заставило меня задуматься и поискать альтернативы.
GridFS (mongodb). Очень медленно и сыро, я не буду детально расписывать что не так с гридфс, отмечу что тестировал его полтора года назад, возможно сейчас с ним все намного лучше, поэтому просто просьба этот вариант не предлагать, я о нем знаю.
Просьба к сообществу
Буду благодарен услышать ваши предложения относительно выбора программного обеспечения для хранилища отвечающего указанным выше требованиям. Отдельно интересует услышать об опыте работы с Elliptics (ioremap.net, elliptics.ru) из описании на сайтах складывается впечатление, что это практически «серебряная пуля», но отсутствии сведений о реальном использовании вызывают опасение использовать данное решение в бою. Спасибо.
Похожие публикации
Как лучше организовать дублирование сайта для защиты от сбоев?
404. Заблокирован за спам
Защита от DDoS html сайта
Как сделать незаметные обновления сайта?
О доменах и хостингах
Нет комментариев