Как я искал замену 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, надежность)

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

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

ПОЧЕМУ не RustFS:

1. Агрессивная пиар кампания, построенная на « костях » Minio, громкие заголовки. В последние месяцы проект очень активно пушится через заказные статьи на Medium. Явно прослеживается модель - набрать аудиторию корпоративных пользователей. В этом нет ничего плохого, но риск смены лицензии очень высокий, вопрос лишь времени

2. На сайте rustfs используются термины вроде "Limitless Scalability" и "EB-level storage capacity". Для проекта, архитектура которого еще до конца не стабилизировалась, заявлять поддержку эксабайтных хранилищ смешно.

3. По баг-репортам, понятно, что на объектах размером 512KB и 1MB производительность RustFS падает в 2 раза по сравнению с MinIO И также мой личный тест на слабом железе был завален rustfs'ом (Ошибки при concurrency: Под высокой параллельной нагрузкой (warp mixed тесты) система начинает сыпать ошибками, упирается в высокий iowait). Кластерный режим (Distributed mode) до сих пор носит статус экспериментального

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

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

2. Дорого для инфраструктуры

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

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

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

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

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

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

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

0. Написан на Rust

1. Полная совместимость с S3 API - Object Locking (WORM), Versioning & Lifecycle, IAM & RBAC со встроенной системой ролей (Reader, Writer, SuperUser) и
   JWT-авторизацией.

2. Дедупликация данных - Content-Addressable Storage: система считает SHA-256 хеш контента. Загрузишь один и тот же файл 10 раз - физически на диске он будет
   лежать в одном экземпляре.

3. Готовый веб интерфейс и мониторинг - В комплекте современная админка на Next.js + эндпоинт для Prometheus, позволяющий отслеживать латентность, IOPS и коэффициент
   дедупликации в реальном времени.

4. Архитектура хранения - В отличие от решений, которые кладут каждый объект в отдельный файл на диске, S4 использует Bitcask-style storage. Миллиард объектов
   хранится всего в ~1000 больших файлах - никакого Inode Exhaustion. Объекты меньше 4 КБ сохраняются прямо в метаданных (база redb), что даёт молниеносное чтение
   без лишних операций ввода-вывода. Данные не перезаписываются «поверх» - любая запись это append в конец лога.

5. 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 и что будет реализовано:

1. Кластерный режим с репликацией - горизонтальное масштабирование, consistent hashing, Raft-репликация. Уже в разработке, планирую выкатить в ближайшие недели (возможно еще неделя потребуется на тестирование).

2. Compaction Worker - фоновый сборщик мусора: переносит живые блобы из старых томов в новые, освобождая место после удалений.

3. Расширенный IAM - полноценные группы, политики на уровне бакетов (Bucket Policies), гранулярные права доступа. Многое из этого уже присутвует в S4Core, но для EE надо шире.

4. CLI-утилита (аналог mc в MinIO) - консольный инструмент для администрирования: алиасы серверов, ls/cp/rm/mirror, управление пользователями и политиками. Пока в раздумье с этим, так как CLI уже есть включая aws cli и куча других

5. Расширенный Lifecycle - перемещение между классами хранения, фильтрация по тегам и размеру, автоматическая очистка незавершённых multipart-загрузок.

6. 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%, ни одного потерянного объекта. Для сравнения с другими решениями опубликую отдельную статью с реальными цифрами.

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

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