Ищем замену MinIO в условиях импортозамещения: опыт тестирования трех S3-совместимых хранилищ

Привет, я Иван Засухин, DataOps Лаборатории искусственного интеллекта ^[1] департамента больших данных Россельхозбанка. Мы одна из команд платформы RAISA (RSHB AI Systems and Applications), отвечаем за инструменты, которые связаны с данными и их обработкой: Оркестрация (Apache Airflow), Compute( Apache Spark и Apache Trino), Хранение (S3 и Qdrant), интерфейсы взаимодействия с источниками данных (python-модули и кастомные операторы). В команде я занимаюсь развитием инструментов и их дальнейшим сопровождением.

 Как эффективно заменить MinIO, если это одно из главных объектных хранилищ команды и ИИ-платформы большого банка? В этой статье поделюсь результатами двух этапов тестирования S3-совместимых хранилищ. Сравнивали три решения: коммерческую российскую разработку «Закрома», опенсорс-решения RustFS и SeaweedFS. Тесты проводились на реальных стендах с нагрузками, приближенными к боевым. Спойлер: однозначного победителя нет, но у каждого кандидата есть четкие сценарии применения. 

Сюрприз от MinIO

В конце 2025 года мы, как и многие команды, использующие S3-совместимые хранилища, столкнулись с неприятным сюрпризом от MinIO. Компания резко изменила курс в сторону жесткой монетизации, что больно ударило по пользователям комьюнити-версии. Для нас, как для разработчиков ИИ-платформы РСХБ, это стало существенным ограничением, поскольку объектное хранилище данных – это один из ключевых инфраструктурных компонентов платформы во всех сценариях работы – и в DataOps-процессах, и в MLOps, и в AnalyticsOps.

Вот что конкретно произошло и почему мы сочли это важным:

1. Полный отказ от разработки Community Edition. Репозиторий Minio на Github был переведен в архивный статус. Можно продолжать использовать, но уже не будет ни улучшений, ни исправлений в критических уязвимостях. Все это теперь перетекло в Enterprise-версию.

2. Удаление веб-консоли из Community-сборок заметно снизило удобство администрирования — мы активно использовали UI для мониторинга состояния кластера, просмотра метрик и быстрых операций с бакетами.

3. Прекращение публикации официальных Docker-образов. Это усложнило процесс развертывания и обновления в наших CI/CD-пайплайнах, так как пришлось собирать образы самостоятельно или искать сторонние.

Ниже — скриншот официального анонса от разработчиков MinIO, который вызвал бурную дискуссию в профильных IT-чатах (источник — репозиторий MinIO (https://github.com/minio/minio/issues/21675#1 ^[2]), ноябрь 2025):

Реакция ^[3] мирового комьюнити не заставила себя ждать: на Reddit, в GitHub Issues и Telegram-каналах (например, @minio_ru) разразились горячие споры. Многие восприняли это как «принудительный вендорлок» и начали активно искать альтернативы. Основные аргументы сообщества сводились к тому, что MinIO нарушил негласное правило «open source friendly» и фактически «залочил» своих бесплатных пользователей. Мы оказались в той же лодке.

Для нас, как для внутреннего продукта крупного государственного банка, критически важно использовать ПО с открытой лицензией типа Apache 2.0. Это гарантирует нам право свободно модифицировать исходный код, внедрять его в наш стек без ограничений по числу экземпляров и, что самое главное, не зависеть от внезапных изменений политики вендора в будущем. Именно поэтому мы не рассматривали варианты с проприетарными лицензиями или ограничениями по использованию (типа AGPL, которая могла бы наложить обязательства на наш внутренний код). В этом плане MinIO с его переходом на коммерческую модель перестал для нас быть безопасным с точки зрения ^[4] долгосрочного планирования.

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

Выбрали трёх кандидатов, каждый из которых олицетворял свой путь: проверенный временем open-source (SeaweedFS), технологичный новичок с заявленной простотой миграции с текущего решения (RustFS) и российский коммерческий продукт с поддержкой (Закрома). Эталоном во всех тестах оставался MinIO.

Первый этап:  знакомство с кандидатами

Первый этап тестирования мы проводили с целью оценить базовую функциональность, совместимость с нашими инструментами и сервисами, получали общее впечатление ^[5] от работы с каждым решением.

Важные условия:

• MinIO брался как эталон и был развернут в кластерном режиме. Да, это дает ему преимущество в отказоустойчивости и потенциально в скорости. Однако он работает в окружении с другими сервисами (GitLab, Nexus и т.д.), что может влиять на результаты.

• SeaweedFS, RustFS и Закрома тестировались в standalone-режиме.

• Инструменты: python с boto3 и rail_connectors (наша библиотека для подключения к источникам данных, в неё имплементирован класс MinioConnection — обертка над minio sdk) для сценариев, приближенных к продуктовым.

• В каждом объектном хранилище был создан бакет на 50 ГБ для тестирования.

Совместимость и интеграция

Прежде чем перейти к результатам, важно понять, как мы используем S3 в платформе ИИ и что для нас критично. Платформа — это DataOps/MLOps/AnalyticsOps-решение RAISA (RSHB AI Systems and Applications). На «Раисе» живут в РСХБ все модели ИИ, огромное количество процессов аналитики и обработки данных, а также дата-приложения, и S3-хранилище в ней является центральным узлом для хранения всех типов данных. Выделим ключевые сценарии:

• Хранение данных для аналитики и ML: датасеты для обучения ^[6] моделей (от сотен МБ до сотен ГБ), подготовленные витрины в Parquet/ORC для аналитиков, исторические срезы для воспроизводимости экспериментов.

• Артефакты пайплайнов: чекпоинты моделей, веса, логи экспериментов, метрики, результаты валидации. Эти данные активно перезаписываются и удаляются в процессе работы.

• Интеграция с вычислительными движками: Spark и Trino постоянно читают данные из S3 при выполнении аналитических запросов и обучении моделей. Скорость чтения напрямую влияет на время выполнения задач. 

С какими требованиями подходили к тестированию?

• S3-совместимость на уровне API: бесшовная работа с boto3 и нашими внутренними библиотеками (rail_connectors).

• Поддержка STS и IAM: возможность выдавать временные токены, управлять доступом на основе единой ролевой модели, реализованной в Keycloak.

• Шифрование: наличие всех трех методов SSE (S3, C, KMS).

• Стабильность и предсказуемость: никаких сюрпризов при заполнении диска, обрывах соединения, высоких нагрузках.

• Производительность: должна быть сравнима с Minio на разных типах нагрузок

Теперь перейдем к тому, как кандидаты справились с этими требованиями.

Функциональные тесты

Все три кандидата успешно работают с boto3 — методы загрузки, выгрузки, получения статистики и управления бакетами протестированы. C rail_connectors ситуация немного различается: у Закрома, RustFS и SeaweedFS выявлено отсутствие некоторых параметров (chunksize в upload), хотя multipart upload поддерживается. MinIO, как эталон, работает без замечаний.

Пользователями S3 в нашей платформе являются не только технологические процессы, но и обычные сотрудники банка. Действия этих пользователей должны быть аудируемы, а значит нельзя просто раздать техническую учетную запись всем. Сотрудники банка иногда увольняются и переводятся между подразделениями, и вслед за этим должны изменяться их права. Для интеграции с банковской платформой аутенфикации мы используем стандартную технологию Security Token Service (STS). При переезде на новый продукт нам очень критична поддержка STS-токенов (Security Token Service) и полнота реализации стандарта:

• SeaweedFS поддерживает AssumeRole, GetFederationToken и IAM policies.

• RustFS – ограниченная поддержка (AssumeRole и IAM policies).

• Закрома –документация описывает настройку Keycloak для OIDC (OpenID Connect), но STS-токены не поддерживаются.

Важный момент для хранения чувствительных и конфиденциальных данных — шифрование: SeaweedFS и RustFS реализуют все три стандартных метода серверного шифрования (SSE-S3, SSE-C, SSE-KMS). Закрома на момент тестирования поддерживает SSE-S3, но SSE-C, которое активно нами используется в кейсах работы с моделями. Вендор нас уверил, что данная функциональность будет реализована в течении 2026 года.

Нагрузочное тестирование

Проведя тесты скорости чтения и записи (представлены на графике), мы получили следующие результаты: 

Полные таблицы результатов тестов в спойлере (!)

По записи все три решения уступают эталонному MinIO: SeaweedFS отстает на 20–30%, RustFS и Закрома — в 1.5–2.7 раза (хотя у RustFS мы подозреваем деградацию диска). По чтению картина противоположная: SeaweedFS — абсолютный лидер, обгоняет MinIO в 5–6 раз, RustFS — в 2–4 раза быстрее, а Закрома держится на уровне эталона. Таким образом, SeaweedFS — выбор для сценариев с высокими требованиями к чтению, RustFS дает сбалансированный профиль, а Закрома, уступая по записи, показывает достойное чтение.

По удобству администрирования MinIO (до последних версий с урезанным UI и функционалом) остается для нас эталоном: полноценный UI, понятное управление пользователями, низкий порог входа. RustFS максимально к нему приближен — управление интуитивно, интерфейс нативно понятный. SeaweedFS не обладает нужными нам функциями в UI, управление ролями и пользователями только через Keycloak, что требует привыкания. Закрома — достаточно детальный продукт с многослойной архитектурой, интерфейс дружелюбный, потребовал немного времени для адаптации.

Разумеется, standalone-режим не является целевым для промышленной эксплуатации, но такое значительное отставание Закрома в одноузловой конфигурации нас насторожило. Мы обсудили эти результаты с вендором и определили, что причина в различии архитектурных решений: Закрома — это микросервисное решение с четким разделением на управляющий слой (Gateway, Core, Composer, Metadata Database) и слой хранения данных (ZDS — Zakroma Data Storage). В standalone-режиме все эти компоненты работают на одной ноде, и именно слой управления метаданными (PostgreSQL с шардированием, сервисы Core/Composer) создает дополнительную нагрузку, которая в одноузловой конфигурации «съедает» часть ресурсов и ограничивает пропускную способность.  А в кластерной конфигурации нагрузка распределяется между узлами, а слой хранения ZDS с Erasure Coding должен раскрыть свой потенциал за счет параллельной записи на несколько дисков и узлов. Поэтому на больших объемах и в многопоточной нагрузке результаты должны были значительно улучшиться.

С этой надеждой мы и перешли ко второму этапу тестирования, целью которого было проверить системы в кластерной конфигурации, на больших объемах, в многопоточной нагрузке, а также оценить поведение ^[7] при заполнении диска.

Второй этап

Конфигурация второго этапа: все S3-совместимые хранилища в кластерном режиме, MinIO также под нагрузкой с бакетом в 0.5 Тб. Остальные – с бакетами в 1.5 Тб. Инструментарий тот же – python с boto3.

Мы прогнали два основных блока:

1. Скоростные тесты – запись и чтение на разных объемах (от 100 КБ до 100 ГБ), в разное количество потоков (1, 4, 10). Получим ли мы результаты отличные от первого этапа?

2. Тесты отказоустойчивости – заполнение диска, прерывание и возобновление загрузки, удаление больших файлов. Попытались поломать хранилище в базовых сценариях.

Производительность тестов скорости записи и чтения

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

Запись 10 ГБ x 4 потока — работа с датасетами для обучения моделей. В нашем пайплайне дата-сайентисты постоянно загружают подготовленные выборки размером 5–20 ГБ для экспериментов, а аналитики — выгрузки из DWH для исследования гипотез. RustFS здесь показывает выдающиеся 255 МБ/с, что позволяет сократить время ожидания загрузки данных перед обучением с 8 минут до 2.5 минут. Это критично при A/B-тестировании гипотез, когда специалист перебирает десятки вариантов за день, а также для аналитиков, которые исследуют новые данные в рамках ad-hoc задач.

Запись 100 ГБ x 1 поток — загрузка исторических данных для нового исследования или аналитической задачи. В RAISA часто возникает потребность ^[8] «поднять» архивный датасет для проверки гипотезы или воспроизведения результатов коллеги. Например, аналитик загружает историю транзакций за прошлый год, чтобы проверить новую метрику.

Здесь Закрома неожиданно вырывается вперёд с 94 МБ/с, обгоняя даже специализированные open-source решения. На практике это означает, что исследователь, который запускает новый эксперимент с историческими данными размером 100 ГБ, дождётся их загрузки за ~18 минут вместо ~29 минут на MinIO. Для дата-сайентиста это ощутимая разница, особенно если эксперимент требует нескольких итераций с разными срезами данных.

Запись100 ГБ x 4 потока — параллельная запись артефактов экспериментов. На платформе часто запускается несколько исследовательских задач одновременно (гиперпараметрическая оптимизация, ансамбли моделей, сравнение подходов), каждая из которых сохраняет чекпойнты, веса и логи. SeaweedFS здесь раскрывается на полную, выдавая 265 МБ/с — в 3 раза быстрее MinIO. На практике это означает, что при параллельной работе 4 специалистов мы упираемся не в диск, а в вычислительные мощности GPU, что является идеальным сценарием.

Запись: 

По итогу тестирования скорости записи: RustFS – лидер на средних объемах (до 10 ГБ), почти в три раза быстрее MinIO. На 100 ГБ скорость снижается, но остается на достойном уровне. SeaweedFS – раскрывается на тяжелых файлах. На 100 ГБ в многопотоке показывает впечатляющие 265 МБ/с. Закрома – в кластерной конфигурации показывает результаты, сопоставимые с конкурентами. В сценарии 100 ГБ x 4 раза в 1 поток, Закрома даже опережает всех, включая SeaweedFS и RustFS, показывая 94 МБ/с против 89 и 93 МБ/с соответственно. Конечно, она уступает лидерам, но держится на уровне выше MinIO.

Чтение:

Чтение 100 МБ x 50 раз, 4 потока — это классическая OLAP-нагрузка от Trino или Spark, когда читают множество мелких файлов при выполнении аналитического запроса. В RAISA это повседневная задача от аналитиков: ad-hoc запросы к данным, построение отчетов. SeaweedFS и RustFS здесь показывают 237 и 223 МБ/с, что в 5 раз быстрее MinIO. Это означает, что интерактивный запрос к данным за 2025 год, который на MinIO выполнялся 2 минуты, на SeaweedFS отработает за 25 секунд. Для наших пользователей затраченное время из «подожду, схожу за кофе» превращается в «получил результат мгновенно», что напрямую влияет на скорость принятия решений.

Чтение 10 ГБ в 3 потока — часто это загрузка данных из больших таблиц для обучения моделей, когда дата-сайентист загружает подготовленный датасет целиком в память ^[9] для работы. SeaweedFS (220 МБ/с) и RustFS (182 МБ/с) сокращают время загрузки с 9 минут до 2.5 минут. За день исследователь может перезапустить эксперимент 20–30 раз.

Чтение 100 ГБ в 2 потока — загрузка тяжелых артефактов, таких как подготовленные аналитические витрины в формате Parquet (например, агрегированные данные по всем клиентам за год), экспортированных датасетов после Feature Engineering (обогащенных признаков для обучения). 

SeaweedFS показывает 171 МБ/с против 136 МБ/с у MinIO, сокращая время загрузки 100-ГБ артефакта с 25 минут до 20 минут, каждая такая задача будет завершаться на 5 минут быстрее. RustFS здесь неожиданно проседает до 124 МБ/с, уступая даже MinIO. Это говорит о проблемах с чтением очень больших объектов в этом движке. Данный нюанс стоит учитывать, если вы планируете хранить в S3 файлы размером более 50 ГБ: например, исторические срезы для аналитики, подготовленные датасеты для обучения или экспортные выгрузки в Parquet/ORC.

По итогу тестирования скорости чтения: SeaweedFS – абсолютный лидер. Обгоняет MinIO в 3–5 раз на всех объемах. RustFS – также значительно быстрее эталона, но на 100 ГБ уступает даже MinIO. Закрома – уверенно держится на уровне MinIO или чуть лучше.

Тесты надежности

В идеальном мире все программное обеспечение работает идеально: место не заканчивается, сеть гарантирована и никогда не пропадает, а сервера никогда не перегружаются нештатно. Но что будет, если идеальные условия были нарушены? Не приведет ли закончившееся место на одном сервере к полной потере данных? Мы протестировали и это. 

Заполнение диска: загружали 1 ГБ файлы, пока место не кончится.

• MinIO – штатная ошибка ^[10] QuotaExceeded.

• Закрома – ошибка превышения квоты, отработала корректно.

• RustFS – ошибка InternalError при записи, связанная с кворумом (при трех узлах требовалось 2, достигнуто 0, 3 отказали). Это требует внимания ^[11] при проектировании отказоустойчивого кластера.

• SeaweedFS – ошибка Unknown после превышения лимитов.

Прерывание и возобновление загрузки (файл 100 МБ): все четыре системы справились штатно – загрузка прервалась и возобновилась корректно.

Удаление файла (100 ГБ):

Здесь Закрома показывает результат, который отличается от конкурентов. Это связано с архитектурными особенностями управления метаданными — они требуют более сложных операций при удалении. Данный фактор стоит учитывать при планировании операций с большими объемами данных.

Функциональный анализ

В ходе анализа документации мы детально прошлись по ключевым функциям каждого решения, чтобы оценить их зрелость и готовность к промышленной эксплуатации. Ниже — сравнение того, что эти функции дают на практике и как обстоят дела с их поддержкой в каждом из трех кандидатов.

1. Object Lock / WORM (Write Once, Read Many)

Что дает: режим, при котором файл нельзя удалить или перезаписать до указанной даты. Критично для хранения аудиторских логов, финансовых отчетов и других данных, подпадающих под регуляторные требования (например, 152-ФЗ). 

У кого есть: Полноценная поддержка режимов governance и compliance реализована во всех трех решениях. MinIO, SeaweedFS и RustFS полностью поддерживают все режимы Object Lock, включая Legal Hold. Это стандартный S3-функционал (режим governance позволяет временно блокировать объект, но пользователи с определенными правами могут его удалить или перезаписать, тогда как compliance обеспечивает жесткую блокировку до истечения срока, которую не может снять даже администратор), предусмотренный спецификацией AWS S3 API, поэтому его наличие в том или ином виде ожидаемо для любого S3-совместимого хранилища.

2. Версионирование объектов

Что дает: возможность хранить все версии файла и откатываться к любой из них. В наших пайплайнах это спасает при случайном перезаписывании подготовленного датасета или артефакта эксперимента — можно быстро вернуться к предыдущей версии без восстановления из бэкапов. Полностью поддерживается во всех решениях.

3. Bit Rot Protection (защита от порчи данных)

Что дает: система автоматически проверяет, не испортились ли данные на диске со временем (например, из-за физических дефектов носителя). В корпоративных хранилищах с многолетним хранением данных это критично — мы не можем позволить себе «молчаливую» порчу датасетов, на которые опираются бизнес-решения. MinIO использует алгоритм HighwayHash, SeaweedFS и RustFS также имеют встроенные механизмы проверки целостности. Есть во всех решениях. Базовая функция надежного хранения.

4. Erasure Coding (избыточное кодирование)

Что дает: технология, при которой объект разбивается на блоки данных и блоки четности, позволяя восстанавливать данные при потере до половины дисков в кластере. Это основа отказоустойчивости любого распределенного хранилища. Для нас это означает, что мы можем терять диски без остановки сервиса и без потери данных — очень критично для production-среды. MinIO — erasure coding лежит в основе архитектуры. SeaweedFS поддерживает EC в открытой версии. RustFS — аналогично.

5. Событийная модель / Webhooks

Что даёт: автоматическая реакция на изменения в хранилище — запуск пайплайна, уведомление внешней системы.

У кого есть:

Закрома: HTTP-вебхуки (методы POST/PUT/GET, протоколы HTTP/HTTPS) с аутентификацией BASIC/API_KEY/BEARER_TOKEN. Важное условие: для работы механизма необходима предварительная настройка Kafka в инфраструктуре. Поддерживается настройка как на уровне всего хранилища, так и на уровне бакета.

MinIO: Webhook, Kafka, AMQP (RabbitMQ), MQTT, NATS, NSQ, Elasticsearch и др.

SeaweedFS: доставка через внешние брокеры (RabbitMQ, Kafka).

RustFS: Webhook, Kafka, MQTT, NATS, AMQP, Redis, MySQL/PostgreSQL, Pulsar

Закрома реализует именно HTTP-вебхуки как целевой сценарий (аналогично MinIO и RustFS), но архитектурно зависит от наличия Kafka — это отличает её от MinIO, где Kafka является лишь одной из опций доставки, а не обязательным компонентом.

6. OIDC-интеграция (Keycloak, LDAP/AD, SSO)

Что дает: возможность входа по корпоративной учетной записи и централизованное управление доступом. В Россельхозбанке это обязательное требование безопасности — мы не можем заводить отдельных пользователей в каждом сервисе. MinIO — полная поддержка OIDC и AD/LDAP. SeaweedFS — поддерживает OIDC (включая Keycloak). RustFS — поддержка OIDC реализована, интеграция с AD дорабатывается. В Закрома присутствует поддержка AD/LDAP, OIDC, Keycloak. Итог: есть или частично есть во всех решениях. 

7. Аудит действий пользователей и администраторов

Что дает: логирование всех действий для безопасности. В банковском секторе это строгое требование регуляторов — мы обязаны знать, кто, когда и что делал с данными. В Закрома есть возможность настройки аудируемых событий, выгрузка в формате CEF в syslog, есть возможность форматировать аудит-логи для различных SIEM. MinIO и SeaweedFS поддерживают аудит в полном объеме. RustFS — есть журналы сервисов, единый enterprise-уровень audit trail в платной версии.  Есть в двух из трех open-source решений. 

Масштабирование

Отдельно оценили, как системы растут под нагрузкой.

Закрома предлагает наиболее сложную архитектуру — система состоит из нескольких независимых слоев (метаданные, событийная шина, управляющий слой + слой хранения zds), каждый из которых масштабируется отдельно.Это дает гибкость, но требует более глубокого понимания системы при планировании роста.

RustFS для продакшн-сред выполняется в режиме Multiple Node Multiple Disk (MNMD). Процесс подразумевает добавление новых узлов в кластер. Поддерживается Active-Active репликация на уровне бакетов между несколькими площадками (Multi-Site).

SeaweedFS масштабируется добавлением Volume-серверов, хранящих данные и опционально Master-серверов для метаданных. Однако здесь есть важные особенности: нет автоматической перебалансировки — после добавления новых Volume-серверов данные не перераспределяются автоматически, новые данные пишутся на новые серверы. Для Multi-DC конфигураций нужно создавать новый кластер — переключить существующий Single-DC кластер невозможно.

Для наших задач наиболее понятным оказался подход RustFS, наиболее сложным — Закромы, а SeaweedFS требует внимания к нюансам с перебалансировкой.

Миграция с MinIO

Оценили сложность перехода с MinIO на каждое из решений.

Закрома предлагает встроенный механизм «бесшовной миграции» с внешних S3-хранилищ, позволяющий перевести клиентов на новое хранилище с минимальным простоем (15–30 минут).

RustFS позволяет выполнить миграцию с минимальными изменениями в приложениях — он полностью совместим с S3 и может выступать в роли «бесшовной замены». Самый простой способ — заменить бинарный файл MinIO на RustFS.

SeaweedFS требует полноценного переноса данных с использованием инструментов синхронизации, поскольку это полноценный переезд между системами, а не замена бинарного файла. Рекомендуемый инструмент — rclone.

Итоговые выводы

По итогам двух этапов тестирования мы не получили единственного правильного ответа – у каждого решения свои сильные и слабые стороны. Выбор зависит от ваших приоритетов.

SeaweedFS – идеальный выбор для сценариев с высокими требованиями к скорости чтения (аналитика, ML, работа с большими данными). Зрелый, стабильный, но сложный в администрировании и поддержке продукт. Требует привыкания к управлению ролями через Keycloak, нет автоматической перебалансировки.

RustFS – максимально близок к базовому MinIO по управлению, прост в миграции, показывает отличную скорость записи на средних объемах. Главный риск – молодость продукта и вопросы к отказоустойчивости (ошибка кворума).

Закрома — это не «галочка» для отчетности по импортозамещению, а полноценное энтепрайз-решение с определенными архитектурными особенностями. Да, на текущий момент оно уступает открытым аналогам по сырым скоростным показателям, а многослойная архитектура приводит к заметному отставанию в операциях удаления больших файлов (9 секунд против 0.05–0.08 у конкурентов). Но для нас есть несколько весомых аргументов в его пользу:

•     Вендор открыто признает отставание — в ходе обсуждения результатов первого этапа они подтвердили разницу в 15–25% и назвали конкретные планы по оптимизации в ближайших релизах. Мы видим дорожную карту и понимаем, когда и какие улучшения придут.

•    ПО с поддержкой — в отличие от опенсорс-решений, здесь есть поддержка 24/7, SLA с гарантированным временем реакции, возможность оперативно получать исправления критических багов. Для нас это важно: очень часто мы не можем ждать, пока комьюнити предложит фикс.

•     Влияние на дорожную карту — как корпоративный заказчик мы можем напрямую влиять на развитие продукта. Если нам критична SSE-C или полноценная поддержка STS-токенов, то вендор готов включить эти доработки в ближайшие релизы. В опенсорс-решениях мы просто потребители — наши потребности не являются приоритетом для разработчиков.

•     Включение в Единый реестр российского ПО — да, это важный фактор, но не единственный. Для нас критична не столько «бумажная»  совместимость, сколько гарантии того, что продукт будет развиваться с учетом наших потребностей.

•    Экономическая целесообразность и закрытие рисков — поддерживать собственное open-source решение в условиях жесткой экономии ресурсов — риск. Когда в опенсорс-проекте возникает критический баг, его устранение может занять дни или недели, а в это время продуктивная среда простаивает. С Закромой мы получаем предсказуемый TCO: платим за лицензию и получаем поддержку, обновления, исправления безопасности в рамках контракта, закрываем регуляторные риски (ФЗ-188, требования к ПО из ЕРРП). Конечно, она не отменяет необходимость в собственном SRE — как поддержка Postgres Pro не отменяет DBA. Она даёт предсказуемый SLA, доступ к экспертам вендора и приоритетные исправления, но эксплуатационная ответственность остаётся на заказчике.

Для нас Закрома остается в шорт-листе как кандидат при условии, что поддержка STS-токенов и шифрования будет в скором времени реализована. Однако, если максимальная производительность — это был бы единственный критерий, то выбор пал бы на SeaweedFS или RustFS.

Будем рады услышать ваш опыт ^[12] в комментариях. Может быть, вы уже эксплуатируете что-то из этого списка в проде? Или тестировали другие решения? Давайте обсудим.

Скрытый текст

Результаты тестов первого этапа:

Тест	Закрома	SeaweedFS	RustFS	MinIO
Время загрузки 10 файлов размером  ~ 1 ГБ через rail_connectors (minio client)	Время:  9.96 сек Скорость: 102.8 МБ/с	Время: 5.97 сек Скорость: 171.5 МБ/с	7.36 сек Скорость: 139.1 МБ/с	Время: 5.85 сек Скорость: 175.0 МБ
Чтение файла 10.00 GB через boto3	Время:  66.67 сек, Скорость: 153.60 МБ/с	Время: 9.72 сек Скорость: 1053.87 МБ/с	Время: 15.38 сек Скорость: 665.97 МБ/с	Время: 61.91 сек Скорость: 165.41 МБ/с
Время загрузки 100 файлов (1 ГБ)   через boto3	Время:  42.87 сек Скорость:  23.89 МБ/с	Время: 27.51 сек Скорость: 39.03 МБ/с	Время: 32.82 сек Скорость: 32.72 МБ/с	Время: 18.53 сек Скорость: 57.96 МБ/с
Чтение файла 5.00 GB через boto3	Время:  30.23 сек, Скорость:  169.37 МБ/с	Время: 4.80 сек Скорость: 1066.97 МБ/с	Время: 9.15 сек Скорость: 559.51 МБ/с	Время: 31.30 сек Скорость: 163.57 МБ/с
Время чтения 100 файлов (1 ГБ)   через boto3	Время:  19.76 сек Скорость: 51.82 МБ/с	Время: 6.05 сек Скорость: 177.58 МБ/с	Время: 8.07 сек Скорость: 133.09 МБ/с	Время: 12.36 сек Скорость: 86.85 МБ/с
Чтение файла 1.00 GB через boto3	Время:  6.02 сек, Скорость:  170.22 МБ/с	Время: 1.12 сек Скорость: 912.77 МБ/с	Время: 2.73 сек Скорость: 375.77 МБ/с	Время: 6.34 сек Скорость: 161.41 МБ/с
Время загрузки файлa размером 10 ГБ через boto3	Время: 115.85 сек, Скорость: 88.39 МБ/с	Время: 53.33 сек Скорость: 192.00 МБ/с	Время: 127.71 сек Скорость: 80.18 МБ/с	Время: 56.54 сек Скорость: 181.12 МБ/с
Время загрузки файла размером 5 ГБ через boto3	Время: 63.28 сек, Скорость: 80.92 МБ/с	Время: 26.89 сек Скорость: 190.39 МБ/с	Время: 38.78 сек Скорость: 132.04 МБ/с	Время: 21.84 сек Скорость: 234.47 МБ/с
Время загрузки файла размером 5 ГБ через rail_connectors (minio client	Время: 46.38 сек Скорость: 110.4 МБ/с	Время: 30.63 сек Скорость: 167.2 МБ/с	39.30 сек Скорость: 130.3 МБ/с	Время: 26.65 сек Скорость: 192.1 МБ/с
Время загрузки файла размером 1 ГБ через boto3	Время: 12.17 сек, Скорость:  84.16 МБ/с	Время: 6.25 сек Скорость: 163.97 МБ/с	Время: 8.27 сек Скорость: 123.83 МБ/с	Время: 4.39 сек Скорость: 233.04 МБ/с
Время загрузки файла размером 1 ГБ через rail_connectors (minio client)	Время: 8.76 сек. Скорость: 116.9 МБ/с	Время: 6.41 сек Скорость: 159.8 МБ/с	Время: 7.82 сек Скорость: 131.0  МБ/с	Время: 5.34 сек Скорость: 191.8 МБ/с

Результаты тестов второго этапа:

тест	MinIO	Закрома	SeaweedFS	RustFS
U-1) Загрузка файла размером 100КБ х 1000 раз в 1 поток	34.09 сек 2.93 Мб/сек	62.65 сек 1.6 Мб/сек	11.93 сек 8.38 Мб/сек	21.98 сек 4.55 Мб/сек
U-2) Загрузка файла размером 100КБ х 1000 раз в 10 потоков	11.09 сек 9.02 Мб/сек	7.08 сек 14.13 Мб/сек	4.76 сек 20.99 Мб/сек	5.08 сек 19.89 Мб/сек
U-3) Загрузка файла размером 1МБ х 100 раз в 1 поток	8.12 сек 12.31 Мб/сек	4.29 сек 23.29 Мб/сек	3.94 сек 25.37 Мб/сек	5.176 сек 19.32 Мб/сек
U-4) Загрузка файла размером 1МБ х 100 раз в 10 потоков	2.56 сек 39.07 Мб/сек	1.08 сек 92.54 Мб/сек	1.02 сек 98.16 Мб/сек	0.971 сек 102.97 Мб/сек
U-5) Загрузка файла размером 1МБ х 1000 раз в 1 поток	78.62 сек 12.72 Мб/сек	41.01 сек 24.39 Мб/сек	43.21 сек 23.14 Мб/сек	51.96 сек 19.25 Мб/сек
U-6) Загрузка файла размером 1МБ х 1000 раз в 10 потоков	21.59 сек 46.32 Мб/сек	10.17 сек 98.33 Мб/сек	10.97 сек 91.12 Мб/сек	9.59 сек 104.24 Мб/сек
U-7) Загрузка файла размером 100МБ х 10 раз в 1 поток	9.87 сек 101.36 Мб/сек	8.14 сек 122.78 Мб/сек	6.34 сек 157.70 Мб/сек	6.80 сек 147.00 Мб/сек
U-8) Загрузка файла размером 100МБ х 10 раз в 10 потоков	11.15 сек 89.65 Мб/сек	9.87 сек 101.35 Мб/сек	5.70 сек 175.32 Мб/сек	5.19 сек 192.74 Мб/сек
U-9) Загрузка файла размером 100МБ х 50 раз в 1 поток	108.54 сек 46.07 Мб/сек	41.78 сек 119.66 Мб/сек	32.73 сек 152.75 Мб/сек	36.09 сек 138.54 Мб/сек
U-10) Загрузка файла размером 100МБ х 50 раз в 10 потоков	61.45 сек 81.36 Мб/сек	49.82 сек 100.36 Мб/сек	24.56 сек 203.61 Мб/сек	24.26 сек 206.09 Мб/сек
U-11) Загрузка файла размером 10ГБ х 1 раз в 1 поток	196.56 сек 52.10 Мб/сек	169.06 сек 60.57 Мб/сек	176.63 сек 57.97 Мб/сек	58.30 сек 175.64 Мб/сек
U-12) Загрузка файла размером 10ГБ х 4 раз в 1 поток	586.69 сек 69.81 Мб/сек	454.30 сек 90.16 Мб/сек	698.04 сек 58.68 Мб/сек	225.32 сек 181.75 Мб/сек
U-13)  Загрузка файла размером 10ГБ х 4 раз в 4 потока	470.66 сек 87.03 Мб/сек	397.61 сек 103.02 Мб/сек	232.92 сек 175.85 Мб/сек	160.52 сек 255.16 Мб/сек
U-15) Загрузка файла размером 100ГБ х 4 раз в 1 поток	6592.33 сек 62.13 Мб/сек	4348.35 сек 94.20 Мб/сек	4605.06 сек 88.95 Мб/сек	4405.99 сек 92.96 Мб/сек
U-16) Загрузка файла размером 100ГБ х 4 раз в 4 потока	4609.42 сек 88.86 Мб/сек	3943.92 сек 103.86 Мб/сек	1544.41 сек 265.22 Мб/сек	2815.85 сек 145.46 Мб/сек
D-1) Чтение файла размером 100КБ х 1000 раз в 1 поток	27.17 сек 3.68 Мб/сек	27.12 сек 3.69 Мб/сек	6.76 сек 14.79 Мб/сек	6.75 сек 14.80 Мб/сек
D-2) Чтение файла размером 100КБ х 1000 раз в 10 потоков	8.62 сек 11.60 Мб/сек	6.13 сек 16.31 Мб/сек	2.22 сек 45.10 Мб/сек	2.70 сек 36.99 Мб/сек
D-3) Чтение файла размером 1МБ х 100 раз в 1 поток	6.78 сек 14.76 Мб/сек	6.08 сек 16.46 Мб/сек	2.78 сек 35.98 Мб/сек	3.84 сек 26.07 Мб/сек
D-4) Чтение файла размером 1МБ х 100 раз в 10 потоков	2.93 сек 34.12 Мб/сек	2.79 сек 35.91 Мб/сек	0.52 сек 193.15 Мб/сек	0.84 сек 199.66  Мб/сек
D-5) Чтение файла размером 1МБ х 1000 раз в 1 поток	56.51 сек 17.70 Мб/сек	57.20 сек 17.48 Мб/сек	26.42 сек 37.84 Мб/сек	37.19 сек 26.89  Мб/сек
D-6) Чтение файла размером 1МБ х 1000 раз в 4 потока	28.49 сек 35.09 Мб/сек	28.97 сек 34.51 Мб/сек	8.16 сек 122.60 Мб/сек	12.19 сек 82.07  Мб/сек
D-7) Чтение файла размером 100МБ х 10 раз в 1 поток	23.92 сек 41.80 Мб/сек	21.24 сек 47.08 Мб/сек	13.07 сек 76.52 Мб/сек	13.58 сек 73.67  Мб/сек
D-8) Чтение файла размером 100МБ х 10 раз в 4 потока	19.59 сек 51.04 Мб/сек	22.04 сек 45.38 Мб/сек	4.90 сек 204.17 Мб/сек	6.11 сек 163.74  Мб/сек
D-9) Чтение файла размером 100МБ х 50 раз в 1 поток	114.25 сек 43.76 Мб/сек	106.10 сек 47.12 Мб/сек	60.52 сек 82.62 Мб/сек	66.48 сек 75.21  Мб/сек
D-10) Чтение файла размером 100МБ х 50 раз в 4 потока	108.09 сек 46.26 Мб/сек	103.28 сек 48.41 Мб/сек	21.07 сек 237.36 Мб/сек	22.42 сек 223.07  Мб/сек
D-11) Чтение файла размером 10ГБ х 1 раз в 1 поток	190.35 сек 53.80 Мб/сек	156.11 сек 65.60 Мб/сек	122.59 сек 83.53 Мб/сек	74.74 сек 137.01 Мб/сек
D-12) Чтение файла размером 10ГБ х 3 раз в 1 поток	581.47 сек 52.83 Мб/сек	463.75 сек 66.39 Мб/сек	366.11 сек 83.91 Мб/сек	223.98 сек 137.15 Мб/сек
D-13) Чтение файла размером 10ГБ х 3 раз в 3 потока	545.64 сек 56.30 Мб/сек	426.64 сек 72.00 Мб/сек	139.41 сек 220.35 Мб/сек	169.20 сек 181.56 Мб/сек
D-14) Чтение файла размером 100ГБ х 1 раз в 1 поток	1246.07 сек 82.18 Мб/сек	1101.30 сек 92.98 Мб/сек	1232.14 сек 83.11 Мб/сек	1402.31 сек 73.02 Мб/сек
D-15) Чтение файла размером 100ГБ х 2 раз в 1 поток	2611.79 сек 78.41	2480.71 сек 82.56 Мб/сек	2474.98 сек 82.75 Мб/сек	2822.98 сек 72.55 Мб/сек
D-16) Чтение файла размером 100ГБ х 2 раз в 2 потока	1504.61 сек 136.11 Мб/сек	1458.21 сек 140.45 Мб/сек	1199.81 сек 170.69 Мб/сек	1653.46 сек 123.86 Мб/сек