Привет, Хабр!
Я Владимир Колпаков, инженер-проектировщик СПД в центре сетевых решений «Инфосистемы Джет». Сегодня расскажу, как работает система автоматизации сетевой фабрики, которую мы сделали для одного из заказчиков.
Автоматизация управления сетевым оборудованием давно превратилась в must-have для бизнеса. Если коротко, то это применение программных инструментов для автоматизации работы сетевых устройств. Цель — не просто упростить жизнь инженерам, а напрямую влиять на бизнес-метрики. В цифрах: развертывание новых сервисов ускоряется на 50–70%, а количество ошибок при конфигурировании снижается на 30–40%.
Почему White Box? Совокупный среднегодовой темп роста рынка White Box-коммутаторов составляет 16,2%. В первую очередь привлекательность White Box-коммутаторов обусловлена ценой, которая может быть ниже на 30–70% по сравнению с традиционными коммутаторами. Ответ на вопрос, за счет чего получается такая разница, раскрывается в идеологии White Box-оборудования.
White Box — это модель поставки сетевого оборудования, в которой аппаратная платформа и сетевое ПО поставляются отдельно. White Box («белый ящик») возник как ответ на классические программно-аппаратные комплексы (ПАК) от известных вендоров, которые представляют собой так называемый черный ящик — Black Box.
Благодаря концепции ONIE (Open Network Install Environment) White Box или baremetal- коммутаторы идут с минимальным набором ПО, который состоит из загрузчика и предустановленной минималистичной ОС ONIE, выполняющей функцию установщика основной сетевой операционной системы без доступа к аппаратной части коммутатора, отвечающей за data plane (плоскость данных).
В одном из проектов мы работаем с White Box-коммутаторами с операционной системой SONiC. Архитектура White Box на SONiC (Software for Open Networking in the Cloud) имеет несколько особенностей.
Часть конфигурации, например, настройка DNS, обеспечивается средствами Linux (/etc/resolve.conf).
Другая часть, описывающая настройки портов, VLAN, IP-адресов и подобного, настраивается через cli SONiC либо с помощью REST-API. Конфигурация сохраняется в файл config_db в формате JSON.
За все настройки, касающиеся протоколов маршрутизации, отвечает модуль FRR. Его настройка производится через cli FRR либо с помощью скрипта проекта FRR — frr-reload.py. Конфигурация сохраняется в файл frr.conf в традиционном текстовом виде, удобном для восприятия пользователя.
На первый взгляд это выглядит достаточно запутанно, и, чтобы упростить себе жизнь, было бы хорошо автоматизировать процесс настройки.
Что на практике даёт автоматизация конфигураций?
Повышение надежности сети. Достигается за счет шаблонизации. Конфигурация типовых устройств описывается один раз в виде параметризованного шаблона. Это гарантирует идентичность настройки для всего пула однородного оборудования и снижает вероятность ручных ошибок.
Скорость и оперативность. Автоматизация превращает часы рутинной работы в минуты выполнения скрипта. Рутинное развертывание десятков новых портов или устройств с типовой конфигурацией перестает быть проблемой, а у инженеров высвобождается ресурс.
Единый источник правды и контроль версий. Вся информация о сетевых настройках оборудования доступна в удобном виде в единой системе.
В нашем проекте мы разработали Систему автоматизации сетевой фабрики (САСФ).
В основе архитектуры — идея единого источника правды для настройки сетевого оборудования, которая возникла в результате эволюции IPAM/DCIM-систем. В прошлом они использовались в большей степени как инструмент документирования, а затем процессе эволюции превратились в основной инструмент для описания настроек оборудования для автоматизированной настройки.
Основные компоненты нашего решения
Open-Source-проект NetBox — это основной модуль, который помимо функционала хранения данных и их визуализации дает возможность с помощью скриптов модифицировать или обогащать хранимые данные, а также формировать конфигурацию для конечных устройств. Отдельно стоит отметить удобство развертывания NetBox в виде контейнеров, что позволяет гибко и оперативно настроить интеграцию, например, с LDAP, передавая при запуске настройки в виде переменных окружения.
Следующий компонент — это набор скриптов на языке Python для различных сценариев. Чтобы максимально минимизировать ручные операции по добавлению и модификации данных, мы написали скрипты, наполняющие NetBox информацией на основании шаблонов документации, а также обогащающие данные сетевых устройств при добавлении или удалении серверов. Помимо обогащения данных есть скрипты деплоя конфигурации на оборудование с генерацией конфигурации для Linux и JSON, деплоя в режиме dry-run, который покажет, какие изменения будут внесены на оборудование без применения настроек (для возможности оценки правильности заполнения конфигурации) и утилитарные скрипты, такие как сохранение состояния наполнения базы данных с возможностью откатиться к предыдущему состоянию, выгрузка коннектов подключенных устройств в формате кабельного журнала и другое.
Еще один важный компонент — это шаблоны конфигурации Config Templates в формате Jinja2. Часть конфигурации, которая настраивается в блоке FRR, не имеет REST-API, поэтому для ее применения используются шаблоны, генерирующие целевой файл конфигурации, который затем применяется на оборудовании с помощью скрипта проекта FRR — frr-reload.py.
И последний модуль — это Ansible. Структура плейбуков организована в виде ролей, что дает возможность при необходимости добавить отдельную логику для другой сетевой ОС или другого производителя.
Роль для сетевой операционной системы SONiC состоит из пяти частей:
Сверка конфигурации: производится анализ текущей конфигурации сетевого оборудования с конфигурацией, сгенерированной САСФ, формируется файл расхождения для режима dry-run и создаются переменные для следующих этапов.
Зачистка конфигурации устройств от настроек, которые были удалены из системы либо в ней не описаны.
Добавление в конфигурацию новых настроек, которые занесены в источник правды, но отсутствуют на оборудовании.
Исправление настроек, которые уже были на оборудовании, но значения которых изменились.
Запуск скрипта настройки FRR (frr-reload.py).
В процессе разработки САСФ мы отметили для себя особенно удобные инструменты в NetBox:
Config Context — это хранилище данных в формате JSON, к которым можно обратиться из скриптов или шаблонов в формате Jinja2. NetBox — очень сильный инструмент, имеющий множество полей для описания различных сущностей. Тем не менее, не всё можно описать в штатных полях, а функционала плагинов порой недостаточно. С помощью Config Context можно в формате JSON описать данные, которые не помещаются в модель NetBox, в удобном виде для скриптов и шаблонов.
Data Source — механизм, который позволяет хранить файлы скриптов, шаблонов и контекстов внутри базы данных, а также отслеживать и обновлять их при изменении. Он позволяет минимизировать рутинные операции по ручному передобавлению файлов в систему, а также сохраняет их состояние вместе с бэкапом базы данных, что позволяет откатиться на сохраненное состояние, даже если локальные файлы были изменены.
Отдельно стоит отметить возможность работы Data Source не только с локальными файлами, но и с системой контроля версий GIT. Это открывает возможности для использования подхода GIT-OPS, когда любые изменения в системе сначала должны быть отправлены в GIT, потом пройти code review, и только потом они будут синхронизированы с системой. Можно наглядно посмотреть, кто и когда вносил изменения, а также проанализировать разницу текущей конфигурации с предыдущей. Помимо этого, упрощается процедура обновления в части скриптов — достаточно отправить их в GIT и запустить синхронизацию Data Source.
Ключевые возможности САСФ:
добавление, удаление и модификация настроек сетевых устройств;
ролевая модель для сетевых устройств (Leaf, Border, Spine);
добавление, удаление и модификация информации о серверах;
ролевая модель для инфраструктурных настроек серверов;
модель сервисных настроек для серверов, основанная на тегах;
возможность менять роль сервера с обновлением соответствующих настроек на сетевых устройствах;
хранение, импорт и экспорт кабельного журнала;
генерация конфигурации для сетевого оборудования (Linux, JSON, FRR);
dry-run-режим для проверки того, какие изменения будут внесены на оборудование системой;
применение конфигурации на сетевое оборудование;
бэкап наполнения базы данных;
откат базы данных к предыдущему состоянию.
Чтобы понять, как отдельные части работают вместе, рассмотрим пару сценариев
Задача: на площадку необходимо добавить новый сервис
В первую очередь запускается скрипт бэкапа базы данных, чтобы можно было быстро откатиться на состояние, зафиксированное перед добавлением новых данных. Из документации в файл контекста заносятся данные. Запускается синхронизация с Data Source, данные подтягиваются в контекст. Далее запускается скрипт инициализации данных, который создает в САСФ все необходимые объекты для сервиса: VLAN, VRF, сети с привязкой к VLAN и VRF, тег с именем сервиса и тому подобное.
После добавления основных данных на серверы, на которых будут развернуты новые сервисы, навешивается тег с именем сервиса. Далее запускаются скрипты обогащения, которые по соответствию имени тега ролям серверов, набору VLAN на портах сервера, описанных в контексте, и информации, добавленной скриптом инициализации, делают следующее:
добавляют новый набор VLAN на интерфейсы сервера;
по описанным коннектам копируют набор VLAN сервиса на интерфейсы коммутаторов, к которым подключены серверы;
при этом, если мы добавляем новый сервер для сервиса, для коммутаторов автоматически создаются PortChannel;
создают SAG, SVI-интерфейсы и Loopback.
Далее запускается скрипт применения настроек в режиме dry-run. Он формирует конфигурацию для устройств в формате JSON, добавляет переменные для настройки части конфигурации в Linux и создает файл конфигурации для FRR на базе шаблона в формате Jinja2. Все это отправляется в модуль Ansible, где производится сравнение текущей конфигурации оборудования с той, которая должна быть применена системой.
Выводится список расхождений в формате: что будет удалено совсем, что будет добавлено и что будет изменено.
После анализа лога с изменением настроек и проверки того, что предлагаемые изменения корректны, запускается скрипт применения настроек:
создаются бэкапы конфигурации до внесения изменений;
штатными модулями Ansible настраивается Linux-часть конфигурации;
модулями REST-API настраивается часть конфигурации SONiC;
скриптом frr-reload.py настраивается конфигурация FRR;
внесенные изменения сохраняются;
создаются бэкапы конфигурации после применения настроек.
Задача: на площадку необходимо добавить два новых коммутатора
В первую очередь запускается скрипт бэкапа базы данных, чтобы можно было быстро откатиться на состояние, зафиксированное перед добавлением новых данных. Далее с помощью скрипта добавления нового устройства или импорта шаблона в формате CSV в систему добавляются новые коммутаторы, а также серверы, которые будут к ним подключены. Потом импортируется кабельный журнал, создаются соединения между портами устройств. После этого импортируются настройки для p2p-интерфейсов коммутаторов. Дальнейшие шаги аналогичны шагам из предыдущего примера. При этом требования к ручной настройке новых коммутаторов минимальны — необходимо настроить IP-адрес менеджмента и блок метаданных в конфигурации SONiC, определяющий режим работы FRR. После запуска скрипта применения настроек на оборудование коммутаторы полностью интегрированы в существующую фабрику и готовы к работе.
Что мы получили в результате?
Ускорили ввод в эксплуатацию сетевой инфраструктуры заказчика на новых площадках в 2 раза.
С необходимыми доработками этот подход может быть применим и к другим производителям сетевого оборудования.
Значительное снижение количества ошибок в сравнении с ручным конфигурированием оборудования.