Oi, Habr!
Neste artigo gostaríamos de falar sobre automação da infraestrutura de rede. Será apresentado um diagrama de funcionamento da rede que opera em uma empresa pequena, mas muito orgulhosa. Todas as correspondências com equipamentos de rede reais são aleatórias. Veremos um caso ocorrido nesta rede, que poderia ter levado à paralisação do negócio por um longo período e a sérios prejuízos financeiros. A solução para este caso enquadra-se muito bem no conceito de “Automação de infraestrutura de rede”. Usando ferramentas de automação, mostraremos como você pode resolver problemas complexos de forma eficaz em um curto espaço de tempo e refletiremos sobre por que esses problemas devem ser resolvidos desta forma e não de outra forma (através do console).
Aviso Legal
Nossas principais ferramentas de automação são Ansible (como ferramenta de automação) e Git (como repositório para playbooks Ansible). Gostaria de fazer uma ressalva imediata de que este não é um artigo introdutório, onde falamos sobre a lógica do Ansible ou Git, e explicamos coisas básicas (por exemplo, o que são módulos roletaski, arquivos de inventário, variáveis em Ansible, ou o que acontece quando você insere os comandos git push ou git commit). Esta história não é sobre como você pode praticar Ansible e configurar NTP ou SMTP em seu equipamento. Esta é uma história sobre como você pode resolver de forma rápida e preferencial um problema de rede sem erros. Também é aconselhável ter um bom entendimento de como a rede funciona, em particular o que é a pilha de protocolos TCP/IP, OSPF, BGP. Também tiraremos a escolha de Ansible e Git da equação. Caso ainda precise escolher uma solução específica, recomendamos fortemente a leitura do livro “Network Programmability and Automation. Habilidades para o engenheiro de rede da próxima geração" por Jason Edelman, Scott S. Lowe e Matt Oswalt.
Agora ao ponto.
Formulação do problema
Vamos imaginar uma situação: 3 horas da manhã você está dormindo profundamente e sonhando. Chamada telefónica. O diretor técnico chama:
- Sim
— ###, ####, #####, o cluster do firewall caiu e não está subindo!!!
Você esfrega os olhos, tentando compreender o que está acontecendo e imaginando como isso poderia acontecer. Ao telefone ouve-se o cabelo da cabeça do diretor se arrancando, e ele pede para ligar de volta porque o general está ligando para ele na segunda linha.
Meia hora depois, você coletou as primeiras notas introdutórias do plantão, acordou todos que podiam ser acordados. Com isso, o diretor técnico não mentiu, tudo está como está, o principal aglomerado de firewalls caiu e nenhum movimento básico do corpo o traz de volta à razão. Todos os serviços que a empresa oferece não funcionam.
Escolha um problema ao seu gosto, todos se lembrarão de algo diferente. Por exemplo, após uma atualização noturna na ausência de carga pesada, tudo funcionou bem e todos foram para a cama felizes. O tráfego começou a fluir e os buffers da interface começaram a transbordar devido a um bug no driver da placa de rede.
Jackie Chan pode descrever bem a situação.
Obrigado, Jackie.
Não é uma situação muito agradável, não é?
Vamos deixar nossa rede mano com seus pensamentos tristes por um tempo.
Vamos discutir como os eventos se desenvolverão ainda mais.
Sugerimos a seguinte ordem de apresentação do material
- Vejamos o diagrama de rede e vejamos como funciona;
- Descreveremos como transferimos configurações de um roteador para outro usando Ansible;
- Vamos falar sobre automação da infraestrutura de TI como um todo.
Diagrama de rede e descrição
Condução
Consideremos o diagrama lógico da nossa organização. Não nomearemos fabricantes de equipamentos específicos; para os fins deste artigo, isso não importa (O leitor atento adivinhará que tipo de equipamento é utilizado). Essa é apenas uma das boas vantagens de trabalhar com Ansible: na hora de configurar, geralmente não nos importamos com o tipo de equipamento. Só para entender, são equipamentos de fornecedores conhecidos, como Cisco, Juniper, Check Point, Fortinet, Palo Alto...você pode substituir por sua própria opção.
Temos duas tarefas principais para movimentar o tráfego:
- Assegurar a publicação dos nossos serviços, que são o negócio da empresa;
- Fornecer comunicação com filiais, data center remoto e organizações terceirizadas (parceiros e clientes), bem como acesso das filiais à Internet através do escritório central.
Vamos começar com os elementos básicos:
- Dois roteadores de borda (BRD-01, BRD-02);
- Cluster de Firewall (FW-CLUSTER);
- Chave central (L3-CORE);
- Um roteador que se tornará uma tábua de salvação (conforme resolvermos o problema, iremos transferir as configurações de rede do FW-CLUSTER para EMERGENCY) (EMERGENCY);
- Switches para gestão de infraestrutura de rede (L2-MGMT);
- Máquina virtual com Git e Ansible (VM-AUTOMATION);
- Um laptop no qual são realizados testes e desenvolvimento de playbooks para Ansible (Laptop-Automation).
A rede está configurada com um protocolo de roteamento OSPF dinâmico com as seguintes áreas:
- Área 0 – área que inclui os roteadores responsáveis pela movimentação do tráfego na zona EXCHANGE;
- Área 1 – área que inclui os roteadores responsáveis pela operação dos serviços da empresa;
- Área 2 – área que inclui roteadores responsáveis pelo gerenciamento de roteamento do tráfego;
- Área N – áreas de redes de agências.
Nos roteadores de borda, é criado um roteador virtual (VRF-INTERNET), no qual é instalada a visualização completa do eBGP com o AS atribuído correspondente. O iBGP é configurado entre VRFs. A empresa possui um pool de endereços brancos que são publicados nestas VRF-INTERNET. Alguns dos endereços brancos são roteados diretamente para FW-CLUSTER (endereços nos quais operam os serviços da empresa), alguns são roteados através da zona EXCHANGE (serviços internos da empresa que requerem endereços IP externos e endereços NAT externos para escritórios). Em seguida, o tráfego vai para roteadores virtuais criados em L3-CORE com endereços branco e cinza (zonas de segurança).
A rede de gerenciamento utiliza switches dedicados e representa uma rede fisicamente dedicada. A rede de gerenciamento também está dividida em zonas de segurança.
O roteador EMERGENCY duplica física e logicamente o FW-CLUSTER. Todas as interfaces nele estão desabilitadas, exceto aquelas que olham para a rede de gerenciamento.
Automação e sua descrição
Descobrimos como a rede funciona. Agora vamos dar uma olhada passo a passo no que faremos para transferir o tráfego de FW-CLUSTER para EMERGENCY:
- Desabilitamos as interfaces do switch core (L3-CORE) que o conecta ao FW-CLUSTER;
- Desativamos as interfaces no switch do kernel L2-MGMT que o conecta ao FW-CLUSTER;
- Configuramos o roteador de EMERGÊNCIA (por padrão, todas as interfaces estão desabilitadas nele, exceto aquelas associadas ao L2-MGMT):
- Habilitamos interfaces em EMERGÊNCIA;
- Configuramos o endereço IP externo (para NAT) que estava no FW-Cluster;
- Geramos solicitações gARP para que os endereços poppy nas tabelas arp L3-CORE sejam alterados de FW-Cluster para EMERGENCY;
- Registramos a rota padrão como estática para BRD-01, BRD-02;
- Crie regras NAT;
- Elevar para OSPF de EMERGÊNCIA Área 1;
- Elevar para OSPF de EMERGÊNCIA Área 2;
- Alteramos o custo das rotas da Área 1 para 10;
- Alteramos o custo da rota padrão na Área 1 para 10;
- Alteramos os endereços IP associados ao L2-MGMT (para aqueles que estavam no FW-CLUSTER);
- Geramos solicitações gARP para que os endereços poppy nas tabelas arp L2-MGMT sejam alterados de FW-CLUSTER para EMERGENCY.
Novamente voltamos à formulação original do problema. Três horas da manhã, um estresse enorme, um erro em qualquer fase pode gerar novos problemas. Pronto para digitar comandos por meio da CLI? Sim? Ok, pelo menos vá enxaguar o rosto, tomar um café e reunir força de vontade.
Bruce, por favor ajude os caras.
Bem, continuamos melhorando nossa automação.
Abaixo está um diagrama de como o manual funciona em termos Ansible. Este esquema reflete o que descrevemos acima, é apenas uma implementação específica no Ansible.
Nesta fase, percebemos o que precisa ser feito, desenvolvemos um playbook, realizamos testes e agora estamos prontos para lançá-lo.
Outra pequena digressão lírica. A facilidade da história não deve enganá-lo. O processo de escrever manuais não foi tão simples e rápido quanto pode parecer. Os testes demoraram bastante, foi criado um stand virtual, a solução foi testada várias vezes, foram realizados cerca de 100 testes.
Vamos lançar... Há uma sensação de que tudo está acontecendo muito devagar, há um erro em algum lugar, algo não vai funcionar no final. A sensação de pular de paraquedas, mas o paraquedas não quer abrir logo... isso é normal.
A seguir, lemos o resultado das operações realizadas do playbook Ansible (os endereços IP foram substituídos para fins de sigilo):
[xxx@emergency ansible]$ ansible-playbook -i /etc/ansible/inventories/prod_inventory.ini /etc/ansible/playbooks/emergency_on.yml
PLAY [------->Emergency on VCF] ********************************************************
TASK [vcf_junos_emergency_on : Disable PROD interfaces to FW-CLUSTER] *********************
changed: [vcf]
PLAY [------->Emergency on MGMT-CORE] ************************************************
TASK [mgmt_junos_emergency_on : Disable MGMT interfaces to FW-CLUSTER] ******************
changed: [m9-03-sw-03-mgmt-core]
PLAY [------->Emergency on] ****************************************************
TASK [mk_routeros_emergency_on : Enable EXT-INTERNET interface] **************************
changed: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Generate gARP for EXT-INTERNET interface] ****************
changed: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Enable static default route to EXT-INTERNET] ****************
changed: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Change NAT rule to EXT-INTERNET interface] ****************
changed: [m9-04-r-04] => (item=12)
changed: [m9-04-r-04] => (item=14)
changed: [m9-04-r-04] => (item=15)
changed: [m9-04-r-04] => (item=16)
changed: [m9-04-r-04] => (item=17)
TASK [mk_routeros_emergency_on : Enable OSPF Area 1 PROD] ******************************
changed: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Enable OSPF Area 2 MGMT] *****************************
changed: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Change OSPF Area 1 interfaces costs to 10] *****************
changed: [m9-04-r-04] => (item=VLAN-1001)
changed: [m9-04-r-04] => (item=VLAN-1002)
changed: [m9-04-r-04] => (item=VLAN-1003)
changed: [m9-04-r-04] => (item=VLAN-1004)
changed: [m9-04-r-04] => (item=VLAN-1005)
changed: [m9-04-r-04] => (item=VLAN-1006)
changed: [m9-04-r-04] => (item=VLAN-1007)
changed: [m9-04-r-04] => (item=VLAN-1008)
changed: [m9-04-r-04] => (item=VLAN-1009)
changed: [m9-04-r-04] => (item=VLAN-1010)
changed: [m9-04-r-04] => (item=VLAN-1011)
changed: [m9-04-r-04] => (item=VLAN-1012)
changed: [m9-04-r-04] => (item=VLAN-1013)
changed: [m9-04-r-04] => (item=VLAN-1100)
TASK [mk_routeros_emergency_on : Change OSPF area1 default cost for to 10] ******************
changed: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Change MGMT interfaces ip addresses] ********************
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n.254', u'name': u'VLAN-803'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+1.254', u'name': u'VLAN-805'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+2.254', u'name': u'VLAN-807'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+3.254', u'name': u'VLAN-809'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+4.254', u'name': u'VLAN-820'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+5.254', u'name': u'VLAN-822'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+6.254', u'name': u'VLAN-823'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+7.254', u'name': u'VLAN-824'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+8.254', u'name': u'VLAN-850'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+9.254', u'name': u'VLAN-851'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+10.254', u'name': u'VLAN-852'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+11.254', u'name': u'VLAN-853'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+12.254', u'name': u'VLAN-870'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+13.254', u'name': u'VLAN-898'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+14.254', u'name': u'VLAN-899'})
TASK [mk_routeros_emergency_on : Generate gARPs for MGMT interfaces] *********************
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n.254', u'name': u'VLAN-803'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+1.254', u'name': u'VLAN-805'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+2.254', u'name': u'VLAN-807'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+3.254', u'name': u'VLAN-809'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+4.254', u'name': u'VLAN-820'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+5.254', u'name': u'VLAN-822'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+6.254', u'name': u'VLAN-823'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+7.254', u'name': u'VLAN-824'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+8.254', u'name': u'VLAN-850'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+9.254', u'name': u'VLAN-851'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+10.254', u'name': u'VLAN-852'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+11.254', u'name': u'VLAN-853'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+12.254', u'name': u'VLAN-870'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+13.254', u'name': u'VLAN-898'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+14.254', u'name': u'VLAN-899'})
PLAY RECAP ************************************************************************Feito!
Na verdade, ainda não está pronto, não se esqueça da convergência de protocolos de roteamento dinâmico e do carregamento de um grande número de rotas no FIB. Não podemos influenciar isso de forma alguma. Nós esperamos. Funcionou. Agora está pronto.
E na aldeia de Vilabajo (que não quer automatizar a configuração da rede) continuam a lavar a louça. Bruce (reconhecidamente, já diferente, mas não menos legal) está tentando entender o quanto mais ocorrerá a reconfiguração manual do equipamento.
Gostaria também de me deter num ponto importante. Como podemos recuperar tudo? Depois de algum tempo, daremos vida ao nosso FW-CLUSTER. Este é o equipamento principal, não o backup, a rede deve rodar nele.
Você sente como os networkers estão começando a se esgotar? O diretor técnico ouvirá mil argumentos porque isso não deve ser feito, porque isso pode ser feito mais tarde. Infelizmente, é assim que a rede funciona a partir de um monte de remendos, peças e resquícios de seu antigo luxo. Acontece que é uma colcha de retalhos. Nossa tarefa em geral, não nesta situação específica, mas em geral em princípio, como especialistas em TI, é trazer o trabalho da rede para a bela palavra inglesa “consistência”, é muito multifacetada, pode ser traduzida como: coerência , consistência, lógica, coerência, sistematicidade, comparabilidade, coerência. É tudo sobre ele. Somente neste estado a rede é gerenciável, entendemos claramente o que funciona e como, entendemos claramente o que precisa ser alterado, se necessário, sabemos claramente onde procurar se surgirem problemas. E somente nessa rede você pode realizar truques como os que acabamos de descrever.
Na verdade, outro manual foi preparado, que retornou as configurações ao seu estado original. A lógica de seu funcionamento é a mesma (é importante lembrar que a ordem das tarefas é muito importante), para não alongar um artigo já bastante longo, decidimos não postar uma listagem da execução do playbook. Depois de realizar esses exercícios, você se sentirá muito mais calmo e confiante no futuro, além disso, quaisquer muletas que você acumulou ali se revelarão imediatamente.
Qualquer um pode nos escrever e receber as fontes de todo o código escrito, junto com todos os palybooks. Contatos no perfil.
Descobertas
Na nossa opinião, os processos que podem ser automatizados ainda não se cristalizaram. Com base no que encontrámos e no que os nossos colegas ocidentais estão a discutir, os seguintes temas são visíveis até agora:
- Provisionamento de dispositivos;
- Coleção de dados;
- Comunicando;
- Solução de problemas;
- Conformidade.
Se houver interesse, podemos continuar a discussão sobre um dos temas indicados.
Gostaria também de falar um pouco sobre automação. O que deveria ser em nosso entendimento:
- O sistema deve viver sem uma pessoa, ao mesmo tempo que é melhorado por uma pessoa. O sistema não deveria depender de humanos;
- A operação deve ser especializada. Não existe uma classe de especialistas que executem tarefas rotineiras. Existem especialistas que automatizaram toda a rotina e resolvem apenas problemas complexos;
- As tarefas padrão de rotina são realizadas automaticamente “com o toque de um botão”, nenhum recurso é desperdiçado. O resultado de tais tarefas é sempre previsível e compreensível.
E a que esses pontos devem levar:
- Transparência da infraestrutura de TI (Menos riscos de operação, modernização, implementação. Menos downtime por ano);
- A capacidade de planejar recursos de TI (Sistema de planejamento de capacidade - você pode ver quanto é consumido, quantos recursos são necessários em um único sistema, e não por cartas e visitas aos principais departamentos);
- Possibilidade de reduzir o número de funcionários de TI.
Autores do artigo: Alexander Chelovekov (CCIE RS, CCIE SP) e Pavel Kirillov. Temos interesse em discutir e propor soluções no tema automação de infraestrutura de TI.
Fonte: habr.com