Parte 1. Início

1.1 Introdução e declaração do problema

Na MTS controlamos de forma centralizada a qualidade das redes de transmissão de dados ou, mais simplesmente, a rede de transporte (não confundir com a rede de transporte logístico), a seguir designada por TS. E, no âmbito da nossa atividade, temos de resolver constantemente duas tarefas principais:

1. Foi detectada degradação dos serviços do cliente (em relação ao veículo) - é necessário determinar o percurso da sua ligação ao veículo e verificar se alguma parte do veículo é a causa da degradação dos serviços. Além disso, chamaremos isso de Problema Direto.
2. É detectada degradação da qualidade do canal de transporte ou da sequência do canal - é necessário determinar quais serviços dependem deste canal / canais para determinar o impacto. Além disso, chamaremos isso de Problema Inverso.

Os serviços de TS são entendidos como qualquer conexão de equipamento cliente. Podem ser estações base (BS), clientes B2B (usando MTS TS para organizar o acesso à Internet e / ou redes VPN de sobreposição), clientes de acesso fixo (os chamados acesso de banda larga), etc. etc.



Temos à nossa disposição dois sistemas de informação centralizados:



Qualquer rede de transporte é inerentemente um gráfico direcionado $$$G=(V,E)$ , em que cada aresta$$$(u,v) in E$ tem capacidade não negativa. Portanto, desde o início, a busca por soluções para esses problemas foi realizada no âmbito da teoria dos grafos.



Em primeiro lugar, a questão de comparar os indicadores de qualidade do TS e serviços com a topologia TS foi resolvida literalmente combinando e apresentando a topologia e os dados de qualidade na forma de um gráfico de rede.



A visualização do gráfico formado de acordo com os dados de topologia e desempenho foi implementada usando o software Gephi de código aberto . Isto permitiu resolver o problema de representação automática da topologia, sem trabalho manual na sua atualização. Se parece com isso:





Aqui, os nós são, na verdade, os nós do TS (roteadores, switches) e os básicos, as bordas são os canais do TS. O código de cores, respectivamente, denota a presença de degradações de qualidade e o estado de tratamento dessas degradações.



Parece que é bastante claro e você pode trabalhar, mas:

• O problema direto (do serviço para o caminho do serviço) pode ser resolvido com bastante precisão, desde que a topologia do TS seja bastante simples - uma árvore ou apenas uma conexão serial, sem anéis e rotas alternativas.
• O problema inverso pode ser resolvido sob uma condição semelhante, mas ao mesmo tempo, ao nível da agregação e do núcleo da rede, é impossível resolver este problema em princípio, uma vez que esses segmentos são governados por protocolos de roteamento dinâmico e têm muitas rotas alternativas em potencial.

Além disso, tenha em mente que, em geral, a topologia da rede é muito mais complicada (o fragmento acima está circulado em vermelho):





E este não é o menor segmento - há muito mais e mais complexidade na topologia:





Portanto, esta opção foi adequada para a análise meditativa de casos individuais, mas de forma alguma para agilizar o trabalho e, além disso, não para automatizar a solução de direto e reverso.

---

Parte 2. Automação v1.0

Deixe-me lembrá-lo das tarefas que resolvemos:

1. Determinar o percurso do serviço através do veículo - Tarefa direta.
2. Determinação dos serviços dependentes do canal TC - Problema inverso.

2.1. Serviços de transporte para estações de base (BS)

Geralmente, a organização do transporte do nó central (controlador / gateway) para o BS é assim:





Nos segmentos de agregação e no núcleo do TS, as conexões são feitas através dos serviços de transporte da rede MPLS: VPN L2 / L3, VLL. Nos segmentos de acesso, as conexões são realizadas, via de regra, por meio de VLANs dedicadas.



Deixe-me lembrá-lo de que temos um banco de dados onde estão todos os parâmetros reais (dentro de um determinado período) e a topologia do veículo.

2.2. Solução de segmento dial-up (acesso)

Pegamos dados sobre a VLAN da interface lógica do BS e, passo a passo, "percorremos" os links cujas portas contêm esse Vlan ID, até chegarmos ao roteador de fronteira (MBN).





Para resolver uma declaração de problema tão simples, acabei tendo que:

1. Escreva um algoritmo para o rastreamento passo a passo da "propagação" do VlanID do BS através dos canais da rede de agregação
2. Considere as lacunas de dados existentes. Isso era especialmente verdadeiro para as junções entre os nós nos sites.
3. Na verdade, escreva um algoritmo SPF para eliminar ramos sem saída no final que não conduzam ao roteador MVN.

O algoritmo resultou de um processo principal e sete subprocessos. Demorou 3-4 semanas de puro tempo de trabalho para implementá-lo e depurá-lo.



Além disso, tivemos um prazer especial ...

2.2.1. SQL JOIN

Em virtude de sua estrutura, o modelo relacional para percorrer o gráfico requer uma abordagem recursiva explícita com operações de junção em cada nível, enquanto percorre repetidamente o mesmo conjunto de registros. Isso, por sua vez, acarreta uma degradação no desempenho do sistema, especialmente em grandes conjuntos de dados.



Por razões óbvias, não posso citar o conteúdo das consultas ao banco de dados aqui, mas avalio - cada "saliência" no texto da consulta é a conexão da próxima tabela, que é necessária para, neste caso, obter uma correspondência unificada entre Port e VlanID:





E esta solicitação é para obter, de forma unificada, conexões cruzadas VlanID dentro do switch:





Considerando que o número de portas era de várias dezenas de milhares, e a VLAN era 10 vezes maior, tudo isso relutava em virar. E essas solicitações tiveram que ser feitas para cada nó e VlanID. E “descarregar tudo de uma vez e calcular” é impossível, pois é um cálculo sequencial do caminho c com operações passo a passo que dependem dos resultados da etapa anterior.

2.3. Determinando o Caminho do Serviço em Segmentos Roteados

Aqui, começamos com um fornecedor de MVN cujo sistema de gerenciamento forneceu dados sobre os LSPs atuais e em espera no segmento MPLS. Conhecendo a interface de acesso que estava conectada ao acesso (L2 Vlan), foi possível localizar o LSP e então, por meio de uma série de solicitações ao sistema NBI, obter o caminho do LSP, constituído de roteadores e links entre eles.

• Semelhante ao segmento comutado, a descrição de descarregar o caminho LSP do serviço MPLS resultou em um algoritmo com já 17 sub-rotinas.
• A solução funcionou apenas em segmentos atendidos por este fornecedor
• Era preciso decidir a definição das juntas entre os serviços MPLS (por exemplo, no centro do segmento havia um serviço VPLS geral, e EPIPE ou L3VPN divergiam dele)

Trabalhamos no problema para outros fornecedores de MVN, onde não havia sistemas de controle ou eles não forneceram dados sobre a passagem LSP atual em princípio. Encontramos uma solução para vários, mas - o número de LSPs que passam pelo roteador não é mais o número de VanIDs, que é registrado no switch. Atrasar tamanho volume de dados “sob demanda” (afinal, precisamos de informações operacionais) - existe o risco de deixar o hardware inativo.



Além disso, surgiram questões adicionais:

• – , , . .. – MPLS .
• , LSP, . . .

2.4. .

Os dados recebidos sobre os caminhos de conexão de serviços devem ser anotados em algum lugar, para que posteriormente possamos consultá-los na resolução de nossos problemas Direto e Inverso.



A opção de armazenamento em um banco de dados relacional foi imediatamente descartada: é tão difícil agregar dados de muitas fontes para que posteriormente sejam classificados nos próximos conjuntos de tabelas? Este não é o nosso método. Além disso, lembre-se das junções de vários andares e seu desempenho.



Os dados devem conter informações sobre a estrutura do serviço e as dependências de seus componentes: links, nós, portas, etc.



Como solução de teste, foram escolhidos o formato XML e Native-XML DB - Exist.



Como resultado, cada serviço foi registrado no banco de dados no formato (os detalhes são omitidos por uma questão de compactação):

<services>
	<service> 
		<id>,<description>   (,  )
		<source>    
		<target>    Z
		<<segment>>  L2/L3
			<topology>      (, /, )
		<<joints>>    (, /, )
	</service>
</services>

A consulta de dados para problemas diretos e inversos foi realizada usando o protocolo XPath:





Tudo. Agora o sistema está funcionando - para uma requisição com o nome do BS é retornada a topologia de sua conexão através da rede de transporte, para uma requisição com o nome do nó e porta do TS é retornada uma lista de BSs que dependem dele para conexão. Portanto, tiramos as seguintes conclusões ...

2,5.

Em vez de seguir as conclusões da Parte 2

2.5.1. Para o segmento comutado (redes em switches Ethernet L2)

• São necessários dados completos sobre a topologia e a correspondência Porta - VlanID. Se não houver dados VlanID em algum link, o algoritmo para, o caminho não foi encontrado
• Consultas improdutivas de vários níveis em um banco de dados relacional. Quando um novo fornecedor aparece com seus próprios parâmetros e especificações - adicionando solicitações em todos os estágios de trabalho

2.5.2. Para um segmento roteado

• Limitado pelos recursos do MVN SU para fornecer dados sobre a topologia dos serviços LSP MPLS.
• – , .. LSP .
• LSP – ( , “” ).

2.5.3.

• , , , , ( – , ), , – .
• . 3-4 .
• , .. , MPLS .
• – , .

2.6. -

• , , .. – .
• , -
• (, VlanID)

Depois de avaliarmos as opções possíveis para a implementação de nossos desejos, decidimos sobre a classe de sistemas que forneceria tudo isso "fora da caixa" - é o que se chama. bancos de dados gráficos.



Embora a última frase seja lida como algo linear e simples, visto que anteriormente nenhum de nós (e nossos especialistas em TI, como se viu, também) jamais havia encontrado tal classe de banco de dados, eles tomaram a decisão um tanto por acidente: bancos de dados semelhantes foram mencionados (mas não entendi) no curso de visão geral sobre Big Data. Em particular, mencionou o produto Neo4j... Não só, a julgar pela descrição, satisfaz todos os nossos requisitos, mas também tem uma versão da comunidade funcional totalmente gratuita. Essa. - não um teste de 30 dias, não corta a funcionalidade principal, mas um produto totalmente funcional que você pode estudar lentamente. Nem a última (senão a principal) função na escolha foi desempenhada pelo amplo suporte de algoritmos de gráfico .

---

Parte 3. Um exemplo da implementação do problema direto no Neo4j

Para não arrastar a narrativa linear sobre como o modelo TS é implementado no banco de dados de gráficos Neo4j, mostraremos imediatamente o resultado final com um exemplo.

3.1. Rastreando o caminho da interface Iub para 3G BS

O caminho da conexão de serviço passa por dois segmentos - um MVN roteado e um link de retransmissão de rádio comutado (as estações de retransmissão de rádio funcionam como switches Ethernet). O caminho através do segmento RRL é determinado da mesma maneira que descrito na Parte 2 - pela passagem da interface BS VlanID ao longo do segmento RRL para o roteador de borda MVN. O segmento MVN conecta o roteador de borda (com o segmento RRL) - com o roteador ao qual o controlador BS (RNC) está conectado.



Inicialmente, a partir do parâmetro Iub, sabemos exatamente qual MVN é o gateway para o BS (MVN de limite) e qual controlador é atendido pelo BS.



Com base nessas condições iniciais, construiremos 2 consultas ao banco de dados para cada um dos segmentos. Todas as consultas ao banco de dados são construídas na linguagem Cypher... Para não se distrair com sua descrição agora, pense nele simplesmente como “SQL para gráficos”.

3.1.1. Segmento RRL. Caminho VlanID

Solicitação Cypher para rastrear o caminho do serviço com base nos dados de topologia VlanID e L2 disponíveis:



Como você pode ver, o caminho foi obtido, mesmo apesar de uma falta parcial de dados. Neste caso, não há informação sobre a junção da porta BS com a porta da estação retransmissora de rádio.

3.1.2. Segmento RRL. Caminho de topologia L2

Digamos que uma tentativa seja feita na cláusula 3.1.1. falhou devido à ausência total ou parcial de dados no parâmetro VlanID. Em outras palavras, tal cadeia contínua alcançando o nó MVN não é construída:



Em seguida, você pode tentar definir a conexão de serviço como o caminho mais curto para o MVN de acordo com a topologia L2:



Como você pode ver, o mesmo resultado é obtido. Aqui, a falta de informação sobre a junção da BS com a RRS é compensada pela passagem da conexão pelo objeto (nó) do local onde estão localizadas. Claro, a precisão deste método será menor, porque em geral, Vlan não pode ser registrado ao longo do caminho mais curto sugerido pelo algoritmo de Dijkstra. Mas a solicitação consiste em apenas duas operações.

3.1.3 Segmento MVN. Traçando o caminho do limite MVN ao controlador

Aqui também usamos o algoritmo de Dijkstra.



Da mesma forma, neste caso, não há informações sobre as articulações diretas do MVN com o RNC. Mas isso não o impede de construir um caminho de serviço, mesmo que seja assumido pelo algoritmo (mais sobre isso mais tarde).

3.2. Custos de mão de obra

A implementação do Problema Direto, mostrado agora, é notavelmente diferente da abordagem "desenvolver um algoritmo, programa, método de armazenamento e recuperação de resultados" - tudo se resume a "escrever uma consulta no banco de dados". Olhando adiante, notamos que todo o ciclo de desenvolvimento de um modelo de gráfico simples, carregamento de dados no Neo4j de um banco de dados relacional, escrita de consultas e até o resultado ser obtido, levou um dia total.



3-4 meses vs 1 dia !!! Este foi o último motivo para a saída final para o banco de dados de gráficos.

---

Parte 4. Gráfico do banco de dados Neo4j e carregamento de dados nele

4.1. Comparação de bancos de dados relacionais e gráficos

4.2. Modelo de dados

O modelo básico da apresentação do TS até o nível de topologia L3, incluindo:





Claro, o modelo é mais extenso do que o apresentado, e também contém serviços MPLS e interfaces virtuais, mas para simplificar, vamos considerar um fragmento limitado dele.



Nesse modelo, a relação entre dois elementos de rede da mesma região pode ser representada como:

4.3. Carregando dados

Carregamos os dados do banco de dados dos parâmetros e topologia do veículo. Para carregar no Neo4j a partir do banco de dados SQL, a biblioteca APOC é usada - apoc.load.jdbc , que recebe como entrada uma string de conexão para o RDBMS e o texto de uma consulta SQL e retorna um conjunto de strings que são mapeadas para nós, links ou parâmetros por meio de expressões CYHPER. Essas operações são realizadas camada por camada para cada tipo de objeto de modelo.



Por exemplo, uma passagem para carregar / atualizar os nós que representam os elementos da rede (nós):



E assim por diante - em todos os níveis do modelo TS.



O campo Atualizado é usado para controlar a relevância dos dados na coluna - objetos que não são atualizados por mais de um determinado período são excluídos.

---

Parte 5. Resolvendo o problema inverso no Neo4j

Quando começamos, a expressão "rastreamento de serviço" trouxe pela primeira vez as seguintes associações:





Ou seja, que o caminho atual do serviço seja traçado diretamente, em um determinado momento.



Isso não é exatamente o que temos em um banco de dados de gráficos. No GDB, um serviço é rastreado de acordo com as relações de objetos que determinam sua configuração em cada elemento de rede envolvido. Ou seja, uma configuração é representada na forma de um modelo de gráfico e o traço resultante é uma passagem pelo modelo que representa essa configuração.



Uma vez que, ao contrário do segmento comutado, as rotas de serviço reais no segmento mpls são determinadas por protocolos dinâmicos, tivemos que aceitar alguns ...

5.1. Suposições para segmentos roteados

Porque a partir dos dados de configuração dos serviços mpls, não é possível determinar seu caminho exato através dos segmentos controlados por protocolos de roteamento dinâmico (especialmente se a Engenharia de Tráfego for usada) - para a solução, o algoritmo de Dijkstra é usado.

Sim, existem sistemas de gerenciamento que podem fornecer o caminho real de LSPs de serviço por meio da interface NBI, mas até agora temos apenas um fornecedor desse tipo e há mais de um fornecedor no segmento MVN.



Sim, existem sistemas de análise de protocolos de roteamento dentro do AS, os quais, ouvindo a troca de protocolos IGP, podem determinar a rota atual do prefixo de interesse. Mas existem tais sistemas - como o Boeing abatido, e dado que tal sistema precisa ser implantado em todos os ASs do mesmo backhole móvel - o custo da solução, junto com todas as licenças, será o custo de um Boeing abatido por uma ponte de ferro fundido amarrada ao foguete Angara quando totalmente reabastecido. E isso apesar do fato de que tais sistemas não resolvem completamente o problema de contabilização de rotas através de vários AS usando BGP.



Portanto - até agora. Claro, adicionamos vários adereços às condições do algoritmo de Dijkstra padrão:

• Contabilizando o status de interfaces / portas. O link desconectado aumenta de custo e vai para o fim das opções de caminho possíveis.
• Contabilizando o status do link de backup. De acordo com o sistema de Monitoramento de Desempenho, a presença de apenas tráfego keepalive no canal mpls é calculada, respectivamente, o custo de tal canal também aumenta.

5,2 Como resolver o problema inverso no Neo4j

Lembrete. A tarefa inversa é obter uma lista de serviços que dependem de um canal ou nó específico da rede de transporte (TS).

5.2.1. Segmento L2 comutado

Para o segmento comutado, onde o caminho do serviço e a configuração do serviço são praticamente iguais, o problema ainda pode ser resolvido por meio de solicitações CYPHER. Por exemplo, para um voo de retransmissão de rádio a partir dos resultados da resolução do problema direto na cláusula 3.1.1., Faremos uma solicitação do modem de link de retransmissão de rádio - iremos "expandir" todas as cadeias Vlan que passam por ele:

match (tn:node {name:'RRN_29_XXXX_1'})-->(tn_port:port {name:'Modem-1'})-->(tn_vlan:vlan)
with tn, tn_vlan, tn_port
call apoc.path.spanningTree(tn_vlan,{relationshipFilter:"ptp_vlan>|v_ptp_vlan>", maxLevel:20}) yield path as pp
with tn_vlan,pp,nodes(pp)[-1] as last_node, tn_port
	match (last_node)-[:vlan]->(:port)-->(n:node)
	return pp, n, tn_port

O nó vermelho indica o modem cujo Vlan estamos implantando. 3 BSs foram circulados em que, como resultado, a implantação de trânsito Vlan com Modem1 levou.





Essa abordagem tem vários problemas:

• Para portas, o Vlan configurado deve ser conhecido e carregado no modelo.
• Devido à possível fragmentação, a cadeia Vlan nem sempre produz saída para o nó terminal
• É impossível determinar se o último nó na cadeia Vlan pertence a um nó terminal ou se o serviço realmente continua.

Ou seja, é sempre mais conveniente rastrear um serviço entre nós / pontos finais de seu segmento, ao invés de um “meio” arbitrário e de uma camada OSI.

5.2.2. Segmento roteado

Com um segmento roteado, conforme já descrito na cláusula 5.1, não há necessidade de escolha - não há como resolver o problema inverso com base nos dados da configuração atual de algum link MPLS intermediário - a configuração não define explicitamente o rastreamento do serviço.

5.3. Decisão

A decisão foi tomada da seguinte forma.

• Carregamento total do modelo do veículo é realizado, incluindo BS e controladores
• Para todos os BS, o problema direto é resolvido - rastreamento de Iub, serviços S1 do BS para o MVN de limite e, em seguida, do MVN de limite para os controladores ou gateways correspondentes.
• Os resultados do rastreamento são gravados em um banco de dados SQL regular no formato: nome BS - uma matriz de elementos de caminho de serviço

Assim, ao acessar o banco de dados com a condição Nó TS ou Nó TS + Porta, é retornada uma lista de serviços (BS), cujo array de caminhos contém o Nó ou Nó + Porta necessário.

---

Parte 6. Resultados e conclusões

6.1. resultados

Como resultado, o sistema funciona da seguinte maneira:





No momento, para resolver o problema direto, ou seja, ao analisar as causas da degradação de serviços individuais, foi desenvolvida uma aplicação web que mostra o resultado do rastreamento (caminho) do Neo4j, com dados sobrepostos sobre a qualidade e desempenho de seções individuais do caminho.





Para obter uma lista de serviços que dependem de nós ou canais do TS (solução do problema inverso), foi desenvolvida uma API para sistemas externos (em particular, Remedy).

6,2 conclusões

• Ambas as soluções elevaram a automação da análise da qualidade do serviço e da análise da rede de transporte a um nível qualitativamente novo.
• Além disso, com a presença de dados prontos sobre as rotas dos serviços da BS, tornou-se possível disponibilizar rapidamente dados às unidades de negócio sobre a possibilidade técnica de inclusão de clientes B2B em sites específicos - em termos de capacidade e qualidade da rota.
• O Neo4j provou ser uma ferramenta muito poderosa para resolver problemas de gráficos de rede. A solução é bem documentada , tem amplo suporte em várias comunidades de desenvolvedores e está em constante desenvolvimento e aprimoramento.

6.3. Planos

Temos planos:

• ampliação dos segmentos tecnológicos modelados no banco de dados Neo4j
• desenvolvimento e implementação de algoritmos de rastreamento para serviços de banda larga
• aumento no desempenho da plataforma de servidor

Obrigado pela atenção!