NAS на серверной материнской плате: когда собирать самому, а когда брать готовый файловый сервер

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

Сначала определяем роль NAS: файловая помойка, архив или часть инфраструктуры

Главная ошибка при выборе NAS — начинать с корпуса, количества дисков или красивой фразы «поставим RAID». Для IT-руководителя важнее другое: какую роль хранилище будет играть в инфраструктуре.

Есть минимум четыре разных сценария:

Офисный файловый сервер: общие папки, документы, сканы, проекты, права доступа по отделам, работа по SMB/NFS.
Архив и резервные копии: хранение копий с рабочих станций, серверов, виртуальных машин, баз, камер. Нагрузка чаще последовательная, но важна ёмкость и надёжность схемы.
Хранилище для виртуализации: Datastore для гипервизора, образы ВМ, снапшоты. Здесь уже критичны задержки, IOPS, сеть и контроллеры.
Смешанный сервер: NAS плюс лёгкие сервисы — контроллер домена, бухгалтерские выгрузки, тестовые ВМ, иногда контейнеры.

Если NAS будет просто держать документы на 20–30 пользователей, требования одни. Если на него планируют складывать резервные копии сервера для 1С, архив видеонаблюдения и образы виртуальных машин — это уже другой класс решения. И здесь серверная материнская плата имеет смысл: больше линий PCIe, больше памяти, поддержка серверных CPU, нормальная работа с несколькими сетевыми адаптерами и HBA-контроллерами.

Но это не значит, что любой NAS нужно собирать на «максимальном серверном железе». Иногда компактный готовый сетевой накопитель или облачное хранилище для части документов окажется проще в администрировании. Например, облачные диски вроде Yandex 360 Disk for business удобны для совместной работы с офисными файлами, но не заменяют локальный NAS там, где нужны большие объёмы, локальная скорость, интеграция с бэкапами или хранение видеопотоков.

Самосбор на серверной плате: где он оправдан, а где превращается в долгую поддержку

Самостоятельная сборка NAS на серверной материнской плате хороша не потому, что «дешевле». Иногда дешевле, иногда нет — зависит от состава, наличия комплектующих, требований к дискам, сети и резервированию. Сильная сторона самосбора — контроль над архитектурой.

Самосбор обычно оправдан, если:

нужно больше дисков, чем дают типовые младшие NAS;
требуется HBA-контроллер под SAS/SATA-диски;
нужна 10GbE-сеть или несколько сетевых портов;
планируется ZFS, TrueNAS, Linux-based NAS или связка с Proxmox;
есть штатный специалист, который понимает RAID/ZFS, SMART, бэкапы и восстановление;
NAS будет не только файловым сервером, но и частью сервера виртуализации.

Серверная материнская плата в таком сценарии даёт запас по слотам PCIe, памяти и CPU. Например, можно поставить отдельный HBA для дисковой корзины, сетевую карту 10GbE и оставить место под дальнейшее расширение. На обычной офисной плате это часто заканчивается компромиссами: не хватает линий, слоты делят пропускную способность, корпус не рассчитан на охлаждение дисков, а питание подобрано «по остаточному принципу».

Но самосбор требует дисциплины. Нужно заранее выбрать файловую систему, схему дисков, контроллер, корпус, охлаждение, блок питания, ИБП, стратегию бэкапа и мониторинг. Если этого нет, самосбор превращается в сервер, который «вроде работает», пока не случается первый отказ диска или сбой питания.

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

Четыре критерия выбора: диски, память, сеть и сценарий отказа

Чтобы не спорить в абстракциях «собрать или купить», лучше пройти по четырём критериям. Они быстро показывают, какой класс NAS нужен.

1. Диски и схема хранения

Для NAS важны не только объём и количество дисков, но и модель отказа. RAID1, RAID10, RAID5/6, ZFS mirror, RAIDZ1/2 — это разные подходы с разной ценой восстановления, производительностью и рисками.

Ориентиры простые:

2 диска — минимальный зеркальный NAS для малого объёма, но почти без гибкости.
4 диска — популярная база для RAID10 или RAIDZ-пула, уже можно получить разумный баланс ёмкости и отказоустойчивости.
6–8 дисков — уровень, где важны корпус, охлаждение, HBA и нормальный мониторинг.
10+ дисков — это уже не «коробка под столом», а серверная задача: питание, вибрации, airflow, корзины, контроллеры, место в стойке.

RAID не является резервной копией. Он помогает пережить отказ диска, но не спасает от удаления файлов, шифровальщика, ошибки администратора или пожара.

2. Оперативная память

Для обычного SMB-хранилища памяти нужно меньше, чем для сервера виртуализации. Но если используется ZFS, дедупликация, снапшоты, кэширование или параллельно крутятся ВМ, требования растут. ECC-память желательна для серьёзного файлового сервера, особенно если данные критичны, но решение зависит от бюджета и риска, который компания готова принять.

3. Сеть

Гигабитная сеть быстро становится бутылочным горлышком. Теоретически 1GbE даёт около 125 МБ/с до накладных расходов. Один современный HDD при последовательном чтении может быть сопоставим с этим уровнем, а массив из нескольких дисков — тем более. Если с NAS одновременно работают дизайнеры, инженеры, бухгалтерия и система бэкапов, стоит рассматривать 2.5GbE, 10GbE или агрегацию каналов — но только если коммутатор и клиенты это поддерживают.

4. Поведение при отказе

Нужно заранее ответить на неприятные вопросы:

сколько часов бизнес может жить без файлового сервера;
кто меняет диск и проверяет восстановление массива;
где лежат резервные копии;
есть ли ИБП и корректное завершение работы;
кто получает уведомления о SMART-ошибках, перегреве и падении пула.

Если на эти вопросы нет ответов, выбор материнской платы пока вторичен.

Практический пример: NAS для офиса на 35 пользователей, 1С и резервных копий

Возьмём реалистичный сценарий. Компания на 35 сотрудников: бухгалтерия, отдел продаж, склад, руководители. Есть сервер для 1С, несколько рабочих папок, сканы документов, архивы договоров и ежедневные резервные копии. Часть пользователей работает с крупными PDF и таблицами, но без тяжёлого видеомонтажа.

Что нужно оценить перед конфигурацией:

текущий объём данных: допустим, около 6 ТБ;
прирост: порядка 1–1,5 ТБ в год;
срок планирования: 3 года;
резерв под снапшоты и бэкапы: хотя бы 30–50% сверху;
допустимое окно восстановления: например, несколько часов, а не несколько дней.

Упрощённый расчёт по ёмкости:

6 ТБ текущих данных
+ 4,5 ТБ прироста за 3 года
+ запас под снапшоты/служебные данные/ошибку оценки
= ориентировочно 14–16 ТБ полезной ёмкости

Под такой сценарий можно рассматривать NAS на 4–6 дисках. Например, 4 диска по 12 ТБ в RAID10 дадут около 24 ТБ сырого объёма и примерно половину полезной ёмкости до форматирования и служебных накладных расходов. 6 дисков позволяют гибче подойти к RAIDZ2/RAID6-сценариям, но увеличивают требования к корпусу, контроллеру, охлаждению и бюджету.

По платформе разумный минимум для такого NAS:

серверная материнская плата с запасом по SATA/PCIe или возможностью поставить HBA;
CPU без гонки за максимальной частотой, но с достаточным числом ядер для файловых служб, снапшотов и фоновых задач;
32–64 ГБ RAM в зависимости от файловой системы и дополнительных сервисов;
2.5GbE или 10GbE, если пользователи активно работают с крупными файлами или бэкапы идут в рабочее время;
отдельный SSD под систему, чтобы не смешивать ОС и массив данных;
ИБП и уведомления о состоянии дисков.

Если этот же NAS хотят использовать как сервер виртуализации, требования меняются. Документация Proxmox VE и обзор Microsoft Hyper-V прямо показывают: гипервизор — это отдельный слой нагрузки, где важны CPU, RAM, дисковая подсистема и сеть. В таком случае NAS лучше проектировать не как «папку с файлами», а как инфраструктурный узел. Иногда правильнее разделить роли: отдельный сервер для 1С, отдельное хранилище, отдельный GPU сервер под локальные ИИ-задачи или расчёты. Смешивать всё в одной коробке можно, но только после расчёта рисков.

Где готовый NAS лучше самосбора, а где наоборот

Нет универсального ответа. Для IT-руководителя правильный выбор — тот, который снижает операционные риски именно в вашей компании.

Готовый файловый сервер чаще лучше, если

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

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

Самосбор чаще оправдан, если

есть опытный администратор или интегратор;
нужны нестандартные дисковые схемы;
планируется ZFS, Proxmox, отдельные HBA, 10/25GbE;
есть требования к шуму, форм-фактору, стойке, корзинам или расширению;
компания готова самостоятельно вести документацию, мониторинг и восстановление.

Когда NAS на серверной плате может не подойти

Есть сценарии, где локальный сервер — не лучший первый шаг:

команда полностью распределённая, работает только с офисными документами и не хранит большие локальные архивы;
объём данных мал, а требования к совместной работе важнее локальной скорости;
нет помещения, ИБП, вентиляции и ответственного за обслуживание;
бизнесу нужен не NAS, а полноценная рабочая станция для инженера, сервер для 1С с быстрым дисковым контуром или GPU сервер под вычисления.

Последний пункт встречается чаще, чем кажется. Иногда запрос звучит как «нам нужен NAS», а после интервью выясняется, что проблема в медленной базе 1С, нехватке RAM на сервере виртуализации или в том, что пользователи открывают тяжёлые проекты по гигабитной сети. Хранилище в этом случае поможет только частично.

Чек-лист перед покупкой или сборкой

Перед тем как утверждать бюджет, пройдитесь по списку. Он помогает быстро отделить реальную потребность от желания «взять с запасом».

Данные и пользователи

Сколько сейчас данных в ТБ?
Какой ежемесячный или годовой прирост?
Сколько пользователей работает одновременно?
Какие файлы преобладают: офисные документы, фото, CAD, видео, базы, архивы?
Есть ли требования к правам доступа по отделам?

Производительность

Достаточно ли 1GbE или нужна 2.5/10GbE?
Есть ли коммутатор и клиентские адаптеры под выбранную скорость?
Будут ли с NAS запускаться ВМ или только храниться файлы?
Планируются ли снапшоты, дедупликация, шифрование?

Надёжность и восстановление

Какая схема массива выбрана и почему?
Что произойдёт при отказе одного диска? А двух?
Где хранятся резервные копии вне основного NAS?
Есть ли ИБП и проверка корректного завершения работы?
Кто получает уведомления об ошибках?

Эксплуатация

Кто обновляет ОС и пакеты?
Кто проверяет логи и SMART?
Есть ли запасные диски той же ёмкости или план закупки?
Задокументированы ли IP-адреса, пароли, схема массива, порядок восстановления?
Понятно ли, когда NAS нужно расширять, а не «дожимать до последнего»?

Частые ошибки выглядят приземлённо: поставить NAS без ИБП, выбрать корпус без нормального обдува дисков, смешать систему и данные на одном массиве, купить 10GbE-карту без подходящего коммутатора, рассчитывать RAID как бэкап, не проверять восстановление из копий. Именно эти мелочи потом превращают недорогой проект в дорогой простой.