O paradigma Infrastructure as Code baseia-se na gestão e provisão da infraestrutura através de código em vez de utilizar processos manuais.
O estado da infraestrutura armazena-se em ficheiros que contêm a representação da sua configuração. Não é necessário que seja a configuração exata, mas um modelo de dados que permita gerar a configuração ou o estado final dos equipamentos alvo.
Utilizar este tipo de representação permite, entre outras coisas:
- Realizar um seguimento simples de alterações na infraestrutura. Este tipo de seguimento pode-se realizar com um sistema de controlo de versões, como o git;
- Implantar e replicar a configuração de forma simples na rede, utilizando ferramentas de automatização;
- Integrar a infraestrutura em pipelines CI/CD (Continuous Integration/Continuous Delivery).
O conceito Infrastructure as Code nasce com a explosão exponencial dos CPDs. O número de equipamentos, físicos ou virtuais, que era necessário gerir aumentou em ordens de magnitude. A aproximação tradicional de configurar manualmente os equipamentos já não era válida. Era fundamental poder automatizar as implantações massivas e conhecer o estado desejado no qual devia estar cada um dos serviços. A utilização do paradigma IaC permite armazenar essa informação de estado, para que logo as ferramentas de automatização implementem ou atualizem os serviços.
Graças ao uso da automatização e IaC, a gestão de grandes CPDs, com centenas ou milhares de servidores físicos e centenas de milhares de servidores virtuais tornou-se assumível.
Está-se a tentar transferir este mesmo paradigma ao mundo das redes de comunicação. O objetivo é poder aproveitar as suas vantagens, por exemplo:
- Redução no custo de operação, manutenção e implementação: uma provisão automatizada, determinista e simplificada tem custos menores que a provisão manual;
- Aumento da flexibilidade e rapidez nas implementações;
- Configurações deterministas: a configuração a implementar não será nunca afectada por erros humanos. Se houver um erro na configuração é determinista e, como tal, rastreável para a sua correção;
- Utilização de pipelines CI/CD para testar a nova configuração antes da sua implementação;
- Informação da configuração da rede rastreável e editável de forma simples.
Mas, a implantação deste paradigma em redes de comunicações encontra-se com desafios bastante complicados:
- Heterogeneidade do equipamento de rede: cada fabricante tem uma forma diferente de configurar o seu equipamento e, até dentro do mesmo fabricante, pode haver modelos com uma forma diferente de configuração (ver Cisco com IOS, IOS-XR, NX-OS);
- Funcionalidades proprietárias: embora todos os fabricantes digam que são a favor de standards, quase todos tendem a realizar “melhorias” proprietárias;
- Escassez de documentação: muitas redes não estão documentadas; outras têm documentação, mas completamente desatualizada; outras a têm fragmentada e não indexada, pelo que encontrar a informação adequada é bastante complicado;
- Modelos: em muitas redes não há modelos oficiais de configuração, pelo que a implementação de um novo serviço costuma seguir o modelo “copia de outro sítio onde funcione”, o que implica uma “deriva” nas configurações que se aplicam em rede;
- Modelo de operação: no caso de a ver problemas na rede, aplica-se a configuração necessária para resolver o problema e restaurar o serviço. Este tipo de configurações nem sempre revertem a uma configuração standard e quase nunca se documenta;
- Falta de conhecimento: embora a automatização nas redes leve anos a dar voltas, a norma é o desconhecimento destas técnicas tanto em departamento de engenharia, como de operações de rede.
Vamos deixar de lado as complicações operacionais de implantar um modelo Network Infrastructure as Code para nos centrarmos nas técnicas.
O primeiro e mais importante obstáculo é como representar a nossa configuração como código. Aqui temos dois modelos claros:
- Declarativo: com esta aproximação, a nossa configuração define como queremos que se comporte o equipamento de rede, qual é o estado desejado (necessito uma adjacência IS-IS na interface Ethernet0);
- Imperativo: neste modelo guardam-se os comandos exatos que se devem aplicar e em que ordem no equipamento alvo.
O modelo imperativo é bastante simples e pode solucionar o nosso problema a curto prazo. Mas, não é útil a médio/longo prazo. Não é independente do fabricante, dado que cada um tem a sua própria linha de comandos.
O modelo declarativo também apresenta os seus problemas nos equipamentos de rede. Nestes equipamentos a ordem na qual se aplicam os comandos é muitas vezes fundamental, e uma ordem diferente de aplicação pode levar à perda de serviço ou de gestão.
Seria ótimo utilizar um modelo declarativo, mas que a automatização para colocar a informação em rede seja capaz de discernir se alguns comandos têm de se executar antes que outros. Com as ferramentas atuais de automatização, esta aproximação não deveria ser nenhum problema.
Neste ponto é necessário dispor de uma abstração que nos permita modelar a configuração de um equipamento independentemente do fabricante ao qual pertença.
A linguagem de modelagem dominante e que se utiliza com protocolos de gestão de rede como NETCONF, é YANG (Yet Another Next Generation).
Esta linguagem permite modelar a configuração de um equipamento utilizando ficheiros YAML, JSON ou XML. Existem modelos YANG standardque podem utilizar quase todos os fabricantes. Além disso, cada fabricante define modelos próprios para poder modelar as suas particularidades.
O problema de conseguir uma abstração completa não está nas configurações simples, como aplicar um endereço IP a uma interface, mas em estruturas complexas como as políticas de routing. A forma na qual se implementam estas políticas em cada fabricante é bastante diferente, mas em todas se costuma utilizar vários objetos de configuração para definir essas políticas:
- Objetos para filtrar por prefixo;
- Diversos objetos para filtrar por atributos BGP;
Modelar de forma declarativa uma política de routing não é simples. Que esta política se possa abstrair do fabricante para poder colocá-la num ou noutro é ainda mais complexo. Mas este obstáculo pode ser ultrapassado com uma boa definição do modelo de dados dos modelos de configuração. Estes modelos permitiriam que com a mesma entrada (os dados) se gerem configurações dependentes do tipo de equipamento.
Depois de vermos que a modelagem da rede é factível, embora com esforço, deve-se ver como obter os dados do estado atual da rede. Num green field não seria um problema, dado que a modelagem seria anterior à implantação da rede. Mas o caso habitual não é precisamente esse. Há equipamentos que permitirão a exportação da sua configuração em formato YANG, mas não são todos. Para o resto seria necessário processar a configuração para gerar o modelo de dados. Existem ferramentas que são capazes de analisar as configurações de alguns fabricantes e modelar a sua configuração (como napalm). Para os fabricantes para os quais não seja possível, será necessário implementar um analisador de configurações para poder extrair os dados ao modelo comum.
Esta informação obtida é a que se guardará no sistema de controlo de versões e a que se utilizará para implantar a configuração na rede.
A partir desse momento, deve-se considerar que essa informação representa a Single Source of Truth, a única fonte da verdade. Isto implica algumas complicações em como se opera a rede:
- A partir deste momento, todas as alterações de rede devem realizar-se a partir de alterações nos ficheiros do nosso modelo de dados;
- Estas alterações implementam-se na rede através das automatizações pertinentes;
- Não se deve realizar alterações na rede de forma manual, dado que isto poderia provocar desvios nas configurações.
Manter a única fonte da verdade é fundamental no paradigma IaC, dado que de outro modo é inviável a gestão da infraestrutura se há discrepâncias entre os dados armazenados nela e a configuração real da rede.
Pelos motivos anteriores, estabelecer de forma completa o paradigma IaC e uma infraestrutura complexa de comunicações é praticamente uma utopia hoje em dia. Se for completamente orientadas a SDN, como ACI de Cisco, que até tem um acordo com Hashicorp, empresa líder em IaC com a sua ferramenta Terraform. Neste tipo de redes há elementos centralizados (controladores) que conhecem o estado completo da rede e têm API´s que permitem uma fácil interação com eles.
Então, será possível utilizar o paradigma IaC em redes complexas de comunicações? A resposta é que alterar completamente o modelo de operação é muito complexo, mas é factível avançar para ele.
A estratégia para implantar o IaC em redes de comunicações passaria por seleccionar parte da configuração para os incluir dentro do paradigma. As primeiras partes que se podem incluir e que são um quick win real são as relacionadas com a gestão do equipamento:
- Configuração de SNMP;
- Configuração de NTP;
- Configuração de SYSLOG;
- Configuração do acesso ao próprio equipamento;
Este tipo de configuração costuma ser comum a todos os equipamentos e centralizar esta informação para que a rede esteja sempre no estado desejado é relativamente fácil de conseguir.
A partir daí podem ser adicionadas outras partes da configuração a nossa infraestrutura IaC, tais como:
- Configuração de interfaces troncais de rede: o número destas interfaces costuma ser reduzido e a sua configuração é mais ou menos homogénea;
- Políticas de qualidade de serviço: estas definem-se uma vez e depois aplicam-se por tipo de interface;
- Políticas comuns de routing: quando se padronizam serviços, costuma-se definir políticas reutilizáveis por todos os clientes do mesmo serviço. Estas políticas podem-se modificar com o tempo para se adequar a novas características do serviço. Se estas políticas estão dentro da nossa infraestrutura IaC, a implantação da modificação em toda a rede é trivial;
A última parte que se poderia adicionar à infraestrutura IaC, numa rede já implementada, seriam os clientes conectados à mesma. Esta é a parte que contém uma maior variabilidade e que também costuma estar ligada a outros sistemas, como o próprio CRM de uma operadora. Conseguir ter esta informação na IaC permitiria simplificar dois dos processos mais abandonados de uma operadora:
- Cancelamentos de serviços: é comum que em muitas redes de uma operadora fiquem restos de configuração de serviços que foram cancelados. Sob um modelo de IaC declarativo, ao cancelar um serviço na única fonte da verdade, os automatismos eliminariam a configuração associada;
- Modificações de serviço: não é raro que as modificações de um serviço existente se tramitem como cancelamento e registos, dado que costuma ser mais simples realizar este processo. Se o modelo IaC for declarativo, os automatismos serão responsáveis por realizar estas modificações.
Como conclusão, a implantação completa do paradigma IaC numa rede de comunicações tradicional é muito complexa, mas é possível aproveitar-se deste paradigma para simplificar muitas operações que se realizam numa rede. De facto, é uma tendência estudar a possível aplicação deste modelo nas rede da operadora.
Se desejar mais informações sobre Satec não hesite em contactar-nos aqui 👈