ProHoster > Blog > Administración > Automatización de redes. Un caso da propia vida

Automatización de redes. Un caso da propia vida

Ola Habr!

Neste artigo queremos falar sobre a automatización da infraestrutura de rede. Presentarase un diagrama de traballo da rede que opera nunha empresa pequena pero moi orgullosa. Todas as coincidencias con equipos de rede reais son aleatorias. Analizaremos un caso acontecido nesta rede, que puido provocar unha paralización da empresa durante moito tempo e graves perdas económicas. A solución a este caso encaixa moi ben no concepto de "Automatización da infraestrutura de rede". Usando ferramentas de automatización, mostraremos como se pode resolver eficazmente problemas complexos en pouco tempo, e reflexionaremos sobre por que estes problemas deben resolverse deste xeito e non doutro xeito (a través da consola).

retratação

As nosas principais ferramentas de automatización son Ansible (como ferramenta de automatización) e Git (como repositorio de libros de xogos de Ansible). Gustaríame facer inmediatamente unha reserva de que este non é un artigo introdutorio, onde falamos da lóxica de Ansible ou Git, e explicamos cousas básicas (por exemplo, que son os roletaskimodules, ficheiros de inventario, variables en Ansible ou que ocorre cando introduce os comandos git push ou git commit). Esta historia non trata de como podes practicar Ansible e configurar NTP ou SMTP no teu equipo. Esta é unha historia sobre como pode resolver rapidamente e preferiblemente un problema de rede sen erros. Tamén é recomendable ter unha boa comprensión de como funciona a rede, en particular cal é a pila de protocolos TCP/IP, OSPF, BGP. Tamén eliminaremos a elección de Ansible e Git da ecuación. Se aínda necesitas escoller unha solución específica, recomendámosche encarecidamente a lectura do libro “Programabilidade e automatización de redes. Skills for the Next-Generation Network Engineer" de Jason Edelman, Scott S. Lowe e Matt Oswalt.

Agora ao grano.

Declaración de problemas

Imaxinemos unha situación: ás 3 da mañá, estás profundamente durmido e soñando. Chamada telefónica. O director técnico chama:

- Si?
— ###, ####, #####, o clúster do firewall caeu e non está a subir!!!
Frógase os ollos, intentando comprender o que está a suceder e imaxinar como isto podería ocorrer. No teléfono pódese escoitar o pelo da cabeza do director rasgando, e el pide que lle devolva a chamada porque o xeneral está a chamalo na segunda liña.

Media hora despois, recollestes as primeiras notas introdutorias da quenda de servizo, espertou a todos os que se podían espertar. Como resultado, o director técnico non mentiu, todo está como está, o grupo principal de cortalumes caeu e ningún movemento corporal básico o trae en razón. Non funcionan todos os servizos que ofrece a empresa.

Elixe un problema ao teu gusto, todos recordarán algo diferente. Por exemplo, despois dunha actualización durante a noite en ausencia dunha carga pesada, todo funcionou ben e todos foron para a cama contentos. O tráfico comezou a fluír e os búfers da interface comezaron a desbordarse debido a un erro no controlador da tarxeta de rede.

Jackie Chan pode describir ben a situación.

Automatización de redes. Un caso da propia vida

Grazas, Jackie.

Non é unha situación moi agradable, non?

Deixemos a nosa rede irmán cos seus tristes pensamentos por un tempo.

Imos discutir como se desenvolverán os eventos.

Suxerimos a seguinte orde de presentación do material

  1. Vexamos o diagrama de rede e vexamos como funciona;
  2. Describiremos como transferimos a configuración dun enrutador a outro mediante Ansible;
  3. Falemos da automatización da infraestrutura de TI no seu conxunto.

Diagrama de rede e descrición

O esquema

Automatización de redes. Un caso da propia vida

Consideremos o diagrama lóxico da nosa organización. Non nomearemos fabricantes de equipos específicos; para os efectos deste artigo non importa (O lector atento adiviñará que tipo de equipo se utiliza). Esta é só unha das boas vantaxes de traballar con Ansible; ao configurar, xeralmente non nos importa que tipo de equipo sexa. Só para entender, trátase de equipos de provedores coñecidos, como Cisco, Juniper, Check Point, Fortinet, Palo Alto... podes substituír a túa propia opción.

Temos dúas tarefas principais para mover o tráfico:

  1. Garantir a publicación dos nosos servizos, que son o negocio da empresa;
  2. Proporcionar comunicación con sucursais, un centro de datos remoto e organizacións de terceiros (socios e clientes), así como o acceso das sucursais a Internet a través da oficina central.

Comecemos cos elementos básicos:

  1. Dous enrutadores de fronteira (BRD-01, BRD-02);
  2. Clúster de cortalumes (FW-CLUSTER);
  3. Interruptor de núcleo (L3-CORE);
  4. Un enrutador que se converterá nun salvavidas (a medida que solucionemos o problema, transferiremos a configuración da rede de FW-CLUSTER a EMERXENCIA) (EMERXENCIA);
  5. Switches para a xestión da infraestrutura de rede (L2-MGMT);
  6. Máquina virtual con Git e Ansible (VM-AUTOMATION);
  7. Un portátil no que se realizan probas e desenvolvemento de playbooks para Ansible (Laptop-Automation).

A rede está configurada cun protocolo de enrutamento OSPF dinámico coas seguintes áreas:

  • Área 0: área que inclúe os enrutadores responsables de mover o tráfico na zona de INTERCAMBIO;
  • Área 1: área que inclúe routers responsables da operación dos servizos da empresa;
  • Área 2: área que inclúe os enrutadores responsables da xestión do tráfico do enrutamento;
  • Área N: áreas de redes de sucursais.

Nos enrutadores de fronteira, créase un enrutador virtual (VRF-INTERNET) no que se instala eBGP full view co AS correspondente asignado. iBGP está configurado entre VRF. A empresa ten un conxunto de enderezos brancos que se publican nestes VRF-INTERNET. Algúns dos enderezos brancos envíanse directamente a FW-CLUSTER (enderezos nos que operan os servizos da empresa), algúns son encamiñados a través da zona EXCHANGE (servizos internos da empresa que requiren enderezos IP externos e enderezos NAT externos para oficinas). A continuación, o tráfico vai a routers virtuais creados en L3-CORE con enderezos brancos e grises (zonas de seguridade).

A rede de xestión usa conmutadores dedicados e representa unha rede físicamente dedicada. A rede de xestión tamén está dividida en zonas de seguridade.
O router de emerxencia duplica física e lóxicamente o FW-CLUSTER. Todas as interfaces están desactivadas, excepto as que miran á rede de xestión.

A automatización e a súa descrición

Descubrimos como funciona a rede. Agora imos dar unha ollada paso a paso ao que faremos para transferir o tráfico de FW-CLUSTER a EMERGENCY:

  1. Desactivamos as interfaces do interruptor principal (L3-CORE) que o conectan ao FW-CLUSTER;
  2. Desactivamos as interfaces do interruptor do núcleo L2-MGMT que o conectan ao FW-CLUSTER;
  3. Configuramos o router de EMERXENCIA (por defecto, todas as interfaces están desactivadas nel, excepto as asociadas a L2-MGMT):

  • Activamos interfaces en EMERXENCIA;
  • Configuramos o enderezo IP externo (para NAT) que estaba no FW-Cluster;
  • Xeramos solicitudes gARP para que os enderezos de poppy nas táboas arp L3-CORE cambien de FW-Cluster a EMERGENCY;
  • Rexistramos a ruta predeterminada como estática para BRD-01, BRD-02;
  • Crea regras NAT;
  • Elevar a EMERXENCIA OSPF Área 1;
  • Elevar a EMERXENCIA OSPF Área 2;
  • Cambiamos o custo das rutas da Área 1 á 10;
  • Cambiamos o custo da ruta predeterminada na Área 1 á 10;
  • Cambiamos os enderezos IP asociados a L2-MGMT (a aqueles que estaban en FW-CLUSTER);
  • Xeramos solicitudes gARP para que os enderezos poppy nas táboas arp L2-MGMT cambien de FW-CLUSTER a EMERGENCY.

De novo, volvemos á formulación orixinal do problema. Tres da mañá, estrés enorme, un erro en calquera momento pode levar a novos problemas. ¿Estás listo para escribir comandos a través da CLI? Si? Ok, polo menos vai a lavar a cara, beber un café e reunir a túa forza de vontade.
Bruce, por favor, axuda aos mozos.

Automatización de redes. Un caso da propia vida

Ben, seguimos mellorando a nosa automatización.
A continuación móstrase un diagrama de como funciona o manual en termos de Ansible. Este esquema reflicte o que describimos anteriormente, é só unha implementación específica en Ansible.
Automatización de redes. Un caso da propia vida

Nesta fase, decatámonos do que hai que facer, elaboramos un manual, realizamos probas e agora estamos preparados para lanzalo.

Outra pequena digresión lírica. A facilidade da historia non debe enganarche. O proceso de escribir libros de xogo non foi tan sinxelo e rápido como podería parecer. As probas levaron bastante tempo, creouse un stand virtual, a solución probouse moitas veces, realizáronse unhas 100 probas.

Imos lanzar... Hai a sensación de que todo está a suceder moi lentamente, hai un erro nalgún lugar, algo non funcionará ao final. A sensación de saltar cun paracaídas, pero o paracaídas non quere abrirse de inmediato... isto é normal.

A continuación, lemos o resultado das operacións realizadas no manual de xogos de Ansible (os enderezos IP foron substituídos por motivos de segredo):

[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!

De feito, non está listo, non esquezas a converxencia de protocolos de enrutamento dinámico e a carga dun gran número de rutas no FIB. Non podemos influír nisto de ningún xeito. Agardamos. Funcionou. Agora xa está listo.

E na aldea de Vilabajo (que non quere automatizar a configuración da rede) seguen lavando a louza. Bruce (de certo, xa diferente, pero non por iso menos xenial) está a tentar comprender canto máis se realizará a reconfiguración manual do equipo.

Automatización de redes. Un caso da propia vida

Tamén me gustaría determe nun punto importante. Como podemos recuperar todo? Despois dun tempo, recuperaremos o noso FW-CLUSTER. Este é o equipo principal, non o backup, a rede debe executarse nel.

Sentes como os networkers comezan a esgotarse? O director técnico escoitará mil argumentos por que non se debe facer isto, por que se pode facer despois. Desafortunadamente, así é como funciona a rede a partir dunha morea de parches, pezas e restos do seu antigo luxo. Resulta que é unha colcha de retazos. A nosa tarefa en xeral, non nesta situación específica, pero en xeral en principio, como especialistas en informática, é levar o traballo da rede á fermosa palabra inglesa "coherencia", é moi multifacética, pódese traducir como: coherencia , coherencia, lóxica, coherencia, sistematicidade, comparabilidade, coherencia. É todo sobre el. Só neste estado é manexable a rede, entendemos claramente o que funciona e como, entendemos claramente o que hai que cambiar, se é necesario, sabemos claramente onde buscar se xorden problemas. E só nesta rede podes realizar trucos como os que acabamos de describir.

En realidade, preparouse outro libro de xogos, que devolveu a configuración ao seu estado orixinal. A lóxica do seu funcionamento é a mesma (é importante lembrar que a orde das tarefas é moi importante), para non alongar un artigo xa bastante longo, decidimos non publicar unha lista da execución do playbook. Despois de realizar tales exercicios, sentirase moito máis tranquilo e seguro no futuro, ademais, as muletas que acumulases alí revelaranse inmediatamente.

Calquera pode escribirnos e recibir as fontes de todo o código escrito, xunto con todos os libros de pago. Contactos no perfil.

Descubrimentos

Na nosa opinión, os procesos que se poden automatizar aínda non cristalizaron. En función do que atopamos e do que están a discutir os nosos colegas occidentais, ata agora son visibles os seguintes temas:

  • Aprovisionamento de dispositivos;
  • Recollida de datos;
  • Informes;
  • Solución de problemas;
  • Cumprimento.

Se hai interese, podemos continuar coa discusión sobre algún dos temas indicados.

Tamén me gustaría falar un pouco da automatización. O que debería ser ao noso entender:

  • O sistema debe vivir sen unha persoa, mentres é mellorado por unha persoa. O sistema non debe depender dos humanos;
  • A operación debe ser experta. Non hai unha clase de especialistas que realicen tarefas rutineiras. Hai expertos que automatizaron toda a rutina e só solucionan problemas complexos;
  • As tarefas estándar de rutina realízanse automaticamente "con só tocar un botón", non se desperdician recursos. O resultado de tales tarefas é sempre previsible e comprensible.

E a que deben levar estes puntos:

  • Transparencia da infraestrutura informática (Menos riscos de operación, modernización, implantación. Menos tempo de inactividade ao ano);
  • A capacidade de planificar recursos informáticos (Sistema de planificación da capacidade: podes ver canto se consume, podes ver cantos recursos son necesarios nun único sistema, e non por cartas e visitas aos departamentos superiores);
  • Posibilidade de reducir o número de persoal informático.

Autores do artigo: Alexander Chelovekov (CCIE RS, CCIE SP) e Pavel Kirillov. Interésanos discutir e propoñer solucións sobre o tema da automatización das infraestruturas informáticas.


Fonte: www.habr.com

Engadir un comentario