Архитектуры хранилищ данных: DAS, NAS, SAN и HCI — как выбрать под свои задачи

Ключевые отличия архитектур СХД: от прямого подключения до гиперконвергенции

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

DAS: когда данные живут внутри сервера

Direct-Attached Storage - это хранилище, подключенное к серверу напрямую, без сетевого взаимодействия. Самый простой пример: внутренние диски сервера, подключенные через SATA или NVMe. На практике DAS часто выходит за пределы корпуса: внешние JBOD-полки и дисковые массивы, подключенные через SAS-кабель, тоже относятся к этой архитектуре. Контроллер сервера управляет дисками монопольно, операционная система видит их как локальные блочные устройства.

Главное преимущество DAS - минимальная задержка. Данные проходят путь от приложения до диска без сетевого стека, без коммутаторов и без конкуренции за полосу пропускания с другими потребителями. Для NVMe-дисков задержка измеряется микросекундами. Это делает DAS незаменимым для задач, чувствительных к latency: высоконагруженных СУБД, систем реального времени, временных рабочих массивов для обработки видео.

Ограничения DAS проявляются при попытке масштабирования. Емкость растет только добавлением дисков в существующую полку или подключением дополнительных JBOD - это вертикальное масштабирование. Потолок упирается в количество SAS-портов на контроллере. Совместный доступ к данным с других серверов возможен только через программные средства самого сервера, что создает единую точку отказа. Подробно тема прямого подключения разобрана в руководстве по DAS, где сравниваются SAS и SATA для различных рабочих нагрузок.

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

Network-Attached Storage - это устройство, предоставляющее файловый доступ по сети. NAS подключается к Ethernet-инфраструктуре и отдает данные по протоколам SMB (CIFS), NFS, AFP. Клиенты видят не блочные устройства, а готовую файловую систему с правами доступа, папками и файлами. В этом ключевое отличие от обычного файлового сервера: NAS - это специализированное устройство с заточенной под хранение операционной системой, часто на базе Linux или BSD.

Рынок NAS делится на две категории. Готовые аппаратные решения - Synology, QNAP, Asustor - поставляются с проприетарной ОС, просты в настройке и подходят для офисов без выделенного IT-специалиста. Программные NAS - TrueNAS Core/Scale, OMV, XigmaNAS - собираются на стандартном x86-железе и дают полный контроль над конфигурацией. Выбор между ними зависит от требуемой гибкости и бюджета. Для домашнего сервера или малого офиса часто выбирают самосборный NAS на TrueNAS с ZFS, что дает надежность корпоративного уровня при умеренных затратах.

Сильная сторона NAS - простота организации совместной работы. Поддержка множества протоколов из коробки, встроенные средства резервного копирования, интеграция с Active Directory. Слабая сторона - производительность на высоких нагрузках. Файловый доступ добавляет накладные расходы, а общая полоса пропускания делится между всеми клиентами. Для офиса на 100-200 пользователей NAS на 10GbE справляется без проблем. Для кластера виртуализации с сотнями виртуальных машин - уже нет.

SAN: выделенная сеть для блочного доступа

Storage Area Network - это выделенная высокоскоростная сеть, соединяющая серверы с дисковыми массивами на блочном уровне. Сервер видит LUN (логический том) как локальный диск и форматирует его в собственную файловую систему. Никакого файлового шаринга на уровне хранилища не происходит - только блочный ввод-вывод. Это принципиально важно для приложений, которым нужен монопольный доступ к данным: СУБД, почтовые серверы, гипервизоры.

Архитектура SAN состоит из трех компонентов: инициаторов (серверные HBA-адаптеры), целей (дисковые массивы) и фабрики (коммутаторы и кабели). Два основных протокола - Fibre Channel (FC) и iSCSI. FC работает на скоростях 16, 32 и 64 Гбит/с, требует специализированных коммутаторов и кабелей, дает задержку в десятки микросекунд. Это выбор для критичных бизнес-приложений, где простой стоит дороже оборудования. iSCSI инкапсулирует SCSI-команды в TCP/IP, работает поверх стандартного Ethernet и дешевле в развертывании. Платой за доступность становится чуть более высокая задержка и зависимость от качества Ethernet-инфраструктуры.

Сильные стороны SAN: высокая производительность, отказоустойчивость на всех уровнях (multipathing, резервные контроллеры, дублированная фабрика), возможность строить катастрофоустойчивые решения с синхронной репликацией между площадками. Слабые: стоимость и сложность. Лицензии на FC-порты, обучение персонала, проектирование фабрики - все это требует серьезных вложений. Для миграции между SAN-массивами с минимальным простоем полезно изучить сравнение архитектур HPE 3PAR и Nimble Storage, где разобраны практические сценарии миграции.

HCI: когда хранилище и вычисления - единое целое

Гиперконвергентная инфраструктура объединяет вычислительные ресурсы и хранилище в одном кластере из стандартных x86-узлов. Каждый узел содержит процессор, память и локальные диски. Специализированное ПО - VMware vSAN, Nutanix AOS, StarWind VSAN - объединяет локальные диски всех узлов в распределенное хранилище. Виртуальные машины работают на том же узле, где физически находятся их данные, или мигрируют между узлами с сохранением доступа.

Ключевой механизм HCI - распределенная файловая система с политиками хранения. Администратор задает правила: «для этой группы ВМ держать две копии данных на разных узлах, для этой - три копии с распределением по разным стойкам». Система автоматически соблюдает эти политики, ребалансирует данные при добавлении или отказе узлов, применяет дедупликацию и компрессию на лету. Управление идет из единой консоли, без разделения на администраторов серверов и администраторов СХД.

Простота масштабирования - главный козырь HCI. Нужно больше ресурсов - добавляете узел в кластер, и система автоматически перераспределяет нагрузку. Это горизонтальное масштабирование, предсказуемое по производительности и емкости. Обратная сторона: высокие требования к сети между узлами (минимум 10GbE, лучше 25GbE), возможная деградация производительности при отказе узла (пока данные ресинхронизируются), зависимость стоимости от лицензионной политики вендора. Лицензии vSAN, например, лицензируются на ядро процессора, что при большом количестве ядер может составить значительную часть бюджета.

Сравнение производительности: IOPS, задержка и пропускная способность

Производительность СХД измеряется тремя метриками. IOPS - количество операций ввода-вывода в секунду, критично для случайного доступа (базы данных, VDI). Задержка - время выполнения одной операции, критично для синхронных нагрузок (транзакционные системы). Пропускная способность - объем данных в секунду, критично для последовательного доступа (видеонаблюдение, бэкапы, big data). Архитектура напрямую влияет на все три показателя.

Влияние сетевого стека на задержку

Каждый дополнительный уровень между приложением и физическим диском добавляет задержку. DAS с локальным NVMe-диском дает 10-100 микросекунд - это baseline, быстрее не бывает. SAN на Fibre Channel добавляет 50-150 микросекунд за счет прохождения через HBA, коммутатор и контроллер массива. iSCSI поверх 10GbE дает 200-500 микросекунд из-за накладных расходов TCP/IP. NAS по NFS или SMB - 500-1000 микросекунд и выше, потому что добавляется уровень файловой системы хранилища. HCI стоит особняком: если данные лежат на локальном диске узла, задержка близка к DAS; если данные находятся на другом узле, добавляется сетевая задержка (минимум 50-100 микросекунд при 25GbE).

Для большинства бизнес-приложений разница в 100-300 микросекунд незаметна. Пользователь файлового шара не почувствует, что данные пришли через NAS, а не с локального диска. Для высоконагруженной СУБД с тысячами транзакций в секунду каждая микросекунда на счету - здесь выбор между DAS и SAN FC становится принципиальным.

Масштабирование производительности: вертикальное vs горизонтальное

DAS масштабируется только заменой компонентов: более быстрые диски, более мощный RAID-контроллер, больше кэша. Это вертикальный подход, его потолок - возможности одного сервера. NAS позволяет добавлять дисковые полки к головному контроллеру (вертикально) или объединять несколько NAS-устройств в кластер (горизонтально), но кластеризация NAS часто ограничена по производительности. SAN наращивает производительность добавлением дисковых массивов в фабрику и распределением LUN между ними - это вертикально-горизонтальный гибрид. HCI масштабируется чисто горизонтально: каждый новый узел добавляет и вычислительные ресурсы, и диски, и пропускную способность. Балансировка нагрузки в HCI автоматическая: при добавлении узла система перемещает часть данных на новые диски, выравнивая загрузку.

Практический вывод: если нагрузка предсказуема и растет медленно, вертикальное масштабирование дешевле. Если нагрузка непредсказуема или растет быстро, горизонтальное масштабирование HCI дает гибкость без перепроектирования инфраструктуры. Тема масштабирования детально раскрыта в отдельном руководстве по Scale-Up и Scale-Out.

Экономика СХД: CAPEX и OPEX для разных масштабов бизнеса

Стоимость системы хранения - это не ценник на оборудование. Полная стоимость владения (TCO) складывается из капитальных расходов (CAPEX) и операционных (OPEX). CAPEX включает серверы, диски, коммутаторы, лицензии. OPEX - электроэнергия, охлаждение, администрирование, поддержка, аренда стоек. Соотношение CAPEX/OPEX сильно различается по архитектурам.

Для малого офиса на 50 пользователей NAS начального уровня (Synology DS923+ с четырьмя HDD) обойдется в 100-150 тысяч рублей CAPEX при минимальном OPEX: потребление 30-50 Вт, администрирование - пара часов в месяц. DAS в этом сценарии дешевле по железу, но не дает совместного доступа без дополнительного сервера. SAN для такого масштаба избыточен: стоимость только FC-коммутатора начинается от 200 тысяч рублей. HCI минимальной конфигурации (3 узла) стартует от 1.5 миллионов рублей - неоправданно для файлового шара.

Для предприятия на 500 пользователей с виртуализацией расклад меняется. NAS enterprise-уровня (TrueNAS R-серии, NetApp) - 2-4 миллиона рублей. SAN с FC-фабрикой - 5-10 миллионов, но дает предсказуемую производительность под СУБД и VDI. HCI из 4-6 узлов - 6-12 миллионов, выигрывает простотой управления и масштабирования. Для ЦОД с сотнями виртуальных машин HCI часто оказывается экономически эффективнее классического SAN за счет снижения OPEX: меньше кабелей, меньше отдельных устройств, единая консоль управления.

Скрытые расходы: лицензии и обучение персонала

При планировании бюджета легко недооценить стоимость лицензий. FC-коммутаторы часто требуют лицензирования портов: купили коммутатор на 24 порта, а активированы 8, остальные - за доплату. vSAN лицензируется на ядро процессора, и для двухпроцессорного сервера с 32 ядрами это десятки тысяч долларов в год. Nutanix включает лицензии в стоимость узла, но цена узла соответственно выше. Подписки на поддержку - ежегодные 15-25% от стоимости оборудования.

Бесплатные альтернативы существуют. TrueNAS CORE, XigmaNAS, StarWind VSAN Free предоставляют функциональность enterprise-уровня без лицензионных отчислений. Платой становится необходимость в квалифицированном персонале: настройка ZFS, мониторинг, решение проблем ложатся на администратора. Для компаний с сильной IT-командой это оправданный путь экономии. Для организаций без выделенных администраторов СХД готовые коммерческие решения с поддержкой вендора снижают риски.

При расчете TCO для виртуализированных сред стоит изучить сравнение моделей HPE MSA, где приведены конкретные цифры для разных конфигураций.

Выбор архитектуры под типовые сценарии: от офиса до ЦОД

Теория становится полезной, когда привязана к конкретным задачам. Разберем четыре типичных сценария с рекомендациями и обоснованием.

Сценарий 1: Файловый сервер для офиса на 100 человек

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

Рекомендация: NAS с RAID 10 или RAID 6 на 4-8 HDD, сетевой интерфейс 10GbE, поддержка SMB и NFS. RAID 10 дает максимальную производительность для случайного доступа и время восстановления в разы быстрее RAID 6. Для 100 пользователей достаточно 4-6 дисков в RAID 10. Аппаратные варианты: Synology DS1823xs+, QNAP TS-873A. Программные: TrueNAS CORE на сервере с Xeon E-2300 и 32 ГБ ECC-памяти. Встроенные средства репликации и снапшотов обеспечивают защиту от случайного удаления файлов без стороннего ПО.

Сценарий 2: Высоконагруженная СУБД (PostgreSQL, MS SQL)

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

Рекомендация: SAN на Fibre Channel с NVMe-дисками или DAS с локальными NVMe и синхронной репликацией на второй сервер. Базам данных нужен блочный доступ: СУБД сама управляет файловой системой и кэшированием, ей не нужен промежуточный NAS с его интерпретацией файлов. FC дает стабильную низкую задержку и предсказуемую производительность под нагрузкой. Для отказоустойчивости строится кластер из двух серверов с синхронной репликацией данных: запись подтверждается только после фиксации на обоих узлах. Это обеспечивает RPO = 0 при отказе одного узла.

Если бюджет ограничен, альтернатива - DAS с NVMe-дисками в одном сервере и асинхронная репликация на резервный. RPO при этом составит от нескольких секунд до минут, но стоимость снижается радикально: не нужны FC-коммутаторы и HBA. Для некритичных баз такой подход оправдан.

Сценарий 3: Кластер виртуализации из 3-х узлов

Задача: запуск 50-100 виртуальных машин разного профиля, миграция ВМ между узлами, отказоустойчивость на уровне кластера. Требуется баланс производительности, простоты управления и стоимости.

Рекомендация: HCI на базе VMware vSAN или альтернатив. Три узла - минимальная конфигурация для отказоустойчивого кластера. Каждый узел содержит локальные диски (NVMe для кэша, SSD для емкости), два порта 25GbE для трафика хранилища и управления. vSAN автоматически распределяет данные между узлами, при отказе одного узла ВМ перезапускаются на оставшихся. Управление из vCenter, без отдельной консоли СХД.

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

Сценарий 4: Резервное копирование и архивное хранение

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

Рекомендация: NAS с большим количеством HDD большого объема, RAID 6 или RAID-Z2. Дедупликация на уровне файловой системы (ZFS) или приложения резервного копирования (Veeam) сокращает занимаемый объем. Интеграция с Veeam через репозиторий на NFS или SMB позволяет использовать снапшоты для быстрого восстановления. Для архивов с редким доступом оправдано использование SMR-дисков - они дешевле, но медленнее на запись, что для архива некритично.

DAS в этом сценарии проигрывает: резервное копирование обычно централизованное, и прямой доступ с одного сервера ограничивает архитектуру. SAN избыточен по стоимости: платить за FC-коммутаторы ради хранения бэкапов нерационально. HCI может использоваться, если бэкапы - часть общей инфраструктуры, но выделенный NAS под бэкапы часто дешевле.

Надежность и отказоустойчивость: RAID, репликация и кластеризация

Надежность СХД строится на трех уровнях. Уровень дисков - защита от физического отказа носителя. Уровень контроллеров - защита от отказа управляющей электроники. Уровень узлов и площадок - защита от потери целого сервера или дата-центра. Каждая архитектура реализует эти уровни по-своему.

DAS защищает диски через RAID-контроллер: уровни 1, 5, 6, 10 с горячей заменой. Контроллер - единая точка отказа, если он не дублирован. Резервирование на уровне узла отсутствует: при отказе сервера данные недоступны до восстановления. NAS добавляет резервные контроллеры в моделях среднего и верхнего уровня, а также кластеризацию: два NAS-устройства синхронизируют данные и IP-адрес, при отказе одного второе подхватывает обслуживание. SAN обеспечивает максимальную отказоустойчивость: дублированные контроллеры массива, multipathing (два и более путей от сервера к LUN), дублированная фабрика, синхронная репликация между массивами на разных площадках. HCI защищает данные на уровне распределенной файловой системы: каждый блок данных имеет несколько копий на разных узлах, при отказе узла система автоматически создает новые копии на оставшихся.

RAID - это не резервная копия

Принцип, который стоит повторять при каждом обсуждении надежности. RAID защищает от физического отказа диска. Он не защищает от случайного удаления файла, от шифровальщика, от повреждения файловой системы, от ошибок приложения, записавшего мусор вместо данных. Все эти угрозы закрываются резервным копированием - отдельным процессом, который создает копии данных на независимом носителе по расписанию. Правило 3-2-1: три копии данных, на двух разных типах носителей, одна копия географически удалена. RAID может быть частью стратегии, но не заменой бэкапа.

Будущее СХД: NVMe-oF, программно-определяемые хранилища и облачная интеграция

Границы между архитектурами размываются. NVMe over Fabrics (NVMe-oF) позволяет подключать NVMe-диски по сети с задержкой, близкой к локальному доступу. Протокол работает поверх RDMA (InfiniBand, RoCE) или TCP, обеспечивая микросекундные задержки для удаленного блочного доступа. Это стирает грань между DAS и SAN: сервер получает производительность локального NVMe, но диск физически находится в общем массиве.

Программно-определяемые хранилища (SDS) - Ceph, Gluster, MinIO - абстрагируют оборудование и предоставляют блочный, файловый или объектный доступ поверх стандартных серверов. SDS может работать как SAN, NAS и объектное хранилище одновременно, в зависимости от конфигурации. Детальное сравнение SDS и аппаратных массивов с расчетом TCO приведено в стратегии выбора между SDS и аппаратными контроллерами.

Гибридные облачные решения - еще один тренд. Данные распределяются между локальной СХД и облачным хранилищем, автоматически перемещаясь туда, где дешевле и быстрее. Это не отдельная архитектура, а надстройка над существующей, будь то NAS, SAN или HCI. Для российских реалий актуальны отечественные СХД, сравнение которых дано в практическом руководстве по выбору российских хранилищ.

Итоговая таблица сравнения и чек-лист для выбора

Чек-лист из семи вопросов перед выбором архитектуры:

1. Какой тип доступа нужен приложениям: блочный или файловый? Блочный - SAN или DAS, файловый - NAS.
2. Какая допустимая задержка? Микросекунды - DAS или NVMe-oF, десятки микросекунд - SAN FC, сотни - iSCSI/NAS.
3. Сколько серверов будут использовать хранилище? Один - DAS, несколько - NAS/SAN/HCI.
4. Какой прогноз роста данных на 3 года? Предсказуемый - вертикальное масштабирование, непредсказуемый - горизонтальное.
5. Есть ли в штате администратор СХД? Нет - NAS с веб-интерфейсом или HCI с единой консолью, да - SAN.
6. Какой бюджет на лицензии и поддержку? Ограничен - open-source решения, достаточен - коммерческие с поддержкой вендора.
7. Требуется ли катастрофоустойчивость между площадками? Да - SAN с синхронной репликацией или HCI с растянутым кластером.

Выбор архитектуры СХД - это баланс между производительностью, надежностью и стоимостью. Не существует единственно правильного решения для всех задач. DAS дает скорость, NAS - простоту, SAN - предсказуемость, HCI - гибкость. Отталкивайтесь от конкретных требований ваших приложений, а не от модных терминов.