Hacker News Digest

В статье рассматриваются альтернативы MinIO для локального S3-хранилища в однозузовом режиме, с акцентом на простоту замены в Docker Compose и минимальные изменения кода. Автор тестирует несколько решений, сохраняя клиент mc для совместимости.

S3Proxy — лёгкий вариант на Java с Apache 2.0 лицензией, Docker-образом (5M+ загрузок) и хорошей S3-совместимостью. Конфигурация простая, но зависит от jclouds, который был перемещён в Apache Attic в mid-2025 — хотя для локального использования это, вероятно, не критично.

RustFS — проект на Rust с GUI, Docker-образом (100k+ загрузок) и Apache 2.0 лицензией. Однако недавно обнаружен серьёзный уязвимость (GHSA-h956-rh7x-ppgj), что вызывает осторожность. Проект находится в альфа-стадии, интерфейс выглядит полированным, но некоторые ссылки ведут на одну страницу — «свежая покраска». Подходит для демо, если легко заменить.

SeaweedFS — зрелый OSS-проект с S3-поддержкой с 2018 года (release 0.91), Docker-образом (5M+ загрузок) и Apache 2.0 лицензией. Требует отдельного конфига для аутентификации, но проект обещает упростить это. Имеет базовый UI, хотя сайт выглядит как enterprise-продукт без явной ссылки на GitHub — что может ввести в заблуждение. Простой переход, минимальные правки.

Garage — упоминается как сложный в настройке из-за строгой валидации ключей (например, ключ должен начинаться с GK и содержать 12 hex-байт), что избыточно для локальных демо и создаёт барьер входа. Не подходит как «drop-in» замена.

Apache Ozone и Ceph Object Gateway — отвергнуты как слишком тяжёлые: Ozone требует минимум четырех узлов для работы, Ceph — избыточен для локального стека. Оба имеют Hadoop-наследие и не подходят для лёгкой интеграции в Docker Compose для демонстраций.

Итого: для простой замены MinIO в локальном режиме лучшие варианты — S3Proxy и SeaweedFS; RustFS — рискован из-за уязвимости и альфа-статуса; остальные — избыточны.

Обсуждение подтверждает потерю доверия к MinIO из-за смены лицензии и выделяет альтернативы с опытом эксплуатации в продакшене: * **Garage**: стабилен в одноузловом режиме (до 10 ТБ), но требует NVMe для метаданных. Не поддерживает перебуферизацию, политики хранения на уровне бакета и строгую согласованность, что делает его непригодным для Iceberg. * **SeaweedFS**: надежная замена с поддержкой IAM, OIDC и Iceberg, но требует больше настроек; ранее были проблемы с API удаления пользователей и отсутствием S3 expiry rules. * **RustFS**: подходит для архивирования, но CVE в прошлом подорвали доверие к надежности. * **S3Proxy**: легкий, популярен (5M+ загрузок), рекомендуется для локальной разработки и тестирования. * **pgsty/minio**: форк MinIO, используется в end-to-end тестах как быстрый локальный симулятор. * **VersityGW**: поддерживает POSIX-бэкенд, сохраняя multipart-загрузки как реальные файлы, что упрощает отладку. * **LocalStack**: простое решение для разработки, особенно при необходимости других AWS-сервисов. * **JuiceFS** (китайский проект) и **Scality S3 (Zenko)** (требует актуальный Docker-репозиторий) — рабочие решения. * **Incus**: имеет встроенный S3-сервер для пользователей LXD-экосистемы (совместимость с S3 API не детализирована). * **S2** и **Filestash** с S3-шлюзом упомянуты без деталей опыта использования. Для Iceberg критична поддержка conditional GET/PUT/DELETE и ETag (строгая согласованность), поэтому SeaweedFS предпочтительнее Garage. В дискуссиях отметили, что альтернативы часто являются компромиссом по функционалу. Для простых локальных задач предлагают s3fs или прямой файловый доступ вместо перегруженного MinIO, хотя другие настаивают на необходимости S3-совместимости для интеграции. Также упомянуто, что для сценариев «good enough» AI-инструменты (например, Claude) позволяют быстро создать простой S3-прокси.

Автор успешно развернул самодельный S3-совместимый сервер на 10 ТБ, используя б/у Framework-ноутбук без экрана и внешний JBOD-массив дисков. В качестве ПО выбраны ZFS для файловой системы и Garage S3 для объектного хранилища. Система стабильно работала автономно несколько месяцев, накопив 10 ТБ данных, а после перезагрузки и обновления Garage с v1 до v2 продолжила работу без сбоев.

Изначально возникали проблемы из-за хранения метаданных SQLite на JBOD, подключённом по USB, что вызывало ошибки ZFS при высокой нагрузке. Решением стало перенос метаданных на внутренний накопитель ноутбука. Проект демонстрирует, что даже нестандартные конфигурации могут быть надёжными при грамотной настройке.

• Обсуждаются альтернативы для создания домашнего NAS: использование старого ноутбука Framework в корпусе Cooler Master, Raspberry Pi с LVM2, Dell T30 с ZFS или готовые решения вроде Ubiquti.
• Сравниваются S3-совместимые объектные хранилища: Minio (критика из-за урезания бесплатной версии), Garage (простота настройки), Ceph (сложность, но гибкость) и SeaweedFS (меньше ручной конфигурации).
• Поднимаются вопросы о конфигурации ZFS (использование RAIDZ1, зеркал, отправка снапшотов) и её пригодности для USB-подключений, а также альтернативах вроде btrfs.
• Обсуждаются сценарии использования самодельного S3: бэкапы (включая гибридные сценарии с AWS Glacier), хранение логов, APK и медиатеки.
• Высказываются опасения по поводу надежности JBOD over USB, рисков потери данных при случайном отключении и отсутствия избыточности для метаданных.

AWS S3 достигает экстремальной производительности в 1 петабайт в секунду и 150 миллионов запросов в секунду, несмотря на использование медленных жёстких дисков (HDD). Ключ к масштабированию — дешёвая экономика HDD: их цена за байт упала в 6 миллиардов раз с поправкой на инфляцию, а ёмкость выросла в 7,2 миллиона раз. Однако физические ограничения — механическое движение считывающих головок и скорость вращения пластин (~7200 оборотов в минуту — держат IOPS на уровне всего ~120 на диск уже 30 лет.

Система компенсирует это массовым параллелизмом: десятки миллионов дисков работают вместе, распределяя нагрузку. S3 использует многопользовательскую архитектуру, обеспечивая высокую доступность и долговечность данных при низкой стоимости. Это инженерное чудо, превращающее медленные, но дёшевые компоненты в мощнейший бэкбон современного интернета.

• Обсуждается архитектура AWS S3, включая использование HDD для хранения данных и SSD для метаданных и кеширования, а также применение эратур-кодирования и шардинга для повышения надежности и производительности.
• Поднимается вопрос о том, как S3 достигает высокой пропускной способности благодаря массовому параллелизму миллионов дисков, что позволяет превысить производительность отдельного HDD.
• Участники обсуждают возможные альтернативы S3 для развертывания в homelab или частных облаках, такие как Ceph, MinIO, SeaweedFS, Garage и Gluster, отмечая их особенности и требования к железу.
• Затрагивается экономический аспект: несмотря на падение цен на HDD, стоимость S3 остается стабильной годами, что связывают с недостатком конкуренции и высокой рентабельностью для AWS.
• В комментариях уточняются технические детали, например, расчет среднего времени поиска на диске и использование различных схем шардинга, отличных от упомянутых в исходной статье.