Descripción general de la arquitectura JDM
Descripción de Junos OS desagregado
Tradicionalmente, muchos proveedores de equipos de red han vinculado su software a hardware especialmente diseñado y han vendido a los clientes la combinación de software-hardware empaquetada y empaquetada. Sin embargo, con la arquitectura desagregada de Junos OS, los dispositivos de Juniper Network ahora están alineados con redes orientadas a la nube, abiertas y basadas en escenarios de implementación más flexibles.
El principio básico de la arquitectura desagregada de Junos OS es la descomposición (desagregación) del software y el hardware propietario de Junos OS en componentes virtualizados que potencialmente pueden ejecutarse no solo en hardware de Juniper Networks, sino también en cajas blancas o servidores sin sistema operativo. En esta nueva arquitectura, Juniper Device Manager (JDM) es un contenedor raíz virtualizado que administra componentes de software.
JDM es el único contenedor raíz en la arquitectura desagregada de Junos OS (hay otros modelos de la industria que permiten más de un contenedor raíz, pero la arquitectura desagregada de Junos OS no es uno de ellos). Junos OS desagregado es un modelo de raíz única . Una de las principales funciones de JDM es evitar que las modificaciones y actividades en la plataforma afecten al sistema operativo host subyacente (generalmente Linux). Como entidad raíz, el JDM es adecuado para esa tarea. La otra función principal de JDM es hacer que el hardware del dispositivo se parezca lo más posible a un sistema físico tradicional basado en Junos OS. Esto también requiere algún tipo de capacidades de raíz.
La figura 1 ilustra la importante posición que ocupa JDM en la arquitectura general.
de dispositivos de Juniper
Una VNF es una oferta consolidada que contiene todos los componentes necesarios para admitir un entorno de red totalmente virtualizado. Un VNF tiene como objetivo la optimización de la red.
JDM permite:
Gestión de funciones de red virtualizadas (VNF) de invitados durante su ciclo de vida.
Instalación de módulos de terceros.
Formación de cadenas de servicio VNF.
Gestión de imágenes VNF invitadas (sus archivos binarios).
Control del inventario del sistema y uso de recursos.
Tenga en cuenta que algunas implementaciones de la arquitectura básica incluyen un motor de reenvío de paquetes, así como los puertos de hardware habituales de la plataforma Linux. Esto permite una mejor integración del plano de datos de Juniper Networks con el hardware bare metal de una plataforma genérica.
La arquitectura desagregada de Junos OS permite a JDM manejar funciones de red virtualizadas, como un firewall o funciones de traducción de direcciones de red (NAT). Los otros VNF y contenedores integrados con JDM pueden ser productos de Juniper Networks o productos de terceros como aplicaciones nativas de Linux. La arquitectura básica del Junos OS desagregado se muestra esquemáticamente en la figura 2.
básica desagregada de Junos OS
Hay varias maneras de implementar la arquitectura básica desagregada de Junos OS en varias plataformas. Los detalles pueden variar mucho. En este tema se describe la arquitectura general.
La virtualización del proceso de software simple que se ejecuta en hardware fijo plantea varios desafíos en el área de la comunicación entre procesos. ¿Cómo funciona, por ejemplo, una VNF con una función NAT con un firewall que se ejecuta como contenedor en el mismo dispositivo? Después de todo, es posible que solo haya uno o dos puertos Ethernet externos en todo el dispositivo, y los procesos siguen siendo internos del dispositivo. Un beneficio es el hecho de que las interfaces entre estos procesos virtualizados a menudo se virtualizan ellas mismas, tal vez como puertos SXE; lo que significa que puede configurar un tipo de puente de capa MAC entre procesos directamente, o entre un proceso y el sistema operativo host y, a continuación, entre el sistema operativo host y otro proceso. Esto admite el encadenamiento de servicios a medida que el tráfico entra y sale del dispositivo.
JDM proporciona a los usuarios una CLI de Junos OS familiar y maneja todas las interacciones con el kernel de Linux subyacente para mantener la "apariencia" de un dispositivo de Juniper Networks.
Algunas de las ventajas del Junos OS desagregado son:
Todo el sistema se puede gestionar como si se gestionara una plataforma de servidor.
Los clientes pueden instalar aplicaciones, herramientas y servicios de terceros, como Chef, Wiireshark o Quagga, en una máquina virtual (VM) o contenedor.
Estas aplicaciones y herramientas se pueden actualizar mediante repositorios típicos de Linux y son independientes de las versiones de Junos OS.
La modularidad aumenta la confiabilidad porque las fallas están contenidas dentro del módulo.
Los planos de control y datos se pueden programar directamente a través de APIs.
Descripción de los componentes físicos y virtuales
En el entorno desagregado de virtualización de funciones de red (NFV) de Junos OS, los componentes del dispositivo pueden ser físicos o virtuales. La misma distinción físico-virtual se puede aplicar a las interfaces (puertos), las rutas que los paquetes o tramas toman a través del dispositivo, y otros aspectos como los núcleos de la CPU o el espacio en disco.
La especificación desagregada de Junos OS incluye un modelo arquitectónico. El modelo arquitectónico de una casa puede tener instrucciones para incluir una cocina, un techo y un comedor, y puede representar varios tipos de viviendas; desde una cabaña junto al mar hasta una mansión palaciega. Todas estas casas se ven muy diferentes, pero aún así siguen un modelo arquitectónico básico y comparten muchas características.
Del mismo modo, en el caso de los modelos arquitectónicos desagregados de Junos OS, los modelos cubren tipos muy diferentes de plataformas, desde simples equipos en las instalaciones del cliente (CPE) hasta equipos de conmutación complejos instalados en un gran centro de datos, pero tienen algunas características básicas que comparten las plataformas.
¿Qué características comparten estas plataformas? Todas las plataformas Junos OS desagregadas se basan en tres capas. Estas capas y parte del contenido posible se muestran en la Figura 3.
desagregado
La capa más baja es la capa de hardware. Además de la memoria (RAM) y el espacio en disco (SSD), el hardware de la plataforma tiene una CPU multinúcleo con un puerto NIC externo utilizado para la administración. En algunos casos, habrá un único puerto NIC utilizado para el plano de control y de datos, pero ese puerto también se puede utilizar para comunicarse con un motor de reenvío de paquetes para flujos de tráfico de usuario.
La capa de software de la plataforma se encuentra en la parte superior de la capa de hardware. Todas las funciones dependientes de la plataforma tienen lugar aquí. Estas funciones pueden incluir una función de conmutación de software para varios componentes virtuales para puentear el tráfico entre ellos. Una máquina virtual basada en Linux o kernel (KVM) ejecuta la plataforma y, en algunos modelos, un agente telefónico se pone en contacto con un proveedor o proveedor de servicios para realizar tareas de configuración automática. El agente telefónico a domicilio es particularmente preferido para plataformas CPE más pequeñas.
Por encima de la capa de software de la plataforma se encuentra la capa de software del cliente, que realiza varias funciones independientes de la plataforma. Algunos de los componentes pueden ser máquinas virtuales de Juniper Networks, como un dispositivo SRX virtual (vSRX) o el plano de control de Junos (JCP). El JCP trabaja con el JDM para hacer que el dispositivo se parezca a una plataforma dedicada de Juniper Networks, pero con mucha más flexibilidad. Gran parte de esta flexibilidad proviene de la capacidad de admitir una o más VNF que implementan una función de red virtualizada (VNF). Estas VNF constan de muchos tipos de tareas, como traducción de direcciones de red (NAT), búsquedas de servidor especializadas en el Sistema de nombres de dominio (DNS), etc.
Generalmente, hay un número fijo de núcleos de CPU y una cantidad finita de espacio en disco. Pero en un entorno virtual, la asignación y el uso de recursos es más complejo. Los recursos virtuales como interfaces, espacio en disco, memoria o núcleos se dividen entre las VNF que se ejecutan en ese momento, según lo determinado por la imagen VNF.
Las VNF, ya sean máquinas virtuales (VM) o contenedores, que comparten el dispositivo físico a menudo deben comunicarse entre sí. Los paquetes o tramas entran en un dispositivo a través de una interfaz física (un puerto) y se distribuyen a una VNF inicial. Después de algún procesamiento del flujo de tráfico, la VNF pasa el tráfico a otra VNF si está configurada para ello y, a continuación, a otra, antes de que el tráfico salga del dispositivo físico. Estas VNF forman una cadena de servicio de plano de datos que se atraviesa dentro del dispositivo.
¿Cómo las VNF, que son máquinas virtuales aisladas o contenedores, pasan el tráfico de una a otra? La cadena de servicio está configurada para pasar tráfico de una interfaz física a una o más interfaces virtuales internas. Por lo tanto, hay NIC virtuales asociadas con cada VM o contenedor, todas conectadas por una función de conmutador virtual o puente dentro del dispositivo. Esta relación genérica, que permite la comunicación entre interfaces físicas y virtuales, se muestra en la figura 4.
de componentes físicos y virtuales
En este modelo general, que puede tener variaciones en diferentes plataformas, los datos ingresan a través de un puerto en la NIC física y se puentean a través de la función de conmutador virtual a la máquina virtual1 a través de la NIC virtual 1, según la dirección MAC de destino. El tráfico también se puede conectar a través de otra interfaz virtual configurada a Virtual Machine2 o más VNF hasta que se devuelve a un puerto físico y sale del dispositivo.
Para fines de configuración, estas interfaces pueden tener designaciones familiares como ge-0/0/0 o fxp0, o designaciones nuevas como sxe0 o hsxe0. Algunos pueden ser reales, pero los puertos internos (como sxe0) y otros pueden ser construcciones completamente virtuales (como hsxe0) necesarios para que el dispositivo funcione.
Máquinas virtuales Junos OS desagregadas
La computación en la nube permite que las aplicaciones se ejecuten en un entorno virtualizado, tanto para las funciones del servidor del usuario final como para las funciones de red necesarias para conectar puntos finales dispersos en un gran centro de datos, o incluso entre varios centros de datos. Las aplicaciones y las funciones de red se pueden implementar mediante funciones de red virtualizadas (VNF). ¿Cuáles son las diferencias entre estos dos tipos de paquetes y por qué alguien usaría un tipo u otro?
Tanto los VNF como los contenedores permiten la multiplexación de hardware con decenas o cientos de VNF que comparten un servidor físico. Esto permite no solo el despliegue rápido de nuevos servicios, sino también la extensión y migración de cargas de trabajo en momentos de uso intensivo (cuando se puede usar la extensión) o mantenimiento físico (cuando se puede usar la migración).
En un entorno de computación en la nube, es común emplear VNF para hacer el trabajo pesado en las granjas de servidores masivas que caracterizan a big data en las redes modernas. La virtualización de servidores permite que las aplicaciones escritas para diferentes entornos de desarrollo, plataformas de hardware o sistemas operativos se ejecuten en hardware genérico que ejecuta un paquete de software adecuado.
Las VNF dependen de un hipervisor para administrar el entorno físico y asignar recursos entre las VNF que se ejecutan en un momento determinado. Los hipervisores populares incluyen Xen, KVM y VMWare ESXi, pero hay muchos otros. Las VNF se ejecutan en el espacio de usuario en la parte superior del hipervisor e incluyen una implementación completa del sistema operativo de la aplicación VM. Por ejemplo, una aplicación escrita en el lenguaje C ++ y cumplida y ejecutada en el sistema operativo Microsoft Windows se puede ejecutar en un sistema operativo Linux utilizando el hipervisor. En este caso, Windows es un sistema operativo invitado.
El hipervisor proporciona al sistema operativo invitado una vista emulada del hardware de las VNF. Entre otros recursos, como el espacio en disco de la memoria, el hipervisor proporciona una vista virtualizada de la tarjeta de interfaz de red (NIC) cuando los puntos de conexión para diferentes máquinas virtuales residen en diferentes servidores o hosts (una situación común). El hipervisor administra las NIC físicas y expone solo interfaces virtualizadas a las VNF.
El hipervisor también ejecuta un entorno de conmutación virtual, que permite que las VNF en la capa de trama VLAN intercambien paquetes dentro de la misma caja o a través de una red (virtual).
La mayor ventaja de los VNF es que la mayoría de las aplicaciones se pueden portar fácilmente al entorno del hipervisor y ejecutarse bien sin modificaciones.
El mayor inconveniente es que, a menudo, la sobrecarga de recursos del sistema operativo invitado debe incluir una versión completa del sistema operativo, incluso si la función de todo el VNF es proporcionar un servicio simple, como un sistema de nombres de dominio (DNS).
Los contenedores, a diferencia de los VNF, están diseñados específicamente para ejecutarse como tareas independientes en un entorno virtual. Los contenedores no empaquetan un sistema operativo completo en su interior como lo hacen los VNF. Los contenedores se pueden codificar y agrupar de muchas maneras, pero también hay formas de construir contenedores estándar que son fáciles de mantener y extender. Los contenedores estándar son mucho más abiertos que los contenedores creados al azar.
Los contenedores estándar de Linux definen una unidad de entrega de software llamada contenedor estándar. En lugar de encapsular todo el sistema operativo invitado, el contenedor estándar encapsula solo la aplicación y las dependencias necesarias para realizar la tarea para la que está programada la aplicación. Este elemento de tiempo de ejecución único se puede modificar, pero luego se debe reconstruir el contenedor para incluir las dependencias adicionales que pueda necesitar la función extendida. La arquitectura general de los contenedores se muestra en la Figura 5.
general
Los contenedores se ejecutan en el kernel del sistema operativo host y no en el hipervisor. La arquitectura de contenedor utiliza un motor de contenedor para administrar la plataforma subyacente. Si aún desea ejecutar VNF, el contenedor también puede empaquetar un hipervisor completo y un entorno de SO invitado.
Los contenedores estándar incluyen:
Un archivo de configuración.
Un conjunto de operaciones estándar.
Un entorno de ejecución.
El nombre contenedor se toma prestado de los contenedores de envío que se utilizan para transportar mercancías en todo el mundo. Los contenedores de envío son unidades de entrega estándar que pueden ser cargadas, etiquetadas, apiladas, levantadas y descargadas por equipos construidos específicamente para manejar los contenedores. No importa lo que haya dentro, el contenedor se puede manejar de manera estándar, y cada contenedor tiene su propio espacio de usuario que no puede ser utilizado por otros contenedores. Aunque Docker es un popular sistema de gestión de contenedores para ejecutar contenedores en un servidor físico, hay alternativas como Drawbridge o Rocket a considerar.
A cada contenedor se le asigna una interfaz virtual. Los sistemas de gestión de contenedores, como Docker, incluyen un puente Ethernet virtual que conecta varias interfaces virtuales y la NIC física. Las variables de configuración y entorno del contenedor determinan qué contenedores pueden comunicarse entre sí, cuáles pueden usar la red externa, etc. Las redes externas generalmente se logran con NAT, aunque existen otros métodos porque los contenedores a menudo usan el mismo espacio de direcciones de red.
La mayor ventaja de los contenedores es que pueden cargarse en un dispositivo y ejecutarse mucho más rápido que los VNF. Los contenedores también usan los recursos con mucha más moderación: puede ejecutar muchos más contenedores que VNF en el mismo hardware. Esto se debe a que los contenedores no requieren un sistema operativo invitado completo ni tiempo de arranque. Los contenedores se pueden cargar y ejecutar en milisegundos, no en decenas de segundos. Sin embargo, el mayor inconveniente con los contenedores es que tienen que ser escritos específicamente para ajustarse a algún estándar o implementación común, mientras que los VNF se pueden ejecutar en su estado nativo.
Uso de Virtio y SR-IOV
Puede habilitar la comunicación entre un dispositivo virtualizado basado en Linux y un módulo de virtualización de funciones de red (NFV) mediante el uso de virtio o mediante el uso de hardware adecuado y virtualización de E/S de raíz única (SR-IOV). Cada método tiene características distintas.
Descripción del uso de Virtio
Cuando se virtualiza un dispositivo físico, coexisten tanto las interfaces NIC físicas como los conmutadores físicos externos, así como las interfaces NIC virtuales y los conmutadores virtuales internos. Por lo tanto, cuando los VNF aislados en el dispositivo, cada uno con su propia memoria, espacio en disco y ciclos de CPU, intentan comunicarse entre sí, los múltiples puertos, direcciones MAC y direcciones IP en uso plantean un desafío. Con la biblioteca virtio, el flujo de tráfico entre las funciones virtuales aisladas se vuelve más simple y fácil.
Virtio es parte de la biblioteca estándar libvirt de Linux de funciones de virtualización útiles y normalmente se incluye en la mayoría de las versiones de Linux. Virtio es un enfoque solo de software para la comunicación entre VNF. Virtio proporciona una forma de conectar procesos virtuales individuales. La naturaleza empaquetada de virtio hace posible que cualquier dispositivo ejecutado en Linux use virtio.
Virtio permite que los VNF y los contenedores utilicen puentes internos simples para enviar y recibir tráfico. El tráfico todavía puede llegar y salir a través de un puente externo. Un puente externo utiliza una interfaz NIC interna virtualizada en un extremo del puente y una interfaz NIC externa física en el otro extremo del puente para enviar y recibir paquetes y tramas. Un puente interno, del cual hay varios tipos, vincula dos interfaces NIC internas virtualizadas mediante un puente entre ellas a través de una función de conmutador interno virtualizado en el sistema operativo host. La arquitectura general de virtio se muestra en la Figura 6.
La figura 6 muestra la estructura interna de un dispositivo de servidor con una sola tarjeta NIC física que ejecuta un sistema operativo host (no se muestra la cubierta exterior del dispositivo). El sistema operativo host contiene el conmutador virtual o el puente implementado con virtio. Por encima del sistema operativo, varias máquinas virtuales emplean NIC virtuales que se comunican a través de virtio. Hay varias máquinas virtuales en ejecución, numeradas del 1 al N en la figura. La notación estándar "punto punto punto" indica posibles máquinas virtuales y NIC que no se muestran en la figura. Las líneas de puntos indican posibles rutas de datos utilizando virtio. Tenga en cuenta que el tráfico que entra o sale del dispositivo lo hace a través de la NIC física y el puerto.
La figura 6 también muestra el tráfico que entra y sale del dispositivo a través del puente interno. La máquina virtual 1 vincula su interfaz NIC interna virtualizada a la interfaz NIC externa física. La máquina virtual 2 y la máquina virtual N vinculan NIC virtuales internas a través del puente interno en el sistema operativo host. Tenga en cuenta que estas interfaces pueden tener etiquetas VLAN asociadas o nombres de interfaz interna. Las tramas enviadas a través de este puente interno entre VNF nunca salen del dispositivo. Tenga en cuenta la posición del puente (y la función de conmutador virtualizado) en el sistema operativo host. Tenga en cuenta el uso de puentes simples en el dispositivo. Estos puentes se pueden configurar con comandos normales de Linux o mediante el uso de instrucciones de configuración de CLI. Los scripts se pueden utilizar para automatizar el proceso.
Virtio es un estándar de virtualización para controladores de disco y dispositivos de red. Solo el controlador de dispositivo invitado (el controlador de dispositivos para las funciones virtualizadas) necesita saber que se está ejecutando en un entorno virtual. Estos controladores cooperan con el hipervisor y las funciones virtuales obtienen beneficios de rendimiento a cambio de la complicación adicional. Virtio es arquitectónicamente similar, pero no es lo mismo que, los controladores de dispositivos paravirtualizados Xen (controladores agregados a un invitado para hacerlos más rápidos cuando se ejecutan en Xen). Las herramientas de invitación de VMWare también son similares a virtio.
Tenga en cuenta que gran parte del tráfico se concentra en la CPU del sistema operativo host, más explícitamente, en los puentes internos virtualizados. Por lo tanto, la CPU del host debe ser capaz de funcionar adecuadamente a medida que el dispositivo escala.
Descripción del uso de SR-IOV
Cuando se virtualiza un dispositivo físico, coexisten tanto las interfaces de tarjeta de interfaz de red (NIC) física como los conmutadores físicos externos, así como las interfaces NIC virtuales y los conmutadores virtuales internos. Por lo tanto, cuando las máquinas virtuales (VM) aisladas o los contenedores del dispositivo, cada uno con su propia memoria, espacio en disco y ciclos de CPU, intentan comunicarse entre sí, los múltiples puertos, direcciones MAC y direcciones IP en uso plantean un desafío.
SR-IOV extiende el concepto de funciones virtualizadas hasta la NIC física. La tarjeta física única se divide en hasta 16 particiones por puerto NIC físico que corresponden a las funciones virtuales que se ejecutan en las capas superiores. La comunicación entre estas funciones virtuales se maneja de la misma manera que las comunicaciones entre dispositivos con NIC individuales se manejan normalmente: con un puente. SR-IOV incluye un conjunto de métodos estándar para crear, eliminar, enumerar y consultar el conmutador NIC SR-IOV, así como los parámetros estándar que se pueden establecer.
La parte de raíz única de SR-IOV se refiere al hecho de que realmente solo hay una pieza primaria de la NIC que controla todas las operaciones. Una NIC habilitada para SR-IOV es solo un puerto Ethernet estándar que proporciona la misma función física bit a bit de cualquier tarjeta de red.
Sin embargo, el SR-IOV también proporciona varias funciones virtuales, que se logran mediante colas simples para manejar tareas de entrada y salida. Cada VNF que se ejecuta en el dispositivo se asigna a una de estas particiones NIC para que las propias VNF tengan acceso directo a los recursos de hardware de NIC. La NIC también tiene una función de clasificador de capa 2 simple, que clasifica las tramas en colas de tráfico. Los paquetes se mueven directamente hacia y desde la función virtual de red a la memoria de la máquina virtual mediante el acceso directo a memoria (DMA), sin pasar por completo por el hipervisor. El rol de la NIC en la operación SR-IOV se muestra en la Figura 7.
El hipervisor todavía está involucrado en la asignación de las VNF a las funciones de red virtual y en la administración de la tarjeta física, pero no en la transferencia de los datos dentro de los paquetes. Tenga en cuenta que la comunicación de VNF a VNF la realizan Virtual NIC 1, Virtual NIC 2 y Virtual NIC N. También hay una parte de la NIC (no mostrada) que realiza un seguimiento de todas las funciones virtuales y el clasificador para transportar el tráfico entre las VNF y los puertos de dispositivos externos.
Tenga en cuenta que la capacidad de admitir SR-IOV depende del hardware de la plataforma, específicamente del hardware de la NIC, y del software de las VNF o contenedores para emplear DMA para la transferencia de datos. Las NIC particionables y los puentes internos necesarios tienden a ser más caros, por lo que su uso puede aumentar el costo en dispositivos más pequeños en una cantidad apreciable. Reescribir VNF y contenedores tampoco es una tarea trivial.
Comparación de Virtio y SR-IOV
Virtio es parte de la biblioteca estándar libvirt de funciones de virtualización útiles y normalmente se incluye en la mayoría de las versiones de Linux. Virtio adopta un enfoque de solo software. SR-IOV requiere un software escrito de cierta manera y hardware especializado, lo que significa un aumento en el costo, incluso con un dispositivo simple.
Generalmente, usar virtio es rápido y fácil. Libvirt es parte de cada distribución de Linux y los comandos para establecer los puentes son bien entendidos. Sin embargo, virtio coloca toda la carga del rendimiento en el sistema operativo host, que normalmente une todo el tráfico entre VNF, dentro y fuera del dispositivo.
En general, SR-IOV puede proporcionar menor latencia y menor utilización de la CPU, en resumen, casi nativo, rendimiento de dispositivos no virtuales. Pero la migración de VNF de un dispositivo a otro es compleja porque VNF depende de los recursos de la NIC en una máquina. Además, el estado de reenvío para la VNF reside en el conmutador de capa 2 integrado en la NIC SR-IOV. Debido a esto, el reenvío ya no es tan flexible porque las reglas para el reenvío están codificadas en el hardware y no se pueden cambiar con frecuencia.
Aunque la compatibilidad con virtio es casi universal, la compatibilidad con SR-IOV varía según el hardware y la plataforma de la NIC. La plataforma de servicios de red NFX250 de Juniper Networks admite capacidades de SR-IOV y permite 16 particiones en cada puerto NIC físico.
Tenga en cuenta que un VNF dado puede usar virtio o SR-IOV, o incluso ambos métodos simultáneamente, si se admite.
Virtio es el método recomendado para establecer la conexión entre un dispositivo virtualizado y un módulo NFV.