Mudanças entre as edições de "Introducao aos conceitos de programabilidade de infraestruturas de redes"

De Wiki BPF
Ir para: navegação, pesquisa
m
m
Linha 66: Linha 66:
 
Para tudo isto que escrevi acima, o que escolher, o que adotar, "o que comer, o que vestir", enfim, tudo isto requer amplo planejamento e boas práticas para a manutenção do '''''ciclo de vida do projeto''''' (Iniciação, Planejamento, Execução, Monitoramento e Controle, Encerramento). Isto será discutido futuramente em outros artigos aqui em nossa Wiki.
 
Para tudo isto que escrevi acima, o que escolher, o que adotar, "o que comer, o que vestir", enfim, tudo isto requer amplo planejamento e boas práticas para a manutenção do '''''ciclo de vida do projeto''''' (Iniciação, Planejamento, Execução, Monitoramento e Controle, Encerramento). Isto será discutido futuramente em outros artigos aqui em nossa Wiki.
  
=== Qual é a relação entre a "seção de revisão de componentes tecnológicos" deste artigo e os objetivos específicos do mesmo? ===
+
=== Qual é a relação entre a "seção de revisão de componentes tecnológicos" deste artigo e os objetivos propostos pelo mesmo? ===
 
Talvez você esteja se perguntando: "''Tá, Leonardo, mas.... o que tem isso a ver?''".
 
Talvez você esteja se perguntando: "''Tá, Leonardo, mas.... o que tem isso a ver?''".
  
Linha 81: Linha 81:
 
E é justamente sobre este tema é que passaremos a dissertar a partir de agora neste artigo, sendo este o nosso foco.
 
E é justamente sobre este tema é que passaremos a dissertar a partir de agora neste artigo, sendo este o nosso foco.
  
=== A relação deste artigo com os frameworks e modelos de gerenciamento de infraestruturas de ambientes ISP ===
+
=== A relação entre este artigo e os frameworks e modelos de gerenciamento de infraestruturas de ambientes ISP ===
 
Não dissertarei detalhadamente sobre os frameworks em questão, pois haverá oportunidades sobre este tema em outros artigos do Brasil Peering Forum. Irei ao ponto logo ao término dessa seção.
 
Não dissertarei detalhadamente sobre os frameworks em questão, pois haverá oportunidades sobre este tema em outros artigos do Brasil Peering Forum. Irei ao ponto logo ao término dessa seção.
  
Linha 117: Linha 117:
 
## Aqui é onde enxergo outra excelente oportunidade para a modernização das infraestruturas e processos dos ISPs regionais!
 
## Aqui é onde enxergo outra excelente oportunidade para a modernização das infraestruturas e processos dos ISPs regionais!
 
[[Arquivo:Bpf-prog-2.png|centro|miniaturadaimagem|800x800px|O roteiro tradicional de implantação e provisionamento de serviços de um ISP]]
 
[[Arquivo:Bpf-prog-2.png|centro|miniaturadaimagem|800x800px|O roteiro tradicional de implantação e provisionamento de serviços de um ISP]]
 +
 +
=== Introdução aos conceitos da disciplina de configurações ===
 +
Realmente pretendo pular a parte referente aos conceitos de ''IT Service Management'' (ITSM), e um tanto do que a versão 3 do ITIL (''Information Technology Infrastructure Library'') aborda neste sentido. Voltaremos aqui ao que importa, e o FCAPS é mais apropriado para dissertarmos a respeito disto.
 +
 +
Na questão de "Configurações", o FCAPS é centrado em um bocado de coisas, mas dá para sumarizar suas principais funções da seguinte forma:
 +
# '''''Inicialização do Serviço'''''
 +
# '''''Provisionamento do Serviço'''''
 +
# '''''Auto-descoberta''''' (de elementos e suas capacidades e propriedades, topologias, etc.)
 +
# '''''Backup e restauração''''' (obviamente incluindo muitas capacidades e facilidades aqui, tais como diff-check, dry-run, etc.)
 +
# '''''Desligamento de recursos''''' (quando não são mais necessários, ou por mudança de perfil de assinante (ex: bloqueado, cancelado))
 +
# '''''Gestão de mudanças''''' (os processos e ferramentas para a "GMUD").
 +
# '''''Pré-provisionamento'''''
 +
# '''''Gerenciamento de inventário''''' (não somente a parte do hardware inteiro, mais também os módulos, acessórios, software, licenças, etc.)
 +
# '''''Cópia de configurações'''''
 +
# '''''Configuração remota'''''
 +
# '''''Atualização automática de software''''' (incluindo funcionalidades que maximizem a disponibilidade dos dispositivos, compliance de software, etc.)
 +
# '''''Iniciação, rastreamento e execução de job'''''
 +
Ou seja, tudo para viabilizar os controles necessários para implementar a configuração inicial dos elementos da rede e seus respectivos componentes, sincronismo e monitoramento dos parâmetros de configuração empregados; distribuição de tarefas de configuração com o auxílio de templates, configuração de propriedades avançadas sobre os elementos da rede (proteção e resiliência, VLANs, entroncamentos, QoS, etc.), manutenção e auditoria de configurações, e tantos outros.
 +
 +
A arquitetura ''Equipment Management Function'' (EMF) proposta pelo ITU-T com relação ao FCAPS fornece as recomendações sobre como os sistemas de gerenciamento de elementos (EMS) gerenciam as funções de elementos de redes (NEF), ao interagir com funções atômicas da camada de transporte e sincronização (AF), e fazendo isto através da troca de informações de gerenciamento (MI) sobre os pontos de gerenciamento (MP); esse "tequiniquês" é abordado no ITU-T G.806, ITU-T X.701 e ITU-T X.720, enfim, suprimamos isso aqui. Talvez eu deva ao menos fornecer uma noção visual destes conceitos:
 +
[[Arquivo:Bpf-prog-fcapscm.png|centro|miniaturadaimagem|800x800px|Ilustração de conceitos FCAPS tais como NEF, EMF, MAF, MCF, MI  e MP (Fonte: ITU-T)]]
 +
Em termos mais práticos, isto significa que você precisa considerar para a sua infraestrutura as devidas funções de gerenciamento para cada uma áreas recomendadas pelo FCAPS (ou eTOM BPF, neste caso), observando como os sistemas de negócios da empresa estão mapeados para os sistemas mais técnicos e operacionais, e como estes sistemas mais técnicos-operacionais interagem com a infraestrutura para aditivar as tecnologias, as quais, por sua vez, darão apoio direto aos resultados tanto técnicos quando os de negócios. Aquela tão desejada aderência...
 +
 +
Você basicamente possui dois caminhos possíveis, dependendo do perfil do seu ambiente em termos de "vendor":
 +
* '''Rede homogênea:''' se a sua rede contiver dispositivos e soluções de apenas um fabricante, você muito provavelmente poderá utilizar as ferramentas/sistemas ou soluções daquele fabricante para as necessidades de gerenciamento de configurações. Aliás, não somente configurações, mas também a parte de desempenho, falhas/incidente, segurança, etc. Ou seja, as plataformas de gerenciamento desenvolvidas pelo fabricante para aquela classe de produtos que você tem na sua rede. Desnecessário comentar que são soluções proprietárias, certo? Não que isto seja algo ruim, mas é bom deixar isto bem claro.
 +
* '''Rede heterogênea:''' se a sua rede contiver um mix de soluções e de vários fabricantes, você terá bem mais dificuldades. Na maioria dos casos, você terá que rodar múltiplos sistemas de gerenciamento para acomodar cada uma das áreas funcionais previstas pelo FCAPS através deste cenário multivendor. É muito pouco provável que a plataforma de gerenciamento de um determinado fabricante vá suportar bem os equipamentos de outros fabricantes, principalmente quando o assunto for ''<u>gerenciamento de configurações</u>''. E, caso haja esse suporte, ele quase sempre ou fatalmente será limitado, ou possuirá algumas chatas restrições.
 +
Em muitos casos, nos vemos forçados a usar uma solução para gerenciar os elementos da marca "A", outra solução de gerenciamento para os elementos da marca "B", mais uma solução para gerenciar os elementos da marca "C", e uma ou mais soluções open source (ou não) para monitorar componentes em comum das marcas "A", "B" e "C", como ocorre frequentemente para a parte de gerenciamento de desempenho e gerenciamento de falhas/incidentes, onde soluções tais como PRTG, Zabbix, Libre NMS, etc., são bastante populares. Eu particularmente vejo muita fragilidade e inconvenientes aqui, pois raramente estes sistemas integram bem com sistemas de outros fabricantes, exceto, talvez, e dependendo do caso, via extensas e complexas integrações por ''Common Object Request Broker Architecture'' (CORBA), do ''Object Management Group'' (OMG), algo que já vi acontecer um bocado em ambientes de telecom. Um porre!
 +
 +
Que tal darmos uma praticidade para estes argumentos?
 +
* O '''Winbox''' da Mikrotik não vai gerenciar configurações de um equipamento Cisco ou Juniper ('''''pelo menos não que eu saiba! KKKKKKK''''').
 +
* O '''Cisco Prime LAN Management Solution''' não vai gerenciar configurações de elementos de rede de classe corporativa não-Cisco.
 +
* O '''Cisco Application Policy Infrastructure Controller (APIC)''' possui alguma integração com soluções específicas (Check Point, Palo Alto Networks, Fortinet Inc, Radware – DefensePro, A10 Networks, Avi Networks, Citrix Systems, F5 Networks, Radware – Alteon VA e VX), mas não para todos os recursos e funções que talvez você necessite para o seu projeto.
 +
* O '''Cisco Adaptive Security Device Manager (ASDM)''' só serve para gerenciar dispositivos de segurança ASA da Cisco.
 +
* O '''Cisco Network Services Orchestrator (NSO)''' implementa zero funções de gerenciamento de falhas ou desempenho, mas talvez seja a única solução comercial que consegue orquestrar o provisionamento de serviços fim a fim sobre qualquer equipamento e de qualquer vendor (a não ser que o seu equipamento não seja realmente lá grandes coisas...).
 +
* O '''Junos Space Network Management Platform''' da Juniper consegue integrar alguns dispositivos de terceiros como elementos gerenciados, mas, "guess what?", há restrições de funcionalidades.
 +
* O '''HPE Intelligent Management Center Enterprise''' da HP permite adicionar alguns elementos externos/de terceiros, tais como o switch Cisco Nexus, e integrações com Aruba Airwave (faz sentido, pois houve a aquisição aqui), ClearPass e HPE OneView. O que exatamente é suportado ou quais são as restrições aqui, eu desconheço no momento.
 +
* O '''Zabbix''' pode ser ótimo para necessidades de gerenciamento de falhas/incidentes e de performance/desempenho, até mesmo porque é amplamente customizável. Agora experimente conduzir a disciplina de gerenciamento de configurações com esta ferramenta, e você verá que é simplesmente inviável.
 +
* O '''Libre NMS''' é outro exemplo clássico, idêntico ao caso do Zabbix, assim como de outras ferramentas bem conhecidas do mercado.
 +
* O '''ManageEngine''' ou o '''PRTG''' são outros ótimos exemplos para as questões de gerenciamento de falhas e de desempenho, mas não são funcionais para o gerenciamento de configurações.
 +
Como você pode notar, muito frequentemente os sistemas que nós utilizamos não atendem bem a todas as nossas necessidades, e nos vemos forçados a contar com 3 ou 4 soluções de gerenciamento para manter a infraestrutura funcionando. Sistemas, estes, que funcionam de forma completamente independente, como "ilhas" mesmo, isolados, e com mínima ou zero troca de dados entre si. Para ''falhas'' e ''desempenho'', isto é até "aceitável". Mas, para o '''''gerenciamento de configurações''''', isto é inaceitável!
 +
 +
A ilustração a seguir fornece exemplos de soluções mapeadas para as áreas do FCAPS, para que você tenha essa noção de que alguns fabricantes procuram especificar as funções de suas soluções de gerenciamento para ficarem mais "alinhadas" com as recomendações do FCAPS. Os exemplos não são completos e tampouco estão atualizados 100%, mas acho que você compreenderá a essência.
 +
[[Arquivo:Bfp-network management.png|centro|miniaturadaimagem|600x600px|(Fonte: snmpserver.com)]]
 +
E é por esta razão que a indústria está convergindo cada vez mais para os princípios de programabilidade, pois os modelos de gerenciamento tradicionais não mais correspondem às nossas expectativas!
 +
 +
Agora, há uma terceira opção aqui, que seria considerar soluções comerciais (destes mesmos fabricantes ou de terceiros) em combinação com outras iniciativas que entendam melhor as nossas necessidades e que sejam capazes de promover melhor aderência. Uma grande verdade aqui é muitos dos sistemas "fechados" não atende integralmente as nossas necessidades! E é nessa hora onde ferramentas e soluções de programabilidade poderão ser bem mais efetivas para os nossos propósitos. É nessa hora que pensamos em Ansible, Chef, Puppet, Salt, outras ferramentas de programabilidade, embarcadas ou não em ambientes SDN, etc.
  
 
=== Compreendendo a programabilidade de infraestruturas ===
 
=== Compreendendo a programabilidade de infraestruturas ===
Linha 122: Linha 168:
 
* O <u>'''''provisionamento'''''</u> é essencialmente a intenção de ativação de um serviço para o ISP ou, bem mais frequentemente, para seus clientes.  
 
* O <u>'''''provisionamento'''''</u> é essencialmente a intenção de ativação de um serviço para o ISP ou, bem mais frequentemente, para seus clientes.  
 
** Este provisionamento de um serviço (ex: um L2VPN "LAN-to-LAN" ou "DCI", uma L3VPN, um serviço de Internet, etc.) pode ser realizado manualmente (como é feito normalmente na maioria dos casos envolvendo os ISPs regionais) ou de forma bem mais "''programável''"; orquestrada e automatizada.
 
** Este provisionamento de um serviço (ex: um L2VPN "LAN-to-LAN" ou "DCI", uma L3VPN, um serviço de Internet, etc.) pode ser realizado manualmente (como é feito normalmente na maioria dos casos envolvendo os ISPs regionais) ou de forma bem mais "''programável''"; orquestrada e automatizada.
* A ''<u>'''orquestração'''</u>'' é a capacidade tecnológica de habilitar serviços envolvendo ações de provisionamento sobre a infraestrutura, que poderá abranger ou contemplar somente a rede, ou, então, por exemplo, rede + computação + storage + plataforma/apps, para um determinado produto ou serviço desejado, seja este para atender uma necessidade interna, do próprio ISP, ou para atender a uma solicitação ou contratação por parte de um cliente/assinante.
+
** Geralmente referimos o conceito à ativação de um serviço fim-a-fim e que vá envolver diversas tecnologias (L2, L3, outros) e em vários dispositivos de rede, homogêneos (mesmo padrão de sintaxe e semântica) ou heterogêneos (diferentes vendors, ou CLIs, sintaxes, etc.).
 +
** O provisionamento pode ser também uma coisa bem mais específica e pontual (um pequeno bloco de configuração a ser programado em um único dispositivo, por exemplo).
 +
* A ''<u>'''orquestração'''</u>'' é a capacidade tecnológica de habilitar serviços envolvendo ações de provisionamento sobre a infraestrutura, que poderá abranger ou contemplar somente a rede, ou, então, por exemplo, rede + computação + storage + plataforma/apps, frequentemente tocando em componentes multivendor, para um determinado produto ou serviço desejado, seja este para atender uma necessidade interna, do próprio ISP, ou para atender a uma solicitação ou contratação por parte de um cliente/assinante.
 
** A orquestração é muito desejada em qualquer tipo de situação, mas, sem sombra de dúvidas, é mais desejável ainda em ambientes heretogêneos (ex: multivendor).
 
** A orquestração é muito desejada em qualquer tipo de situação, mas, sem sombra de dúvidas, é mais desejável ainda em ambientes heretogêneos (ex: multivendor).
 
* A <u>'''''automação'''''</u> é o estado operacional desejado para que estas ações de configuração e provisionamento de serviços (e até mesmo nos casos de diagnósticos ou suporte a falhas) na infraestrutura envolvam "zero" ou o mínimo possível de ações humanas.
 
* A <u>'''''automação'''''</u> é o estado operacional desejado para que estas ações de configuração e provisionamento de serviços (e até mesmo nos casos de diagnósticos ou suporte a falhas) na infraestrutura envolvam "zero" ou o mínimo possível de ações humanas.
Linha 129: Linha 177:
 
*** Em muitos casos, o contrato do serviço pode ser desenhado na forma de templates e acionados por ações nos sistemas da companhia, onde, num simples ''frontend'', os parâmetros são preenchidos/fornecidos para que, no ''backend'', a rede seja acionada para receber as configurações devidas e concluir todo o provisionamento. Neste cenário, não há o envolvimento de analistas na linha de comando (CLI) ou em plataformas específicas de provisionamento (EMS/GUI/WebUI).
 
*** Em muitos casos, o contrato do serviço pode ser desenhado na forma de templates e acionados por ações nos sistemas da companhia, onde, num simples ''frontend'', os parâmetros são preenchidos/fornecidos para que, no ''backend'', a rede seja acionada para receber as configurações devidas e concluir todo o provisionamento. Neste cenário, não há o envolvimento de analistas na linha de comando (CLI) ou em plataformas específicas de provisionamento (EMS/GUI/WebUI).
 
*** Em outros casos, o provisionamento é feito em sistemas específicos para este propósito e poderá exigir algum padrão de intervenção técnica, por exemplo, a execução de scripts ou acionamentos de funções mais técnicas em sistemas específicos, mas exigindo pouco ou nada em termos de uma intervenção por CLI ou GUI/WebUI dos dispositivos.
 
*** Em outros casos, o provisionamento é feito em sistemas específicos para este propósito e poderá exigir algum padrão de intervenção técnica, por exemplo, a execução de scripts ou acionamentos de funções mais técnicas em sistemas específicos, mas exigindo pouco ou nada em termos de uma intervenção por CLI ou GUI/WebUI dos dispositivos.
* A '''''<u>programabilidade</u>''''' tem relação com a afinidade de tecnologias, processos, ferramentas e soluções técnicas compatíveis que são empregadas para as orquestrações de serviços.  
+
* A '''''<u>programabilidade</u>''''' tem relação com a afinidade de tecnologias, processos, ferramentas e soluções técnicas compatíveis que são empregadas para as orquestrações e automações de serviços.  
** Isto é, idealmente, o seu aparato tecnológico, incluindo hardware, software e sistemas utilizados em seu ambiente, tudo isto precisa ser compatível com o suporte à tecnologias que fomentam a orquestração e automação para um provisionamento fim a fim de serviços com maior fluidez, menor tempo/prazo, "zero" ou menor esforço de implementação, e menores riscos para a rede e para o negócio.  
+
** Isto é, idealmente, o seu aparato tecnológico, incluindo hardware, software e sistemas utilizados em seu ambiente, tudo isto precisa ser compatível com o suporte à tecnologias que fomentam a orquestração e automação para a programabilidade do provisionamento fim a fim de serviços com maior fluidez, menor tempo/prazo, "zero" ou menor esforço de implementação, e menores riscos para a rede e para o negócio.  
 
* Praticamente em todos os casos a orquestração envolve automação, mas não o contrário: nem toda automação tem relação com orquestração.
 
* Praticamente em todos os casos a orquestração envolve automação, mas não o contrário: nem toda automação tem relação com orquestração.
* Programabilidade e <u>'''''Software-Defined Networking'' (SDN)'''</u> são coisas completamente '''<u>distintas</u>'''.
+
* Programabilidade e <u>'''''Software-Defined Networking'' (SDN)'''</u>, apesar de andarem lado a lado constantemente, são coisas completamente '''<u>distintas</u>'''.
* Orquestração e ''Software-Defined Networking (SDN)'' são coisas '''<u>distintas</u>'''. Nem toda orquestração ocorre em um ambiente SDN, mas quase sempre o oposto é verdadeiro.
+
* Orquestração e ''Software-Defined Networking (SDN)'' são coisas '''<u>distintas</u>'''. Nem toda orquestração ocorre em um ambiente SDN (ex: com controladoras e soluções específicas de SDN), mas quase sempre o inverso é verdadeiro.
 
* ''Software-Defined Networking'' (SDN) e ''<u>'''Network Functions Virtualization'''</u>'' (NFV) são coisas completamente '''<u>distintas</u>'''.
 
* ''Software-Defined Networking'' (SDN) e ''<u>'''Network Functions Virtualization'''</u>'' (NFV) são coisas completamente '''<u>distintas</u>'''.
 
* As capacidades de programabilidade da infraestrutura estão condicionadas à disponibilidade e suporte de recursos e ferramentas específicas, e isto valendo para cada equipamento.
 
* As capacidades de programabilidade da infraestrutura estão condicionadas à disponibilidade e suporte de recursos e ferramentas específicas, e isto valendo para cada equipamento.
 +
** Não adiantará muito controladoras SDN com suporte a OpenFlow na sua rede se os seus elementos de rede (equipamentos) forem incompatíveis. Ou, ao invés do OpenFlow, não adiantará muito (ou pelo menos ficará bem mais complicado) fazer a orquestração de serviços na rede se os seus equipamentos não suportarem o protocolo NETCONF.
 
* Redes mais sofisticadas utilizam ferramentas e recursos mais arrojados para estas finalidades de programabilidade.
 
* Redes mais sofisticadas utilizam ferramentas e recursos mais arrojados para estas finalidades de programabilidade.
 
A ilustração a seguir mostra exemplos de recursos de programabilidade representados por funcionalidades suportadas por um determinado equipamento, assim como mostra alguns casos de tecnologias mais apropriadas para que se tenha uma rede mais programática e versátil neste sentido.
 
A ilustração a seguir mostra exemplos de recursos de programabilidade representados por funcionalidades suportadas por um determinado equipamento, assim como mostra alguns casos de tecnologias mais apropriadas para que se tenha uma rede mais programática e versátil neste sentido.
[[Arquivo:Bpf-prog-1.png|centro|miniaturadaimagem|800x800px|Componentes fomentadores da programabilidade de infraestruturas]]
+
[[Arquivo:Bpf-prog-1.png|centro|miniaturadaimagem|800x800px|Exemplos de componentes fomentadores da programabilidade de infraestruturas]]
  
==== Ferramentas e soluções orientadas aos princípios de programabilidade ====
+
==== Identificando as principais soluções, ferramentas e componentes orientados aos princípios de programabilidade ====
Caso você tenha ficado impressionado com a "salada de tecnologias" ilustrada no início deste artigo, isto porque você talvez desconheça o turbilhão de ferramentas empregadas para fins de programabilidade, incluindo orquestração e automação! Como realmente não dá para listar todas as opções de código aberto e comercial, fornecerei aqui alguns exemplos, talvez os principais. Aliás, a intenção a seguir é apenas listas estas ferramentas e soluções, e não esmiuçar como são implementadas ou inseridas nas infraestruturas.
+
Caso você tenha ficado impressionado com a "salada de tecnologias" ilustrada no início deste artigo, isto porque você talvez desconheça o turbilhão de ferramentas empregadas para fins de programabilidade, incluindo orquestração e automação! Como realmente não dá para listar todas as opções de código aberto e comercial, fornecerei aqui alguns exemplos, talvez os principais, além de citar muitas ferramentas e os principais componentes usados por estas, tais como protocolos, procedimentos e formatos de dados, onde for viável comentar neste nível. Aliás, a intenção a seguir não é realmente esmiuçar como são de fato implementadas ou inseridas nas infraestruturas. Outro aspecto importante a ser comentado é que os exemplos a seguir não funcionam "sozinhos", no sentido que, em uma rede, você precisará combinar diversas destas soluções, linguagens, ferramentas e procedimentos; e que nem tudo o que está citado a seguir depende de um ambiente SDN para acontecer. Há casos e casos, e cenários para tudo.
  
 
A ilustração a seguir mostra algumas destas soluções e ferramentas.
 
A ilustração a seguir mostra algumas destas soluções e ferramentas.
 
{| class="wikitable"
 
{| class="wikitable"
|+Descrição das principais ferramentas e soluções para programabilidade
+
|+Descrição das principais soluções, ferramentas, procedimentos e componentes de programabilidade
 
!Ferramenta
 
!Ferramenta
 
!Disponibilidade
 
!Disponibilidade
 
!Descrição
 
!Descrição
 
|-
 
|-
|'''VMware vSphere'''
+
| colspan="3" |'''Soluções Comerciais'''
|
+
|-
 +
| colspan="2" |'''VMware vSphere'''
 
|O vSphere é o software de virtualização de servidores líder do setor e o núcleo de um SDDC moderno. Ele ajuda você a executar, gerenciar, conectar e proteger os aplicativos em um ambiente operacional comum entre nuvens.
 
|O vSphere é o software de virtualização de servidores líder do setor e o núcleo de um SDDC moderno. Ele ajuda você a executar, gerenciar, conectar e proteger os aplicativos em um ambiente operacional comum entre nuvens.
 
A solução é amplamente utilizado no mundo todo e em todo e qualquer tipo de ambiente, mesmo aqueles ambiente mais estáticos ou isentos de componentes de orquestração.
 
A solução é amplamente utilizado no mundo todo e em todo e qualquer tipo de ambiente, mesmo aqueles ambiente mais estáticos ou isentos de componentes de orquestração.
 
|-
 
|-
|'''VMware vRealize'''
+
| colspan="2" |'''VMware vRealize'''
|
 
 
|VMware vRealize Suite, conhecido anteriormente pelo nome vCenter Operations Management Suite, é uma plataforma de software projetada para a comstrução de núveis heterogêneas híbridas.
 
|VMware vRealize Suite, conhecido anteriormente pelo nome vCenter Operations Management Suite, é uma plataforma de software projetada para a comstrução de núveis heterogêneas híbridas.
 
|-
 
|-
|'''Cisco APIC-EM'''
+
| colspan="2" |'''Cisco APIC-EM'''
|
 
 
|O Cisco Application Policy Infrastructure Controller Enterprise Module (APIC-EM) é a solução de controladora SDN da Cisco para redes corporativas, atendendo tanto a LAN quanto a WAN.
 
|O Cisco Application Policy Infrastructure Controller Enterprise Module (APIC-EM) é a solução de controladora SDN da Cisco para redes corporativas, atendendo tanto a LAN quanto a WAN.
  
 
A sua proposta é a de fornecer uma plataforma elástica paraa a automação, simplificação e abstração da rede, acomodando apliações que usam padrões abertos, e com suporte a northbound Representational State Transfer (REST) APIs.
 
A sua proposta é a de fornecer uma plataforma elástica paraa a automação, simplificação e abstração da rede, acomodando apliações que usam padrões abertos, e com suporte a northbound Representational State Transfer (REST) APIs.
 
|-
 
|-
|'''Cisco DNA Center'''
+
| colspan="2" |'''Cisco DNA Center'''
|
 
 
|O Cisco DNA Center é uma solução que reúne componentes focados na construção de ambientes intuitivos (Intent-based Networking), em compatibilidade com as arquiteturas SDN da Cisco.
 
|O Cisco DNA Center é uma solução que reúne componentes focados na construção de ambientes intuitivos (Intent-based Networking), em compatibilidade com as arquiteturas SDN da Cisco.
 
Reúne excepcionais facilidades para Projeto, Policy, Provisionamento, Assurance e integração com outras plataformas, e com foco em ambientes corporativos.
 
Reúne excepcionais facilidades para Projeto, Policy, Provisionamento, Assurance e integração com outras plataformas, e com foco em ambientes corporativos.
 
|-
 
|-
|'''Cisco Crosswork Network Automation'''
+
| colspan="2" |'''Cisco Application Centric Infrastructure (ACI)'''
|
+
|O Cisco Application Policy Infrastructure Controller (Cisco APIC) é o principal componente arquitetural da solução Cisco ACI. Ele é o ponto unificado de automação e gerenciamento para a estrutura, a aplicação de políticas e o monitoramento de integridade da solução. O controlador otimiza o desempenho e a gestão, além de operar uma estrutura multiusuário escalonável da Cisco ACI. A solução como um todo embarca outros componentes tais como a própria controladora (Cisco APIC), Cisco Cloud ACI, Cisco Virtual ACI, swiches Cisco Nexus 9000 Series, Cisco ACI Multisite Orchestrator, Cisco ACI App Center, além de ótimas integrações com outras soluções tais como AppDynamics, DNA Center e ISE. O foco do ACI está para os ambientes de data center.
 +
|-
 +
| colspan="2" |'''Cisco Crosswork Network Automation'''
 
|O Cisco Crosswork Network Automation é uma solução voltada especificamente para service providers / ISPs e que reúne uma diversidade muito grande de recursoos para o gerenciamento proativo fim a fim das redes.
 
|O Cisco Crosswork Network Automation é uma solução voltada especificamente para service providers / ISPs e que reúne uma diversidade muito grande de recursoos para o gerenciamento proativo fim a fim das redes.
  
 
Embarca uma suite de componentes de machine-learning, intent-based networking, e outros, viabilizando ampla orquestração de redes plenamente automatizadas.
 
Embarca uma suite de componentes de machine-learning, intent-based networking, e outros, viabilizando ampla orquestração de redes plenamente automatizadas.
 
|-
 
|-
|'''Cisco Network Services Orchestrator'''
+
| colspan="2" |'''Cisco Network Services Orchestrator'''
|
 
 
|O Cisco NSO é uma solução muito robusta de abstração de infraestruturas físicas e virtuais, fornecendo excepcionais capacidades de oquestração de serviços fim a fim, e muitas facilidades de integração com APIs northbound e southbound.
 
|O Cisco NSO é uma solução muito robusta de abstração de infraestruturas físicas e virtuais, fornecendo excepcionais capacidades de oquestração de serviços fim a fim, e muitas facilidades de integração com APIs northbound e southbound.
  
 
O Cisco NSO pode funcionar sozinho ou em combinação ao Cisco Crosswork Network Automation.
 
O Cisco NSO pode funcionar sozinho ou em combinação ao Cisco Crosswork Network Automation.
 
|-
 
|-
|'''Cisco Open SDN Controller'''
+
| colspan="2" |'''Cisco Open SDN Controller'''
|
 
 
|O Cisco OSC é uma distribuição comercial do OpenDaylight para o fornecimento de agilidade e automação de infraestruturas, fazendo a abstração de ambientes de redes heterogênas para a entrega de serviços.
 
|O Cisco OSC é uma distribuição comercial do OpenDaylight para o fornecimento de agilidade e automação de infraestruturas, fazendo a abstração de ambientes de redes heterogênas para a entrega de serviços.
 
|-
 
|-
|'''Microsoft System Center'''
+
| colspan="2" |'''Microsoft System Center'''
|
 
 
|O Microsoft Systems Management Server é uma solução para o gerenciamento de grandes grupos de sistemas baseados no Microsoft Windows.
 
|O Microsoft Systems Management Server é uma solução para o gerenciamento de grandes grupos de sistemas baseados no Microsoft Windows.
 
|-
 
|-
|'''BMC Software'''
+
| colspan="2" |'''BMC Software'''
|
 
 
|A BMC é uma empresa americana bastante especializada em soluções para o gerenciamento de TI, oferecendo suporte a 92 das 100 empresas listadas na Forbes Global.
 
|A BMC é uma empresa americana bastante especializada em soluções para o gerenciamento de TI, oferecendo suporte a 92 das 100 empresas listadas na Forbes Global.
  
Linha 200: Linha 245:
 
Suas soluções são frequentemente encontradas em grandes e bem sucedidos empreendimentos, e possui ótimas capacidades de integração com infraestruturas de redes.
 
Suas soluções são frequentemente encontradas em grandes e bem sucedidos empreendimentos, e possui ótimas capacidades de integração com infraestruturas de redes.
 
|-
 
|-
|'''Juniper Contrail'''
+
| colspan="2" |'''Juniper Contrail'''
|
 
 
|A solução Contrail Controller da Juniper Networks é um produto de automação tipo open cloud que implementa tecnologias SDN para a orquestração e criação de redes virtuais altamente escaláveis. É fruto da aquisição da Contrail em dezembro de 2010.
 
|A solução Contrail Controller da Juniper Networks é um produto de automação tipo open cloud que implementa tecnologias SDN para a orquestração e criação de redes virtuais altamente escaláveis. É fruto da aquisição da Contrail em dezembro de 2010.
  
Linha 208: Linha 252:
 
A solução é projetada para operar em uma máquina virtual (VM) que possui integração com Kubernetes, OpenShift, Mesos, OpenStack, VMware vSphere, e facilidades de integração com sistemas OSS e BSS.
 
A solução é projetada para operar em uma máquina virtual (VM) que possui integração com Kubernetes, OpenShift, Mesos, OpenStack, VMware vSphere, e facilidades de integração com sistemas OSS e BSS.
 
|-
 
|-
|'''Huawei Agile SDN Controller'''
+
| colspan="2" |'''Huawei Agile SDN Controller'''
|
 
 
|O controlador Agile para campus é a última geração de controladores da Huawei para redes de campus e de ramificação. Utilizado em diversas soluções inovadoras, como implantação de rede automática, automação de política e SD-WAN.
 
|O controlador Agile para campus é a última geração de controladores da Huawei para redes de campus e de ramificação. Utilizado em diversas soluções inovadoras, como implantação de rede automática, automação de política e SD-WAN.
 
O controlador Agile para campus reduz as despesas operacionais (OPEX) e os custos de operações e manutenção (O&M) das empresas, aceleram a mudança dos serviços para a nuvem e a transformação digital, além de tornar o gerenciamento de rede mais ágil e os procedimentos de O&M de rede mais inteligentes.
 
O controlador Agile para campus reduz as despesas operacionais (OPEX) e os custos de operações e manutenção (O&M) das empresas, aceleram a mudança dos serviços para a nuvem e a transformação digital, além de tornar o gerenciamento de rede mais ágil e os procedimentos de O&M de rede mais inteligentes.
 
|-
 
|-
|'''Ansible'''
+
| colspan="3" |'''Soluções de Código Aberto, Ferramentas, Sistemas, Linguagens, Protocolos, Procedimentos e Formatos de Dados'''
|
+
|-
 +
| colspan="2" |'''Ansible'''
 
|O Ansible é uma ferramenta de provisionamento, gerenciamento de configurações e implantação de aplicativos de software livre. É executado em muitos sistemas semelhantes ao Unix e pode configurar sistemas semelhantes ao Unix e também o Microsoft Windows.
 
|O Ansible é uma ferramenta de provisionamento, gerenciamento de configurações e implantação de aplicativos de software livre. É executado em muitos sistemas semelhantes ao Unix e pode configurar sistemas semelhantes ao Unix e também o Microsoft Windows.
  
O Ansible pode automatizar três tipos de tarefas: provisionamento, gerenciamento de configurações, automação de aplicações. É bastante utilizado tanto em projetos de infraestruturas de redes quanto nas questões relacionadas a servidores e aplicações. É uma ferramenta bastante popular!
+
O Ansible pode automatizar três tipos de tarefas: provisionamento, gerenciamento de configurações, automação de aplicações. É bastante utilizado tanto em projetos de infraestruturas de redes quanto nas questões relacionadas a servidores e aplicações.
 +
 
 +
O Ansible não usa agentes e nenhuma infraestrutura de segurança personalizada adicional, apenas uma linguagem muito simples (YAML, na forma de Ansible Playbooks) que permite descrever seus trabalhos de automação de uma maneira que se aproxima bastante do inglês comum. É uma ferramenta bastante popular!
 
|-
 
|-
|'''Chef'''
+
| colspan="2" |'''Chef'''
|
 
 
|Chef é uma ferramenta de gerenciamento de configurações escrita em Ruby e Erlang. O Chef usa uma linguagem específica de domínio, pura em Ruby, para escrever "receitas" na configuração do sistema.  
 
|Chef é uma ferramenta de gerenciamento de configurações escrita em Ruby e Erlang. O Chef usa uma linguagem específica de domínio, pura em Ruby, para escrever "receitas" na configuração do sistema.  
  
Linha 227: Linha 272:
 
O cliente Chef fica instalado em cada servidor, máquina virtual, conteiner ou dispositivo de rede que você gerencia, chamados de "nodes". O cliente consulta periodicamente a política e o estado mais recentes da sua rede do servidor Chef. Se algo no nó estiver desatualizado, o cliente o atualizará.
 
O cliente Chef fica instalado em cada servidor, máquina virtual, conteiner ou dispositivo de rede que você gerencia, chamados de "nodes". O cliente consulta periodicamente a política e o estado mais recentes da sua rede do servidor Chef. Se algo no nó estiver desatualizado, o cliente o atualizará.
 
|-
 
|-
|'''Puppet'''
+
| colspan="2" |'''Puppet'''
|
 
 
|O Puppet é uma excepcional solução de DevOps para a automação de workloads de infraestrutura e aplicativos, e o gerenciamento contínuo destes. Muito frequentemente o Puppet é usado como ferramenta para gerenciamento de configurações, operando através de uma sofisticada arquitetura Master x Slave.
 
|O Puppet é uma excepcional solução de DevOps para a automação de workloads de infraestrutura e aplicativos, e o gerenciamento contínuo destes. Muito frequentemente o Puppet é usado como ferramenta para gerenciamento de configurações, operando através de uma sofisticada arquitetura Master x Slave.
 +
Em curtas palavras, é composto de uma linguagem declarativa para expressar a configuração do sistema, um cliente e servidor para distribuí-lo, e uma biblioteca para realizar a tarefaa de configuração pretendida.
 
|-
 
|-
|'''Python'''
+
| colspan="2" |'''SaltStack'''
|
 
|Python é uma linguagem de programação interpretada, orientada a objetos e de alto nível, com uma semântica dinâmica, e sintaxe simples e fácil de aprender.  O Python suporta módulos e pacotes, o que incentiva a modularidade do programa e a reutilização de código.
 
É certamente um dos "queridinhos" dos times de DevOps para as necessidades de automação de infraestruturas de redes.
 
|-
 
|'''SaltStack'''
 
|
 
 
|O SaltStack ou "Salt" é uma ferramenta de gerenciamento e orquestração de configurações, fornecendo um repositório central para provisionar novos servidores e outras infraestruturas de TI, incluindo a instalação de softwareem servidores físicos, virtuais e cloud.
 
|O SaltStack ou "Salt" é uma ferramenta de gerenciamento e orquestração de configurações, fornecendo um repositório central para provisionar novos servidores e outras infraestruturas de TI, incluindo a instalação de softwareem servidores físicos, virtuais e cloud.
  
Linha 246: Linha 285:
 
Os usuários do Salt podem escrever seus próprios scripts e programas e fazer o download de configurações pré-construídas que outros usuários contribuíram para um repositório público.
 
Os usuários do Salt podem escrever seus próprios scripts e programas e fazer o download de configurações pré-construídas que outros usuários contribuíram para um repositório público.
 
|-
 
|-
|'''Ruby'''
+
| colspan="2" |'''OpenStack'''
|
 
|Ruby é uma linguagem de programação interpretada multiparadigma, de tipagem dinâmica e forte e com gerenciamento de memória automático, e frequentemente utilizado como linguagem de script.
 
Seu criador (Yukihiro “Matz” Matsumoto) juntou o "melhor dos mundos" de suas liguagens favoritas (Perl, Smalltalk, Eiffel, Ada, and Lisp) para a criação do Ruby. Muitos projetos bastante atraentes são baseados no Ruby, entre eles o The Metasploit Framework, Sass, Rails, Sinatra, Homebrew, Dicourse, Jekyll, Vagrant e Chef, para citar alguns exemplos.
 
|-
 
|'''OpenStack'''
 
|
 
 
|O OpenStack é um sistema operacional em nuvem que controla grandes pools de recursos de computação, armazenamento e rede em um datacenter, todos gerenciados e provisionados por meio de APIs com mecanismos de autenticação comuns. É impossível citar o termo "SDN" sem que o nome OpenStack seja lembrado.
 
|O OpenStack é um sistema operacional em nuvem que controla grandes pools de recursos de computação, armazenamento e rede em um datacenter, todos gerenciados e provisionados por meio de APIs com mecanismos de autenticação comuns. É impossível citar o termo "SDN" sem que o nome OpenStack seja lembrado.
 
|-
 
|-
|'''OpenDaylight'''
+
| colspan="2" |'''OpenDaylight'''
|
 
 
|O OpenDaylight (ODL) é uma plataforma aberta modular para a personalização e automação de redes de qualquer tamanho, porte e escala. O Projeto OpenDaylight surgiu do movimento SDN, com um foco claro na programação da rede. Foi desenvolvido desde o início como base para soluções comerciais que abordam uma variedade de casos de uso em ambientes de rede existentes.
 
|O OpenDaylight (ODL) é uma plataforma aberta modular para a personalização e automação de redes de qualquer tamanho, porte e escala. O Projeto OpenDaylight surgiu do movimento SDN, com um foco claro na programação da rede. Foi desenvolvido desde o início como base para soluções comerciais que abordam uma variedade de casos de uso em ambientes de rede existentes.
 
|-
 
|-
|'''OpenContrail''' '''(Tungsten Fabric)'''
+
| colspan="2" |'''OpenContrail''' '''(Tungsten Fabric)'''
|
 
 
|O Tungsten Fabric é uma solução de SDN para redes multicloud e automação multi-stack, e de código aberto. Utilizado para fornecer conectividade segura para workloads virtuais, conteiners ou bare-metal. Possui ótima integração com OpenStack, VMware vCenter, Kubernetes e Redhat Openshift.
 
|O Tungsten Fabric é uma solução de SDN para redes multicloud e automação multi-stack, e de código aberto. Utilizado para fornecer conectividade segura para workloads virtuais, conteiners ou bare-metal. Possui ótima integração com OpenStack, VMware vCenter, Kubernetes e Redhat Openshift.
 
|-
 
|-
|'''OpenFlow'''
+
| colspan="2" |'''Kubernetes'''
|
+
|Kubernetes é um formidável sistema de orquestração de conteiners open source que automatiza a implantação, o dimensionamento e a gestão de aplicações em conteiners. Foi originalmente projetado pelo Google, e agora é mantido pela Cloud Native Computing Foundation. É um "must have" em ambientes onde conteiners são fundamentais para os projetos de infraestrutura.
|O OpenFlow não é uma solução em si, mas sim um protocolo que permite que os controladores de rede determinem o caminho os pacotes em uma rede, e operando no regime de separação entre os planos de controle e de dados, além de permitir o acionamento de ações periféricas tais como listas de controle de acesso (ACLs), protocolos de roteamento e outros.
+
|-
 +
| colspan="2" |'''Docker, Jails, LXC, LXD, etc.'''
 +
|FreeBSD Jails, Solaris Zones, LXC, Docker, Rkt, OpenVZ e LXD, enfim, são soluções para containers, cada qual com suas particularidades, propósitos, prós e contras. Está fora do escopo dissertar sobre containers aqui, exceto reforçar que são bastante utilizados em ambientes onde a eslasticidade dos ambientes computacionais é cada vez mais exigida, assim como a cada vez maior necessidade por redução de tempo, esforços e custos.
 +
|-
 +
| colspan="2" |'''Recursos proprietários de equipamentos'''
 +
|Saiba que o software de seu próprio equipamento de rede (roteador, switch, etc.) possui recursos ou funcionalidades que servem para automatizar algum tipo de necessidade ou situação.
 +
Citarei alguns exemplos aqui:
 +
 
 +
Generic Online Diagnostic (GOLD), Cisco Smart Call Home, Cisco Auto Smartports, Cisco IOS Embedded Event Manager (EEM), Zero Touch Provisioning (ZTP), PoAP, Scheduler, TCLsh, dentre muitos outros recursos, são exemplos clássicos de ferramentas/funcionalidades orientadas a algum tipo de automação.
 +
 
 +
Em combinação com outras tecnologias, soluções ou ferramentas, das tantas citadas nesta tabela, você poderá conquistar ótimos níveis de automação para uma diversidade impressionante de casos e situações.
 +
 
 +
Antes que você me questione ou reclame por eu ter citado apenas tecnologias "Cisco" aqui, relaxe: consulte a documentação de SEU fabricante, pois é provável que você vá encontrar recursos similares para o seu equipamento!
 +
|-
 +
| colspan="2" |'''OpenFlow'''
 +
|O OpenFlow não é uma "solução" em si, mas sim uma combinação de especificações e protocolo que permite que os controladores de rede determinem o caminho os pacotes em uma rede, e operando no regime de separação entre os planos de controle e de dados, além de permitir o acionamento de ações periféricas tais como listas de controle de acesso (ACLs), protocolos de roteamento e outros.
  
 
O OpenFlow permite que equipamentos de diferentes fabricantes (ex: switches e roteadores), sendo que cada qual com suas próprias interfaces proprietárias e linguagens de script, sejam gerenciados remotamente usando um único protocolo aberto. Os inventores do protocolo consideram o OpenFlow como um facilitador de redes definidas por software (SDN).
 
O OpenFlow permite que equipamentos de diferentes fabricantes (ex: switches e roteadores), sendo que cada qual com suas próprias interfaces proprietárias e linguagens de script, sejam gerenciados remotamente usando um único protocolo aberto. Os inventores do protocolo consideram o OpenFlow como um facilitador de redes definidas por software (SDN).
Linha 273: Linha 319:
 
Apesar de bastante promissor, o OpenFlow nunca "deslanchou" como pensávamos que isto fosse acontecer um dia e, para falar a verdade, cada vez mais nos vemos mais distantes de implementá-lo em nossas infraestruturas!
 
Apesar de bastante promissor, o OpenFlow nunca "deslanchou" como pensávamos que isto fosse acontecer um dia e, para falar a verdade, cada vez mais nos vemos mais distantes de implementá-lo em nossas infraestruturas!
 
|-
 
|-
|'''Kubernetes'''
+
| colspan="2" |'''Python'''
|
+
|Python é uma linguagem de programação interpretada, orientada a objetos e de alto nível, com uma semântica dinâmica, e sintaxe simples e fácil de aprender.  O Python suporta módulos e pacotes, o que incentiva a modularidade do programa e a reutilização de código.
|Kubernetes é um formidável sistema de orquestração de conteiners open source que automatiza a implantação, o dimensionamento e a gestão de aplicações em conteiners. Foi originalmente projetado pelo Google, e agora é mantido pela Cloud Native Computing Foundation. É um "must have" em ambientes onde conteiners são fundamentais para os projetos de infraestrutura.
+
É certamente um dos "queridinhos" dos times de DevOps para as necessidades de automação de infraestruturas de redes.
 +
|-
 +
| colspan="2" |'''Ruby'''
 +
|Ruby é uma linguagem de programação interpretada multiparadigma, de tipagem dinâmica e forte e com gerenciamento de memória automático, e frequentemente utilizado como linguagem de script.
 +
Seu criador (Yukihiro “Matz” Matsumoto) juntou o "melhor dos mundos" de suas liguagens favoritas (Perl, Smalltalk, Eiffel, Ada, and Lisp) para a criação do Ruby. Muitos projetos bastante atraentes são baseados no Ruby, entre eles o The Metasploit Framework, Sass, Rails, Sinatra, Homebrew, Dicourse, Jekyll, Vagrant e Chef, para citar alguns exemplos.
 +
|-
 +
| colspan="2" |'''Application Programming Interface (API)'''
 +
|Um conjunto de requisitos que governa como um aplicativo pode ser usado por outro. Uma API expõe funções internas ao mundo externo, ou seja, permite que outros aplicativos externos utilizem a funcionalidade dentro do aplicativo. O API não é um conceito novo, já que a maioria dos aplicativos modernos tem algum tipo de API. Frequentemente usa autenticação, enquanto a comunicação geralmente usa scripts Java, Python, XML ou HTTP simples, para exemplificar alguns casos.
 +
 
 +
As APIs são extremamente fundamentais para ambientes de programabilidade, pois fornecem a devida modularidade, onde os aplicativos podem ser construídos em módulos que podem se comunicar com outros módulos por meio de uma API. Além disto, a abstração, pois permite expor parte das bibliotecas de um programa e ferramentas externas, na condição de orquestradores, os quais podem ser automatizados em um aplicativo ou infraestrutura de forma mais consistente e sem a necessidade de entender as implementações dos dispositivos da infraestrutura.
 +
 
 +
E, por fim, a automação, pois as APIs são muito importantes para as tecnologias em nuvem, assim como projetos de infraestruturas de redes bem dinâmicas e elásticas, já que permitem que os recursos e o provisionamento sejam orquestrados por meios destas.
 +
|-
 +
| colspan="2" |'''REST / RESTCONF'''
 +
|REST significa "Representational State Transfer", um estilo de arquitetura para projetar aplicativos em rede que usa HTTP/S para fazer chamadas entre entidades. O REST opera em representações de recursos, cada qual identificado por uma URL, sendo crucial para projetos de infraestrutura prevendo ampla automação de praticamente todas as suas funções. Por exemplo, APIs northbound em SDN são geralmente SDN RESTful APIs usadas para a comunicação entre a controladora SDN e os tantos serviços e aplicativos em execução na rede. Essas APIs podem ser usadas para facilitar a orquestração e automação eficientes da rede para o alinhamento com as necessidades de diferentes aplicações, e fazendo isto via esta capacidade de programabilidade da rede SDN.
 +
O RESTCONF é um draft do IETF que procura descrever como mapear uma especificação Yang para uma interface RESTful. Os dados de resposta podem ser em formato JSON ou XML, cujas as estruturas, nestes casos, seguem de acordo com o JSON-YANG e XML-YANG, respectivamente.
 +
|-
 +
| colspan="2" |'''NETCONF'''
 +
|O NETCONF é um protocolo usado para a configuração e monitoramento de dispositivos de redes, e é descrito no <nowiki>RFC 6241</nowiki>. Embora possa ser usado para o monitoramento da rede, a grande vantagem do NETCONF está realmente nas questões envolvendo o gerenciamento de configurações.
 +
 
 +
Anteriormente ao NETCONF, qual era praticamente a nossa única opção para automatizarmos as tarefas de configuração nos elementos da rede? CLI. Linha de comando.
 +
 
 +
Basicamente dependíamos de algumas (ou várias!) gambiarras envolvendo scripts para o lançamento de configurações nos elementos de rede. Em alguns casos, para os mais afortunados, equipados com algumas soluções e componentes proprietários, tais como interfaces Linux embarcadas nos equipamento (tipo guestshell), CLI scraping, NX-OS (proprietário nos switches Nexus), dentre outros casos, conseguíamos resultados mais interessantes. O problema com abordagens envolvendo CLI e scripts, mesmo que, de certa forma, "automatizados", é a completa ausência de mecanismos de transações, e isto é crítico quando lidando com o provisionamento de serviços fim a fim. E é onde o NETCONF dá um banho.
 +
 
 +
O NETCONF utiliza dados em formato XML, e anda lado a lado com o Yang, que será apresentado logo a seguir.
 +
 
 +
O NETCONF é o que de fato promoveu excepcional capacidade de configuração de elementos de rede para os padrões atuais, em especial a instalação, configuração e manipulação de configurações em uma rede, e é considerado por muitos (inclusive por mim) como a melhor abordagem "interface para o sul" disponível atualmente.
 +
|-
 +
| colspan="2" |'''XML'''
 +
|O XML significa "Extensible Markup Language", e é uma linguagem de marcação muito parecida com HTML, projetada para transportar dados, enquanto o HTML concentra-se mais na aparência destes dados. O XML requer que você defina suas próprias tags, além de ser projetado para ser auto-descritivo. Note que a natureza de transporte dados do XML o torna um dos formatos mais populares para a troca de dados numa infraestrutura prevendo a programabilidade. O protocolo NETCONF citado anteriormente utiliza este formato de dados.
 +
|-
 +
| colspan="2" |'''JSON'''
 +
|JSON significa "JavaScript Object Notation", que é um formato de dados que usa texto legível por humanos para transmitir objetos de dados que consistem em pares atributo-valor. O JSON é relativamente bem fácil para que máquinas consigam analisar e gerar seu formato, e é construído com base em duas estruturas: pares de nome / valor, e lista ordenada de valores. Assim como o XML, o JSON é bastante popular por ser um formato de dados de fácil leitura e parsing, e é o formato de representação de dados mais usado em REST APIs.
 
|-
 
|-
|'''Docker, Jails, LXC, LXD, etc.'''
+
| colspan="2" |'''Northbound APIs'''
|
+
|Northbound APIs ("APIs para o norte") são o elo entre os aplicações de TI, tais como os sistemas OSS e BSS, e o controlador SDN. Estas aplicações podem informar à rede sobre o que necessitam, incluindo parâmetros tais como dados, armazenamento, largura de banda, etc., fazendo com que a rede então possa fornecer estes recursos ou comunicar o que possui.
|FreeBSD Jails, Solaris Zones, LXC, Docker, Rkt, OpenVZ e LXD, enfim, são soluções para containers, cada qual com suas particularidades, propósitos, prós e contras. Está fora do escopo dissertar sobre containers aqui, exceto reforçar que são bastante utilizados em ambientes onde a eslasticidade dos ambientes computacionais é cada vez mais exigida, assim como a cada vez maior necessidade por redução de tempo, esforços e custos.
+
 
 +
Essas APIs northbound suportam uma ampla variedade de aplicativos, sendo geralmente os componentes mais moldáveis existentes em um ambiente SDN, pois existem muitas interfaces possíveis em diferentes locais das pilhas para controlar diferentes tipos de serviços por meio de uma controladora SDN.
 +
 
 +
Exemplos de serviços de rede que podem ser otimizados via interfaces norte incluem roteadores, switches, concentradores de assinantes de Internet banda larga, firewalls, balanceadores de carga, e muitos outros serviços de segurança definidos por software ou aplicativos de orquestração de recursos da nuvem.
 +
 
 +
As APIs Northbound também são usadas para integrar a controladora SDN com pilhas de automação, tais como Puppet, Chef, SaltStack, Ansible e CFEngine, além de plataformas de orquestração, como OpenStack, vCloudDirector da VMware ou CloudStack, de código aberto do Apache.  
 +
 
 +
Nestes casos, o objetivo é abstrair o funcionamento interno da rede, para que os desenvolvedores de aplicações possam conectar-se à rede visando fazer alterações para acomodar as necessidades da aplicação.
 +
 
 +
O maior e melhor exemplo de interface norte aqui seria por Representational State Transfer (REST) API, o qual é baseado em URIs (Uniform Resource Identifier, ou seja, URLs de tipo específico), transportados por protocolo HTTP/S e utilizando rotineiramente o formato de dados em JSON. Há muitas vantagens ao considerar este tipo de interface norte. Outros casos menos conhecidos incluem SMASH, IPMI, WSMAN, e SOAP, mas a lista não para por aí.
 
|-
 
|-
|'''Recursos proprietários de equipamentos'''
+
| colspan="2" |'''Southbound APIs'''
|
+
|Equanto uma API Northbound (ou interface para o norte) é uma interface que permite que um componente específico de uma rede se comunique com um componente de nível superior, a API Southbound (ou interface para o sul), por sua vez, permite que um componente de rede específico se comunique com um componente de nível inferior.
|Saiba que o software de seu próprio equipamento de rede (roteador, switch, etc.) possui recursos ou funcionalidades que servem para automatizar algum tipo de necessidade ou situação.
+
 
Citarei alguns exemplos aqui:
+
Apenas para constar: ambas as APIs northbound e southbound existem em qualquer tipo de infraestrutura de rede ou ambiente computacionai, e não necessariamente, ou não apenas, em ambientes SDN, embora a popularização da SDNs tenha aumentado essa ligação destas APIs para si.
  
Generic Online Diagnostic (GOLD), Cisco Smart Call Home, Cisco Auto Smartports, Cisco IOS Embedded Event Manager (EEM), Zero Touch Provisioning (ZTP), dentre muitos outros recursos, são exemplos clássicos de ferramentas/funcionalidades orientadas a algum tipo de automação.
+
Um exemplo clássico de API Southbound envolve as especificações para o funcionamento do protocolo OpenFlow, já apresentado previamente. Mas, conforme citado anteriormente, o OpenFlow de fato nunca deslanchou como achávamos que fosse acontecer, então citarei aqui um exemplo melhor: NETCONF! Nada melhor que citar o NETCONF/Yang para ilustrar o conceito de APIs Southbound! Outro exemplo mais antigo e bastante conhecido disto é o Cisco OnePK.
  
Em combinação com outras tecnologias, soluções ou ferramentas, das tantas citadas nesta tabela, você poderá conquistar ótimos níveis de automação para uma diversidade impressionante de casos e situações.
+
Exemplo mais "pobres" (ou menos sofisticados e flexíveis que o NETCONF, por exemplo) de interfaces para o sul seria invocação por procedimentos SSH e SNMP
 +
|-
 +
| colspan="2" |'''Software-Defined Networking (SDN)'''
 +
|Uma rede definida por software (SDN) é uma arquitetura que visa tornar as redes mais ágeis e flexíveis, fornecendo melhor controle sobre a rede, e permitindo que as empresas e os ISPs consigam responder mais rapidamente às mudanças nos requisitos dos negócios. Com um exemplo bem simples e prático, em um ambiente SDN o administrador da rede pode manipular o tráfego a partir de uma console de controle centralizado, ou seja, sem precisar tocar em equipamentos individuais. Esse processo é um desacoplamento da arquitetura de rede tradicional, na qual dispositivos de rede individuais tomam decisões de tráfego com base em suas tabelas de roteamento configuradas. Uma representação típica da arquitetura SDN compreende três camadas: a camada de aplicação, a camada de controle e a camada de infraestrutura.
 +
|-
 +
| colspan="2" |'''Network Functions Virtualization (NFV)'''
 +
|Embora ambos SDN e NFV realizem a abstração da rede, são conceitos completamente distintos. O NFV é uma abordagem de virtualização dos serviços e funções de rede, os mesmos serviços e funções que são encontrados em equipamentos tradicionais baseados em hardware dedicado, porém implementando estas funções em hardware "''commodity''". Com o NFV, funções tais como roteamento, firewalls, load balancing, e outros, chamadas de Virtual Network Functions (VNFs), são empacotados na forma de máquinas virtuais (VMs) e embarcados em hardware de missão genérica. Desta forma, múltiplas destas VNFs podem ser adicionadas para servidores x86 convencionais (por favor, ao menos dimensione estes servidores adequadamente...), assegurando um tanto de agilidade e economia de custos. Uma vez que o servidor físico geralmente já encontra-se integrado à rede (ex: cabeamento e afins), a agilidade de provisionamento destes VNFs é um tanto notória, além de contribuir para a consolidação de infraestruturas e para a consequente redução de custos. Em outras palavras, o processo fica bastante simplificado.
 +
|}
 +
Ufa, hein!
 +
 
 +
Que tal ilustrarmos alguns destes (principais) componentes?[[Arquivo:Bpf-prog-tools.png|centro|miniaturadaimagem|814x814px|Alguns exemplos ou casos de ferramentas e soluções orientadas aos princípios de programabilidade]]De todas as coisas citadas na mega-tabela anterior, focaremos a seguir somente nos componentes que possuem relação direta com '''''<u>infraestrutura de redes</u>'''''.
  
Antes que você me questione ou reclame por eu ter citado apenas tecnologias "Cisco" aqui, relaxe: consulte a documentação de SEU fabricante, pois é provável que você vá encontrar recursos similares para o seu equipamento!
+
==== A integração entre dispositivos de redes, gerenciamento de configurações e pilhas de orquestração ====
 +
Já que o artigo tem como principal proposta falarmos de programabilidade e com foco no gerenciamento de configurações, talvez seja prudente comentar aqui as principais diferenças entre algumas das conhecidas soluções para esta necessidade. Lembra que eu comentei anteriormente que, em muitos casos, as plataformas de gerenciamento não atendem integralmente às nossas necessidades, especialmente no que diz respeito ao gerenciamento de configurações? Pois bem, é nessa hora que vale a pena considerar ótimas soluções para administrarmos isto. As mais conhecidas são o Chef, Puppet, Ansible e Salt. A tabela a seguir fornece um comparativo "raso" entre eles.
 +
{| class="wikitable"
 +
|+
 +
!
 +
!Chef
 +
!Puppet
 +
!Ansible
 +
!Salt
 +
|-
 +
|'''Template'''
 +
|Cookbook/Recipe
 +
|Manifest
 +
|Playbook
 +
|States/Pillars
 +
|-
 +
|'''Linguagem'''
 +
|Extensão do Ruby
 +
|Linguagem customizada semelhante ao JSON com opção Ruby
 +
|YAML
 +
|YAML
 +
|-
 +
|'''Licença'''
 +
|Apache
 +
|Apache
 +
|GPL
 +
|Apache
 +
|-
 +
|'''Agente'''
 +
|Requerido
 +
|Requerido
 +
|Não requerido
 +
|Não requerido, porém recomendado ("Minions")
 +
|-
 +
| colspan="5" |Confira os comparativos entre as diversas soluções deste tipo aqui:
 +
|-
 +
| colspan="5" |https://en.wikipedia.org/wiki/Comparison_of_open-source_configuration_management_software
 
|}
 
|}
[[Arquivo:Bpf-prog-tools.png|centro|miniaturadaimagem|1042x1042px|Alguns exemplos ou casos de ferramentas e soluções orientadas aos princípios de programabilidade]]
+
O Puppet em ação
 +
[[Arquivo:Bpg-prog-puppet.png|centro|miniaturadaimagem|800x800px]]
  
 
==== O que é e o que não é o Software-Defined Networking (SDN) ====
 
==== O que é e o que não é o Software-Defined Networking (SDN) ====

Edição das 03h08min de 18 de janeiro de 2020

Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes

Autor: Leonardo Furtado

Introdução

Este artigo apresentará os fundamentos mais importantes acerca do gerenciamento de infraestruturas de redes e pavimentará a sua jornada, caro leitor da Wiki do BPF, para as questões de programabilidade de infraestruturas de redes e com foco aos ambientes de ISP. Este é mais um daqueles artigos que publico aqui onde a principal intenção ou motivação é a de ensinar, educar, e capacitar e, portanto, o artigo não vai direto ao ponto: conto uma história primeiro, volto no tempo para mostrar algumas coisas e eventos importantes e, lá para o final, é que comento com mais propriedade sobre os aspectos de programabilidade pretendidos por este artigo. Esta abordagem mais didática poderá ser melhor apreciada por leitores mais "leigos".

Espero que você curta a leitura deste artigo tanto quanto eu curti para produzi-lo!

Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes: comparando a rede ideal versus os modelos tradicionais

Pré-requisitos

A leitura deste artigo fará muito mais sentido caso você reúna determinados pré-requisitos em termos de conhecimentos técnicos. Recomendo que certifique-se de possuir os conhecimentos equivalentes aos temas discutidos nos seguintes artigos, já publicados na Wiki do Brasil Peering Forum (BPF).

Revisão dos principais conceitos e componentes de uma infraestrutura de redes Metro e IP

Para começarmos com o pé direito, que tal fazermos uma boa revisão sobre os principais componentes e conceitos presentes em uma infraestrutura de redes? Ao término do artigo, talvez esta seção tenha sido bastante útil para você entender melhor as complicações no que diz respeito à manutenção das infraestruturas de redes e como as tecnologias e ferramentas de programabilidade poderão drasticamente atenuar os esforços e custos operacionais.

Dispositivos de rede

Em uma rede de ambiente ISP (aka "service provider") é comum encontrarmos os seguintes tipos de equipamentos ou elementos ativos, que são referências aos dispositivos de rede:

  • Roteadores: devidamente categorizados por suas funções e missões, em especial em alinhamento com uma infraestrutura de redes hierárquica, modular e estruturada, ou seja roteadores de Acesso, Pré-Agregação, Agregação, Core, Borda de Serviços e Borda de Internet, e também os roteadores de clientes, sejam estes de propriedade do ISP (comodato) ou mantidos pelo próprio cliente. Aqui entram os termos CE ou CPE (Customer Premises Equipment), PE (Provider Edge), P (Provider), e cada um destes, além de seu respectivo posicionamento na hierarquia topológica física e lógica da rede, desempenhando funções tais como LSR (Label Switch Router), LER (Label Edge Router), BNG (Broadband Network Gateway), dentre outros casos.
  • Switches: praticamente a mesma coisa com relação aos roteadores no que diz respeito ao seus posicionamentos em uma rede, hierarquia e afins. Podendo ser elementos ativos desempenhando funções de encaminhamento de dados puramente de Camada 2 (L2), neste caso o processamento dos quadros (frames), ou multicamadas (L3), neste caso o processamento de pacotes, em ambientes Ethernet ou Ethernet + IP nativos, ou ainda em ambientes MPLS.
  • GPON: neste caso aqui, sumarizando os dispositivos desta infraestrutura, tais como OLT (Optical Line Terminal), ONU (Optical Network Unit), ONT (Optical Network Terminal), e, por que não, toda a parte passiva (leia-se: não ativa) da infraestrutura, denominada Optical Distribution Network (ODN), e que incluem as fibras ópticas e passivos ópticos, como splitters, conectores, cordões, extensões, caixas de emenda e terminação.
Dispositivos de rede Metro Ethernet, IP, MPLS: roteadores e switches

Protocolos e serviços de infraestruturas de redes

Uma coisa são os dispositivos de redes mencionados anteriormente, outra coisa são as tecnologias (embarcadas nestes dispositivos) que viabilizam o funcionamento de uma rede, em especial no que diz respeito à comunicação necessária entre os elementos ativos para o efetivo transporte do tráfego da rede e dos serviços contratados por seus usuários. Nem de longe atreverei-me a listar tudo, pois isto seria obviamente inviável! Tentemos sintetizar os exemplos a serem citados aqui, pois uma versão completa disso seria quilométrica!

O arranjo destas tecnologias, devidamente organizadas em suas respectivas categorias funcionais, é que costumo chamar de "Salada de Tecnologias"!

  • Protocolos e serviços de camada 2 (L2): em referência ao modelo de referência OSI (RM-OSI) ou ao modelo TCP/IP, são tecnologias primariamente envolvidas na viabilidade de uma infraestrutura redundante (com foco na maior disponibilidade) isenta de bridging loops, e com capacidades de recuperação de falhas envolvendo enlaces de transmissão ou dos próprios elementos de rede. Exemplos de tecnologias assim: Spanning Tree Protocol (e suas variações, 802.1d (STP), 802.1w (RSTP), 802.1s (MSTP), 802.1aq (Shortest Path Bridging (SPB), e revisões incorporadas ao 802.1Q-2014), Resilient Ethernet Protocol (REP, proprietário), Ethernet Automatic Protection Switching (EAPS, proprietário), G.8032 (Ethernet Ring Protection (ERP) protocol), coexistência de Inter-Chassis Communication Protocol (ICCP) e STP, etc. E, claro, não poderia deixar de mencionar aqui o mais óbvio, que são tecnologias mais básicas e elementares tais como o próprio endereçamento físico (Media Access Control (MAC)) dos dispositivos, Virtual LAN (VLAN), entroncamento 802.1q e 802.1ad (Q-in-Q), etc. E isto focando apenas no óbvio, pois há uma gama muito grande de tecnologias e serviços que implementam funções ou que atuam na camada 2. E, para concluir, L2VPN (VPLS, VPWS, EVPN) também são exemplos de tecnologias para o transporte de tráfego/serviços L2 em uma rede MPLS (VPLS/VPWS) ou MPLS ou VxLAN (EVPN). Generic Routing Encapsulation (GRE), Layer 2 Tunneling Protocol (L2TP), Layer 2 Protocol Tunneling (L2PT), Point-to-Point Tunneling Protocol (PPTP) são outros exemplos clássicos e empregando conceitos de túneis.
  • Protocolos e serviços de camada 3 (L3): também em alinhamento ao RM-OSI, são tecnologias que tem como propósito a construção e manutenção de uma rede IP "roteada". Enquadram-se aqui o endereçamento IPv4 e IPv6, protocolos de roteamento dinâmicos (ex: OSPF, IS-IS, EIGRP, BGP, RIPv2 para IPv4, e RIPng, OSPFv3, IS-IS for IPv6, EIGRP for IPv6, BGP para o IPv6), além de rotas conectadas, rotas estáticas, serviços de roteamento por políticas (PBR, ABF ou nome similar usado pelo seu fabricante de equipamento). Enquadram-se também, à título de serviços L3, mas com algumas destas tecnologias implementando funções também em outras camadas, os seguintes: Network Address Translation (NAT), Carrier Grade NAT (CGN), Broadband Network Gateway (BNG, como concentrador PPPoE e/ou IPoE).
  • Protocolos e serviços orientados à confiabilidade, resiliência e disponibilidade: compreenda estes como serviços periféricos e pensados para melhorarmos a confiabilidade geral da infraestrutura, seja em cenários L2 ou L3, ou ainda ambos. Exemplos de tecnologias que enquadram-se aqui temos o Unidirectional Link Detection (UDLD), Bidirectional Forwarding Detection (BFD), In-Service Software Upgrade (ISSU), Online Insertion and Removal (OIR), Stateful Switchover (SSO), Nonstop Forwarding (NSF) ou Graceful Restart (GR), Non Stop Routing (NSR), MPLS Traffic Engineering Fast Reroute (FRR), Topology Independent LFA (TI-LFA) e RLFA, Segment Routing TI-LFA (SRTILFA), Link Aggregation Control Protocol (LACP), enfim, são exemplos clássicos. Outros exemplos aqui incluem os protocolos de resiliência de primeiro salto ou de default gateway, conhecidos por FHRP (First Hop Redundancy Protocol), tais como o HSRP (Hot Standby Router Protocol), VRRP (Virtual Router Redundancy Protocol) e GLBP (Gateway Load Balancing Protocol). Isto para não mencionar os mecanismos periféricos presentes em outros protocolos já apresentados, tais como o OSPF LSA e SPF Throttling, BGP Prefix Independent Convergence (PIC), etc.
  • Protocolos e serviços de suporte à infraestrutura: enquadram-se aqui protocolos e serviços tais como o PPPoE (Point-to-Point Protocol over Ethernet), IPoE (Internet Protocol over Ethernet), DHCP (Dynamic Host Configuration Protocol), DNS (Domain Name System), AAA (Authentication, Authorization, Accounting), RADIUS (Remote Authentication Dial In User Service), TACACS+ (Terminal Access Controller Access-Control System), Diameter, NTP (Network Time Protocol), PTP (Precision Time Protocol), SyncE (Synchronous Ethernet), e outros. As tecnologias com foco no Quality of Service (QoS) também podem ser descritas aqui.
  • Protocolos e serviços de gerenciamento: figuram aqui, dentre tantos, o Simple Network Management Protocol (SNMP), Remote Network MONitoring (RMON) MIB, Netflow, Internet Protocol Flow Information Export (IPFIX), Telnet, Secure Shell (SSH), SSH File Transfer Protocol (SFTP), Operations, Administration and Maintenance (OAM) incluindo Ethernet OAM Link Fault Management (EOAM LFM), 802.1ag Connectivity Fault Management (CFM), Ethernet Local Management Interface (E-LMI), Ethernet Performance Management, MPLS OAM; Network Configuration e modelos Yang (NETCONF/Yang), interface RESTful para a modelagem Yang com RESTCONF, Technical Report 069 (TR-69) e substitutos, dentre tantos outros protocolos, serviços e procedimentos.
  • Protocolos e serviços de segurança da infraestrutura: há tantos casos para citar aqui, tentarei ser mais prático. Port Security, 802.1X IBNS, Network Admission Control (NAC), Private VLAN, Dynamic ARP Inspection (DAI), DHCP Snooping, IP Source Guard (IPSG), Root Guard, BPDU Guard, BPDU Filtering, mecanismos de autenticação dos protocolos de roteamento, mecanismos de autenticação de protocolos MPLS (LDP e RSVP-TE), filtros e políticas de roteamento, BGP Flowspec, Remotely Triggered Black Hole (RTBH), stateful packet filtering, BGP Resource Public Key Infrastructure (RPKI), Control Plane Policing (CoPP/dCoPP), Broadcast, Unicast and Multicast (BUM) Storm Control, limitação de prefixos mantidos em tabelas de roteamento, Unicast Reverse Path Forwarding (uRPF), e tantas outras. E isto com relação às tecnologias, pois devem ser considerados também os appliances (dispositivos) de segurança que embarcam estas tecnologias e serviços, tais como firewalls, UTMs, etc.
Que "salada" de tecnologias! É tanta coisa que temos que nos preocupar em fazer funcionar corretamente e conforme as boas práticas!

Sistemas e serviços de suporte à infraestrutura

A lista de situações aqui é mais simples, mas não menos complexa:

  • Sistemas de Suporte ao Negócio (BSS)
  • Sistemas de Suporte à Operação (OSS)
  • Serviços de Diretório (ex: LDAP, Active Directory)
  • Infraestrutura Public Key Infrastructure (PKI)
  • Sistema IP Address Management (IPAM)
  • Sistemas específicos para fins de gerenciamento de elementos e de infraestrutura (EMS e NMS), com baixa ou parcial aderência aos padrões OSS.
  • Etc.
Exemplo de integrações de sistemas OSS e BSS, demonstrando a solução IBM Catalog Driven Order Management Solution. Note o "SID", um dos padrões do TM Forum Frameworx!
OBS: no segmento de ISPs regionais de pequeno e médio portes é onde compreendemos, também, uma diferença bastante acentuada entre os padrões de sistemas empregados por estes quando comparados aos sistemas de gestão operacional e de negócios dos operadores de redes "grandes". Nos ISPs regionais, é muito mais comum o uso de sistemas específicos que operam de forma completamente independente e com nenhuma ou mínima troca ou compartilhamento de dados entre si, para lidar com as necessidades gerais, técnicas e operacionais inclusive, mesmo que sendo funcionais para a realidade desta empresas. No entanto, a ausência das devidas e desejadas integrações entre estes sistemas (vide Frameworx (eTOM BPF, SID, TAM, TNA)) dificulta ou literalmente inviabiliza uma solução legitimamente projetada para fins de automação, orquestração e provisionamento, exigindo que ocorram, quase que para todos os casos e situações, ações diretas com intervenção humana sobre os equipamentos (por meios de acessos via CLI, por exemplo) para a ativação ou provisionamento de serviços de clientes.

Áreas sistêmicas das arquiteturas de roteadores e switches

Tantos destes protocolos e serviços de rede citados na seção anterior precisam ser selecionados e configurados por você, um por um, e conforme diretivas do seu projeto técnico (ex: configurações homologadas, boas práticas, validação de sintaxe e semântica, etc.) para que possam convergir e fornecer o transporte e a efetiva viabilidade dos serviços e produtos contratados pelos clientes. Para fazer toda a coisa acontecer, há um determinado arranjo de dependências entre as tecnologias necessárias onde, em muitos casos, para que uma determinada tecnologia que você configurou possa funcionar, são necessários o suporte e o funcionamento de outras tecnologias e serviços, as quais, por sua vez, precisarão ser também pensadas, projetadas, e configuradas por... você! Para exemplificar aqui, para que o BGP de seu AS possa operar é necessário o roteamento recursivo para o transporte das sessões IBGP e a devida resolução do atributo NEXT_HOP das rotas mantidas pelo BGP, e isto significa que você precisará adotar um protocolo de roteamento interior (IGP), provavelmente o OSPF aqui, o qual, por sua vez, depende de endereçamento IP, definição das tecnologias de enlace (VLANs, entroncamentos, etc.) e das tecnologias de transmissão (L1). Ou seja, uma coisa depende da outra.

Em particular, roteadores e switches em uma rede mantém áreas sistêmicas e funcionais para os propósitos de conectividade e de serviços:

  • Plano de Controle: área sistêmica responsável por hospedar protocolos que forneçam entendimento e convergência para fins de encaminhamento de tráfego L2 (ex: STP, REP, EAPS...) e L3 (ex: OSPF, IS-IS, BGP, etc.), e até mesmo "L2.5" (ex: MPLS). Não somente os protocolos são mantidos nesta área, mas também as suas respectivas estruturas de dados, tais como o Link-State Database (LSDB) do OSPF, o Label Information Base (LIB) do MPLS LDP, a BGP Table do BGP, e a própria tabela de roteamento IP (Routing Information Base ou RIB) do roteador.
  • Plano de Dados: área sistêmica responsável por hospedar as estruturas de dados especificamente orientadas ao processamento e efetivo encaminhamento de pacotes, tais como a Forwarding Information Base (FIB) ou Forwarding Table, Label Forwarding Information Table (LFIB), Adjacency Table (ADJ) ou similar, isto no caso dos roteadores, e Content Addressable Memory (CAM) ou MAC Table, no caso dos switches, além de outras estruturas de dados que possam servir para funções adicionais da cadeia de processamento de pacotes, geralmente organizadas em TCAMs (Ternary Content Addressable Memory), para o acionamento de manipulações de cabeçalhos, QoS, ACL, etc.
  • Plano de Gerenciamento: responsável por hospedar e manter os serviços de gerenciamento do dispositivo, tais como Telnet, SSH, SNMP, NETCONF, HTTP server, Syslog, NTP, etc.
  • Plano de Serviços: responsável por manter processos relacionados ao RADIUS, TACACS+, PPPoE, IPoE, IPsec, NAT, QoS, Stateful Firewall, AVC, etc.

É importante salientar que o modelo de computação em rede tradicional é completamente distribuído, ou seja, que estas áreas sistêmicas supracitadas são independentes e localmente significantes para cada dispositivo. Isto significa que o estado de informação de cada processo de software referente a um destes protocolos e serviços é mantido por cada equipamento, independentemente, podendo haver, em alguns casos, alguma integração entre equipamentos distintos para um determinado componente.

Projeto técnico compatível com o plano de negócios

Você deve ter notado a quantidade brutal de componentes e recursos tecnológicos listados até agora! No que tange aos tipos de equipamentos que você precisa utilizar, como deverão ser feitas as conexões físicas e lógicas, quais protocolos e serviços deverão ser projetados e empregados (configurados, ativados...), e tudo mais, enfim, isto dependerá muito de como o seu projeto técnico for construído, e este projeto precisa "casar" com o seu plano de negócios. A dissertação disto está fora do escopo deste artigo e por razões bem óbvias, pois seria um baita off-topic. Isto será tema para futuros artigos aqui na Wiki do BPF. Todavia, caso tenha curiosidade de saber um pouco mais sobre o tema, talvez estes dois vídeos possam ser úteis neste sentido, pois, neles, tento apresentar de forma bem objetiva estes conceitos:

É importante salientar que há muita redundância entre as tecnologias citadas previamente, particularmente no que concerne às aplicabilidades, cenários e casos de uso. Por exemplo, você não irá realmente rodar o protocolo de roteamento EIGRP no backbone do seu provedor, pois será óbvia e natural a escolha pelo protocolo de roteamento OSPF (as razões quanto a isto podem ser estudadas no artigo Boas Práticas para a Implantação do OSPF em Ambientes de ISP), embora ambos sejam protocolos de roteamento, e muito bons por sinal. Assim como, caso a sua rede de Acesso seja L2, será muito provável que você vá optar por tecnologias de resiliência Ethernet mais sofisticadas, preferindo o G.8032 ou EAPS, ao invés do protocolo Spanning Tree, mesmo que ambos sejam protocolos de resiliência destinados ao mesmo propósito (vide artigo Proteção e Resiliência em Redes L2 de Provedores para saber o por que). Assim como você optará pelo IPoE ou PPPoE, ou ainda rodando os dois serviços simultaneamente por um tempo em caráter de transição tecnológica, mas, no final das contas, é provável que você vá manter apenas o IPoE, embora ambos PPPoE e IPoE tenham como proposta a mesma missão (apenas a cumprem de formas distintas). Quanto aos protocolos FHRP, é bem provável que você vá optar pelo VRRP (até mesmo pela provável natureza multivendor da sua rede), e não o HSRP, que é uma tecnologia proprietária. A maioria absoluta das instalações de rede de Internet residencial emprega o protocolo/serviço RADIUS como um dos componentes de integração requeridos, mas a tendência é que, com o passar do tempo, vejamos cada vez mais instalações operando com o protocolo Diameter. Enfim, acho que você conseguiu me entender aqui.

Para tudo isto que escrevi acima, o que escolher, o que adotar, "o que comer, o que vestir", enfim, tudo isto requer amplo planejamento e boas práticas para a manutenção do ciclo de vida do projeto (Iniciação, Planejamento, Execução, Monitoramento e Controle, Encerramento). Isto será discutido futuramente em outros artigos aqui em nossa Wiki.

Qual é a relação entre a "seção de revisão de componentes tecnológicos" deste artigo e os objetivos propostos pelo mesmo?

Talvez você esteja se perguntando: "Tá, Leonardo, mas.... o que tem isso a ver?".

Em primeiro momento, informo que nem todos os leitores de nossa Wiki são profissionais altamente experientes quanto você, nobre leitor! Há indivíduos que nos visitam aqui que já reportaram dificuldades em absorver conhecimentos mais avançados ou complexos, e que estão em processo de aperfeiçoamento de carreira. Para este perfil de nosso público, tenho certeza que as informações apresentadas na seção anterior são tidas como muito úteis e, portanto, achei prudente lembra-los da magnitude em termos de quantidade e diversidade de componentes, conceitos, procedimentos e especificações tipicamente encontrados nas redes de service providers.

A pergunta que faço agora: como você projeta, implementa (as tecnologias, protocolos, serviços, etc.), opera (a manutenção geral), suporta (diagnóstico, troubleshooting), e provisiona clientes e seus respectivos produtos contratados?

Na grande maioria dos casos, a coisa não funciona por pura e simples "mágica", e quase tudo depende de ações e intervenções humanas. Aposto que hoje, no seu ambiente, mais de 95% de tudo o que a sua rede precisa fazer é fruto de uma configuração realizada inteiramente pelas mãos de um operador da sua rede, um profissional de operações (NOC), provisionamento ou da engenharia! O camarada foi lá e configurou elemento por elemento, "na mão", e todo o ambiente é mantido assim, desta forma.

Cada vez que você tiver que adicionar um novo elemento/equipamento na sua rede, como você faz? Cada vez que você precisa suportar novos prefixos IP, como você lida com as modificações nas suas políticas de roteamento? Cada vez que você precisa ativar um cliente corporativo para um produto do seu ISP, como você faz para provisionar este serviço? Ativar uma L2VPN ponto a ponto ou multiponto, ou uma extensão entre data centers (Data Center Interconnect), ou uma L3VPN (simple, complex, managed services, e Internet), ou um serviço SD-WAN gerenciado e em combinação com proteção de DNS e outros "mimos"? E com relação ao assinante residencial, como você faz? Tenho certeza que hoje a maior parte destes processos, pra não citar "todos", é manual ou, no melhor caso, uma ação humana realizada sobre algum tipo de ferramenta que atenua estes esforços, mas que, mesmo assim, precisa ser realizada sobre diversos equipamentos da infraestrutura.

Para efeitos comparativos aqui: nos melhores casos e envolvendo grandes empresas do setor de tecnologia, quando você contrata uma plataforma como serviço (PaaS) ou uma infraestrutura como serviço (IaaS) de uma destas consagradas empresas globais, você realmente acredita que alguém recebe um email (referente a sua solicitação) e o encaminha internamente para as áreas técnicas para que estes mobilizem qualquer atividade de ativação manualmente, tais como a instalação de equipamentos, instalação e atualização de software, configuração de dispositivos e serviços? Claro que não! Nestes perfis de organizações, tudo isso é orquestrado e automatizado a partir do momento em que você passa o seu cartão de crédito durante o procedimento de subscrição!

E é justamente sobre este tema é que passaremos a dissertar a partir de agora neste artigo, sendo este o nosso foco.

A relação entre este artigo e os frameworks e modelos de gerenciamento de infraestruturas de ambientes ISP

Não dissertarei detalhadamente sobre os frameworks em questão, pois haverá oportunidades sobre este tema em outros artigos do Brasil Peering Forum. Irei ao ponto logo ao término dessa seção.

Talvez você queira aprofundar-se um pouco mais sobre esta área com a leitura do artigo Frameworks de Indústria para a Reestruturação e Profissionalização do ISP, caso não tenha feito isso ainda.

Há muitos anos o ITU-T introduziu o termo Telecommunications Management Network (TMN) para a descrição de uma rede dedicada com interfaces orientadas ao gerenciamento de redes de telecomunicações, e buscando definir os pontos de interconexão entre as duas redes, além de especificar as diversas funcionalidades de gerenciamento. A proposta deste framework foi ilustrar as áreas funcionais distintas e como estas deveriam interoperar. E isto foi originalmente especificado pelo ITU-T M.3400 e X.700, em especial a classificação das funcionalidades de gerenciamento, mas sem a descrição detalhada dos componentes destas funções, algo que foi tratado mais apropriadamente por outros padrões periféricos mais específicos e que nasceram mais ou menos no mesmo período.

Por sua vez, o FCAPS é um modelo de gerenciamento de redes produzido pela ISO, e não pelo ITU-T, descrito inicialmente como Working Drafts (N1719) da norma ISO 10040, e com o intuito de definir cinco padrões de protocolos distintos, sendo cada um para uma área funcional específica. Posteriormente, dadas as similaridades entre muitas funções pretendidas por estes protocolos, os cinco foram consolidados em um só (Common Management Information Protocol ou CMIP). No entanto, a coisa não parou por aí, e muitas evoluções ocorreram, até que o próprio ITU-T, nos anos 90, passasse a integrar o FCAPS como parte de seu framework TMN. Esta integração entre TMN e FCAPS está mostrada na ilustração logo abaixo.

Posteriormente, o FCAPS evoluiu para o que chamamos de FAB (Fulfillment, Assurance, Billing), conforme definido pelo framework Business Process Framework (BPF), que foi bem esclarecido no mapa eTOM apresentado no artigo "Frameworks de Indústria para a Reestruturação e Profissionalização do ISP", publicado em nossa Wiki. Ou seja, resumindo aqui, tanto a ISO quanto o ITU-T tinham propostas e modelos bastante interessantes para compreendermos as questões associadas ao gerenciamento de infraestruturas, e houve este esforço ou intenção de ambas as partes para que o melhor dos dois mundos pudessem se encontrar, promover uma certa unificação e direcionamento para os melhores resultados para a indústria. No que concerne ao FCAPS em si, para todos os efeitos, as classificações das funções de gerenciamento para cada uma das áreas de negócios e funcionais de um ISP foram inicialmente especificadas pelo FCAPS da ISO, posteriormente integradas pelo TMN da ITU-T, e aprimoradas e portadas para o eTOM BPF. Atualmente, o framework BPF é um dos frameworks do Frameworx, criado e mantido pelo TM Forum.

Visualização da integração entre TMN e FCAPS, e a ênfase no conceito de Configuration, que será o foco do artigo a partir deste ponto

A relação entre eTOM BPF ou FAB ou FCAPS, enfim, e este artigo, é buscar capacitá-los com informações fundamentais sobre o Gerenciamento de Configurações de uma rede de ISP.

Por que o FCAPS é útil, inclusive para o nosso artigo aqui? Assim como temos o hábito de usarmos frequentemente o modelo de referência OSI (RM-OSI), ou seja, aquelas 7 camadas (Física, Enlace de Dados, Rede, Transporte, Sessão, Apresentação e Aplicação) para ensinarmos os fundamentos de redes para profissionais da área ou indivíduos que estejam começando nela, usamos também o FCAPS para este mesmo propósito, que é o de ensinar e capacitar, só que, neste caso, sobre os conceitos e fundamentos de gerenciamento de infraestruturas!

O FCAPS, mesmo que o "original" esteja um pouco defasado (pois hoje está incorporado, mais amplo e melhor especificado no eTOM BPF), é uma excelente ferramenta de aprendizado! Por este motivo decidi escrever um pouco a respeito dele nesta seção do artigo. Quer ensinar redes para alguém? O modelo de referência OSI é ótimo para isso! Quer ensinar fundamentos de gerenciamento de redes? O FCAPS é certamente um dos recursos mais interessantes e valiosos para concebermos estes ensinamentos!

Para concluir, a sequência deste artigo estará centrada no Gerenciamento de Configurações (o "C" do modelo FCAPS). Além do artigo, você talvez tenha interesse em consultar a recomendação ITU-T G.7710/Y.1701 (08/2019) - Common Equipment Management Function Requirements para ampliar seus horizontes.

Como o gerenciamento de configurações é realizado pela maioria dos ISPs regionais de pequeno e médio portes

É de amplo conhecimento que, em parâmetros tecnológicos, os provedores de acesso à Internet de pequeno e médio portes evoluíram muito de uns anos para cá. Em termos de sofisticação de equipamentos e tecnologias, estes ISPs tem "encostado" nos grandes operadores de rede, geralmente ficando as principais diferenças entre ambos os perfis nas questões associadas ao porte dos equipamentos utilizados (capacidade, densidade, quantidade, volume), tamanhos das áreas de concessão, tamanho da base de assinantes, sendo estas diferenças até bastante expressivas, mas não no tipo ou na qualidade da tecnologias empregadas. E, nas questões administrativas, claro, a quantidade de colaboradores, o orçamento, áreas internas do negócio, e diversos outros casos que não convém elencar no momento.

Mas há uma diferença muito significativa, importantíssima, e que tem a ver com o que este artigo propõe-se a discutir: o gerenciamento da infraestrutura como um todo, incluindo frameworks, processos, procedimentos, metodologias, integrações, o tanto de programabilidade, automação e orquestração, os respectivos padrões de ferramentas empregadas... e isto são algumas das principais comparações operacionais e procedurais que faço quando analisando um operador de redes de grande porte e um ISP regional de pequeno ou médio porte, quanto a estes quesitos.

No que diz respeito ao gerenciamento de configurações, mais especificamente quando um ISP regional de menor porte precisa ativar ou provisionar um novo serviço, geralmente são necessários os seguintes procedimentos (estou generalizando aqui):

  1. Se a manobra tiver que incluir a instalação física de um novo equipamento em um site/Pop do ISP, conduzir e documentar um Projeto Provisório de Instalação (PPI) ou Projeto Definitivo de Instalação (PDI), juntamente com os demais procedimentos homologados pela Engenharia da empresa, tais como Plano de Instalação e Ativação, etc.
    1. Sejamos realistas: a instalação física de um equipamento não pode ser automatizada! (exceto, talvez, por robôs, o que não será o nosso caso tão cedo)
  2. Configuração de equipamento para a sua efetiva integração com a rede, o que, por sua vez, normalmente ou quase sempre, exige a condução de outros procedimentos aprovados pela Engenharia da empresa, em particular a atualização do software para a versão homologada e a condução de um extenso roteiro/script contendo os parâmetros de configuração, apoiados por artefatos tais como um Plano de Instalação e Configuração Lógica.
    1. Aqui temos a primeira oportunidade de automação e orquestração, via métodos de provisionamento tais como o de zero toque ou "Zero Touch Provisioning", os quais propõem-se a simplesmente exigir do profissional lá no site/Pop a energização e cabeamento/conectorização das portas do equipamento, que a rede automaticamente se encarregará de todo o resto e fornecerá a configuração definitiva do equipamento.
  3. Em seguida, o provisionamento do serviço do cliente! É aqui que você terá que "visitar" a CLI (linha de comando) de vários equipamentos para realização das configurações necessárias para a viabilidade fim-a-fim do serviço contratado pelo assinante, e geralmente apoiado por um formato pré-estabelecido para aquele tipo de produto/configuração. Ou seja, definir as VLANs, entroncamentos de VLAN, os mecanismos de controle de admissão à rede, recursos de segurança, endereços IP, roteamento, QoS, policies, etc., e fazendo isto para as tecnologias requeridas, caso a caso, sobre todo e qualquer dispositivo exigido para a viabilidade quanto à "ativação" (fim a fim) daquele produto que aquele assinante contratou.
    1. Talvez uma das áreas operacionais mais frágeis da organização seja exatamente esta baixa aderência quanto às boas práticas regidas pelo "C" do FCAPS, ou seja, da disciplina de gerenciamento de configurações! Muito frequentemente, para não dizer "quase sempre", é um processo estritamente manual e associado a custos mais elevados, maiores esforços e complexidades operacionais, maiores riscos de incidentes e downtime (decorrentes de falha humana durante o processo de configuração de elementos de rede), dentre muitas situações eventual e obviamente indesejadas.
    2. E é aqui que enxergo uma excelente oportunidade para os ISPs regionais poderem se modernizar!
  4. O serviço que foi ativado (produto + assinante) é testado e validado, e posicionado para produção em caráter definitivo. A partir deste ponto, a Operação da rede (ex: NOC) deverá ficar responsável por assegurar que as métricas do SLA contratado sejam respeitados, tais como capacidade, consumo de banda dentro do perfil, latência, jitter, perda de pacotes, disponibilidade/uptime, etc.
    1. Outra seara repleta de procedimentos manuais e ferramentas dissimilares que não "conversam" entre si, não compartilham dados, e fica bem mais difícil encontrar uma utilidade real para os sistemas de gerenciamento de elementos (EMS) e de rede (NMS), como partes integrantes ou isoladamente dos sistemas de suporte a operação (OSS) da organização.
    2. Aqui é onde enxergo outra excelente oportunidade para a modernização das infraestruturas e processos dos ISPs regionais!
O roteiro tradicional de implantação e provisionamento de serviços de um ISP

Introdução aos conceitos da disciplina de configurações

Realmente pretendo pular a parte referente aos conceitos de IT Service Management (ITSM), e um tanto do que a versão 3 do ITIL (Information Technology Infrastructure Library) aborda neste sentido. Voltaremos aqui ao que importa, e o FCAPS é mais apropriado para dissertarmos a respeito disto.

Na questão de "Configurações", o FCAPS é centrado em um bocado de coisas, mas dá para sumarizar suas principais funções da seguinte forma:

  1. Inicialização do Serviço
  2. Provisionamento do Serviço
  3. Auto-descoberta (de elementos e suas capacidades e propriedades, topologias, etc.)
  4. Backup e restauração (obviamente incluindo muitas capacidades e facilidades aqui, tais como diff-check, dry-run, etc.)
  5. Desligamento de recursos (quando não são mais necessários, ou por mudança de perfil de assinante (ex: bloqueado, cancelado))
  6. Gestão de mudanças (os processos e ferramentas para a "GMUD").
  7. Pré-provisionamento
  8. Gerenciamento de inventário (não somente a parte do hardware inteiro, mais também os módulos, acessórios, software, licenças, etc.)
  9. Cópia de configurações
  10. Configuração remota
  11. Atualização automática de software (incluindo funcionalidades que maximizem a disponibilidade dos dispositivos, compliance de software, etc.)
  12. Iniciação, rastreamento e execução de job

Ou seja, tudo para viabilizar os controles necessários para implementar a configuração inicial dos elementos da rede e seus respectivos componentes, sincronismo e monitoramento dos parâmetros de configuração empregados; distribuição de tarefas de configuração com o auxílio de templates, configuração de propriedades avançadas sobre os elementos da rede (proteção e resiliência, VLANs, entroncamentos, QoS, etc.), manutenção e auditoria de configurações, e tantos outros.

A arquitetura Equipment Management Function (EMF) proposta pelo ITU-T com relação ao FCAPS fornece as recomendações sobre como os sistemas de gerenciamento de elementos (EMS) gerenciam as funções de elementos de redes (NEF), ao interagir com funções atômicas da camada de transporte e sincronização (AF), e fazendo isto através da troca de informações de gerenciamento (MI) sobre os pontos de gerenciamento (MP); esse "tequiniquês" é abordado no ITU-T G.806, ITU-T X.701 e ITU-T X.720, enfim, suprimamos isso aqui. Talvez eu deva ao menos fornecer uma noção visual destes conceitos:

Ilustração de conceitos FCAPS tais como NEF, EMF, MAF, MCF, MI e MP (Fonte: ITU-T)

Em termos mais práticos, isto significa que você precisa considerar para a sua infraestrutura as devidas funções de gerenciamento para cada uma áreas recomendadas pelo FCAPS (ou eTOM BPF, neste caso), observando como os sistemas de negócios da empresa estão mapeados para os sistemas mais técnicos e operacionais, e como estes sistemas mais técnicos-operacionais interagem com a infraestrutura para aditivar as tecnologias, as quais, por sua vez, darão apoio direto aos resultados tanto técnicos quando os de negócios. Aquela tão desejada aderência...

Você basicamente possui dois caminhos possíveis, dependendo do perfil do seu ambiente em termos de "vendor":

  • Rede homogênea: se a sua rede contiver dispositivos e soluções de apenas um fabricante, você muito provavelmente poderá utilizar as ferramentas/sistemas ou soluções daquele fabricante para as necessidades de gerenciamento de configurações. Aliás, não somente configurações, mas também a parte de desempenho, falhas/incidente, segurança, etc. Ou seja, as plataformas de gerenciamento desenvolvidas pelo fabricante para aquela classe de produtos que você tem na sua rede. Desnecessário comentar que são soluções proprietárias, certo? Não que isto seja algo ruim, mas é bom deixar isto bem claro.
  • Rede heterogênea: se a sua rede contiver um mix de soluções e de vários fabricantes, você terá bem mais dificuldades. Na maioria dos casos, você terá que rodar múltiplos sistemas de gerenciamento para acomodar cada uma das áreas funcionais previstas pelo FCAPS através deste cenário multivendor. É muito pouco provável que a plataforma de gerenciamento de um determinado fabricante vá suportar bem os equipamentos de outros fabricantes, principalmente quando o assunto for gerenciamento de configurações. E, caso haja esse suporte, ele quase sempre ou fatalmente será limitado, ou possuirá algumas chatas restrições.

Em muitos casos, nos vemos forçados a usar uma solução para gerenciar os elementos da marca "A", outra solução de gerenciamento para os elementos da marca "B", mais uma solução para gerenciar os elementos da marca "C", e uma ou mais soluções open source (ou não) para monitorar componentes em comum das marcas "A", "B" e "C", como ocorre frequentemente para a parte de gerenciamento de desempenho e gerenciamento de falhas/incidentes, onde soluções tais como PRTG, Zabbix, Libre NMS, etc., são bastante populares. Eu particularmente vejo muita fragilidade e inconvenientes aqui, pois raramente estes sistemas integram bem com sistemas de outros fabricantes, exceto, talvez, e dependendo do caso, via extensas e complexas integrações por Common Object Request Broker Architecture (CORBA), do Object Management Group (OMG), algo que já vi acontecer um bocado em ambientes de telecom. Um porre!

Que tal darmos uma praticidade para estes argumentos?

  • O Winbox da Mikrotik não vai gerenciar configurações de um equipamento Cisco ou Juniper (pelo menos não que eu saiba! KKKKKKK).
  • O Cisco Prime LAN Management Solution não vai gerenciar configurações de elementos de rede de classe corporativa não-Cisco.
  • O Cisco Application Policy Infrastructure Controller (APIC) possui alguma integração com soluções específicas (Check Point, Palo Alto Networks, Fortinet Inc, Radware – DefensePro, A10 Networks, Avi Networks, Citrix Systems, F5 Networks, Radware – Alteon VA e VX), mas não para todos os recursos e funções que talvez você necessite para o seu projeto.
  • O Cisco Adaptive Security Device Manager (ASDM) só serve para gerenciar dispositivos de segurança ASA da Cisco.
  • O Cisco Network Services Orchestrator (NSO) implementa zero funções de gerenciamento de falhas ou desempenho, mas talvez seja a única solução comercial que consegue orquestrar o provisionamento de serviços fim a fim sobre qualquer equipamento e de qualquer vendor (a não ser que o seu equipamento não seja realmente lá grandes coisas...).
  • O Junos Space Network Management Platform da Juniper consegue integrar alguns dispositivos de terceiros como elementos gerenciados, mas, "guess what?", há restrições de funcionalidades.
  • O HPE Intelligent Management Center Enterprise da HP permite adicionar alguns elementos externos/de terceiros, tais como o switch Cisco Nexus, e integrações com Aruba Airwave (faz sentido, pois houve a aquisição aqui), ClearPass e HPE OneView. O que exatamente é suportado ou quais são as restrições aqui, eu desconheço no momento.
  • O Zabbix pode ser ótimo para necessidades de gerenciamento de falhas/incidentes e de performance/desempenho, até mesmo porque é amplamente customizável. Agora experimente conduzir a disciplina de gerenciamento de configurações com esta ferramenta, e você verá que é simplesmente inviável.
  • O Libre NMS é outro exemplo clássico, idêntico ao caso do Zabbix, assim como de outras ferramentas bem conhecidas do mercado.
  • O ManageEngine ou o PRTG são outros ótimos exemplos para as questões de gerenciamento de falhas e de desempenho, mas não são funcionais para o gerenciamento de configurações.

Como você pode notar, muito frequentemente os sistemas que nós utilizamos não atendem bem a todas as nossas necessidades, e nos vemos forçados a contar com 3 ou 4 soluções de gerenciamento para manter a infraestrutura funcionando. Sistemas, estes, que funcionam de forma completamente independente, como "ilhas" mesmo, isolados, e com mínima ou zero troca de dados entre si. Para falhas e desempenho, isto é até "aceitável". Mas, para o gerenciamento de configurações, isto é inaceitável!

A ilustração a seguir fornece exemplos de soluções mapeadas para as áreas do FCAPS, para que você tenha essa noção de que alguns fabricantes procuram especificar as funções de suas soluções de gerenciamento para ficarem mais "alinhadas" com as recomendações do FCAPS. Os exemplos não são completos e tampouco estão atualizados 100%, mas acho que você compreenderá a essência.

(Fonte: snmpserver.com)

E é por esta razão que a indústria está convergindo cada vez mais para os princípios de programabilidade, pois os modelos de gerenciamento tradicionais não mais correspondem às nossas expectativas!

Agora, há uma terceira opção aqui, que seria considerar soluções comerciais (destes mesmos fabricantes ou de terceiros) em combinação com outras iniciativas que entendam melhor as nossas necessidades e que sejam capazes de promover melhor aderência. Uma grande verdade aqui é muitos dos sistemas "fechados" não atende integralmente as nossas necessidades! E é nessa hora onde ferramentas e soluções de programabilidade poderão ser bem mais efetivas para os nossos propósitos. É nessa hora que pensamos em Ansible, Chef, Puppet, Salt, outras ferramentas de programabilidade, embarcadas ou não em ambientes SDN, etc.

Compreendendo a programabilidade de infraestruturas

Tentarei ser muito objetivo ao explicar logo a seguir algumas verdades, assim como aproveitar a oportunidade para esclarecer algumas "inverdades", sobre este universo envolvendo programabilidade, orquestração, automação, provisionamento, SDN, NFV, etc. Vamos lá?

  • O provisionamento é essencialmente a intenção de ativação de um serviço para o ISP ou, bem mais frequentemente, para seus clientes.
    • Este provisionamento de um serviço (ex: um L2VPN "LAN-to-LAN" ou "DCI", uma L3VPN, um serviço de Internet, etc.) pode ser realizado manualmente (como é feito normalmente na maioria dos casos envolvendo os ISPs regionais) ou de forma bem mais "programável"; orquestrada e automatizada.
    • Geralmente referimos o conceito à ativação de um serviço fim-a-fim e que vá envolver diversas tecnologias (L2, L3, outros) e em vários dispositivos de rede, homogêneos (mesmo padrão de sintaxe e semântica) ou heterogêneos (diferentes vendors, ou CLIs, sintaxes, etc.).
    • O provisionamento pode ser também uma coisa bem mais específica e pontual (um pequeno bloco de configuração a ser programado em um único dispositivo, por exemplo).
  • A orquestração é a capacidade tecnológica de habilitar serviços envolvendo ações de provisionamento sobre a infraestrutura, que poderá abranger ou contemplar somente a rede, ou, então, por exemplo, rede + computação + storage + plataforma/apps, frequentemente tocando em componentes multivendor, para um determinado produto ou serviço desejado, seja este para atender uma necessidade interna, do próprio ISP, ou para atender a uma solicitação ou contratação por parte de um cliente/assinante.
    • A orquestração é muito desejada em qualquer tipo de situação, mas, sem sombra de dúvidas, é mais desejável ainda em ambientes heretogêneos (ex: multivendor).
  • A automação é o estado operacional desejado para que estas ações de configuração e provisionamento de serviços (e até mesmo nos casos de diagnósticos ou suporte a falhas) na infraestrutura envolvam "zero" ou o mínimo possível de ações humanas.
    • Desejavelmente, a automação deve estar contida na orquestração, pois, por exemplo, do contrário, não fará muito sentido "juntar as peças de sistemas dissimilares" (alçada da orquestração) se você tiver que executar os blocos do contrato manualmente depois, na CLI ou GUI/WebUI de vários equipamentos.
    • A orquestração e automação devem andar lado a lado.
      • Em muitos casos, o contrato do serviço pode ser desenhado na forma de templates e acionados por ações nos sistemas da companhia, onde, num simples frontend, os parâmetros são preenchidos/fornecidos para que, no backend, a rede seja acionada para receber as configurações devidas e concluir todo o provisionamento. Neste cenário, não há o envolvimento de analistas na linha de comando (CLI) ou em plataformas específicas de provisionamento (EMS/GUI/WebUI).
      • Em outros casos, o provisionamento é feito em sistemas específicos para este propósito e poderá exigir algum padrão de intervenção técnica, por exemplo, a execução de scripts ou acionamentos de funções mais técnicas em sistemas específicos, mas exigindo pouco ou nada em termos de uma intervenção por CLI ou GUI/WebUI dos dispositivos.
  • A programabilidade tem relação com a afinidade de tecnologias, processos, ferramentas e soluções técnicas compatíveis que são empregadas para as orquestrações e automações de serviços.
    • Isto é, idealmente, o seu aparato tecnológico, incluindo hardware, software e sistemas utilizados em seu ambiente, tudo isto precisa ser compatível com o suporte à tecnologias que fomentam a orquestração e automação para a programabilidade do provisionamento fim a fim de serviços com maior fluidez, menor tempo/prazo, "zero" ou menor esforço de implementação, e menores riscos para a rede e para o negócio.
  • Praticamente em todos os casos a orquestração envolve automação, mas não o contrário: nem toda automação tem relação com orquestração.
  • Programabilidade e Software-Defined Networking (SDN), apesar de andarem lado a lado constantemente, são coisas completamente distintas.
  • Orquestração e Software-Defined Networking (SDN) são coisas distintas. Nem toda orquestração ocorre em um ambiente SDN (ex: com controladoras e soluções específicas de SDN), mas quase sempre o inverso é verdadeiro.
  • Software-Defined Networking (SDN) e Network Functions Virtualization (NFV) são coisas completamente distintas.
  • As capacidades de programabilidade da infraestrutura estão condicionadas à disponibilidade e suporte de recursos e ferramentas específicas, e isto valendo para cada equipamento.
    • Não adiantará muito controladoras SDN com suporte a OpenFlow na sua rede se os seus elementos de rede (equipamentos) forem incompatíveis. Ou, ao invés do OpenFlow, não adiantará muito (ou pelo menos ficará bem mais complicado) fazer a orquestração de serviços na rede se os seus equipamentos não suportarem o protocolo NETCONF.
  • Redes mais sofisticadas utilizam ferramentas e recursos mais arrojados para estas finalidades de programabilidade.

A ilustração a seguir mostra exemplos de recursos de programabilidade representados por funcionalidades suportadas por um determinado equipamento, assim como mostra alguns casos de tecnologias mais apropriadas para que se tenha uma rede mais programática e versátil neste sentido.

Exemplos de componentes fomentadores da programabilidade de infraestruturas

Identificando as principais soluções, ferramentas e componentes orientados aos princípios de programabilidade

Caso você tenha ficado impressionado com a "salada de tecnologias" ilustrada no início deste artigo, isto porque você talvez desconheça o turbilhão de ferramentas empregadas para fins de programabilidade, incluindo orquestração e automação! Como realmente não dá para listar todas as opções de código aberto e comercial, fornecerei aqui alguns exemplos, talvez os principais, além de citar muitas ferramentas e os principais componentes usados por estas, tais como protocolos, procedimentos e formatos de dados, onde for viável comentar neste nível. Aliás, a intenção a seguir não é realmente esmiuçar como são de fato implementadas ou inseridas nas infraestruturas. Outro aspecto importante a ser comentado é que os exemplos a seguir não funcionam "sozinhos", no sentido que, em uma rede, você precisará combinar diversas destas soluções, linguagens, ferramentas e procedimentos; e que nem tudo o que está citado a seguir depende de um ambiente SDN para acontecer. Há casos e casos, e cenários para tudo.

A ilustração a seguir mostra algumas destas soluções e ferramentas.

Descrição das principais soluções, ferramentas, procedimentos e componentes de programabilidade
Ferramenta Disponibilidade Descrição
Soluções Comerciais
VMware vSphere O vSphere é o software de virtualização de servidores líder do setor e o núcleo de um SDDC moderno. Ele ajuda você a executar, gerenciar, conectar e proteger os aplicativos em um ambiente operacional comum entre nuvens.

A solução é amplamente utilizado no mundo todo e em todo e qualquer tipo de ambiente, mesmo aqueles ambiente mais estáticos ou isentos de componentes de orquestração.

VMware vRealize VMware vRealize Suite, conhecido anteriormente pelo nome vCenter Operations Management Suite, é uma plataforma de software projetada para a comstrução de núveis heterogêneas híbridas.
Cisco APIC-EM O Cisco Application Policy Infrastructure Controller Enterprise Module (APIC-EM) é a solução de controladora SDN da Cisco para redes corporativas, atendendo tanto a LAN quanto a WAN.

A sua proposta é a de fornecer uma plataforma elástica paraa a automação, simplificação e abstração da rede, acomodando apliações que usam padrões abertos, e com suporte a northbound Representational State Transfer (REST) APIs.

Cisco DNA Center O Cisco DNA Center é uma solução que reúne componentes focados na construção de ambientes intuitivos (Intent-based Networking), em compatibilidade com as arquiteturas SDN da Cisco.

Reúne excepcionais facilidades para Projeto, Policy, Provisionamento, Assurance e integração com outras plataformas, e com foco em ambientes corporativos.

Cisco Application Centric Infrastructure (ACI) O Cisco Application Policy Infrastructure Controller (Cisco APIC) é o principal componente arquitetural da solução Cisco ACI. Ele é o ponto unificado de automação e gerenciamento para a estrutura, a aplicação de políticas e o monitoramento de integridade da solução. O controlador otimiza o desempenho e a gestão, além de operar uma estrutura multiusuário escalonável da Cisco ACI. A solução como um todo embarca outros componentes tais como a própria controladora (Cisco APIC), Cisco Cloud ACI, Cisco Virtual ACI, swiches Cisco Nexus 9000 Series, Cisco ACI Multisite Orchestrator, Cisco ACI App Center, além de ótimas integrações com outras soluções tais como AppDynamics, DNA Center e ISE. O foco do ACI está para os ambientes de data center.
Cisco Crosswork Network Automation O Cisco Crosswork Network Automation é uma solução voltada especificamente para service providers / ISPs e que reúne uma diversidade muito grande de recursoos para o gerenciamento proativo fim a fim das redes.

Embarca uma suite de componentes de machine-learning, intent-based networking, e outros, viabilizando ampla orquestração de redes plenamente automatizadas.

Cisco Network Services Orchestrator O Cisco NSO é uma solução muito robusta de abstração de infraestruturas físicas e virtuais, fornecendo excepcionais capacidades de oquestração de serviços fim a fim, e muitas facilidades de integração com APIs northbound e southbound.

O Cisco NSO pode funcionar sozinho ou em combinação ao Cisco Crosswork Network Automation.

Cisco Open SDN Controller O Cisco OSC é uma distribuição comercial do OpenDaylight para o fornecimento de agilidade e automação de infraestruturas, fazendo a abstração de ambientes de redes heterogênas para a entrega de serviços.
Microsoft System Center O Microsoft Systems Management Server é uma solução para o gerenciamento de grandes grupos de sistemas baseados no Microsoft Windows.
BMC Software A BMC é uma empresa americana bastante especializada em soluções para o gerenciamento de TI, oferecendo suporte a 92 das 100 empresas listadas na Forbes Global.

Tem conquistado o reconhecimento como Líder no Quadrante Mágico da Gartner em ITSM por cinco anos consecutivos.

A BMC possui sofisticadas soluções para o grenciamento multi-cloud, automação e DevOps, segurança e conformidade, otimização de TI, inteligência artificial e machine learning, e gerenciamento de serviços.

Suas soluções são frequentemente encontradas em grandes e bem sucedidos empreendimentos, e possui ótimas capacidades de integração com infraestruturas de redes.

Juniper Contrail A solução Contrail Controller da Juniper Networks é um produto de automação tipo open cloud que implementa tecnologias SDN para a orquestração e criação de redes virtuais altamente escaláveis. É fruto da aquisição da Contrail em dezembro de 2010.

O Contrail pode ser utilizado por service providers / ISPs para agilizar o provisionamento de serviços, e também atende a muitos casos e necessidades de empresas do segmento corporativo.

A solução é projetada para operar em uma máquina virtual (VM) que possui integração com Kubernetes, OpenShift, Mesos, OpenStack, VMware vSphere, e facilidades de integração com sistemas OSS e BSS.

Huawei Agile SDN Controller O controlador Agile para campus é a última geração de controladores da Huawei para redes de campus e de ramificação. Utilizado em diversas soluções inovadoras, como implantação de rede automática, automação de política e SD-WAN.

O controlador Agile para campus reduz as despesas operacionais (OPEX) e os custos de operações e manutenção (O&M) das empresas, aceleram a mudança dos serviços para a nuvem e a transformação digital, além de tornar o gerenciamento de rede mais ágil e os procedimentos de O&M de rede mais inteligentes.

Soluções de Código Aberto, Ferramentas, Sistemas, Linguagens, Protocolos, Procedimentos e Formatos de Dados
Ansible O Ansible é uma ferramenta de provisionamento, gerenciamento de configurações e implantação de aplicativos de software livre. É executado em muitos sistemas semelhantes ao Unix e pode configurar sistemas semelhantes ao Unix e também o Microsoft Windows.

O Ansible pode automatizar três tipos de tarefas: provisionamento, gerenciamento de configurações, automação de aplicações. É bastante utilizado tanto em projetos de infraestruturas de redes quanto nas questões relacionadas a servidores e aplicações.

O Ansible não usa agentes e nenhuma infraestrutura de segurança personalizada adicional, apenas uma linguagem muito simples (YAML, na forma de Ansible Playbooks) que permite descrever seus trabalhos de automação de uma maneira que se aproxima bastante do inglês comum. É uma ferramenta bastante popular!

Chef Chef é uma ferramenta de gerenciamento de configurações escrita em Ruby e Erlang. O Chef usa uma linguagem específica de domínio, pura em Ruby, para escrever "receitas" na configuração do sistema.

O Chef transforma a infraestrutura em código, onde você pode automatizar a criação criar, implantação e gerenciamento da sua infraestrutura, e de forma bastante versátil, testável e repetível quanto o código do aplicativo. O servidor Chef armazena suas receitas e outros dados de configuração.

O cliente Chef fica instalado em cada servidor, máquina virtual, conteiner ou dispositivo de rede que você gerencia, chamados de "nodes". O cliente consulta periodicamente a política e o estado mais recentes da sua rede do servidor Chef. Se algo no nó estiver desatualizado, o cliente o atualizará.

Puppet O Puppet é uma excepcional solução de DevOps para a automação de workloads de infraestrutura e aplicativos, e o gerenciamento contínuo destes. Muito frequentemente o Puppet é usado como ferramenta para gerenciamento de configurações, operando através de uma sofisticada arquitetura Master x Slave.

Em curtas palavras, é composto de uma linguagem declarativa para expressar a configuração do sistema, um cliente e servidor para distribuí-lo, e uma biblioteca para realizar a tarefaa de configuração pretendida.

SaltStack O SaltStack ou "Salt" é uma ferramenta de gerenciamento e orquestração de configurações, fornecendo um repositório central para provisionar novos servidores e outras infraestruturas de TI, incluindo a instalação de softwareem servidores físicos, virtuais e cloud.

O SaltStack automatiza tarefas repetidas de implementação administrativa e de código do sistema, eliminando processos manuais de maneira a reduzir os erros que ocorrem quando as organizações de TI configuram os sistemas.

O Salt é bastante usado nas organizações do DevOps porque extrai o código do desenvolvedor e as informações de configuração de um repositório de código central, como o GitHub ou o Subversion, e envia esse conteúdo remotamente para os servidores.

Os usuários do Salt podem escrever seus próprios scripts e programas e fazer o download de configurações pré-construídas que outros usuários contribuíram para um repositório público.

OpenStack O OpenStack é um sistema operacional em nuvem que controla grandes pools de recursos de computação, armazenamento e rede em um datacenter, todos gerenciados e provisionados por meio de APIs com mecanismos de autenticação comuns. É impossível citar o termo "SDN" sem que o nome OpenStack seja lembrado.
OpenDaylight O OpenDaylight (ODL) é uma plataforma aberta modular para a personalização e automação de redes de qualquer tamanho, porte e escala. O Projeto OpenDaylight surgiu do movimento SDN, com um foco claro na programação da rede. Foi desenvolvido desde o início como base para soluções comerciais que abordam uma variedade de casos de uso em ambientes de rede existentes.
OpenContrail (Tungsten Fabric) O Tungsten Fabric é uma solução de SDN para redes multicloud e automação multi-stack, e de código aberto. Utilizado para fornecer conectividade segura para workloads virtuais, conteiners ou bare-metal. Possui ótima integração com OpenStack, VMware vCenter, Kubernetes e Redhat Openshift.
Kubernetes Kubernetes é um formidável sistema de orquestração de conteiners open source que automatiza a implantação, o dimensionamento e a gestão de aplicações em conteiners. Foi originalmente projetado pelo Google, e agora é mantido pela Cloud Native Computing Foundation. É um "must have" em ambientes onde conteiners são fundamentais para os projetos de infraestrutura.
Docker, Jails, LXC, LXD, etc. FreeBSD Jails, Solaris Zones, LXC, Docker, Rkt, OpenVZ e LXD, enfim, são soluções para containers, cada qual com suas particularidades, propósitos, prós e contras. Está fora do escopo dissertar sobre containers aqui, exceto reforçar que são bastante utilizados em ambientes onde a eslasticidade dos ambientes computacionais é cada vez mais exigida, assim como a cada vez maior necessidade por redução de tempo, esforços e custos.
Recursos proprietários de equipamentos Saiba que o software de seu próprio equipamento de rede (roteador, switch, etc.) possui recursos ou funcionalidades que servem para automatizar algum tipo de necessidade ou situação.

Citarei alguns exemplos aqui:

Generic Online Diagnostic (GOLD), Cisco Smart Call Home, Cisco Auto Smartports, Cisco IOS Embedded Event Manager (EEM), Zero Touch Provisioning (ZTP), PoAP, Scheduler, TCLsh, dentre muitos outros recursos, são exemplos clássicos de ferramentas/funcionalidades orientadas a algum tipo de automação.

Em combinação com outras tecnologias, soluções ou ferramentas, das tantas citadas nesta tabela, você poderá conquistar ótimos níveis de automação para uma diversidade impressionante de casos e situações.

Antes que você me questione ou reclame por eu ter citado apenas tecnologias "Cisco" aqui, relaxe: consulte a documentação de SEU fabricante, pois é provável que você vá encontrar recursos similares para o seu equipamento!

OpenFlow O OpenFlow não é uma "solução" em si, mas sim uma combinação de especificações e protocolo que permite que os controladores de rede determinem o caminho os pacotes em uma rede, e operando no regime de separação entre os planos de controle e de dados, além de permitir o acionamento de ações periféricas tais como listas de controle de acesso (ACLs), protocolos de roteamento e outros.

O OpenFlow permite que equipamentos de diferentes fabricantes (ex: switches e roteadores), sendo que cada qual com suas próprias interfaces proprietárias e linguagens de script, sejam gerenciados remotamente usando um único protocolo aberto. Os inventores do protocolo consideram o OpenFlow como um facilitador de redes definidas por software (SDN).

Dentre outras coisas, o OpenFlow permite a administração remota de tabelas de encaminhamento de pacotes de roteadores, adicionando, modificando e removendo regras e ações de correspondência ou de incidência de pacotes. Dessa forma, as decisões de roteamento podem ser tomadas periodicamente ou ad hoc pelo controlador, e traduzidas em regras e ações com uma lifecycle configurável, que são, então, aplicadas automaticamente nas tabelas dos equipamentos.

Apesar de bastante promissor, o OpenFlow nunca "deslanchou" como pensávamos que isto fosse acontecer um dia e, para falar a verdade, cada vez mais nos vemos mais distantes de implementá-lo em nossas infraestruturas!

Python Python é uma linguagem de programação interpretada, orientada a objetos e de alto nível, com uma semântica dinâmica, e sintaxe simples e fácil de aprender. O Python suporta módulos e pacotes, o que incentiva a modularidade do programa e a reutilização de código.

É certamente um dos "queridinhos" dos times de DevOps para as necessidades de automação de infraestruturas de redes.

Ruby Ruby é uma linguagem de programação interpretada multiparadigma, de tipagem dinâmica e forte e com gerenciamento de memória automático, e frequentemente utilizado como linguagem de script.

Seu criador (Yukihiro “Matz” Matsumoto) juntou o "melhor dos mundos" de suas liguagens favoritas (Perl, Smalltalk, Eiffel, Ada, and Lisp) para a criação do Ruby. Muitos projetos bastante atraentes são baseados no Ruby, entre eles o The Metasploit Framework, Sass, Rails, Sinatra, Homebrew, Dicourse, Jekyll, Vagrant e Chef, para citar alguns exemplos.

Application Programming Interface (API) Um conjunto de requisitos que governa como um aplicativo pode ser usado por outro. Uma API expõe funções internas ao mundo externo, ou seja, permite que outros aplicativos externos utilizem a funcionalidade dentro do aplicativo. O API não é um conceito novo, já que a maioria dos aplicativos modernos tem algum tipo de API. Frequentemente usa autenticação, enquanto a comunicação geralmente usa scripts Java, Python, XML ou HTTP simples, para exemplificar alguns casos.

As APIs são extremamente fundamentais para ambientes de programabilidade, pois fornecem a devida modularidade, onde os aplicativos podem ser construídos em módulos que podem se comunicar com outros módulos por meio de uma API. Além disto, a abstração, pois permite expor parte das bibliotecas de um programa e ferramentas externas, na condição de orquestradores, os quais podem ser automatizados em um aplicativo ou infraestrutura de forma mais consistente e sem a necessidade de entender as implementações dos dispositivos da infraestrutura.

E, por fim, a automação, pois as APIs são muito importantes para as tecnologias em nuvem, assim como projetos de infraestruturas de redes bem dinâmicas e elásticas, já que permitem que os recursos e o provisionamento sejam orquestrados por meios destas.

REST / RESTCONF REST significa "Representational State Transfer", um estilo de arquitetura para projetar aplicativos em rede que usa HTTP/S para fazer chamadas entre entidades. O REST opera em representações de recursos, cada qual identificado por uma URL, sendo crucial para projetos de infraestrutura prevendo ampla automação de praticamente todas as suas funções. Por exemplo, APIs northbound em SDN são geralmente SDN RESTful APIs usadas para a comunicação entre a controladora SDN e os tantos serviços e aplicativos em execução na rede. Essas APIs podem ser usadas para facilitar a orquestração e automação eficientes da rede para o alinhamento com as necessidades de diferentes aplicações, e fazendo isto via esta capacidade de programabilidade da rede SDN.

O RESTCONF é um draft do IETF que procura descrever como mapear uma especificação Yang para uma interface RESTful. Os dados de resposta podem ser em formato JSON ou XML, cujas as estruturas, nestes casos, seguem de acordo com o JSON-YANG e XML-YANG, respectivamente.

NETCONF O NETCONF é um protocolo usado para a configuração e monitoramento de dispositivos de redes, e é descrito no RFC 6241. Embora possa ser usado para o monitoramento da rede, a grande vantagem do NETCONF está realmente nas questões envolvendo o gerenciamento de configurações.

Anteriormente ao NETCONF, qual era praticamente a nossa única opção para automatizarmos as tarefas de configuração nos elementos da rede? CLI. Linha de comando.

Basicamente dependíamos de algumas (ou várias!) gambiarras envolvendo scripts para o lançamento de configurações nos elementos de rede. Em alguns casos, para os mais afortunados, equipados com algumas soluções e componentes proprietários, tais como interfaces Linux embarcadas nos equipamento (tipo guestshell), CLI scraping, NX-OS (proprietário nos switches Nexus), dentre outros casos, conseguíamos resultados mais interessantes. O problema com abordagens envolvendo CLI e scripts, mesmo que, de certa forma, "automatizados", é a completa ausência de mecanismos de transações, e isto é crítico quando lidando com o provisionamento de serviços fim a fim. E é onde o NETCONF dá um banho.

O NETCONF utiliza dados em formato XML, e anda lado a lado com o Yang, que será apresentado logo a seguir.

O NETCONF é o que de fato promoveu excepcional capacidade de configuração de elementos de rede para os padrões atuais, em especial a instalação, configuração e manipulação de configurações em uma rede, e é considerado por muitos (inclusive por mim) como a melhor abordagem "interface para o sul" disponível atualmente.

XML O XML significa "Extensible Markup Language", e é uma linguagem de marcação muito parecida com HTML, projetada para transportar dados, enquanto o HTML concentra-se mais na aparência destes dados. O XML requer que você defina suas próprias tags, além de ser projetado para ser auto-descritivo. Note que a natureza de transporte dados do XML o torna um dos formatos mais populares para a troca de dados numa infraestrutura prevendo a programabilidade. O protocolo NETCONF citado anteriormente utiliza este formato de dados.
JSON JSON significa "JavaScript Object Notation", que é um formato de dados que usa texto legível por humanos para transmitir objetos de dados que consistem em pares atributo-valor. O JSON é relativamente bem fácil para que máquinas consigam analisar e gerar seu formato, e é construído com base em duas estruturas: pares de nome / valor, e lista ordenada de valores. Assim como o XML, o JSON é bastante popular por ser um formato de dados de fácil leitura e parsing, e é o formato de representação de dados mais usado em REST APIs.
Northbound APIs Northbound APIs ("APIs para o norte") são o elo entre os aplicações de TI, tais como os sistemas OSS e BSS, e o controlador SDN. Estas aplicações podem informar à rede sobre o que necessitam, incluindo parâmetros tais como dados, armazenamento, largura de banda, etc., fazendo com que a rede então possa fornecer estes recursos ou comunicar o que possui.

Essas APIs northbound suportam uma ampla variedade de aplicativos, sendo geralmente os componentes mais moldáveis existentes em um ambiente SDN, pois existem muitas interfaces possíveis em diferentes locais das pilhas para controlar diferentes tipos de serviços por meio de uma controladora SDN.

Exemplos de serviços de rede que podem ser otimizados via interfaces norte incluem roteadores, switches, concentradores de assinantes de Internet banda larga, firewalls, balanceadores de carga, e muitos outros serviços de segurança definidos por software ou aplicativos de orquestração de recursos da nuvem.

As APIs Northbound também são usadas para integrar a controladora SDN com pilhas de automação, tais como Puppet, Chef, SaltStack, Ansible e CFEngine, além de plataformas de orquestração, como OpenStack, vCloudDirector da VMware ou CloudStack, de código aberto do Apache.

Nestes casos, o objetivo é abstrair o funcionamento interno da rede, para que os desenvolvedores de aplicações possam conectar-se à rede visando fazer alterações para acomodar as necessidades da aplicação.

O maior e melhor exemplo de interface norte aqui seria por Representational State Transfer (REST) API, o qual é baseado em URIs (Uniform Resource Identifier, ou seja, URLs de tipo específico), transportados por protocolo HTTP/S e utilizando rotineiramente o formato de dados em JSON. Há muitas vantagens ao considerar este tipo de interface norte. Outros casos menos conhecidos incluem SMASH, IPMI, WSMAN, e SOAP, mas a lista não para por aí.

Southbound APIs Equanto uma API Northbound (ou interface para o norte) é uma interface que permite que um componente específico de uma rede se comunique com um componente de nível superior, a API Southbound (ou interface para o sul), por sua vez, permite que um componente de rede específico se comunique com um componente de nível inferior.

Apenas para constar: ambas as APIs northbound e southbound existem em qualquer tipo de infraestrutura de rede ou ambiente computacionai, e não necessariamente, ou não apenas, em ambientes SDN, embora a popularização da SDNs tenha aumentado essa ligação destas APIs para si.

Um exemplo clássico de API Southbound envolve as especificações para o funcionamento do protocolo OpenFlow, já apresentado previamente. Mas, conforme citado anteriormente, o OpenFlow de fato nunca deslanchou como achávamos que fosse acontecer, então citarei aqui um exemplo melhor: NETCONF! Nada melhor que citar o NETCONF/Yang para ilustrar o conceito de APIs Southbound! Outro exemplo mais antigo e bastante conhecido disto é o Cisco OnePK.

Exemplo mais "pobres" (ou menos sofisticados e flexíveis que o NETCONF, por exemplo) de interfaces para o sul seria invocação por procedimentos SSH e SNMP

Software-Defined Networking (SDN) Uma rede definida por software (SDN) é uma arquitetura que visa tornar as redes mais ágeis e flexíveis, fornecendo melhor controle sobre a rede, e permitindo que as empresas e os ISPs consigam responder mais rapidamente às mudanças nos requisitos dos negócios. Com um exemplo bem simples e prático, em um ambiente SDN o administrador da rede pode manipular o tráfego a partir de uma console de controle centralizado, ou seja, sem precisar tocar em equipamentos individuais. Esse processo é um desacoplamento da arquitetura de rede tradicional, na qual dispositivos de rede individuais tomam decisões de tráfego com base em suas tabelas de roteamento configuradas. Uma representação típica da arquitetura SDN compreende três camadas: a camada de aplicação, a camada de controle e a camada de infraestrutura.
Network Functions Virtualization (NFV) Embora ambos SDN e NFV realizem a abstração da rede, são conceitos completamente distintos. O NFV é uma abordagem de virtualização dos serviços e funções de rede, os mesmos serviços e funções que são encontrados em equipamentos tradicionais baseados em hardware dedicado, porém implementando estas funções em hardware "commodity". Com o NFV, funções tais como roteamento, firewalls, load balancing, e outros, chamadas de Virtual Network Functions (VNFs), são empacotados na forma de máquinas virtuais (VMs) e embarcados em hardware de missão genérica. Desta forma, múltiplas destas VNFs podem ser adicionadas para servidores x86 convencionais (por favor, ao menos dimensione estes servidores adequadamente...), assegurando um tanto de agilidade e economia de custos. Uma vez que o servidor físico geralmente já encontra-se integrado à rede (ex: cabeamento e afins), a agilidade de provisionamento destes VNFs é um tanto notória, além de contribuir para a consolidação de infraestruturas e para a consequente redução de custos. Em outras palavras, o processo fica bastante simplificado.

Ufa, hein!

Que tal ilustrarmos alguns destes (principais) componentes?

Alguns exemplos ou casos de ferramentas e soluções orientadas aos princípios de programabilidade

De todas as coisas citadas na mega-tabela anterior, focaremos a seguir somente nos componentes que possuem relação direta com infraestrutura de redes.

A integração entre dispositivos de redes, gerenciamento de configurações e pilhas de orquestração

Já que o artigo tem como principal proposta falarmos de programabilidade e com foco no gerenciamento de configurações, talvez seja prudente comentar aqui as principais diferenças entre algumas das conhecidas soluções para esta necessidade. Lembra que eu comentei anteriormente que, em muitos casos, as plataformas de gerenciamento não atendem integralmente às nossas necessidades, especialmente no que diz respeito ao gerenciamento de configurações? Pois bem, é nessa hora que vale a pena considerar ótimas soluções para administrarmos isto. As mais conhecidas são o Chef, Puppet, Ansible e Salt. A tabela a seguir fornece um comparativo "raso" entre eles.

Chef Puppet Ansible Salt
Template Cookbook/Recipe Manifest Playbook States/Pillars
Linguagem Extensão do Ruby Linguagem customizada semelhante ao JSON com opção Ruby YAML YAML
Licença Apache Apache GPL Apache
Agente Requerido Requerido Não requerido Não requerido, porém recomendado ("Minions")
Confira os comparativos entre as diversas soluções deste tipo aqui:
https://en.wikipedia.org/wiki/Comparison_of_open-source_configuration_management_software

O Puppet em ação

Bpg-prog-puppet.png

O que é e o que não é o Software-Defined Networking (SDN)

Conforme antecipado na seção anterior, não há uma dependência direta entre programabilidade e SDN, neste exato sentido, pois, por exemplo, é possível instrumentar a rede com bons padrões de automação usando ferramentas e recursos embarcados nos dispositivos da rede e sem que isto vá exigir uma adoção de SDN, e isto será discutido posteriormente neste artigo. Por outro lado, em parâmetros de eficiência de automação, o SDN possui uma relação direta com a programabilidade. Curioso, não? Para automatizar e até mesmo contar com padrões razoáveis de programabilidade na sua rede, o SDN não é necessariamente exigido. No entanto, ao considerar o SDN, este promove um padrão de programabilidade incomparável aos modelos de projetos de redes tradicionais, e isto é um fato!

A propósito, você compreende o mínimo de SDN? Para os mais leigos, isto será bastante apropriado:

  • O SDN não pode ser representado como se fosse um simples "botão", onde clica-se e temos um ambiente pronto, rodando! Não é bem por aí... e está longe de ser algo deste tipo.
  • O SDN tem como uma de suas principais propostas a atenuação drástica dos esforços e complexidades operacionais associados com o provisionamento e manutenção de infraestruturas de redes.
  • O SDN é um esforço da indústria para a caracterização de redes mais automatizadas, ágeis, elásticas, e empregando menos esforços e custos operacionais, assim como a diminuição de riscos para os negócios das empresas.
  • O SDN não obrigará que você torne-se um programador do dia para a noite, mas saber o essencial de lógica de programação e algumas linguagens de programação será muito útil para você poder destravar potenciais incríveis de seu ambiente!
  • O SDN não substituirá a necessidade da sua empresa em continuar contando com engenheiros e operadores de NOC, muito pelo contrário! Todavia, a tendência é que consolidem-se no setor os profissionais mais especializados e diferenciados. Os negócios precisam evoluir (sempre para melhor), e por que você não pode fazer o mesmo com a sua carreira?
  • O SDN busca promover uma abordagem de arquitetura que realiza uma separação bem legítima entre os planos de controle e de dados (control plane e data plane), levando o estado de informações, juntamente com a inteligência para tomadas de decisões, para um conceito logicamente centralizado. Ou seja, a centralização do estado de informações em uma zona estratégica da infraestrutura, enquanto os dispositivos de redes ficam dedicados e especializados em executar o processamento de pacotes e afins.
  • O SDN promove excepcional abstração entre a infraestrutura de rede (com seus protocolos e serviços mais básicos ou essenciais (ex: IGP da infraestrutura, o MPLS, o QoS do backbone, etc.)) e as aplicações e demais serviços da rede. Ou seja, uma separação bastante interessante entre rede underlay e rede overlay.
  • O SDN pode ser representado como um conceito de interfaces programáticas que permitem que sistemas externos influenciem no provisionamento de serviços, controle e operações da rede.
  • O SDN fornece novas formas de interação com os equipamentos e serviços da rede via controladoras e APIs (Application Programming Interface).
  • O SDN permite formidáveis capacidades de provisionamento, orquestração, automação e normalização de equipamentos e serviços.
  • O SDN pode destravar diversas barreiras do seu negócio ao permitir que agentes externos - devidamente integrados à rede - consigam influenciar nas características de seu projeto e na sua operação, promovendo melhor alinhamento entre as tecnologias empregadas e os resultados almejados pelos modelos de negócios.
  • O SDN poderá ser:
    • Uma rede onde os dispositivos retém os seus próprios planos de controle, mas que uma controladora SDN contém/mantém o estado de informação de todos os protocolos e serviços. Isto seria o exemplo de uma abordagem híbrida.
    • Uma rede onde todo o plano de controle é centralizado na(s) controladora(s) SDN, enquanto os equipamentos ficam dedicados para as funções de processamento de pacotes.

A ilustração a seguir mostra um excelente comparativo entre redes tradicionais e SDN, "for dummies" (para os leigos).

Comparativos entre redes tradicionais e SDN, para os leigos