Протоколы доступа к СХД: как выбрать и настроить iSCSI, NFS, SMB и Fibre Channel

Блочные и файловые протоколы: в чем разница и что выбрать

Выбор протокола сводится к одной развилке: нужен блочный LUN или сетевая файловая система. Блочные протоколы (iSCSI, Fibre Channel) передают клиенту виртуальный диск, и файловую систему на нем создает сам клиент: ext4, XFS, NTFS, VMFS. Файловые протоколы (NFS, SMB) отдают готовую папку, а метаданными, блокировками и целостностью управляет сервер хранения.

Отсюда два практических правила. Один LUN нельзя одновременно смонтировать на двух хостах с обычной файловой системой: получите повреждение данных. Исключение - кластерные ФС (GFS2, OCFS2, VMFS) и Windows Failover Cluster с CSV. Файловая шара, наоборот, рассчитана на сотни одновременных клиентов, потому что целостность обеспечивает сервер.

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

Терминология, которую полезно держать в голове: iSCSI и Fibre Channel строят SAN, то есть сеть блочного доступа к LUN; NFS и SMB строят NAS, сетевое файловое хранилище. Разницу в стоимости, латентности и сценариях разбирает материал NAS или SAN: выбор сетевого хранилища.

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

iSCSI или Fibre Channel: сравнение и выбор

Fibre Channel дает выделенную фабрику: трафик хранения не конкурирует с обычным IP-трафиком, кадры не фрагментируются, задержка предсказуема. Современные скорости - 16, 32 и 64 Gbps на порт. На практике 32 Gbps на порт с двумя независимыми фабриками (A и B) закрывают большинство задач виртуализации и OLTP среднего и крупного размера.

iSCSI работает поверх Ethernet и TCP. На 25 GbE с двумя портами в MPIO вы получаете до 50 Gbps агрегированной полосы, чего достаточно для подавляющего большинства нагрузок. Стоимость входа ниже в разы: сетевые карты, коммутаторы и SFP-модули обходятся дешевле FC-компонентов, а компетенции у администраторов уже есть.

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

Практическая замена FC на iSCSI почти всегда реализуема на 25 GbE и выше, но требует внимания к трем вещам: jumbo frames на всем пути, выключенный energy-efficient Ethernet на портах и корректный MPIO с проверкой failover. Без этих трех пунктов iSCSI на бумаге быстрый, а в проде дает просадки на пиках.

NFS или SMB: что выбрать для файлового хранилища

NFS вырос в Unix-мире и остается стандартом для Linux. Версии 3, 4.0, 4.1 и 4.2 отличаются механикой: NFSv3 без состояния и требует rpcbind, NFSv4.1 приносит сессии и pNFS, NFSv4.2 добавляет server-side copy и работу с разреженными файлами. На клиенте Linux опция nconnect=4 в разы поднимает пропускную способность за счет нескольких TCP-соединений к одному серверу.

SMB развивался вокруг Windows и лучше работает в смешанной среде с Active Directory. Версии 2.1, 3.0 и 3.1.1 дают SMB Multichannel, SMB Direct поверх RDMA, непрерывную доступность с persistent handles, теневые копии VSS и полноценные ACL. Для Hyper-V и файловых сервисов Windows это родной протокол без прослоек.

Рекомендация простая. Чисто Linux-парк, бэкапы, диски Kubernetes ReadWriteMany - NFSv4.2. Смешанный парк с Windows и доменом, профили пользователей, общие диски отделов - SMB 3.1.1. Оба протокола спокойно живут на одном СХД: TrueNAS, например, отдает и экспорт NFS, и SMB-шару с одного датасета, права при этом считаются по-разному, что стоит помнить при выдаче доступа. Сравнение с готовыми конфигурациями и флагами монтирования есть в руководстве сетевые протоколы для систем хранения: iSCSI, NFS и SMB.

Настройка iSCSI в Linux: пошаговое руководство

Настройка iSCSI target

Ставим инструмент управления таргетом: на Debian и Ubuntu это apt install targetcli-fb, на RHEL-подобных системах dnf install targetcli. Дальше запускаем targetcli, который открывает интерактивную оболочку с деревом конфигурации в configfs.

1. Создаем backstore на блочном устройстве: /backstores/block create name=disk1 dev=/dev/sdb. Диск должен быть без файловой системы и не смонтирован.
2. Создаем таргет с IQN, где год и домен ваши: /iscsi create iqn.2026-09.com.example:storage.target1.
3. Переходим в TPG: cd /iscsi/iqn.2026-09.com.example:storage.target1/tpg1.
4. Привязываем LUN: luns create /backstores/block/disk1.
5. Создаем ACL для инициатора: acls create iqn.2026-09.com.example:host1. Имя инициатора должно совпадать с файлом /etc/iscsi/initiatorname.iscsi на клиенте.
6. Включаем аутентификацию: cd acls/iqn.2026-09.com.example:host1, затем set auth userid=storageuser и set auth password=Str0ngPass. Возвращаемся в TPG и выставляем set attribute authentication=1, а также set attribute generate_node_acls=0, чтобы доступ получали только прописанные инициаторы.
7. Выходим командой exit и включаем службу: systemctl enable --now target.
8. Открываем порт: firewall-cmd --permanent --add-port=3260/tcp и firewall-cmd --reload. Для nftables правило выглядит как разрешение tcp dport 3260.

Проверка конфигурации: targetcli ls показывает дерево, а systemctl status target подтверждает, что служба работает. Конфигурация сохраняется автоматически при выходе, отдельный файл saveconfig.json формируется в /etc/rtslib-fb-target/ для сборок targetcli-fb.

Настройка iSCSI initiator

На клиенте ставим пакет open-iscsi и задаем собственное имя инициатора в /etc/iscsi/initiatorname.iscsi, строка InitiatorName=iqn.2026-09.com.example:host1. Дальше включаем службу: systemctl enable --now iscsid.

1. Поиск таргетов: iscsiadm -m discovery -t st -p 10.0.0.10:3260.
2. Подключение: iscsiadm -m node -T iqn.2026-09.com.example:storage.target1 -p 10.0.0.10:3260 -l.
3. Проверка: lsblk покажет новое устройство, например sdb, а dmesg | grep -i attached подтвердит обнаружение SCSI-диска.
4. Автоподключение при загрузке: iscsiadm -m node -T iqn.2026-09.com.example:storage.target1 -p 10.0.0.10:3260 --op update -n node.startup -v automatic.
5. Параметры CHAP задаются отдельными ключами: node.session.auth.authmethod=CHAP, node.session.auth.username=storageuser, node.session.auth.password=Str0ngPass.

Для отказоустойчивости discovery выполняется для каждого портала: iscsiadm -m discovery -t st -p 10.0.1.10:3260 для второй подсети. После этого настраивается multipath: в /etc/multipath.conf задаются defaults с path_grouping_policy multibus, path_checker tur и path_selector «round-robin 0», а для конкретного массива можно прописать секцию device с vendor и product. Проверка: multipath -ll показывает один mpathX с двумя путями и статусом active ready. Монтируется и форматируется именно /dev/mapper/mpathX, а не /dev/sdb.

Настройка NFS сервера и клиента в Linux

Сервер: apt install nfs-kernel-server на Debian и Ubuntu, dnf install nfs-utils на RHEL-подобных. Экспорты описываются в /etc/exports, пример строки: /srv/nfs/data 192.168.1.0/24(rw,sync,no_subtree_check,root_squash). Для отдельной подсети Kubernetes добавляют вторую строку: /srv/nfs/k8s 10.0.0.0/24(rw,sync,no_root_squash,no_subtree_check). Опция no_root_squash нужна CSI-драйверам, и открывать ее стоит только для доверенной сети хранения.

Опции, которые чаще всего меняют поведение: rw и ro задают режим, sync пишет на диск до подтверждения клиенту, async ускоряет запись и рискует данными при сбое питания, root_squash превращает root клиента в анонимного пользователя, crossmnt дает доступ к вложенным монтированиям. После правки файла выполняется exportfs -ra, а список активных экспортов показывает showmount -e localhost.

Firewall: порт 2049/tcp и 2049/udp, для NFSv3 дополнительно rpcbind на 111 и mountd. Практичнее оставить только NFSv4.2, тогда хватает одного порта 2049 и rpcbind не нужен. Монтирование на клиенте: mount -t nfs -o vers=4.2,hard,rsize=1048576,wsize=1048576,nconnect=4 10.0.0.10:/srv/nfs/data /mnt/data. В /etc/fstab та же строка с добавлением _netdev, чтобы монтирование ждало сеть: 10.0.0.10:/srv/nfs/data /mnt/data nfs vers=4.2,hard,nconnect=4,_netdev 0 0.

Безопасность в домене решается через Kerberos: sec=krb5 проверяет пользователя, krb5i добавляет проверку целостности, krb5p шифрует трафик. Шифрование стоит 10-20% пропускной способности на слабых CPU, поэтому для больших объемов его включают осознанно.

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

Первая и самая частая ошибка - рассогласованный MTU. Кто-то выставил jumbo frames на СХД, забыл про коммутатор, и в итоге получает фрагментацию, падение скорости и странные таймауты. Проверка одной командой: ping -M do -s 8972 -I eth0 10.0.0.10 проходит только при MTU 9000 на всем пути, а ping -M do -s 1472 проверяет стандартные 1500. Настройка интерфейса: ip link set dev eth0 mtu 9000, для постоянного эффекта параметр прописывается в конфигурации сети. Порядок действий один: сначала обе стороны и коммутатор, потом тесты.

Вторая ошибка - отсутствие multipath. Один кабель или один порт превращается в единую точку отказа, а полоса упирается в лимит одного линка. Лечится вторым портом в другой подсети или на другой фабрике, настройкой multipathd и проверкой multipath -ll. Обязательно проверяют failover на практике: выключают один коммутатор и смотрят, что ввод-вывод не прервался дольше таймаута замены пути (node.session.timeo.replacement_timeout, по умолчанию 120 секунд).

Третья ошибка - права доступа. Экспорт NFS на 0.0.0.0/0, iSCSI-таргет без CHAP и с generate_node_acls=1, SMB-шара с доступом Everyone: любой, кто попал в сеть, получает данные. Минимальный набор: ограничение экспорта по подсети, ACL по IQN, CHAP, отдельный VLAN или подсеть для трафика хранения, раздельные учетные записи для сервисов.

Отдельно стоит упомянуть ошибку уровня архитектуры: один LUN, подключенный к двум хостам без кластерной ФС. Данные разрушаются быстро и незаметно, а восстановление стоит дорого. И еще одна: сравнение производительности на глаз. Замеры делают инструментами, fio с профилем randread и bs=4k для IOPS, fio с bs=1M и iodepth=32 для полосы, iperf3 -P 8 для сети. Зафиксируйте baseline сразу после внедрения, иначе не с чем будет сравнивать при деградации.

Влияние протоколов на производительность и совместимость с гипервизорами

Блочные протоколы на одном и том же массиве дают меньшую задержку, чем файловые. Разница в чистой сети с 25 GbE и FC 32G лежит в пределах 10-20% по IOPS при 4k random read, но на пиках с записью файловые протоколы просаживаются заметнее из-за блокировок и метаданных. Для баз данных и плотной виртуализации это решает: каждая миллисекунда задержки умножается на количество виртуальных машин.

Для VMware с высокой нагрузкой выбирают FC или iSCSI с MPIO, NFS ставят для смешанных парков и больших VDI, где плюсы от общего датастора перевешивают. В Hyper-V связка SMB 3.1.1 с CSV на Windows Server дает масштабирование без SAN, но требует корректной настройки Multichannel и, в идеале, RDMA. В KVM чаще всего встречаются iSCSI и NFS, оба варианта работоспособны, а выбор зависит от того, кто владеет файловой системой и как организован HA кластера.

Рекомендации по выбору протокола для конкретных сценариев

Комбинировать протоколы на одном СХД нормально и часто выгодно: один пул отдает LUN для виртуализации, экспорт NFS для бэкапов и SMB-шару для офисных документов. Ограничение тут одно: каждый протокол добавляет нагрузку на контроллер, поэтому в проекте стоит посчитать суммарный IOPS и полосу по всем фронтам сразу.

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

Дальше решает стенд. Возьмите два хоста, одну СХД и прогоните четыре теста: iSCSI на 25 GbE с MPIO, FC 32G, NFSv4.2 с nconnect=4 и SMB 3.1.1 с Multichannel. Снимите IOPS, задержку и полосу на fio, проверьте отказ одного пути и зафиксируйте цифры в документации. Такая таблица замеров закрывает спор о протоколе быстрее любой теории и защищает от сюрпризов при масштабировании. Общие критерии выбора между DAS, NAS, SAN и HCI с матрицей решений разобраны в отдельном материале DAS, NAS, SAN и HCI: как выбрать систему хранения.