Сравнение объектных хранилищ для документов в 2026: MinIO, Ceph и AWS S3

Что важно для объектного хранилища документов и СЭД

Под хранение документов и работу с СЭД в 2026 году рассматривают три варианта: MinIO, Ceph RADOS Gateway (RGW) и AWS S3. Короткий ответ по сценариям: MinIO подходит компаниям с объёмом документов до 300-500 ТБ, которым нужен S3-совместимый API и низкая задержка на мелких объектах при минимальной эксплуатационной нагрузке. Ceph выбирают, когда одним кластером закрывают объектный, блочный и файловый доступ и когда в штате есть инженер по хранению. AWS S3 берут в гибридных схемах и там, где обслуживание железа не входит в планы, а объём чтения из облака остаётся под контролем.

Средняя скорость кластера ничего не говорит о пригодности под документооборот. Профиль нагрузки здесь особый: миллионы мелких объектов, частые операции HEAD и LIST, версионирование, требования к целостности и срокам хранения. Выбор идёт по четырём измеримым критериям: покрытие S3 API, которое требует ваша СЭД; задержка PUT, GET и HEAD на объектах 50 КБ - 2 МБ; совокупная стоимость 1 ТБ в год с учётом трафика; и объём ручной работы по обслуживанию кластера.

Перед выбором вендора определите тип хранения, потому что объектное решение не заменяет блочное или файловое. Логика выбора и расчёт ёмкости с erasure coding разобраны в материале проектирование хранилища документов. Ниже речь идёт только о доступе через S3 API.

Почему документы - это отдельный класс нагрузки

Миллион документов средним размером 200 КБ занимает 200 ГБ полезных данных. Проблема не в объёме, а в количестве объектов: миллион записей в metadata-слое, миллион наборов тегов, версий и прав доступа. Дисковое пространство в такой нагрузке расходуется медленно, а метаданные и журнал операций становятся узким местом.

Хранение документов отличается от хранения изображений и видео по нескольким параметрам.

• Размер объекта: у сканов, PDF, DOCX и вложений он держится в пределах 50 КБ - 2 МБ, тогда как у фото 3-15 МБ, а у видео гигабайты.
• Состав операций: преобладают PUT, GET и HEAD, доля больших последовательных чтений невелика.
• Версионирование: каждая правка документа создаёт новую версию, и число объектов растёт быстрее, чем объём данных.
• Поиск: СЭД строит индекс по метаданным и регулярно перечисляет бакет, поэтому производительность LIST критична.

Проверить это просто. Откройте статистику своего хранилища и сравните: если средний размер объекта ниже 1 МБ, а число объектов измеряется миллионами, вы работаете в профиле документооборота. Кластер, рассчитанный на потоковое видео, на такой нагрузке покажет низкую утилизацию дисков и высокую загрузку CPU.

Требования СЭД к S3-совместимому API

Совместимость по названию протокола ничего не гарантирует. СЭД проверяет работу конкретных функций, и покрытие у self-hosted решений отличается. Практический список требований выглядит так.

• Подпись запросов по AWS Signature Version 4. Без неё клиент получит ошибку 403 при первом же обращении.
• Versioning бакета, иначе СЭД не сможет хранить историю редактирования.
• Object Lock и режим WORM для документов с регламентированным сроком хранения.
• Presigned URL, если СЭД отдаёт документы браузеру напрямую, минуя свой backend.
• Bucket policy и разграничение прав по префиксам, чтобы подразделения не видели чужие папки.
• Тегирование объектов и lifecycle-правила для перевода старых версий в холодный класс.
• Multipart upload и ListObjectsV2 для файлов крупнее 100 МБ и для постраничного обхода бакета.

AWS S3 остаётся эталоном API: всё перечисленное работает по умолчанию. MinIO и Ceph RGW покрывают список, но проверять нужно на своей версии, потому что поведение отдельных вызовов меняется от релиза к релизу. Отдельная ловушка: некоторые СЭД используют нестандартные расширения S3 или опираются на особенности формата ошибок AWS. Такие места выявляются только тестом на стенде.

Архитектура MinIO, Ceph и AWS S3: ключевые различия

Архитектура определяет три вещи: сколько людей нужно для эксплуатации, как ведёт себя кластер при отказе диска и что произойдёт при попытке увеличить ёмкость.

MinIO: простота и erasure coding

MinIO поставляется одним бинарным файлом и настраивается переменными окружения. Отдельного metadata-сервиса нет: данные и метаданные лежат на дисках, а согласованность обеспечивает erasure coding. Типовой старт под отказоустойчивый кластер: 4 ноды, по 8 дисков в каждой, набор дисков одинакового размера.

Масштабирование идёт добавлением server pool, то есть нового набора нод со своим набором дисков. Уменьшить пул или заменить в нём диски на диски другого размера нельзя, это ограничение архитектуры, и его учитывают на этапе планирования. MinIO работает только как объектное хранилище: блочного или файлового доступа к тем же данным не будет.

Ceph: гибкость RADOS и цена сложности

Ceph строится на распределённом хранилище RADOS и отдаёт доступ тремя способами: объекты через RGW, блочные устройства через RBD, файлы через CephFS. Объектный шлюз RGW реализует S3 API и подходит для СЭД.

Цена гибкости - число компонентов. Мониторы MON хранят карту кластера, OSD обслуживают диски, менеджеры MGR собирают телеметрию, MDS нужен для CephFS, RGW обслуживает S3. Размещение данных описывает CRUSH-карта, а число placement groups в пулах задают с запасом на рост. Ошибка в CRUSH-карте приводит к перекосу: часть OSD перегружена, часть простаивает.

Минимальная конфигурация для тестов: 3 MON и 3 OSD. Для продакшена этого мало, обычно ставят от 6 OSD и отдельные NVMe под журналы. Добавление OSD запускает ребалансировку, которая заметно расходует сеть и дисковый ввод-вывод.

AWS S3: управляемый сервис и его ограничения

AWS S3 закрывает задачу хранения без обслуживания железа. Сервис предлагает классы хранения Standard, Intelligent-Tiering, Glacier Instant Retrieval и Glacier Deep Archive, а согласованность операций чтения и записи строгая: после записи новой версии или удаления объекта следующий запрос видит актуальное состояние.

Ограничения лежат не в функциях, а в экономике и юрисдикции. Трафик чтения из интернета оплачивается отдельно, задержка доступа из локальной сети зависит от канала и измеряется десятками миллисекунд, а требования к хранению персональных данных могут запрещать размещение за пределами страны. Для СЭД с активным чтением документов счёт за трафик нередко превышает счёт за хранение.

Развёрнутые на своём железе решения сравниваются между собой подробнее в отдельном разборе выбор S3-совместимого хранилища, там же приведена матрица по MinIO, Ceph RGW и TrueNAS S3.

Производительность и масштабируемость под нагрузкой документооборота

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

Мелкие объекты: где решения различаются сильнее всего

На объектах 100 КБ и меньше различия проявляются максимально.

Причина разницы в архитектуре. MinIO обслуживает запрос на объект, минуя лишние слои, а Ceph RGW раскладывает операцию по RADOS, добавляя сетевые обмены между компонентами. AWS S3 стабилен, но к каждой операции добавляется задержка канала. Сравнение на больших массивах, с тестами на 10 и 100 млн объектов, есть в материале сравнение систем хранения изображений: профиль мелких файлов там разбирается подробно и переносится на документы.

LIST на больших бакетах тормозит у всех решений, включая AWS S3. Обход бакета с миллионами ключей идёт страницами по 1000 объектов, поэтому СЭД стоит настраивать на иерархию префиксов по годам, подразделениям или типам документов.

Масштабирование: добавление нод и дисков

MinIO расширяется добавлением server pool. Новый пул берёт на себя часть новых записей, старые данные автоматически не перераспределяются, поэтому равномерность достигается только при дальнейшем росте объёма. Пул из 4 нод по 8 дисков добавляют целиком, частичное добавление не поддерживается.

Ceph расширяется добавлением OSD и нод. Новые диски попадают в CRUSH-карту, после чего данные перераспределяются по кластеру. Ребалансировка занимает часы и дни при больших объёмах, и в это время задержка растёт.

AWS S3 масштабируется прозрачно для клиента. Внешние ограничения задают квоты на число запросов в секунду на префикс и бюджет. Планируя рост с 10 ТБ до 100 ТБ документов, закладывайте запас по дискам и сети: прирост числа объектов обычно опережает прирост объёма данных.

Стоимость владения: CAPEX, OPEX и скрытые расходы

Считать нужно стоимость 1 ТБ в год на горизонте 3-5 лет, включая трафик, обслуживание и резервные копии. Методика расчёта и сравнение локальной, облачной и гибридной схем приведены в статье локальные, облачные и гибридные системы хранения.

Локальные MinIO и Ceph: что входит в TCO

В локальной схеме расходы делятся на CAPEX и OPEX. В CAPEX входят серверы, диски, сетевые карты и коммутаторы, стойки и ИБП. В OPEX: электропитание, охлаждение, обслуживание железа, запасные диски, обучение и зарплата администраторов.

Пример для 100 ТБ полезной ёмкости под документы. Четыре ноды, в каждой 6 дисков по 12 ТБ, это 288 ТБ сырой ёмкости. Схема erasure coding 8+4 даёт около 192 ТБ полезных данных, что закрывает 100 ТБ с запасом на версии и копии бэкапов. Сеть 25 Гбит/с, NVMe под кэш метаданных. Ориентировочный бюджет железа: 2,5-4 млн рублей, плюс 15-20% в год на электропитание, ЗИП и обслуживание.

Разница между MinIO и Ceph в OPEX. MinIO обслуживает один администратор без специальной подготовки: обновление сводится к замене бинарника и перезапуску сервиса. Ceph требует понимания CRUSH, пулов и ребалансировки, а также дежурства при замене OSD. В крупных инсталляциях под Ceph выделяют отдельного инженера.

AWS S3: хранение, запросы и egress

Счёт в AWS S3 складывается из трёх частей: плата за хранение, плата за запросы и плата за исходящий трафик. Хранение в Standard стоит около 0,023 доллара за ГБ в месяц, запросы PUT около 0,005 доллара за 1000 операций, GET примерно в десять раз дешевле, а исходящий трафик за пределы AWS около 0,09 доллара за ГБ.

Расчёт для 100 ТБ документов и 10 ТБ чтения в месяц: хранение даёт примерно 2355 долларов, трафик около 920 долларов, пять миллионов запросов PUT около 25 долларов. Итого около 3300 долларов в месяц или примерно 39 600 долларов в год. Доля исходящего трафика в счёте близка к 28%, и она растёт пропорционально активности пользователей СЭД.

Скрытые статьи расходов в облаке: жизнь версий объектов, неполные multipart-загрузки, которые продолжают тарифицироваться, и запросы LIST от индексаторов СЭД. Ограничить их помогают lifecycle-правила, удаление неполных загрузок и лимиты на стороне приложения.

Для проектов, где облако нужно как площадка под сервисы вокруг хранилища, подойдёт аренда инфраструктуры: Timeweb Cloud даёт серверы, базы данных и объектное хранилище с оплатой по факту потребления, что позволяет развернуть тестовый контур рядом с продуктивом и не покупать железо под пиковую нагрузку.

Настройка S3-совместимого API для интеграции с СЭД

Порядок подключения одинаков для MinIO, Ceph RGW и AWS S3, различия касаются endpoint, региона и прав доступа.

Создание бакета и политик доступа

1. Создайте бакет с осмысленным именем, например sed-docs, и включите versioning до первой записи документов.
2. Включите шифрование на стороне сервера. MinIO и Ceph RGW поддерживают SSE-S3 и SSE-KMS, ключи храните вне кластера.
3. Создайте отдельного пользователя для СЭД. Root-ключи в приложении не используйте: они дают полный доступ ко всем бакетам.
4. Назначьте политику с минимальным набором действий.

Пример политики для учётной записи СЭД: чтение, запись и удаление объектов только в своём бакете, обязательное шифрование канала.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject", "s3:GetObjectVersion"],
      "Resource": ["arn:aws:s3:::sed-docs/*"],
      "Condition": {"Bool": {"aws:SecureTransport": "true"}}
    },
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket", "s3:GetBucketVersioning"],
      "Resource": ["arn:aws:s3:::sed-docs"]
    }
  ]
}

Права на ListBucket нужны почти всегда: без них СЭД не сможет построить индекс и покажет пустой список документов. Права на DeleteBucket приложению не выдавайте никогда.

Подключение СЭД: endpoint, ключи и проверка

В настройках хранилища СЭД указывают endpoint, access key, secret key и region. Для MinIO и Ceph RGW endpoint совпадает с адресом шлюза, например https://s3.company.local:9000, а регион задают произвольной строкой, важно чтобы он совпадал в настройках клиента и при подписи запросов.

1. Проверьте доступность endpoint из сети приложения и разрешите имя в DNS.
2. Установите сертификат. Самоподписанные сертификаты вызывают ошибки проверки цепочки на стороне СЭД.
3. Загрузите тестовый документ и скачайте его обратно, сверьте контрольную сумму.
4. Проверьте удаление и восстановление версии, а также создание presigned URL.

Проверку удобно делать штатным клиентом. Командой aws s3 cp с ключом --endpoint-url проверяют чтение и запись, а консольный клиент MinIO (mc) даёт команды alias, ls, cp и stat для быстрой диагностики. Для AWS S3 параметр --endpoint-url не нужен, но вызов aws s3api get-bucket-versioning покажет, включено ли версионирование.

Типичные ошибки подключения: несовпадение региона, из-за которого подпись не проходит; отсутствие прав на ListBucket; блокировка исходящих соединений на порт 9000; расхождение времени более пяти минут между СЭД и хранилищем, что ломает Signature V4.

Практическое развёртывание MinIO и Ceph в локальной инфраструктуре

MinIO: развёртывание кластера и типовые ошибки

Для кластера из четырёх нод подготовьте по 6 пустых дисков на каждой, статически назначьте адреса и настройте синхронизацию времени. Бинарник кладут в /usr/local/bin, конфигурацию в /etc/default/minio, запуск оформляют через systemd.

[Unit]
Description=MinIO
After=network-online.target

[Service]
EnvironmentFile=/etc/default/minio
ExecStart=/usr/local/bin/minio server $MINIO_VOLUMES --console-address ":9001"
Restart=always

# /etc/default/minio
MINIO_VOLUMES="https://minio{1...4}.lan/data{1...6}"
MINIO_ROOT_USER="admin"
MINIO_OPTS="--address :9000"

Проверка состояния выполняется командой mc admin info, вход в консоль остаётся на порт 9001. Типовые ошибки при запуске: разные версии бинарника на нодах кластера, директории с правами root вместо сервисного пользователя, диски разного размера в одном пуле и отсутствие мониторинга свободного места. MinIO отказывается стартовать, если набор дисков в пуле не совпадает по конфигурации, и это защищает от скрытой потери отказоустойчивости.

Про отказоустойчивость на уровне узлов и балансировку трафика перед кластером подробно написано в статье кластеризация серверов для бизнеса: те же принципы применимы к хранилищу, которое обслуживает СЭД.

Ceph: развёртывание RGW и требования к ресурсам

Ceph разворачивают через cephadm: он поднимает контейнеры на нодах и управляет сервисами.

cephadm bootstrap --mon-ip 10.0.0.11
ceph orch host add node2 10.0.0.12
ceph orch apply osd --all-available-devices
ceph orch apply rgw rgw --placement="3 node1 node2 node3"
ceph osd pool create sed-docs.rgw.buckets.data 128 128

Требования к ресурсам выше, чем у MinIO. Планируйте не менее 4 ГБ RAM на каждый OSD плюс запас под кэш, отдельные NVMe под журналы OSD, сеть 25 Гбит/с для трафика репликации и отдельную сеть для клиентского доступа. Для кластера-минимума нужны 3 MON и 3 OSD, для продакшена от 6 OSD и 3 экземпляра RGW.

Частые ошибки: запуск OSD на дисках совместно с системой, игнорирование заполнения пула выше 85%, установка слишком малого числа placement groups, из-за чего новые OSD получают перекос данных, и отсутствие отдельной сети для репликации. Каждая из них проявляется не сразу, а через месяцы эксплуатации.

Типовые ошибки и требования к ресурсам

Ошибки при планировании ресурсов

• Экономия на дисках: SMR-диски и настольные модели дают провал по задержке при записи и выпадают из кластера под нагрузкой.
• Недооценка сети: 1 Гбит/с на ноду не вытягивает ребалансировку и резервное копирование, 25 Гбит/с становятся нормой для кластеров от 100 ТБ.
• Малый запас RAM: для MinIO минимум 2 ГБ на ноду плюс кэш метаданных, для Ceph 4 ГБ на каждый OSD.
• Игнорирование роста числа версий: расчёт по объёму документов без учёта версий занижает ёмкость в 1,5-2 раза.

Пример расчёта для 100 ТБ документов с учётом версий и схемы erasure coding 8+4: полезные 100 ТБ превращаются в 150 ТБ с запасом на версии, а с учётом кода чётности нужна сырая ёмкость около 225 ТБ, то есть 24 диска по 12 ТБ в 4 нодах.

Ошибки при эксплуатации и масштабировании

• Отсутствие мониторинга свободного места и состояния дисков: заполнение пула выше 85% у Ceph и выше 90% у MinIO приводит к отказу записи.
• Ребалансировка без ограничений: у Ceph её стоит замедлять в рабочие часы, иначе СЭД получает рост задержки.
• Добавление в пул MinIO дисков другого размера или части нод: кластер не запустится или потеряет отказоустойчивость.
• Единая точка отказа в виде одного RGW или одного прокси перед MinIO.
• Резервное копирование самого кластера вместо репликации данных во второе хранилище: erasure coding защищает от отказа диска, но не от удаления бакета.

Практическое правило: любое изменение топологии, будь то добавление нод, замена дисков или обновление версии, сначала прогоняют на стенде с тем же профилем нагрузки. Проверка на пустом кластере ничего не показывает.

Рекомендации по выбору: MinIO, Ceph или AWS S3

Когда выбирать MinIO

MinIO подходит, если документы занимают до нескольких сотен терабайт, нужен только S3 API, а команда состоит из двух-трёх администраторов без опыта работы с распределёнными хранилищами. Характерный пример: компания с 50 ТБ документов и СЭД на 500 пользователей. Кластер из 4 нод закрывает нагрузку, обслуживание занимает несколько часов в месяц, а обновление сводится к замене бинарника.

Когда выбирать Ceph

Ceph оправдан, когда одним кластером нужно закрыть объектный, блочный и файловый доступ, например под СЭД, виртуальные машины и общие сетевые папки. Объёмы от 500 ТБ и выше, наличие инженера по хранению и требования к единой платформе делают его экономически осмысленным. Пример: предприятие с 1 ПБ данных и несколькими СЭД, где блочные тома для виртуализации и объектный доступ для документов живут в одной инфраструктуре.

Когда выбирать AWS S3

AWS S3 выбирают в гибридных схемах, при распределённых офисах и отсутствии желания обслуживать железо. Эластичность и глобальная доступность перекрывают задержку, если пользователи работают из разных стран. Обязательные условия: контроль исходящего трафика, lifecycle-правила для старых версий и проверка регуляторных требований к месту хранения персональных данных. Пример: компания с филиалами в трёх странах и объёмом документов до 20 ТБ, где локальный кластер не окупается.

Итоговая проверка перед решением: замерьте на стенде задержку PUT и GET для объектов своего размера, посчитайте стоимость 1 ТБ в год с трафиком и резервными копиями и оцените, сколько часов в месяц вы готовы тратить на обслуживание кластера. Эти три числа дают ответ быстрее любой таблицы сравнения.