Esta publicación de blog es parte de nuestra serie de redes de centros de datos:
Con el desarrollo de soluciones de red definidas por software de código abierto, la virtualización está desempeñando un papel cada vez más importante en los centros de datos modernos. Conceptos como la conmutación virtual y el enrutamiento se han convertido en parte del escenario de la red del centro de datos, y OVS es un ejemplo pionero. Sin embargo, al principio el conmutador virtual omitió funciones y estándares de red muy importantes. Estas funciones y estándares ya pertenecen a dispositivos de red basados en hardware y se han verificado e implementado ampliamente. OVN comenzó a representar estas funciones de red en un entorno de conmutación virtual y abordó su escalabilidad en clústeres de múltiples hosts. Primero echemos un vistazo más de cerca para comprender qué es OVN.
¿Qué es OVN?
OVN, o Open Virtual Network, es un proyecto de código abierto desarrollado originalmente por el equipo Open vSwitch (OVS) de Nicira.
Complementa las funciones existentes de OVS y proporciona abstracción de red virtual, como superposiciones virtuales L2 y L3, grupos de seguridad y servicios DHCP. Al igual que OVS, OVN está diseñado para admitir implementaciones de nivel de producción altamente escalables. Utiliza la misma API para proporcionar un método de función de red virtual abierta para cualquier tipo de carga de trabajo en la plataforma de virtualización (máquinas virtuales y contenedores).
OVN conecta grupos de VM o grupos de contenedores a redes privadas L2 y L3, de manera programática de manera rápida y sin la necesidad de configurar VLAN u otros recursos de red físicos, lo que permite a los administradores controlar los recursos de la red.
El proyecto OVN se anunció por primera vez en enero de 2015 y la primera versión experimental se lanzó en febrero de 2016. La primera versión compatible se lanzó en septiembre de 2016.
Funciones de motivación y OVN
Open vSwitch (OVS), el conmutador virtual más popular de OpenStack, está diseñado para proporcionar componentes de red de bajo nivel para hipervisores de servidor. Para que OVS sea más eficaz en varios entornos de red, OVN tiene como objetivo mejorar las funciones de conmutación de bajo nivel a través de un plano de control ligero que proporciona soporte nativo para abstracciones de redes virtuales comunes.
OVN proporciona un diseño simple a nivel de producción con alta escalabilidad, que puede extender las funciones de OVS a miles de hipervisores. Muestra un mayor rendimiento y estabilidad que el complemento OVS existente sin ningún agente adicional para la implementación y la depuración. OVN es compatible con puertas de enlace basadas en DPDK y aceleración de hardware, y ha sido compatible con conmutadores de Brocade, Cumulus, Dell, HP, Lenovo, Arista y Juniper.
OVN proporciona muchas funciones de red virtual, desde la capa 2 hasta servicios de red superiores como DHCP y DNS. La siguiente es una vista de alto nivel de sus principales funciones compatibles:
- Cuando se usa con OVN (versión 2.11 o posterior), el controlador networking-ovn admite redes de inquilinos VLAN.
- Cuando el controlador Trunk utiliza el puerto principal de OVN y la función de marcado de puertos, se admite el complemento de servicio Trunk. El complemento de servicio ‘troncal’ debe estar habilitado en el archivo de configuración de neutrones.
- Implementación nativa de conmutación de capa 2, que reemplaza al tradicional proxy Open vSwitch (OVS).
- Implementación nativa de enrutamiento de capa 3 que admite enrutamiento distribuido. Esto reemplaza al agente tradicional Neutron L3. También admite puertas de enlace L3 desde redes lógicas hasta redes físicas.
- Admite el grupo de seguridad de la lista de control de acceso (ACL) L2 / L3 / L4.
- La implementación distribuida nativa de DHCP, reemplaza al agente DHCP de Neutron tradicional. Sin embargo, la implementación nativa aún no es compatible con las funciones de metadatos o DNS.
- Admite múltiples protocolos de tunelización y cobertura, como Geneve y STT.
- OVS se puede utilizar con OVN y networking-ovn, utilizando la ruta de datos del kernel de Linux o la ruta de datos DPDK.
- Desde la versión OVN 2.8, se admite la implementación de DNS integrado.
- Para integrarse con OpenStack, OVN admite una gran cantidad de extensiones API de Neutron.
- Admite puertas de enlace de Capa 2 basadas en software y en la parte superior del bastidor que implementan la arquitectura hardware_vtep.
- OVN puede proporcionar una red para máquinas virtuales y contenedores que se ejecutan en ellas, sin la necesidad de una capa de red superpuesta adicional.
- Integración con OpenStack y otros sistemas de gestión de la nube (CMS).
- Función de descarga de hardware: OVN utiliza OVS para el procesamiento de datos, en el que OVS puede realizar la descarga de hardware (por ejemplo, tarjeta Mellanox ConnectX-5 (+)), o DPDK Desinstale según la tarjeta de red Intel.
Arquitectura y cimientos de OVN
Los componentes principales de OVN se pueden ver en la categoría de base de datos o demonio:
Base de datos OVN:
- ovn-northbound ovsdb Representa el punto de integración de OpenStack / CMS y mantiene la configuración intermedia y de alto nivel del estado requerido definido en el CMS. Realiza un seguimiento de la configuración de QoS, NAT y ACL y sus objetos principales (puertos lógicos, conmutadores lógicos, enrutadores lógicos).
- ovn-en dirección sur ovsdb Tiene una representación de red más específica del hipervisor y mantiene el estado de tiempo de ejecución (es decir, la ubicación de los puertos lógicos, la ubicación de los puntos finales físicos, las canalizaciones lógicas generadas según la configuración y el estado de tiempo de ejecución).
Demonio OVN:
- Horno norte La base de datos avanzada en dirección norte se convierte en la base de datos en tiempo de ejecución en dirección sur y el flujo lógico se genera de acuerdo con la configuración avanzada.
- Controlador de horno Es un controlador SDN local que se ejecuta en cada host y administra cada instancia de OVS. Registra el chasis y VIF en la base de datos en dirección sur y convierte el flujo lógico en un flujo físico (es decir, UUID de VIF al puerto OpenFlow). Envía la configuración física a la instancia de OVS local a través de OVSDB y OpenFlow, y utiliza SDN para la ubicación informática remota (VTEP). Todos los controladores están coordinados a través de la base de datos en dirección sur.
Puede encontrar información más detallada sobre los componentes de OVN en este enlace.
OVN utiliza la base de datos para su plano de control y aprovecha su alta escalabilidad.Es conveniente de usar servidor ovsdb Como su base de datos, no introduce nuevas dependencias, porque ovsdb-server ya está en cada host que usa OVS.
Cada instancia de ovn-controller siempre usa una instantánea consistente de la base de datos. Mantiene una conexión impulsada por actualizaciones con la base de datos. Si se interrumpe la conexión, ovn-controller se pondrá al día con la última instantánea coherente del contenido de la base de datos relevante y la procesará.
Flujo lógico
El siguiente es el principio de funcionamiento de la población flotante de Norte-Sur DB:
OVN introduce una representación intermedia de la configuración del sistema, denominada flujo lógico. La configuración de la red lógica se almacena en la base de datos en dirección norte (por ejemplo, definida y escrita por CMS-Neutron ML2). Los flujos lógicos y los flujos físicos de OpenFlow tienen una expresividad similar, pero solo operan en entidades lógicas. El flujo lógico de una red dada es el mismo en todo el entorno.
ovn-northd convierte estos elementos de topología de red lógica en la base de datos en dirección sur en una tabla de flujo lógico. Para todas las demás tablas de la base de datos en dirección sur, se envían a todos los nodos de cómputo y controladores OVN a través de la solicitud de monitor OVSDB. Por lo tanto, todos los cambios que ocurren en la base de datos en dirección sur se envían al controlador OVN correspondiente (esto se denomina «monitoreo de condición»), y el programa de administración del chasis genera el flujo físico en consecuencia. En el hipervisor, ovn-controller recibe los datos actualizados de la base de datos en dirección sur, actualiza el flujo físico de OVS y actualiza el ID de la versión de configuración en ejecución.
En el nivel del hipervisor, cuando se agrega una nueva VM a un nodo informático, el controlador OVN en ese nodo informático específico envía (empuja) una nueva condición a la base de datos en dirección sur a través del protocolo OVSDB. Esto elimina los flujos de actualización irrelevantes.
ovn-northd monitorea continuamente nb_cfg globalmente y en cada chasis, donde nb_cfg proporciona la configuración solicitada actualmente, sb_cfg proporciona la configuración de flujo y hv_cfg proporciona la versión en ejecución del chasis.
Flujo de estado
La población de flujo estatal es de sur a norte, y los métodos de trabajo son los siguientes:
La información de estado fluye de sur a norte. ovn-northd llena la columna UP en la base de datos en dirección norte para cada puerto virtual (v-port), y OVN proporciona comentarios al CMS sobre la implementación de la configuración solicitada. Ovn-northd supervisa nb_cfg a nivel mundial y por chasis. CMS verifica las versiones nb_cfg, sb_cfg y hv_cfg para medir el progreso de la implementación de la solicitud de configuración.
Migrar de OVS a Charmed OVN
Una de las principales mejoras proporcionadas por Canonical desde su lanzamiento. Encantador OpenStack 20.10 Una versión es el proceso de migración a OVN para usar OVS para la implementación. Esto permite a los usuarios de Charmed OpenStack migrar fácilmente de OVS a OVN y disfrutar de los beneficios de OVN, como el soporte nativo para la abstracción de redes virtuales y una mejor separación del plano de control. Como resultado, obtuvieron una plataforma de red definida por software completamente funcional en su entorno Charmed OpenStack.
Todo el proceso de migración está automatizado y encapsulado en operadores de código abierto (Charms), que proporcionan una abstracción de alto nivel de las operaciones de infraestructura. El equipo de DevOps solo necesita ajustar el tamaño de su Unidad de transmisión máxima (MTU) para habilitar el paquete Geneve utilizado por OVN, implementar componentes OVN y servicios Vault e iniciar la migración. Una vez completada la migración, los usuarios pueden eliminar de forma segura los componentes redundantes del modelo Juju, como los agentes Neutron OVS y Neutron Gateway.
Otro trabajo interesante realizado por Canonical es habilitar OVN en SmartNIC y DPU.
Puede encontrar información más detallada sobre Charmed OpenStack y Charmed OVN aquí Asociar.
¿Que sigue?
El próximo blog se centrará en hacer de las tarjetas de red inteligentes uno de los temas más interesantes y futuros que afectan el panorama de los centros de datos modernos.
