Как я искал замену MinIO S3 и написал свой S4 на Rust / Хабр

Спойлер для тех кто не в курсе:

В начале 2025 года компания MinIO в лице сооснователя Harshavardhana начала поэтапно сворачивать свою версию Community Edition. В феврале из open-source версии был вырезан веб-интерфейс администрирования - управление политиками, мониторинг, репликация, IAM - всё это переехало в коммерческий продукт AIStor с ценником от $96 000 в год. Пользователям оставили лишь базовый object browser и CLI-утилиту mc. В мае последовало удаление поддержки OIDC-аутентификации. В октябре MinIO прекратил публикацию Docker-образов и готовых бинарников - причём аккурат в момент раскрытия критической CVE-уязвимости. А в декабре 2025-го проект официально перешёл в режим maintenance mode: никаких новых фич, pull request'ы не принимаются, только точечные security-фиксы по усмотрению компании.

Мой опыт с Minio

В моей инфраструктуре MinIO присутствует на нескольких стендах с 3ТБ данных, и также в домашней лабе для бэкапов Synology, всех ПК, репозиториев кода. 10 января вышла интересная статья про альтернативы Minio, где я заинтересовался вопросом миграции своего "нажитого". Критерии поиска были такие - S3 Full Compatibility, OpenLicense (Apache 2.0 и тд), Web UI для администрирования, небольшое потребление ресурсов, а также желательно чтобы было из коробки Versioning, Crashrecovery, Deduplication, Lifecycle policy, Object Locking, IAM, и желательно метрики

Желание не всегда совпадает с реальностью..

Табличка по альтернативам - приоритету слева направо (простота, full s3, надежность)

Решение	Простота	S3 API	Репликация	Версии	Locking	Lifecycle
RustFS	9/10 🟢	✅ 100%	🟢 Высокая (распред.)	✅	✅	✅
Garage	9/10 🟢	⚠️ Базовый	🔥 Отличная (CRDT)	❌	❌	⚠️ Частично
MinIO + OpenMaxIO	8/10 🟢	✅ 100%	🟢 Высокая (Erasure)	✅	✅	✅
SeaweedFS	7/10 🟡	✅ Высокая	🟢 Высокая (O(1))	✅	✅	✅
Apache Ozone	4/10 🔴	✅ Высокая	🔥 Максимальная (Raft)	✅	✅	✅
Ceph (RGW)	3/10 🔴	✅ Высокая	🔥 Максимальная (CRUSH)	✅	✅	✅

MinIO и Garage сразу вылетают по лицензии, поддержки CE и отсутствии версионирования

Если отвлечься от первой колонки "Простота", то можно предположить что победитель тут RustFS или SeaweedFS, но к сожалению это не так.

ПОЧЕМУ не RustFS:

Агрессивная пиар кампания, построенная на « костях » Minio, громкие заголовки. В последние месяцы проект очень активно пушится через заказные статьи на Medium. Явно прослеживается модель - набрать аудиторию корпоративных пользователей. В этом нет ничего плохого, но риск смены лицензии очень высокий, вопрос лишь времени
На сайте rustfs используются термины вроде "Limitless Scalability" и "EB-level storage capacity". Для проекта, архитектура которого еще до конца не стабилизировалась, заявлять поддержку эксабайтных хранилищ смешно.
По баг-репортам, понятно, что на объектах размером 512KB и 1MB производительность RustFS падает в 2 раза по сравнению с MinIO И также мой личный тест на слабом железе был завален rustfs'ом (Ошибки при concurrency: Под высокой параллельной нагрузкой (warp mixed тесты) система начинает сыпать ошибками, упирается в высокий iowait). Кластерный режим (Distributed mode) до сих пор носит статус экспериментального

Почему не остальные SeaweedFS / Ceph / Apache Ozone S3 и тд:

Высокая кривая в установке и поддержке. Куча нод - master, filer, volume, gateway. В общем для самых отважных
Дорого для инфраструктуры

Что в сухом остатке

Вариантов не много, больше всего душа лежала к SeaweedFS, проект стабильный и надежный, но поддерживать и следить за этим парком нод не очень хочется, минус еще - ручное расширение volume нод, в итоге пошел другим путем..

Я просто взял и написал свой S3, то есть S4

... в котором есть все из коробки:

Имел ли я на это право?) Считаю, что да. Как бы это не безумно звучало, но хочешь сделать хорошо, сделай это сам. Во-первых хотелось нормальной альтернативы Minio, которой по сути на данный момент нет. Во-вторых за плечами несколько лет разработки бэка, поэтому сделать аналог S3 не такая и проблема

Из чего состоит S4 ?

Github https://github.com/s4core/s4core
Сайт https://s4core.com
Документация https://docs.s4core.com

Написан на Rust
Полная совместимость с S3 API - Object Locking (WORM), Versioning & Lifecycle, IAM & RBAC со встроенной системой ролей (Reader, Writer, SuperUser) и
JWT-авторизацией.
Дедупликация данных - Content-Addressable Storage: система считает SHA-256 хеш контента. Загрузишь один и тот же файл 10 раз - физически на диске он будет
лежать в одном экземпляре.
Готовый веб интерфейс и мониторинг - В комплекте современная админка на Next.js + эндпоинт для Prometheus, позволяющий отслеживать латентность, IOPS и коэффициент
дедупликации в реальном времени.
Архитектура хранения - В отличие от решений, которые кладут каждый объект в отдельный файл на диске, S4 использует Bitcask-style storage. Миллиард объектов
хранится всего в ~1000 больших файлах - никакого Inode Exhaustion. Объекты меньше 4 КБ сохраняются прямо в метаданных (база redb), что даёт молниеносное чтение
без лишних операций ввода-вывода. Данные не перезаписываются «поверх» - любая запись это append в конец лога.
Crash Recovery-Каждый блоб защищён CRC32-контрольной суммой, fsync гарантирует сброс на диск до ответа клиенту. Метаданные хранятся в ACID-базе redb. Даже
если база метаданных потеряна - движок при старте сканирует все volume-файлы, проверяет CRC32 каждого блоба и полностью восстанавливает индекс и карту
дедупликации из append-only логов. Данные не теряются.

Немного про архитектуру

s4-server- приложение: конфигурация, TLS, запуск воркеров.
s4-api - сетевой слой на Axum: парсинг S3-запросов, аутентификация AWS Signature V4, роутинг.
s4-core -сердце системы: append-only тома, ACID-индекс на redb, дедупликатор (SHA-256), CRC32-валидация и crash recovery.
s4-features - бизнес-логика поверх ядра: версионирование, Object Lock, lifecycle-политики, IAM с JWT.
s4-compactor -фоновый процесс: находит «мёртвые» блобы в старых томах, переносит живые в новый том, освобождает место.

А теперь про установку и тестирование

Quick start for DEV:

  git clone https://github.com/s4core/s4core.git
  cd s4core
  cargo build --release
  ./target/release/s4-server
  # Готово — S4 слушает на http://127.0.0.1:9000

Docker:

docker run -d \
  --name s4core \
  -p 9000:9000 \
  -v s4-data:/data \
  -e S4_ACCESS_KEY_ID=myaccesskey \
  -e S4_SECRET_ACCESS_KEY=mysecretkey \
  -e S4_ROOT_PASSWORD=password12345 \
  s4core/s4core:latest

Логинимся и проверяем:

aws --endpoint-url http://localhost:9000 s3 mb s3://test-bucket
aws --endpoint-url http://localhost:9000 s3 cp file.txt s3://test-bucket/
aws --endpoint-url http://localhost:9000 s3 ls s3://test-bucket

Production ready:

  services:
    s4core:
      image: s4core/s4core:latest
      restart: unless-stopped
      ports:
        - "9000:9000"
      volumes:
        - s4-data:/data
      environment:
        - S4_ACCESS_KEY_ID=myaccesskey
        - S4_SECRET_ACCESS_KEY=mysecretkey
        - S4_ROOT_PASSWORD=password12345

    s4-console:
      image: s4core/s4console:latest
      restart: unless-stopped
      ports:
        - "3000:3000"
      environment:
        - S4_BACKEND_URL=http://s4core:9000
      depends_on:
        - s4core

  volumes:
    s4-data:

После запуска:

S4 API: https://localhost:9000
Web Console: http://localhost:3000 (логин с root-кредами)

Почему модель лицензирования OpenCore (Apache 2.0 + ELv2)?

Весь основной код S4Core - это Apache 2.0: используй, форкай, встраивай в свои продукты без ограничений. Никаких скрытых лимитов, никакого «community edition с обрезанными фичами».

Корпоративные возможности (LDAP, multi-node репликация, приоритетная поддержка с SLA) живут в отдельной директории ee/ под Elastic License 2.0 - исходный код открыт для аудита. На данный момент в разработке.

Зачем так?
Крупные компании с требованиями к SLA и энтерпрайз-интеграциям - получает поддержку и дополнительный функционал от моей команды.

Чего не хватает в S4Core и что будет реализовано:

Кластерный режим с репликацией - горизонтальное масштабирование, consistent hashing, Raft-репликация. Уже в разработке, планирую выкатить в ближайшие недели (возможно еще неделя потребуется на тестирование).
Compaction Worker - фоновый сборщик мусора: переносит живые блобы из старых томов в новые, освобождая место после удалений.
Расширенный IAM - полноценные группы, политики на уровне бакетов (Bucket Policies), гранулярные права доступа. Многое из этого уже присутвует в S4Core, но для EE надо шире.
CLI-утилита (аналог mc в MinIO) - консольный инструмент для администрирования: алиасы серверов, ls/cp/rm/mirror, управление пользователями и политиками. Пока в раздумье с этим, так как CLI уже есть включая aws cli и куча других
Расширенный Lifecycle - перемещение между классами хранения, фильтрация по тегам и размеру, автоматическая очистка незавершённых multipart-загрузок.
Audit Log - раздел «кто, что и когда сделал» для полной прозрачности действий на сервере. .. и еще порядка 10 пунктов

Что будет в Enterprise версии, и будет НЕ доступно в CE?

Масштабирование и отказоустойчивость:

Горизонтальное масштабирование на неограниченное количество нод
Raft-репликация с автоматическим failover
Cross-region репликация и гео кластеры
Автоматическое перераспределение данных при добавлении/удалении нод

Корпоративная авторизация:

LDAP / Active Directory
RADIUS
SAML 2.0 / OpenID Connect (SSO)
Kerberos
Multi-tenant изоляция с отдельными квотами и политиками

Интеграция с внешними сервисами:

HashiCorp Vault - управление ключами шифрования (KMS)
Event-уведомления об операциях с объектами
Elasticsearch - полнотекстовый поиск по метаданным
Splunk / Datadog / Grafana Cloud - расширенная телеметрия
Расширенные метрики Prometheus

Безопасность и compliance:

Encryption at Rest (AES-256) с ротацией ключей
Подробный Audit Log с экспортом в SIEM-системы
Immutable Audit Trail для регуляторных требований

Поддержка и SLA:

Приоритетная техподдержка
Помощь с миграцией, оптимизацией

Эпилог

S4Core ещё в активной фазе тестирования, но даже текущая alpha-версия уже прошла серьёзные нагрузочные тесты: несколько терабайт данных, смесь крупных и мелких файлов, тестирование на древнем железе с HDD. По итогу процент отказа - 0%, ни одного потерянного объекта. Для сравнения с другими решениями опубликую отдельную статью с реальными цифрами.

Буду рад найти единомышленников в развитии проекта, а также в тестировании 🤝

Всем спасибо, кто дочитал!