Как выбрать систему хранения данных: пошаговая методика для DevOps и сисадминов

Почему выбор СХД - это процесс, а не сравнение цен

Два инженера получают одинаковый бюджет, 1,5 млн рублей. Первый обслуживает базу 1С с 800 одновременными пользователями, второй хранит видеоархив и ночные бэкапы. Закупка выглядит похоже, результат расходится: у первого база встаёт на блокировках через полгода, у второго половина дискового массива простаивает. Причина в том, что выбор системы хранения данных (СХД) начинается со сбора требований, а не с прайс-листа.

Ошибка на этапе требований стоит дороже всего. Массив из NVMe под архив медиафайлов = переплата в разы без выигрыша в скорости. NAS на четырёх HDD под транзакционную базу = деградация производительности в первые месяцы, когда нагрузка вырастет. Откатить такое решение задним числом почти невозможно: диски куплены, сервисный контракт подписан, миграция стоит простоя.

Методика состоит из шести шагов:

1. Сбор требований: IOPS, латентность, ёмкость, протоколы, профиль нагрузки.
2. Расчёт реальной нагрузки и запаса на рост.
3. Определение уровня отказоустойчивости: RAID, снапшоты, репликация, RPO и RTO.
4. Сравнение вариантов: NAS на TrueNAS или промышленная СХД с вендорской поддержкой.
5. Оценка совокупной стоимости владения (TCO) на 3-5 лет.
6. Пилотное тестирование и финальное решение.

Порядок шагов менять нельзя: TCO без требований превращается в гадание, а сравнение вендоров без метрик нагрузки даёт выбор по цвету корпуса. Методика одинаково работает и для TrueNAS на своём железе, и для массива за несколько миллионов рублей.

Шаг 1: Сбор требований к системе хранения данных

Требования описывают четырьмя группами параметров: производительность (IOPS и латентность), ёмкость (сырая и полезная), протоколы доступа и профиль нагрузки. Пока эти цифры не сведены в таблицу, сравнивать модели бессмысленно.

Профиль нагрузки определяет всё остальное. База данных OLTP читает и пишет блоками 4-8 КБ в случайном порядке, ей нужны десятки тысяч IOPS и латентность ниже 2 мс. Хранилище бэкапов и медиаархива работает с последовательными блоками по 1 МБ, ему хватает нескольких сотен IOPS и ёмкости на десятки терабайт. Между этими полюсами находятся файловые серверы, раннеры CI/CD, репозитории артефактов сборки и персистентные тома Kubernetes.

Владельцев приложений опрашивают отдельно от мониторинга. Разработчики часто говорят «нам нужно быстро», а мониторинг показывает 400 IOPS и латентность 4 мс. Обе цифры полезны: первая задаёт цель на будущее, вторая описывает текущее состояние.

Как определить IOPS и латентность для вашей нагрузки

Четыре инструмента закрывают почти все задачи сбора данных. iostat -x 1 показывает нагрузку на блочные устройства в реальном времени. sar -d читает историю за прошлые сутки из sysstat. ioping измеряет латентность чтения без создания нагрузки. fio генерирует синтетический профиль с заданными блоками и очередями. Для виртуальных машин метрики снимают на гипервизоре: esxtop для VMware, virt-top для KVM. Prometheus с node_exporter даёт удобные графики, но данные самого массива точнее показывают, что происходит на дисках.

Разделяйте случайный и последовательный доступ. Случайные операции 4 КБ ограничены механикой и глубиной очереди, последовательные упираются в пропускную способность интерфейса. Ориентиры по одному диску: HDD 7.2K в случайном чтении 4 КБ выдаёт 120-180 IOPS, SATA SSD - 50-90 тыс., NVMe - 300 тыс. и выше. Parity-массивы на HDD добавляют штраф на запись: блок 4 КБ превращается в read-modify-write по нескольким дискам.

Пересчёт на будущую нагрузку делается простой формулой. Если сейчас система выдаёт 1000 IOPS при латентности 10 мс, а рост ожидается трёхкратный, целевой показатель - 3000 IOPS при латентности не выше 10 мс. Латентность при этом нельзя усреднять: решение принимают по 95-му перцентилю, а не по среднему значению, иначе пиковые всплески останутся незамеченными.

Паспортные цифры вендоров снимают на идеальном профиле: 100% чтение, полный страйп, ни одного перестроения массива, пустой пул. Реальная работа даёт 40-60% от пиковых значений. Сравнивайте варианты по тестам со своим профилем.

Отдельный параметр - ресурс носителей. Для баз с постоянной записью считайте TBW (суммарный объём данных, который SSD выдерживает по гарантии) и закладывайте замену дисков в бюджет. Жизненный цикл данных, типы носителей и их ресурс подробно разобраны в материале об обработке и хранении данных в серверных системах.

Ёмкость: сколько места нужно на самом деле

Сырая ёмкость пула и полезная отличаются заметно. Пример: шесть дисков по 4 ТБ в RAIDZ2. Из 24 ТБ сырых данных на чётность уходит ёмкость двух дисков, остаётся 16 ТБ. Служебные метаданные ZFS, резерв на фрагментацию и снапшоты за месяц оставляют под файлы около 14-15 ТБ. Планирование по цифре 24 ТБ даёт ошибку почти 40%.

Сжатие lz4 на текстах, логах и JSON даёт коэффициент 1,2-1,5 без заметной нагрузки на процессор. Дедупликация экономит место на виртуализации с множеством одинаковых образов, при этом таблица дедупликации требует 1-5 ГБ RAM на каждый терабайт пула. На пуле с медиафайлами дедупликация не даст ничего и заберёт память, которая нужнее на кэш.

Резервируйте 20-30% полезной ёмкости на рост данных и снапшоты. Снапшоты занимают место только под изменения, но при активной записи их вклад в расход ёмкости становится заметным за считаные недели.

Протоколы доступа: iSCSI, NFS, SMB, NVMe-oF

Протокол задаёт, как приложение увидит хранилище, и напрямую сокращает список подходящих моделей.

• iSCSI: блочный доступ по сети. Гипервизоры, кластеры СУБД, приложения со своей файловой системой. Требует стабильной сети и корректно настроенного multipath.
• NFS: файловый доступ для Linux. Стандарт для персистентных томов Kubernetes через CSI-драйвер, для общих каталогов между серверами и для бэкапов.
• SMB: файловый доступ для Windows и смешанных сред, домашние каталоги, документооборот.
• NVMe-oF: блочный доступ к NVMe по сети с латентностью в десятки микросекунд. Нужен для высоконагруженных СУБД. Поддерживают его далеко не все массивы, и это само по себе критерий отбора.

Пример: кластер Kubernetes с 50 подами и персистентными томами проще всего поднять на NFS или на CSI-драйвере. Репозиторию артефактов сборки хватит SMB или NFS. Для PostgreSQL с миллионом транзакций в час нужен блочный доступ с низкой латентностью и предсказуемой глубиной очереди.

Для системного администратора в требованиях почти всегда всплывают снапшоты и репликация: без них любая ошибка администратора превращается в многодневное восстановление из бэкапа.

Шаг 2: Расчёт реальной нагрузки и запаса на рост

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

Как снять метрики с текущей системы

Минимальный набор инструментов и то, что они показывают:

• iostat -x 1: нагрузка на устройства в реальном времени, ключевые поля %util, await, r/s, w/s.
• sar -d -f /var/log/sa/saXX: история по дискам за прошлые сутки из пакета sysstat.
• ioping -c 50 /data: реальная латентность чтения на пустом и на нагруженном томе.
• fio: синтетический тест с профилем 4k randread, iodepth 32, numjobs 16 для поиска предела по случайному чтению.
• esxtop или virt-top: метрики виртуальных машин на стороне гипервизора.

Читайте метрики вместе, а не по одной. %util 100% при await 2 мс означает, что устройство загружено, но справляется. %util 60% при await 40 мс говорит о проблемах с очередями, контроллером или сетью. Расхождение между числом операций на хосте и на самом массиве указывает на кэш или на потери в сети.

Шаблон таблицы для сбора данных по приложениям:

Запас на рост: сколько закладывать и почему

Запас по IOPS - 30% на 1-2 года, по ёмкости - 20-30%. Пиковый коэффициент обычно держится в пределах 2-3 к среднему значению: если средняя нагрузка базы 1200 IOPS, проектируйте под 3000-4000 IOPS.

Пример расчёта: сейчас база выдаёт 2000 IOPS в пике, через год ожидается 3000 IOPS. СХД должна стабильно держать 3000 IOPS при латентности ниже 10 мс, а не показывать эту цифру на стенде вендора с пустым пулом.

ZFS добавляет свой нюанс: заполнение пула выше 85-90% снижает скорость из-за фрагментации и особенностей copy-on-write. Массив, забитый под завязку, теряет производительность в разы, поэтому свободное место входит в требования наравне с дисками.

Стратегия расширения тоже влияет на расчёт. В TrueNAS пул растёт добавлением новой группы дисков (vdev), и распределение данных по старым и новым vdev остаётся неравномерным. Промышленные СХД добавляют диски в существующий пул онлайн, без простоя и без пересборки структуры.

Экономия на запасе почти всегда приводит к деградации через 6-12 месяцев: сначала растёт заполнение пула, потом проявляются пиковые очереди, затем приложение упирается в латентность, и всё это происходит в самый неудачный момент.

Шаг 3: Требования к отказоустойчивости системы хранения данных

Отказоустойчивость описывают двумя метриками. RPO (Recovery Point Objective) - сколько данных допустимо потерять. RTO (Recovery Time Objective) - за какое время сервис вернётся в работу. Эти цифры запрашивают у бизнеса, а не выводят из возможностей железа: сначала допустимые потери, потом механизмы защиты.

RAID и ZFS: что выбрать для защиты от отказов дисков

Аппаратный RAID работает внутри контроллера: он быстрее на записи при батарейном кэше, но не проверяет целостность данных и привязывает к вендору. ZFS хранит контрольные суммы для каждого блока, поддерживает scrubbing и самовосстановление по данным чётности, работает на любом HBA в IT-режиме. TrueNAS построен на ZFS и поддерживает RAIDZ1, RAIDZ2 и RAIDZ3.

RAIDZ2 переживает отказ двух дисков, RAIDZ3 - трёх. Промышленные массивы решают ту же задачу через RAID 6 и RAID-TP. Плата за надёжность - ёмкость: в RAIDZ2 из шести дисков по 4 ТБ под данные уходит 16 ТБ из 24 ТБ, в RAIDZ1 осталось бы 20 ТБ, но массив не выдержит второго отказа во время восстановления.

Большие HDD добавляют риск по времени: перестроение массива на дисках 12-16 ТБ занимает 20-40 часов, и всё это время массив работает с пониженной избыточностью. Горячий резерв сокращает окно уязвимости, потому что замена начинается автоматически. RAID защищает от отказа железа и не защищает от удаления файлов, шифровальщика или ошибки администратора: для этого нужен бэкап по схеме 3-2-1, где есть три копии, два типа носителей и одна копия вне основной площадки.

Репликация и снапшоты: RPO и RTO на практике

Снапшоты фиксируют состояние пула и занимают место только под изменения, они спасают от логических ошибок. Репликация переносит снапшоты на второй сервер или площадку и спасает от отказа самого хранилища. В TrueNAS периодические снапшоты, например каждые 15 минут с хранением за 30 дней, и задачи репликации настраиваются штатными средствами, без сторонних скриптов.

Промышленные СХД дают синхронную репликацию с RPO=0, но за это платят задержкой записи: подтверждение приходит после записи на вторую площадку, и латентность растёт на величину задержки канала. Асинхронная репликация дешевле и терпимее к расстоянию между площадками.

Пример: интернет-магазин с оформлением заказов требует RPO 15 минут и RTO 1 час. Под это нужны снапшоты каждые 15 минут, реплика на второй узел и заранее описанный порядок переключения с проверкой на учениях. Внутреннему файловому серверу хватает RAIDZ2 и ежедневных снапшотов с хранением за 90 дней.

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

Шаг 4: Сравнение вариантов - TrueNAS или промышленная СХД

Сравнение ведут по пяти параметрам, а не по цене за гигабайт:

Когда достаточно NAS на TrueNAS

Файловый сервер, бэкапы, репозитории артефактов, персистентные тома Kubernetes через NFS, виртуализация до 20-30 машин, домашняя лаборатория. Конфигурация из шести HDD и двух SSD под L2ARC и SLOG держит 5-10 тыс. IOPS и латентность в единицы миллисекунд, чего хватает для десятков виртуальных машин и команд разработки.

Ограничения тоже конкретны: вендорской поддержки нет, экспертиза в ZFS и сетевом стеке нужна внутри команды, производительность упирается в железо и в шину. Как собрать такой массив с расчётом ёмкости, кэша и стратегией расширения, пошагово разобрано в руководстве по сборке и настройке массива на TrueNAS. Сравнение TrueNAS, Ceph, ZFS, OpenMediaVault и Unraid по требованиям к дискам, сети и команде собрано в материале о программных системах хранения.

Когда нужна промышленная СХД с вендорской поддержкой

Критерии перехода к вендорскому решению: латентность ниже 1 мс, IOPS выше 50-100 тыс., гарантированный SLA с реакцией инженера за 4 часа, синхронная репликация между площадками, тонкое провизионирование и QoS по томам, NVMe-oF. Биллинг телеком-оператора или процессинговый центр за час простоя теряет миллионы рублей, и на этом фоне экономия на поддержке обходится дороже самой поддержки.

Вендорская поддержка закрывает замену дисков по SLA, обновления прошивок, разбор инцидентов производительности и консультации по настройке. Разбор случаев, когда аппаратная СХД выигрывает у программной, приведён в статье об аппаратных и программных СХД.

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

Шаг 5: Оценка совокупной стоимости владения (TCO)

Сравнивать варианты по цене закупки бессмысленно, если горизонт эксплуатации 3-5 лет. Формула простая: TCO = CAPEX + OPEX, умноженный на число лет.

CAPEX и OPEX: что учитывать

• CAPEX: серверы и шасси, диски, HBA или RAID-контроллеры, сетевые карты и коммутаторы, лицензии, монтаж и пусконаладка.
• OPEX: поддержка вендора, электроэнергия и охлаждение, каналы связи, время администратора, обучение, замена вышедших из строя дисков, обновления.

Пример на три года. Промышленная СХД стоит 5 млн рублей плюс поддержка 500 тыс. рублей в год, итого 6,5 млн. TrueNAS на своём железе - 1,2 млн рублей плюс 200 тыс. рублей в год на администрирование, обновления и тестирование, итого 1,8 млн. Разница 4,7 млн рублей и есть цена предсказуемости и SLA. Если простой обходится дешевле этой суммы, разумнее взять TrueNAS и вложить часть денег в резервирование, мониторинг и второй узел репликации.

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

Стоимость простоя и риски

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

Дальше оценивают вероятность и длительность отказа для каждого варианта. Массив без вендорской поддержки, с одним блоком питания и без горячего резерва, восстанавливается от 4 до 24 часов. Промышленная СХД с резервированием всех компонентов и заменой диска за 4 часа укладывается в 1-2 часа. Если разница в ожидаемых потерях за год превышает разницу в TCO, решение принимается без сомнений.

В расчёт стоит добавить время своей команды. Администратор, который тратит четыре часа в месяц на разбор производительности и обновления, за три года отдаёт задаче около 150 часов.

Шаг 6: Проверка решения на практике

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

Профиль для fio задают под свою задачу: 4k randread и randwrite с iodepth 32 и 16 задачами показывают поведение под случайной нагрузкой, 1M sequential - пропускную способность бэкапа. Замеряйте IOPS и латентность p95 на 50%, 80% и 95% заполнении пула. Последний замер часто показывает провал, которого нет на пустом массиве.

Кроме скорости, проверьте восстановление: файл из снапшота, отказ диска на работающем массиве, время resilver, переключение на реплику, поведение при обрыве одного сетевого пути. У вендора промышленной СХД запросите демо-стенд с вашим профилем, для TrueNAS тестовый контур разворачивается в виртуальной машине или на временном сервере.

Помните, что бенчмарк и продакшен расходятся: кэш, очереди контроллера, сеть и поведение приложений дают другую картину. Решение принимают по результатам пилота на своей нагрузке, а не по презентации.

Чек-лист выбора СХД

1. Соберите требования: случайные и последовательные IOPS, латентность p95, полезная ёмкость, протоколы, профиль нагрузки.
2. Снимите текущие метрики (iostat, sar, ioping, fio, esxtop) за сутки, неделю и месяц, выделите пиковые значения.
3. Добавьте запас: 30% по IOPS и 20-30% по полезной ёмкости на 1-2 года.
4. Получите от бизнеса RPO и RTO, выберите уровень защиты: RAIDZ2 или RAID 6, горячий резерв, снапшоты, репликация, бэкап 3-2-1.
5. Сравните NAS на TrueNAS и промышленную СХД по производительности, поддержке, масштабированию и сложности эксплуатации.
6. Посчитайте TCO на 3-5 лет с поддержкой, электроэнергией, временем администратора и стоимостью простоя.
7. Проведите пилот: fio, реальная нагрузка, восстановление из снапшота, отказ диска, переключение на реплику.

Начните с таблицы требований. Пока в ней нет цифр по IOPS, латентности p95 и полезной ёмкости с запасом, любой выбор остаётся догадкой, а разница между TrueNAS и промышленной СХД обсуждается на уровне вкусов, а не инженерных расчётов.