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