Уронить нельзя поддерживать сеть

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

Преамбула:

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

Story:

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

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

И подборка полного функционального аналога не выглядела простой задачей.

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

Мы хотели простую, но функциональную систему, желая сохранить текущие интеграции с другими сервисами, или даже их расширить. Готовых AIO решений под наш “зоопарк” серверов и сетевого оборудования, который на тот момент уже серьёзно подрос, да ещё и с такими нашими требованиями, как можно догадаться, не нашлось. Даже крутые решения наподобие NOC не дотягивали до наших требований: либо не хватало функционала, либо поддержки наших сетевых устройств. И тут пришлось бы уходить в содержание сразу нескольких решений, что на наш взгляд непродуктивно от слова совсем, или допиливать тот же NOC под себя.

Ну, мы пошли любимым нами путём ☺

Так зародилась идея иметь полный контроль над сетью и её мониторингом в одном месте, без компромиссов (да, было больно и тернисто, но мы справились). Проект получил кодовое название UnicNet.

Задачи:1. Инвентаризация, максимальная актуальность всего парка сетевого оборудования, сканирование сети для автонаполнения базы устройств.

2. Массовое конфигурирование сетевого оборудования: чем проще, тем лучше.Инфраструктура как код (IaC) выглядела идеальным подходом под этот концепт.

3. Контроль конфигураций с полной историей изменений, удобный компаратор конфигов, сигналинг и откат изменений руками и по триггеру при получении данных по SNMP или SYSLOG.

4. Визуализация топологии сети с динамическим обновлением ее состояния, L2+L3, любые конструкции и сложность.

5. Группировка девайсов, теги, локация, быстрая БД устройств, которая махом перелопатит и выдаст любые объёмы списком, да ещё и с фильтрами и поиском (а вот и вопросы масштабирования системы подъехали).

6. Все протоколы, ведущий сетевой инженер сказал “Надо!” – разрабы ответили “Сделаем”:SSH\Telnet(пусть будет)\SNMP\Redfish\IPMI. Ну и походу дела прикрутить чекер любых портов по кнопке.

7. CLi – чтобы не хуже, чем у Putty и CMD, но с вечной памятью команд, избранными командами, и чтобы удобный. Ну и рабочие SNMP запросы оттуда же (мы же можем себе это позволить☺).

8. Автоматизация любых задач с расписанием выполнения и удобной выборкой устройств для реализации Zero-Touch Provisioning (ZTP), что бы любой юзер мог настраивать целые сети в пару кликов, заливая таким образом готовые конфигурации из базы UnicNet. Туда же - автодискавер, автообновление данных в базе, и главное – нормальные скрипты, в нативном виде для устройства, просто набором команд. Но не уходить же от готовых скриптов Ansible - надо сделать интеграцию…

9. …и как-то решить задачу простоя сетевых участков или недоступности ресурсов, пока идёт решение каких-либо проблем, возникших в сети. Ключевая задача - ускорить процесс, чтобы инженеры не сидели часами в командной строке и логах Zabbix, в поисках немощной железки.Но это решение пришло к нам сильно позже остальных, как кумулятивный инструмент на основе фундамента нашего предыдущего опыта решения других задач.

10. Максимальный охват вендоров.Российские сферы богаты на истории с содержанием древнего, а иногда и непопулярного оборудования в своих сетях (“Ну оно же работает!”). Да и мы сами понимали, что нет смысла становиться очередной системой с узкой поддержкой, всё-таки для нас не менее важно не только решать свои задачи, но и коммерциализировать наши продукты, что позволяет продукту расти и развиваться под популярные и не очень запросы, и оправдывать затраченное на разработку время.

11. Быстрый и красивый UI, и дайте тёмную тему! (мы совсем не против кучи окошек Cli, но UX наше всё☺)

Вывод?:

Итогом почти двухлетней разработки стал наш продукт - UnicNet.

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

Во второй части статьи я расскажу, что из себя по существу представляет наше решение и как его готовим мы и наши клиенты. И конечно же о наших планах на будущие итерации UnicNet:

● Развертывание в Kubernetes

● Поддержка distributed databases

● Использование ML-моделей для предсказания сбоев сети, анализ аномалий на основе статистики

● Оптимизация QoS-параметров на основе анализа трафика

● Как мы ушли в разработку модуля для создания цифрового двойника сети (Network Digital Twin) и куда пришиваем этот ваш ИИ.

● Интеграции с облачными решениями и ещё много всего…Ну или можно потыкать сюда - https://unicnet.ru/ или подписаться на наш Телеграм-канал https://t.me/rsunicnet