惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

S
SegmentFault 最新的问题
B
Blog
P
Proofpoint News Feed
美团技术团队
The GitHub Blog
The GitHub Blog
Y
Y Combinator Blog
A
About on SuperTechFans
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Vercel News
Vercel News
有赞技术团队
有赞技术团队
小众软件
小众软件
H
Hackread – Cybersecurity News, Data Breaches, AI and More
Google DeepMind News
Google DeepMind News
Martin Fowler
Martin Fowler
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
aimingoo的专栏
aimingoo的专栏
H
Help Net Security
罗磊的独立博客
L
LangChain Blog
GbyAI
GbyAI
腾讯CDC
T
The Blog of Author Tim Ferriss
Microsoft Security Blog
Microsoft Security Blog

Все публикации подряд на Хабре

Ловим музу за клавиатуру: как айтишнику стать автором Что умеет Midjourney в 2026? Мой немного грустный разбор этого шикарного инструмента Никто не любит писать тесты, но ИИ может исправить это IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит Производители вернули в продажу материнки с DDR3. Что происходит? Управление агентом с телефона через Telegram теперь в KodaCode От координации к лидерству: как меняется роль руководителя разработки Я сделала родителям бизнес вместо пенсии: зарабатываем 70 тысяч, мама не даёт продать В три раза быстрее приемка товара и оптимизация трудозатрат на 73%: как «РСТ-Инвент» помог Gulliver Group ИИ-шечный мир победил? О влиянии искусственного интеллекта на игропром Кремль снижает давление на Телеграмм пока Европа строит интернет по паспорту Как CEO, CTO и CIO за 8 часов собрали ИИ-директора, который умеет держать позицию под давлением Как (не) потерять домен за выходные Вместо 8 разных VPS: как я организовал практику студентам на одном сервере Почему твой Open Source проект не замечают? R&D: искусство управления неопределенностью в разработке AI-дефляция: вакансий для разработчиков больше, а рост зарплат — худший за 15 лет Мы отдали управление роботами OpenClaw. Что из этого вышло Галактический ID: система идентификации для всех форм разумной жизни Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?» Код-ревью, в котором дело не в коде Данные переехали. Команда — нет Системной подход к сдаче OSWE в 2025 Почему комната управления реактором покрашена в цвет морской пены 4 YAML-файла вместо PySpark: как аналитикам строить пайплайны без разработчиков LLM-агент для поиска свободных доменов: автоматизируем подбор Когда, зачем и как правильно начинать новую сессию в Claude Code? Как я заставил нейросеть писать макросы для FreeCAD Анатомия ИИ‑агента для подбора персонала. От тысячи резюме к топ‑10 за минуты Опыт разработчика как экономика внимания
От MinIO к SeaweedFS: опыт замены S3-хранилища
dbraincloud · 2026-04-28 · via Все публикации подряд на Хабре

Время на прочтение4 мин

Охват и читатели0

Кейс

Есть такой опасный момент в инфраструктуре: когда все вроде бы работает, но трогать это лишний раз не хочется. Не потому что идеально. А потому что есть ощущение — если полезешь, станет хуже. В какой-то момент мы поймали себя на этом с 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 — будет интересно услышать ваш опыт.