¡Hola, Habr!
En este artículo nos gustaría hablar sobre la automatización de la infraestructura de red. Se presentará un diagrama de funcionamiento de la red que opera en una empresa pequeña pero muy orgullosa. Todas las coincidencias con equipos de red reales son aleatorias. Veamos un caso ocurrido en esta red, que podría haber provocado el cierre de la empresa durante mucho tiempo y graves pérdidas económicas. La solución a este caso encaja muy bien en el concepto de “Automatización de la infraestructura de red”. Utilizando herramientas de automatización, mostraremos cómo se pueden resolver eficazmente problemas complejos en poco tiempo y reflexionaremos sobre por qué estos problemas deben resolverse de esta manera y no de otra manera (a través de la consola).
Observación
Nuestras principales herramientas de automatización son Ansible (como herramienta de automatización) y Git (como repositorio de los manuales de Ansible). Me gustaría hacer una reserva de inmediato: este no es un artículo introductorio donde hablamos sobre la lógica de Ansible o Git y explicamos cosas básicas (por ejemplo, qué son los módulos roletaski, archivos de inventario, variables en Ansible o qué sucede cuando ingresas los comandos git push o git commit). Esta historia no trata sobre cómo puedes practicar Ansible y configurar NTP o SMTP en tu equipo. Esta es una historia sobre cómo se puede resolver de forma rápida y preferiblemente un problema de red sin errores. También es recomendable tener un buen conocimiento de cómo funciona la red, en particular cuál es la pila de protocolos TCP/IP, OSPF y BGP. También eliminaremos de la ecuación la elección de Ansible y Git. Si aún necesita elegir una solución específica, le recomendamos leer el libro “Programabilidad y automatización de redes. Habilidades para el ingeniero de redes de próxima generación" por Jason Edelman, Scott S. Lowe y Matt Oswalt.
Ahora al grano.
Formulación del problema
Imaginemos una situación: a las 3 de la mañana estás profundamente dormido y soñando. Llamada telefónica. El director técnico llama:
- si
— ###, ####, #####, ¡¡¡el grupo de firewall ha caído y no se levanta!!!
Te frotas los ojos, tratando de comprender lo que está sucediendo e imaginar cómo podría suceder esto. Por teléfono se oye cómo al director se le arranca el pelo de la cabeza y pide volver a llamar porque el general lo llama por la segunda línea.
Media hora después, recogiste las primeras notas introductorias del turno de guardia y despertaste a todos los que podían ser despertados. Como resultado, el director técnico no mintió, todo está como está, el grupo principal de cortafuegos ha caído y ningún movimiento básico del cuerpo le hace recuperar el sentido. Todos los servicios que ofrece la empresa no funcionan.
Elige un problema a tu gusto, cada uno recordará algo diferente. Por ejemplo, después de una actualización nocturna en ausencia de una carga pesada, todo funcionó bien y todos se fueron a la cama felices. El tráfico comenzó a fluir y los buffers de la interfaz comenzaron a desbordarse debido a un error en el controlador de la tarjeta de red.
Jackie Chan puede describir bien la situación.
Gracias, Jackie.
No es una situación muy agradable, ¿verdad?
Dejemos por un rato nuestra red hermano con sus pensamientos tristes.
Analicemos cómo se desarrollarán aún más los eventos.
Sugerimos el siguiente orden de presentación del material
- Miremos el diagrama de red y veamos cómo funciona;
- Describiremos cómo transferimos la configuración de un enrutador a otro usando Ansible;
- Hablemos de la automatización de la infraestructura de TI en su conjunto.
Diagrama de red y descripción.
esquema
Consideremos el diagrama lógico de nuestra organización. No nombraremos fabricantes de equipos específicos; para los fines de este artículo, no importa (El lector atento adivinará qué tipo de equipo se utiliza). Esta es solo una de las buenas ventajas de trabajar con Ansible; al configurarlo, generalmente no nos importa qué tipo de equipo sea. Para que lo entiendas, se trata de equipos de proveedores conocidos, como Cisco, Juniper, Check Point, Fortinet, Palo Alto... puedes sustituirlos por tu propia opción.
Tenemos dos tareas principales para mover el tráfico:
- Asegurar la publicación de nuestros servicios, que son objeto de la empresa;
- Proporcionar comunicación con sucursales, un centro de datos remoto y organizaciones de terceros (socios y clientes), así como acceso de sucursales a Internet a través de la oficina central.
Empecemos por los elementos básicos:
- Dos enrutadores fronterizos (BRD-01, BRD-02);
- Clúster de cortafuegos (FW-CLUSTER);
- Interruptor central (L3-CORE);
- Un enrutador que se convertirá en un salvavidas (a medida que solucionemos el problema, transferiremos la configuración de red de FW-CLUSTER a EMERGENCIA) (EMERGENCIA);
- Switches para gestión de infraestructura de red (L2-MGMT);
- Máquina virtual con Git y Ansible (VM-AUTOMATION);
- Una computadora portátil en la que se realizan pruebas y desarrollo de playbooks para Ansible (Laptop-Automation).
La red está configurada con un protocolo de enrutamiento OSPF dinámico con las siguientes áreas:
- Área 0 – área que incluye enrutadores responsables de mover el tráfico en la zona EXCHANGE;
- Área 1 – área que incluye los routers responsables de la operación de los servicios de la empresa;
- Área 2 – área que incluye enrutadores responsables de enrutar el tráfico de gestión;
- Área N – áreas de redes de sucursales.
En los enrutadores de frontera, se crea un enrutador virtual (VRF-INTERNET), en el que se instala eBGP full view con el AS asignado correspondiente. iBGP se configura entre VRF. La empresa cuenta con un conjunto de direcciones blancas que se publican en estos VRF-INTERNET. Algunas de las direcciones blancas se enrutan directamente a FW-CLUSTER (direcciones en las que operan los servicios de la empresa), otras se enrutan a través de la zona EXCHANGE (servicios internos de la empresa que requieren direcciones IP externas y direcciones NAT externas para oficinas). Luego, el tráfico se dirige a enrutadores virtuales creados en L3-CORE con direcciones blancas y grises (zonas de seguridad).
La red de administración utiliza conmutadores dedicados y representa una red físicamente dedicada. La red de gestión también está dividida en zonas de seguridad.
El router de EMERGENCIA duplica física y lógicamente el FW-CLUSTER. Todas las interfaces están deshabilitadas excepto aquellas que miran a la red de administración.
Automatización y su descripción.
Descubrimos cómo funciona la red. Ahora echemos un vistazo paso a paso a lo que haremos para transferir tráfico de FW-CLUSTER a EMERGENCY:
- Deshabilitamos las interfaces del switch central (L3-CORE) que lo conectan al FW-CLUSTER;
- Deshabilitamos las interfaces en el switch del kernel L2-MGMT que lo conectan al FW-CLUSTER;
- Configuramos el enrutador de EMERGENCIA (por defecto, todas las interfaces están deshabilitadas en él, excepto las asociadas a L2-MGMT):
- Habilitamos interfaces en EMERGENCIA;
- Configuramos la dirección IP externa (para NAT) que estaba en el FW-Cluster;
- Generamos solicitudes gARP para que las direcciones poppy en las tablas arp L3-CORE se cambien de FW-Cluster a EMERGENCY;
- Registramos la ruta predeterminada como estática para BRD-01, BRD-02;
- Crear reglas NAT;
- Elevar a EMERGENCIA OSPF Área 1;
- Elevar a EMERGENCIA OSPF Área 2;
- Cambiamos el costo de las rutas del Área 1 al 10;
- Cambiamos el costo de la ruta predeterminada en el Área 1 a 10;
- Cambiamos las direcciones IP asociadas a L2-MGMT (a las que estaban en FW-CLUSTER);
- Generamos solicitudes gARP para que las direcciones poppy en las tablas arp L2-MGMT cambien de FW-CLUSTER a EMERGENCY.
Nuevamente volvemos a la formulación original del problema. Las tres de la mañana, estrés enorme, un error en cualquier momento puede generar nuevos problemas. ¿Listo para escribir comandos a través de la CLI? ¿Sí? Ok, al menos ve a enjuagarte la cara, toma un poco de café y reúne fuerzas de voluntad.
Bruce, por favor ayuda a los chicos.
Bueno, seguimos mejorando nuestra automatización.
A continuación se muestra un diagrama de cómo funciona el manual en términos de Ansible. Este esquema refleja lo que describimos anteriormente, es solo una implementación específica en Ansible.
En esta etapa, nos dimos cuenta de lo que había que hacer, desarrollamos un manual, realizamos pruebas y ahora estamos listos para lanzarlo.
Otra pequeña digresión lírica. La facilidad de la historia no debe engañarte. El proceso de redacción de manuales no fue tan sencillo y rápido como podría parecer. Las pruebas requirieron bastante tiempo, se creó un stand virtual, la solución se probó muchas veces y se realizaron alrededor de 100 pruebas.
Comencemos... Existe la sensación de que todo sucede muy lentamente, hay un error en alguna parte, al final algo no funcionará. La sensación de saltar con un paracaídas, pero el paracaídas no quiere abrirse de inmediato... esto es normal.
A continuación, leemos el resultado de las operaciones realizadas en el libro de jugadas de Ansible (las direcciones IP fueron reemplazadas por motivos de secreto):
[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 ************************************************************************¡Ya está!
De hecho, aún no está listo, no se olvide de la convergencia de protocolos de enrutamiento dinámico y de cargar una gran cantidad de rutas en la FIB. No podemos influir en esto de ninguna manera. Esperamos. Funcionó. Ahora está listo.
Y en el pueblo de Vilabajo (que no quiere automatizar la instalación de la red) siguen lavando los platos. Bruce (es cierto que ya es diferente, pero no menos genial) está tratando de comprender cuántas más reconfiguraciones manuales del equipo se llevarán a cabo.
También me gustaría detenerme en un punto importante. ¿Cómo podemos recuperar todo? Después de un tiempo, le devolveremos la vida a nuestro FW-CLUSTER. Este es el equipo principal, no el de respaldo, la red debe funcionar en él.
¿Sientes cómo los networkers están empezando a agotarse? El director técnico escuchará mil argumentos de por qué no se debe hacer esto, de por qué se puede hacer más adelante. Desafortunadamente, así es como funciona la red a partir de un montón de parches, pedazos y restos de su antiguo lujo. Resulta ser una colcha de retazos. Nuestra tarea en general, no en esta situación específica, pero en general en principio, como especialistas en TI, es acercar el trabajo de la red a la hermosa palabra inglesa "consistencia", es muy multifacética, se puede traducir como: coherencia , coherencia, lógica, coherencia, sistematicidad, comparabilidad, coherencia. Se trata de él. Solo en este estado la red es manejable, entendemos claramente qué funciona y cómo, entendemos claramente qué se debe cambiar, si es necesario, sabemos claramente dónde buscar si surgen problemas. Y sólo en una red así se pueden realizar trucos como los que acabamos de describir.
En realidad, se preparó otro libro de jugadas que devolvió la configuración a su estado original. La lógica de su funcionamiento es la misma (es importante recordar que el orden de las tareas es muy importante), para no alargar un artículo ya bastante largo, decidimos no publicar una lista de ejecución del playbook. Después de realizar tales ejercicios, se sentirá mucho más tranquilo y seguro en el futuro, además, cualquier muleta que haya acumulado allí se revelará de inmediato.
Cualquiera puede escribirnos y recibir las fuentes de todo el código escrito, junto con todos los palybooks. Contactos en el perfil.
Hallazgos
En nuestra opinión, los procesos que pueden automatizarse aún no han cristalizado. Según lo que hemos encontrado y lo que nuestros colegas occidentales están discutiendo, hasta ahora son visibles los siguientes temas:
- Aprovisionamiento de dispositivos;
- Recopilación de datos;
- Informes;
- Solución de problemas;
- Conformidad.
Si hay interés, podemos continuar la discusión sobre uno de los temas indicados.
También me gustaría hablar un poco sobre la automatización. Lo que debería ser en nuestro entendimiento:
- El sistema debe vivir sin una persona, mientras que una persona lo mejora. El sistema no debería depender de los humanos;
- La operación debe ser experta. No existe una clase de especialistas que realicen tareas rutinarias. Hay expertos que han automatizado toda la rutina y resuelven sólo problemas complejos;
- Las tareas estándar de rutina se realizan automáticamente "con solo tocar un botón", no se desperdician recursos. El resultado de tales tareas es siempre predecible y comprensible.
¿Y a qué deberían conducir estos puntos?
- Transparencia de la infraestructura de TI (Menos riesgos de operación, modernización, implementación. Menos tiempo de inactividad por año);
- La capacidad de planificar recursos de TI (sistema de planificación de capacidad: puede ver cuánto se consume, cuántos recursos se requieren en un solo sistema, y no mediante cartas y visitas a los departamentos superiores);
- Posibilidad de reducir el número de personal de TI.
Autores del artículo: Alexander Chelovekov (CCIE RS, CCIE SP) y Pavel Kirillov. Estamos interesados en discutir y proponer soluciones sobre el tema de la automatización de la infraestructura de TI.
Fuente: habr.com