Garage или SeaweedFS: что выгоднее и когда

MAATRIX

Оба проекта дают S3-совместимый API на вашем железе без привязки к AWS — и на этом сходство почти заканчивается. Garage и SeaweedFS решают принципиально разные задачи, просто обе задачи в итоге упираются в один и тот же запрос "нужно своё объектное хранилище". Разберём, где какой инструмент реально выигрывает, а где вы просто зря потратите вечер на неподходящий выбор.

Garage: репликация по зонам, а не erasure coding

Garage — проект французской ассоциации Deuxfleurs, написанный на Rust специально под self-hosted инфраструктуру небольших сообществ. Ключевая идея — явные зоны (zone): вы говорите Garage, в каком дата-центре или регионе стоит каждый узел, и хранилище само следит, чтобы копии объекта не оседали в одной зоне.

Это принципиально отличает Garage от классических распределённых хранилищ, включая MinIO в кластерном режиме:

• Репликация (по умолчанию replication_factor = 3), а не erasure coding — проще для узлов с разным объёмом диска и не самой быстрой сетью между ними.
• Узлы могут стоять в разных странах — RU/US/UK на трёх обычных VPS вполне рабочий сценарий, задержки между зонами Garage переживает штатно, просто балансировка данных после layout apply займёт больше времени, чем в одной сети.
• Бинарник занимает единицы мегабайт, метаданные — в LMDB или SQLite, зависимостей почти нет.
• Из коробки нет полноценной админ-консоли уровня MinIO Console — управление через CLI garage и небольшой Admin API.

Разворачивается Garage через один TOML-файл на узел плюс несколько команд layout assign для назначения зон — подробный пошаговый разбор есть в статье про установку Garage на VPS. Если задача — три недорогих сервера в разных локациях, которые вместе переживают падение любого одного из них, Garage закрывает её почти без лишних настроек.

SeaweedFS: архитектура под миллионы мелких файлов

SeaweedFS написан Крисом Лу изначально по мотивам Facebook Haystack — системы, спроектированной под миллиарды маленьких файлов с минимальными накладными расходами на метаданные. Архитектура строится на двух базовых слоях:

• Master — знает только про volume-серверы и свободное место на них, про отдельные файлы ничего не хранит.
• Volume server — хранит данные внутри больших volume-файлов (по умолчанию до 30 ГБ), а метаданные конкретного файла — это просто смещение и размер внутри такого volume-файла, порядка 40 байт на объект вместо сотен байт inode обычной ФС.

Поверх этих слоёв — опциональный filer (REST/POSIX-подобное дерево каталогов, метаданные в LevelDB, PostgreSQL, MySQL или Redis) и S3 API, работающий через filer и понимающий стандартные S3-клиенты.

Это даёт SeaweedFS реальное преимущество именно на объёме: там, где у Garage или MinIO рост числа файлов линейно съедает память под метаданные, SeaweedFS держит эти накладные расходы почти постоянными за счёт компактного формата volume-файлов. Но география узлов здесь не главная идея — кластер SeaweedFS обычно живёт в одной сети или одном облаке, геораспределённость не входит в число исходных задач проекта. Установка одним weed server на старте и разнесение master/volume/filer по систем-юнитам при росте — в статье про установку SeaweedFS на VPS.

Ресурсы и порог входа

Оба проекта скромны по требованиям в сравнении с тяжёлыми распределёнными ФС вроде Ceph, но разница в профиле нагрузки на память и диск есть.

Точные цифры RAM у Garage сильно зависят от числа объектов и интенсивности листингов бакетов — если хотите прикинуть конкретно под свою нагрузку, в статье сколько RAM нужно для Garage разобран подход к расчёту. Для SeaweedFS официальных таких же жёстких расчётов меньше — ориентируйтесь на то, что сам master и volume-серверы держат память скромно, а вот filer с внешней БД метаданных при большом дереве каталогов может съедать заметно больше — тестируйте на своих объёмах, прежде чем закладывать конфигурацию под прод.

Где каждый спотыкается

Ни один из проектов не универсален, и стоит проговорить это прямо, а не только хвалить.

У Garage:

• Меньше зрелой документации и сообщества, чем у MinIO — если что-то ведёт себя неожиданно, чаще приходится читать исходники или issue-трекер, чем находить готовый ответ на форуме.
• Нет lifecycle-политик уровня MinIO (автоматическое удаление объектов по возрасту, переход между классами хранения) и ограниченная поддержка части расширений S3 API — для базового PUT/GET/DELETE, presigned URL и статического хостинга сайта хватает, для более специфичных сценариев стоит сверяться с документацией под вашу версию.
• На большом количестве мелких объектов Garage не проектировался специально под этот сценарий — он справится, но не даёт того выигрыша по памяти на метаданные, который даёт SeaweedFS.

У SeaweedFS:

• Геораспределённость не основная идея архитектуры — кластер из нескольких master-серверов с Raft-консенсусом собрать можно, но это не так просто "из коробки", как назначение зон в Garage, и типовые инструкции чаще предполагают одну сеть или одно облако.
• Больше движущихся частей при масштабировании: master, volume, filer, S3-шлюз — каждый со своим systemd-юнитом и портом, а filer на внешней БД метаданных добавляет ещё одну зависимость, за здоровьем которой нужно следить отдельно.
• Диск не резервируется заранее — SeaweedFS просто пишет, пока есть место, и если не отслеживать заполнение отдельно, ошибки записи вы увидите уже по факту, а не заранее.
• Для сценария "просто пара сотен тысяч файлов среднего размера" выигрыш архитектуры Haystack практически не ощущается — это тот случай, когда MinIO или Garage проще в эксплуатации без потери в результате.

Сравнение и по какому сценарию выбирать

У вас три (или больше) недорогих VPS в разных странах, и задача — пережить падение любого одного дата-центра. Берите Garage. Назначаете зоны, layout apply — и хранилище само следит, чтобы копии не оседали в одной локации. Меньше всего лишних решений на старте.

У вас миллионы мелких файлов — превью, тайлы, вложения, чанки — и они растут быстрее, чем вы успеваете следить за памятью под метаданные. Берите SeaweedFS. Архитектура master/volume специально под это спроектирована, и разница станет заметна именно на масштабе, а не на первых тысячах объектов.

У вас средний по размеру и количеству объём файлов, один регион, и хочется минимум сложности. Тут ни Garage, ни SeaweedFS не дают решающего преимущества друг перед другом — возможно, обычный MinIO окажется проще в администрировании за счёт более зрелой документации и консоли, если нет специфичной задачи под географию или плотность файлов.

У вас и геораспределённость, и миллионы мелких файлов одновременно. Честного единого ответа нет — оба проекта решают только одну из двух задач хорошо. Практичный компромисс: разворачивать SeaweedFS-кластер в одном регионе как основное хранилище, а офсайт-копию через S3 API синхронизировать rclone-ом на второй сервер в другой локации по расписанию — так вы не собираете два хранилища в одно ради экономии на настройке, а честно решаете каждую задачу тем инструментом, который под неё сделан.

Если пока не определились с самой конфигурацией сервера под хранилище, стоит сначала прикинуть объём и требования к диску — в статье про выделенный сервер под файловое хранилище на терабайты разобрано, как считать нужный объём и какая конфигурация диска реально нужна под растущий архив.

Частые вопросы