Программные системы хранения (SDS) в 2026 году: сравнение TrueNAS, Ceph, ZFS, Unraid и Proxmox

Что такое SDS и зачем он нужен в 2026 году

Программно-определяемая система хранения (SDS) переносит логику работы с данными в софт: пулы, тома, снапшоты, репликацию, дедупликацию и восстановление после сбоев выполняет программный слой на стандартных x86-серверах. Диски и полки расширения перестают быть частью проприетарного массива с прошивкой вендора и превращаются в заменяемый расходный материал.

Ядро любой SDS состоит из трёх частей. Контрольный слой хранит конфигурацию: какие диски собраны в пулы, какие политики репликации и снапшотов действуют. Слой данных обслуживает ввод-вывод: раскладывает блоки по дискам, считает контрольные суммы, кэширует горячие данные. Интерфейсный слой отдаёт результат потребителям по SMB, NFS, iSCSI, NVMe-oF, S3 или через CSI-плагин для Kubernetes.

Прямой ответ для выбора: SDS берут, когда нужны низкая стоимость гигабайта, масштабирование наращиванием узлов и независимость от одного поставщика железа. Для дома это способ превратить старый ПК или мини-сервер в NAS с защитой от потери диска. Для компании это возможность собрать отказоустойчивый кластер на серийных серверах вместо массива за десятки тысяч долларов.

Три фактора сделали SDS массовыми к 2026 году. NVMe-накопители классов consumer и U.2/U.3 сравнялись по цене за гигабайт с SATA SSD, а сети 25 и 100 Гбит/с перестали быть экзотикой, поэтому узкое место сместилось с дисков на архитектуру. OpenZFS, Ceph и KVM дозрели до состояния, когда кластер собирается инсталлятором, а не ручной компиляцией. Kubernetes-кластеры получают тома из SDS через CSI так же просто, как из облака.

SDS vs аппаратные СХД: ключевые отличия

Разница проявляется на четырёх осях.

• Стоимость владения. Аппаратный массив - это контроллерная пара, полки расширения и лицензии на снапшоты, репликацию и тонкое выделение места. У вендоров эти функции часто продаются отдельными блоками, тогда как в SDS входят в базовый пакет. Серийные серверы и диски дают CAPEX на терабайт ниже в 2-4 раза при сопоставимой избыточности.
• Масштабирование. Массив наращивают полками, привязанными к контроллерам: упёрлись в их производительность, меняете весь массив. SDS масштабируется узлами, и пропускная способность растёт вместе с числом дисков и CPU.
• Зависимость от вендора. Из массива нельзя вытащить диски и собрать тот же пул на сервере другой марки. В SDS данные, схемы раскладки и снапшоты переносимы, а замена узла сводится к подключению диска и импорту пула.
• Поддержка и предсказуемость. Здесь выигрывают аппаратные решения: единый контракт SLA, заявленные значения задержки под конкретный профиль нагрузки, инженер на площадке и замена деталей по регламенту. В SDS за производительность и восстановление отвечает ваша команда.

Отдельно про отказоустойчивость. Аппаратный массив держит две контроллерные головы с общим кэшем и не теряет данные при отказе одной из них. В SDS того же результата добиваются репликацией на 3 копии или erasure coding с распределением ролей по узлам. Цена в обоих случаях - резервирование ёмкости от 1,5x и выше.

Дальше сравниваются пять решений: TrueNAS SCALE, Ceph, ZFS on Linux, Unraid и Proxmox VE. Каждое разобрано по трём критериям: требования к железу, гибкость конфигурации, сложность поддержки.

Критерии сравнения SDS-платформ

Три метрики отсекают большую часть вариантов ещё до тестового стенда.

Требования к оборудованию. Считайте CPU под контрольные процессы, RAM под кэш и метаданные, диски под данные и журналы, сеть под репликацию и клиентский трафик. Ключевое правило: RAM под кэш определяет скорость случайного чтения, а пропускная способность сети задаёт потолок производительности всего кластера. Ceph хочет 16 ГБ на узел минимум и 10 Гбит/с для production, ZFS - около 1 ГБ RAM на каждый терабайт пула, Unraid обходится 4-8 ГБ, если не держать десятки контейнеров.

Гибкость конфигурации. Смотрите на поддержку пулов разного уровня (mirror, RAID-Z, erasure coding), консистентные снапшоты для виртуальных машин, репликацию локальную и удалённую, набор протоколов доступа, интеграцию с Kubernetes и наличие API для автоматизации. Гибкость стоит денег: чем больше вариантов раскладки, тем выше шанс ошибиться при создании первого пула.

Сложность поддержки. Оценивайте порог входа, качество документации, размер сообщества, частоту релизов и наличие инструментов мониторинга. Отдельный пункт - процедура обновления: у ZFS и TrueNAS апгрейд пула необратим, Ceph обновляют по узлам в пределах одного релиза, Unraid меняет системные файлы без перестройки массива.

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

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

TrueNAS SCALE - дистрибутив на базе Debian с встроенным OpenZFS, веб-интерфейсом и поддержкой контейнеров и виртуальных машин. Это самый доступный вход в ZFS: пул данных создаётся в GUI, там же настраиваются снапшоты, задания репликации, права SMB и шары NFS.

Требования: 64-битный CPU x86-64, минимум 8 ГБ RAM (16 ГБ и больше для пулов от 50 ТБ и приложений), отдельный загрузочный диск на 16-32 ГБ или SATA DOM, HBA в режиме IT при работе с SAS-полками. Сеть 1 Гбит/с годится для медиатеки, 10 Гбит/с и выше нужны для iSCSI под виртуализацию и репликации. Ориентир по памяти: 1 ГБ RAM на 1 ТБ пула; ARC освобождает память приложениям, но на 8 ГБ RAM и пуле в 100 ТБ случайное чтение заметно просядет.

Гибкость: пулы ZFS (mirror, RAID-Z1/2/3, dRAID), снапшоты, ZFS send/recv, задания rsync, шифрование датасетов, протоколы SMB, NFS, iSCSI, S3 через приложения, Docker-контейнеры и KVM-ВМ, объединение двух узлов в отказоустойчивую пару на Enterprise-лицензии.

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

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

Пошаговая настройка SMB, NFS и FTP с управлением ACL и интеграцией с Windows, Linux, Proxmox и Docker описана в руководстве по сетевому доступу к файлам в TrueNAS Core и SCALE.

TrueNAS SCALE vs TrueNAS CORE: что выбрать

CORE построен на FreeBSD и запускает приложения в jails, а виртуальные машины через bhyve. SCALE работает на Linux с KVM и Docker, поэтому поддерживает более широкий список оборудования и драйверов, включая свежие сетевые карты и GPU-ускорение для транскодинга.

Для новых проектов в 2026 году разумный выбор - SCALE. CORE остаётся рабочим вариантом там, где уже есть FreeBSD-компетенции и перенос данных обойдётся дороже выгоды.

Ceph: распределённое хранилище для корпоративных задач

Ceph - распределённая SDS без единой точки отказа с тремя типами интерфейсов: блочные тома (RBD), файловая система (CephFS) и объектное хранилище с S3/Swift API (RADOS Gateway). Данные лежат в RADOS-кластере, раскладкой управляет алгоритм CRUSH: он решает, на каких дисках и в каких узлах держать копии или фрагменты erasure coding.

Компоненты: MON с кворумом из 3 или 5 узлов, MGR для метрик и дашборда, OSD по одному процессу на диск, MDS для CephFS. Репликация по умолчанию - 3 копии, схема erasure coding 4+2 даёт накладные 1,5x вместо 3x, но хуже переносит мелкие случайные операции и требует больше CPU.

Сеть 10 Гбит/с на узел считается нижней границей, для NVMe-кластеров смотрят на 25 или 100 Гбит/с, часто с отдельным линком под репликацию. Журнал OSD (WAL/DB) на NVMe ускоряет запись заметно сильнее, чем любой тюнинг HDD-группы.

Минимальные требования к кластеру Ceph

• 3 узла для кворума MON, каждый со своим диском под ОС и минимум одним OSD.
• 16 ГБ RAM на узел как минимум, 32 ГБ и выше для кластеров от 10 дисков на узел.
• Отдельный NVMe или SSD под журнал OSD и под метаданные.
• 10 Гбит/с на узел, желательно два линка в агрегации.
• Включённый pg autoscaler: ручной расчёт числа placement groups давно не нужен и служит источником ошибок.
• Тестовый стенд из 3 виртуальных машин на одной физической машине с 16 ГБ RAM подходит для изучения команд и логики CRUSH, но не для замеров производительности.

Сложность поддержки: высокая. Нужны мониторинг (Prometheus с модулем ceph-mgr, дашборд, алерты), понимание CRUSH и пулов, дисциплина при обновлениях и контроль заполнения дисков: при 75-80% занятости кластер начинает тормозить, а восстановление занимает часы. Для дома Ceph избыточен.

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

ZFS on Linux: гибкость и мощь на уровне файловой системы

OpenZFS в Linux совмещает файловую систему и менеджер томов. Она проверяет контрольные суммы каждого блока, объединяет диски в пулы, делает мгновенные снапшоты, шифрует датасеты алгоритмом AES-256-GCM, сжимает данные через lz4 и zstd, отправляет состояние пула на другой сервер командой zfs send и защищает от тихих ошибок диска, о которых SMART не сообщает.

Требования: 8 ГБ RAM как практический минимум, около 1 ГБ на терабайт пула под ARC, ECC-память желательна (снижает риск повреждения метаданных при сбое железа, но бэкап не заменяет), отдельный загрузочный диск не обязателен. HBA лучше держать в режиме IT: ZFS должен видеть диски напрямую, без аппаратного RAID-слоя.

Гибкость: максимальная, вместе с максимальной ответственностью. Собираются зеркала, RAID-Z2 из восьми дисков, SLOG под синхронную запись, L2ARC под чтение, отдельные датасеты под базы данных с recordsize 16K. Дедупликация требует огромной таблицы DDT в памяти: без 64 ГБ RAM и более её включать не стоит, даже с учётом fast dedup в OpenZFS 2.3.

ZFS пул настройка: базовые принципы

Пул строится из vdev, каждый vdev состоит из одного или нескольких дисков. Зеркало из двух дисков переживает отказ одного, RAID-Z1 одного, RAID-Z2 двух, RAID-Z3 трёх. Скорость пула определяется самым медленным vdev, а не суммарным числом дисков.

• Диски внутри vdev фиксируются навсегда: добавить один диск в существующее зеркало или RAID-Z нельзя без пересоздания. Новый vdev добавить в пул можно в любой момент, ёмкость распределится между всеми vdev.
• Раскладка: 2 диска на зеркало, 4-8 дисков на RAID-Z2. Широкие vdev замедляют ребилд и повышают риск второго отказа во время восстановления.
• ashift=12 для дисков с сектором 4K, recordsize 128K для файловых шар и 16K для образов виртуальных машин.
• Создание пула из двух зеркал: zpool create tank mirror sda sdb mirror sdc sdd. Проверка: zpool status, zpool list, zfs list.
• Снапшот: zfs snapshot tank/data@2026-09-11. Репликация на второй сервер: zfs send с передачей на приёмник по SSH через zfs receive.

Планируйте пул до первой записи. Смена схемы позже означает перенос данных на новый пул, а не переконфигурацию на месте.

Сложность поддержки: средняя для типовых задач и высокая при тюнинге. Документация OpenZFS подробная, но описывает механику, а не готовые сценарии, поэтому первый пул лучше собирать по проверенному чек-листу. Типичные сценарии: серверы с кастомной конфигурацией, хранилище для Proxmox, домашние NAS на Ubuntu или Debian. ZFS лежит в основе TrueNAS SCALE и служит стандартным локальным хранилищем Proxmox VE.

Unraid: простота для домашнего сервера

Unraid - коммерческая SDS с необычной моделью массива: диски не объединяются в страйп, каждый работает как самостоятельная файловая система XFS или Btrfs, а от отказа защищают один или два parity-диска. Схема позволяет смешивать HDD на 4, 8 и 18 ТБ в одном массиве и терять только данные отказавшего диска, а не весь пул.

Требования: 64-битный CPU, 4 ГБ RAM минимум (8-16 ГБ при десятках контейнеров), USB-флешка как загрузочный носитель, к которой привязана лицензия, SSD-кэш под запись и под виртуальные машины. Docker и KVM доступны из коробки, есть шаблоны приложений для медиасерверов, синхронизации и бэкапов.

Гибкость: высокая по железу и средняя по возможностям. Смешивание дисков, снапшоты Btrfs и ZFS в кэш-пуле, поддержка ZFS как основного типа массива в свежих версиях. Запись в parity-массив идёт с пересчётом чётности, поэтому кэш-накопитель или отдельный NVMe-пул под виртуальные машины практически обязательны.

Поддержка: низкая сложность. Интерфейс понятный, сообщество активное, обновления частые. Лицензии делятся на базовый, расширенный и пожизненный уровни, стоимость варьируется примерно от 50 до 250 долларов, есть пробный период около 30 дней. Корпоративных SLA и подписки с гарантированным временем реакции нет.

Сценарии: домашний медиасервер, шара для бэкапов, переиспользование дисков разного размера после апгрейдов, площадка под домашние Docker-сервисы.

Unraid или TrueNAS: что выбрать для дома

• Стоимость: TrueNAS SCALE бесплатен, Unraid требует лицензии.
• Диски: Unraid смешивает любые размеры, TrueNAS строит vdev из дисков одинакового объёма, иначе избыточная ёмкость расходуется впустую.
• Производительность: пул ZFS быстрее на случайных операциях и строже следит за целостностью данных, parity-массив Unraid ограничен скоростью одного диска при записи.
• Порог входа: Unraid проще для новичка, TrueNAS требует понимания ZFS, vdev и ARC.
• Итог: при разнородных дисках и желании минимум настроек выбирают Unraid, при готовности читать документацию и требовании бесплатного решения - TrueNAS SCALE.

Proxmox VE: хранилище как часть виртуализации

Proxmox VE - платформа виртуализации на Debian с KVM и LXC, где хранилище встроено в модель управления: один узел держит локальные ZFS-пулы и LVM-thin, а кластер из трёх и более узлов собирает общий Ceph с гиперконвергентной схемой, когда вычислительные узлы одновременно отдают свои диски под данные виртуальных машин.

Требования зависят от выбранного бэкенда: ZFS - 8 ГБ RAM на узел и желательно ECC, Ceph - 16 ГБ RAM и 10 Гбит/с на узел, NFS и iSCSI требовательны к сети, а не к локальным ресурсам. Кластер Ceph внутри Proxmox настраивается через веб-интерфейс, состояние видно в дашборде.

Гибкость: локальные ZFS и LVM-thin, общие Ceph-пулы, внешние NFS, iSCSI, CIFS и GlusterFS, снапшоты на уровне ZFS и Ceph, live-миграция ВМ при общих хранилищах, инкрементальный бэкап через Proxmox Backup Server с дедупликацией.

Поддержка: средняя. Документация подробная, релизы регулярные, подписка открывает enterprise-репозиторий и тикетную поддержку, лицензия считается по числу сокетов. Основные ошибки связаны с форматом тома и параметрами ZFS, а не с самой платформой.

Сценарии: домашний или офисный гипервизор на ZFS, гиперконвергентный кластер из трёх серверов, отказоустойчивая площадка под критичные сервисы. Метрики IOPS, задержки и требования к хранилищу под виртуальные машины разобраны в статье о выборе СХД для виртуализации под VMware и Proxmox.

Proxmox ZFS хранилище: настройка и особенности

При установке Proxmox можно выбрать ZFS с RAID-Z как корневую файловую систему: тогда система, образы ВМ и данные окажутся на одном пуле. Практичнее разделять пулы: отдельный под виртуальные машины, отдельный под бэкапы и архивы. Новое хранилище добавляют в разделе Datacenter, пункт Storage, кнопка Add, тип ZFS, с указанием пула и списка типов содержимого (Disk image, Container, Backups).

• Виртуальные машины размещают на zvol с блоком 16K и включённым thin provisioning, контейнеры - на датасете.
• Синхронную запись ускоряет SLOG на NVMe с высоким показателем DWPD, иначе каждая запись ждёт подтверждения от диска и задержка растёт.
• Снапшоты ZFS дают мгновенные точки отката, но не заменяют бэкап: копия на том же пуле не спасёт от отказа узла.
• На 8 ГБ RAM и пуле из 8 дисков ребилд после отказа может идти десятки часов и заметно снижать отзывчивость ВМ.

Сравнительная таблица SDS-решений 2026

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

Домашний сервер: что выбрать

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

• Unraid - новичкам и тем, у кого лежат диски разного размера. Простой интерфейс, гибкий массив, готовые шаблоны Docker.
• TrueNAS SCALE - бесплатный вариант с лучшей целостностью данных и высокой скоростью чтения из ARC. Требует больше RAM и дисциплины при сборке vdev.
• Proxmox VE с ZFS - если на том же железе нужны виртуальные машины, контейнеры и файловая шара одновременно.
• ZFS on Linux без NAS-оболочки - тем, кто хочет полный контроль и уже администрирует Linux.
• Ceph дома не оправдан: три узла ради файлохранилища дают лишний шум, трёхкратный расход ёмкости и требования к 10 Гбит/с.

Пример бюджетной конфигурации: мини-ПК на процессоре класса N100 с 16 ГБ RAM, два HDD по 8 ТБ в зеркале ZFS или массив с одним parity-диском в Unraid, сеть 2,5 Гбит/с. Потребление такой системы держится в диапазоне 15-30 Вт. Продвинутый вариант: серверный CPU, 32-64 ГБ ECC, HBA в режиме IT, 6-8 HDD и два NVMe под SLOG и L2ARC, сеть 10 Гбит/с. Круглосуточная работа сервера на 100 Вт даёт около 876 кВт*ч в год, и это стоит учитывать при выборе между старым железом и энергоэффективной платформой.

Если сравниваете варианты для небольшого офиса, пригодятся требования к RAM и ECC, лицензиям и TCO из разбора TrueNAS, OpenMediaVault и Unraid для малого и среднего бизнеса.

Корпоративная инфраструктура: критерии выбора

В компании решение выбирают по требованиям к доступности и предсказуемости, а не по удобству интерфейса.

• Крупные кластеры на сотни терабайт с единым пулом: Ceph. Он даёт отказоустойчивость на уровне узлов, объектный и блочный доступ, масштабирование до тысяч OSD.
• Гиперконвергентные среды: Proxmox VE с Ceph на 3-5 узлах, сеть 10-25 Гбит/с, отдельная сеть под репликацию Ceph.
• Филиалы и небольшие офисы: TrueNAS SCALE, часто два узла с репликацией и Enterprise-подпиской для доступа к SLA.
• Unraid в корпоративный контур не ставят: лицензия привязана к USB-носителю, нет ролевой модели уровня предприятия, обновления зависят от небольшой команды разработки.

Критерии, которые стоит зафиксировать до выбора: RPO и RTO, требуемые IOPS и задержка на профиле рабочей нагрузки, число площадок, требования регуляторов к шифрованию и аудиту, регламент обновлений, стоимость гигабайта на горизонте 3-5 лет. Поддержка с реакцией за 4 часа предполагает контракт: TrueNAS Enterprise, подписка Proxmox, коммерческие сборки Ceph от крупных поставщиков.

Пример расчёта: кластер на 500 ТБ полезной ёмкости с трёхкратной репликацией требует около 1,5 ПБ сырых дисков. Три узла по 12 дисков на 16-20 ТБ дают примерно 640 ТБ сырой ёмкости на узел, то есть 1,9 ПБ суммарно, чего хватает с запасом на ребилд и рост. Схема erasure coding 4+2 снижает накладные расходы до 1,5x, но требует больше CPU и хуже работает на мелких случайных операциях.

Когда SDS выгоднее аппаратного хранилища

Экономика решается на горизонте 3-5 лет и учитывает не только железо.

CAPEX. Серийный сервер 2U с 12 дисками по 16 ТБ даёт 192 ТБ сырой ёмкости, а при трёхкратной репликации - 64 ТБ полезной. Стоимость такого сервера сопоставима с ценой одной полки расширения у вендора массива, при этом лицензии на снапшоты и репликацию не нужны.

TCO. В расчёт входят железо, лицензии, контракт поддержки, электроэнергия, охлаждение, ФОТ команды и стоимость простоя. У SDS выше доля ФОТ и ниже доля лицензий, у аппаратных массивов наоборот. Порог выгоды обычно лежит там, где в компании уже есть инженеры с опытом Linux и ZFS или Ceph.

Vendor lock-in. Из массива нельзя переставить диски в сервер другой марки, лицензии не переносятся, замена контроллера идёт через вендора с его сроками поставки. В SDS замена узла сводится к переносу дисков и импорту пула.

Гибкость. SDS позволяет держать NVMe под горячие данные и HDD под архив в одном пространстве имён, менять раскладку пулов и добавлять узлы под задачу, а не под прайс-лист.

Где аппаратное хранилище остаётся сильнее: гарантированная задержка в десятки микросекунд на all-flash платформах, двойной контроллер с синхронным кэшем, сертификация под конкретные приложения, поддержка устаревших платформ, отсутствие собственной экспертизы в команде.

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

Практические шаги для старта с SDS

1. Соберите требования: полезная ёмкость с ростом на 3 года, профиль нагрузки (последовательная или случайная, размер блока), целевые IOPS и задержка, RPO и RTO, протоколы доступа, бюджет.
2. Выберите решение по таблице и проверьте его ограничения: минимальное число узлов, объём RAM, тип сетевых карт, поддержка нужных протоколов.
3. Проверьте железо: HBA в режиме IT, актуальность прошивок дисков и контроллера, исправность кабелей и полок, отдельный загрузочный диск, наличие ECC.
4. Соберите тестовый стенд: три виртуальные машины для Ceph, чистый диск под ZFS-пул, USB-флешку для Unraid. Если физического железа нет, арендуйте несколько облачных серверов, например в Timeweb Cloud, и прогоните нагрузку там, вместо того чтобы верить теоретическим цифрам.
5. Смоделируйте отказ: выдерните диск из пула или выключите узел, замерьте время восстановления и просадку производительности для работающих сервисов.
6. Настройте мониторинг: состояние пулов и OSD, атрибуты SMART, задержки чтения и записи, свободное место, алерты при заполнении 80%.
7. Опишите бэкап по правилу 3-2-1: три копии данных, два разных носителя, одна копия вне площадки. Снапшоты на том же пуле не считаются резервной копией.
8. Зафиксируйте регламент обновлений: апгрейд пула ZFS необратим, кластер Ceph обновляют по одному узлу без перехода между релизами, TrueNAS обновляют после чтения заметок о выпуске и сохранения конфигурации.

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