MogileFS — один из первых опенсорсных ответов на задачу, к которой рано или поздно приходит любая крупная веб-платформа: как надёжно и дёшево хранить десятки миллионов пользовательских файлов, не покупая SAN и не доверяя ни одному отдельному диску? В этом руководстве разбираемся, что такое MogileFS, как именно работает его архитектура, чем он отличается от современных альтернатив вроде Ceph и S3-совместимых хранилищ и как рассчитать реальный кластер на выделенных серверах.
Одним предложением: MogileFS — это распределённая файловая система уровня приложения с открытым кодом, которая хранит каждый файл несколькими целыми репликами на независимых узлах, а базой MySQL отслеживает, где лежит каждая копия — давая отказоустойчивость без RAID и общего хранилища.
MogileFS кратко
| Свойство | Значение |
|---|---|
| Тип | Распределённая ФС уровня приложения / объектное хранилище |
| Автор | Brad Fitzpatrick — Danga Interactive (команда LiveJournal) |
| Первый релиз | Середина 2000-х (разработан ~2004 для LiveJournal) |
| Язык | Perl (серверная часть) |
| Лицензия | Свободное ПО — те же условия GPL / Artistic, что и у Perl |
| Метаданные | MySQL (единый источник истины о расположении файлов) |
| Демон хранения | mogstored — отдаёт данные по HTTP / WebDAV |
| Демон-координатор | mogilefsd (трекер) |
| Модель доступа | По непрозрачному ключу через клиентскую библиотеку — не POSIX-монтирование |
| Избыточность | Репликация целых файлов (настраиваемое число копий), без RAID |
| Оптимальная нагрузка | Write-once / read-many blob-ы, отдаваемые по HTTP |
Ключевая идея: без RAID, без единой точки отказа
Традиционное хранилище покупает надёжность железом — RAID-массивы, дублированные контроллеры, дорогие общие файлеры. MogileFS идёт обратным путём: считать, что железо дешёвое и обязательно откажет, а надёжность брать из софта. Каждый файл хранится как одна или несколько целых реплик на независимых узлах. Ни страйпинга, ни чётности для перестроения. Если диск умирает, копии на других узлах остаются целыми, и фоновый процесс просто до-реплицирует их до нужного числа.
Поскольку она работает на уровне приложения, а не как ядерная ФС, MogileFS не монтируется как NFS и не даёт POSIX-семантики. Приложение обращается к ней через клиентскую библиотеку и адресует файлы непрозрачным ключом, а не путём. Именно этот компромисс позволяет ей горизонтально масштабироваться на обычных дисках на бюджетных выделенных серверах.
Четыре компонента
| Компонент | Демон / технология | Роль | Хранит состояние? |
|---|---|---|---|
| Трекер | mogilefsd | Stateless-координатор: отвечает «где ключ X?», выдаёт места для записи, планирует репликацию | Нет |
| База метаданных | MySQL | Единый источник истины: файл → устройства, домен, класс, состояние репликации | Да — резервируйте её |
| Узел хранения | mogstored | Лёгкий HTTP/WebDAV-демон с данными файлов на обычных локальных ФС | Только данные |
| Клиент | библиотека (Perl, PHP, Python, Ruby, Java, Go) | Хранит/читает/удаляет по ключу; читает и пишет напрямую на узлы | Нет |
Поскольку всё общее состояние лежит в MySQL, трекеры stateless и взаимозаменяемы — их запускают несколько для отказоустойчивости, и любой обслужит любой запрос. Административная утилита mogadm регистрирует хосты, устройства, домены и классы. База метаданных — единственный компонент, который нужно защищать: держите её на надёжном хранилище и реплицируйте (обычно MySQL primary/replica).
Домены, классы и репликация
MogileFS раскладывает файлы по доменам (пространствам имён, например по одному на приложение) и классам внутри домена. Класс несёт политику репликации — прежде всего mindevcount, минимальное число отдельных устройств, на которые должен быть скопирован файл этого класса. Фоновый репликатор постоянно сверяет реальность с метаданными и создаёт или перемещает копии, пока каждый файл не удовлетворит политике класса. Тот же механизм самовосстанавливает кластер после отказа узла или диска.
| Пример класса | mindevcount | Типичное применение | Накладные расходы |
|---|---|---|---|
| thumbnails | 2 | Дешёво пересоздаваемые производные | 2× |
| user_uploads | 3 | Невосстановимые оригиналы | 3× |
| cache | 1 | Временные, пересоздаваемые данные | 1× |
Целевая надёжность имеет прямую цену: класс с mindevcount=3 утраивает сырую ёмкость, которую нужно заложить. Это число — главный драйвер того, сколько диска потребует кластер, — планируйте его до покупки узлов.
Как записывается файл
- Клиент просит трекер создать новый файл в заданном домене/классе.
- Трекер выбирает подходящие устройства и возвращает временные URL для записи.
- Клиент делает
PUTданных напрямую на один или несколько узлов хранения по HTTP. - Клиент сообщает трекеру о завершении записи; трекер фиксирует расположение файла и ключ в MySQL.
- Асинхронно репликатор доводит файл до полного числа реплик его класса на разных устройствах.
«MogileFS — наша распределённая файловая система с открытым кодом. Её свойства: уровень приложения — не нужны специальные модули ядра; отсутствие единой точки отказа; автоматическая репликация файлов; лучше, чем RAID; плоское пространство имён.»
— Danga Interactive, оригинальное описание проекта MogileFS
MogileFS против Ceph, GlusterFS и S3/MinIO
MogileFS старше большей части современного стека распределённого хранения и занимает намеренно узкую нишу. Вот как он соотносится с инструментами, с которыми его чаще всего сравнивают:
| Система | Тип | Доступ | POSIX-монтирование? | Избыточность | Оптимальна для |
|---|---|---|---|---|---|
| MogileFS | ФС уровня приложения | Ключ через клиент / HTTP | Нет | Целые реплики | Масштабные write-once/read-many blob-ы |
| Ceph (RADOS/RGW) | Объект + блок + ФС | S3/Swift, RBD, CephFS | Да (CephFS) | Репликация или erasure coding | Универсально, до эксабайтов |
| GlusterFS | POSIX распределённая ФС | Монтирование (FUSE/NFS) | Да | Реплицированные / dispersed тома | Общая POSIX-ФС |
| MinIO / S3 | Объектное хранилище | S3 API | Нет | Erasure coding | Современные S3-совместимые приложения |
Если нужна монтируемая POSIX-ФС, низколатентные случайные чтения/записи или стандартный S3 API — уместнее один из остальных. Если же нужно предельно простое blob-хранилище целыми репликами, переживающее потерю узла без RAID и масштабируемое добавлением дешёвых дисков, — MogileFS по-прежнему делает это чисто.
Где MogileFS уместен — и где нет
Отлично подходит: пользовательские загрузки, галереи изображений, вложения почты, статические ассеты — всё, что адресуется по ID и отдаётся по HTTP, пишется один раз и читается многократно. Сильные стороны — дешёвое горизонтальное масштабирование, устойчивость к отказу узлов без RAID и операционная простота для такой нагрузки.
Плохо подходит: монтируемая POSIX-ФС, низколатентные случайные чтения/записи, частая модификация на месте или строгая транзакционность. Здесь берите CephFS, GlusterFS или S3-совместимое хранилище.
Запуск MogileFS на выделенных серверах
Минимальный продакшн хочет как минимум два узла хранения на разных физических машинах (чтобы класс с двумя репликами пережил потерю целого хоста), плюс два трекера и реплицированную пару MySQL под метаданные. Каждый узел хранения — это просто дешёвые диски и запущенный mogstored; масштабирование — добавлением новых. Именно такая нагрузка ложится на несколько независимых выделенных серверов в разных доменах отказа, а не на одну большую машину — нужна изоляция диска и сети, а не общее шасси.
Для слоя хранения важнее ёмкость на доллар, чем сырая скорость, поэтому ёмкие HDD выделенные серверы или специализированные storage-серверы — естественный дом для реплик. Узел MySQL с метаданными и трекеры разместите на быстрых NVMe выделенных серверах, а если реплики распределены по нескольким площадкам — заложите 10 Gbps выделенные серверы, чтобы ре-репликация после сбоя не забивала каналы. Вот актуальные выделенные серверы, на которых можно поднять узлы хранения:
Рекомендуемый расчёт узлов
| Роль | CPU | RAM | Диск | Сеть |
|---|---|---|---|---|
| Узел хранения (mogstored) | Скромный (2–4 ядра) | 8–16 ГБ | Ёмкий HDD/SSD, JBOD — RAID не нужен | 1–10 Gbps |
| Трекер (mogilefsd) | 2–4 ядра | 4–8 ГБ | Небольшой SSD/NVMe | 1 Gbps+ |
| MySQL с метаданными | 4+ ядра | 16 ГБ+ | NVMe (надёжный, реплицированный) | 1 Gbps+ |
Частые вопросы
MogileFS ещё поддерживается и используется в 2025?
MogileFS скорее зрелый и стабильный, чем активно развивающийся. Он остаётся крепким, проверенным в бою вариантом для своей ниши — объёмное blob-хранилище на серийном железе, — хотя новые объектные хранилища и кластерные ФС забрали большинство универсальных сценариев.
Использует ли MogileFS RAID?
Нет. MogileFS намеренно отказывается от RAID и вместо этого держит несколько целых копий каждого файла на разных устройствах и хостах. Проект исторически называл это «лучше, чем RAID», потому что потерянный диск или узел восстанавливается ре-репликацией с уцелевших копий, а не перестроением массива.
Можно ли смонтировать MogileFS как обычную ФС?
В привычном смысле — нет. Это хранилище уровня приложения, доступ к которому идёт по ключу через клиентскую библиотеку или по HTTP; POSIX-семантики и монтирования ядром оно не даёт. Нужна монтируемая ФС — используйте GlusterFS или CephFS.
Какая БД нужна MogileFS?
База MySQL хранит все метаданные — какие файлы существуют и на каких устройствах лежат их реплики. Трекеры stateless; именно MySQL нужно резервировать и делать высокодоступной.
Сколько серверов нужно для старта?
Для реальной избыточности — минимум два узла хранения на разных физических хостах плюс хотя бы один трекер и один MySQL (по два для отказоустойчивости). Двух независимых выделенных серверов достаточно, чтобы пережить отказ целого хоста при классе с двумя репликами.
Историческая справка и источники
MogileFS вырос из инженерного стека LiveJournal середины 2000-х и вместе с memcached, Perlbal и Gearman стал известным кирпичиком для масштабирования крупных веб-проектов на серийном железе. Сегодня он остаётся надёжным выбором для своей ниши. Первоисточники: страница и код проекта MogileFS (изначально danga.com/mogilefs, теперь на GitHub), Perl-клиент на MetaCPAN и архитектурные заметки Danga Interactive эпохи LiveJournal.
