Se acabó el SDSM, pero el deseo incontrolable de escribir permanece.

Durante muchos años, nuestro hermano sufrió por realizar trabajos rutinarios, cruzar los dedos antes de comprometerse y falta de sueño debido a los retrocesos nocturnos.
Pero los tiempos oscuros están llegando a su fin.

Con este artículo comenzaré una serie sobre cómo me Aparece la automatización.
En el camino, entenderemos las etapas de automatización, almacenamiento de variables, formalización del diseño, RestAPI, NETCONF, YANG, YDK y haremos mucha programación.
Me significa que a) no es una verdad objetiva, b) no es incondicionalmente el mejor enfoque, c) mi opinión, incluso durante el paso del primer al último artículo, puede cambiar - para ser honesto, desde la etapa de borrador hasta publicación, reescribí todo completamente dos veces.

contenido

1. Objetivos
   1. La red es como un solo organismo.
   2. Pruebas de configuración
   3. Versionado
   4. Monitoreo y autorreparación de servicios.

2. Los fondos
   1. sistema de inventario
   2. Sistema de gestión de espacio IP.
   3. Sistema de descripción de servicios de red.
   4. Mecanismo de inicialización del dispositivo
   5. Modelo de configuración independiente del proveedor
   6. Interfaz de controlador específica del proveedor
   7. Mecanismo para entregar la configuración al dispositivo.
   8. CI / CD
   9. Mecanismo de respaldo y búsqueda de desvíos.
   10. Sistema de monitoreo

3. Conclusión

Intentaré realizar ADSM en un formato ligeramente diferente al SDSM. Seguirán apareciendo artículos extensos, detallados y numerados, y entre ellos publicaré pequeñas notas de la experiencia cotidiana. Intentaré luchar contra el perfeccionismo aquí y no lamerlos a todos.

Qué curioso que la segunda vez tengas que recorrer el mismo camino.

Al principio tuve que escribir artículos sobre redes porque no estaban en RuNet.

Ahora no pude encontrar un documento completo que sistematizara los enfoques de la automatización y analizara las tecnologías anteriores utilizando ejemplos prácticos simples.

Puede que me equivoque, así que proporcione enlaces a recursos útiles. Sin embargo, esto no cambiará mi determinación de escribir, porque el objetivo principal es aprender algo por mí mismo, y hacer la vida más fácil a los demás es un bono agradable que acaricia el gen de compartir experiencias.

Intentaremos tomar un centro de datos LAN DC de tamaño mediano y desarrollar todo el esquema de automatización.
Haré algunas cosas casi por primera vez contigo.

No seré original en las ideas y herramientas descritas aquí. Dmitry Figol tiene una excelente canal con transmisiones sobre este tema.
Los artículos se superpondrán con ellos en muchos aspectos.

El LAN DC tiene 4 DC, alrededor de 250 conmutadores, media docena de enrutadores y un par de firewalls.
Facebook no, pero lo suficiente como para hacerte pensar profundamente sobre la automatización.
Sin embargo, existe la opinión de que si tiene más de un dispositivo, la automatización ya es necesaria.
De hecho, es difícil imaginar que alguien pueda vivir ahora sin al menos un paquete de guiones rodilla.
Aunque escuché que hay oficinas donde las direcciones IP se guardan en Excel y cada uno de los miles de dispositivos de red se configura manualmente y tiene su propia configuración única. Esto, por supuesto, puede hacerse pasar por arte moderno, pero los sentimientos del ingeniero definitivamente se sentirán ofendidos.

Objetivos

Ahora fijaremos los objetivos más abstractos:

• La red es como un solo organismo.
• Pruebas de configuración
• Versiones del estado de la red
• Monitoreo y autorreparación de servicios.

Más adelante en este artículo veremos qué medios usaremos y, a continuación, veremos los objetivos y los medios en detalle.

La red es como un solo organismo.

La frase definitoria de la serie, aunque a primera vista pueda no parecer tan significativa: Configuraremos la red, no los dispositivos individuales..
En los últimos años hemos visto un cambio en el énfasis hacia el tratamiento de la red como una entidad única, de ahí la Redes definidas por software, Redes impulsadas por la intención и Redes Autónomas.
Después de todo, ¿qué necesitan las aplicaciones globalmente de la red?: conectividad entre los puntos A y B (bueno, a veces +B-Z) y aislamiento de otras aplicaciones y usuarios.

Y entonces nuestra tarea en esta serie es construir un sistema, manteniendo la configuración actual toda la red, que ya está descompuesto en la configuración real de cada dispositivo de acuerdo con su función y ubicación.
Sistema La gestión de red implica que para realizar cambios contactamos con él, y éste a su vez calcula el estado deseado para cada dispositivo y lo configura.
De esta manera, minimizamos el acceso manual a la CLI a casi cero (cualquier cambio en la configuración del dispositivo o el diseño de la red debe formalizarse y documentarse) y solo luego implementarse en los elementos de red necesarios.

Es decir, por ejemplo, si decidiéramos que a partir de ahora los conmutadores de rack en Kazán deberían anunciar dos redes en lugar de una,

1. Primero documentamos los cambios en los sistemas.
2. Generar la configuración de destino de todos los dispositivos de red.
3. Lanzamos el programa de actualización de la configuración de la red, que calcula qué se debe eliminar en cada nodo, qué agregar y lleva los nodos al estado deseado.

Al mismo tiempo, realizamos cambios manualmente solo en el primer paso.

Pruebas de configuración

Conocidoque el 80% de los problemas ocurren durante los cambios de configuración; una prueba indirecta de esto es que durante las vacaciones de Año Nuevo todo suele estar tranquilo.
Personalmente he sido testigo de docenas de tiempos de inactividad globales debido a errores humanos: el comando incorrecto, la configuración se ejecutó en la rama incorrecta, la comunidad lo olvidó, MPLS fue demolido globalmente en el enrutador, se configuraron cinco piezas de hardware, pero el error no fue El día XNUMX se notó que se cometieron viejos cambios hechos por otra persona. Hay un montón de escenarios.

La automatización nos permitirá cometer menos errores, pero a mayor escala. De esta manera puedes bloquear no sólo un dispositivo, sino toda la red a la vez.

Desde tiempos inmemoriales, nuestros abuelos comprobaron con atención la exactitud de los cambios realizados, las bolas de acero y la funcionalidad de la red después de su implementación.
Aquellos abuelos cuyo trabajo provocó tiempos de inactividad y pérdidas catastróficas dejaron menos descendencia y deberían desaparecer con el tiempo, pero la evolución es un proceso lento y, por lo tanto, no todo el mundo sigue probando los cambios en el laboratorio primero.
Sin embargo, a la vanguardia del progreso están aquellos que han automatizado el proceso de prueba de la configuración y su posterior aplicación a la red. En otras palabras, tomé prestado el procedimiento CI/CD (Integración continua, implementación continua) de los desarrolladores.
En una de las partes veremos cómo implementar esto usando un sistema de control de versiones, probablemente Github.

Una vez que se acostumbre a la idea de CI/CD de red, de la noche a la mañana el método de verificar una configuración aplicándola a una red de producción le parecerá una ignorancia medieval temprana. Algo así como golpear una ojiva con un martillo.

Una continuación orgánica de ideas sobre sistema La gestión de red y CI/CD se convierte en un versionado completo de la configuración.

Versionado

Supondremos que con cualquier cambio, incluso el más pequeño, incluso en un dispositivo imperceptible, toda la red pasa de un estado a otro.
Y no siempre ejecutamos un comando en el dispositivo, cambiamos el estado de la red.
Entonces, ¿llamamos versiones a estos estados?

Digamos que la versión actual es 1.0.0.
¿Ha cambiado la dirección IP de la interfaz Loopback en uno de los ToR? Esta es una versión menor y se numerará 1.0.1.
Revisamos las políticas para importar rutas a BGP, un poco más en serio, ya en 1.1.0
Decidimos deshacernos de IGP y cambiar solo a BGP; esto ya es un cambio de diseño radical: 2.0.0.

Al mismo tiempo, diferentes DC pueden tener diferentes versiones: la red se está desarrollando, se están instalando nuevos equipos, se están agregando nuevos niveles de columnas en algún lugar, no en otros, etc.

Про versionado semántico hablaremos en un artículo aparte.

Repito: cualquier cambio (excepto los comandos de depuración) es una actualización de la versión. Se debe notificar a los administradores sobre cualquier desviación de la versión actual.

Lo mismo se aplica a la reversión de los cambios: esto no es cancelar los últimos comandos, no es una reversión utilizando el sistema operativo del dispositivo, sino que lleva toda la red a una versión nueva (antigua).

Monitoreo y autorreparación de servicios.

Esta tarea evidente ha alcanzado un nuevo nivel en las redes modernas.
A menudo, los grandes proveedores de servicios adoptan el enfoque de que un servicio fallido debe repararse muy rápidamente y generar uno nuevo, en lugar de averiguar qué sucedió.
"Mucho" significa que debe estar generosamente cubierto por todos lados con un sistema de control que en cuestión de segundos detectará las más mínimas desviaciones de la norma.
Y aquí las métricas habituales, como la carga de la interfaz o la disponibilidad de los nodos, ya no son suficientes. Tampoco basta con que el oficial de guardia los controle manualmente.
Para muchas cosas debería haber Autocuración — las luces de monitoreo se pusieron rojas y nosotros mismos fuimos y nos aplicamos el plátano donde nos dolía.

Y aquí también monitoreamos no solo los dispositivos individuales, sino también el estado de toda la red, tanto la caja blanca, que es relativamente comprensible, como la caja negra, que es más complicada.

¿Qué necesitaremos para implementar planes tan ambiciosos?

• Tener una lista de todos los dispositivos en la red, su ubicación, roles, modelos, versiones de software.
  kazan-leaf-1.lmu.net, Kazán, hoja, Juniper QFX 5120, R18.3.
• Contar con un sistema de descripción de servicios de red.
  IGP, BGP, L2/3VPN, Política, ACL, NTP, SSH.
• Ser capaz de inicializar el dispositivo.
  Nombre de host, IP de administración, ruta de administración, usuarios, claves RSA, LLDP, NETCONF
• Configure el dispositivo y lleve la configuración a la versión deseada (incluida la anterior).
• Configuración de prueba
• Verificar periódicamente el estado de todos los dispositivos para detectar desviaciones de los actuales e informar a quién debe ser.
  De la noche a la mañana, alguien añadió discretamente una regla a la ACL.
• Monitorear el desempeño.

Los fondos

Suena bastante complicado como para empezar a descomponer el proyecto en componentes.

Y habrá diez de ellos:

1. sistema de inventario
2. Sistema de gestión de espacio IP.
3. Sistema de descripción de servicios de red.
4. Mecanismo de inicialización del dispositivo
5. Modelo de configuración independiente del proveedor
6. Interfaz de controlador específica del proveedor
7. Mecanismo para entregar la configuración al dispositivo.
8. CI / CD
9. Mecanismo de respaldo y búsqueda de desvíos.
10. Sistema de monitoreo

Esto, por cierto, es un ejemplo de cómo cambió la visión sobre los objetivos del ciclo: el borrador tenía 4 componentes.

En la ilustración representé todos los componentes y el dispositivo en sí.
Los componentes que se cruzan interactúan entre sí.
Cuanto más grande sea el bloque, más atención se debe prestar a este componente.

Componente 1: Sistema de inventario

Obviamente queremos saber qué equipo está ubicado, dónde, a qué está conectado.
El sistema de inventario es una parte integral de cualquier empresa.
Muy a menudo, una empresa tiene un sistema de inventario separado para dispositivos de red, que resuelve problemas más específicos.
Como parte de esta serie de artículos, lo llamaremos DCIM - Gestión de infraestructura de centros de datos. Aunque el propio término DCIM, en sentido estricto, incluye mucho más.

Para nuestros propósitos, almacenaremos la siguiente información sobre el dispositivo en él:

• Número de inventario
• Descripción del Título
• Modelo (Huawei CE12800, enebro QFX5120, etc.)
• Parámetros característicos (placas, interfaces, etc.)
• Role (Hoja, lomo, enrutador de bordes, etc.)
• Ubicación (región, ciudad, centro de datos, estante, unidad)
• Interconexiones entre dispositivos
• Topología de la red

Está perfectamente claro que nosotros mismos queremos saber todo esto.
¿Pero esto ayudará con fines de automatización?
Por supuesto.
Por ejemplo, sabemos que en un determinado centro de datos en conmutadores Leaf, si es Huawei, se deben aplicar ACL para filtrar cierto tráfico en la VLAN, y si es Juniper, entonces en la unidad 0 de la interfaz física.
O necesita implementar un nuevo servidor Syslog en todas las fronteras de la región.

En él almacenaremos dispositivos de red virtuales, por ejemplo enrutadores virtuales o reflectores raíz. Podemos agregar servidores DNS, NTP, Syslog y en general todo lo que de una u otra forma esté relacionado con la red.

Componente 2: sistema de gestión del espacio IP

Sí, y hoy en día existen equipos de personas que realizan un seguimiento de los prefijos y direcciones IP en un archivo Excel. Pero el enfoque moderno sigue siendo una base de datos, con una interfaz en nginx/apache, API y amplias funciones para registrar direcciones IP y redes divididas en VRF.
IPAM - Gestión de direcciones IP.

Para nuestros fines, almacenaremos en él la siguiente información:

• VLAN
• VRF
• Redes/Subredes
• Dirección IP
• Vincular direcciones a dispositivos, redes a ubicaciones y números de VLAN

Nuevamente, está claro que queremos asegurarnos de que cuando asignamos una nueva dirección IP para el loopback ToR, no tropecemos con el hecho de que ya fue asignada a alguien. O que usamos el mismo prefijo dos veces en diferentes extremos de la red.
Pero, ¿cómo ayuda esto a la automatización?
Fácil
Solicitamos un prefijo en el sistema con la función Loopbacks, que contiene direcciones IP disponibles para asignación; si se encuentra, asignamos la dirección, si no, solicitamos la creación de un nuevo prefijo.
O al crear una configuración de dispositivo, podemos averiguar desde el mismo sistema en qué VRF debe ubicarse la interfaz.
Y al iniciar un nuevo servidor, el script inicia sesión en el sistema, descubre en qué conmutador se encuentra el servidor, qué puerto y qué subred está asignado a la interfaz y le asignará la dirección del servidor.

Esto sugiere el deseo de combinar DCIM e IPAM en un solo sistema para no duplicar funciones y no servir a dos entidades similares.
Eso es lo que haremos.

Componente 3. Sistema de descripción de servicios de red.

Si los dos primeros sistemas almacenan variables que aún deben usarse de alguna manera, el tercero describe para cada función de dispositivo cómo se debe configurar.
Cabe distinguir dos tipos diferentes de servicios de red:

• Infraestructura
• Cliente.

Los primeros están diseñados para proporcionar conectividad básica y control de dispositivos. Estos incluyen VTY, SNMP, NTP, Syslog, AAA, protocolos de enrutamiento, CoPP, etc.
Estos últimos organizan el servicio para el cliente: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP, etc.
Por supuesto, también hay casos límite: ¿dónde incluir MPLS LDP, BGP? Sí, y se pueden utilizar protocolos de enrutamiento para los clientes. Pero esto no es importante.

Ambos tipos de servicios se descomponen en primitivas de configuración:

• Interfaces físicas y lógicas (tag/anteg, mtu)
• Direcciones IP y VRF (IP, IPv6, VRF)
• ACL y políticas de procesamiento de tráfico
• Protocolos (IGP, BGP, MPLS)
• Políticas de enrutamiento (listas de prefijos, comunidades, filtros ASN).
• Servicios de utilidades (SSH, NTP, LLDP, Syslog...)
• Etc.

Cómo exactamente haremos esto, todavía no tengo idea. Lo analizaremos en un artículo aparte.

Si nos acercamos un poco más a la vida, entonces podríamos describir eso.
El conmutador Leaf debe tener sesiones BGP con todos los conmutadores Spine conectados, importar redes conectadas al proceso y aceptar solo redes de un determinado prefijo de conmutadores Spine. Limite CoPP IPv6 ND a 10 pps, etc.
A su vez, las espinas mantienen sesiones con todos los clientes potenciales conectados, actuando como reflectores de raíz, y aceptan de ellos solo rutas de cierta longitud y con una determinada comunidad.

Componente 4: Mecanismo de inicialización del dispositivo

Bajo este título combino muchas de las acciones que deben ocurrir para que un dispositivo aparezca en el radar y se pueda acceder a él de forma remota.

1. Ingrese el dispositivo en el sistema de inventario.
2. Seleccione una dirección IP de administración.
3. Configure el acceso básico a él:
   Nombre de host, dirección IP de administración, ruta a la red de administración, usuarios, claves SSH, protocolos: telnet/SSH/NETCONF

Hay tres enfoques:

• Todo es completamente manual. El dispositivo se lleva al stand, donde una persona orgánica ordinaria lo introducirá en los sistemas, lo conectará a la consola y lo configurará. Puede funcionar en pequeñas redes estáticas.
• ZTP: aprovisionamiento sin intervención. El hardware llegó, se puso en pie, recibió una dirección vía DHCP, fue a un servidor especial y se configuró solo.
• La infraestructura de servidores de consola, donde la configuración inicial se realiza a través del puerto de consola en modo automático.

Hablaremos de los tres en un artículo aparte.

Componente 5: modelo de configuración independiente del proveedor

Hasta ahora, todos los sistemas han recibido parches dispares que proporcionan variables y una descripción declarativa de lo que nos gustaría ver en la red. Pero tarde o temprano tendrás que lidiar con detalles específicos.
En esta etapa, para cada dispositivo específico, las primitivas, los servicios y las variables se combinan en un modelo de configuración que en realidad describe la configuración completa de un dispositivo específico, solo que de manera neutral en cuanto al proveedor.
¿Qué hace este paso? ¿Por qué no crear inmediatamente una configuración de dispositivo que puedas simplemente cargar?
De hecho, esto resuelve tres problemas:

1. No se adapte a una interfaz específica para interactuar con el dispositivo. Ya sea CLI, NETCONF, RESTCONF, SNMP, el modelo será el mismo.
2. No mantengas el número de plantillas/scripts según el número de proveedores en la red, y si cambia el diseño, cambia lo mismo en varios lugares.
3. Cargue la configuración del dispositivo (copia de seguridad), colóquela exactamente en el mismo modelo y compare directamente la configuración de destino con la existente para calcular el delta y preparar un parche de configuración que cambiará solo aquellas partes que sean necesarias o para identificar desviaciones.

Como resultado de esta etapa obtenemos una configuración independiente del proveedor.

Componente 6. Interfaz de controlador específica del proveedor

No debe enorgullecerse de la esperanza de que algún día sea posible configurar un ciska exactamente de la misma manera que un Juniper, simplemente enviándoles exactamente las mismas llamadas. A pesar de la creciente popularidad de las cajas blancas y la aparición de soporte para NETCONF, RESTCONF, OpenConfig, el contenido específico que ofrecen estos protocolos difiere de un proveedor a otro, y esta es una de sus diferencias competitivas a la que no renunciarán tan fácilmente.
Esto es más o menos lo mismo que OpenContrail y OpenStack, que tienen RestAPI como interfaz NorthBound, esperan llamadas completamente diferentes.

Entonces, en el quinto paso, el modelo independiente del proveedor debe adoptar la forma en que irá al hardware.
Y aquí todos los medios son buenos (no): CLI, NETCONF, RESTCONF, SNMP simplemente.

Por lo tanto, necesitaremos un controlador que transfiera el resultado del paso anterior al formato requerido de un proveedor específico: un conjunto de comandos CLI, una estructura XML.

Componente 7. Mecanismo de entrega de configuración al dispositivo

Hemos generado la configuración, pero aún es necesario entregarla a los dispositivos y, obviamente, no manualmente.
Primero, nos enfrentamos a la pregunta de ¿qué transporte utilizaremos? Y hoy la elección ya no es pequeña:

• CLI (telnet, ssh)
• SNMP
• CONF.NET
• DESCANSO
• REST API
• OpenFlow (aunque es un caso atípico porque es una forma de entregar FIB, no configuraciones)

Pongamos los puntos aquí. CLI es heredado. SNMP... tos, tos.
RESTCONF es todavía un animal desconocido; casi nadie admite la API REST. Por lo tanto, nos centraremos en NETCONF en la serie.

De hecho, como el lector ya habrá comprendido, en este punto ya hemos decidido la interfaz: el resultado del paso anterior ya se presenta en el formato de la interfaz elegida.

En segundo lugar¿Y con qué herramientas haremos esto?
Aquí también hay una gran variedad de opciones:

• Guión o plataforma autoescrito. Armémonos con ncclient y asyncIO y hagamos todo nosotros mismos. ¿Cuánto nos cuesta construir un sistema de implementación desde cero?
• Ansible con su rica biblioteca de módulos de red.
• Salt con su magro trabajo con la red y conexión con Napalm.
• En realidad Napalm, que conoce a un par de vendedores y listo, adiós.
• Nornir es otro animal que diseccionaremos en el futuro.

Aquí aún no se ha elegido el favorito; estaremos buscando.

¿Qué más es importante aquí? Consecuencias de aplicar la configuración.
Exitoso o no. ¿Todavía hay acceso al hardware o no?
Parece que la confirmación ayudará aquí con la confirmación y validación de lo que se descargó en el dispositivo.
Esto, combinado con la implementación correcta de NETCONF, reduce significativamente la gama de dispositivos adecuados; no muchos fabricantes admiten confirmaciones normales. Pero éste es sólo uno de los requisitos previos para RFP. Al final, a nadie le preocupa que ningún proveedor ruso cumpla con la condición de la interfaz 32*100GE. ¿O está preocupado?

Componente 8. CI/CD

En este punto ya tenemos lista la configuración para todos los dispositivos de la red.
Escribo “para todo” porque estamos hablando de versionar el estado de la red. E incluso si necesita cambiar la configuración de un solo conmutador, los cambios se calculan para toda la red. Obviamente, pueden ser cero para la mayoría de los nodos.

Pero, como ya se dijo anteriormente, no somos una especie de bárbaros que quieren poner todo directamente en producción.
La configuración generada primero debe pasar por Pipeline CI/CD.

CI/CD significa Integración Continua, Despliegue Continuo. Este es un enfoque en el que el equipo no solo lanza una nueva versión importante cada seis meses, reemplazando completamente la anterior, sino que implementa (implementación) nuevas funcionalidades de manera incremental y periódica en pequeñas porciones, cada una de las cuales se prueba exhaustivamente en cuanto a compatibilidad, seguridad y rendimiento (Integración).

Para ello contamos con un sistema de control de versiones que monitorea los cambios de configuración, un laboratorio que verifica si el servicio al cliente está roto, un sistema de monitoreo que verifica este hecho y el último paso es implementar los cambios en la red de producción.

Con la excepción de los comandos de depuración, absolutamente todos los cambios en la red deben pasar por el canal CI/CD; esta es nuestra garantía de una vida tranquila y una carrera larga y feliz.

Componente 9. Sistema de respaldo y detección de anomalías

Bueno, no es necesario volver a hablar de copias de seguridad.
Simplemente los colocaremos en git según la corona o ante un cambio de configuración.

Pero la segunda parte es más interesante: alguien debería vigilar estas copias de seguridad. Y en algunos casos, ese alguien debe ir y cambiar todo como estaba, y en otros, maullarle a alguien que algo anda mal.
Por ejemplo, si ha aparecido un nuevo usuario que no está registrado en las variables, es necesario eliminarlo del hack. Y si es mejor no tocar una nueva regla de firewall, tal vez alguien acaba de activar la depuración, o tal vez el nuevo servicio, un chapucero, no se registró de acuerdo con las regulaciones, pero la gente ya se ha unido a él.

Todavía no escaparemos de algún pequeño delta en la escala de toda la red, a pesar de los sistemas de automatización y la mano férrea de la dirección. Para depurar problemas, nadie agregará configuración a los sistemas de todos modos. Además, es posible que ni siquiera estén incluidos en el modelo de configuración.

Por ejemplo, una regla de firewall para contar la cantidad de paquetes por IP específica para localizar un problema es una configuración temporal completamente común.

Componente 10. Sistema de monitoreo

Al principio no iba a abordar el tema del seguimiento; sigue siendo un tema voluminoso, controvertido y complejo. Pero a medida que avanzaban las cosas, resultó que esto era una parte integral de la automatización. Y es imposible evitarlo, incluso sin práctica.

La evolución del pensamiento es una parte orgánica del proceso de CI/CD. Después de implementar la configuración en la red, debemos poder determinar si todo está bien ahora.
Y no estamos hablando solo y no tanto de los horarios de uso de la interfaz o la disponibilidad de los nodos, sino de cosas más sutiles: la presencia de las rutas necesarias, los atributos en ellas, el número de sesiones BGP, los vecinos OSPF, el rendimiento de un extremo a otro. de servicios superpuestos.
¿Los syslogs del servidor externo dejaron de acumularse, o el agente SFlow se estropeó, o las caídas en las colas comenzaron a crecer, o se estropeó la conectividad entre algún par de prefijos?

Reflexionaremos sobre esto en un artículo aparte.

Conclusión

Como base, elegí uno de los diseños de red de centros de datos modernos: L3 Clos Fabric con BGP como protocolo de enrutamiento.
Esta vez construiremos la red en Juniper, porque ahora la interfaz JunOs es un vanlove.

Hagamos nuestra vida más difícil usando solo herramientas de código abierto y una red de múltiples proveedores; así que, además de Juniper, elegiré a una persona más afortunada en el camino.

El plan para las próximas publicaciones es algo como esto:
Primero hablaré de las redes virtuales. En primer lugar, porque quiero y, en segundo lugar, porque sin ello el diseño de la red de infraestructuras no quedará muy claro.
Luego, sobre el diseño de la red en sí: topología, enrutamiento, políticas.
Montemos un soporte de laboratorio.
Pensemos en ello y tal vez practiquemos inicializando el dispositivo en la red.
Y luego sobre cada componente en detalle.

Y sí, no prometo terminar elegantemente este ciclo con una solución ya preparada. 🙂

Enlaces de interés

• Antes de profundizar en la serie, vale la pena leer el libro de Natasha Samoilenko. Python para ingenieros de redes. Y tal vez pase curso.
• También será útil leer RFC sobre el diseño de fábricas de centros de datos de Facebook por Peter Lapukhov.
• La documentación de arquitectura le dará una idea de cómo funciona Overlay SDN. Tela de tungsteno (anteriormente Open Contrail).

Gracias

Garganta Romana. Para comentarios y ediciones.
Artem Chernobay. Para KDPV.

Fuente: habr.com