Документы в информационных системах по умолчанию ложатся в объектное хранилище с S3 API. Оно даёт версионирование, предподписанные ссылки и горизонтальное масштабирование без общих сетевых папок. Файловое хранение остаётся рабочим выбором до 5-10 ТБ, когда сотрудники правят документы напрямую по SMB или NFS, а приложение не умеет работать с S3. Блочное хранение документы напрямую не хранит: LUN отдают файловой системе, СУБД или виртуальной машине.
Выбор сводится к четырём вопросам. Какой объём нужен сегодня и какой рост ожидается за три года? Как часто документы читают и правят? Требуется история версий и защита от удаления? Сколько стоит терабайт в год с учётом резервирования? Ответы дают тип хранения почти автоматически.
Дальше: критерии выбора с таблицей, сравнение трёх моделей хранения, слоистая архитектура документооборота, практика MinIO и Ceph, схемы отказоустойчивости, стратегия бэкапа и три готовые конфигурации под малый, средний и крупный масштаб.
Ключевые критерии выбора типа хранения документов
На старте проектирования проверяют семь параметров, каждый из которых отсекает часть вариантов.
- Объём и прогноз роста на три года с учётом запасa 20-30%.
- Характер доступа: чтение целиком, частичные правки, потоковая отдача, случайная выборка.
- Размер объектов: сканы по 200-500 КБ, PDF по 5-20 МБ, видеоархив по несколько гигабайт.
- Консистентность и блокировки: нужны ли одновременные правки одного файла.
- Версионирование и срок хранения истории: 1 год, 5 лет, бессрочно.
- Требования регуляторов: неизменяемость, сроки хранения, размещение данных на территории страны.
- Бюджет CAPEX и OPEX: стоимость терабайта в год, сетевые затраты, лицензии.
Сводка по трём моделям хранения показывает, где каждая из них проигрывает.
| Критерий | Файловое (NAS) | Блочное (SAN) | Объектное (S3) |
|---|---|---|---|
| Что получает потребитель | Каталоги и файлы | LUN как блочное устройство | Bucket, ключ объекта, метаданные |
| Протоколы | SMB 2/3, NFSv3, NFSv4 | iSCSI, Fibre Channel, NVMe-oF | HTTPS, S3 API |
| Масштабирование | Scale-up, реже scale-out | Scale-up по ёмкости и IOPS | Scale-out до петабайт |
| Версионирование | Снапшоты тома, теневые копии SMB | Снапшоты LUN | Встроенное, по объектам |
| Правка содержимого | Частичная, на месте | Через файловую систему поверх LUN | Только перезапись объекта целиком |
| Задержка | 0,5-3 мс в локальной сети | 0,1-1 мс | 10-100 мс на запрос |
| Стоимость терабайта | Средняя | Высокая | Низкая |
| Роль в системе документов | Общие папки отдела | Метаданные, СУБД, виртуальные машины | Основное хранилище и архив |
Два примера из практики. Массив на 10 ТБ со сканами договоров и редким доступом на чтение выгоднее держать в объектном хранилище: версионирование, lifecycle-политики и репликация в другой дата-центр настраиваются штатными средствами. Каталог на 1 ТБ, где пять сотрудников одновременно правят сметы в Word и Excel, требует файлового доступа с блокировками. Попытка перенести такую работу на S3 упирается в перезапись объекта целиком и отсутствие блокировок.
Классификация СХД, уровни RAID и расчёт IOPS под конкретную нагрузку разобраны в материале про системы хранения данных в 2026 году.
Файловое, блочное и объектное хранение: сравнение и сценарии применения
Три модели различаются тем, что именно получает потребитель: путь в иерархии каталогов, блочное устройство или HTTP-эндпоинт с ключом. Детальное сравнение протоколов, задержек и сценариев с примерами собрано в разборе объектного, блочного и файлового хранилищ.
Когда файловое хранение всё ещё оправдано
Файловый доступ нужен в четырёх случаях: объём до 5-10 ТБ, прямое редактирование документов людьми, приложения без поддержки S3 и простые бэкапы сетевым диском. Типовая конфигурация - NAS с четырьмя дисками в RAID 10, доступ по SMB для офиса на 20 человек, снапшоты тома раз в час с хранением двух суток.
Ограничения проявляются на росте. Контроллер NAS остаётся единой точкой отказа, а наращивание идёт заменой дисков и корпуса, не добавлением узлов. Каталог с миллионами файлов деградирует: листинг по SMB или NFS начинает отвечать секундами. Блокировки NFSv4 и SMB leases защищают от конфликтов при правке, но плохо работают между площадками. Для распределённых офисов файловую модель дополняют репликацией или кэширующим шлюзом, иначе филиал работает по медленному каналу.
Блочное хранение: производительность и ограничения
LUN по iSCSI, Fibre Channel или NVMe-oF даёт предсказуемую задержку от 0,1 мс, поэтому на блочных томах живут PostgreSQL, MySQL, MS SQL, KVM и VMware. Для документов этот тип применяют косвенно: как основу для объектного хранилища, кластерной файловой системы или диска базы метаданных.
Ключевое ограничение: блочное устройство не разделяется между хостами без кластерной файловой системы. GFS2 и OCFS2 добавляют кворум, fencing и собственные требования к задержкам. Второй нюанс - ёмкость тома не растёт от добавления дисков автоматически: расширение LUN, файловой системы и таблицы разделов выполняют вручную и с проверками. Третий - снапшоты LUN удобны для откатов, но не заменяют версионирование отдельных документов.
Объектное хранение и S3 API: почему это стандарт для документов
Модель проста: bucket содержит объекты, каждый объект имеет ключ, тело и пользовательские метаданные. Плоское пространство имён снимает ограничение на количество файлов в каталоге, а распределение по узлам выполняет внутренний механизм хранилища. AWS S3 даёт строгую согласованность чтения после записи для новых и перезаписанных объектов, поэтому приложение сразу видит загруженный документ.
Практические возможности, которых нет у файлового доступа: версионирование бакета, lifecycle-политики с переходом в холодный класс и удалением по сроку, предподписанные URL с ограниченным временем жизни, Object Lock для неизменяемых документов, серверное шифрование, репликация бакета в другой кластер. Ограничения тоже известны: объект нельзя изменить частично, максимальный размер объекта 5 ТБ при загрузке частями (один PUT до 5 ГБ, до 10 000 частей от 5 МБ), задержка выше файловой, а операции листинга дороги по ресурсам.
Хранилище на 100 млн сканов по 300 КБ даёт около 30 ТБ данных и требует индексации метаданных в отдельной базе: перебирать листинг по префиксам для поиска документа по реквизитам неработоспособно. Совместимые реализации: MinIO, Ceph RGW, OpenStack Swift с S3-совместимым слоем, облачные сервисы. Гибридный вариант - S3-шлюз перед NAS: горячие документы остаются локально, холодные уезжают в облако, приложение работает с единым S3-эндпоинтом.
Архитектура хранилища документов: слои и компоненты
Рабочая схема состоит из четырёх слоёв. Слой приложений принимает документы от веб-интерфейса, сканеров и внешних систем. Слой метаданных хранит карточки документов и поисковый индекс. Слой хранения отвечает за сами файлы в объектном хранилище. Слой управления закрывает аутентификацию, права и аудит.
Поток данных при загрузке: API-шлюз проверяет токен и права, приложение считает SHA-256 и проверяет дубликат, объект пишется в bucket, затем в базу попадает карточка с ключом объекта, после чего документ уходит в поисковый индекс. Выдача идёт двумя путями: через API для бизнес-логики или через предподписанный URL, чтобы файл отдавался напрямую хранилищем без нагрузки на приложение.
Управление метаданными и индексация
Метаданные удобно держать в PostgreSQL: транзакции, внешние ключи, репликация и понятное резервное копирование. Минимальный набор полей: идентификатор, имя, MIME-тип, размер, хеш SHA-256, дата создания, автор, теги, версия, ключ объекта в хранилище, срок хранения. Хеш решает две задачи: проверка целостности при восстановлении и защита от повторной загрузки одного файла (идемпотентность).
Полнотекстовый поиск строят на OpenSearch или Elasticsearch: в индекс уходят текст документа, реквизиты и права доступа, чтобы фильтровать результаты по подразделению. Для 1 млн документов индекс занимает десятки гигабайт и требует отдельного планирования шардов. Разметку входящих сканов часто поручают моделям: единый API к десяткам нейросетей без VPN и с оплатой в рублях даёт агрегатор вроде AiTunnel, который удобно использовать для классификации и извлечения реквизитов. Если из документов строится аналитика, поток загрузок дополнительно уводят в брокер и обрабатывают отдельно, о чём подробно написано в статье про хранение больших данных и массивов.
API-шлюз и аутентификация
Шлюз на Nginx или Envoy закрывает три задачи: проверка JWT или OAuth 2.0 токена, ограничение скорости запросов и логирование доступа. Права описывают через RBAC: роль определяет доступ к префиксам bucket, например отдел кадров видит только свой префикс. Проверку подписи лучше выполнять на уровне хранилища политиками IAM, а шлюз оставлять для бизнес-логики и аудита.
Предподписанный URL со сроком жизни 5-15 минут снимает нагрузку с приложения и убирает необходимость проксировать гигабайты через шлюз. Логи доступа пишутся в отдельный bucket с включённым Object Lock, чтобы злоумышленник с правами администратора не смог их подчистить.
S3-совместимые хранилища: MinIO и Ceph на практике
Оба решения дают S3 API, но различаются порогом входа и потолком масштаба. MinIO поднимается на одном сервере с четырьмя дисками для теста и на четырёх узлах для продакшена. Ceph требует минимум трёх узлов с кворумом MON и оправдывает себя с десятков терабайт, когда нужны блочные, файловые и объектные пулы в одном кластере.
MinIO: развёртывание и настройка отказоустойчивости
Режимы: single-node single-drive только для проверки, single-node multi-drive для небольших инсталляций, multi-node multi-drive для продакшена. Диски берут одинакового размера, RAID под MinIO не нужен: отказоустойчивость даёт erasure coding, а RAID-контроллер добавляет точку отказа и скрывает от хранилища состояние отдельных дисков.
export MINIO_ROOT_USER=docsadmin
export MINIO_ROOT_PASSWORD=SilnyjParol2026
minio server http://node{1...4}/data/disk{1...4} --certs-dir /etc/minio/certs --console-address :9001
Настройка erasure set: от 4 до 16 дисков в наборе, чётность до половины набора. Схема 4+2 на шести дисках выдерживает отказ двух дисков, запись требует 5 из 6, чтение возможно при 4 доступных. Схема 8+4 даёт накладные расходы 50% и переживает потерю четырёх дисков в наборе. Переменные MINIO_ACCESS_KEY и MINIO_SECRET_KEY устарели, вместо них используют MINIO_ROOT_USER и MINIO_ROOT_PASSWORD.
mc alias set docs https://minio.example.net docsadmin SilnyjParol2026 mc mb docs/documents mc version enable docs/documents mc ilm rule add docs/documents --expire-days 2555 mc replicate add docs/documents --remote-bucket https://minio-dr.example.net/documents --replicate delete,existing-objects
Мониторинг важен не меньше настройки. Эндпоинт /minio/v2/metrics/cluster отдаёт метрики для Prometheus, дашборд собирают в Grafana. Контролируют свободное место по каждому набору, ошибки heal, задержки PUT и GET, число незавершённых multipart-загрузок. В community-сборке графическая консоль урезана до браузера объектов, поэтому управление ведут через mc и API.
Ceph: когда сложность оправдана
Компоненты кластера: MON с кворумом из 3 или 5 узлов, MGR, OSD на BlueStore, MDS для CephFS, RGW для S3 и Swift API. В продакшене закладывают минимум три узла и 6+ OSD, сеть 10-25 Гбит/с с разделением на public и cluster. Журналы и БД BlueStore размещают на NVMe, иначе задержки записи растут, а backfill после отказа диска растягивается на дни.
ceph osd erasure-code-profile set ec-8-4 k=8 m=4 crush-failure-domain=host ceph osd pool create docs_data erasure ec-8-4 ceph osd pool create docs_index 128 128 ceph osd pool set docs_index size 3 ceph osd pool application enable docs_data rgw
CRUSH map задаёт failure domain: диск, узел, стойка, зал. Пул с size=3 переживает отказ узла или стойки. Для архивов берут EC-пул 8+4 с накладными расходами 50%, но индекс бакета RGW держат в реплицированном пуле, иначе операции листинга работают медленно. Порог nearfull по умолчанию 85%, full 95%: заполнять кластер выше 80% не стоит, иначе часть запросов отклоняется, а восстановление идёт с throttling. Восстановление 100 ТБ данных после отказа OSD занимает сутки и больше, и всё это время производительность кластера ниже обычной.
Отказоустойчивость и горизонтальное масштабирование хранилища
Надёжность строится на трёх уровнях: локальный RAID внутри узла, распределение копий или фрагментов между узлами, репликация между площадками. Первые два защищают от отказа железа, третий - от аварии дата-центра и ошибок администратора.
Репликация vs erasure coding: что выбрать
| Схема | Накладные расходы | Сырая ёмкость на 100 ТБ полезной | Сценарий |
|---|---|---|---|
| Репликация 3 копии | 200% | 300 ТБ | Горячие документы, высокая нагрузка на чтение |
| Erasure coding 4+2 | 50% | 150 ТБ | Основной массив документов среднего размера |
| Erasure coding 8+4 | 50% | 150 ТБ | Архивы и крупные объекты, меньше накладных на узел |
| RAIDZ2 локально | Зависит от ширины vdev | Зависит от конфигурации | Защита внутри одного узла до распределения |
Репликация проще в обслуживании: копия восстанавливается быстрым копированием, вычислений почти нет. Erasure coding экономит диски, но при восстановлении читает данные со всех уцелевших фрагментов и нагружает CPU и сеть. Для документов с редким доступом выбор очевиден в пользу 4+2 или 8+4. Для критичных данных с высокой нагрузкой на чтение оставляют репликацию.
Планирование ёмкости и масштабирование
Полезная ёмкость при erasure coding считается по формуле: сырая ёмкость × k / (k + m). Для схемы 4+2 это 66,7%, для 8+4 - те же 66,7% при другой ширине набора. Пример: 10 ТБ документов, схема 4+2, запас 30% на перебалансировку и рост. Требуется 10 × 1,5 × 1,3 = 19,5 ТБ сырой ёмкости. Округляют до 24 ТБ, если диски по 8 ТБ, чтобы получить ровный набор.
Горизонтальное масштабирование сводится к добавлению узлов и наборов дисков. MinIO добавляет новый erasure set и сразу принимает записи, перераспределение затрагивает только новые объекты. Ceph пересчитывает CRUSH и запускает backfill, который в больших кластерах идёт сутками, поэтому добавление узлов планируют на окно низкой нагрузки и ограничивают скорость восстановления через параметры backfill. Балансировку выполняет сама система: Ceph распределяет placement groups, MinIO использует хеш по имени объекта для выбора набора. Заполнение выше 80% и отказ диска одновременно создают риск потери кворума, поэтому свободное место держат под контролем. Детали проектирования и реорганизации таких систем, включая уровни hot, warm, cold и archive, разобраны в статье про проектирование информационной системы хранения данных предприятия.
Стратегия резервного копирования хранилища документов
Базовое правило 3-2-1: три копии данных, два разных носителя, одна копия вне основной площадки. К нему добавляют нулевую ошибку проверки: без регулярного теста восстановления бэкап остаётся надеждой, а не защитой.
| Класс документов | RPO | RTO | Схема |
|---|---|---|---|
| Активный документооборот | 15 минут | 1-2 часа | Репликация бакета, снапшоты метаданных |
| Юридически значимые документы | 1 час | 4 часа | Immutable-копия с Object Lock |
| Архив старше трёх лет | 24 часа | 1-3 суток | Холодный класс, лента, внешняя площадка |
Резервное копирование объектного хранилища
Методы складывают в три группы. Репликация бакетов (bucket replication в MinIO, multisite в Ceph RGW) переносит объекты и их версии в удалённый кластер почти без задержки. Снапшоты файловой системы (ZFS, Btrfs) дают мгновенный снимок тома и удобны для отката после ошибочного удаления. Выгрузка в холодный класс или на ленту закрывает требование хранить копию вне сети.
Версионирование не заменяет бэкап: удаление бакета или потеря ключей шифрования уничтожает и актуальные данные, и версии. Для защиты от шифровальщиков используют immutable backup: Object Lock в режиме compliance, офлайн-копию на ленте или диске, который отключают от сети. Инструменты вроде restic, borg и rclone дают дедупликацию, шифрование на клиенте и проверку контрольных сумм. Пример рабочей схемы: ежедневная репликация бакета документов во второй дата-центр, еженедельный инкрементальный бэкап метаданных PostgreSQL, ежемесячная полная копия архива на ленту с хранением 12 месяцев.
Восстановление и проверка бэкапов
Процедура восстановления должна быть описана и проверена до аварии. Минимальный регламент: раз в месяц поднимать тестовый стенд из бэкапа, восстанавливать случайный документ, сверять SHA-256 с записью в базе метаданных, фиксировать фактическое время восстановления. Рассинхрон метаданных и объектов лечится сверкой списка ключей в bucket с таблицей документов: такие отчёты полезно запускать еженедельно.
Типовые архитектуры: от малого бизнеса до enterprise
Три конфигурации закрывают большинство задач. Различаются они объёмом, требованиями к отказоустойчивости и стоимостью владения.
Малый бизнес: простота и бюджет
NAS на четыре диска по 8 ТБ в RAID 10 даёт около 14 ТБ полезной ёмкости, доступ по SMB и NFS для 10-25 человек, снапшоты раз в час. Бэкап: внешний USB-диск с ротацией плюс ночная копия в облачное хранилище. Ориентировочный CAPEX на железо 150-250 тыс. руб., OPEX сводится к электричеству и облачным копейкам за архив. Ограничения принимают сознательно: горизонтального масштабирования нет, контроллер остаётся единой точкой отказа, при поломке сервер восстанавливают из бэкапа за несколько часов.
Средний бизнес: кластер MinIO
Четыре сервера по четыре диска 8 ТБ дают 128 ТБ сырой ёмкости. В распределённом режиме с erasure coding 4+2 полезная ёмкость около 85 ТБ, с запасом 20% под рост и перебалансировку - примерно 68 ТБ. Схема выдерживает отказ двух дисков в наборе или одного узла без потери данных. Метаданные живут в PostgreSQL со streaming replication, поиск в OpenSearch, доступ к документам идёт через Nginx как API-шлюз с проверкой JWT. Бэкап: репликация бакетов в удалённый кластер MinIO и еженедельные снапшоты базы. Для площадки под DR или для переноса части нагрузки в облако подойдёт инфраструктура вроде Timeweb Cloud: виртуальные серверы, базы данных и хранилище разворачиваются за минуты и оплачиваются по факту использования.
Enterprise: Ceph и мультисайт
Кластер из 10 узлов со 100+ OSD, пул size=3 для горячих данных и EC-пул 8+4 для архива, RGW с S3 API, MDS для CephFS под общие каталоги. Второй кластер в другом дата-центре получает данные через multisite-репликацию RGW. Интеграция с LDAP или Active Directory, аудит доступа в отдельный индекс, шифрование трафика TLS 1.2/1.3. Полезная ёмкость считается по тому же принципу: 1 ПБ сырых дисков при EC 8+4 дают около 660 ТБ под данные. CAPEX начинается с нескольких миллионов рублей, OPEX включает выделенную команду из двух-трёх инженеров, сопровождение и обновления кластера. Такая конфигурация окупается на объёмах от 300-500 ТБ.
Безопасность и соответствие требованиям
Базовый набор мер одинаков для всех масштабов. Трафик шифруют через TLS, ключи хранят вне конфигурационных файлов, доступ описывают политиками IAM с RBAC. Серверное шифрование включают на уровне бакета (SSE-S3) или через внешний KMS (SSE-KMS). Шифрование на стороне клиента усиливает защиту, но ломает серверный полнотекстовый поиск: индекс приходится строить на расшифрованных данных в доверенном контуре.
Регуляторные требования задают архитектуру заранее. GDPR требует минимизации данных и права на удаление, 152-ФЗ - хранения персональных данных на территории страны, HIPAA - аудита любого доступа к медицинским документам. Для юридически значимых документов включают WORM через S3 Object Lock: объект нельзя изменить или удалить до истечения срока хранения даже администратору. Логи доступа и операции администраторов пишутся в отдельный бакет с включённым версионированием и Object Lock, что даёт доказательную базу при разборе инцидентов.
Чек-лист проектирования хранилища документов
- Определить объём документов, темп роста и срок хранения по классам.
- Выбрать тип хранения: объектное для основного массива, файловое для совместной правки, блочное для СУБД и виртуальных машин.
- Рассчитать сырую ёмкость с учётом схемы erasure coding и запаса 20-30%.
- Выбрать S3-совместимое решение: MinIO для средних инсталляций, Ceph для петабайтных и мультисайтовых.
- Спроектировать отказоустойчивость: failure domain, кворум, число одновременных отказов, которое переживает система.
- Включить версионирование бакетов и lifecycle-политики с переходом в холодный класс.
- Спроектировать метаданные и поиск: PostgreSQL для карточек, OpenSearch для полнотекста, SHA-256 для целостности.
- Разработать стратегию бэкапа по правилу 3-2-1 с immutable-копией и защитой от шифровальщиков.
- Закрыть безопасность: TLS, IAM-политики, RBAC, аудит доступа, WORM для юридически значимых документов.
- Провести тестовое восстановление и зафиксировать фактическое время, затем задокументировать архитектуру и регламенты.
Начните с расчёта ёмкости и схемы отказоустойчивости: эти два числа определяют выбор между NAS, MinIO и Ceph. Дальше поднимайте тестовый кластер на минимальной конфигурации, прогоняйте сценарии загрузки, версионирования и восстановления, и только после проверенных цифр переносите систему в продакшен.