Всем добрый день.

В своей предыдущей статье я уже упомянул о разрабатываемой нами системе, которая решает, казалось бы, не решаемую задачу - а именно автодискавери сетевых элементов в сетях телеком операторов, построение топологий, поиск путей прохождения трафика на основе информации, полученной из самих сетевых элементов. При этом стоит уточнить, что система не нуждается в интеграции со сторонними системами управления, такими как NCE (бывший Huawei u2000 TN), SoEM (СУ Ericsson), Aviat Provision, NFM-P (Nokia), и любыми другими. Т.е. система самодостаточна и способна работать в полностью автономном режиме.

Начну с той проблемы, которая возникла много десятилетий тому назад - и название этой проблемы - актуальная информация о состоянии сетей в режиме он-лайн. Дело в том, что мультисервисные сети давно стали мультивендорными - т.е. в каком-то филиале N любого провайдера связи, с течением времени скопилось множество разновендорного оборудования - сети MEN построены на Cisco, Huawei, Nokia. РРЛ - NEC, Huawei, Nokia и т.д. до бесконечности и в разных последовательностях. И т.к. каждый вендор не стремится создать универсальную СУ, которая могла хотя бы нарисовать топологию мультивендорной сети, приходится изобретать велосипед раз за разом.

Чаще всего велосипеды получались не далеко едущими, одноколесными, неудобными, без сидения или колес. Даже в системах управления крупных вендоров, функциональность не блистала. Более менее вменяемое я увидел в СУ Huawei - NCE. Но опять таки - каждый домен типов оборудования на своих вкладках, и единую топологию не получить - т.е. нельзя отобразить единовременно и на одной подложке сеть MBH (MEN+RRL). Не говоря уже о единовременном отображении специфических проблем, за которыми следят операторы связи - высокая утилизация интерфейсов, BBE/ES/SES/UAS, FCS, RSL Low, QoS Drop по очередям и пр.

Вторая задача для подобных систем управления - отображение путей прохождения трафика для RAN и B2B/B2C. Сложно представить, как это могло бы выглядеть. Примерно в режиме наскальной живописи можно найти информацию и отобразить ее, но только для прописанного сервиса в том же NCE или NFM-P. А что, если сервис прописан через множество типов оборудования, которых попросту нет в СУ?

Итак, постулаты для создания системы:

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

Стоит также упомянуть, что эти постулаты были сформированы лет 30 назад, и по-настоящему решены только сейчас. Подобных нами разработанной системы, во всем мире не так уж и много - первый аналог, который приходит на ум, это система израильской компании ArtiNet - NetACE.

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

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

Погрузимся немного в практическую составляющую. Одной из подзадач является задача сбора информации, на основании которой будет строиться топология. Решается эта проблема достаточно нативным способом - написанием краулеров (сборщиком данных) на любых известных ныне языках программирования. Алгоритм прост донельзя - в какой-то период времени запускаются скрипты, которые подключаются к оборудованию, и посылая команды в cli устройств, получают данные, парсят их на лету и через механизмы ETL отправляют в графовую БД. Все - про топологию рассказал :-). Если же отнестись к этому вопросу серьезно, то именно эта часть разработки системы, является самой трудоемкой. У заказчиков все есть свое мнение, какие данные им необходимо выбрать и распарсить из cli. RTN Huawei просто песня, с точки зрения сбора данных. Для начала нужно поработать с сетью, чтобы получить заветные данные - настроить траст хосты, чтобы РРЛ поняла, что именно с этого хоста к ней разрешено подключаться, настроить STelnet (SSH по-китайски). А каков синтаксис - мммм....... Если сказать точно, то не зная команд, в RTN лучше не лезть). С мандаринского на цискославянский этот cli не переводится, уж слишком специфично. А все это выливается в опыт работы с сетью, и даже не одной пятилеткой - нужно точно знать, что хочешь получить на выходе, и далее дело за малым - написать код на пайтон, C, go - и прочим языкам программирования.

Отдельная задача - это преобразование полученных данных с помощью механизмов ETL в вид, который съест Neo4j. Приведу примеры кода для создания нод сети МЕН и связей между ними

<!-- MEN IMPORT - Create Chassis -->    
<script connection-id="neo4j">
LOAD CSV WITH HEADERS FROM 'file:$men.chassisNodes' AS row
FIELDTERMINATOR ';'
MERGE (chassis:Chassis {uid: row.oam_ip})
SET
chassis.oam_ip = row.oam_ip,
chassis.name = row.name,
chassis.location = row.location,
chassis.type = row.type,
chassis.longitude = row.longitude,
chassis.latitude = row.latitude,
chassis.filial = row.filial,
chassis.status = "Available",
chassis.lastAvailable= datetime(),
chassis.lastAvailableLinux= timestamp()
</script>

<!-- MEN IMPORT - Create relationships between Chassis LSP -->
<script connection-id="neo4j">
LOAD CSV WITH HEADERS FROM "file:$men.chassisToChassisEdges" AS row
FIELDTERMINATOR ';'
MATCH (ch1:Chassis {oam_ip: row.local_ip})
MATCH (ch2:Chassis {oam_ip: row.remote_ip})
MERGE (ch1)-[lsp:LSP{uid:replace(replace(row.local_ip + "-LSP-" + row.remote_ip + "-" + row.out_interface1 + "-" + row.AreaId, "/", ""), " ", "")}]->(ch2)
SET
lsp.uid = replace(replace(row.local_ip + "-LSP-" + row.remote_ip + "-" + row.out_interface1 + "-" + row.AreaId, "/", ""), " ", ""),
lsp.port = row.out_interface1,
lsp.vlan = row.vlan,
lsp.zabbix_ifindex = row.ifindex,
lsp.status = "Available",
lsp.description = row.description,
lsp.area_id = row.AreaId,
lsp.lastAvailable= datetime(),
lsp.lastAvailableLinux= timestamp()
</script>

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

Также в свойства узлов и релейшншипов можно записать и названия сервисов (Abis, S1, IuB, B2B, B2O, B2G), пути прохождения которых, были рассчитаны заранее. Для того, чтобы визуализировать данные в UI Graphlytic, достаточно написать короткий запрос на языке Cypher.

Запрос с параметром $path

MATCH (c1)-[r]-(c2) WHERE size([x IN $path WHERE x IN c1.paths]) > 0 AND
size([x IN $path WHERE x IN c2.paths]) > 0 RETURN c1, r, c2

Обработка параметра "path"

[{
"parameter": "path",
"type": "CYPHER",
"config": {
"placeholder": "Select BTS",
"multiple": true,
"query": "MATCH (ns) UNWIND ns AS n UNWIND n.paths AS path WITH COLLECT(distinct path) AS collected UNWIND collected AS value RETURN value"
}
}]

Результатом работы данного запроса, станет выборка нод с релейшншипами, где в свойстве "paths" упоминается название того или иного сервиса.

Это первая статья из цикла. В остальных статьях я расскажу о других решенных задачах.

Об инновациях. Или Neo4J на страже Telco