MinIO Distributed в отечественном облаке: разворачиваем self-hosted S3 как backend для резервных копий Veeam

У нас есть клиент с типичной для 2023 года историей: инфраструктура переехала в российское облако, с AWS расстались, а Veeam Backup & Replication остался - лицензии куплены, процессы выстроены, менять не хочется. Проблема в том, что Veeam умеет писать резервные копии напрямую в S3-совместимое хранилище, но нативный Yandex Object Storage в некоторых конфигурациях даёт не тот уровень производительности, на который рассчитывал клиент. Плюс у части задач есть требование хранить копии в том же изолированном облачном сегменте, не выходя за его границы.

Решение, к которому мы пришли - поднять MinIO Distributed прямо на виртуальных машинах в облаке и подключить его к Veeam как SOBR (Scale-Out Backup Repository) с S3-совместимым capacity tier. Вот что из этого вышло.

Почему MinIO, а не Ceph RGW

Вариант с Ceph RGW мы рассматривали на другом проекте. Там он зашёл хорошо, но у Ceph другой порог входа: кластер требует минимум трёх нод под MON, ещё несколько под OSD, и overhead на оркестровку. Для задачи "надёжное S3-хранилище под резервные копии в облаке" MinIO проще в развёртывании, не требует выделенных нод под метаданные и нативно заточен именно под S3-семантику.

MinIO в режиме Distributed работает поверх обычных дисков на нескольких нодах и даёт erasure coding из коробки. Добавить диски в существующий erasure set нельзя - только новый пул, поэтому размер кластера нужно планировать заранее.

Конфигурация стенда

Четыре ВМ в одном облачном сегменте, каждая с четырьмя дополнительными дисками по 500 ГБ - итого 16 дисков на пул. MinIO в Distributed-режиме требует чётного числа дисков, делимого на 4 для erasure coding. С 16 дисками получаем схему 12+4 (двенадцать data, четыре parity): потеря до четырёх дисков или одной ноды целиком - без потери данных.

Схема запуска на каждой ноде:

export MINIO_VOLUMES="http://minio{1...4}.internal:9000/data{1...4}"
export MINIO_ROOT_USER=admin
export MINIO_ROOT_PASSWORD=<из vault>
minio server $MINIO_VOLUMES --console-address :9001

Фронт через nginx с TLS, потому что Veeam при работе с S3-таргетом без HTTPS начинает предупреждать, а в новых версиях - и вовсе отказывается от plain HTTP в production-конфигурациях. Сертификат - внутренний CA клиента, добавили в доверенные на всех нодах Veeam.

Подключение к Veeam

Veeam B&R v12 добавил поддержку immutable S3 Object Lock - это одна из причин, почему клиент не торопится менять инструмент резервного копирования. MinIO поддерживает Object Lock в режиме COMPLIANCE и GOVERNANCE начиная с актуальных релизов.

Бакет создаём с включённым Object Lock до подключения к Veeam - после создания бакета это изменить нельзя:

mc mb --with-lock minio-cluster/veeam-backups
mc retention set --default COMPLIANCE "30d" minio-cluster/veeam-backups

В Veeam добавляем как S3-совместимое хранилище с endpoint на nginx. Bucket name - тот же. Immutability в настройках репозитория включаем явно - Veeam проверяет наличие Object Lock на бакете при подключении и ругается, если его нет, но он был запрошен.

Сравнение с Yandex Object Storage

Тут надо честно сказать: сравнение не совсем fair, потому что MinIO работает в той же облачной сети, а Yandex Object Storage - отдельный сервис с другим путём трафика. Мы меряли throughput при полном бэкапе виртуальных машин одинакового размера.

MinIO Distributed (4 ноды, локальная сеть): скорость записи держится стабильно и упирается в пропускную способность облачной сети между нодами Veeam и MinIO, не в сам MinIO. Параллельные задачи не мешают друг другу - erasure coding обрабатывает запись асинхронно.

Yandex Object Storage (нативный): скорость записи чуть ниже при одиночных потоках, но при параллельной нагрузке от нескольких заданий Veeam ведёт себя стабильно. Зато операции GET при восстановлении - чуть быстрее, чем с MinIO на виртуалках. Видимо, YOS за счёт большего масштаба лучше обрабатывает конкурентное чтение.

Итог сравнения: разрыв не драматический ни в ту, ни в другую сторону. MinIO выигрывает по задержке при записи в пределах одного сегмента. YOS - более предсказуем при росте количества параллельных задач. Для клиентского профиля (резервные копии ночью, восстановление редкое) MinIO закрывает задачу.

Что осталось не идеальным

• Мониторинг. MinIO отдаёт метрики в Prometheus - подключили к существующему стеку без боли. Но алерты на деградацию erasure-set нужно настраивать вручную, готовых рецептов в официальной документации на момент развёртывания было маловато.
• Расширение кластера. Добавить диски в существующий пул нельзя - только создать новый erasure set или новый кластер. Для клиента это не проблема сейчас, но при проектировании нужно закладывать запас с головой.
• Стоимость. Четыре ВМ плюс 16 дисков - это деньги, которых не тратишь с нативным managed-хранилищем. Экономика сходится только если есть требование изоляции или специфика по производительности.

Мы продолжаем смотреть за managed-инфраструктурой клиента. Через пару месяцев накопится статистика по реальным восстановлениям - тогда будет нагляднее, где MinIO держится, а где YOS был бы проще. Пока результат устраивает обе стороны.