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

Введение: почему выбор СХД - это не только про железо

Единой системы хранения, которая одинаково хорошо закроет файловый сервер на 20 ТБ и кластер виртуализации на 500 ТБ, не существует. Выбор определяют четыре параметра: сценарий использования, требуемая производительность в IOPS и задержке, набор протоколов доступа и бюджет на 3-5 лет с учётом трудозатрат.

Начните с профиля нагрузки, а не с бренда. Кластеру из 30 виртуальных машин нужны устойчивые 5 000-15 000 IOPS при задержке ниже 5 мс. Хранилищу резервных копий достаточно 500-800 МБ/с последовательной записи. Это два разных требования, и приводят они к разным решениям и разному бюджету.

Четыре критерия отсеивают неподходящие варианты быстрее всего: масштабируемость, поддержка NFS, SMB и iSCSI, интеграция с существующей инфраструктурой, совокупная стоимость владения (TCO). Ниже разберём каждый критерий, сравним TrueNAS, OpenMediaVault, Unraid и коммерческие СХД, затем пройдём алгоритм от сбора требований до пилотного стенда. Классификация архитектур (DAS, NAS, SAN, SDS, облако) и уровни RAID разобраны в статье о системах хранения данных в 2026 году, здесь же фокус на выборе конкретного решения.

Ключевые критерии выбора системы хранения данных

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

Масштабируемость: вертикальная и горизонтальная

Вертикальное масштабирование - это добавление дисков в массив, оперативной памяти под ARC-кэш ZFS или сетевой карты 25GbE. Горизонтальное - добавление узлов, между которыми распределяются данные. Первое дешевле и быстрее, второе упирается в пределы контроллера и число полок.

Ориентир по ёмкости: сервер 2U на 24 отсека с дисками 20 ТБ даёт около 300 ТБ сырой ёмкости, после чётности RAIDZ2 остаётся примерно 200-220 ТБ полезной. Дальше нужны внешние полки JBOD, SAS-экспандеры или второй узел.

TrueNAS масштабируется вертикально, а кластеризация в SCALE пока развивается и не закрывает все продакшен-сценарии: чаще строят два узла с репликацией zfs send/recv между ними. Ceph масштабируется горизонтально по-настоящему, но требует минимум трёх узлов, на практике пяти, и сети 10GbE и выше. OpenMediaVault и Unraid растут только вертикально, дисками и полками.

Вопрос для проверки: что произойдёт, когда данных станет втрое больше? Если ответ «добавим полку», уточните, поддерживает ли её контроллер и не упрётесь ли вы в лицензию по ёмкости.

Поддержка протоколов: NFS, SMB, iSCSI

Протокол определяется тем, кто и как обращается к данным:

• NFS (порт 2049) - файловый доступ для Linux, Unix, ESXi и контейнеров. Версии 3, 4.1, 4.2; в 4.1 и выше есть pNFS и мультипути.
• SMB (порт 445) - доступ для Windows и macOS. Версия 3.1.1 умеет шифрование, а SMB Direct использует RDMA и снимает нагрузку с процессора там, где есть RoCE или InfiniBand.
• iSCSI (порт 3260) - блочный доступ по TCP: диск для базы данных, кластера или гипервизора.

NFS over RDMA и SMB Direct нужны нечасто, но там, где нужны, замены нет: оба снижают задержку и освобождают CPU на скоростях 100GbE.

TrueNAS CORE и SCALE отдают все три протокола из коробки, включая Kerberos для NFS и SMB, цели iSCSI с LUN и тонким выделением. OpenMediaVault тоже поддерживает NFS, SMB и iSCSI, но тонкая настройка требует SSH, а часть опций приходит с плагинами. Unraid закрывает NFS и SMB, iSCSI работает с оговорками и не рассчитан на нагруженный блочный доступ. Коммерческие СХД поддерживают весь набор плюс Fibre Channel и NVMe-oF, но функции вроде асинхронной репликации часто лицензируются отдельными позициями.

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

Интеграция с существующей инфраструктурой

Ответы на эти вопросы нужны до покупки, а не после:

• Аутентификация: Active Directory, LDAP, Kerberos, локальные пользователи, ACL на уровне файлов.
• Виртуализация: NFS-датасторы и iSCSI-LUN для VMware vSphere, Proxmox VE, Hyper-V, снапшоты и клонирование на стороне СХД.
• Kubernetes: наличие CSI-драйвера. Для NFS это democratic-csi или nfs-subdir-external-provisioner, для Ceph - ceph-csi с RBD. Без драйвера останутся только PersistentVolume с NFS, собранные вручную.
• Резервное копирование: совместимость с Veeam, Restic, Borg, снапшот-интеграция, S3-совместимый шлюз (MinIO на TrueNAS) для копий за пределами площадки.
• Сеть и мониторинг: LACP, VLAN, экспорт метрик в Prometheus или SNMP-ловушки в Zabbix.

TrueNAS включает AD/LDAP, Kerberos, S3-шлюз и каталог приложений в контейнерах. OpenMediaVault подключает каталоги плагинами, а интеграцию с Kubernetes придётся собирать вручную. Unraid ориентирован на домашние и малые офисные сценарии, корпоративные каталоги поддерживает частично. Коммерческие СХД поставляют готовые плагины к vCenter, Veeam и системам мониторинга, обычно в рамках контракта поддержки.

Совокупная стоимость владения (TCO)

TCO на 3-5 лет состоит из пяти статей: железо, лицензии, администрирование, электроэнергия, обучение. Бесплатная система не означает нулевые расходы, разница переходит в часы инженера.

Считайте в часах. Восемь часов в месяц на обслуживание самосборного хранилища за три года дают около 290 часов. При ставке 2 000 ₽/час выходит 580 000 ₽, и эта сумма сопоставима с разницей в цене с коммерческой СХД начального уровня. Как соотносятся аппаратный и программный подходы по стоимости, отказоустойчивости и сценариям, разобрано в статье об аппаратных и программных СХД.

Сравнение популярных решений: TrueNAS, OpenMediaVault, Unraid и коммерческие СХД

Сводка по ключевым параметрам, от которых зависит выбор:

TrueNAS: возможности и ограничения

TrueNAS выпускается в двух ветках: CORE на FreeBSD и SCALE на Debian. Обе построены вокруг ZFS с контрольными суммами, снапшотами, репликацией zfs send/recv, компрессией LZ4 и ZSTD. Дедупликацию включайте только при большом объёме RAM, иначе таблица DDT съест память и замедлит запись.

Ориентир по ресурсам: правило «1 ГБ RAM на 1 ТБ ёмкости плюс 8-16 ГБ на систему» остаётся рабочим для случайного доступа. Для 100 ТБ файловых данных хватает 64 ГБ. Для виртуализации с большим числом случайных операций ставьте NVMe под SLOG (журнал ZIL) и L2ARC, иначе запись упрётся в диски.

Схемы пулов: RAIDZ1 переживает отказ одного диска, RAIDZ2 двух, RAIDZ3 трёх. Для дисков 16 ТБ и выше RAIDZ1 рискован: ребилд при 150 МБ/с занимает около 30 часов, и второй отказ в этот период обнулит пул. Зеркальные vdev дают лучшую производительность на случайных операциях, но забирают 50 % ёмкости.

Сильные сценарии: файловый сервер с NFS и SMB, хранилище для Proxmox и ESXi, приёмник резервных копий с репликацией, S3 через MinIO в SCALE. Слабые места: масштабирование за пределы одного узла, требовательность к RAM и невозможность расширить существующий RAIDZ-вирт одним диском, добавить можно только целый vdev.

Кому подходит: командам и специалистам, готовым разбираться с ZFS. Прямое сравнение с Ceph, ZFS on Linux и другими программными платформами есть в практическом сравнении программных систем хранения.

OpenMediaVault: простота и гибкость

OpenMediaVault - веб-интерфейс поверх Debian. В основе обычные Linux-технологии: mdadm, LVM, ext4, XFS, Btrfs, ZFS через плагин openmediavault-zfs. Установка на мини-ПК или старый сервер занимает 20-30 минут, базовая система работает на 4 ГБ RAM без ZFS.

Плагины закрывают Docker, SMB, NFS, iSCSI, Rsync, Borg Backup, работу с ИБП. Сильная сторона - предсказуемость и малый вес: один сервер на 8 дисков обслуживает файловый обмен для офиса до 20 человек.

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

Unraid: особенности и сценарии использования

Ключевая особенность Unraid - массив с выделенными дисками чётности, где можно смешивать накопители разного размера. Данные не распределяются по всем дискам: каждый файл лежит на одном накопителе, а чётность (один или два диска) позволяет пережить его отказ.

Плюсы: простота, добавление диска любого объёма, контейнеры и виртуальные машины из коробки, популярность в домашних медиасерверах. Минусы: скорость записи в массив ограничена скоростью диска чётности, для больших объёмов нужен кэш-пул NVMe. iSCSI работает, но нагруженные базы данных на него не ставят.

Лицензии платные и различаются числом подключаемых устройств. Для компании на 10-30 человек и массива до 100 ТБ Unraid удобен, для кластера виртуализации нет.

Коммерческие СХД: когда стоит переплачивать

Dell PowerStore и PowerVault, NetApp, HPE, IBM продают гарантированную производительность, поддержку 24×7 с SLA, конфигурацию активный-активный, репликацию между площадками и шифрование с внешним управлением ключами.

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

Переплата оправдана, когда час простоя дороже железа: биллинг, медицинские системы, кластеры баз данных с жёсткими требованиями к задержке, а также ситуации, когда нет инженера, способного сопровождать ZFS и Ceph.

Пошаговый алгоритм выбора СХД под конкретный сценарий

1. Определите сценарий: файловый сервер, хранилище для виртуализации, приёмник резервных копий, медиатека, артефакты CI. Сценарий задаёт профиль нагрузки.
2. Переведите требования в числа: полезная ёмкость сейчас и через три года, IOPS и задержка, последовательная пропускная способность, протоколы, допустимое время простоя.
3. Посчитайте бюджет и TCO на 3-5 лет, включая часы на администрирование и электроэнергию.
4. Проверьте интеграции: AD или LDAP, гипервизор, CSI-драйвер для Kubernetes, систему резервного копирования, сеть 10GbE или 25GbE.
5. Составьте шорт-лист из двух-трёх решений и прогоните каждое по чек-листу критериев, выставляя пороги, а не оценки «нравится, не нравится».
6. Проведите пилот на реальном профиле нагрузки: сначала на копии 5-10 % данных. S3-шлюз, NFS-export и CSI-драйвер удобно обкатать на облачном стенде, например на инфраструктуре Timeweb Cloud, прежде чем переносить схему в продакшен.
7. Зафиксируйте решение, документацию и план роста ёмкости на два-три года вперёд.

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

• Недооценка нагрузки. Расчёт по объёму без учёта IOPS приводит к тому, что файловый массив ставят под базы данных. Считайте IOPS и задержку заранее, проверяйте на fio с профилем 70/30 случайных операций.
• Неверный выбор RAID. RAIDZ1 на дисках 18-20 ТБ почти гарантирует потерю пула при втором отказе во время ребилда. Для таких накопителей берите RAIDZ2, а критичные данные размещайте на зеркалах.
• Отсутствие резервных копий. Снапшоты не заменяют бэкап. Схема 3-2-1: три копии, два разных носителя, одна копия за пределами площадки, плюс регулярная проверка восстановления.
• Нет мониторинга. SMART, состояние пула, заполнение выше 80 %, температура дисков и ошибки сети должны давать алерт в Zabbix или Prometheus. Без этого деградация обнаружится по жалобам пользователей.
• Сеть как узкое место. iSCSI через 1GbE упирается в 110-118 МБ/с. Для виртуальных машин и баз данных нужен 10GbE, 25GbE или NVMe-oF, иначе быстрые диски не дадут эффекта.
• SMR-диски в ZFS. На черепичной записи ресилвер падает до единиц мегабайт в секунду. Берите CMR-модели и проверяйте это свойство до покупки партии.
• Отсутствие документации. Схема пулов и vdev, карта сети, точки монтирования, порядок восстановления. Без этого через год никто не вспомнит, почему выбран конкретный размер блока.
• Экономия на тестах. Отключение диска в лаборатории стоит ноль, на продакшене стоит часов простоя. Проверьте поведение пула при потере накопителя и при обрыве сети.

Практические рекомендации по развёртыванию и снижению рисков

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

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

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

Оставляйте запас. 15-20 % свободного места в пуле ZFS нужны для нормальной работы COW-записи и снапшотов, иначе деградация происходит резко. Планируйте ёмкость с учётом роста данных на год вперёд.

Для коммерческой СХД используйте контракт поддержки, он входит в стоимость владения. Для бесплатных решений закладывайте время инженера на обновления: обновлять ZFS и ядро без чтения changelog опасно, а раз в квартал это занимает несколько часов.

Заключение: как принять взвешенное решение

Универсального ответа нет: TrueNAS выигрывает там, где нужны ZFS, снапшоты и все три протокола, OpenMediaVault закрывает лёгкий файловый сервер на Debian, Unraid удобен для смешанного массива из дисков разного размера, коммерческие СХД берут на себя гарантии и поддержку там, где простой стоит дороже железа.

Дальше работает алгоритм: сценарий, требования в числах, TCO на 3-5 лет, проверка интеграций, шорт-лист, пилот на реальной нагрузке. Ошибки чаще возникают не на этапе выбора, а на этапе запуска: слабая сеть под iSCSI, RAIDZ1 на больших дисках, отсутствие проверенных бэкапов и мониторинга.

Если выбор стоит между конкретными программными платформами под хранилище артефактов и инструментов, посмотрите сравнение TrueNAS, OpenMediaVault и Synology с расчётом TCO на 50 ТБ. В базе знаний admin-wiki собраны практические руководства по настройке TrueNAS, ZFS, OpenMediaVault и разбору типовых сбоев хранилищ, чтобы проверять конфигурацию по шагам, а не по маркетинговым описаниям.