Здравствуйте! Это наша первая публикация на Хабре, посвящённая системе автоматизации АТОМ. Пишу вам от себя и от имени своего коллеги, с которым мы активно занимаемся разработкой системы автоматизации и визуализации АТОМ для сетей ЦОД в компании Ростелеком, о которой пойдёт речь ниже.
Коротко о нас и нашем подразделении
Меня зовут Александр, а моего коллегу зовут Олег, мы являемся сотрудниками Блока ИТ ПАО "Ростелеком", вместе с коллегами нашего управления занимаемся разработкой архитектуры корпоративной сети, проектируем и имплементируем решения, эксплуатируем сети важных проектов компании, оказываем внутреннюю экспертную поддержку командам эксплуатации.
В число наших задач входит не только непосредственная работа с сетевым оборудованием (коммутаторы, маршрутизаторы, межсетевые экраны, балансировщики нагрузки и т.п.), но и разработка средств автоматизации, а также тестирование отечественных решений (программных и аппаратных), оценка их применимости на всём распределённом корпоративном ландшафте сети Ростелеком и последующее внедрение. Последнее время мы серьёзно сконцентрированы именно на задачах исследования отечественных разработок, подбора аналогов зарубежных решений, проведения проверок и испытаний соответствия заявленным характеристикам и активном применении в проде успешно протестированных нами решений. В рамках таких тестов стало понятно, что не все решения соответствуют тому, о чём пишет производитель и тестирование, выявление недочётов, багов, постоянная работа с технической поддержкой стала нашей новой реальностью.
Мы создали внутреннюю лабораторию (не путать с лабораторией РТК-ЦОД), где тестируем как программные решения (ПО) для корпоративных нужд, так и аппаратные: коммутаторы, маршрутизаторы, межсетевые экраны (NGFW), трансиверы, а также комбинированные решения, такие как брокеры + фильтры.
Корпоративная сеть Ростелеком — это более 70 тыс. устройств сотрудников, ежедневно использующих сетевую инфраструктуру, несколько тысяч объектов по всей стране, где размещаются наши коллеги, тысячи единиц сетевого оборудования, десятки площадок ЦОД, в которых размещены сотни крупных корпоративных информационных систем (ИС) и более тысячи средних и мелких ИС и сервисов компании.
С чего всё началось и как появилась сама идея
У нас много Центров обработки данных (ЦОД), в которых используются различные сетевые технологии. Они построены на разных решениях/архитектурах, вендорах, все они разного размера и запущены в эксплуатацию в разное время. У нас в ЦОД имеются как решения с применением SDN контроллеров, так и активно используем CLOS-архитектуру (VXLAN BGP EVPN или LEAF-SPINE архитектура). Среди них есть и такие, в которых пока ещё используются Legacy L2 технологии.
Количество информационных систем растёт постоянно, количество VLAN на сетевом оборудовании тоже. В определённый момент мы выяснили, что такой параметр, как максимальное количество VLAN на коммутаторе, ещё ни о чём не говорит. Согласно datasheet, практически на любом коммутаторе ЦОД можно создать 4096 Vlan, только вот почти нигде не написано, что подать все эти 4К Vlan возможно только на несколько портов. Если нужно подать много Vlan на все порты (обычно на коммутаторах ЦОД их 48 шт.), то количество таких Vlan (доступных для полноценного использования) будет сильно меньше. На части используемого у нас импортного оборудовании количество таких Vlan не превышает 270 Vlan. Причина - аппаратные ограничения в чипах коммутаторов. То есть настроить можно, как угодно, но с какого-то момента коммутатор перестает корректно выполнять свою основную функцию – передавать данные.
В этот момент многие читатели, разбирающиеся в сетевых технологиях, про себя подумают: «переводите этот ЦОД на VXLAN BGP EVPN, и проблема уйдет». Мы думали также, вспоминалась фраза, которая есть в любом курсе про VXLAN «VXLAN – это 24 бита против 12 бит для Vlan, все ограничения пропадают».
Выяснилось, что не совсем все так радужно. На доступном нам отечественном сетевом оборудовании есть такие же (или аналогичные) ограничения в чипах. В итоге при использовании VXLAN мы можем подать на все порты коммутатора не более 250 Vlan.
Читатель может спросить – а зачем мы подавали столько Vlan в каждый порт? Ответ – так было удобно. В порты коммутаторов подключены сотни серверов виртуализации, на которых работают тысячи виртуальных машин, серверы периодически выводятся на обслуживание, виртуальные машины мигрируют на другие серверы. При этом нет никаких проблем с сетевой доступностью для любой виртуальной машины – она появлялась сразу, а нам как сетевикам для этого ничего не нужно было делать.
То есть у нас было так:

Столкнувшись с ограничениями, мы поняли, что так дальше продолжать невозможно и нам придется ограничивать количество Vlan, подаваемых на порты коммутаторов, а для этого надо будет разбираться с тем, куда и какие Vlan надо настроить. И очень желательно, чтобы работы у подразделения эксплуатации сильно не прибавилось.
Т.е. нам необходимо было добиться, чтобы получилось вот так:

Так и родилась идея разработать приложение, которое мы назвали - ATOM.
АТОМ, что ЭТО?
Сейчас это веб-приложение, написанное на React.JS и FastAPI, которое мы планируем развить и превратить в полноценную систему автоматизации. Оно предназначено для подготовки конфигураций сетевого оборудования ЦОД и автоматической настройки VLAN (добавления тегов 802.1Q на транковые порты) с согласия сетевого инженера.
React.js и FastAPI
React.js — это JavaScript-библиотека для создания пользовательских интерфейсов (UI), разработанная Facebook. Она позволяет строить динамические, компонентные веб-приложения с использованием декларативного подхода и виртуального DOM.
FastAPI — это современный, высокопроизводительный фреймворк для создания веб-API на Python. Он основан на стандартах OpenAPI и Pydantic, обеспечивает автоматическую генерацию документации и поддерживает асинхронные запросы, что делает его быстрым и удобным для разработки.
Вместе React.js и FastAPI часто используются для создания полноценных веб-приложений, где React отвечает за фронтенд, а FastAPI — за бэкенд.
Система включает в себя портал агрегации и визуализации данных, полученных из API отечественной системы виртуализации Basis DynamiX и данных, полученных из LLDP таблиц сетевого оборудования. Система уже содержит данные о гипервизорах виртуализации, кластерах виртуализации (сгруппированных групп гипервизоров), VM (виртуальных машин), необходимых Vlan-ах, таблицах соединений серверов и свитчей и другой полезной информацией, используемой в ежедневной работе. Интерфейс АТОМ-а позволяет гибко менять визуальное отображение таблиц, сортировать данные, выполнять поиск по ним, делать необходимые отчеты сохраняя данные в CSV или EXCEL формате.

Сейчас система умеет автоматизированно (раз в сутки) вычислять необходимые данные, хранить их внутри себя, а также информирует нас о произведённых изменениях, найденных ошибках и ошибках в работе системы и текущих интеграций.
Система позволяет готовить конфигурации для портов оборудования ЦОД по выбранным параметрам - локация, кластер виртуализации, коммутатор.

Ещё несколько скриншотов из веб-интерфейса системы.
Список имён кластеров (SEP/Cluster) с указанием количества гипервизоров в каждом кластере (Node Count), вланов необходимых для работы кластера (Vlan Count) и информация по вычисленным Vlan-ам (Computed Vlans), которые используются в реальности:

Список VM (виртуальных машин), содержащих в имени "test" и отсортированных по столбцу c именем проекта (RG Name). В интерфейсе отображается Vlan, в котором размещен данный виртуальный сервер, его IP адрес и МАК адрес, а также указан гипервизор, на котором он находится:

Гибкая сортировка объектов в веб-интерфейсе позволяет делать разные удобные конструкции, скрывать или добавлять дополнительные столбцы и отображать только необходимую информацию, а также удобно экспортировать в CSV или EXCEL только то, что вы видите на экране. В примере ниже отсортировано по свитчам и кластерам, что позволяет понять какие гипервизоры конкретного кластера подключены в этот коммутатор, а также какие порты используются, сколько там запущено VM и какое количество Vlan требуется для каждого сервера:

Для работы системы мы активно используем Docker-контейнеры, которые обеспечивают изоляцию и масштабируемость приложений, упрощают развёртывание и тестирование.
Для автоматизации рабочих процессов и интеграции различных сервисов мы используем N8N — бесплатный, открытый и расширяемый инструмент (low-code и no-code). Он позволяет быстро создавать сложные рабочие процессы, такие как интеграция с внешними API, автоматизация уведомлений и обработка данных, без необходимости написания большого объёма кода. Это значительно ускоряет разработку и упрощает поддержку системы.
Текущий статус и промежуточные итоги
На данный момент система уже находится на стадии опытно-промышленной эксплуатацию, первая версия нашего продукта включает необходимую базовую функциональность. В данный момент мы занимаемся доработкой данного приложения, расширяем масштаб покрытия существующей инфраструктуры и добавляем новую функциональность.
Мы считаем, что в текущем состоянии наша система, обладая удобным интерфейсом с необходимыми данными, уже позволяет:
Автоматически готовить конфигурации для коммутаторов доступа;
Снизить время на поиск и устранение неисправности;
Экономить время на выполнении рутинных задач;
Оптимизировать затраты на эксплуатацию при возросшем объёме задач;
Уменьшить риск человеческой ошибки.
Благодаря интеграции с системой виртуализации и автоматическому анализу мы теперь получаем достоверную и консолидированную информацию в удобном для нас формате. Это позволило снизить коэффициент утилизации ресурсов сетевого оборудования и подавать только необходимые VLAN на те порты серверов, где это действительно требуется. В результате мы стали значительно реже сталкиваться с проблемами, а благодаря удобному интерфейсу смежные задачи решаются в несколько раз быстрее, чем раньше. Эти изменения не только повысили эффективность работы, но и позволили сократить операционные затраты, что положительно сказалось на общей производительности компании.
Дальнейшие планы
Мы планируем интегрировать систему с корпоративной облачной платформой и с помощью механизма webhook оперативно получать актуальную информацию о создаваемых виртуальных машинах. Это позволит нам программно определять необходимость подачи новых Vlan на сервера того или иного кластера, формировать задачи на добавление настроек на оборудование, которые в автоматизированном режиме будут исполняться. Тем самым мы сможем достигнуть цели снизить до минимума трудозатраты на выполнение таких задач.
На этом мы завершаем наш рассказ. Если статья вызовет интерес, мы обязательно поделимся дальнейшими результатами развития системы и её техническими деталями. Мы будем признательны за обратную связь и желаем вам стабильно работающей инфраструктуры и как можно больше интересных задач!