Информационная система хранения данных в ИТ-инфраструктуре предприятия: проектирование и реорганизация

Система хранения данных (СХД) предприятия - аппаратно-программный комплекс, который централизованно хранит данные и отдаёт их приложениям по блочному, файловому или объектному протоколу. Проект начинают с инвентаризации потребителей: СУБД, платформы виртуализации, Kubernetes, систем резервного копирования. У каждой группы свои требования к задержке, IOPS и режиму доступа, именно они задают архитектуру, а выбор модели массива идёт после.

Практический минимум для проекта: таблица требований по каждому сервису с объёмом, средним и пиковым IOPS, RPO и RTO; запас ёмкости 30-40% на три года; разделение разнородных нагрузок по пулам или через QoS. Если эти три пункта выполнены, реорганизация сводится к плановой миграции. Если нет, переезд базы данных на другой массив обходится в несколько окон обслуживания, а расходы на хранение оказываются на 40-60% выше, чем при раскладке данных по уровням hot, warm, cold и archive.

Дальше: пошаговый алгоритм проектирования, расчёты IOPS и ёмкости, сравнение RAID с репликацией, шаблоны таблиц требований и стоимости, план Disaster Recovery и чек-лист ошибок.

Что такое СХД и как она связана с остальной ИТ-инфраструктурой

СХД объединяет носители (NVMe, SSD, HDD, ленту), контроллеры и дисковые полки, файловые системы или блочные пулы и слой управления: снапшоты, репликацию, квоты, тонкое выделение, шифрование. Доступ выдаётся по протоколам: iSCSI, Fibre Channel и NVMe-oF для блоков, NFS и SMB для файлов, S3 для объектов.

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

Ключевые потребители ресурсов СХД: СУБД, виртуализация, контейнеры

СУБД работают с блоками и требуют стабильно низкой задержки: для OLTP практический ориентир - менее 1 мс на операцию записи, иначе транзакции выстраиваются в очередь и приложение ловит таймауты. От массива нужны тысячи операций ввода-вывода в секунду на активную базу, поддержка атомарных снапшотов пула или LUN для консистентных копий и предсказуемое поведение в пике.

Платформе виртуализации нужны общие датасторы, аппаратные примитивы разгрузки хоста (VAAI у VMware), тонкое выделение и снапшоты виртуальных машин. Консолидация сотни ВМ на одном LUN превращает его в узкое место: очередь команд растёт, задержка поднимается одновременно у всех машин.

Контейнерные платформы создают и удаляют тома динамически через CSI-драйверы. Базам в Kubernetes обычно нужен режим ReadWriteOnce с быстрым блочным устройством, общим файлам - ReadWriteMany на NFS или CephFS. Отдельное требование - скорость очистки: том после удаления пода освобождается за секунды, иначе «мёртвые» диски накопятся и место закончится раньше расчёта.

Пример конфликта нагрузок. На одном пуле живут OLTP-база и файловый сервис отдела. Сотрудник копирует 50 ГБ архива, задержка базы подскакивает с 0,4 до 15 мс, приложение теряет соединения. Разделение по пулам, отдельные LUN или лимиты QoS по IOPS и пропускной способности снимают проблему.

Типовые ошибки при определении границ СХД

• Недооценка роста данных. Запас 30-40% на три года - нижняя граница; расширение без него превращается в аврал с закупкой полок.
• Расчёт по среднему IOPS. Пиковые периоды (отчётность, распродажи, ночные бэкапы) требуют коэффициента 2-3.
• Отсутствие связи между уровнем избыточности и целевыми RPO и RTO. Избыточность выбирают «на глаз», а на учениях выясняется, что восстановление занимает сутки.
• Смешивание разнородных нагрузок на одном пуле без QoS.
• Забытые потребители: система резервного копирования, мониторинг, тестовые стенды, реестр контейнерных образов, репозиторий артефактов сборки.

Чек-лист вопросов владельцам сервисов: какой объём занимают данные сейчас и через год; сколько операций ввода-вывода в секунду требуется в пике; какая задержка приемлема; сколько данных допустимо потерять при аварии и за какое время сервис должен подняться; есть ли сезонность, планы развития или требования регуляторов по срокам хранения.

Как спроектировать СХД: пошаговый алгоритм от требований до внедрения

1. Сбор требований: интервью с владельцами сервисов, анализ текущей утилизации, прогноз роста.
2. Классификация данных по уровням hot, warm, cold, archive.
3. Расчёт ёмкости и производительности: IOPS, пропускная способность, задержка, коэффициенты запаса.
4. Выбор архитектуры: SAN, NAS, программно-определяемая СХД, гиперконвергентная платформа.
5. Определение уровня отказоустойчивости: RAID или erasure coding, репликация, резервирование контроллеров и путей.
6. Проектирование сети хранения: выделенные VLAN, jumbo frames, multipath, избыточные коммутаторы.
7. Планирование резервного копирования и Disaster Recovery с целевыми RPO и RTO.
8. Пилот на некритичном сервисе, нагрузочные тесты, проверка восстановления.
9. Документация, регламенты обслуживания, передача в эксплуатацию.

Сбор требований и аудит текущей инфраструктуры

Начинают с опроса владельцев приложений и со метрик. Источники: Zabbix, Prometheus с Grafana, отчёты самой СУБД (pg_stat_statements в PostgreSQL, AWR в Oracle, Performance Schema в MySQL), логи гипервизора и счётчики vSphere или Proxmox. Из метрик берут объём данных, скорость роста за квартал, средний и пиковый IOPS, задержку чтения и записи, утилизацию сети.

Прогноз роста берут из планов бизнеса: новый продукт, приток пользователей, требования регуляторов по сроку хранения. Сезонные пики (отчётные периоды, распродажи, начало учебного года) фиксируют отдельной строкой, иначе расчёт по среднему не выдержит нагрузки. Часть нагрузки можно вообще не размещать в своей СХД: если ML-эксперименты идут через внешний API, например через агрегатор AiTunnel с доступом к моделям GPT, Gemini и Claude, датасеты и веса не оседают в локальном хранилище и не требуют десятков терабайт.

Расчёт ёмкости и производительности: IOPS, задержка, пропускная способность

Требуемый IOPS = сумма средних IOPS всех потребителей, умноженная на коэффициент пика (обычно 2-3) и на коэффициент запаса 1,2-1,3.

Задержка определяется носителем: NVMe отдаёт десятки микросекунд, SATA и SAS SSD - сотни микросекунд, nearline HDD - единицы миллисекунд, а на случайной записи HDD проваливается в 10-15 мс. Пропускная способность в МБ/с важна для последовательных сценариев: бэкапы, видеонаблюдение, выгрузка аналитики, репликация.

Пример расчёта. База данных 1 ТБ с 5000 IOPS и файловое хранилище 10 ТБ с 500 IOPS. Суммарно 5500 IOPS, с коэффициентом запаса 1,3 выходит около 7150 IOPS. Для базы берут RAID 10 на NVMe или SAS SSD, для файлов - RAID 6 на nearline HDD: случайная нагрузка OLTP на RAID 6 с большими дисками даёт лишнюю задержку и долгое восстановление. По ёмкости: 12 ТБ данных плюс 35% запаса = 16 ТБ полезного объёма, с учётом потерь на уровень RAID (RAID 10 теряет половину) закупают 24-28 ТБ сырых дисков.

Узкое место часто находится выше дисков: контроллер, сеть или кэш. Один канал 10GbE отдаёт около 1100 МБ/с, и репликация «всё в поде» забивает его целиком. Проверяют это нагрузочным тестом до ввода в эксплуатацию: утилизация портов выше 60% в пике означает, что запас на исходе.

Выбор архитектуры: SAN, NAS, программно-определяемые и гиперконвергентные решения

• SAN (Fibre Channel, iSCSI, NVMe-oF): блочный доступ, предсказуемая задержка, подходит для СУБД и датасторов виртуализации. Требует отдельной сети и компетенций.
• NAS (NFS, SMB): файловый доступ, простая настройка прав, подходит для общих файлов, домашних каталогов и томов ReadWriteMany для Kubernetes.
• Программно-определяемые СХД (Ceph, ZFS, vSAN): работают на стандартных серверах, растут добавлением узлов, дешевле в наращивании ёмкости, но требуют понимания внутренней механики. ZFS даёт контрольные суммы, снапшоты и репликацию, а TrueNAS на его основе закрывает NFS, SMB и iSCSI для небольших инсталляций.
• Гиперконвергентные платформы (Nutanix, vSAN): вычисления и хранение на одних узлах, проще масштабировать целиком, сложнее разделять бюджеты и независимо менять ресурсы.

Критерии выбора: бюджет, требуемые задержки, наличие компетенций в команде, планы роста и потребность в вендорской поддержке. Развёрнутое сравнение классов и расчёт IOPS по нагрузкам собраны в статье СХД: классификация, архитектура и практический выбор. Если бюджет ограничен и важна скорость запуска, полезно заранее сравнить аппаратную и программную СХД по TCO и требованиям поддержки.

Уровни хранения данных: как выстроить иерархию hot, warm, cold, archive

Hot - NVMe и SAS SSD: активные базы, диски виртуальных машин с высокой нагрузкой, поисковые индексы. Warm - SATA SSD и SAS HDD: менее активные приложения, файловые сервисы, репозитории кода. Cold - nearline HDD и объектное хранилище: бэкапы, редко читаемая отчётность, логи. Archive - ленточные библиотеки и облачное объектное хранилище холодного класса: долгосрочное хранение и требования регуляторов.

Критерии отнесения данных к уровням хранения

• Частота доступа: ежедневно, еженедельно, реже раза в месяц.
• Требования к задержке: транзакционная база не терпит миллисекундных провалов, архив отчётов их не замечает.
• Срок хранения: от нескольких дней у логов до 5-10 лет у финансовых документов.
• Критичность для бизнеса и требования регуляторов к неизменяемости копий.

Примеры раскладки. Транзакционная база клиентского портала - hot. Кадровые документы и договоры в работе - warm. Годовые отчёты и закрытые проекты - cold. Архив за прошлые периоды с хранением 5 лет - archive. Автоматизируют перемещение политиками ILM на самой СХД, скриптами по метаданным (дата создания или последнего доступа) и тегами жизненного цикла в объектном хранилище. Холодную часть удобно держать не на своём железе: облачная инфраструктура вроде Timeweb Cloud даёт серверы, базы данных, объектное хранилище и управляемый Kubernetes, поэтому тестовые стенды и архивные копии размещают там без закупки полок и дисков.

Расчёт стоимости хранения данных по уровням

Ориентиры для планирования на 1 ТБ полезной ёмкости (без привязки к вендорам, разброс по регионам и моделям достигает двух раз):

Пример на 100 ТБ. Полностью флешевый вариант на NVMe обойдётся около 50 тысяч USD только за носители. Схема с уровнями: 15 ТБ hot на NVMe (около 7,5 тысячи), 25 ТБ warm на SATA SSD (около 3,5 тысячи), 45 ТБ cold на nearline HDD (около 1,5 тысячи), 15 ТБ archive на ленте (около 200 плюс библиотека от 8-10 тысяч). По носителям выходит около 13 тысяч, разница с all-flash достигает 60%, но её часть съедают библиотека, лицензии и работа администратора. Реалистичная оценка экономии в TCO на 5 лет - 40-60%.

В шаблон расчёта включают: стоимость носителей, полок, контроллеров, коммутаторов и лицензий; электропитание и охлаждение (nearline HDD потребляет 6-10 Вт на диск, лента в покое почти ничего); поддержку вендора; труд администратора (0,2-0,5 FTE на массив); аренду стойки; носители для бэкапа и репликации. Неправильная классификация данных даёт один из двух исходов: либо деградацию сервиса на медленном уровне, либо переплату за флеш там, где хватило бы HDD.

Обеспечение отказоустойчивости СХД и план Disaster Recovery

Отказоустойчивость строят на четырёх уровнях: диск, контроллер, узел, площадка. Метрики задают требования к каждому из них. RPO - сколько данных допустимо потерять, RTO - за какое время сервис должен вернуться в работу. Для базы с RPO 15 минут нужна синхронная репликация (даёт RPO 0) либо асинхронная с отставанием меньше 15 минут плюс снапшоты каждые 5-10 минут.

Выбор уровня избыточности: RAID, репликация, георезервирование

• RAID 1 и RAID 10: высокая производительность и устойчивость к отказу одного-двух дисков, цена - половина ёмкости.
• RAID 5 и RAID 6: экономия ёмкости, но ребилд диска 16 ТБ и выше длится часы и сутки, и всё это время массив уязвим. RAID 5 на больших дисках в новых проектах не применяют.
• Erasure coding: схема для объектных хранилищ (Ceph, S3-совместимые платформы), экономит ёмкость, но добавляет нагрузку на процессор при восстановлении.
• Синхронная репликация: RPO 0, требует канала с задержкой в единицы миллисекунд и снижает скорость записи.
• Асинхронная репликация: RPO от секунд до минут, работает между удалёнными площадками, не тормозит запись.
• Георезервирование: схема актив-пассив проще и дешевле, актив-актив требует согласованности данных и зрелой автоматизации переключения.

RAID не ловит «тихие» ошибки: битые сектора, которые носитель отдаёт без сообщения об ошибке. Контрольные суммы ZFS и Ceph выявляют их и восстанавливают блок из реплики. Практичные сочетания: критичные СУБД - RAID 10 плюс синхронная репликация внутри площадки и асинхронная на удалённую; файловые сервисы - RAID 6 плюс асинхронная репликация. Схемы связки RAID, репликации, снапшотов и multipath разобраны в материале об отказоустойчивости хранилища.

Разработка и тестирование Disaster Recovery плана

Рабочая структура документа: цель и область действия; роли и ответственность с именами и телефонами; инвентаризация сервисов с целевыми RPO и RTO; сценарии сбоев (отказ диска, контроллера, узла, площадки, шифровальщик, ошибка администратора); пошаговые процедуры восстановления с путями к копиям и командами; план коммуникаций с бизнесом; порядок пересмотра документа.

Учения превращают документ в работающий план: имитируют отказ (отключают узел, разворачивают базу из бэкапа на тестовый стенд), замеряют фактический RTO, разбирают узкие места и обновляют процедуры. Минимальная частота - раз в год, для критичных сервисов раз в квартал. Практический пример: регулярные учения сократили RTO с 8 до 2 часов, причём узким местом оказалось не восстановление данных, а согласование переключения DNS и порядок запуска зависимых сервисов.

Интеграция СХД с СУБД, виртуализацией и контейнерными платформами

Для СУБД выделяют отдельные пулы или LUN, чтобы чужие всплески ввода-вывода не влияли на транзакции. Снапшоты пула дают консистентные точки для бэкапа, но перед снятием базу приводят в согласованное состояние (pg_start_backup, fsfreeze, режим горячего бэкапа). Тонкое выделение экономно, однако суммарный размер томов выше физической ёмкости пула больше чем на 20-30% уже опасен. Параметры вроде innodb_flush_method=O_DIRECT в MySQL и wal_sync_method в PostgreSQL снижают двойное кэширование и сглаживают запись.

Особенности хранилища для виртуализации

Для виртуальных машин критичны низкая задержка и поддержка снапшотов. Датесторы разделяют по типам нагрузки: базы, файловые серверы, инфраструктурные ВМ и терминальные фермы живут на разных LUN с собственными лимитами. Аппаратные примитивы (VAAI) разгружают хосты при клонировании и обнулении блоков, multipath в режиме Round Robin с поддержкой ALUA даёт отказоустойчивость путей. Консолидация десятков активно пишущих ВМ на одном LUN превращает его в бутылочное горлышко.

Чек-лист для vSphere: включить VAAI, проверить политику выбора пути, настроить SIOC и лимиты IOPS, поставить алерты на заполнение датастора (предупреждение на 70%, тревога на 85%), вынести swap и логи на отдельный том. Для Proxmox: выбрать LVM-thin или ZFS, включить discard для тонких дисков, следить за фрагментацией и не смешивать на одном пуле диски ВМ и бэкапы. Сравнение DAS, NAS, SAN и HCI под виртуализацию и базы собрано в статье о выборе системы хранения для виртуализации баз данных и файловых сервисов.

Хранилище для Kubernetes: CSI, постоянные тома, StatefulSet

CSI-драйверы подключают к кластеру Ceph RBD, CephFS, NFS, iSCSI, локальные диски и блочные устройства облачных провайдеров. Режим доступа выбирают по задаче: ReadWriteOnce для баз и очередей (Ceph RBD, локальный NVMe), ReadWriteMany для общих файлов и артефактов (NFS, CephFS). Динамическое создание тома занимает от 10 до 30 секунд, и при одновременном старте десятков подов пауза растягивается на минуты: помогает volumeBindingMode: WaitForFirstConsumer и предварительно прогретый пул.

Защита данных в кластере строится на снапшотах CSI и резервном копировании (Velero, операторы СУБД). Снапшот тома не спасает при потере всего кластера или аккаунта, поэтому копии уходят на отдельное хранилище. Устройство программного массива, слои кэша и репликации подробно разобраны в статье о том, как устроено программное хранилище данных.

Резервное копирование и проверка восстановления данных

Правило 3-2-1 задаёт каркас: три копии данных, два разных типа носителей, одна копия вне основной площадки. Снапшоты на СХД ускоряют возврат отдельных файлов и дают точку консистентности, но лежат на тех же дисках: отказ массива, шифровальщик с правами администратора или ошибка в политике ретенции уничтожат их вместе с продакшеном. Снапшот дополняет бэкап, но не заменяет его.

Агентский бэкап читает данные через приложение (VSS в Windows, pg_basebackup в PostgreSQL) и даёт консистентную копию ценой нагрузки на сервер. Копирование со СХД через снапшот быстрее и почти не мешает продакшену. Инструменты выбирают по платформам: Veeam, Bacula, restic, Borg, коммерческие решения с поддержкой лент. Проверка восстановления обязательна: раз в квартал восстанавливают случайный файл или базу на тестовый стенд, сверяют контрольные суммы и запускают приложение. Показательный случай из практики: бэкапы писались два года без ошибок в отчётах, а на учениях выяснилось, что часть архивов повреждена из-за ошибки в скрипте ротации, и обнаружилось бы это только в реальной аварии.

Стратегии резервного копирования для разных уровней хранения

Политики задают в планировщике СХД или в ПО бэкапа и дублируют в документации: расписание, срок хранения, ответственный, порядок эскалации при сбое задания.

Реорганизация существующей СХД: план миграции без простоя

1. Аудит текущей СХД: занятость пулов, утилизация портов, задержки, список зависимых сервисов.
2. Выбор целевой архитектуры и расчёт ёмкости с запасом на три года.
3. Пилотная миграция некритичного сервиса и замер реальных показателей.
4. Планирование окон обслуживания и уведомление бизнеса за 1-2 недели.
5. Перенос данных: репликация, снапшоты, файловая синхронизация.
6. Переключение сервисов и обновление конфигураций (монтирования, IQN, DNS-имена).
7. Валидация: контрольные суммы, тесты приложения, замер задержек под нагрузкой.
8. Мониторинг в течение 2-4 недель и вывод старого оборудования.

Инструменты и методы миграции данных

• Онлайн-репликация на уровне СХД: SnapMirror, rbd mirror, zfs send и receive, репликация средствами платформы. Переносит блоки, простой только на переключение.
• Миграция на уровне гипервизора: vMotion и Storage vMotion, live migration в Proxmox. Виртуальная машина переезжает без остановки, но нужен общий кластер и совместимые процессоры.
• Файловая синхронизация: rsync, robocopy, rclone для объектных хранилищ. Первый проход делают заранее, затем повторный по разнице, и только после этого переключают сервис.
• Логическая репликация СУБД: streaming replication в PostgreSQL, встроенная репликация MySQL, Data Guard в Oracle. Позволяет заодно сменить версию и платформу.
• Валидация после переноса: сверка контрольных сумм, количества объектов и прав доступа, тесты приложения на новом массиве до переключения.

Предупреждения по рискам. Несовместимость протоколов (NVMe-oF против iSCSI, разные версии NFS) ломает план на середине. Пропускная способность сети задаёт сроки: перенос 50 ТБ на скорости 100 МБ/с занимает около 6 суток непрерывной работы. Забытые зависимости - монтирования NFS по IP, IQN инициаторов, лицензии, привязанные к серийным номерам, жёстко прописанные пути в конфигурациях - дают сбой уже после переключения.

Типичные ошибки при проектировании и реорганизации СХД

• Недооценка роста данных. Запас меньше 30% на три года приводит к авральной закупке. Решение: прогноз по метрикам за 6-12 месяцев плюс план развития бизнеса.
• Расчёт IOPS по среднему значению. Решение: коэффициент пика 2-3 и нагрузочный тест до ввода в эксплуатацию.
• Отсутствие QoS при смешивании нагрузок. Решение: отдельные пулы, LUN или лимиты по IOPS и МБ/с.
• Экономия на сети хранения: один коммутатор, один путь, отсутствие multipath. Решение: два коммутатора, два HBA или порта, проверка переключения путей.
• Отказ от учений по восстановлению. Решение: восстановление на тестовый стенд раз в квартал с замером RTO.
• RAID 5 на дисках большого объёма. Решение: RAID 6, RAID 10 или erasure coding, плюс контрольные суммы файловой системы.
• Отсутствие мониторинга производительности и заполнения. Решение: алерты на задержку, очередь команд, свободное место и ошибки носителей.
• Ожидание, что снапшоты заменяют бэкап. Решение: снапшоты для быстрого отката, отдельные копии по правилу 3-2-1 вне площадки.
• Переключение сервисов без валидации. Решение: контрольные суммы и функциональные тесты приложения до вывода старого массива.

Чек-лист перед запуском проекта: есть таблица требований с RPO и RTO по каждому сервису; запас ёмкости не меньше 30% и подтверждён прогнозом; пиковый IOPS посчитан с коэффициентом и проверен тестом; разнородные нагрузки разведены или ограничены QoS; RAID сочетается с репликацией, а не подменяет её; копии лежат по правилу 3-2-1 и восстанавливались за последние три месяца; план Disaster Recovery протестирован, а RTO замерен, а не оценён; сеть хранения имеет избыточные коммутаторы и пути; настроены алерты на задержку, заполнение пула и ошибки носителей.

Начните с таблицы требований и аудита метрик: эти два артефакта дают обоснование бюджета перед руководством и снимают большинство спорных решений на этапе выбора архитектуры.