MinIO self-hosted: строим S3-совместимое хранилище для нескольких клиентов и разбираемся с erasure coding

В начале 2022 года MinIO переключил AGPL-лицензию на более строгую схему: бесплатный open-source остался AGPLv3, но Enterprise-фичи (мультисайт репликация, IAM-интеграции, поддержка) ушли за подписку. Для нашего контекста это оказалось скорее новостью хорошей: AGPLv3-MinIO нам достаточно, клиентам ничего не надо платить вендору, а на фоне ухода AWS и Azure из РФ запрос на S3-совместимое хранилище в нашем периметре вырос до неприличия.

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

Почему не Ceph Object Storage

Честный вопрос. Ceph умеет S3 через RadosGW и мы c ним работаем. Но MinIO выигрывает в одном конкретном сценарии: когда клиенту нужно именно объектное хранилище и ничего больше. Ceph - это операционные расходы на поддержку MON/MGR/OSD-кластера, cephadm, PG-балансировку. MinIO - это бинарь и директория с дисками. При ресурсах в 4-8 серверов Ceph избыточен по сложности. При большем масштабе или потребности в блочном хранилище - наоборот.

Erasure coding: матчасть на практике

MinIO использует собственную реализацию Reed-Solomon erasure coding вместо репликации. Это важный момент, который часто недооценивают при планировании.

В pool с EC схемой EC:4 на 8 дисках (4 данных + 4 чётности) теряется до 4 дисков без потери данных. Overhead по месту - 2x вместо 3x при тройной репликации Ceph. На практике для клиентов с большими объёмами холодных данных (бэкапы, архивы, дистрибутивы) это значимая экономия.

Производительность - отдельный разговор, о котором документация говорит вскользь.

Мелкие объекты убивают EC. MinIO держит мелкие объекты (по умолчанию до 128 KiB) в inline storage без EC. Но если у вас много объектов 200-500 KiB, они идут через полный цикл EC-кодирования - и throughput на запись ощутимо падает по сравнению с обычной репликацией. Мы поймали это на клиенте, который гонит в хранилище журналы: много мелких файлов, высокая частота PUT-запросов, и на EC 4+4 throughput оказался хуже, чем ожидалось. Переключились на EC:2 (2+2 на 4 дисках) - стало лучше, с потерей одного уровня защиты.

EC работает на уровне Set, не кластера. Диски MinIO делятся на erasure sets - группы, внутри которых работает EC. По умолчанию MinIO сам выбирает размер set исходя из числа дисков. На 8 дисках - 1 set из 8. На 12 - возможны варианты. Это важно: если диск выходит из строя внутри set, heal работает интенсивно именно на этом set, не распределяясь по всему кластеру. На больших дисках heal может занять сутки под реальной нагрузкой.

Что по производительности на смешанном железе

У двух клиентов конфигурация «что было в серверной» - смесь SSD и HDD, разные поколения. MinIO это не Ceph: он не умеет разделять пулы по типу диска. Все диски в одном deployment работают в одном pool. Производительность тянется к самому медленному диску в erasure set.

Обходится это через несколько deployment-ов MinIO на одном кластере (MinIO Gateway Mode давно убрали, речь про несдвигаемые ServerPools начиная с версии RELEASE.2022-04 и новее). Быстрый pool на SSD - один deployment, архивный на HDD - другой. Клиент видит разные bucket-пространства или проксирует через один endpoint - зависит от того, нужна ли ему единая точка доступа.

Это немного усложняет операционку, зато производительность предсказуема.

Multi-tenant: несколько клиентов на одном кластере

Изоляция в MinIO - через access key / secret key + policy. Один клиент = отдельный пользователь с политикой, ограниченной своими bucket-ами. Policy-язык - AWS IAM-совместимый JSON, что удобно тем, кто переезжает с AWS.

Что мы проверили: один клиент через IAM-политику действительно не видит bucket другого. Но важно понимать: это логическая изоляция, не физическая. Данные всех клиентов лежат на одних и тех же дисках. Если erasure set деградировал - деградировал для всех.

Для клиентов с требованиями по физической изоляции (есть такие в рамках ФЗ-152 и КИИ) - отдельный кластер. Стоимость лицензии нулевая, значит накладные расходы только операционные.

Мониторинг

MinIO отдаёт метрики в Prometheus из коробки - /minio/v2/metrics/cluster. Grafana dashboard от MinIO (ID 13502) работает без доработки. Ключевые метрики для нас:

• minio_cluster_capacity_raw_free_bytes - свободное место с учётом overhead EC
• minio_node_drive_errors_timeout - тайм-ауты обращений к диску, первый сигнал о проблемах
• minio_s3_requests_errors_total - ошибки на уровне S3 API

Heal-операции тоже видны через метрики, что важно после замены диска - можно следить за прогрессом без mc admin heal вручную.

Где сейчас

Три клиента на production MinIO, ещё два в процессе миграции с Azure Blob. Серьёзных проблем нет, но и иллюзий нет: MinIO - это не managed-сервис с чьей-то SLA, это программа которую эксплуатируешь ты сам. Релизы выходят часто, несколько раз в месяц, и changelog надо читать - в этом году MinIO ломал обратную совместимость форматов метаданных пару раз. Обновления строго по инструкции, с проверкой версии формата перед апгрейдом.

Для клиентов, которым нужно заместить S3 или Azure Blob, MinIO - разумный выбор: API-совместимость хорошая, SDK те же, SDK-шные клиенты (aws cli, boto3, s3cmd) работают без изменений. Основная работа - правильно спроектировать erasure coding под нагрузочный профиль конкретного клиента. Универсального рецепта нет.