Cómo hacemos la automatización de una gran red heredada

Hola Tenemos más de 15,260 objetos y 38,000 dispositivos de red que deben configurarse, actualizarse y verificarse para que funcionen. Mantener tal flota de equipos es bastante difícil y requiere mucho tiempo, esfuerzo y personas. Por lo tanto, necesitábamos automatizar el trabajo con equipos de red y decidimos adaptar el concepto de Red como Código para administrar la red en nuestra empresa. Debajo del corte, lea nuestro historial de automatización, los errores cometidos y un plan adicional para construir sistemas.

Larga historia corta, queremos automatizar la red

Hola Mi nombre es Alexander Prokhorov y, junto con el equipo de ingenieros de redes de nuestro departamento, estamos trabajando en una red en #IT X5 . Nuestro departamento desarrolla infraestructura de red, monitoreo, automatización de red y la dirección moderna de Network as a Code.

Inicialmente, en realidad no creía en ninguna automatización en nuestra red. Quedaban muchos errores heredados y de configuración: no en todas partes había una autorización central, no todo el hardware soportaba SSH, no todo SNMP estaba configurado. Todo esto minó en gran medida la creencia en la automatización. Por lo tanto, en primer lugar, arreglamos lo que se necesita para iniciar la automatización, a saber: estandarización de la conexión SSH, autorización única ( AAA ) y perfiles SNMP. Toda esta base le permite escribir una herramienta para la entrega masiva de configuraciones a un dispositivo, pero surge la pregunta: ¿puedo obtener más? Entonces llegamos a la necesidad de elaborar un plan para el desarrollo de la automatización y, en particular, el concepto de Red como Código.

El concepto de red como código, según Cisco, significa los siguientes principios:

• Almacene configuraciones de destino en el repositorio, control de origen
• Los cambios de configuración pasan por el repositorio, Fuente única de verdad
• Incrustar configuraciones a través de la API

Los primeros dos puntos le permiten aplicar el enfoque DevOps o NetDevOps para administrar su infraestructura de red. Con el tercer párrafo hay dificultades, por ejemplo, ¿qué hacer si no hay API? ¡Por supuesto, SSH y CLI, somos networkers!


Además de tratar de aplicar nuevos enfoques para la gestión de la red, queríamos resolver algunos problemas más graves en la infraestructura de la red, como la integridad de los datos, la actualización y, por supuesto, la automatización. Por automatización nos referimos no solo a la entrega masiva de configuraciones a los equipos, sino también a la configuración automática, la recopilación automática de datos de inventario de equipos de red y la integración con los sistemas de monitoreo. Pero lo primero es lo primero.

La funcionalidad a la que apuntamos es:

• Base de datos de equipos de red (+ descubrimiento, + actualización automática)
• Direcciones de red base (IPAM + verificaciones de validación)
• Integración de sistemas de monitoreo con datos de inventario.
• Almacenamiento de estándares de configuración en el sistema de control de versiones.
• Formación automática de configuraciones de destino para un objeto.
• Entrega masiva de configuraciones a equipos de red
• Implemente un proceso de CI / CD para administrar los cambios de configuración de red
• Probar configuraciones de red con CI / CD
• ZTP (Zero Touch Provisioning): configuración automática de equipos para un objeto

Los sistemas que necesitamos y sus conexiones.

Una breve conclusión del spoiler: es mejor sistematizar y controlar el proceso de entrega masiva de configuraciones para no llegar a la entrega masiva de errores en las configuraciones.

 - DevOps:    50ms     4    -     : ", !@#$%" 

El esquema al que llegamos consiste en bloques de datos maestros "comerciales", bloques de datos maestros "red", sistemas de monitoreo de infraestructura de red, sistemas de entrega de configuración, sistemas de control de versiones con una unidad de prueba.

Todo lo que necesitamos son datos

Primero necesitamos saber qué objetos hay en la empresa.

SAP - Sistema de empresa ERP . Los datos sobre casi todas las instalaciones están allí, y más precisamente en todas las tiendas y centros de distribución. Además, hay datos sobre equipos que pasaron por un almacén de TI con números de inventario, que también nos serán útiles en el futuro. Solo faltan oficinas, no se inician en el sistema. Estamos tratando de resolver este problema como un proceso separado, comenzando desde el momento de la apertura, necesitamos una conexión en cada objeto y seleccionamos las configuraciones para la comunicación, por lo que en algún momento en este momento necesitamos crear datos maestros. Pero la insuficiencia de datos es un tema separado, es mejor poner esta descripción en un artículo separado si hay interés en esto.

HPSM : un sistema que contiene un CMDB común para TI, gestión de incidentes, gestión de cambios. Dado que el sistema es común a todas las TI, debe tener todos los equipos de TI, incluidos los equipos de red. Este es el lugar donde agregaremos todos los datos finales a través de la red. Con la gestión de incidentes y cambios, planeamos interactuar desde los sistemas de monitoreo en el futuro.

Sabemos qué objetos tenemos, los enriquecemos con datos a través de la red. Para este propósito, tenemos dos sistemas: IPAM de SolarWinds y nuestro propio sistema CMDB.noc.

IPAM es un repositorio de subredes IP, los datos más correctos y correctos sobre la propiedad de las direcciones IP en la empresa deben estar aquí.

CMDB.noc es una base de datos con una interfaz WEB donde se almacenan datos estáticos en equipos de red: enrutadores, conmutadores, puntos de acceso, así como proveedores y sus características. Bajo estático significa que su cambio se lleva a cabo solo con la participación del hombre. En otras palabras, la detección automática no realiza cambios en esta base de datos; necesitamos que comprenda qué "debería" instalarse en el objeto. Su base es necesaria como un amortiguador entre los sistemas productivos con los que trabaja toda la empresa y las herramientas de red internas. Acelera el desarrollo, agregando los campos necesarios, nuevas relaciones, ajustando parámetros, etc. Además, esta solución no solo está en la velocidad de desarrollo, sino también en la presencia de esas relaciones entre los datos que necesitamos, sin compromiso. Como mini-ejemplo, utilizamos varios exid en la base de datos para la comunicación entre IPAM, SAP y HPSM.

Como resultado, recibimos datos completos de todos los objetos, con equipos de red y direcciones IP conectados. Ahora necesitamos plantillas de configuración o servicios de red que proporcionamos en estos sitios.

Fuente única de verdad

Aquí, acabamos de llegar a la aplicación del primer principio NaaC: almacenar configuraciones de destino en el repositorio. En nuestro caso, este es Gitlab. La elección para nosotros fue simple:

• En primer lugar, ya tenemos esta herramienta en nuestra empresa, no tuvimos que implementarla desde cero
• En segundo lugar, es bastante adecuado para todas nuestras tareas actuales y futuras en infraestructura de red

La principal parte interesante de la automatización sucederá en Gitlab: el proceso de cambiar el estándar de configuración o, más simplemente, la plantilla.

Ejemplo de proceso de cambio estándar

Uno de los tipos de objetos que tenemos es la tienda Pyaterochka. Allí, una topología típica consiste en un enrutador y uno / dos conmutadores. El archivo de configuración de la plantilla se almacena en Gitlab, en esta parte todo es simple. Pero esto no es del todo NaaC.

Ahora digamos que nos llega un nuevo proyecto. Las tareas para el nuevo proyecto de TI son hacer un piloto en un cierto volumen de tiendas. De acuerdo con los resultados del piloto: si tiene éxito, realice una replicación para todos los objetos de este tipo; de lo contrario, colapsar el piloto sin realizar una replicación.

Este proceso encaja muy bien en la lógica de Git:

1. Para un nuevo proyecto, creamos una Rama, donde hacemos cambios a las configuraciones.
2. En Branch también mantenemos una lista de objetos en los que se está probando este proyecto.
3. Si tiene éxito, hacemos una solicitud de fusión en la rama maestra, que deberá replicarse en la red prod
4. En caso de falla, deje Branch para el historial o simplemente elimine

En una primera aproximación, incluso sin automatización, es una herramienta muy conveniente para trabajar juntos en una configuración de red. Especialmente si imagina que se presentaron tres o más proyectos al mismo tiempo. Cuando llegue el momento del lanzamiento de proyectos en prod, deberá resolver todos los conflictos de configuración en las solicitudes de fusión y verificar que los cambios en la configuración no sean mutuamente excluyentes. Y esto es muy conveniente de hacer en git.

Además, este enfoque nos agrega la flexibilidad para usar las herramientas Gitlab CI / CD para probar configuraciones virtualmente, para automatizar la entrega de configuraciones a un banco de pruebas o un grupo piloto de objetos. // E incluso en prod si quieres.

Implementación de la configuración en cualquier entorno.

Inicialmente, el objetivo principal era precisamente la entrega masiva de configuraciones, como una herramienta que claramente le permite ahorrar tiempo a los ingenieros y acelerar la ejecución de las tareas de configuración. Para hacer esto, incluso antes del comienzo de la gran actividad "Red como un código", escribimos una solución de Python para conectarse al equipo, ya sea para recopilar configuraciones de equipos o para configurarlo. Esto es netmiko , esto es pysnmp , esto es jinja2 , etc.

Pero es hora de que dividamos la configuración masiva en varias subespecies:

1. Entrega de configuraciones a zonas de prueba y piloto.

   Este elemento se basa en Gitlab CI, que le permite habilitar la entrega de configuración a las zonas piloto y de prueba en la tubería.
   
2. Duplicación de configuraciones en prod

   • Un elemento separado, la mayoría de las veces, la replicación a dispositivos de 38k se lleva a cabo en varias ondas, aumentando el volumen, para monitorear la situación en producción. Además, el trabajo de esta magnitud requiere la coordinación del trabajo, por lo tanto, es mejor comenzar este proceso a mano. Para esto, es conveniente usar Ansible + -AWX y ajustar la compilación dinámica del inventario de nuestros sistemas de datos maestros.
   • Además, esta es una solución conveniente cuando necesita darle a la segunda línea el lanzamiento de libros de jugadas preconfigurados que realizan operaciones complejas e importantes, como cambiar el tráfico entre sitios.
3. Recogida de datos

   • Detección automática de dispositivos de red
   • Configuraciones de respaldo
   • Verificar conectividad

   
   Asignamos esta tarea en un bloque separado, ya que hay momentos en que alguien desmanteló repentinamente un interruptor o instaló un nuevo dispositivo, pero no lo sabíamos de antemano. En consecuencia, este dispositivo no estará en nuestros datos maestros y quedará fuera del proceso de entrega de configuración, monitoreo y, en general, trabajo operativo. Sucede que el equipo se instaló legítimamente, pero la configuración se "vertió" incorrectamente allí y, por alguna razón, las contraseñas ssh , snmp , aaa o no estándar para el acceso no funcionan allí. Para hacer esto, tenemos Python para probar todos los métodos de conexión heredados posibles que podríamos tener en la empresa, hacer fuerza bruta para todas las contraseñas antiguas, y todo para llegar al trozo de hierro y prepararlo para trabajar con Ansible y monitorear .
   
   Hay una manera simple: hacer varios archivos de inventario para ansible, donde describir todos los datos posibles para las conexiones (todos los tipos de proveedores con todos los pares posibles de nombre de usuario / contraseña) y ejecutar un libro de jugadas para cada variante de inventario . Esperábamos una mejor solución, pero en la conferencia de RedHat, el arquitecto de Ansible aconsejó lo mismo. En general, se supone que sabe de antemano a qué se está conectando.
   Queríamos una solución universal: cuando elimine una copia de seguridad, busque nuevos equipos y, si los encuentra, agréguelos a todos los sistemas necesarios. Por lo tanto, elegimos una solución en python: sepa qué podría ser más hermoso que un programa que puede detectar una pieza de hardware de red para conectarse, independientemente de lo que esté configurado en él (dentro de límites razonables, por supuesto), configurar según sea necesario, eliminar la configuración y, al mismo tiempo, Agregue datos de API a los sistemas requeridos.
   

Verificación como Monitoreo

Una de las tareas de la automatización es, por supuesto, averiguar qué se cayó de esta automatización. No todos los 38k están configurados perfectamente la primera vez, incluso sucede que alguien configura el equipo con sus manos. Y es necesario rastrear estos cambios y restaurar la justicia en la configuración de destino.

Existen tres enfoques para verificar el cumplimiento de la configuración con el estándar:

• Haga una verificación una vez por período: descargue el estado actual, verifique el objetivo y corrija las deficiencias identificadas.
• Sin verificar nada, una vez al período: despliegue las configuraciones de destino. Es cierto que existe el riesgo de romper algo, tal vez no haya todo en la configuración de destino.
• Un enfoque conveniente es cuando las diferencias de la configuración de destino en Single Source of Truth se consideran alertas y son monitoreadas por el sistema de monitoreo. Esto incluye: un desajuste con el estándar de configuración actual, una diferencia entre el hardware y el especificado en los datos maestros, un desajuste con los datos en IPAM .

En el tercer caso, una opción parece transferir este trabajo a la gestión de incidentes (SO), de modo que las inconsistencias se eliminan en pequeñas porciones durante todo el tiempo que una vez por emergencia.

Zabbix , sobre el que escribí anteriormente en el artículo "Cómo monitoreamos 14,000 objetos", es nuestro sistema de monitoreo de objetos distribuidos donde podemos hacer cualquier disparador y alerta que podamos pensar. Desde que escribimos el último artículo, hemos actualizado a Zabbix 4.0 LTS .

Basado en Web Zabbix, realizamos una actualización de nuestro portal de soporte de red, donde ahora puede encontrar toda la información sobre un objeto de todos nuestros sistemas en una pantalla, así como ejecutar scripts para verificar si ocurren problemas frecuentes.



También presentamos una nueva característica: para nosotros, Zabbix se convirtió de alguna manera en un CRON para el lanzamiento de scripts programados, como scripts de integración de sistemas, scripts de detección automática. Esto es realmente conveniente cuando necesita ver los scripts actuales y cuándo y dónde se ejecutan sin verificar todos los servidores. Es cierto que para los scripts que se ejecutan durante más de 30 segundos, necesitará un lanzador que los inicie sin esperar el final. Afortunadamente, es simple:




Splunk es una solución que le permite recopilar registros de eventos de equipos de red, y esto también se puede utilizar para monitorear la automatización. Por ejemplo, al recopilar una copia de seguridad de la configuración, un script de Python genera un mensaje de REGISTRO CFG-5-BACKUP , un enrutador o conmutador envía un mensaje a Splunk, en el que contamos el número de mensajes de este tipo del equipo de red. Esto nos permite rastrear la cantidad de equipo que el script ha detectado. Y vemos cuántas piezas de hierro pudieron informar esto a Splunk y verificar que llegaron mensajes de todas las piezas de hierro.
Spectrum es un sistema integral que utilizamos para monitorear objetos críticos, una herramienta bastante poderosa que nos ayuda mucho a resolver incidentes críticos de la red. En automatización, lo usamos solo extrayendo datos de él, no es de código abierto , por lo que las posibilidades son algo limitadas.

La guinda del pastel

Al usar sistemas con datos maestros en el equipo, podemos pensar en crear ZTP o Zero Touch Provisioning. Como un botón de "autoajuste", pero solo sin un botón.

Tenemos todos los datos necesarios de los bloques anteriores: conocemos el objeto, su tipo, qué equipo hay (proveedor y modelo), cuáles son las direcciones (IPAM), cuál es el estándar de configuración actual (Git). Al unirlos todos, al menos podemos preparar una plantilla de configuración para cargarla en el dispositivo, será más como One Touch Provisioning, pero a veces no se requiere más.

True Zero Touch necesita una forma de entregar automáticamente la configuración al hardware no configurado. Además, es deseable independientemente del proveedor. Hay varias opciones de trabajo: un servidor de consola, si todo el equipo pasa por el almacén central, soluciones de consola móvil, si el equipo llega de inmediato. Solo estamos trabajando en estas soluciones, pero tan pronto como haya una opción de trabajo, podemos compartirla.

Conclusión

En total, en nuestro concepto de Red como Código , hubo 5 hitos principales:

• Datos maestros (comunicación de sistemas y datos entre sí, API de sistemas, suficiencia de datos para soporte y lanzamiento)
• Monitoreo de datos y configuraciones (detección automática de dispositivos de red, verificación de la relevancia de la configuración en la instalación)
• Control de versiones, pruebas y configuraciones piloto (Gitlab CI / CD aplicado a la red, herramientas de prueba de configuración de red)
• Entrega de configuración (Ansible, AWX, scripts de python para conectar)
• Aprovisionamiento Zero Touch (qué datos se necesitan, cómo construir un proceso para que sea así, cómo conectarse a una pieza de hardware no configurada)

No funcionó para encajar todo en un artículo, cada elemento merece una discusión separada, podemos hablar de algo ahora, de algo cuando verificamos las soluciones en la práctica. Si está interesado en alguno de los temas, al final habrá una encuesta en la que podrá votar por el próximo artículo. Si el tema no está incluido en la lista, pero es interesante leerlo, deje un comentario lo antes posible, asegúrese de compartir nuestra experiencia.

---

Un agradecimiento especial a Virilin Alexander ( xscrew ) y Sibgatulin Marat ( eucariot ) por la visita de referencia en el otoño de 2018 a la nube de yandex y la historia sobre la automatización en la infraestructura de red de la nube. Después de él, obtuvimos inspiración y muchas ideas sobre el uso de la automatización y NetDevOps en la infraestructura del X5 Retail Group.