Есть такой опасный момент в инфраструктуре: когда все вроде бы работает, но трогать это лишний раз не хочется. Не потому что идеально. А потому что есть ощущение — если полезешь, станет хуже. В какой-то момент мы поймали себя на этом с MinIO. Он не падал каждый день, не устраивал катастроф, не блокировал разработку. Но вокруг него накопилось слишком много «но»: лучше не обновлять, лучше не трогать репликацию, лучше не лезть в админку без необходимости.

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

Когда временное решение живет слишком долго

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

Изначально у нас в платформе контейнеризации dBrain.cloud все было разложено по полочкам следующим образом:

  • Для больших кластеров — Ceph, потому что он мощный, отказоустойчивый и проверенный.

  • Для более компактных сценариев — MinIO: простой, быстрый, S3-совместимый.

  • Дополнялось все это TopoLVM, который закрывал задачи локального хранилища.

И какое-то время это выглядело как очень здравая и удобная архитектура. Но со временем MinIO перестал быть тем самым простым и легким решением, ради которого мы его вообще когда-то выбрали.

Много лет назад, когда мы выбирали типы хранилища для dBrain.cloud, MinIO казался почти идеальным компромиссом. Не хотелось тянуть в маленький кластер тяжелый Ceph, а S3 API уже тогда был фактическим стандартом. MinIO закрывал эту нишу практически без конкурентов. Он запускался одним бинарником, не требовал сложной обвязки и в целом создавал ощущение, что объектное хранилище может быть простым. Почитать про нашу работу с хранилищами можно тут.

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

Отдельная боль — обновления. Они все чаще приносили сюрпризы. Где-то менялось поведение после сбоев, где-то исчезали привычные механизмы восстановления. В итоге мы пришли к довольно тревожной практике: MinIO в рабочих кластерах лучше не трогать. Потому что после апдейта могло стать хуже. Финальный перелом произошел, когда MinIO окончательно сместился в сторону коммерческой модели. Open-source версия начала заметно худеть.

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

Поиск альтернативы: неожиданно сложный квест

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

Казалось бы, S3 — стандарт де-факто, решений должно быть много. На практике же выяснилось, что выбирать особо не из чего. Мы пересмотрели кучу проектов: от относительно известных до совсем нишевых. Что-то выглядело красиво на GitHub, но разваливалось при попытке использовать это в реальном кластере. Что-то банально не дотягивало по зрелости. Где-то архитектура вызывала больше вопросов, чем ответов.

В итоге стало понятно, что адекватных open-source S3-хранилищ гораздо меньше, чем кажется.

Про SeaweedFS мы знали давно, но долгое время не воспринимали его как полноценную замену MinIO. Он казался чем-то нишевым, слегка в стороне от мейнстрима. Вернулись к нему уже без особых ожиданий — скорее потому, что нужно было проверить все. Довольно быстро стало понятно, что мы его недооценивали.

SeaweedFS оказался не «магическим бинарником», а системой с вполне прозрачной архитектурой. Есть master-ноды, которые управляют метаданными. Есть volume-серверы, где лежат сами данные. Есть сервис, который предоставляет файловые интерфейсы и S3. Вся конструкция напоминает упрощенный и более легкий вариант привычных распределенных систем хранения.

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

На практике SeaweedFS приятно удивил. Во-первых, он ведет себя предсказуемо. Репликация работает так, как от нее ожидаешь. После сбоев система восстанавливается, а не оставляет тебя разбираться с последствиями вручную. Да, где-то не хватает автоматизации из коробки, например, мы добавляли свою логику для скраббинга и самовосстановления.

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

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

И наконец, S3. Да, SeaweedFS не реализует весь API на сто процентов, как это делал MinIO. Но он покрывает большую часть реально используемых сценариев. А после изменений в MinIO вокруг проекта заметно активизировалось сообщество, и недостающие фичи начали довольно быстро появляться, например, ttl/livecycles. Мы это наблюдали в процессе своей интеграции.

В результате архитектура dBrain.cloud не перевернулась с ног на голову, но стала заметно здоровее. Ceph остался на своем месте — как решение для больших и требовательных кластеров. TopoLVM продолжает закрывать задачи локального хранения. А вот роль легкого S3 полностью перешла к SeaweedFS.

На текущий момент SeaweedFS встроен в платформу как стандартный вариант объектного хранилища. Это не экспериментальная опция и не решение для смелых, а нормальный, поддерживаемый и рекомендуемый путь.

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

Вместо вывода

Эта история на самом деле не про то, кто лучше — MinIO или SeaweedFS. Она про то, как инструмент, который когда-то идеально подходил, со временем перестал соответствовать задачам. И про то, как важно вовремя принять меры и двигаться дальше.

SeaweedFS не идеален. Но он понятный, предсказуемый и развивается в сторону, которая нам близка. А в инфраструктуре это зачастую важнее, чем громкие обещания и полная совместимость.

Если вы сейчас стоите перед похожим выбором или уже проходили через миграцию с MinIO — будет интересно услышать ваш опыт.

Комментарии (2)


  1. trabl
    28.04.2026 10:06

    Хотелось бы сравнительные характеристики SeaweedFS и MinIO посмотреть в плане производительности, отказоустойчивости, капасити и т.д. С MinIO знаком, про SeaweedFS слышал, но не сталкивался на практике.


    1. kenoma
      28.04.2026 10:06

      Дак, а чо там смотреть то, в 26 году делов на пару секунд:

      ## Key Performance & Scaling Comparison
      
      * Small Files (< 1MB):
      * SeaweedFS is significantly faster (up to 3-4x) for small file ingestion. It uses a "Haystack-style" architecture that stores metadata in memory and appends data to large volumes, resulting in $O(1)$ disk seek performance.
      * Large Files (> 10MB):
      * MinIO typically wins or ties in throughput for large objects. MinIO's erasure coding model is highly optimized for sequential reads and writes of large data chunks.
      * Resource Efficiency:
      * MinIO is generally more CPU-efficient under load. SeaweedFS can be more memory-efficient at scale because it avoids the metadata overhead typical of traditional filesystems. 
      
      ## Feature & Compatibility Breakdown
      
      |   Feature         |              MinIO           |                     SeaweedFS             |
      |-------------------|------------------------------|-------------------------------------------|
      | Primary Focus     | S3-Compatible Object Storage | Universal Distributed Storage             |
      | S3 Compatibility  | High (Gold Standard)         | High (covers most use cases)              |
      | Deployment        | Simple single binary         | More complex (Master, Volume, Filer)      |
      | Native Interfaces | S3 API only                  | S3, Filer (POSIX), WebDAV, Fuse           |
      | Data Protection   | Erasure Coding by default    | Replication (hot) / Erasure Coding (cold) |