SAN (сеть хранения данных): принципы работы и преимущества

SAN (Storage Area Network) — выделенная высокопроизводительная сеть, которая физически отделяет трафик хранения данных от вашей LAN. Серверы получают прямой блочный доступ к дисковым массивам, минуя файловые протоколы и общую сетевую инфраструктуру. Для операционной системы диск на SAN выглядит так же, как локальный — с той разницей, что физически он находится в другой стойке или даже в другом зале ЦОД.

Как SAN работает на уровне блоков

Сетевое хранилище типа NAS отдаёт файлы через SMB или NFS. Это удобно для шары с документами, но для СУБД или виртуальных машин — избыточная абстракция. SAN работает ниже: на уровне блоков ввода-вывода. Сервер посылает команду «запиши блок 4096 байт по адресу X» — и СХД её выполняет. Никакой файловой системы между ними нет.

Что это даёт? Минимальные задержки и предсказуемую производительность. Когда Oracle или PostgreSQL пишут WAL-логи, им не нужен оверхед файлового протокола. Они работают с блочным устройством напрямую — как с локальным SSD, только этот «SSD» живёт в СХД с RAID, снэпшотами и репликацией.

Ещё один плюс блочного доступа — формат файловой системы выбирает сам сервер. Хотите ext4 — пожалуйста. Нужен NTFS для Windows-кластера — без проблем. VMFS для VMware — тоже. SAN ничего не знает про файлы, каталоги и права доступа: это просто «трубопровод» для блоков. И именно поэтому SAN разгружает локальную сеть — трафик хранения данных не пересекается с пользовательским и не конкурирует за полосу пропускания с RDP-сессиями или IP-телефонией.

Протоколы: Fibre Channel, iSCSI и NVMe-oF

Выбор протокола — это выбор баланса между скоростью, стоимостью и сложностью эксплуатации. Три основных варианта для подключения серверов к сетевому хранилищу:

Fibre Channel остаётся стандартом для mission-critical нагрузок. Gen 6 достигает 128 Гбит/с за счёт агрегации четырёх линков по 32G через QSFP-трансиверы. Протокол lossless — потерь пакетов не бывает, данные доставляются строго по порядку. Для баз данных и виртуализации это критично. Уже ведутся работы над Gen 7 — 256GFC и 512GFC, хотя до серийного оборудования дело дойдёт не раньше 2027–2028 года.

iSCSI — бюджетная альтернатива. SCSI-команды инкапсулируются в TCP/IP и идут по обычной Ethernet-сети. Можно обойтись без специализированного оборудования, но за это приходится платить бо́льшими задержками и необходимостью выделять VLAN, настраивать jumbo frames и следить за QoS. Для тестовых сред и некритичных нагрузок — вполне рабочий вариант.

NVMe over Fabrics — протокол, который меняет расстановку сил. Он снимает SCSI-оверхед и даёт до 64 тысяч очередей ввода-вывода, каждая на 64 тысячи команд. Рынок NVMe-oF коммутаторов вырос с $1,59 млрд в 2025 году до прогнозных $5,4 млрд к 2030-му (CAGR ~28%). Microsoft уже добавила NVMe-oF инициатор в Windows Server Insider-билды — технология перестаёт быть нишевой.

Компоненты SAN-фабрики

Построить SAN — это не просто воткнуть кабели. Каждый элемент выполняет свою роль, и ошибка в любом компоненте скажется на всей инфраструктуре хранения данных.

HBA (Host Bus Adapter) — специализированный адаптер в сервере, аналог сетевой карты, но для SAN-фабрики. Разгружает CPU сервера от обработки протокола FC. Типичные варианты — двухпортовые карты Emulex LPe32002 или QLogic 2770 Series на 32 Гбит/с.

FC-коммутаторы — ядро фабрики. Бывают двух классов: фиксированные (Brocade G610/G620 — от 24 до 64 портов) и директорского класса (Brocade X7 Director — до 512 портов в одном шасси). Директоры стоят от 3–5 млн рублей, но обеспечивают горячую замену любого модуля без остановки фабрики.

СХД (Система хранения данных) — дисковые массивы с контроллерами. HPE Nimble, Dell PowerStore, NetApp AFF — всё это примеры массивов, которые подключаются к SAN-фабрике и предоставляют серверам блочные LUN-ы. О том, какие ошибки при выборе СХД приводят к потерям, мы разбирали отдельно.

Оптические кабели и трансиверы — физический уровень. Для 32GFC используются SFP+ с LC-коннекторами, для 128GFC — QSFP с MPO-разъёмами. Длина линков внутри ЦОД обычно до 100 метров на OM4-многомоде.

Топологии и отказоустойчивость

SAN проектируют без единой точки отказа — и это не маркетинговая фраза, а архитектурное требование. Стандартная схема — две независимые фабрики (Fabric A и Fabric B). Каждый сервер подключается к обеим через два HBA-порта. Каждая СХД тоже подключена к обеим фабрикам через дуальные контроллеры.

Если коммутатор в Fabric A выходит из строя, весь трафик хранения данных автоматически переключается на Fabric B. Multipath-драйвер на сервере (MPIO в Windows, DM-Multipath в Linux) делает это прозрачно для приложений. БД даже не заметит, что путь к диску изменился.

Топологии SAN-фабрик варьируются от каскадных (edge-core), где периферийные коммутаторы связаны с центральными через ISL-транки, до mesh-схем, где каждый коммутатор соединён с каждым. Крупные инсталляции используют каскадную топологию — она проще масштабируется и легче диагностируется при сбоях.

Зонирование (zoning) — механизм изоляции внутри фабрики. Вы указываете, какие HBA-порты могут видеть какие LUN-ы на СХД. Это и безопасность, и защита от случайного затирания чужих томов. Без зонирования любой сервер увидит все диски — а это прямой путь к коррупции данных.

Зонирование бывает port-based (по физическому порту коммутатора) и WWN-based (по уникальному идентификатору HBA). Второй вариант гибче: если пересоединить кабель в другой порт коммутатора, зона не сломается. LUN masking — дополнительный фильтр уже на стороне СХД. Двойная защита: фабрика контролирует, кто видит массив, а массив контролирует, кто видит конкретный том. Параноидально? Может быть. Но когда на одной фабрике живут продуктивная база и тестовая среда — лишней защиты не бывает.

SAN и виртуализация: зачем это кластерам

Виртуализация — одна из главных причин, по которой SAN продолжает жить и развиваться. VMware vSphere, Proxmox VE, Microsoft Hyper-V — все они используют общее хранение данных для ключевых функций кластера. Если вы ещё определяетесь с платформой, поможет полный разбор популярных гипервизоров.

Живая миграция (vMotion, Live Migration) работает только когда оба хоста видят один и тот же датастор. На DAS — локальных дисках — это невозможно без танцев с бубном и репликации. С SAN сервер просто переносит оперативную память ВМ на соседний хост, а диски остаются на месте, потому что оба хоста видят один LUN.

HA-кластеры требуют общего хранилища для фенсинга и перезапуска ВМ на уцелевших нодах. Если нода упала — кластер поднимает машины на других хостах, используя те же LUN-ы. Для среды из 500+ виртуальных машин SAN — стандартный выбор.

Отдельная история — Storage DRS в VMware и аналогичные механизмы в других гипервизорах. Если один датастор перегружен, система автоматически мигрирует VMDK-файлы на менее загруженный LUN. Для этого нужно, чтобы все датасторы были на общем хранилище — и SAN здесь безальтернативен. Proxmox VE использует аналогичную схему: Ceph или LVM-thin поверх iSCSI/FC LUN-ов, а миграция идёт через общий storage pool.

SAN vs NAS vs DAS: когда что выбирать

Спор «SAN или NAS» обычно начинается тогда, когда бюджет ограничен, а задачи — амбициозны. Разберём трезво.

NAS отлично справляется с файловым доступом: расшарить папку, раздать видеоредакторам медиаконтент, организовать бэкап-репозиторий. Если резервное копирование — приоритет, стоит изучить, как выбрать сервер для бэкапов. Но если нужен прямой блочный доступ для СУБД — NAS добавит слой абстракции и увеличит задержки. DAS — дёшев и быстр, но изолирует хранение данных внутри одного сервера. Умер сервер — пропал доступ к дискам (если нет аппаратного RAID-контроллера с выносным подключением, но это уже костыль).

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

Есть и гибридный подход. Некоторые СХД (NetApp FAS, Dell Unity) умеют одновременно отдавать блочный доступ по FC/iSCSI и файловый — через NFS/SMB. Один массив закрывает и SAN, и NAS-сценарии. Для компаний, где бюджет не позволяет держать два отдельных хранилища — это разумный путь. Но производительность блочного доступа на таких «унифицированных» платформах чуть ниже, чем на чистых SAN-массивах, потому что контроллер делит ресурсы между протоколами.

Безопасность и корпоративные функции

SAN-инфраструктура несёт целый набор функций, которые превращают просто «сеть для дисков» в полноценную платформу управления данными.

SAN-массивы поддерживают шифрование данных at-rest (AES-256) — диски можно безопасно списывать без риска утечки. Дедупликация и компрессия на уровне СХД экономят ёмкость: типичный коэффициент сжатия для виртуальных машин — 3:1–5:1. Это означает, что 100 ТБ «сырых» данных виртуализированной среды реально занимают 20–30 ТБ физического пространства. Репликация между площадками (синхронная для RPO=0, асинхронная для удалённых ДЦ) решает задачу DR без внешних инструментов.

Тонкое выделение (thin provisioning) — ещё одна функция, экономящая деньги. Вы создаёте LUN на 10 ТБ, но физически СХД выделяет пространство по мере записи. Пока реально используется 2 ТБ — столько и занято. Экономия на дисках может составлять 40–60% от «толстого» выделения, особенно для тестовых и девелоперских сред.

Мониторинг SAN-фабрики обычно идёт через Brocade SANnav или Cisco DCNM. Эти инструменты показывают утилизацию портов, ошибки CRC на оптике, задержки до целевого массива и помогают найти узкое место до того, как о нём узнают пользователи.

Тренды: что меняется в мире SAN

Рынок FC SAN растёт на ~6% в год. Но главные изменения — качественные, а не количественные.

NVMe-oF вытесняет SCSI-стек. Вендоры (Dell, NetApp, Pure Storage) уже продают all-flash массивы с нативной поддержкой NVMe-oF. Windows Server получает встроенный NVMe-oF инициатор. Linux поддерживает nvme-tcp и nvme-rdma из коробки через модули ядра. Gen 7 Fibre Channel (64GFC, 128GFC в агрегации) заточен именно под NVMe.

Софтверный SAN (vSAN, StarWind) снижает порог входа. Вместо выделенной FC-фабрики можно собрать распределённое хранение данных поверх обычного Ethernet. Это не замена классическому SAN для тяжёлых нагрузок, но для кластеров из 3–8 нод с all-flash дисками — разумный компромисс. StarWind, к примеру, уже предлагает active-active HA для NVMe-oF без выделенных коммутаторов — два узла реплицируют данные между собой и отдают блочный доступ серверам.

Масштабирование без простоя — сильная сторона SAN, которую DAS просто не может повторить. Нужно добавить ёмкость? Вставляете дисковую полку в СХД, расширяете RAID-группу или пул — и LUN растёт онлайн. Нужна производительность? Добавляете SSD-tier, и контроллер автоматически перемещает горячие данные на быстрые диски. Серверы ничего не замечают — для них LUN не изменился.

Интеграция с облаком и edge. Гибридные сценарии — локальный SAN + облачный tier для холодных данных — становятся нормой. А edge-площадки получают компактные СХД с iSCSI или NVMe-oF/TCP, которые реплицируют данные в основной ЦОД.

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