En los dos primeros artículos, planteé el tema de la automatización y esbocé su marco, en el segundo me retiré a la virtualización de redes, como primer enfoque para automatizar la configuración de servicios.
Ahora es el momento de dibujar un diagrama de la red física.
Si no está familiarizado con la configuración de redes de centros de datos, le recomiendo encarecidamente comenzar con .
Todos los problemas:
Las prácticas descritas en esta serie deben ser aplicables a cualquier tipo de red, de cualquier tamaño y con cualquier variedad de proveedores (no). Sin embargo, es imposible describir un ejemplo universal de la aplicación de estos enfoques. Por tanto, me centraré en la arquitectura moderna de la red DC: .
Haremos DCI en MPLS L3VPN.
Una red Overlay se ejecuta sobre la red física desde el host (esto podría ser VXLAN de OpenStack o Tungsten Fabric o cualquier otra cosa que requiera solo conectividad IP básica de la red).
En este caso, obtenemos un escenario de automatización relativamente simple, porque tenemos muchos equipos que están configurados de la misma manera.
Elegiremos una DC esférica en el vacío:
- Una versión de diseño en todas partes.
- Dos proveedores formando dos planos de red.
- Un DC es como otro, como dos guisantes en una vaina.
contenido
- Topología física
- Enrutamiento
- plan de propiedad intelectual
- Laba
- Conclusión
- Enlaces de interés
Deje que nuestro proveedor de servicios LAN_DC, por ejemplo, presente vídeos de formación sobre cómo sobrevivir en ascensores atascados.
En las megaciudades esto es muy popular, por lo que se necesitan muchas máquinas físicas.
Primero, describiré la red aproximadamente como me gustaría que fuera. Y luego lo simplificaré para el laboratorio.
Topología física
Ubicaciones
LAN_DC tendrá 6 DC:
- Rusia (RU):
- Moscú (msk)
- Kazán (kzn)
- España (SP):
- Barcelona (bcn)
- Málaga (mlg)
- Porcelana (CN):
- Shangai (sha)
- Xi'an (como)
Dentro de DC (Intra-DC)
Todos los DC tienen redes de conectividad interna idénticas basadas en la topología Clos.
¿Qué tipo de redes Clos son y por qué están en un apartado aparte? .
Cada CD cuenta con 10 racks con máquinas, estarán numerados como A, B, C Y así sucesivamente.
Cada rack tiene 30 máquinas. No nos interesarán.
Además, en cada bastidor hay un interruptor al que están conectadas todas las máquinas; esto es Interruptor de la parte superior del rack - ToR o de lo contrario, en términos de la fábrica Clos, la llamaremos Hoja.
Esquema general de la fábrica.
los llamaremos XXX-hojaYDonde XXX - abreviatura de tres letras DC, y Y - número de serie. Por ejemplo, kzn-leaf11.
En mis artículos me permitiré utilizar los términos Leaf y ToR de manera bastante frívola como sinónimos. Sin embargo, debemos recordar que este no es el caso.
ToR es un switch instalado en un rack al que se conectan las máquinas.
Leaf es la función de un dispositivo en una red física o un conmutador de primer nivel en términos de topología Cloes.
Es decir, Hoja! = ToR.
Entonces Leaf puede ser un conmutador EndofRaw, por ejemplo.
Sin embargo, en el marco de este artículo los trataremos como sinónimos.
Cada conmutador ToR está conectado a su vez a cuatro conmutadores de agregación de nivel superior: Espina. Un bastidor en el DC está asignado para Spines. Lo nombraremos de manera similar: XXX-columna vertebralY.
El mismo rack contendrá equipos de red para la conectividad entre los enrutadores DC - 2 con MPLS a bordo. Pero, en general, estos son los mismos TdR. Es decir, desde el punto de vista de los conmutadores Spine, el ToR habitual con máquinas conectadas o un enrutador para DCI no importa en absoluto, solo el reenvío.
Estos TdR especiales se denominan hoja de borde. los llamaremos XXX-bordeY.
Se verá así.
En el diagrama de arriba, coloqué el borde y la hoja al mismo nivel. Nos enseñaron a considerar los enlaces ascendentes (de ahí el término) como enlaces ascendentes. Y aquí resulta que el “enlace ascendente” DCI vuelve a caer, lo que para algunos rompe ligeramente la lógica habitual. En el caso de redes grandes, cuando los centros de datos se dividen en unidades aún más pequeñas - POD's (Punto de entrega), resaltar individuo Edge-PODEs para DCI y acceso a redes externas.
Para facilitar la percepción en el futuro, seguiré dibujando Edge sobre Spine, aunque tengamos en cuenta que no hay inteligencia en Spine y no hay diferencias cuando se trabaja con Leaf y Edge-leaf normales (aunque puede haber matices aquí). , pero en general esto es cierto).
Esquema de una fábrica con Edge-leafs.
La trinidad de Leaf, Spine y Edge forman una red o fábrica de Underlay.
La tarea de una fábrica de redes (léase Underlay), como ya la hemos definido en , muy, muy simple: proporcionar conectividad IP entre máquinas tanto dentro del mismo DC como entre ellas.
Es por eso que la red se llama fábrica, como, por ejemplo, una fábrica de conmutación dentro de cajas de red modulares, sobre las cuales puede leer más en .
En general, esta topología se denomina fábrica, porque tejido traducido significa tejido. Y es difícil no estar de acuerdo:
La fábrica es completamente L3. Sin VLAN, sin transmisión: tenemos programadores maravillosos en LAN_DC, saben cómo escribir aplicaciones que viven en el paradigma L3 y las máquinas virtuales no requieren Live Migration con preservación de la dirección IP.
Y una vez más: la respuesta a la pregunta de por qué la fábrica y por qué L3 está en un lugar separado .
DCI - Interconexión del centro de datos (Inter-DC)
Los DCI se organizarán mediante Edge-Leaf, es decir, son nuestro punto de salida a la autopista.
Para simplificar, suponemos que los DC están conectados entre sí mediante enlaces directos.
Excluyamos de nuestra consideración la conectividad externa.
Soy consciente de que cada vez que elimino un componente, simplifico significativamente la red. Y cuando automaticemos nuestra red abstracta, todo irá bien, pero en la real habrá muletas.
Esto es cierto. Aún así, el objetivo de esta serie es pensar y trabajar en enfoques, no resolver heroicamente problemas imaginarios.
En Edge-Leafs, la base se coloca en la VPN y se transmite a través de la red troncal MPLS (el mismo enlace directo).
Este es el diagrama de nivel superior que obtenemos.
Enrutamiento
Para el enrutamiento dentro del DC usaremos BGP.
En el troncal MPLS OSPF+LDP.
Para DCI, es decir, organizar la conectividad subterránea: BGP L3VPN sobre MPLS.
Esquema de enrutamiento general
No hay OSPF ni ISIS (protocolo de enrutamiento prohibido en la Federación Rusa) en la fábrica.
Esto significa que no habrá descubrimiento automático ni cálculo de rutas más cortas, solo configuración manual (en realidad automática; estamos hablando de automatización) para configurar el protocolo, la vecindad y las políticas.
Esquema de enrutamiento BGP dentro del DC
¿Por qué BGP?
Sobre este tema hay que lleva el nombre de Facebook y Arista, que explica cómo construir muy grande Redes de centros de datos utilizando BGP. Se lee casi como ficción, lo recomiendo mucho para una velada lánguida.
Y también hay una sección completa en mi artículo dedicada a esto. ¿A dónde te llevo y .
Pero, en resumen, ningún IGP es adecuado para redes de grandes centros de datos, donde el número de dispositivos de red asciende a miles.
Además, utilizar BGP en todas partes le permitirá no perder tiempo soportando varios protocolos diferentes y sincronizando entre ellos.
Con la mano en el corazón, en nuestra fábrica, que con un alto grado de probabilidad no crecerá rápidamente, OSPF sería suficiente para los ojos. En realidad, estos son problemas de los megaescaladores y los titanes de las nubes. Pero imaginemos que lo necesitamos solo para algunas versiones y usaremos BGP, como nos legó Pyotr Lapukhov.
Políticas de enrutamiento
En los conmutadores Leaf, importamos prefijos de las interfaces de red Underlay a BGP.
Tendremos una sesión BGP entre cada un par Leaf-Spine, en el que estos prefijos subyacentes se anunciarán en la red aquí y allá.
Dentro de un centro de datos, distribuiremos las especificaciones que importamos a ToRe. En Edge-Leafs los agregaremos y los anunciaremos a los DC remotos y los enviaremos a los TOR. Es decir, cada TdR sabrá exactamente cómo llegar a otro TdR en el mismo DC y dónde está el punto de entrada para llegar a los TdR en otro DC.
En DCI, las rutas se transmitirán como VPNv4. Para hacer esto, en Edge-Leaf, la interfaz hacia la fábrica se colocará en un VRF, llamémoslo UNDERLAY, y la vecindad con Spine en Edge-Leaf aumentará dentro del VRF, y entre Edge-Leafs en el VPNv4- familia.
También prohibiremos volver a anunciar las rutas recibidas de las espinas de regreso a ellas.
En Leaf y Spine no importaremos Loopbacks. Sólo los necesitamos para determinar el ID del enrutador.
Pero en Edge-Leafs lo importamos a Global BGP. Entre direcciones de Loopback, Edge-Leafs establecerá una sesión BGP en la familia VPN IPv4 entre sí.
Tendremos una red troncal OSPF+LDP entre dispositivos EDGE. Todo está en una zona. Configuración extremadamente simple.
Esta es la imagen con el enrutamiento.
ASN de BGP
ASN de borde-hoja
En Edge-Leafs habrá un ASN en todos los DC. Es importante que haya iBGP entre Edge-Leafs y no nos dejemos atrapar por los matices de eBGP. Sea 65535. En realidad, este podría ser el número de un AS público.
ASN de la columna vertebral
En Spine tendremos un ASN por DC. Comencemos aquí con el primer número de la gama de AS privados: 64512, 64513 y así sucesivamente.
¿Por qué ASN en DC?
Dividamos esta pregunta en dos:
- ¿Por qué los ASN son los mismos en todas las columnas de un DC?
- ¿Por qué son diferentes en diferentes países en desarrollo?
¿Por qué hay los mismos ASN en todas las columnas de un DC?
Así es como se verá el AS-Path de la ruta subyacente en Edge-Leaf:
[leafX_ASN, spine_ASN, edge_ASN]
Cuando intente anunciarlo nuevamente en Spine, lo descartará porque su AS (Spine_AS) ya está en la lista.
Sin embargo, dentro del DC estamos completamente satisfechos de que las rutas Underlay que ascienden al Edge no podrán bajar. Toda comunicación entre hosts dentro del DC debe ocurrir dentro del nivel de la columna vertebral.
En este caso, las rutas agregadas de otros DC llegarán fácilmente a los ToR: su AS-Path solo tendrá ASN 65535, el número de AS Edge-Leafs, porque ahí es donde se crearon.
¿Por qué son diferentes en diferentes países en desarrollo?
En teoría, es posible que necesitemos arrastrar Loopback y algunas máquinas virtuales de servicio entre DC.
Por ejemplo, en el host ejecutaremos Route Reflector o (Virtual Network Gateway), que se bloqueará con TopR a través de BGP y anunciará su loopback, al que debería ser accesible desde todos los DC.
Así es como se verá su AS-Path:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]
Y no debería haber ASN duplicados en ninguna parte.
Es decir, Spine_DC1 y Spine_DC2 deben ser diferentes, al igual que leafX_DC1 y leafY_DC2, que es exactamente a lo que nos estamos acercando.
Como probablemente sepa, existen trucos que le permiten aceptar rutas con ASN duplicados a pesar del mecanismo de prevención de bucles (permitido en Cisco). E incluso tiene usos legítimos. Pero ésta es una brecha potencial en la estabilidad de la red. Y yo personalmente caí en eso un par de veces.
Y si tenemos la oportunidad de no utilizar cosas peligrosas, la aprovecharemos.
Hoja ASN
Tendremos un ASN individual en cada switch Leaf de toda la red.
Hacemos esto por las razones expuestas anteriormente: AS-Path sin bucles, configuración BGP sin marcadores.
Para que las rutas entre Leafs transcurran sin problemas, AS-Path debería verse así:
[leafX_ASN, spine_ASN, leafY_ASN]
donde sería bueno que leafX_ASN y leafY_ASN fueran diferentes.
Esto también es necesario para la situación con el anuncio de un loopback VNF entre DC:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]
Usaremos un ASN de 4 bytes y lo generaremos en función del ASN de Spine y el número de conmutador de Leaf, es decir, así: Columna_ASN.0000X.
Esta es la imagen con ASN.
plan de propiedad intelectual
Básicamente, necesitamos asignar direcciones para las siguientes conexiones:
- Direcciones de red subyacentes entre ToR y la máquina. Deben ser únicos dentro de toda la red para que cualquier máquina pueda comunicarse con cualquier otra. Gran ajuste 10/8. Por cada rejilla hay /26 con reserva. Asignaremos /19 por DC y /17 por región.
- Direcciones de enlace entre Leaf/Tor y Spine.
Me gustaría asignarlos algorítmicamente, es decir, calcularlos a partir de los nombres de los dispositivos que deben conectarse.
Que así sea... 169.254.0.0/16.
A saber 169.254.00X.Y/31Donde X - Número de lomo, Y — Red P2P /31.
Esto le permitirá lanzar hasta 128 racks y hasta 10 Spines en el DC. Las direcciones de enlace pueden (y se repetirán) de DC a DC. - Organizamos la unión Spine-Edge-Leaf en subredes 169.254.10X.Y/31, donde exactamente lo mismo X - Número de lomo, Y — Red P2P /31.
- Vincular direcciones desde Edge-Leaf a la red troncal MPLS. Aquí la situación es algo diferente: el lugar donde todas las piezas están conectadas en un solo pastel, por lo que reutilizar las mismas direcciones no funcionará; debe seleccionar la siguiente subred libre. Por tanto, tomemos como base 192.168.0.0/16 y sacaremos los que estén libres.
- Direcciones de bucle invertido. Les daremos toda la gama. 172.16.0.0/12.
- Hoja - /25 por CC - los mismos 128 bastidores. Asignaremos /23 por región.
- Lomo - /28 por DC - hasta 16 Lomo. Asignemos /26 por región.
- Edge-Leaf - /29 por DC - hasta 8 cajas. Asignemos /27 por región.
Si no tenemos suficientes rangos asignados en el DC (y no habrá ninguno; afirmamos ser hiperescaladores), simplemente seleccionamos el siguiente bloque.
Esta es la imagen con dirección IP.
Bucles:
Prefijo
Rol del dispositivo
Región
DC
172.16.0.0/23
Edge
172.16.0.0/27
ru
172.16.0.0/29
msk
172.16.0.8/29
kzn
172.16.0.32/27
sp
172.16.0.32/29
bcn
172.16.0.40/29
mlg
172.16.0.64/27
cn
172.16.0.64/29
sha
172.16.0.72/29
como
172.16.2.0/23
espina
172.16.2.0/26
ru
172.16.2.0/28
msk
172.16.2.16/28
kzn
172.16.2.64/26
sp
172.16.2.64/28
bcn
172.16.2.80/28
mlg
172.16.2.128/26
cn
172.16.2.128/28
sha
172.16.2.144/28
como
172.16.8.0/21
hoja
172.16.8.0/23
ru
172.16.8.0/25
msk
172.16.8.128/25
kzn
172.16.10.0/23
sp
172.16.10.0/25
bcn
172.16.10.128/25
mlg
172.16.12.0/23
cn
172.16.12.0/25
sha
172.16.12.128/25
como
Subyacer:
Prefijo
Región
DC
10.0.0.0/17
ru
10.0.0.0/19
msk
10.0.32.0/19
kzn
10.0.128.0/17
sp
10.0.128.0/19
bcn
10.0.160.0/19
mlg
10.1.0.0/17
cn
10.1.0.0/19
sha
10.1.32.0/19
como
Laba
Dos vendedores. Una red. ADSM.
Enebro + Arista. Ubuntu. Buena Eva.
La cantidad de recursos de nuestro servidor virtual en Mirana aún es limitada, por lo que para practicar usaremos una red simplificada al límite.
Dos centros de datos: Kazán y Barcelona.
- Dos lomos cada uno: Enebro y Arista.
- Un toro (Leaf) en cada uno: Juniper y Arista, con un host conectado (tomemos una LIO Cisco liviana para esto).
- Un nodo Edge-Leaf cada uno (por ahora solo Juniper).
- Un switch Cisco para gobernarlos a todos.
- Además de las cajas de red, se ejecuta una máquina de control virtual. Ejecutando Ubuntu.
Tiene acceso a todos los dispositivos, ejecutará sistemas IPAM/DCIM, un montón de scripts de Python, Ansible y cualquier otra cosa que podamos necesitar.
de todos los dispositivos de red, que intentaremos reproducir mediante la automatización.
Conclusión
¿Eso también se acepta? ¿Debo escribir una breve conclusión debajo de cada artículo?
Así que elegimos Red Kloz dentro del DC, ya que esperamos mucho tráfico de este a oeste y queremos ECMP.
La red se dividió en física (subyacente) y virtual (superpuesta). Al mismo tiempo, la superposición comienza desde el host, simplificando así los requisitos para la base.
Elegimos BGP como protocolo de enrutamiento para redes de red por su escalabilidad y flexibilidad de políticas.
Tendremos nodos separados para organizar DCI - Edge-leaf.
La red troncal tendrá OSPF+LDP.
DCI se implementará en base a MPLS L3VPN.
Para enlaces P2P, calcularemos las direcciones IP algorítmicamente en función de los nombres de los dispositivos.
Asignaremos loopbacks según el rol de los dispositivos y su ubicación de forma secuencial.
Prefijos subyacentes: solo en conmutadores Leaf de forma secuencial según su ubicación.
Supongamos que ahora mismo aún no tenemos el equipo instalado.
Por tanto, nuestros próximos pasos serán agregarlos a los sistemas (IPAM, inventario), organizar el acceso, generar una configuración y desplegarla.
En el próximo artículo nos ocuparemos de Netbox, un sistema de gestión e inventario del espacio IP en un centro de datos.
Gracias
- Andrey Glazkov alias @glazgoo por la revisión y correcciones
- Alexander Klimenko alias @v00lk por la revisión y edición
- Artyom Chernobay para KDPV
Fuente: habr.com