Как зарезервировать юниты в NetBox под будущий сервер и не перепутать резерв с установленным оборудованием

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

Зачем резервировать юниты отдельно от устройства

Когда я веду внедрение NetBox для компании с серверной или колокейшн-стойкой, рано или поздно возникает вопрос: сервер ещё не куплен, но место под него нужно застолбить прямо сейчас — иначе кто-то другой поставит туда патч-панель или коммутатор. Заводить в DCIM устройство, которого физически нет, — плохая идея: оно попадёт в инвентарные отчёты, отчёты по питанию, автоматизацию мониторинга, и появится путаница, что реально стоит в стойке, а что только планируется.

Для этого в NetBox есть отдельная модель — RackReservation. Это не устройство и не элемент монтажа, а декларация: «эти юниты этой стойки заняты под такую-то задачу». Юниты под ней не заняты ни физически, ни по питанию — они заняты только в системе учёта — и это принципиально другая природа объекта, чем Device.

Из чего состоит RackReservation

Модель RackReservation привязана к конкретной стойке через поле rack — одна резервация всегда относится к одной стойке, распределить один резерв на несколько стоек нельзя. Поле units содержит список юнитов, которые резервируются, и документация NetBox прямо описывает формат: несколько юнитов можно указать через запятую и/или дефис, например 1,3,5-7 означает юниты 1, 3, 5, 6 и 7.

Поле description обязательно — документация формулирует это жёстко: «каждая резервация должна включать описание своего назначения». Без внятного описания резерв превращается в загадку для следующего администратора: юниты заняты, но неясно, зачем и до какого момента. Поле user — обязательное: резерв всегда привязан к учётной записи NetBox (в модели это внешний ключ без пустого значения, и REST API без него запрос не примет). При этом пользователи с достаточными правами могут резервировать место от имени других пользователей — например, инженер может застолбить юниты по заявке менеджера проекта. Резервация также может быть опционально связана с tenant — конкретным арендатором или клиентом, если стойка общая для нескольких проектов.

С версии NetBox 4.4 (релиз 2 сентября 2025 года) у RackReservation появилось ещё одно поле — status (issue #18984). Штатных значений три: pending (ожидает подтверждения), active (по умолчанию) и stale (устаревший резерв); свои статусы можно добавить через параметр FIELD_CHOICES с ключом RackReservation.status. Документация уточняет важный момент: статус резервации не влияет на возможность установки устройства в зарезервированный юнит. Иными словами, status — это метка для людей и отчётов, а не техническое ограничение, которое остановит монтаж.

Резерв не блокирует физическую установку — и это надо знать заранее

Это самый важный практический момент всей статьи. RackReservation — документальный объект. NetBox позволяет установить Device в те же самые юниты, которые уже указаны в резервации: при сохранении устройства проверяется только пересечение с другими устройствами, а резервации в этой проверке не участвуют вообще — ни ошибки, ни предупреждения. Конфликт видно разве что глазами на графической схеме стойки. Я специально проверял это на своих проектах: резерв — это не lock, а метка планирования.

На карточке стойки резервации отображаются на графической схеме (rack elevation) — с версии 3.5.2 (issue #11900) маркеры резервирования получили визуальную обводку (outline), чтобы отличать их от установленных устройств на глаз, а не только по цвету заливки. Это полезно на совещаниях с командой, но не заменяет процесс: если в компании несколько человек имеют права монтажа оборудования, полагаться только на визуальную схему в NetBox рискованно — нужен процесс, при котором монтажник перед установкой сверяется со списком активных резерваций через API или отчёт, а не просто смотрит на элевацию глазами.

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

Как оформить резерв на практике

Через REST API резервация создаётся одним POST-запросом к /api/dcim/rack-reservations/ с обязательными полями rack, units, user и description. Про user часто забывают, потому что в веб-интерфейсе он подставляется формой, а в API его надо передать явно — иначе ответ 400.

curl -s -X POST https://netbox.example.local/api/dcim/rack-reservations/ \
  -H "Authorization: Token $NETBOX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "rack": 12,
    "units": [21, 22, 23, 24],
    "user": 3,
    "description": "Резерв под сервер 1С, проект Q4 2026",
    "tenant": 5
  }'

ID стойки, пользователя и арендатора здесь условные — их нужно взять из списков /api/dcim/racks/, /api/users/users/ и /api/tenancy/tenants/ вашей инсталляции. Описание ограничено 200 символами. Обратите внимание: units в запросе передаётся как список конкретных номеров, даже если человеку в UI удобнее ввести диапазон через дефис — интерфейс сам разворачивает 21-24 в перечисление при сохранении.

Перед созданием резерва полезно свериться с тем, что уже занято. Здесь есть тонкость, на которой я сам однажды споткнулся: JSON-вариант эндпоинта /api/dcim/racks/{id}/elevation/ показывает по каждому юниту, занят ли он устройством, но про резервации ничего не сообщает — они есть только на SVG-картинке. Поэтому в скриптах я проверяю две вещи отдельно: устройства — через elevation или /api/dcim/devices/?rack_id=…, резервации — через /api/dcim/rack-reservations/ с фильтром unit, который находит резервы, содержащие конкретный юнит. Так конфликт ловится автоматически, а не зависит от того, насколько внимательно администратор посмотрел на картинку.

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

Как быстро найти все активные резервации по стойке или проекту

Когда резерваций становится больше десятка, искать конфликты глазами по элевации перестаёт быть надёжным способом. Я обычно строю простой отчёт через тот же REST API: GET-запрос к /api/dcim/rack-reservations/ с параметром rack_id возвращает все резервации конкретной стойки, а с параметром tenant_id — все резервации конкретного арендатора или внутреннего проекта, если в компании заведена тенантность на уровне отделов или клиентов.

curl -s "https://netbox.example.local/api/dcim/rack-reservations/?rack_id=12&status=active&unit=21" \
  -H "Authorization: Token $NETBOX_TOKEN" | python3 -m json.tool

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

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

Кейс: двойное бронирование стойки у «Свободная строка»

Условный клиент — самиздат-лаборатория «Свободная строка», 24 рабочих места, с небольшой серверной на несколько стоек для печатного оборудования, файлового хранилища и внутренних сервисов. Два внутренних проекта — обновление системы вёрстки и расширение хранилища для архива макетов — независимо друг от друга рассчитывали на одно и то же свободное место в третьей стойке: юниты 18–21. Информация о планах жила в двух разных Excel-файлах у двух руководителей проектов — ровно тот случай, из-за которого я обычно и начинаю документацию инфраструктуры в NetBox, — а в NetBox тогда вели только карточки уже установленных устройств, резервированием никто не пользовался.

Конфликт обнаружился в день монтажа: инженер приехал ставить новый файловый сервер архива и обнаружил, что юниты 18–21 заняты сервером растеризации для новой системы вёрстки, который поставили неделей раньше без предупреждения. Оборудование пришлось на ходу переставлять в соседнюю стойку, менять патч-корды и переносить окно работ на два дня — не критично, но неприятно и совершенно избежимо.

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

Частые ошибки при использовании резерваций

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

Вторая ошибка — использовать RackReservation не по назначению, для документирования постоянных, не занятых устройствами элементов: кабель-каналов, полок, заглушек. В обсуждении на GitHub с этим столкнулось сообщество: предложение использовать резервации для учёта «мебели стойки» вызвало возражение автора обсуждения: по его словам, для подсчёта заполненности это сработает, но путает, когда нужно действительно что-то зарезервировать, когда им действительно нужно что-то зарезервировать, а часть юнитов уже занята искусственными «резервами» постоянных элементов. Участники обсуждения в итоге советуют заводить полки и органайзеры как устройства со своей ролью — так делаю и я.

Третья ошибка — оставлять резервации бессрочными без пересмотра. Резерв без даты и без регулярной сверки со временем превращается в мусор: место формально занято, но никто не помнит зачем, и в итоге администратор либо боится освободить действительно свободные юниты, либо — что хуже — игнорирует все резервации разом, потому что «они всё равно не актуальны». Я привязываю к каждой резервации срок и раз в квартал прохожусь по списку активных RackReservation, закрывая те, что уже стали устройствами или отменённым проектом — тот же регулярный пересмотр я закладываю и в резервирование сервисов кластера 1С: резерв без даты пересмотра рано или поздно перестаёт отражать реальность независимо от того, о какой системе идёт речь.

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