Привет, Хабр! На связи команда K2 Cloud — ведущий сетевой инженер Сергей Алексеев и инженер-разработчик Александр Гнатюк.
Мы расскажем о нашем пути к инвентаризации и автоматизации огромной сети ЦОД, каких результатов достигли усилиями сетевых инженеров службы эксплуатации и разработки. Надеемся, что этот опыт будет полезен тем, кто хочет автоматизировать свою работу и сделать инфраструктуру прозрачнее.
Как устроена инвентаризация ЦОД
С точки зрения сетевых инженеров, ЦОД — это огромный мир: нужно хранить информацию о тысячах линий связи, большом количестве оборудования, множестве сервисов, физических, виртуальных и других сущностях:
IP-адреса и VLAN в привязке к конкретному клиенту.
Идентификаторы активностей: номера обращений в Service Desk.
Кабельный журнал каждого подключения.
Размещение сервисного сетевого оборудования.
Информация о провайдерах: ASN, стыковочные сети и условия Burst Rate, идентификатор услуги или договора.
Карточка клиента со всеми указанными услугами, ответственными за проект, задействованными VLAN, VRF, номерами договоров и другими данными.
Чтобы эффективно и просто эксплуатировать такую огромную инфраструктуру, нужно вести точный учёт всех сущностей. Без удобной системы инвентаризации это невозможно. Мы решали эту задачу с помощью ряда инструментов:
Netdot. «Записная книжка» для хранения информации об IP-адресах, VLAN и прочих виртуальных сущностях.
Wiki. Другая увесистая «записная книжка» с информацией по проектам и ответственным менеджерам.
NOC. Физическая и логическая инвентаризация. NOC автоматически создаёт резервные копии конфигураций устройств и поддерживает исторические версии для сравнения и отката.
OpenDCIM. Хранение информации о размещении сервисного клиентского оборудования с привязкой к стойкам и с указанием принадлежности.
Все эти разрозненные инструменты с помощью набора ссылок из одной системы в другую объединяла Jira.
Проблемы одновременного использования нескольких инструментов
Итак, вместо единого удобного инструмента у нас был набор разрозненных систем без взаимосвязей, единого интерфейса и сквозного поиска. Вдобавок у каждой системы были существенные недостатки.
NetDot. Нет сводной информации о заказчике, поэтому получить все привязанные к нему сущности сложно. Неудобно хранить информацию о контрактах и ИТ-услугах.
Wiki. Множество несвязанных друг с другом статей. Неудобно обновлять, информация быстро устаревает.
NOC. Хороший, но сложный и перегруженный продукт, с нетривиальным добавлением функциональности. Слабая документация.
OpenDCIM. Отличный инструмент, состоящий из одних достоинств. Однако они не могут перекрыть главной проблемы всех систем — оторванности друг от друга.
Чтобы получить объёмную карточку заказчика и понять, какие сущности к нему относятся, нужно было открыть кучу окон. Никакого сводного отчёта-выгрузки по щелчку пальцев не появлялось. А мы верили в светлое будущее и хотели получить единую систему для инвентаризации физических и виртуальных сущностей.
Формируем требования к новой системе
Нас интересовали следующие ключевые характеристики будущего решения:
Единая карточка заказчика. Договоры, IPAM/DCIM, кабельные журналы и многое другое.
Утилиты по базовой сетевой диагностике для L1/L2. Единый инструмент с функционалом диагностики — это возможность делегировать задачи по управлению ЦОД первой и второй линиям поддержки.
Автоматизация управления сервисами и API.
Поддержка плагинов. Приложение должно поддерживать модульность и возможность добавлять новый функционал без существенного переписывания софта.
Хорошая документация и простая установка.
Наши требования были представлены в виде конкретных метрик для будущего приложения. Мы хотели, чтобы NetBox стал Source of Truth — единой точкой правды.
Дело в том, что есть два принципиально разных подхода к построению инфраструктуры. Первый — обновляемая постфактум записная книжка. Информация в ней может немного отличаться от реального состояния. Второй подход, Source of Truth — единый источник истины. Он хранит актуальные данные об устройствах, IP-адресах, подключениях и виртуальных ресурсах, заменяя ручные таблицы и wiki. Встроенная валидация, API и интеграция с инструментами автоматизации (Ansible, Terraform) исключают ошибки и ускоряют работу.
Выбираем систему
Мы отобрали пять систем: phpIPAM, NOC, Racktables, Nautobot и NetBox.
В финал вышли Nautobot и NetBox. Это похожие продукты с разницей лишь в том, что в Nautobot уже преднастроена автоматизация. В итоге мы выбрали NetBox. В его пользу сыграло то, что это популярный продукт с огромным комьюнити. Вдобавок у нас сильные компетенции в разработке, чтобы кастомизировать NetBox для своих задач.
Что такое NetBox
NetBox — классическая DCIM/IPAM система с открытым кодом. Разработчик Джереми Стретч (Jeremy Stretch) написал её на Python для внутренних нужд провайдера DigitalOcean.
DCIM — это тот же самый IPAM, только для хранения информации об оборудовании. NetBox — система инвентаризации всех физических и виртуальных сущностей ЦОД.
Чем хорош NetBox:
IPAM/DCIM с карточкой клиента.
Сквозная система связей между объектами.
Удобный API и документация.
Поддержка плагинов.
Большое комьюнити с массой положительных отзывов.
Инвентаризация с помощью NetBox
Чтобы собрать все данные в NetBox, мы разбили нашу огромную инфраструктуру на множество информационных систем. С помощью встроенных в NetBox CSV, YAML, JSON загрузили данные и увидели результат.
С помощью NetBox решили следующие задачи:
Полная инвентаризация сервисов и оборудования.
Ведение объемной карточки заказчика.
Автоматизация ряда процессов.
Compliance-тестирование.
Встроенная функциональность NetBox дала нам то, чего давно хотелось.
NetBox как Compliance Auditor
Мы обеспечиваем поддержку всей инфраструктуры облака и должны быть уверены, что наше оборудование настроено и работает правильно.
Важно удостовериться, что включены:
Ограничение PPS для BUM-трафика на соответствующем порту.
Журналирование.
Синхронизация времени с помощью NTP-сервиса.
Ограничение сетевого трафика согласно тарифу (QOS).
Доступ к оборудованию только из закрытого контура (Security ACL).
Нужен внутренний аудитор, который проверит и подтвердит, что оборудование работает, а текущие настройки соответствуют эталонным. Его получили за счёт использования плагина Validity, а точнее, его подмодулей: Serializers и Test.
Как это работает. Когда мы добавляем новое оборудование в NetBox, он отправляет веб-хук в Oxidized — отдельный инструмент резервного копирования конфигурации сетевых устройств.
Oxidized по API перезапрашивает у NetBox список всех устройств, конфигурацию с которых нужно выгрузить: имя, платформа, Management IP. Затем по настроенному расписанию Oxidized подключается по SSH ко всем устройствам из полученной базы и проверяет, изменилась ли конфигурация. Если изменилась, то плагин сохраняет новую конфигурацию в Git отдельным коммитом.
Для работы Validity в NetBox настроена интеграция data sources с Git. Плагин с помощью своего SSH-ключа идёт в Git и синхронизирует все файлы (конфигурации всех девайсов) к себе. Таким образом, у Validity появляется актуальная конфигурация каждого «боевого» сетевого устройства.
Подробное описание работы на GitHub.
NetBox как looking glass
Модуль Scripts в NetBox запускает в веб-интерфейсе наши самописные скрипты через функционал Custom scripts (пользовательские скрипты).
Пользовательские скрипты были введены для предоставления операторам Netbox возможности выполнять произвольную логику из пользовательского интерфейса NetBox. Пользовательские скрипты позволяют оператору напрямую и удобно манипулировать данными NetBox предписанным образом. Пользовательские скрипты — это код Python, который существует вне кодовой базы NetBox, поэтому их можно обновлять и изменять, не вмешиваясь в основную установку NetBox. И поскольку они полностью пользовательские, нет никаких внутренних ограничений на то, что может выполнить скрипт.
Таким образом пользовательские скрипты работают как ссылка на запуск произвольного действия вне NetBox. Можно запустить ping до какого-либо ресурса из графического интерфейса NetBox.
Мы добавили в NetBox средства базовой диагностики и получили аналог looking glass для L1/L2. Таким образом передали часть полномочий на первую и вторую линию поддержки и разгрузили наших инженеров, чтобы быстрее реагировать на запросы клиентов.
Как это работает. Выбираем скрипт, например, show route или ping, соответствующие AZ (зоны доступности), маршрутизатор, необходимую команду, просмотр интерфейса — и быстро получаем нужную диагностическую информацию.
NetBox как утилита сетевой автоматизации
Крутая особенность NetBox — возможность автоматизировать отдельный техпроцесс. Например, мы предоставляем такие услуги, как выход в интернет, L2- и L3-каналы (внешние сети и Direct Connect).
Для наших инженеров это несложные, хоть и многоступенчатые процессы, и на первый взгляд их не нужно автоматизировать и ускорять. Нюанс в том, что никто не застрахован от ошибок. Например, если сетевой инженер работал с простыми рутинными операциями и забыл добавить какое-то ключевое слово, это может привести к катастрофе.
Процессы на примере кастомных сущностей Service и Connection
Наши кастомные сущности называются Service и Connection. Например, клиенту нужен доступ из своей сети к облачному проекту. Для этого необходимо физически подключить его оборудование к нашему. Это соединение и есть Connection. Его атрибуты: откуда и куда он ведёт, максимальная скорость, отказоустойчивость (подключён одним или двумя линками).
После подключения клиента нам нужно сконфигурировать настройки его сети, например, прокинуть VLAN. Этот VLAN и есть Service. Он может быть разных типов (extnet, l2vpn), и от типа зависит его конфигурация. Вдобавок Service может быть настроен на нескольких соединениях одного пользователя. Все эти абстракции нужно превратить в читаемые конфигурации. На оборудовании разных вендоров они выглядят по-разному. За всеми этими сущностями нужно следить — инвентаризировать и жёстко привязывать к клиенту.
Конечно, мы написали много скриптов по упрощению эксплуатации огромной инфраструктуры. Но разрозненные маленькие скрипты — это большие неудобства. Во-первых, у нас не было автоматической проверки логики операций. Скрипты не искали свободный порт, его нужно было указывать вручную. Во-вторых, один скрипт не передавал результат своей работы в другой, и они не охватывали весь техпроцесс от и до. Часть работы всё равно приходилось выполнять руками.
Для решения этих проблем мы обратились к коллегам-разработчикам, чтобы они помогли автоматизировать скрипты по настройке Service и Connection.
ТЗ на разработку волшебной кнопки
ТЗ для разработчиков выглядело так: хотим кнопку, которая максимально автоматизирует нашу работу. Какие задачи должна была решать эта кнопка:
Подключение, отключение и изменение сервисов: extnet, L2vpn, интернет.
Поддержка инвентаризации в актуальном состоянии: внесение изменений в учётную систему.
Откат настроек (roll-back), потому что никто не застрахован от ошибок.
Делегирование полномочий (роли).
Как мы раньше настраивали Service и Connection
С помощью собственного скрипта мы регистрировали в NetBox коммутатор и интерфейс. Присваивали тег с именем сервиса интерфейсу, через который проходит физическое соединение пользователя. Тег служил ярлыком для быстрого поиска и идентификации. Затем вводили данные из NetBox в скрипт на подключённом к сетевому оборудованию хосте. Запускали скрипт. Он применял конфигурацию на сетевом оборудовании и сохранял её в формате YAML. Этот YAML-файл мы коммитили в Git, чтобы у нас было версионирование конфигураций
У этой схемы были недостатки:
Необходимость актуализировать YAML, синхронизировать YAML, NetBox и тикеты в Jira.
Неудобная фильтрация сущностей в NetBox.
Отсутствие информации о конфигурации в NetBox, настроено ли оборудование, какие на нём конфигурации.
Отсутствие агрегации сервисов по клиентам.
Высокая вероятность ошибок при ручном вводе.
Параметры для настройки Service и Connection находятся в NetBox, поэтому он и должен заниматься их конфигурацией и инвентаризацией.
Создаём плагин для Service и Connection
Мы написали плагин, в котором реализовали наши кастомные сущности Service и Connection, и создали кнопки управления их конфигурациями. Для этого написали сервис, который генерирует конфиги и применяет их на оборудовании. Сервис не хранит никакие состояния и у него нет базы данных, потому что её роль выполняет NetBox.
Мы применяем конфигурации с помощью библиотеки napalm. Однако в napalm нет нативной поддержки оборудования российского вендора B4COM. Поэтому мы немного допилили библиотеку и написали свой драйвер.
Встраиваемся своим плагином на уровень Django-приложения. Оно подгружается на старте, при необходимости прогоняет свои миграции и подгружает статические файлы.
В интерфейсе NetBox появляется новое навигационное меню Network Services. Теперь информация хранится не в YAML-файлах, а в NetBox.
В карточке Connection видно, какому клиенту (tenant) принадлежит определённый Connection, где он расположен и через какие соединения пролегает.
Если провалиться в Service и посмотреть его атрибуты, то мы увидим, что в конкретный момент происходит с сущностью Service или Connection на устройствах.
После того как мы создали Connection и Service, можно их конфигурировать.
Как работает наша волшебная кнопка
Инженер нажимает на кнопку «Configure», и в дело вступает машинерия. NetBox собирает всю информацию о Сonnection, Service и связанных с ними сущностях, затем отправляет API-запрос на сервис генерации конфигураций. Он получает запрос, генерирует конфигурации в XML-формате и с помощью napalm применяет их на сетевом оборудовании. После этого отправляет API-запрос обратно в NetBox для обновления статуса сущности и извлекает актуальные конфигурации с оборудования.
Планы на будущее
Мы хотим автоматизировать работу остальных сервисов NetBox. Первый в очереди на автоматизацию — наш флагманский сервис Direct Connect.
Автоматизация Direct Connect
Когда клиенту нужно подключить инфраструктуру в офисе, ЦОД или на наших площадках к своему облачному проекту, мы используем Direct Connect. Это L3-подключение, сети в нём маршрутизируются с помощью BGP-роутеров со стороны облака и со стороны физической клиентской инфраструктуры.
В облаке создаются виртуальные сущности: VPC, Transit Gateways, Direct Connect gateways и Direct Connect virtual interfaces. Клиент получает связанность оборудования за пределами облака и своего облачного проекта.
Сейчас физическое подключение организовано по старинке: пользователь отправляет письмо в службу поддержки с указанием, где нужно разместить оборудование, и описанием параметров соединения.
Обработка всех данных зависит от загрузки инженеров и очереди на подключение. Это долго и неудобно.
Заявку по почте мы заменим на кнопки в веб-интерфейсе К2 Облака. Каждый клиент сможет самостоятельно создавать соединение с нужными параметрами напрямую из консоли и отправлять запрос в NetBox с просьбой провалидировать его. Если в заявке всё указано верно и нужные ресурсы доступны, то NetBox сконфигурирует соединение и заведёт заявку в Jira на физическое подключение оборудования.
В дальнейших планах — интеграция с Jira. Любые действия с сетевым оборудованием ЦОД совершаются по тикетам Jira, поэтому мы хотим заводить и перемещать их напрямую из NetBox.
Ещё одна задача — стать вендор-агностик. Сейчас мы конфигурируем Service и Connection на оборудовании вендора B4COM, а хотим уметь настраивать и другое железо.
Хотим протестировать Yandex annet, открытый менеджер конфигураций Яндекса. Он делает ту же работу, что и наш сервис конфигурации оборудования: сверяется с источником правды, генерирует конфигурацию и применяет на оборудовании.
Итоги
Мы исключили многие трудности при эксплуатации огромной инфраструктуры и возможные ошибки инвентаризации. Наконец-то отказались от десятка разрозненных окон, отключили NetDot, Wiki, NOC, DCIM, и полностью переехали в Netbox. Сосредоточили весь учёт в одной системе и реализовали ряд автоматизаций по эксплуатации инфраструктуры.
Хотим закончить статью пожеланием в первую очередь для тех, кто поддерживает инфраструктуру. Никто лучше вас не знает её, но… объединяйтесь с другими командами. Совместные усилия эксплуатации, сетевых инженеров и разработки помогают достичь действительно интересных результатов.