Классификация систем хранения данных: DAS, NAS, SAN, объектные и облачные решения, сравнение и выбор в 2026 году

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

Практический критерий выбора один: профиль нагрузки. Транзакционная база с 50 000 случайных операций записи по 4 КБ в секунду требует блочного доступа и локальных NVMe. Архив на 500 ТБ, который читают несколько раз в год, дешевле и надёжнее держать в объектном хранилище. Общий сетевой диск для отдела из 20 человек закрывает NAS.

Ниже разобраны пять классов: DAS, NAS, SAN, объектные и облачные решения, с протоколами, цифрами по задержкам и сценариями, где каждый класс выигрывает или проигрывает.

Зачем нужна классификация СХД и как она помогает выбрать хранилище

Класс хранилища задаёт потолок производительности и пол затрат. Ошибка на этом уровне обходится дороже всего: переезд с NAS на SAN через год стоит денег и простоя.

Конкретный пример. Базу PostgreSQL разместили на NFS-шаре. При 4 КБ случайной записи и 2000 IOPS отклик вырос с 0,5 мс до 12-18 мс: файловый протокол добавляет уровень абстракции, сериализует часть операций и согласует кэши. Железо при этом загружено на треть. Правильный класс для такой нагрузки - блочный том по iSCSI или локальные NVMe.

Классификация нужна для быстрого отсечения неподходящих вариантов. Определили профиль (случайная запись, 20 000 IOPS, отклик до 1 мс) - остаётся два-три класса из пяти.

В 2026 году границы между классами размываются. Унифицированные системы (NetApp ONTAP, Dell PowerStore) отдают файловые и блочные тома из одного массива. Программные платформы (Ceph, MinIO, VMware vSAN) публикуют блочный, файловый и объектный интерфейсы поверх общего набора дисков. Базовые различия сохраняются: семантика доступа, модель консистентности и предел масштабирования у каждого интерфейса свои. Расчёты IOPS, уровни RAID и схемы резервирования собраны в материале про разбор классификации СХД с расчётом IOPS.

Три способа доступа к данным: блочный, файловый, объектный

Блочный доступ. Устройство отдаёт набор блоков фиксированного размера, обычно 512 байт или 4 КБ, и адресует их по номеру LBA. Файловую систему создаёт клиент: ext4, XFS, NTFS, VMFS. Протоколы: iSCSI поверх Ethernet 1/10/25/100 Гбит/с, Fibre Channel 8/16/32/64 Гбит/с, NVMe-oF через RDMA или TCP. Типовой пример: LUN на 2 ТБ для кластера Oracle или datastore VMFS для сотни виртуальных машин.

Файловый доступ. Хранилище публикует иерархию каталогов и файлов с правами, блокировками и метаданными. Клиент видит привычную файловую систему и не знает, где лежат блоки физически. Протоколы: NFSv3, NFSv4.1, NFSv4.2, SMB 2.1 и 3.1.1. Типовой пример: сетевой диск отдела и домашние каталоги сотрудников.

Объектный доступ. Данные хранятся как объекты: содержимое плюс метаданные плюс ключ в плоском пространстве имён (bucket). Доступ идёт по HTTP REST API, стандарт де-факто - S3 API. Объект перезаписывается целиком, блокировок файлов нет. Типовой пример: бэкапы, артефакты сборки, медиатека, датасеты для обучения моделей.

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

Модели развёртывания: on-premise, облако, гибрид

On-premise. Затраты идут по CAPEX: диски, контроллеры, полки, лицензии, сети. Отклик предсказуем и не зависит от внешнего канала: локальные NVMe дают 0,05-0,1 мс, массивы среднего класса 0,3-1 мс. Обслуживание на вас: замена дисков, обновления прошивок, контроль свободного места, питание и охлаждение.

Облако. Затраты уходят в OPEX и растут вместе с объёмом и трафиком. Эластичность настоящая: том на 1 ТБ создаётся за минуту, лишний отключается в конце месяца. Обратная сторона - лимиты и платежи за исходящий трафик. У AWS EBS gp3 базовая производительность 3000 IOPS и 125 МБ/с, докупить можно до 16 000 IOPS и 1000 МБ/с, объём тома до 16 ТиБ. Исходящий трафик в интернет тарифицируется отдельно и при больших объёмах превышает стоимость самого хранения.

Гибрид. Горячие данные и метаданные остаются локально, холодные и архивные уходят в облако. Рабочая схема для Kubernetes: персистентные тома на локальном Ceph RBD, резервные копии кластера через Velero в S3-совместимое хранилище. Гибрид требует двух компетенций и политики жизненного цикла данных, иначе счета за облако растут без контроля.

TCO считайте на 3-5 лет. Для облака в расчёт входят объём, IOPS, операции (у S3 типично 0,005 доллара за 1000 запросов PUT), исходящий трафик и копии. Для локального варианта - амортизация железа, поддержка, электропитание, зарплата инженера и стоимость простоя.

DAS: прямое подключение, когда скорость и простота важнее гибкости

DAS (Direct Attached Storage) - накопители, подключённые к серверу напрямую, без сети. Интерфейсы: SATA до 6 Гбит/с, SAS 12 и 24 Гбит/с, NVMe через PCIe 4.0 (около 7 ГБ/с на устройство) и PCIe 5.0 (около 14 ГБ/с). Внешние полки JBOD подключаются через HBA, расширители SAS позволяют собрать десятки дисков на одном хосте.

Задержки: NVMe 0,05-0,1 мс, SAS SSD 0,2-0,5 мс, SAS HDD 5-10 мс. Ни один сетевой класс не даёт таких значений при сопоставимой цене.

Сценарии: транзакционные базы данных, кэш и временные (scratch) данные, брокеры сообщений, шардированные СУБД, локальные тома Kubernetes через local-path provisioner, диски OSD для Ceph. В гиперконвергентных и SDS-схемах DAS становится строительным блоком: серверы с дисками объединяются в кластер, копии данных распределяются по узлам.

Ограничения: нет общего доступа по сети, масштабирование упирается в корпус сервера и полки, отказ сервера делает данные недоступными другим узлам. Резервирование закрывается RAID и отдельным бэкапом, RAID не отменяет копий. Для кластера без кластерного ПО (Ceph, vSAN, StarWind) набор DAS не даст общей точки монтирования. Схемы подключения SAS и SATA, настройка полок и сравнение с NAS разобраны в руководстве по DAS и настройке SAS/SATA.

NAS: файловое хранилище для совместной работы

NAS (Network Attached Storage) отдаёт данные по файловым протоколам: NFS для Linux и гипервизоров, SMB/CIFS для Windows и macOS. Реализации: TrueNAS на ZFS, Synology DSM, QNAP QTS, NetApp ONTAP, Dell PowerScale.

Сценарии: общие файлы, домашние каталоги, бэкапы, медиахранилище, NFS-datastore для VMware, профили VDI, репозитории резервных копий Veeam. Для отдела до 50 человек NAS за 150-300 тысяч рублей закрывает задачу полностью.

Плюсы: простая настройка, централизация данных, снапшоты и квоты, интеграция с AD и LDAP, ACL, дедупликация на уровне массива. ZFS добавляет контрольные суммы блоков, copy-on-write, снапшоты без остановки сервиса и уровни RAIDZ1/RAIDZ2/RAIDZ3.

Минусы: накладные расходы протокола. На одном и том же железе NFS на 4 КБ случайной записи проигрывает iSCSI в разы, SMB согласует блокировки и чувствителен к задержке сети. Массив мелких файлов по 20-40 КБ снижает эффективность ещё сильнее. Для СУБД с плотной записью NAS не подходит.

В Kubernetes нативного CSI для NFS нет: ставят сторонние драйверы (nfs-subdir-external-provisioner) или S3-шлюзы. Для томов баз данных надёжнее блочный CSI. Матрица выбора по нагрузкам с RPO и RTO есть в сравнении DAS, NAS, SAN и HCI под виртуализацию.

SAN: блочное хранилище для критичных нагрузок

SAN (Storage Area Network) - выделенная сеть для блочного доступа, отделённая от пользовательского трафика. Транспорты: Fibre Channel 8/16/32/64 Гбит/с, iSCSI поверх 10/25/100 GbE, NVMe-oF (RoCEv2, TCP), реже FCoE. Управляющие механизмы: zoning по WWN на коммутаторах, LUN masking, multipath (MPIO) для отказоустойчивости путей, ALUA для балансировки.

Реализации: Dell PowerStore, NetApp AFF, HPE Alletra, Hitachi VSP, Huawei OceanStor. Из доступных альтернатив - iSCSI на TrueNAS и Ceph RBD, которые закрывают часть задач за меньшие деньги.

Сценарии: кластеры виртуализации (VMFS, Hyper-V CSV), Oracle RAC, MS SQL Always On, SAP HANA, VDI. Возможности: отклик 0,1-1 мс, двойные контроллеры, синхронная репликация между площадками, снапшоты, thin provisioning, автоматическое распределение данных по уровням.

Цена: FC-коммутаторы, HBA, лицензии на ПО управления, обучение персонала. Массив начального уровня с двумя контроллерами и полкой обходится в несколько миллионов рублей, а квалифицированный инженер нужен постоянно.

Для компании с 20-40 виртуальными машинами классический SAN избыточен: тот же результат даёт пара серверов с NVMe и iSCSI-таргетом или трёхузловой Ceph. NVMe-oF в 2026 году переходит в продакшен и снимает часть задержек, которые раньше были аргументом в пользу DAS.

Объектные СХД: масштабируемость и S3-совместимость

Объектное хранилище держит данные как объекты в плоском пространстве имён. Основные понятия: bucket, ключ объекта, метаданные, версионирование, политики жизненного цикла, erasure coding для защиты от потери дисков и узлов. Доступ идёт по S3 API, поэтому одно приложение работает и с локальным MinIO, и с облачным хранилищем без правок кода.

Реализации: MinIO, Ceph RADOS Gateway, OpenStack Swift, облачные AWS S3, Azure Blob, Yandex Object Storage, Selectel, Cloudflare R2.

Сценарии: резервные копии (включая Velero для Kubernetes), архивы, медиафайлы, артефакты CI/CD, статические сайты, дата-лейки, данные для аналитики и обучения моделей.

Плюсы: горизонтальное масштабирование до петабайт без простоя, устойчивость за счёт erasure coding и репликации, нижняя стоимость гигабайта (дешёвые HDD вместо SSD, нет требований к задержке), доступ по HTTP(S) без VPN.

Ограничения: задержка на порядок выше блочной, 10-100 мс и больше; объект перезаписывается целиком, частичное обновление невозможно; нет блокировок файлов и POSIX-семантики; транзакционные базы данных на объектном хранилище не работают. В S3 консистентность read-after-write для новых объектов и list-операций обеспечена с 2020 года, у совместимых реализаций поведение стоит проверять на своей версии.

В Kubernetes объектное хранилище закрывает бэкапы и артефакты, а роль томов для баз данных берут блочные CSI-драйверы. Попытка подключить S3 как основной том через FUSE упирается в производительность на мелких операциях. Развёртывание и тюнинг кластера описаны в настройке отказоустойчивого кластера Ceph, vSAN и StarWind.

Облачные решения: эластичность против контроля и стоимости

Облачные СХД делятся по тому же признаку: блочные (AWS EBS, Google Persistent Disk, Yandex Network Block Storage), файловые (AWS EFS, Google Filestore, Azure Files), объектные (AWS S3, Azure Blob, Yandex Object Storage, Selectel).

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

Минусы: OPEX растёт вместе с данными, исходящий трафик тарифицируется отдельно, производительность ограничена лимитами сервиса (у gp3 база 3000 IOPS и 125 МБ/с), есть риск привязки к провайдеру: API, форматы снапшотов и сетевые схемы у всех свои. Перенос между облаками требует отдельного проекта.

Сценарии: стартапы без своего железа, сезонные пики, dev и test-контуры, площадки аварийного восстановления, сервисы с пользователями в разных регионах.

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

Сравнительная таблица классов СХД: критерии выбора

Как читать таблицу. Столбец задержки показывает порядок величин для типовой конфигурации, а не гарантию: NVMe в DAS обгоняет любой сетевой вариант, а объектное хранилище на HDD с erasure coding редко опускается ниже 10 мс. Стоимость за терабайт считайте вместе с расходами на IOPS: дешёвый HDD-массив под 10 000 IOPS случайной записи потребует сотен шпинделей. Масштабирование бывает вертикальное (мощнее контроллер, больше дисков в полке) и горизонтальное (добавление узлов); объектные и SDS-системы масштабируются горизонтально, классические SAN в основном вертикально.

Как выбрать СХД под задачу: пошаговый алгоритм

1. Определите профиль нагрузки. Соберите IOPS, долю случайных операций, размер блока, требуемую задержку, объём сегодня и прогноз на три года. Для PostgreSQL на 100 ГБ с 3000 IOPS и откликом до 2 мс нужен блочный доступ на SSD.
2. Выберите способ доступа. База данных и гипервизор - блочный. Общие файлы и репозиторий бэкапов - файловый. Архивы, медиа, артефакты - объектный.
3. Определите модель развёртывания. Свой ЦОД, облако или гибрид. Учтите требования к юрисдикции данных и допустимый простой.
4. Соберите 2-3 кандидата. TrueNAS на ZFS для файловых задач, Ceph или MinIO для объектных, Dell PowerStore или NetApp AFF для SAN, облачные сервисы под переменную нагрузку. Обзор платформ есть в статье про программные системы хранения.
5. Проверьте совместимость. Сверьтесь с HCL вендора для гипервизора, СУБД и версии ядра, проверьте поддержку нужного протокола в вашей версии ПО: NFSv4.2, SMB 3.1.1, iSCSI с CHAP, уровень S3 API.
6. Рассчитайте TCO на 3-5 лет. Железо или подписка, лицензии, поддержка, электропитание, обучение, трафик, резервные копии.
7. Проведите пилот и бенчмарки. Прогоните fio на своём профиле (4 КБ random write, смесь 70/30), замерьте задержку на 95-м процентиле и время восстановления из бэкапа.
8. Спланируйте миграцию. Репликация между старым и новым хранилищем, снапшоты перед переключением, тестовый прогон в отдельном окне и план отката.

Пример связки для Kubernetes: блочные тома на Ceph RBD для баз данных и stateful-сервисов, объектное хранилище MinIO для бэкапов Velero и артефактов сборки. Оба компонента работают на одном наборе дисков DAS, что снижает стоимость железа.

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

• Недооценка IOPS и задержки. NAS под СУБД с плотной записью деградирует уже при 2000 IOPS. Перед покупкой снимите профиль нагрузки и сравните его с паспортными значениями массива на нужном размере блока.
• Игнорирование роста данных. Прирост 20% в год превращает 100 ТБ в 249 ТБ за пять лет. Планируйте расширение на 12-18 месяцев вперёд и проверяйте, что шасси и блок питания допускают добавление дисков.
• RAID вместо резервного копирования. RAID защищает от отказа диска и не спасает от удаления файлов, шифровальщика, ошибки оператора и пожара. Стройте схему 3-2-1: три копии, два носителя, одна копия вне площадки.
• RAID 5 на больших дисках. Восстановление массива из восьми дисков по 18 ТБ читает 126 ТБ и идёт сутками, вероятность второй ошибки за это время растёт. Для таких объёмов берите RAID 6, RAIDZ2 или зеркала.
• Переплата за избыточность. SAN с FC-фабрикой под 20 виртуальных машин расходует бюджет, который лучше вложить в NVMe и резервные копии. Считайте потребность по фактическим метрикам, а не по принципу «на вырост».
• Неучтённые платежи за трафик и операции. В облаке копия на 50 ТБ, выгружаемая раз в месяц, добавляет заметную строку в счёт. Считайте egress и число запросов до подписания договора.
• Отсутствие проверки совместимости версий. Несовпадение прошивки массива, драйвера HBA и версии ядра даёт отказ на ровном месте. Сверьте матрицу совместимости до пилота и зафиксируйте версии ПО и прошивок в документе проекта.

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

1. Профиль нагрузки зафиксирован: IOPS, размер блока, доля случайных операций, задержка, объём и прогноз роста.
2. Способ доступа выбран и обоснован: блочный, файловый или объектный.
3. Совместимость проверена: гипервизоры, СУБД, версии Kubernetes, поддерживаемые протоколы и прошивки из HCL вендора.
4. TCO посчитан на 3-5 лет, включая поддержку, обучение, питание, трафик и простой.
5. Пилот проведён с бенчмарками на реальном профиле и замером 95-го процентиля задержки.
6. Резервное копирование и репликация настроены, восстановление хотя бы раз протестировано на копии.
7. План миграции готов: репликация данных, снапшоты, окно переключения, порядок отката.
8. Требования безопасности и compliance учтены: шифрование в покое и на канале, разграничение доступа, журналирование операций.
9. Поддержка вендора и наличие запчастей проверены, сроки поставки дисков и контроллеров известны.
10. Метрики мониторинга определены: задержка, IOPS, заполнение, ошибки чтения и записи, состояние дисков, срок службы SSD.

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