Свободные юниты записаны в таблице стоек. Порты коммутатора — в схеме сети. IP-адреса — в отдельном файле, а нагрузка виртуальных машин живёт в голове администратора. Сервер ещё не заказан, но проверить его размещение уже нельзя без четырёх сверок и пары сообщений коллегам.
NetBox собирает эту картину в одной модели. По ней ты проверишь место в стойке, питание, кабельные соединения, сетевые адреса и виртуальные нагрузки до закупки. Сам процессор или RAID система не подберёт — её задача в другом.
NetBox хранит проектное состояние инфраструктуры
NetBox объединяет IPAM и DCIM: адресное пространство связано с площадками, стойками, устройствами и их компонентами. Получается не складской перечень серверов, а схема связей между физической и логической инфраструктурой.
При этом NetBox не опрашивает коммутаторы и серверы. Он не заменяет мониторинг, систему управления конфигурациями или инвентаризацию по агентам. В нём фиксируют, как инфраструктура должна выглядеть, а фактическое состояние сверяют с этой моделью.
Эта граница определяет пользу продукта. Если нужен список из десяти серверов с серийными номерами, хватит ведомости. Если перед заказом надо доказать, что новый узел поместится, получит два независимых подключения и не займёт чужой адрес, таблица начинает мешать.
Одна запись о сервере связывает стойку, питание и сеть
Модель NetBox ведёт от региона и площадки к помещению, стойке, устройству и его компонентам. В ней также учитывают кабели, беспроводные соединения и распределение питания.
Для закупки цепочка выглядит так:
- площадка и помещение определяют место установки;
- стойка показывает позицию устройства;
- компоненты описывают интерфейсы, блоки питания и отсеки;
- кабели связывают сервер с коммутационной панелью и коммутатором;
- цепи питания показывают подключение к PDU;
- кластер и виртуальные машины объясняют будущую нагрузку.
NetBox хранит выбранное размещение, но не проверяет физическую совместимость оборудования. Глубину корпуса, допустимую нагрузку, резерв по мощности PDU и отвод тепла всё равно придётся рассчитать до заказа. Для этой проверки пригодится разбор о том, как выбрать серверную стойку по глубине, питанию и охлаждению.
Допустим, ты заказываешь двухъюнитовый сервер виртуализации. В NetBox можно заранее зарезервировать позицию в стойке, создать два подключения к разным коммутаторам, указать цепи питания и связать физические интерфейсы с VLAN. Если одного из этих объектов нет, спецификация ещё не готова к согласованию.
IPAM показывает, какие сетевые ресурсы займёт сервер
Адресный план в NetBox строится иерархически: крупные CIDR-блоки делятся на префиксы, а внутри них размещаются диапазоны и отдельные адреса. Система считает занятость и находит свободные дочерние префиксы либо IP-адреса.
Адрес можно связать с физическим интерфейсом сервера или интерфейсом виртуальной машины. Так запись 10.20.4.18 перестаёт быть строкой с комментарием «новый гипервизор»: у неё появляется конкретный порт и конкретное устройство.
VLAN-группы ограничиваются площадкой или кластером. Это защищает от ложного предположения, что VLAN с одинаковым номером означает одну сеть во всех филиалах. VRF, напротив, позволяют учитывать пересекающиеся адресные пространства — например, у нескольких изолированных клиентов.
В результате заявка «нужны четыре адреса для нового сервера» превращается в проверяемую схему: адрес управления, два адреса хостов и адрес миграционной сети; для каждого видны префикс, VLAN, интерфейс и область действия.
API приносит пользу только после наведения порядка в данных
NetBox отдаёт сведения через REST и GraphQL API. Правила событий могут запускать webhook или пользовательский скрипт, а журнал фиксирует создание, изменение и удаление управляемых объектов (netbox.readthedocs.io; github.com).
Это позволяет формировать заявки и конфигурации из эталонных данных. Но API не исправит запись «порт уточнить позже». Автоматизация лишь быстрее разнесёт ошибку по зависимым системам.
Показателен кейс компании из списка Fortune 500 с глобальной сетью. Разрозненные системы и ручные операции создавали информационные разрывы и риски. После переноса документации в NetBox Cloud компания смогла выявлять расхождения конфигураций, связать работу отдельных команд, улучшить управление изменениями и сократить ручные операции.
Кейс не доказывает, что NetBox даст тот же результат в любой инфраструктуре. Он показывает механизм: сначала единая модель, затем проверки и автоматические действия на её основе.
Когда NetBox оправдывает сопровождение
NetBox стоит включить в проект закупки, если одни и те же сотрудники учитывают стойки, серверы, кабели, питание, адреса, VLAN и виртуальные машины. Связи между объектами здесь важнее самих карточек оборудования.
За эту связность придётся платить временем команды. Нужно определить роли, договориться об именовании объектов, настроить проверки и назначить владельцев данных. NetBox поддерживает права пользователей, собственные правила валидации, дополнительные поля и плагины, но не выбирает эти правила за тебя.
Для одного помещения и нескольких автономных серверов это может оказаться лишней системой. Если никто не будет обновлять порт после перекоммутации или освобождать адрес после удаления виртуальной машины, обычная ведомость хотя бы честнее: она не притворяется источником истины.
Разместить NetBox можно самостоятельно: проект открыт под лицензией Apache 2.0, для него опубликованы руководство по установке и Docker-образ сообщества. Альтернатива — облачный NetBox Cloud от NetBox Labs. Выбор здесь зависит не от числа серверов, а от того, кто будет обновлять систему, резервировать её и отвечать за доступность.
Что проверить до закупки и внедрения
Возьми одну будущую поставку и попробуй собрать её модель целиком:
- площадка, помещение и позиция в стойке;
- сервер, его сетевые интерфейсы и блоки питания;
- кабели, порты коммутаторов и цепи питания;
- IP-префиксы, адреса, VLAN и при необходимости VRF;
- кластер и виртуальные машины;
- роли доступа и правила, которые запрещают неполные записи;
- выгрузка нужных данных через REST или GraphQL API.
Если эта цепочка заменяет несколько таблиц и переписку между командами, NetBox закроет понятную задачу. Если тебе нужна только ведомость оборудования, не заводи отдельную платформу ради аккуратных карточек.
Правило для закупки простое: NetBox не отвечает, какой процессор, объём памяти или RAID выбрать. Он отвечает, куда встанет сервер, как подключится, какие сетевые ресурсы займёт и кто согласовал эту схему. Именно эту картину стоит приложить к спецификации до отправки заказа поставщику.
