Несколько корпусов в одном кампусе: что заводить в NetBox как Site, а что как Location

У вас кампус из нескольких корпусов, и первый вопрос при внедрении NetBox — что здесь Site, а что Location. Ответ важен: Site, Rack и Device в NetBox не рекурсивны, и переигрывать это решение потом дорого. Разбираю модель Region/SiteGroup/Site/Location и показываю, как я развёл кампус компьютерной школы на 9 рабочих мест.

Почему этот выбор нельзя делать «на глазок»

Вопрос звучит просто: два корпуса, один кампус — заводить их как два Site или как один Site с двумя Location внутри? На практике это первое решение, которое я фиксирую в самом начале, когда берём внедрение NetBox для клиента с распределённой площадкой, — потому что от него зависит вся дальнейшая структура: к какому объекту привязывать стойки, как фильтровать устройства по зданию, как потом строить отчёты по кампусу целиком.

Цена ошибки не в том, что «неправильно» — сама модель NetBox не запрещает ни один из вариантов. Цена в объёме переделки: Site — не рекурсивная сущность, то есть вы не можете сделать один Site дочерним по отношению к другому. Если сначала завести оба корпуса как отдельные Site, а потом понять, что для отчётов и фильтров удобнее видеть их одним кампусом, слить их штатно нельзя — придётся переносить на новый Site и Location всё, что к старому привязано: стойки, устройства, а заодно префиксы и VLAN, если их scope указывает на Site. Массовое редактирование в интерфейсе NetBox облегчает перенос, но это всё равно миграция с проверкой каждой связи, а не одна кнопка. Проще один раз разобраться в модели, чем потом разгребать миграцию на живой инфраструктуре.

Четыре уровня иерархии площадок в NetBox: Region, SiteGroup, Site, Location

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

Site — центральная сущность, к которой физически привязывается инфраструктура: по документации сайт обычно соответствует зданию или кампусу целиком, классический пример из документации — сеть банковских отделений, где Site заводится на каждый филиал, головной офис и колокейшн. Ключевое отличие от Region и SiteGroup — Site не рекурсивен: вы не можете сделать один Site вложенным в другой. Все объекты внутри площадки — стойки, устройства — привязываются именно к Site, напрямую или через Location.

Location — вложенная сущность внутри Site, и по документации это именно тот уровень, где рекурсия возвращается: локация может представлять этаж, комнату, серверную клетку, и локации можно вкладывать друг в друга — например, этаж, а внутри него комната. Формально: у одного Site может быть множество Location, у Location может быть родительская Location того же Site, и так угодно глубоко — в отличие от Site, у Location такое ограничение снято.

Главное правило из практики сообщества: сначала решите, что такое Site

На GitHub есть предметное обсуждение ровно этой ситуации — учреждение с несколькими кампусами, зданиями, этажами, серверными и стойками, и вопрос «как всё это разложить по Region/SiteGroup/Site/Location». Ответ, который там дали, сводится к одному тезису: важнее всего решить, что именно в вашем случае будет считаться Site, потому что именно Site, Rack и Device не определены рекурсивно — это тот уровень, ошибка на котором стоит дороже всего остальных. Там же прозвучал аргумент, который я разделяю: удобно, когда Site совпадает с «локальной сетью кампуса», потому что VLAN и префиксы в NetBox естественно привязываются именно к Site. Привязать их к Location или Region тоже можно, но при смешанной схеме, когда часть VLAN висит на Site, а часть на Location, автор ответа предупреждает о возможных сложностях.

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

Второе наблюдение из обсуждения касается SiteGroup: в отличие от Region, у которого понятное географическое назначение, практическая польза SiteGroup для типового случая «одно учреждение, несколько кампусов» не так очевидна — это скорее инструмент для случаев, когда площадки нужно группировать по функции или принадлежности, а не по территории. Для одной компании с несколькими корпусами SiteGroup чаще всего просто не нужен, и не стоит заводить его только потому, что поле существует в форме.

Как я развёл кампус компьютерной школы «Класс с нуля»

«Класс с нуля» — компьютерная школа, 9 рабочих мест, где мы документируем инфраструктуру в NetBox вместо списка на бумаге у администратора. Два здания через двор: основной корпус с классами и ресепшеном и малый корпус, переоборудованный из бывшей квартиры на первом этаже соседнего дома, для младших групп. Формально это два разных адреса, разные входы, но для родителей, вывески и самой компании это один кампус — и коллеги сначала завели оба здания как два отдельных Site, по числу физических адресов.

Я пересобрал схему в один Site «Класс с нуля — кампус» с двумя Location верхнего уровня: «Основной корпус» и «Малый корпус». Внутри «Основного корпуса» — ещё одна Location «Серверная ниша» для коммутатора и роутера, а внутри «Малого корпуса» отдельная Location не понадобилась — там всего один шкаф с оборудованием на стене. То, что раньше было два Site с независимыми списками устройств, стало одним Site с понятной вложенностью, и фильтр «все устройства кампуса» в NetBox теперь просто фильтр по одному Site, а не объединение двух.

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

Стойки и устройства без стойки: Rack и Device на уровне Location

У «Класс с нуля» полноценной серверной стойки нет — в основном корпусе оборудование стоит в невысокой открытой нише: настроенный под учебную сеть MikroTik, коммутатор на 24 порта, точки доступа хранятся там же на полке, а не смонтированы в стойку. Стойку ради такой ниши я заводить не стал. По документации Rack обязательно привязан к Site, а привязка к Location или к группе стоек — необязательна; но раз стойки нет, оборудование ниши у нас привязано напрямую к Location «Серверная ниша», и это даёт удобный фильтр «оборудование основного корпуса» отдельно от малого.

Отдельно стоит учитывать, что устройство в NetBox вообще не обязано быть в стойке: документация прямо допускает установку устройства непосредственно на Site или в Location, без Rack — что закрывает как раз случаи вроде настенного коммутатора малого корпуса или точки доступа под потолком, у которых физически нет и не будет юнита в стойке. Для небольших площадок вроде компьютерной школы это не исключение из правил, а типовой сценарий: большая часть сетевого оборудования там вообще не рэковая.

Практический вывод: не пытайтесь заводить фиктивную стойку только ради того, чтобы «правильно» привязать устройство — если оборудования физически нет в стойке, честнее и проще привязать его напрямую к Location. Фиктивная стойка добавляет лишний уровень, который потом придётся объяснять новому инженеру: почему в списке стоек кампуса есть стойка, в которую по факту ничего не смонтировано.

Типичные ошибки при выборе Site и Location

Первая ошибка — заводить Site по числу физических адресов, а не по административной единице, как изначально сделали в «Класс с нуля». Формально это не запрещено, но плодит Site там, где команда всё равно администрирует объекты как одно целое, и потом приходится вручную объединять данные из двух Site в отчётах, вместо того чтобы просто отфильтровать один.

Вторая ошибка — обратная: попытка засунуть в один Site территориально и административно разные площадки только потому, что «это же почти рядом». Пример из документации — сеть банковских отделений: там каждый филиал получает свой Site именно потому, что у него собственный персонал, собственный набор оборудования и собственная зона ответственности, несмотря на то, что географически филиалы могут быть в соседних кварталах. Критерий не расстояние, а то, как компания реально управляет площадкой.

Третья ошибка — использовать Region там, где нужен SiteGroup, и наоборот. Region — про географию (страна, город), SiteGroup — про функциональную принадлежность (бренд, юрлицо, тип площадки). Если завести регион «Филиалы» вместо города, отчёты по географии начнут врать, а если пытаться закодировать в SiteGroup этажность здания — вы просто изобретаете велосипед вместо готовой вложенной Location.

Четвёртая, менее очевидная ошибка — заводить Location по сегментам сети, а не по физическому расположению. Location в NetBox — про географию внутри здания, а не про логику VLAN: если вам нужно отдельно видеть сегментацию учебной сети и бухгалтерии, для этого в NetBox есть отдельные объекты VLAN и Prefix, а не подмена ими иерархии площадок. Смешение этих двух слоёв — частая причина, почему структура Location через год выглядит нелогично и её приходится пересобирать.

Чек-лист: с чего начать разметку кампуса в NetBox

Перед тем как создавать первую площадку, я отвечаю на три вопроса. Первый: администрируется ли территория как одна единица — общий канал связи, общий персонал, общий бюджет — или как несколько независимых филиалов? В первом случае это один Site, во втором — несколько. Второй вопрос: нужна ли вообще географическая иерархия выше Site (город, регион) или функциональная группировка (бренд, юрлицо) — если нужна только одна из них, второй уровень просто не заводится, оставлять пустые Region или SiteGroup «про запас» не нужно.

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

Отдельно я советую клиентам масштаба «Класс с нуля» не откладывать эту разметку до момента, когда оборудования станет много: пересчитать 9 рабочих мест и десяток сетевых устройств по новой иерархии — работа на пару часов, а пересобирать сотню объектов на растущей сети через год-два — совсем другой бюджет времени. То же правило действует независимо от того, обсуждаем ли мы структуру NetBox или вообще объём работ на абонентском обслуживании — порядок в структуре тем дешевле навести, чем раньше это сделано.

• Site — не рекурсивен: два Site нельзя вложить друг в друга, переделка дорогая.
• Region — географическая иерархия выше Site, SiteGroup — функциональная; оба рекурсивные и оба опциональны.
• Location — вложенная сущность внутри Site (этаж, комната, клетка), можно вкладывать произвольно глубоко.
• Rack обязательно привязан к Site, привязка к Location — опциональна.
• Device можно установить прямо на Site или в Location, без Rack — не изобретайте фиктивную стойку.

Частые вопросы