NAS даёт доступ к данным на уровне файлов по сети. Клиент монтирует сетевой ресурс и видит каталоги, а не дисковые блоки: файловой системой управляет сам сервер хранения. Отсюда сильные стороны (общий доступ для разных ОС, централизованные права, снапшоты, простые бэкапы) и ограничения: сетевые задержки, потолок пропускной способности, единая точка отказа.
DAS подключают кабелем напрямую к серверу, и диски видит только эта машина. SAN - отдельная сеть хранения (Fibre Channel, iSCSI, NVMe over Fabrics), которая отдаёт блочные устройства, то есть LUN. NAS тоже умеет публиковать iSCSI target, но основной его режим остаётся файловым.
Дальше разбираем три уровня: разницу файлового и блочного доступа, файловые системы ZFS, Btrfs, ext4 и XFS, протоколы NFSv3, NFSv4, SMB 2.1 и SMB 3.1.1, а также ограничения NAS и критерии выбора между готовым устройством и сборкой на TrueNAS.
Что такое NAS и чем он отличается от DAS и SAN
NAS (Network Attached Storage) - сервер хранения, который публикует файловые ресурсы в сети Ethernet. Клиенты работают с ними по NFS, SMB/CIFS, FTP или через S3-совместимый шлюз. Файловая система живёт на стороне NAS: он отвечает за размещение блоков на дисках, целостность, снапшоты и права.
DAS (Direct Attached Storage) - полки с дисками или отдельные накопители, подключённые к серверу по SAS, SATA, USB или NVMe. SAN (Storage Area Network) - выделенная сеть, в которой массив отдаёт блочные LUN серверам по Fibre Channel, iSCSI или NVMe over Fabrics. Три схемы различаются по двум осям: уровень доступа (файлы или блоки) и способ подключения (общая сеть или прямое соединение).
Файловый vs блочный доступ: принципиальная разница
При файловом доступе клиент оперирует путями и файлами. Ядро ОС отправляет запросы вида «прочитать 4 КБ по смещению в файле X» по NFS или SMB, а NAS сам решает, на какие блоки это ложится. Один ресурс монтируется на десятки машин, права и квоты настраиваются в одном месте, снапшоты и репликация работают на уровне датасета целиком.
При блочном доступе инициатор получает LUN - сырое блочное устройство. Сервер форматирует его в ext4, XFS, NTFS или ZFS и владеет этой файловой системой единолично. Плюсы: минимальные накладные расходы, предсказуемая задержка, поддержка кластерных ФС, полный контроль СУБД над кэшем и очередью ввода-вывода. Минус: один LUN нельзя просто «расшарить» между разными ОС, иначе данные будут повреждены - нужна кластерная файловая система.
Практическое правило простое. Там, где нужны общая папка, права и версии файлов, выигрывает файловый доступ: NFS-монтирование в Linux удобно для домашних каталогов и бэкендов приложений. Там, где важны IOPS и контроль над диском, выигрывает блочный: iSCSI-LUN под базу данных даёт СУБД собственную файловую систему и собственный планировщик.
Когда выбирать NAS, а когда SAN или DAS
NAS закрывает общие файлы и домашние каталоги, бэкапы серверов и рабочих станций, медиахранилище, раздачу образов, хранение артефактов сборки, RWX-тома для Kubernetes и небольшие офисы, где отдельной сети хранения нет.
SAN выбирают для нагруженных СУБД, виртуализации с жёсткими требованиями к IOPS и задержке, отказоустойчивых кластеров с общей кластерной ФС, а также когда нужны multipath и предсказуемая очередь ввода-вывода.
DAS уместен для одного сервера с минимальным бюджетом: локальные диски, тестовые стенды, узлы с плотной установкой NVMe.
Три типовых примера. Отдел из 20 человек с документами, сканами и общими папками закрывается NAS с SMB и интеграцией в Active Directory. Кластер PostgreSQL с миллионом транзакций в сутки требует SAN или локальных NVMe с репликацией, потому что каждая транзакция ждёт подтверждения записи на диск. Тестовому серверу хватает DAS.
Схемы не исключают друг друга: NAS часто ставят рядом с SAN под бэкапы и архивы, чтобы не занимать дорогое блочное хранилище копиями. Разбор бюджетов и домашних сценариев для NAS, DAS и собственного сервера собран в отдельном сравнении трёх подходов.
Файловые системы NAS: ZFS, Btrfs, ext4 и XFS
Файловая система определяет, что NAS умеет без стороннего ПО: снапшоты, контрольные суммы, сжатие, репликацию. Ниже четыре распространённых варианта и их ограничения.
ZFS: возможности и требования
ZFS объединяет менеджер томов и файловую систему. Пул (zpool) собирается из vdev: одиночных дисков, зеркал или RAID-Z1, Z2, Z3. Внутри пула создаются датасеты с собственными квотами, правами, сжатием, снапшотами и клонами.
Что даёт ZFS:
- Контрольные суммы для каждого блока. При чтении ZFS сверяет хэш и, если есть избыточность (зеркало или RAID-Z), восстанавливает повреждённый блок автоматически. Это и есть self-healing.
- Copy-on-Write: новые данные пишутся в свободные блоки, поэтому после сбоя питания нет «грязной» ФС и долгой проверки при монтировании.
- Снапшоты и клоны на уровне датасета. Снапшот занимает место только под изменения, снятие занимает секунды.
- Скруб - плановая проверка всех блоков; типичный ориентир - раз в месяц.
- Отправка снапшотов на другой хост (zfs send и zfs receive) для репликации.
Требования. ARC-кэш живёт в оперативной памяти, поэтому на практике минимум 8 ГБ, комфортно от 16 ГБ; ориентир «1 ГБ RAM на 1 ТБ пула плюс запас» остаётся разумным. ECC-память желательна: она снижает риск повреждения данных в кэше, но не заменяет контрольные суммы. Дедупликация требует таблицы DDT в памяти, то есть нескольких гигабайт RAM на каждый терабайт данных, поэтому включать её стоит точечно.
Ограничения. vdev из RAID-Z нельзя расширить заменой одного диска на больший: пул вырастет только после замены всех дисков в этом vdev. Исторически пул расширяли добавлением новых vdev, а в свежих версиях OpenZFS появилось расширение RAID-Z на один диск за раз. SLOG (быстрый SSD под ZIL) ускоряет синхронную запись, L2ARC расширяет кэш чтения, но ни то, ни другое не заменяет RAM.
Пример для домашнего NAS: 6 дисков по 8 ТБ в RAID-Z2, 16 ГБ RAM, отдельный SSD под систему. Такая конфигурация даёт около 32 ТБ полезной ёмкости и переживает отказ двух дисков. TrueNAS строит всю работу на ZFS: пулы, датасеты, снапшоты и репликация доступны из веб-интерфейса без консоли.
Btrfs, ext4, XFS: альтернативы для NAS
Btrfs поддерживает CoW, снапшоты, субтома и встроенный RAID, но RAID5 и RAID6 для продакшена не рекомендуют из-за проблемы write hole: при сбое питания паритет и данные могут разойтись. Надёжные режимы - одиночный диск, RAID1 и RAID10. В готовых NAS Btrfs часто работает как слой снапшотов поверх mdraid.
ext4 - простой и предсказуемый вариант: журналирование, стабильность, огромная база документации. Снапшотов и контрольных сумм данных нет, целостность проверяет только журнал метаданных.
XFS хорошо держит большие файлы и параллельный доступ, умеет онлайн-дефрагментацию, но снапшоты в ней появляются только через LVM.
Практический вывод: для данных, где важны проверка целостности и снапшоты, берите ZFS; для простых задач и старого железа хватит ext4 или XFS; Btrfs уместна там, где нужны снапшоты и есть вендорский слой управления.
| ФС | CoW | Снапшоты | Контрольные суммы данных | RAID | Требования к RAM |
|---|---|---|---|---|---|
| ZFS | Да | Да | Да, с самовосстановлением | RAID-Z1/Z2/Z3, зеркала | 8-16 ГБ и выше |
| Btrfs | Да | Да | Да | RAID0/1/10, RAID5/6 не рекомендуют | Умеренные |
| ext4 | Нет | Через LVM | Нет | Через mdraid или LVM | Низкие |
| XFS | Нет, есть reflink | Через LVM | Нет | Через mdraid или LVM | Низкие |
NFS и SMB/CIFS: сравнение сетевых протоколов доступа
Протокол определяет, какие клиенты подключатся, как устроены аутентификация и блокировки файлов, сколько накладных расходов добавит сеть.
NFS: версии, особенности, настройка
NFSv3 не хранит состояние: сервер не отслеживает открытые файлы, аутентификация строится на UID и GID с доверием к клиенту, для согласования портов нужен rpcbind. Простая и быстрая в Linux-среде, но слабая по безопасности и блокировкам.
NFSv4 работает через один TCP-порт 2049, поддерживает состояние, делегирование, POSIX ACL и Kerberos. Режимы безопасности задаёт параметр sec: krb5 даёт аутентификацию, krb5i добавляет проверку целостности, krb5p шифрует трафик. В версиях 4.1 и 4.2 доступны pNFS и серверные копирования файлов.
Настройка на сервере начинается с файла /etc/exports, строка выглядит так: /srv/nfs 192.168.1.0/24(rw,sync,no_subtree_check). После правки выполняется exportfs -ra, проверка - exportfs -v или showmount -e. На клиенте ресурс подключают командой mount -t nfs 192.168.1.10:/srv/nfs /mnt. Опция sync надёжнее, потому что запись подтверждается после попадания на диск, async быстрее, но при сбое возможна потеря последних записей. Для ускорения применяют nconnect, то есть несколько TCP-соединений к одному серверу, и увеличенные значения rsize и wsize.
SMB/CIFS: версии, особенности, настройка
SMB - протокол Windows, в Linux его роль играет Samba. Версия SMB 2.1 появилась в Windows 7 и Windows Server 2008 R2, SMB 3.0 - в Windows 8 и Server 2012, SMB 3.1.1 - в Windows 10 и Server 2016. В SMB 3 добавили шифрование, multichannel (объединение нескольких сетевых путей), SMB Direct по RDMA и непрерывную доступность для кластеров. SMB1 держат выключенным: он уязвим и лишён современных механизмов защиты.
Настройка Samba идёт через секции в smb.conf. Пример общего каталога: секция [public], path = /srv/samba/public, browseable = yes, read only = no, guest ok = no, valid users = @smbusers. Пользователи заводятся через smbpasswd или pdbedit, конфигурация проверяется утилитой testparm, службы перезапускаются командой systemctl restart smbd nmbd. Для работы с Windows полезна интеграция с Active Directory через winbind или sssd и корректные ACL, иначе права будут расходиться с ожиданиями пользователей.
Сравнение iSCSI, NFSv4 и SMB3 по задачам, а также настройка target и initiator в Linux, экспортов, CHAP, ACL и multipath разобраны в руководстве по сетевым протоколам для систем хранения.
Критерии выбора между NFS и SMB
- NFS: клиенты Linux и Unix, бэкенды Kubernetes, много мелких файлов, отсутствие Active Directory, необходимость POSIX-прав.
- SMB: клиенты Windows и macOS, общие папки для сотрудников, интеграция с Active Directory и групповыми политиками, теневые копии, офисные приложения с блокировками файлов.
Смешанная среда - обычное дело: серверы и системы сборки ходят по NFS, сотрудники открывают те же данные по SMB. TrueNAS и большинство готовых устройств публикуют оба протокола одновременно. Учитывайте блокировки: механизмы SMB и NFS не согласуются между собой автоматически, поэтому одновременная запись одного файла по двум протоколам ведёт к конфликтам и потере данных. Надёжный вариант - разводить данные по разным датасетам или оставлять запись только одному протоколу.
Ограничения NAS и способы их обойти
NAS не масштабируется бесконечно и не заменяет блочное хранилище для любой нагрузки. Основные ограничения: пропускная способность сети, задержки на мелких операциях, единая точка отказа и слабая поддержка кластеризации у готовых устройств.
Производительность и масштабирование
Один гигабитный канал даёт около 110-118 МБ/с, 10 GbE - примерно 1,1 ГБ/с, 25 GbE - около 2,8 ГБ/с. Это потолок для одного соединения, и он часто упирается в сеть раньше, чем в диски.
Агрегация каналов (LACP) повышает суммарную пропускную способность, но отдельный поток по-прежнему ограничен скоростью одного линка: распределение идёт по хэшу. Чтобы задействовать несколько путей, нужны SMB multichannel или NFS с nconnect.
Ускоряют работу SSD-кэш чтения, отдельный быстрый SSD под синхронную запись (SLOG в ZFS), больше RAM под кэш и переход на 10, 25 или 40 GbE. Масштабирование бывает вертикальным (больше дисков и памяти) и горизонтальным (несколько NAS с репликацией или распределённая ФС). Готовые устройства редко поддерживают кластеризацию, поэтому горизонтальный рост строят на репликации, а не на одном большом пуле.
Отказоустойчивость и резервное копирование
RAID защищает от отказа диска, но не спасает от случайного удаления, шифровальщика или сбоя самого NAS. Пока сервер хранения недоступен, файлы недоступны всем клиентам: это и есть единая точка отказа.
Рабочий набор мер: снапшоты по расписанию (например, каждый час с хранением за неделю и ежедневные за месяц), репликация на второй NAS через rsync или zfs send, копия на ленту или в облако, регулярная проверка восстановления. Ориентир - правило 3-2-1: три копии данных, две разные среды хранения, одна копия вне площадки.
Перед переносом нагруженной СУБД на NAS проверяйте производительность на реальном профиле запросов. Если приложение делает много синхронных записей, файловый доступ по сети почти всегда проигрывает блочному.
Выбор дисков под NAS, ресурс TBW и поведение кэша подробно разобраны в материале о жизненном цикле данных в серверных системах.
Готовый NAS или TrueNAS: критерии выбора
Решение сводится к компромиссу: время администратора против денег и гибкости.
Плюсы и минусы готовых решений
Готовые NAS от Synology, QNAP и других вендоров дают веб-интерфейс, мастер первоначальной настройки, магазин приложений с медиасервером и клиентом резервного копирования, техподдержку и гарантию на устройство целиком. Минусы: закрытая аппаратная часть, ограничения на установку произвольного ПО, проприетарные дисковые полки и цена выше, чем у сборки с теми же характеристиками. Для команды без выделенного администратора это обычно оправданно.
TrueNAS: возможности и требования
TrueNAS Community Edition - бесплатная операционная система для собственного сервера. Ветка CORE построена на FreeBSD, SCALE - на Linux. Обе работают с ZFS: пулы, датасеты, снапшоты, репликация, шифрование, квоты. В SCALE приложения запускаются в Docker-контейнерах, виртуальные машины - на KVM.
Требования: 64-битный процессор, минимум 8 ГБ RAM (для ZFS комфортнее 16 ГБ и больше), отдельный SSD или DOM под систему, сетевые карты с нормальными драйверами. Для серверного класса типична платформа Supermicro с 32 ГБ RAM и шестью дисками.
Плюсы: бесплатная лицензия, полный контроль над железом, ZFS, широкий набор функций, активное сообщество, отсутствие привязки к вендору. Минусы: сборка и настройка своими силами, диагностика на вас, официальная поддержка только в платной версии Enterprise.
Критерии простые. Нужны гарантия, поддержка и минимальное время на запуск - берите готовое устройство. Есть опыт в Linux и FreeBSD, желание контролировать железо и ограниченный бюджет - собирайте TrueNAS. Для офиса из 10 человек экономия времени часто перевешивает разницу в цене железа, а для специалиста с опытом сборка выгоднее. Сравнение интерфейсов, производительности и конфигураций под бюджет собрано в материале Synology, QNAP или TrueNAS. Пошаговая настройка доступа к данным в CORE и SCALE описана в руководстве по SMB, NFS и FTP.
Практические сценарии использования NAS в инфраструктуре
Сценарий 1. Файловый сервер офиса. Протокол SMB 3.1.1, интеграция с Active Directory, квоты на пользователя, снапшоты каждые два часа, сеть 1 GbE для 20-50 человек. Файловая система - ZFS или Btrfs, если NAS готовый.
Сценарий 2. Бэкапы серверов и рабочих станций. Источники выгружают данные по NFS или через rsync, restic и borg на отдельный датасет, далее репликация на второй NAS и копия в облако. Приоритет - ёмкость, а не IOPS, поэтому ставят диски большого объёма.
Сценарий 3. Медиахранилище для монтажа. NFS или SMB, 10 GbE до рабочей станции, SSD-кэш, последовательное чтение. Критична пропускная способность, а не задержка на мелких операциях.
Сценарий 4. Хранилище для Kubernetes. Динамический провижионер по NFS, режим доступа ReadWriteMany для томов, которые читают несколько подов, отдельный датасет и квоты на namespace. Там, где нужна проверка подлинности, используют NFSv4 с Kerberos.
Сценарий 5. Домашний NAS. SMB для файлов с ноутбуков и телевизора, DLNA для медиатеки, ежедневные снапшоты, репликация важных каталогов в облако. NFS уместен, если в домашней лаборатории есть Linux-хосты и виртуальные машины.
Во всех случаях NAS работает рядом с SAN и локальными NVMe: дорогое блочное хранилище оставляют под базы данных и виртуальные машины, а файловые сервисы, бэкапы и архивы переносят на сетевое хранилище с ZFS.