В Describí el marco de automatización de la red. Según algunos, incluso esta primera aproximación al problema ya ha resuelto algunas cuestiones. Y esto me hace muy feliz, porque nuestro objetivo en el ciclo no es tapar los scripts de Ansible con Python, sino construir un sistema.
El mismo marco establece el orden en el que abordaremos la cuestión.
Y la virtualización de redes, a la que está dedicado este número, no encaja particularmente en el tema ADSM, donde analizamos la automatización.
Pero veámoslo desde un ángulo diferente.
Muchos servicios utilizan la misma red desde hace mucho tiempo. En el caso de un operador de telecomunicaciones, esto es 2G, 3G, LTE, banda ancha y B2B, por ejemplo. En el caso de un DC: conectividad para diferentes clientes, Internet, almacenamiento en bloques, almacenamiento de objetos.
Y todos los servicios requieren aislamiento unos de otros. Así aparecieron las redes superpuestas.
Y todos los servicios no quieren esperar a que una persona los configure manualmente. Así aparecieron los orquestadores y las SDN.
El primer enfoque para la automatización sistemática de la red, o más bien parte de ella, se ha adoptado e implementado durante mucho tiempo en muchos lugares: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.
De eso es de lo que nos ocuparemos hoy.
contenido
- razones
- Vocabulario
- Capa base: red física
- Superposición - red virtual
- Superposición con TdR
- Superposición del anfitrión
- Usando tela de tungsteno como ejemplo
- Comunicación dentro de una sola máquina física
- Comunicación entre VM ubicadas en diferentes máquinas físicas
- Salida al mundo exterior
- Preguntas Frecuentes
- Conclusión
- Enlaces de interés
razones
Y ya que estamos hablando de esto, vale la pena mencionar los requisitos previos para la virtualización de la red. De hecho, este proceso no comenzó ayer.
Probablemente hayas escuchado más de una vez que la red siempre ha sido la parte más inerte de cualquier sistema. Y esto es cierto en todos los sentidos. La red es la base sobre la que se basa todo y es bastante difícil realizar cambios en ella: los servicios no lo toleran cuando la red no funciona. A menudo, desmantelar un solo nodo puede desactivar una gran parte de las aplicaciones y afectar a muchos clientes. Esta es en parte la razón por la que el equipo de la red puede resistirse a cualquier cambio, porque ahora de alguna manera funciona (Puede que ni siquiera sepamos cómo), pero aquí es necesario configurar algo nuevo y se desconoce cómo afectará esto a la red.
Para no esperar a que los networkers inserten VLAN y no registrar ningún servicio en cada nodo de la red, a la gente se le ocurrió la idea de utilizar overlays (redes superpuestas) de las cuales hay una gran variedad: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE, etc.
Su atractivo radica en dos cosas simples:
- Solo se configuran los nodos finales; no es necesario tocar los nodos de tránsito. Esto acelera significativamente el proceso y, en ocasiones, permite excluir por completo al departamento de infraestructura de red del proceso de introducción de nuevos servicios.
- La carga está oculta en lo profundo de los encabezados: los nodos de tránsito no necesitan saber nada al respecto, ni sobre las direcciones en los hosts ni sobre las rutas de la red superpuesta. Esto significa que necesita almacenar menos información en tablas, lo que significa utilizar un dispositivo más simple y económico.
En este tema no del todo completo, no planeo analizar todas las tecnologías posibles, sino describir el marco para el funcionamiento de redes superpuestas en centros de datos.
Toda la serie describirá un centro de datos que consta de filas de bastidores idénticos en los que está instalado el mismo equipo de servidor.
Este equipo ejecuta máquinas virtuales/contenedores/serverless que implementan servicios.
Vocabulario
En ciclo servidor Nombraré un programa que implementa el lado del servidor de la comunicación cliente-servidor.
Las máquinas físicas en racks se llaman servidores. no Lo haremos.
maquina fisica — Computadora x86 instalada en un rack. El término más utilizado host. Así lo llamaremos”coche"O host.
Hipervisor - una aplicación que se ejecuta en una máquina física que emula los recursos físicos en los que se ejecutan las máquinas virtuales. A veces, en la literatura e Internet, la palabra "hipervisor" se utiliza como sinónimo de "host".
Maquina virtual - un sistema operativo que se ejecuta en una máquina física encima de un hipervisor. Para nosotros en este ciclo, realmente no importa si en realidad se trata de una máquina virtual o simplemente un contenedor. Llamémoslo "VM«
Arrendatario Es un concepto amplio que definiré en este artículo como un servicio independiente o un cliente independiente.
Multi Alquiler o multitenencia: el uso de la misma aplicación por diferentes clientes/servicios. Al mismo tiempo, el aislamiento de los clientes entre sí se logra gracias a la arquitectura de la aplicación y no a través de instancias que se ejecutan por separado.
ToR: interruptor de la parte superior del rack - un conmutador instalado en un bastidor al que están conectadas todas las máquinas físicas.
Además de la topología ToR, varios proveedores practican End of Row (EoR) o Middle of Row (aunque este último es una rareza despectiva y no he visto la abreviatura MoR).
Red subyacente o la red subyacente o base es la infraestructura de red física: conmutadores, enrutadores, cables.
Red superpuesta o red superpuesta o superposición: una red virtual de túneles que se ejecutan sobre la física.
Tejido L3 o tejido IP - un invento asombroso de la humanidad que te permite evitar repetir STP y aprender TRILL para las entrevistas. Un concepto en el que toda la red hasta el nivel de acceso es exclusivamente L3, sin VLAN y, en consecuencia, enormes dominios de difusión extendidos. En la siguiente parte veremos de dónde viene la palabra "fábrica".
SDN - Red definida por software. Apenas necesita presentación. Un enfoque para la gestión de redes donde los cambios en la red no los realiza una persona, sino un programa. Por lo general, significa mover el plano de control más allá de los dispositivos de red finales hasta el controlador.
NFV - Virtualización de funciones de red: virtualización de dispositivos de red, lo que implica que algunas funciones de red se pueden ejecutar en forma de máquinas virtuales o contenedores para acelerar la implementación de nuevos servicios, organizar el encadenamiento de servicios y simplificar la escalabilidad horizontal.
VNF - Función de red virtual. Dispositivo virtual específico: router, switch, firewall, NAT, IPS/IDS, etc.
Ahora estoy simplificando deliberadamente la descripción a una implementación específica, para no confundir demasiado al lector. Para una lectura más reflexiva, lo remito a la sección . Además, Roma Gorge, que critica este artículo por sus imprecisiones, promete escribir un número aparte sobre tecnologías de virtualización de redes y servidores, más profundo y atento a los detalles.
La mayoría de las redes actuales se pueden dividir claramente en dos partes:
Subyacer — una red física con una configuración estable.
Superposición — abstracción sobre Underlay para aislar a los inquilinos.
Esto es cierto tanto para el caso de DC (que analizaremos en este artículo) como para el de ISP (que no analizaremos porque ya ha sido ). Por supuesto, con las redes empresariales la situación es algo diferente.
Imagen con foco en la red:
Subyacer
La base es una red física: conmutadores de hardware y cables. Los dispositivos subterráneos saben cómo llegar a las máquinas físicas.
Se basa en protocolos y tecnologías estándar. Sobre todo porque los dispositivos de hardware hasta el día de hoy funcionan con software propietario que no permite programar el chip ni implementar sus propios protocolos, por lo que se necesita compatibilidad con otros proveedores y estandarización.
Pero alguien como Google puede darse el lujo de desarrollar sus propios conmutadores y abandonar los protocolos generalmente aceptados. Pero LAN_DC no es Google.
La capa subyacente cambia relativamente raramente porque su trabajo es la conectividad IP básica entre máquinas físicas. Underlay no sabe nada acerca de los servicios, clientes o inquilinos que se ejecutan sobre él; solo necesita entregar el paquete de una máquina a otra.
La base podría ser así:
- IPv4+OSPF
- IPv6+ISIS+BGP+L3VPN
- L2+TRINO
- L2+STP
La red Underlay se configura de la forma clásica: CLI/GUI/NETCONF.
Manualmente, scripts, utilidades propietarias.
El próximo artículo de la serie estará dedicado a la base con más detalle.
Superposición
Overlay es una red virtual de túneles extendida sobre Underlay, que permite que las máquinas virtuales de un cliente se comuniquen entre sí, al tiempo que proporciona aislamiento de otros clientes.
Los datos del cliente se encapsulan en algunos encabezados de túnel para su transmisión a través de la red pública.
Por lo tanto, las máquinas virtuales de un cliente (un servicio) pueden comunicarse entre sí a través de Overlay, sin siquiera saber qué ruta toma realmente el paquete.
La superposición podría ser, por ejemplo, como mencioné anteriormente:
- túnel GRE
- VXLAN
- EVPN
- L3VPN
- GENEVE
Una red superpuesta normalmente se configura y mantiene a través de un controlador central. Desde él, la configuración, el Plano de Control y el Plano de Datos se entregan a los dispositivos que enrutan y encapsulan el tráfico del cliente. Un poco Veamos esto con ejemplos.
Sí, esto es SDN en su forma más pura.
Hay dos enfoques fundamentalmente diferentes para organizar una red Overlay:
- Superposición con TdR
- Superposición del anfitrión
Superposición con TdR
La superposición puede comenzar en el conmutador de acceso (ToR) que se encuentra en el bastidor, como ocurre, por ejemplo, en el caso de una estructura VXLAN.
Este es un mecanismo probado en las redes de ISP y todos los proveedores de equipos de red lo admiten.
Sin embargo, en este caso, el conmutador ToR debe poder separar los distintos servicios, respectivamente, y el administrador de la red debe, hasta cierto punto, cooperar con los administradores de la máquina virtual y realizar cambios (aunque sea automáticamente) en la configuración de los dispositivos. .
Aquí remitiré al lector a un artículo sobre nuestro viejo amigo .
En este Se describen en detalle enfoques para construir una red de CC con una estructura EVPN VXLAN.
Y para una inmersión más completa en la realidad, puedes leer el libro de Tsiska. .
Observo que VXLAN es solo un método de encapsulación y la terminación de túneles puede ocurrir no en ToR, sino en el host, como ocurre en el caso de OpenStack, por ejemplo.
Sin embargo, la estructura VXLAN, donde la superposición comienza en ToR, es uno de los diseños de red superpuestos establecidos.
Superposición del anfitrión
Otro método consiste en iniciar y finalizar túneles en los hosts finales.
En este caso, la red (Underlay) sigue siendo lo más simple y estática posible.
Y el propio host realiza toda la encapsulación necesaria.
Por supuesto, esto requerirá ejecutar una aplicación especial en los hosts, pero vale la pena.
En primer lugar, ejecutar un cliente en una máquina Linux es más fácil o, digamos, incluso posible, mientras que en un conmutador lo más probable es que tenga que recurrir a soluciones SDN patentadas, lo que acaba con la idea de múltiples proveedores.
En segundo lugar, el cambio de ToR en este caso se puede dejar lo más simple posible, tanto desde el punto de vista del Plano de Control como del Plano de Datos. De hecho, entonces no necesita comunicarse con el controlador SDN, y tampoco necesita almacenar las redes/ARP de todos los clientes conectados; basta con conocer la dirección IP de la máquina física, lo que simplifica enormemente la conmutación/ tablas de enrutamiento.
En la serie ADSM, elijo el enfoque de superposición del host; luego solo hablaremos de ello y no volveremos a la fábrica de VXLAN.
Es más fácil mirar ejemplos. Y como sujeto de prueba tomaremos la plataforma OpenSource SDN OpenContrail, ahora conocida como .
Al final del artículo daré algunas ideas sobre la analogía con OpenFlow y OpenvSwitch.
Usando tela de tungsteno como ejemplo
Cada máquina física tiene enrutador virtual - un enrutador virtual que conoce las redes conectadas a él y a qué clientes pertenecen; esencialmente un enrutador PE. Para cada cliente, mantiene una tabla de enrutamiento aislada (léase VRF). Y vRouter en realidad realiza túneles de superposición.
Un poco más sobre vRouter se encuentra al final del artículo.
Cada VM ubicada en el hipervisor está conectada al vRouter de esta máquina a través de .
TAP - Terminal Access Point: una interfaz virtual en el kernel de Linux que permite la interacción en red.
Si hay varias redes detrás del vRouter, entonces se crea una interfaz virtual para cada una de ellas, a la que se le asigna una dirección IP; esta será la dirección de puerta de enlace predeterminada.
Todas las redes de un cliente se colocan en una VRF (una mesa), diferentes - en diferentes.
Haré una advertencia aquí de que no todo es tan simple y enviaré al lector curioso al final del artículo..
Para que los vRouters puedan comunicarse entre sí y, en consecuencia, las VM ubicadas detrás de ellos, intercambian información de enrutamiento a través de controlador SDN.
Para salir al mundo exterior, existe un punto de salida de la matriz: una puerta de enlace de red virtual. VNGW — Puerta de enlace de red virtual (mi término).
Ahora veamos ejemplos de comunicaciones, y todo quedará claro.
Comunicación dentro de una sola máquina física
VM0 quiere enviar un paquete a VM2. Supongamos por ahora que se trata de una máquina virtual de un solo cliente.
Plano de datos
- VM-0 tiene una ruta predeterminada a su interfaz eth0. El paquete se envía allí.
Esta interfaz eth0 en realidad está conectada virtualmente al enrutador virtual vRouter a través de la interfaz TAP tap0. - vRouter analiza a qué interfaz llegó el paquete, es decir, a qué cliente (VRF) pertenece y verifica la dirección del destinatario con la tabla de enrutamiento de este cliente.
- Habiendo detectado que el destinatario en la misma máquina está en un puerto diferente, vRouter simplemente le envía el paquete sin encabezados adicionales; en este caso, vRouter ya tiene un registro ARP.
En este caso, el paquete no ingresa a la red física, sino que se enruta dentro del vRouter.
Plano de control
Cuando se inicia la máquina virtual, el hipervisor le dice:
- Su propia dirección IP.
- La ruta predeterminada es a través de la dirección IP del vRouter en esta red.
El hipervisor informa a vRouter a través de una API especial:
- Lo que necesitas para crear una interfaz virtual.
- ¿Qué tipo de red virtual necesita crear (VM)?
- A qué VRF (VN) vincularlo.
- Una entrada ARP estática para esta máquina virtual: qué interfaz está detrás de su dirección IP y con qué dirección MAC está asociada.
Nuevamente, el procedimiento de interacción real se simplifica para comprender el concepto.
Por lo tanto, vRouter ve todas las máquinas virtuales de un cliente en una máquina determinada como redes conectadas directamente y puede enrutarlas él mismo.
Pero VM0 y VM1 pertenecen a clientes diferentes y, en consecuencia, están en diferentes tablas de vRouter.
Que puedan comunicarse entre sí directamente depende de la configuración del vRouter y del diseño de la red.
Por ejemplo, si las máquinas virtuales de ambos clientes usan direcciones públicas, o si NAT ocurre en el propio vRouter, entonces se puede realizar el enrutamiento directo al vRouter.
En la situación opuesta, es posible cruzar espacios de direcciones (es necesario pasar por un servidor NAT para obtener una dirección pública); esto es similar al acceso a redes externas, que se analizan a continuación.
Comunicación entre VM ubicadas en diferentes máquinas físicas
Plano de datos
- El comienzo es exactamente el mismo: VM-0 envía un paquete con el destino VM-7 (172.17.3.2) por defecto.
- vRouter lo recibe y esta vez ve que el destino está en una máquina diferente y se puede acceder a él a través de Tunnel0.
- Primero, cuelga una etiqueta MPLS que identifica la interfaz remota, de modo que en el reverso vRouter pueda determinar dónde colocar este paquete sin búsquedas adicionales.
- Tunnel0 tiene origen 10.0.0.2, destino: 10.0.1.2.
vRouter agrega encabezados GRE (o UDP) y una nueva IP al paquete original. - La tabla de enrutamiento de vRouter tiene una ruta predeterminada a través de la dirección ToR1 10.0.0.1. Ahí es donde lo envía.
- ToR1, como miembro de la red Underlay, sabe (por ejemplo, a través de OSPF) cómo llegar a 10.0.1.2 y envía el paquete a lo largo de la ruta. Tenga en cuenta que ECMP está habilitado aquí. Hay dos nexthops en la ilustración, y se clasificarán diferentes subprocesos en ellos por hash. En el caso de una fábrica real, lo más probable es que haya 4 próximos saltos.
Al mismo tiempo, no necesita saber qué hay debajo del encabezado de IP externa. Es decir, de hecho, bajo IP puede haber un sándwich de IPv6 sobre MPLS sobre Ethernet sobre MPLS sobre GRE sobre griego.
- En consecuencia, en el lado receptor, vRouter elimina GRE y, utilizando la etiqueta MPLS, comprende a qué interfaz debe enviarse este paquete, lo elimina y lo envía en su forma original al destinatario.
Plano de control
Cuando arrancas el coche, sucede lo mismo que se describe anteriormente.
Y además lo siguiente:
- Para cada cliente, vRouter asigna una etiqueta MPLS. Esta es la etiqueta de servicio L3VPN, por la cual los clientes estarán separados dentro de la misma máquina física.
De hecho, la etiqueta MPLS siempre la asigna incondicionalmente el vRouter; después de todo, no se sabe de antemano que la máquina solo interactuará con otras máquinas detrás del mismo vRouter y lo más probable es que esto ni siquiera sea cierto.
- vRouter establece una conexión con el controlador SDN mediante el protocolo BGP (o similar; en el caso de TF, es XMPP 0_o).
- A través de esta sesión, vRouter informa rutas a las redes conectadas al controlador SDN:
- Dirección de red
- Método de encapsulación (MPLSoGRE, MPLSoUDP, VXLAN)
- Etiqueta de cliente MPLS
- Tu dirección IP como nexthop
- El controlador SDN recibe dichas rutas de todos los vRouters conectados y las refleja a los demás. Es decir, actúa como Reflector de Ruta.
Lo mismo sucede en sentido contrario.
La superposición puede cambiar al menos cada minuto. Esto es más o menos lo que sucede en las nubes públicas, donde los clientes inician y apagan regularmente sus máquinas virtuales.
El controlador central se encarga de toda la complejidad de mantener la configuración y monitorear las tablas de conmutación/enrutamiento en el vRouter.
En términos generales, el controlador se comunica con todos los vRouters a través de BGP (o un protocolo similar) y simplemente transmite información de enrutamiento. BGP, por ejemplo, ya tiene Address-Family para transmitir el método de encapsulación. o .
Al mismo tiempo, la configuración de la red Underlay no cambia de ninguna manera, lo que, por cierto, es mucho más difícil de automatizar y más fácil de romper con un movimiento incómodo.
Salida al mundo exterior
En algún lugar la simulación debe terminar y debes salir del mundo virtual al real. Y necesitas una puerta de enlace de teléfono público.
Se practican dos enfoques:
- Se instala un enrutador de hardware.
- Se lanza un dispositivo que implementa las funciones de un enrutador (sí, después de SDN, también nos encontramos con VNF). Llamémoslo puerta de enlace virtual.
La ventaja del segundo enfoque es la escalabilidad horizontal económica (no hay suficiente potencia), lanzamos otra máquina virtual con una puerta de enlace. En cualquier máquina física, sin tener que buscar racks, unidades, salida de energía libres, comprar el hardware en sí, transportarlo, instalarlo, cambiarlo, configurarlo y luego también cambiar los componentes defectuosos en él.
Las desventajas de una puerta de enlace virtual son que una unidad de enrutador físico sigue siendo mucho más poderosa que una máquina virtual de múltiples núcleos, y su software, adaptado a su propia base de hardware, funciona mucho más estable (no). También es difícil negar el hecho de que el complejo de hardware y software simplemente funciona y solo requiere configuración, mientras que iniciar y mantener una puerta de enlace virtual es una tarea para ingenieros sólidos.
Con un pie, la puerta de enlace mira hacia la red virtual Overlay, como una máquina virtual normal, y puede interactuar con todas las demás máquinas virtuales. Al mismo tiempo, puede terminar las redes de todos los clientes y, en consecuencia, realizar el enrutamiento entre ellos.
Con el otro pie, la puerta de enlace mira hacia la red troncal y sabe cómo acceder a Internet.
Plano de datos
Es decir, el proceso se ve así:
- VM-0, habiendo predeterminado el mismo vRouter, envía un paquete con un destino en el mundo exterior (185.147.83.177) a la interfaz eth0.
- vRouter recibe este paquete y busca la dirección de destino en la tabla de enrutamiento; encuentra la ruta predeterminada a través de la puerta de enlace VNGW1 a través del túnel 1.
También ve que se trata de un túnel GRE con SIP 10.0.0.2 y DIP 10.0.255.2, y también necesita adjuntar primero la etiqueta MPLS de este cliente, que espera VNGW1. - vRouter empaqueta el paquete inicial con MPLS, GRE y nuevos encabezados IP y lo envía a ToR1 10.0.0.1 de forma predeterminada.
- La red subyacente entrega el paquete a la puerta de enlace VNGW1.
- La puerta de enlace VNGW1 elimina los encabezados de túnel GRE y MPLS, ve la dirección de destino, consulta su tabla de enrutamiento y comprende que está dirigida a Internet, es decir, a través de Vista completa o Predeterminada. Si es necesario, realiza la traducción NAT.
- Podría haber una red IP regular desde VNGW hasta la frontera, lo cual es poco probable.
Puede haber una red MPLS clásica (IGP+LDP/RSVP TE), puede haber una estructura trasera con BGP LU o un túnel GRE desde VNGW hasta la frontera a través de una red IP.
Sea como fuere, VNGW1 realiza los encapsulamientos necesarios y envía el paquete inicial hacia la frontera.
El tráfico en dirección opuesta pasa por los mismos pasos en el orden opuesto.
- La frontera deja caer el paquete a VNGW1.
- Lo desnuda, mira la dirección del destinatario y ve que es accesible a través del túnel Tunnel1 (MPLSoGRE o MPLSoUDP).
- En consecuencia, adjunta una etiqueta MPLS, un encabezado GRE/UDP y una nueva IP y la envía a su ToR3 10.0.255.1.
La dirección de destino del túnel es la dirección IP del vRouter detrás del cual se encuentra la VM de destino: 10.0.0.2. - La red subyacente entrega el paquete al vRouter deseado.
- El vRouter de destino lee GRE/UDP, identifica la interfaz mediante la etiqueta MPLS y envía un paquete IP desnudo a su interfaz TAP asociada con eth0 de la VM.
Plano de control
VNGW1 establece un vecindario BGP con un controlador SDN, del cual recibe toda la información de enrutamiento sobre los clientes: qué dirección IP (vRouter) está detrás de qué cliente y con qué etiqueta MPLS se identifica.
Del mismo modo, él mismo informa al controlador SDN de la ruta por defecto con la etiqueta de este cliente, indicándose a sí mismo como el siguiente salto. Y luego este valor predeterminado llega a los vRouters.
En VNGW, generalmente se produce agregación de rutas o traducción NAT.
Y en la otra dirección envía exactamente esta ruta agregada a la sesión con bordes o Reflectores de Ruta. Y de ellos recibe la ruta predeterminada o Full-View, o algo más.
En términos de encapsulación e intercambio de tráfico, VNGW no es diferente de vRouter.
Si amplía un poco el alcance, puede agregar otros dispositivos de red a los VNGW y vRouters, como firewalls, limpieza de tráfico o granjas de enriquecimiento, IPS, etc.
Y con la ayuda de la creación secuencial de VRF y el anuncio correcto de rutas, puede obligar al tráfico a circular de la manera deseada, lo que se denomina encadenamiento de servicios.
Es decir, aquí también el controlador SDN actúa como un reflector de ruta entre VNGW, vRouters y otros dispositivos de red.
Pero, de hecho, el controlador también publica información sobre ACL y PBR (enrutamiento basado en políticas), lo que hace que los flujos de tráfico individuales vayan de manera diferente a lo que les indica la ruta.
Preguntas Frecuentes
¿Por qué siempre haces el comentario GRE/UDP?
Bueno, en general, se puede decir que esto es específico de Tungsten Fabric; no es necesario tenerlo en cuenta en absoluto.
Pero si lo tomamos, entonces el propio TF, aunque todavía era OpenContrail, admitía ambas encapsulaciones: MPLS en GRE y MPLS en UDP.
UDP es bueno porque en el puerto de origen es muy fácil codificar una función hash del IP+Proto+Puerto original en su encabezado, lo que le permitirá realizar el equilibrio.
En el caso de GRE, por desgracia, solo hay IP externas y encabezados GRE, que son los mismos para todo el tráfico encapsulado y no se habla de equilibrio: pocas personas pueden mirar tan profundamente dentro del paquete.
Hasta hace algún tiempo, los routers, si sabían utilizar túneles dinámicos, lo hacían sólo en MPLSoGRE, y sólo muy recientemente aprendieron a utilizar MPLSoUDP. Por tanto, siempre tenemos que tener en cuenta la posibilidad de dos encapsulaciones diferentes.
Para ser justos, vale la pena señalar que TF es totalmente compatible con la conectividad L2 mediante VXLAN.
Prometiste establecer paralelismos con OpenFlow.
Realmente lo están pidiendo. vSwitch en el mismo OpenStack hace cosas muy similares, usando VXLAN, que, por cierto, también tiene un encabezado UDP.
En el plano de datos funcionan aproximadamente igual; en el plano de control difieren significativamente. Tungsten Fabric usa XMPP para entregar información de enrutamiento a vRouter, mientras que OpenStack ejecuta Openflow.
¿Puedes contarme un poco más sobre vRouter?
Se divide en dos partes: vRouter Agent y vRouter Forwarder.
El primero se ejecuta en el espacio de usuario del sistema operativo host y se comunica con el controlador SDN, intercambiando información sobre rutas, VRF y ACL.
El segundo implementa Data Plane, generalmente en Kernel Space, pero también puede ejecutarse en SmartNIC: tarjetas de red con una CPU y un chip de conmutación programable separado, que le permite eliminar la carga de la CPU de la máquina host y hacer que la red sea más rápida y eficiente. previsible.
Otro escenario posible es que vRouter sea una aplicación DPDK en User Space.
vRouter Agent envía la configuración a vRouter Forwarder.
¿Qué es una red virtual?
Mencioné al principio del artículo sobre VRF que cada inquilino está vinculado a su propio VRF. Y si esto fue suficiente para una comprensión superficial del funcionamiento de la red superpuesta, entonces en la siguiente iteración es necesario hacer aclaraciones.
Normalmente, en los mecanismos de virtualización, la entidad de Red Virtual (puede considerarlo como un nombre propio) se introduce por separado de los clientes/inquilinos/máquinas virtuales, algo completamente independiente. Y esta Red Virtual ya se puede conectar a través de interfaces a un inquilino, a otro, a dos o a cualquier lugar. Así, por ejemplo, el encadenamiento de servicios se implementa cuando el tráfico debe pasar a través de ciertos nodos en la secuencia requerida, simplemente creando y conectando redes virtuales en la secuencia correcta.
Por tanto, como tal, no existe correspondencia directa entre la Red Virtual y el inquilino.
Conclusión
Esta es una descripción muy superficial del funcionamiento de una red virtual con una superposición del host y un controlador SDN. Pero no importa qué plataforma de virtualización elija hoy, funcionará de manera similar, ya sea VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric o Juniper Contrail. Se diferenciarán en los tipos de encapsulaciones y encabezados, protocolos para entregar información a los dispositivos finales de la red, pero el principio de una red superpuesta configurable por software que opera sobre una red subyacente relativamente simple y estática seguirá siendo el mismo.
Podemos decir que hoy SDN basado en una red superpuesta ha ganado el campo de la creación de una nube privada. Sin embargo, esto no significa que Openflow no tenga cabida en el mundo moderno: se usa en OpenStacke y en el mismo VMWare NSX, hasta donde yo sé, Google lo usa para configurar la red subterránea.
A continuación, proporcioné enlaces a materiales más detallados si desea estudiar el tema en mayor profundidad.
¿Y qué pasa con nuestra base?
Pero en general nada. No cambió del todo. Todo lo que necesita hacer en el caso de una superposición del host es actualizar las rutas y los ARP a medida que vRouter/VNGW aparecen y desaparecen y transportan paquetes entre ellos.
Formulemos una lista de requisitos para la red Underlay.
- Ser capaz de utilizar algún tipo de protocolo de enrutamiento, en nuestra situación: BGP.
- Tener un ancho de banda amplio, preferiblemente sin sobresuscripción, para que no se pierdan paquetes por sobrecargas.
- El apoyo a ECMP es una parte integral del tejido.
- Ser capaz de proporcionar QoS, incluidas cosas complicadas como ECN.
- Apoyar a NETCONF es la base para el futuro.
Dediqué muy poco tiempo aquí al trabajo de la propia red Underlay. Esto se debe a que más adelante en la serie me centraré en ello y solo tocaremos la superposición de pasada.
Obviamente, nos estoy limitando severamente a todos al usar como ejemplo una red DC construida en una fábrica de Cloz con enrutamiento IP puro y una superposición del host.
Sin embargo, estoy seguro de que cualquier red que tenga un diseño puede describirse en términos formales y automatizarse. Es solo que mi objetivo aquí es comprender los enfoques de la automatización y no confundir a todos resolviendo el problema de forma general.
Como parte de ADSM, Roman Gorge y yo planeamos publicar un número separado sobre la virtualización de la potencia informática y su interacción con la virtualización de redes. Mantente en contacto.
Enlaces de interés
- .
- . 6 horas sobre Yandex.Cloud, que también cubre la red virtual en TF.
- .
- . Habla de toda la red de CC, incluidos Underlay, Overlay, enfoques de administración y alojamiento múltiple.
Gracias
- - ex presentador del podcast linkmeup y ahora experto en el campo de las plataformas en la nube. Para comentarios y ediciones. Bueno, estamos esperando su artículo más profundo sobre virtualización en un futuro próximo.
- - mi colega y experto en el campo del desarrollo de redes virtuales. Para comentarios y ediciones.
- - mi colega y experto en el campo del tejido de tungsteno. Para comentarios y ediciones.
- - enlace de ilustrador. Para KDPV.
- Alejandro Limónov. Para el meme "autómata".
Fuente: habr.com