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

Любые серьёзные изменения инфраструктуры начинаются с одного вопроса: что именно у нас есть сейчас?

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

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

Документация существует, но её актуальность вызывает вопросы. В одном документе устройство называется одним образом, в другом — другим, а на самой стойке используется третье обозначение. В таблице порт отмечен как свободный, хотя в него включён рабочий линк. На схеме uplink уходит в один коммутатор, а LLDP показывает другой. Какие-то подключения давно не используются, но продолжают числиться в документации. Какие-то, наоборот, работают много месяцев и нигде не описаны.

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

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

В качестве основы для такой модели мы выбрали NetBox.

Построение модели инфраструктуры

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

По мере наполнения NetBox начинал работать не просто как система учёта оборудования, а как единая модель инфраструктуры. У каждого устройства появлялся контекст: площадка, стойка, позиция, интерфейсы, адресация и связи с другими объектами.

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

Но главным эффектом стало даже не построение самой модели, а возможность проверить качество существующей документации.

Импорт данных как проверка документации

Часть данных мы вносили вручную — например, площадки, помещения или типы стоек. Но вручную создавать сотни устройств, интерфейсов и соединений было бы слишком долго и ненадёжно.

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

Очень быстро стало понятно, что основная ценность импорта заключается не в переносе данных в NetBox, а в проверке их качества. Любое несоответствие между устройствами, интерфейсами, подключениями и их описанием сразу становилось заметным. Мы проверяли не только наличие обязательных полей, но и простые, на первый взгляд, вещи: совпадает ли имя устройства с принятой схемой именования, существует ли такой интерфейс у выбранной модели, не занят ли порт другим подключением, есть ли стойка и позиция, куда предлагается поставить оборудование. Например, если в таблице указан Eth1/24, а на устройстве такого интерфейса нет, это сигнал, что подключение описано неверно или относится к другому устройству.

По мере наполнения NetBox начал работать не просто как база устройств, а как навигация по инфраструктуре. У каждого устройства появилась карточка с рабочим контекстом: площадкой, стойкой, позицией, ролью, IP-адресами, интерфейсами, портами питания, контактами, журналом изменений и связанными объектами.

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

Для переезда такого описания недостаточно. В NetBox подключение привязывается к конкретным устройствам и интерфейсам. Такая формализация быстро отделяет подтверждённые данные от предположений и позволяет понимать, что именно необходимо восстановить после переноса.

Сначала мы загружали только то, в чём были уверены. Затем отдельно разбирали спорные подключения. Где-то помогали выгрузки с коммутаторов и LLDP/CDP, а в некоторых случаях приходилось идти в зал и проверять коммутацию физически.

Карта портов: чтобы ночью не искать нужную строку в таблице

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

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

Во время ночных работ это оказалось гораздо удобнее обычных таблиц. Инженеру не нужно было искать нужный интерфейс среди десятков строк или сверяться с несколькими документами одновременно. Достаточно было открыть устройство и сразу увидеть текущее состояние подключений.

Фактически карта портов стала рабочим чек-листом переезда. После выполнения задачи статус обновлялся, и остальные участники проекта сразу видели актуальное состояние.

Как это выглядело в день переезда

Перед началом работ команда открывала список устройств, участвующих в переносе. Для каждого объекта было видно:

• где он находится сейчас; 

• куда должен быть установлен после переезда; 

• какие подключения нужно отключить и восстановить; 

• какие интерфейсы уже проверены. 

Во время самого переноса данные обновлялись не «потом, когда появится время», а прямо по ходу работ. Это оказалось критически важным.

Если откладывать актуализацию документации на конец проекта, часть изменений почти гарантированно потеряется — особенно когда переезд идёт ночью, в несколько волн и с участием разных инженеров.

После установки оборудования проверялись подключения, доступность сервисов и соответствие плану. Если что-то отличалось от ожидаемого состояния, это фиксировалось сразу.

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

Не стоит идеализировать

Сам по себе NetBox не решает проблему.

Если загрузить в него мусорные данные, получится просто хорошо структурированный мусор. А если не договориться о правилах ведения актуализации инфраструктуры, через некоторое время система снова начнёт зарастать дубликатами, устаревшими объектами и несогласованными именами.

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

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

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

Для таких сценариев мы используем уже собственный продукт, который позволяет формировать цифровое представление физической инфраструктуры в 2d и 3d-визуализации и сопровождать её на протяжении всего жизненного цикла.

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