NAS и SAN: ключевые различия и критерии выбора
NAS отдаёт данные файлами: клиент монтирует сетевую папку по NFS или SMB и работает с каталогами, правами и блокировками. SAN отдаёт блочные устройства: сервер получает LUN по iSCSI или Fibre Channel и форматирует его в собственную файловую систему. В первом случае один массив делят десятки клиентов, во втором каждый сервер получает личный виртуальный диск.
Короткое правило для 2026 года выглядит так: файловые сервисы, резервные копии, медиатека и шаблоны виртуальных машин живут на NAS; СУБД, диски виртуальных машин с интенсивным вводом-выводом и кластеры живут на SAN. Дальше выбор уточняют латентность, бюджет и компетенции команды. Разницу между файловым, блочным и объектным доступом на уровне архитектуры подробно разбирает материал про объектное, блочное и файловое хранилище.
Файловый доступ (NAS) против блочного (SAN)
В NAS файловая система работает на самом массиве: он управляет метаданными, квотами, снапшотами, правами через AD или LDAP. Клиент видит только протокол и сетевой путь. Один NAS обслуживает сотни клиентов одновременно, и это его главное преимущество. Обратная сторона: сетевой файловый протокол добавляет overhead, а конкурентный доступ к одним файлам требует корректных блокировок.
В SAN массив отдаёт сырые блоки. Файловую систему создаёт хост, он же отвечает за кэш, журнал и восстановление после сбоя. Латентность получается ниже и предсказуемее, потому что между приложением и диском нет файлового слоя по сети. Ограничение жёсткое: один LUN без кластерной файловой системы (GFS2, OCFS2) или без менеджера блокировок гипервизора (VMFS) отдают только одному хосту. Аналогия простая: NAS это сетевой диск, SAN это виртуальный жёсткий диск.
| Параметр | NAS | SAN |
|---|---|---|
| Тип доступа | файловый | блочный |
| Протоколы | NFS v3/v4.1/v4.2, SMB 3.1.1 | iSCSI, FC, FCoE, FC-NVMe |
| Единица данных | файл | блок 512 Б или 4 КиБ |
| Типичная латентность | 0,5-2 мс | 0,1-1 мс |
| Совместный доступ | да, десятки и сотни клиентов | один хост на LUN |
| Стоимость старта | ниже | выше |
| Порог компетенций | средний | высокий |
| Масштабирование | диски, полки, сетевые шары | LUN, порты, полки, фабрика |
Когда выбирать NAS, а когда SAN
Проверьте задачу по списку ниже, прежде чем смотреть в сторону тяжёлых массивов.
- NAS: общий доступ к файлам для офиса, домашние каталоги, права через Active Directory, квоты.
- NAS: ночные резервные копии, архивы, снапшоты рабочей станции, медиатека, раздача файлов по SMB и NFS.
- NAS: хранилища под шаблоны ВМ и ISO, где важнее объём и цена гигабайта, а не микросекунды.
- SAN: PostgreSQL, MySQL, MS SQL, 1С с базой от 500 ГБ и требованием десятков тысяч IOPS.
- SAN: диски виртуальных машин с постоянной нагрузкой отклика меньше 1 мс.
- SAN: отказоустойчивые кластеры, где нужен multipath, ALUA и предсказуемая очередь команд.
Практический пример из инфраструктур 2026 года: база 1С на PostgreSQL с пиком 10 000 IOPS и требованием отклика до 1 мс ставится на LUN NVMe через iSCSI на 25GbE или на FC 32G. Файловый сервер на 50 пользователей с профилем нагрузки 30-60 МБ/с на запись спокойно закрывается NAS на 10GbE с кэшем SSD.
Границы между классами стираются. Появились NAS на NVMe с портами 40 и 100GbE, которые выдают сотни тысяч IOPS по NFS, и SAN с Ethernet вместо оптики. Унифицированные массивы отдают и файлы, и блоки одновременно, но через разные порты и процессоры, иначе производительность просядет.
Протоколы и производительность: NFS, SMB, iSCSI, Fibre Channel
Потолок производительности задаёт протокол. Разберём четыре основных варианта и их актуальные версии.
NFS. Версия 3 живёт без состояния и всё ещё встречается в старых экспортах. Версия 4.1 добавила сессии и pNFS, что позволяет распараллелить доступ между серверами массива. Версия 4.2 принесла server-side copy и разреженные файлы, плюс появился NFS over RDMA. Слушает порт 2049. Клиентские параметры nconnect и размеры rsize/wsize прямо влияют на пропускную способность.
SMB. Версия 2.1 уже умеет большие MTU и durable handles. Версия 3.0 добавила multichannel и прозрачное переключение путей, версия 3.1.1 закрепила шифрование AES-128-GCM и проверку целостности до аутентификации. SMB Direct через RDMA снимает нагрузку с процессора на 25 и 100GbE.
iSCSI. Работает на обычном Ethernet, поддерживает программный инициатор (open-iscsi в Linux, встроенные в VMware и Windows), CHAP-аутентификацию, MPIO с выбором путей. Для блочного трафика включают jumbo frames с MTU 9000, если весь путь это поддерживает.
Fibre Channel. Скорости 8, 16, 32, 64 и 128 Гбит/с, отдельная фабрика, зонирование по WWN, LUN masking. FC-NVMe переносит команды NVMe поверх той же оптики и снижает отклик ниже 100 мкс.
Сравнение латентности и IOPS
| Протокол | Транспорт | Типичная латентность | Пропускная способность на порт | Где применять |
|---|---|---|---|---|
| NFS v4.2 | 10/25/100GbE | 0,5-2 мс | 10, 25, 100 Гбит/с | файловые шары, шаблоны ВМ, бэкапы |
| SMB 3.1.1 | Ethernet, RDMA | 0,4-1,5 мс | 10, 25, 100 Гбит/с | Windows-среды, Veeam, общие каталоги |
| iSCSI | Ethernet, MPIO | 0,3-1 мс | 10, 25, 100 Гбит/с | СУБД, тома ВМ, кластеры |
| FC 32G | оптика | 0,1-0,5 мс | 32 Гбит/с | критичные СУБД, высокая нагрузка |
| FC-NVMe | оптика | 0,05-0,2 мс | 32, 64 Гбит/с | NVMe-массивы, миллионы IOPS |
Цифры стоит соотносить с возможностями носителей. Один HDD на 7200 об/мин выдаёт 150-200 IOPS, SATA SSD около 90 000, SAS SSD выше 200 000, современный NVMe от 500 000. Когда диск даёт миллион IOPS, узким местом становится протокол и сеть, а не накопитель.
Для баз данных критичен отклик меньше 1 мс, и здесь подходят FC или NVMe over Fabrics. Для ночного резервного копирования и файловых шар 5-10 мс не создают проблем, поэтому iSCSI на 25GbE закрывает большинство рабочих задач с запасом. Подробная настройка target и initiator, экспортов NFS и SMB-шар с CHAP, ACL и multipath разобрана в руководстве по протоколам iSCSI, NFS и SMB.
Влияние сети на производительность
iSCSI требует отдельного VLAN или физического интерфейса, настроенных jumbo frames и включённого MPIO с балансировкой по путям. Fibre Channel требует отдельной фабрики с зонированием и проверкой, что каждый HBA видит только свой target.
Сто Гигабит Ethernet стал доступнее, но требует коммутаторов, NIC и оптики соответствующего класса, а также продуманного охлаждения. Для типовой инфраструктуры 25GbE с iSCSI и multipath даёт 2-4 ГБ/с на узел и этого хватает даже под требовательные СУБД.
Отдельная ловушка: смешивание трафика NAS и SAN в одной сети. Когда резервное копирование по NFS и нагрузка базы по iSCSI идут через один 10GbE, коммутатор начинает терять буферы, растут ретрансмиты, а отклик базы подскакивает с 0,8 до 5-8 мс. Разносите протоколы по интерфейсам и VLAN.
Стоимость владения и сложность эксплуатации
CAPEX и OPEX: что учесть в бюджете
Капитальные расходы на NAS начинаются от 50 тыс. руб. за готовое устройство на 2-4 диска и доходят до миллионов за enterprise-массив с полками расширения. SAN стартует выше: дисковый массив от 500 тыс. руб., FC-коммутатор от 300 тыс. руб., каждый HBA 60-100 тыс. руб., плюс оптика и SFP-модули.
Операционные расходы складываются из поддержки вендора, ЗИП, электроэнергии, аренды стойки, обучения персонала и фонда оплаты труда администратора. Оптический кабель и трансиверы FC дороже Ethernet при сопоставимой длине, но FC-фабрика предсказуемее под нагрузкой.
Ориентировочный TCO за три года для 50 ТБ полезной ёмкости: NAS на 10-25GbE около 1,5 млн руб., SAN с FC и NVMe-кэшем около 4 млн руб. Программно-определяемые решения на стандартных серверах снижают железную часть счёта, но повышают требования к компетенциям команды.
Не забудьте про диски: ресурс TBW, DWPD и гарантию. Как считать остаточный ресурс SSD, менять накопители без остановки сервиса и выбирать носители под нагрузку, показано в разборе жизненного цикла данных в серверных системах.
Навыки команды и риски эксплуатации
NAS настраивается через веб-интерфейс: тома, шары, права, снапшоты, репликация. Специалист среднего уровня развернёт такой массив за день и будет поддерживать его без внешней помощи.
SAN требует другой подготовки: зонирование по WWN, LUN masking, multipath, проверка ALUA, контроль глубины очереди. Ошибка в зонировании отрезает хосты от данных, а неверная политика путей превращает отказоустойчивость в иллюзию и приводит к ложным переключениям. Если в команде нет опыта FC, берите iSCSI или NAS: те же блочные тома на Ethernet без отдельной фабрики.
Сценарии использования: виртуализация, резервное копирование, медиа, базы данных
Виртуализация: VMware и Proxmox
Под VMware диски виртуальных машин с постоянной нагрузкой ставят на VMFS поверх iSCSI или FC, а шаблоны, ISO и бэкапы держат на NFS-датасторе. VMFS сам управляет блокировками, поэтому один LUN можно безопасно отдать всем хостам кластера. В Proxmox блочные тома iSCSI подключают как LVM или LVM-thin, а NFS и CIFS используют для бэкапов и ISO. Матрица выбора между DAS, NAS, SAN и HCI со сравнением по производительности, RPO и RTO собрана в сравнении архитектур хранения.
NAS для резервного копирования: почему это работает
Бэкапы редко требуют микросекундного отклика, зато требуют ёмкости и дешёвого гигабайта. NAS отдаёт SMB и NFS, поддерживает снапшоты, дедупликацию и репликацию на второй массив. Veeam пишет на SMB или NFS-репозиторий, rsync забирает данные с серверов, снапшоты фиксируют состояние без остановки сервисов.
Пример по железу: Synology RS3621xs+ на 12 дисков с 10GbE выдаёт до 500 МБ/с на запись, чего хватает для ночного окна бэкапа объёмом 5-10 ТБ. Для защиты от шифровальщиков включают immutability: WORM-каталоги, объектную блокировку S3 или отдельный hardening-репозиторий на XFS с reflink для быстрых полных копий.
Ограничение важное: NAS плохо подходит для резервного копирования баз с RPO в минуты. Здесь нужны снапшоты на уровне массива, потоковая репликация журналов или блочный доступ с выгрузкой WAL и binlog.
Медиахранилище: объём важнее IOPS
Для видео, монтажа и архивов собирают NAS на 10 или 25GbE с большим количеством HDD и SSD-кэшем под метаданные. Один диск 7200 об/мин отдаёт 150-250 МБ/с последовательно, массив на 24 диска упирается в сеть: 10GbE даёт около 1,1 ГБ/с, 25GbE около 2,5 ГБ/с. SMB multichannel и RDMA позволяют выжать больше на клиентах с несколькими портами. Если объёмы измеряются петабайтами и нужна аналитика, смотрите в сторону объектного доступа: технологии сбора и миграции больших массивов разобраны в руководстве по хранению больших данных.
Базы данных: только блочный доступ с контролем отклика
PostgreSQL, MySQL и MS SQL чувствительны к задержке fsync и глубине очереди. Для них берут отдельные LUN под данные, отдельные под журнал и отдельные под временные файлы, ставят NVMe-кэш или полностью NVMe-полки, ограничивают размер блока и проверяют отклик под нагрузкой.
Базу на NFS запускают только при явной необходимости и с осторожностью: нужны NFS v4.1 и выше, корректные параметры монтирования, отдельная сеть и регулярная проверка блокировок. Ошибка в настройках приводит к зависшим транзакциям и повреждению данных после сетевого сбоя.
Сетевое хранилище для Kubernetes: CSI и выбор драйвера
Kubernetes работает с хранилищем через CSI-драйверы, и выбор драйвера важнее выбора железа.
- NFS CSI подключается проще всего и умеет режим RWX, когда один том монтируют несколько подов. Минус: нет квот на уровне драйвера, снапшоты ограничены, а слабая настройка блокировок ведёт к повреждению файлов.
- iSCSI CSI даёт блочный том в режиме RWO, подходит для stateful-приложений и СУБД, требует multipath на всех узлах.
- Ceph RBD через Rook закрывает блочные и файловые тома с репликацией, но требует минимум трёх узлов, отдельной сети и SSD под журнал.
- Longhorn удобен на небольших кластерах: репликация, снапшоты и бэкапы из коробки при умеренной нагрузке.
- local-path и hostPath годятся для кэшей и временных данных, но не дают переносимости подов между узлами.
Для stateful-приложений берите блочный доступ: PostgreSQL в Kubernetes на iSCSI LUN с ext4 даёт стабильный отклик и понятное поведение при перезапуске пода. NFS с версией 4.1 и включёнными leases допустим под файловые задачи и общие каталоги.
Смешивание протоколов: подводные камни и лучшие практики
Один массив под NAS и SAN работает, но только при грамотном разделении трафика и дисциплине доступа к томам.
Изоляция трафика и QoS
Выделите отдельные VLAN или физические интерфейсы для iSCSI, NFS и SMB. Для iSCSI и RoCE включайте приоритизацию и управление потоком: DCB с классами трафика и PFC для lossless-профиля. Jumbo frames с MTU 9000 настраивайте на всём пути, включая коммутаторы, иначе фрагментация и потери пакетов съедят выигрыш.
Проверяйте MTU и скорость после каждого изменения. Рассинхрон MTU между хостом и коммутатором даёт падение пропускной способности в разы, а диагностируется это счётчиками ретрансмитов и ошибок интерфейса.
Блокировки и целостность данных
NFS и SMB по-разному управляют блокировками: NFS v4 использует leases, SMB - oplocks и диапазонные блокировки. Если одно и то же хранилище отдать обоим протоколам и писать в одни файлы с двух сторон, конфликты приведут к повреждению содержимого.
С блочными томами правило одно: один LUN одному хосту, пока нет кластерной файловой системы GFS2 или OCFS2 либо менеджера блокировок гипервизора. Типовая авария выглядит так: два Linux-хоста получили доступ к одному LUN без кластерной ФС и писали в него одновременно. Через несколько минут ext4 разрушилась, потребовалось восстановление из бэкапа и разбор причины.
Практика, которая экономит нервы: отдельный LUN на каждый хост, снапшот перед изменениями, тест на стенде вместо продуктивной среды и мониторинг отклика до и после переключений.
Тренды 2026: что изменится в выборе хранилищ
NVMe over Fabrics размывает привычное деление. FC-NVMe и RoCEv2 отдают отклик ниже 100 мкс, а NVMe/TCP работает на обычном Ethernet без отдельной оптики. Массивы на NVMe постепенно вытесняют SAS-полки в задачах с высокой нагрузкой, а 25GbE становится базовым уровнем подключения.
Гиперконвергентные платформы объединяют вычисления и хранение: vSAN и Nutanix упрощают масштабирование, но требуют аккуратного подбора дисков и сетевых карт. Программно-определяемые хранилища на стандартных серверах снижают аппаратные расходы и повышают требования к команде.
Облачные шлюзы позволяют строить гибридные сценарии: холодные данные уходят в объектное хранилище через S3-шлюз, горячие остаются локально. Для тестов, репликации и новых сервисов удобно поднимать инфраструктуру в облаке: Timeweb Cloud даёт серверы, базы данных, хранилище и Kubernetes, что позволяет проверить архитектуру до закупки железа. Если в пайплайнах есть обработка данных моделями, агрегатор API AiTunnel даёт доступ к более 200 моделям через единый интерфейс с оплатой в рублях.
План действий перед закупкой: соберите профиль нагрузки за 2-4 недели (iostat, fio, метрики гипервизора), посчитайте пиковые IOPS и отклик, определите долю файловых и блочных задач, проверьте компетенции команды и только потом выбирайте между NAS, iSCSI-SAN и FC. Для новых проектов с требованием отклика меньше 0,5 мс смотрите на NVMe-oF, для остальных остаются проверенные NAS на 25GbE и iSCSI-массивы.