Как выбрать систему хранения данных: критерии, расчёт ёмкости и чек-лист для сисадмина

С чего начать выбор СХД: определяем тип нагрузки

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

Профили нагрузок, с которыми приходится работать в 2026 году:

• OLTP и СУБД (PostgreSQL, MS SQL, MySQL, Oracle): случайные операции блоком 4-8 КБ, цель по задержке ниже 1 мс, счёт идёт на десятки тысяч IOPS.
• VDI: всплески при массовом входе пользователей (boot storm), в среднем 40-60 IOPS на пользователя, доля записи выше, чем у транзакционных систем.
• Файловые серверы и домашние каталоги: 3-8 IOPS на активного пользователя, высокая чувствительность к операциям с метаданными, то есть к созданию и перебору каталогов.
• Бэкапы и архив: длительные последовательные потоки, приоритет у пропускной способности, а не у IOPS.
• Контейнерные среды (Kubernetes): множество мелких томов, нагрузка следует за расписанием подов, часто достаточно NFS или блочных томов через CSI-драйвер.
• Медиахранилища и видеонаблюдение: непрерывная последовательная запись, решающими становятся ёмкость и стабильность потока.

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

Блочная, файловая или объектная СХД: что выбрать

Три архитектуры закрывают разные сценарии, и путать их дорого.

• Блочная (SAN). Сервер видит сырые LUN и сам решает, какую файловую систему на них разместить. Протоколы: iSCSI по Ethernet, Fibre Channel по выделенной сети, NVMe-oF. Базовый вариант для баз данных, гипервизоров и кластеров.
• Файловая (NAS). Общий доступ к файлам по NFS для Linux и VMware, по SMB для Windows. Подходит для домашних каталогов, общих папок, бэкапов и томов Kubernetes.
• Объектная. Доступ по HTTP к S3-совместимому API, у каждого объекта есть ключ, метаданные и теги. Рассчитана на миллиарды объектов: архивы, ML-датасеты, резервные копии, логи.

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

Как определить требования к производительности на этапе планирования

Статистику снимают до покупки, а не после жалоб пользователей. В Linux пригодятся iostat -x 5 и sar -d, в Windows - Performance Monitor со счётчиками Avg. Disk sec/Read и Avg. Disk sec/Write, в VMware - вкладка Performance для датастора. Период наблюдения минимум две недели, чтобы поймать закрытие месяца и окно ночных бэкапов.

Формула для быстрой оценки: требуемые IOPS = (число активных пользователей × операции на пользователя в секунду) / длительность пикового интервала, результат умножается на коэффициент пика 1,5-2. Для синтетических проверок используйте fio с профилями randread и randwrite при размере блока 4 КБ и iodepth 32 либо vdbench. Замер на глубине очереди 1 и на глубине 32 расходится в разы, поэтому сравнивайте только сопоставимые профили.

Ориентиры по задержке: СУБД - ниже 1 мс, VDI - 5-10 мс, файловые серверы - до 20 мс. Разделяйте случайные и последовательные операции: диски HDD отдают 75-150 случайных IOPS и до 200 МБ/с при последовательном чтении, а массив NVMe с миллионом случайных IOPS легко упирается в пропускную способность сети. Расчёт IOPS и задержки именно под виртуальные машины разобран в руководстве СХД для виртуализации под VMware и Proxmox.

Расчёт ёмкости СХД: от полезного объёма до запаса на снапшоты

Реальная ёмкость всегда меньше суммы дисков. Часть объёма забирает RAID, часть уходит на снапшоты, метаданные файловой системы и служебные издержки. Порядок расчёта выглядит так:

1. Определите полезную ёмкость: объём данных плюс метаданные приложений и индексы.
2. Добавьте запас на рост 20-30% на один-два года вперёд.
3. Заложите место под снапшоты: 10-20% от полезной ёмкости.
4. Учтите служебные издержки: 5-10% на метаданные файловой системы, журналы и thin provisioning.
5. Разделите результат на коэффициент RAID, чтобы получить raw-ёмкость.

Формула: raw = (полезные данные × (1 + запас роста) × (1 + доля снапшотов) × (1 + издержки ФС)) / коэффициент RAID.

Пример. Полезные данные 10 ТБ, запас роста 25%, снапшоты 15%, издержки 5%. Получаем 10 × 1,25 = 12,5 ТБ, затем 12,5 × 1,15 = 14,4 ТБ, затем 14,4 × 1,05 = 15,1 ТБ usable. При RAID 6 на массиве из 10 дисков коэффициент равен 0,8, значит нужно 15,1 / 0,8 = 18,9 ТБ raw. Практичная конфигурация: 10 дисков по 2 ТБ плюс один диск в горячем резерве, итого 20 ТБ raw и около 16 ТБ usable.

Как RAID влияет на доступную ёмкость

Формулы полезной ёмкости: RAID 5 - (N-1) × размер диска, RAID 6 - (N-2) × размер диска, RAID 10 - N/2 × размер диска. Для массива из 8 дисков по 4 ТБ это 28 ТБ, 24 ТБ и 16 ТБ соответственно. Горячий резерв уменьшает raw-ёмкость ещё на один диск, зато перестройка массива начинается сразу после отказа, без выезда инженера.

Для дисков объёмом выше 4 ТБ RAID 5 рискован: вероятность нечитаемого сектора (URE) при полной перестройке становится заметной, а восстановление массива из дисков по 18-22 ТБ длится сутки и больше. Практика 2026 года: RAID 6 для ёмких HDD-массивов, RAID 10 для баз данных с интенсивной записью. Детали выбора уровня, настройки контроллеров и расчёта latency собраны в руководстве Выбор и настройка RAID для серверов СУБД и виртуализации.

Снапшоты и thin provisioning: сколько закладывать

Снапшот не копирует данные целиком, он хранит ссылки на блоки. Место начинает расходоваться, когда исходные блоки меняются: чем чаще запись и чем дольше срок хранения, тем больше расход. Для снапшотов каждые 15 минут с хранением 7 дней закладывайте 15-20% полезной ёмкости, для ежедневных снимков с хранением 30 дней хватает 10%.

Thin provisioning добавляет отдельный риск. Пример: 100 виртуальных машин по 100 ГБ выделены тонкими томами, суммарно 10 ТБ, реально занято 30%, то есть 3 ТБ. Пока занятость растёт медленно, экономия очевидна, но суммарный выделенный объём превышает физический, и одновременный рост данных на всех томах приводит к переполнению пула и остановке записи. Решение: порог оповещения на 80% занятости пула и жёсткий на 90%, авторасширение пула и регулярная проверка фактического заполнения, а не выделенного.

Производительность и IOPS: как не купить слишком медленную или дорогую СХД

IOPS определяет судьбу случайных нагрузок, пропускная способность - последовательных. Оценивать нужно пиковое значение, а не среднее: массив, который держит 5 000 IOPS днём, столкнётся с 20 000 IOPS во время бэкапа и миграции виртуальных машин.

Как рассчитать IOPS для типовых нагрузок

• СУБД: 500 активных пользователей × 2 транзакции в секунду × 10 операций ввода-вывода на транзакцию = 10 000 IOPS, с коэффициентом пика 1,5 получаем 15 000 IOPS.
• VDI: 200 пользователей × 50 IOPS = 10 000 IOPS, доля записи около 80%.
• Файловый сервер: 1000 пользователей × 5 IOPS = 5 000 IOPS, преобладает чтение.

Доля чтения и записи меняет требования к кэшу. Для OLTP типично соотношение 70/30, для VDI - 20/80, поэтому кэш записи и энергонезависимая защита кэша важны сильнее, чем объём кэша чтения. Ориентиры по одному устройству: HDD 7200 об/мин - 75-150 IOPS, SATA SSD - 50 000-100 000 IOPS, NVMe - от 200 000 до миллиона IOPS и выше.

Latency и пропускная способность: что важнее

Для баз данных решает задержка: рост latency с 0,5 до 5 мс снижает пропускную способность транзакций в разы, даже если диски не загружены на 100%. Для бэкапов и видеопотоков важнее полоса. Прикидка: 10 Gigabit Ethernet даёт около 1,1 ГБ/с, значит резервная копия 100 ТБ займёт примерно 25 часов, а на 25 Gigabit Ethernet - около 10 часов.

NVMe-oF снижает задержку до 100 микросекунд против 1-3 мс у iSCSI в неоптимизированной сети. Заявленные вендором цифры IOPS достигаются на идеальном профиле: длинная очередь, крупный блок, отсутствие конкуренции за полосу. Проверяйте систему на своём профиле, пилот на две-три недели дешевле ошибочной закупки на пять лет.

Резервирование и отказоустойчивость: какой уровень выбрать

Минимальный рабочий уровень - RAID плюс горячий резерв. Для систем, где простой стоит денег, добавляются двойные контроллеры, репликация и резервирование путей. Уровень защиты выбирают от двух величин: RPO (сколько данных допустимо потерять) и RTO (сколько времени допустимо восстанавливаться).

RAID и горячий резерв: базовый уровень

RAID защищает от отказа диска, но не от удаления файла, шифровальщика или отказа контроллера, поэтому резервная копия остаётся обязательной. Горячий резерв ускоряет восстановление: массив из 12 дисков в RAID 6 плюс один резервный диск начинает перестройку автоматически, без ожидания замены. Для SSD горячий резерв менее критичен из-за меньшего времени перестройки, но при больших массивах NVMe он тоже оправдан.

Репликация и снапшоты: защита от логических ошибок

Снапшоты закрывают логические ошибки: случайное удаление, неудачное обновление, действия шифровальщика. Репликация закрывает отказ площадки. Рабочая схема для среднего проекта: снапшоты каждые 15 минут с хранением 7 дней, асинхронная репликация в резервный центр с RPO 15 минут. Для защиты от шифровальщиков используйте неизменяемые снапшоты (immutable snapshots), которые нельзя удалить с подключённого хоста.

Пример расчёта требований. Интернет-магазин теряет 10 000 долларов в час простоя. Допустимый RTO 5 минут и RPO 0 означают синхронную репликацию между контроллерами и автоматическое переключение. Если тот же магазин согласен на потерю 15 минут данных, достаточно асинхронной репликации, а это заметно дешевле. Каждый шаг по надёжности повышает стоимость, поэтому требования фиксируют письменно до выбора модели.

Протоколы доступа и совместимость с инфраструктурой

Протокол определяет не только скорость, но и совместимость с гипервизорами, серверами и системой резервного копирования. Базовый набор: iSCSI, Fibre Channel, NFS, SMB, S3 и NVMe-oF. Для виртуализации VMware обычно берут iSCSI или FC, для Kubernetes - NFS или CSI-драйвер, для архивов - S3.

iSCSI vs Fibre Channel: что выбрать в 2026

iSCSI работает поверх Ethernet 10/25/100 Гбит/с, не требует отдельной инфраструктуры и обходится дешевле. Обратная сторона: производительность зависит от сети и от настройки, при потерях пакетов задержка растёт. Fibre Channel предсказуем, изолирован в отдельной фабрике и по-прежнему популярен в крупных центрах обработки данных, но требует HBA, коммутаторов и отдельной компетенции в команде.

NVMe-oF вытесняет FC в новых проектах: он даёт задержку около 100 микросекунд и работает поверх Ethernet с RoCE или поверх той же фабрики FC. Для компании с парком до нескольких десятков серверов разумный старт - iSCSI с MPIO и jumbo frames 9000 MTU в отдельном VLAN. Для крупных баз данных с требованиями ниже 1 мс стоит считать NVMe-oF. Подробнее о настройке target, initiator и multipath - в статье Протоколы доступа к СХД: как выбрать и настроить iSCSI и NFS.

Файловые протоколы: NFS и SMB

NFS используют Linux, VMware и среда Kubernetes, SMB - Windows и частично macOS. Актуальные версии: NFSv4.1 с поддержкой pNFS и SMB 3.1.1 с шифрованием и подписью пакетов. В смешанной среде один NAS отдаёт доступ по обоим протоколам одновременно, но права доступа придётся согласовывать: сопоставление SID и UID через Kerberos или отображение пользователей настраивается заранее, иначе общие каталоги превращаются в источник инцидентов.

Масштабирование: как СХД будет расти вместе с данными

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

Scale-up vs scale-out: что выбрать

Scale-up означает добавление дисков и полок расширения к существующему контроллеру. Это проще в обслуживании, но упирается в число слотов и вычислительную мощность контроллеров. Scale-out означает добавление узлов в кластер: Ceph, vSAN и подобные системы дают неограниченный рост и распределяют нагрузку, но требуют сетевой фабрики, планирования отказоустойчивости и компетенций в команде.

Практическая прикидка: рост с 50 ТБ до 500 ТБ за три года выгоднее закрывать scale-out кластером, а рост с 20 ТБ до 60 ТБ - полками расширения на существующем массиве. Облачный вариант стоит рассматривать, когда данные растут непредсказуемо: Timeweb Cloud даёт блочные и объектные хранилища с изменением ресурсов по факту, что снимает риск простоя из-за переполнения локального пула.

Стоимость владения и лицензирование

Совокупная стоимость владения за 3-5 лет включает железо, лицензии на функции (снапшоты, репликация, тонкое выделение), поддержку, обучение персонала, электричество и охлаждение. Часть вендоров лицензирует ёмкость: расширение на 100 ТБ требует покупки дополнительных лицензий, а иногда и новой поддержки. Уточняйте цену расширения до подписания договора и просите посчитать сценарий роста на три года. Общий подход к проектированию уровней хранения и плану восстановления описан в материале Информационная система хранения данных: проектирование и реорганизация.

Чек-лист вопросов перед покупкой или развёртыванием СХД

Список ниже удобно отправить поставщику письмом и попросить ответы в письменном виде. Устные обещания менеджера не переносятся в договор, а значит не имеют силы при инциденте.

Вопросы по производительности и ёмкости

• Какие IOPS гарантируются на профиле 70/30 при блоке 4 КБ и очереди 32?
• Какая задержка при пиковой нагрузке и на каком числе томов?
• Сколько usable-ёмкости останется после RAID, снапшотов и метаданных в конфигурации из N дисков?
• Какой запас на рост заложен и что произойдёт при переполнении пула thin provisioning?
• Есть ли кэш записи с защитой батареей и как он ведёт себя при потере питания?

Насторожить должны ответы вида «до миллиона IOPS» без указания профиля, «ёмкость указана в спецификации» без расчёта usable и отказ назвать задержку под нагрузкой.

Вопросы по поддержке и стоимости владения

• Включена ли поддержка 24/7 и какой у неё SLA по времени реакции и восстановления?
• Сколько стоит расширение на 100 ТБ: железо, лицензии, полки, поддержка?
• Входят ли обновления микрокода и прошивок в контракт, как они устанавливаются?
• Предусмотрено ли обучение администраторов и доступ к базе знаний вендора?
• Можно ли поставить пилотную систему на две-три недели и протестировать её своим профилем?

Типичные ошибки при выборе СХД и как их избежать

Большинство провалов в проектах хранения связано с тремя вещами: недооценкой роста, игнорированием снапшотов и неподходящим уровнем RAID. Разбор частых ошибок:

1. Ёмкость без запаса на рост. Массив заполняется за год, а расширение требует новых полок и лицензий.
2. Нет места под снапшоты. Снимки молча съедают 15% пула и приводят к остановке записи.
3. RAID 5 на дисках свыше 4 ТБ. Перестройка длится сутки и риск нечитаемого сектора растёт пропорционально объёму.
4. Покупка без пилота. Синтетические показатели вендора не совпадают с реальным профилем приложения.
5. Недооценка IOPS. Массив держит среднюю нагрузку, но падает на пике бэкапа и миграции.
6. Нет плана масштабирования. Через два года выясняется, что слотов нет, а кластер требует другой сети.
7. Экономия на резервировании. RAID принимают за бэкап и остаются без копии при шифровании данных.

Пример из практики: компания выделила массив на 50 ТБ под файлы и виртуальные машины. За год данные выросли до 45 ТБ, снапшоты заняли ещё 10 ТБ, и пул thin provisioning переполнился. Запись остановилась, часть виртуальных машин пришлось отключать. При расчёте на старте хватило бы запаса 25% и порога оповещения на 80% занятости.

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