NAS, SAN и DAS: чем отличаются и что выбрать

Три буквы DAS, NAS и SAN на первый взгляд решают одну задачу: где физически будет лежать корпоративная информация и каким путём до неё дотянется сервер. На деле подход у них разный: от выбора архитектуры зависят и скорость приложений, и итоговый счёт за инфраструктуру, и то, насколько легко потом добавить ещё дисков. Универсально правильной архитектуры не бывает — есть та, что подходит конкретной задаче.

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

У каждой архитектуры свой набор протоколов: прямое подключение работает по SAS или SATA, файловое хранилище использует NFS и SMB, а блочная сеть опирается на Fibre Channel или iSCSI. Именно протокол диктует, во сколько обойдутся контроллеры и какая кабельная обвязка понадобится, а разница здесь ощутима уже на этапе сметы.

Расшифровывается DAS как Direct Attached Storage: по сути, накопитель, зашитый в сам сервер. Кабель SAS либо SATA идёт от диска (или полки) прямиком в контроллер, никакого коммутатора между ними нет в принципе, поэтому запрос добирается кратчайшим из всех возможных путей.

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

За аббревиатурой NAS стоит Network Attached Storage: устройство прописывается в локальной сети компании и работает не с блоками, а с целыми файлами. За ним закреплён собственный IP-адрес, оно видно в сети как обычная папка, а содержимое отдаёт клиентам Linux по NFS и клиентам Windows по SMB.

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

За SAN стоит Storage Area Network, и, в отличие от файлового доступа NAS, тут серверы и дисковые массивы разделяет целая выделенная сеть. Удалённый том сервер воспринимает так, будто диск установлен прямо в нём: это заслуга блочного протокола Fibre Channel или iSCSI поверх обычной IP-сети.

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

В чистой скорости DAS почти всегда впереди: данные не делают крюк через сетевой узел. Зато масштабируется прямое подключение хуже всех: прибавить объём получится только дисками в тот же сервер, а поделиться этим пространством с соседними машинами без специального софта не выйдет.

NAS растёт вширь без особых усилий: докупил и подключил в сеть новую коробку, хотя канал Ethernet рано или поздно станет узким местом для десятков активных клиентов. SAN эту стену обходит выделенной инфраструктурой: пропускную способность наращивают портами и коммутаторами, а новые серверы подключают к общему пулу дисков без переноса данных.

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

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

NAS просит собственное сетевое железо или готовую коробку, но настраивается это без узкой специализации в хранилищах. Бюджет подрастает за счёт лицензий на снапшоты, репликацию и квоты, если бизнесу они вообще нужны.

SAN оказывается самой дорогой из трёх архитектур, и дело не только в железе. Коммутаторы Fibre Channel, адаптеры HBA, резервирование путей и обучение персонала складываются в солидный бюджет: и на старте, и в поддержке. Экономически это оправдано, когда простой обходится дороже, чем содержание сложной СХД.

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

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

Кластерам виртуализации, распределённым СУБД и всему, что требует высокой отказоустойчивости, нужна SAN: когда несколько серверов одновременно работают с одними блочными томами без потери скорости, замены такой СХД попросту не существует. Плюс такого сценария: возможность добавлять серверы в общий пул без остановки сервисов.

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

Современные СХД всё чаще умеют сразу и то, и другое: один контроллер обслуживает и файловых, и блочных клиентов одновременно, переключая протокол на лету. Это позволяет стартовать с простого NAS, а затем постепенно переводить часть нагрузки на блочный доступ без замены железа.

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

Да, это рабочая и распространённая схема: под приложением стоит быстрый диск DAS, а рядом крутится NAS с общими файлами и архивами всей команды.

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

Маленькой команде такая инфраструктура почти всегда не по карману и избыточна по задачам: DAS или NAS закроют типичные сценарии дешевле и без лишней возни с администрированием.

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

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

Быстрее всех встаёт DAS: достаточно подключить диски к серверу. NAS потребует настройки сети, а SAN — ещё и коммутаторов с адаптерами.