Implementación del vRouter DPDK
Descripción general de DPDK
Cloud-Native Contrail® Networking™ admite el kit de desarrollo de plano de datos (DPDK). DPDK es un conjunto de bibliotecas de código abierto y controladores para el procesamiento rápido de paquetes. Cloud-Native Contrail Networking acelera las redes de contenedores con la tecnología vRouter DPDK. DPDK permite el procesamiento rápido de paquetes al permitir que las tarjetas de interfaz de red (NIC) envíen paquetes de acceso directo a la memoria (DMA) directamente al espacio de direcciones de una aplicación. Este método de enrutamiento de paquetes permite que la aplicación sondee paquetes, lo que evita la sobrecarga de interrupciones desde la NIC.
El uso de DPDK permite que contrail vRouter nativo de la nube procese más paquetes por segundo de los que podría cuando se ejecuta como una interfaz DPDK de módulo de kernel para funciones de servicio de contenedor. CN2 utiliza la potencia de procesamiento de DPDK vRouter y aprovecha la potencia de procesamiento para funciones de servicio de contenedor de alta demanda.
Cuando se aprovisiona un nodo de computación de Contrail con DPDK, el archivo YAML correspondiente especifica lo siguiente:
-
Número de núcleos de CPU que se usarán para el reenvío de paquetes.
-
Número de páginas enormes para asignar para DPDK.
-
Controlador UIO para usar en DPDK.
Compatibilidad con vRouter DPDK para cargas de trabajo DPDK y no DPDK
Cuando un contenedor o un pod necesita acceso al vRouter DPDK, se producen los siguientes tipos de carga de trabajo:
-
Carga de trabajo no DPDK (pod): esta carga de trabajo incluye aplicaciones de pod que no sean DPDK que no son conscientes del vRouter DPDK subyacente. Estas aplicaciones no están diseñadas para DPDK y no utilizan capacidades DPDK. En Contrail Networking nativo de la nube, este tipo de carga de trabajo funciona normalmente en un clúster habilitado para vRouter DPDK.
-
Carga de trabajo DPDK en contenedores: estas cargas de trabajo se construyen en la plataforma DPDK. Las interfaces DPDK se muestran mediante el protocolo vhost (Host virtual), que actúa como una ruta de datos para funciones de administración y control. El protocolo vhost permite que los dispositivos host virtualizados se asignen a dispositivos de entrada y salida virtuales (virtio). Los pods actúan como el servidor vHost y el vRouter DPDK subyacente actúa como el cliente de vHost.
-
Combinación de cargas de trabajo no DPDK y DPDK: el canal de administración o control de una aplicación en este pod es un no DPDK (par Veth), y la ruta de datos es una interfaz DPDK. Un par Veth es un par de interfaces Ethernet virtuales conectadas.
Descripción general del pod no DPDK
Un par de Ethernet virtual (Veth) fontaniza la red de un pod que no sea DPDK. Un extremo del par Veth se conecta al espacio de nombres del pod. El otro extremo se conecta al núcleo de la máquina host. La interfaz de red de contenedores (CNI) establece el par Veth y asigna direcciones IP mediante la administración de direcciones IP (IPAM).
Descripción general de DPDK Pod
Un pod DPDK contiene una interfaz vhost y una interfaz virtio. El pod usa la interfaz vhost para fines de administración y la interfaz virtio para aplicaciones de procesamiento de paquetes de alta transferencia de datos. Una aplicación DPDK en el pod usa el protocolo vhost para establecer comunicación con el vRouter DPDK en el host. La aplicación DPDK recibe un argumento para establecer una ruta de archivo para un socket UNIX. El vRouter usa este socket para establecer el canal de control, ejecutar negociaciones y crear vrings en enormes páginas de memoria compartida para rutas de datos de alta velocidad.
Descripción general de los podes que no son DPDK y DPDK
Este pod puede contener aplicaciones que no son DPDK y DPDK. Una aplicación que no es DPDK usa una interfaz que no es DPDK (par Veth), y la aplicación DPDK usa las interfaces DPDK (vhost, virtio). Estas dos cargas de trabajo se producen simultáneamente.
Arquitectura de vRouter DPDK
Contrail DPDK vRouter es un contenedor que se ejecuta dentro del nodo de computación de Contrail. El vRouter se ejecuta como un módulo de kernel linux o como un proceso DPDK de espacio de usuario. El vRouter es responsable de la transmisión de paquetes entre cargas de trabajo virtuales (inquilinos, invitados) en dispositivos físicos. El vRouter también transmite paquetes entre interfaces virtuales e interfaces físicas.
El vRouter CN2 admite los siguientes protocolos de encapsulación:
-
MPLS por UDP (MPLSoUDP)
-
MPLS sobre GRE (MPLSoGRE)
-
VIRTUAL EXTENSIBLE LAN (VXLAN)
En comparación con la implementación tradicional del kernel de Linux, la implementación del vRouter como un proceso DPDK en espacio de usuario aumenta drásticamente el rendimiento y la velocidad de procesamiento de la aplicación vRouter. Este aumento del rendimiento es el resultado de los siguientes factores:
-
Las funciones de red virtual (VNF) que funcionan en el espacio del usuario están diseñadas para DPDK y están diseñadas para aprovechar la potencia de procesamiento de paquetes de DPDK.
-
Los controladores de modo de sondeo (PMD) de DPDK usan la interfaz física (NIC) del host de una máquina virtual en lugar de los controladores basados en interrupciones del kernel de Linux. Los registros del NIC operan en el espacio del usuario, lo que los hace accesibles para los PMD de DPDK.
Como resultado, el sistema operativo Linux no necesita administrar los registros de la NIC. Esto significa que la aplicación DPDK administra todo el sondeo de paquetes, el procesamiento de paquetes y el reenvío de paquetes de una NIC. En lugar de esperar a que ocurra una interrupción de E/S, una aplicación DPDK sondea constantemente los paquetes y procesa estos paquetes inmediatamente después de recibirlos.
Compatibilidad de interfaz DPDK para contenedores
Las ventajas y la arquitectura de DPDK suelen optimizar las redes de VM. Cloud-Native Contrail Networking permite que sus contenedores de Kubernetes aprovechen al máximo estas funciones. En Kubernetes, un pod DPDK contenerizado normalmente contiene dos o más interfaces. Las siguientes interfaces forman la red troncal de un pod DPDK:
- Protocolo de usuario de Vhost (para la administración): El protocolo de usuario vhost es un componente de backend que interactúa con el host. En Cloud-Native Contrail Networking, la interfaz vhost actúa como una ruta de datos para funciones de administración y control entre el pod y el vRouter. Este protocolo consta de los dos planos siguientes:
-
El plano de control intercambia información (asignación de memoria para DMA, negociación de capacidad para establecer y terminar el plano de datos) entre un pod y vRouter a través de un socket Unix.
-
El plano de datos se implementa a través del acceso directo a la memoria y transmite paquetes de datos entre un pod y vRouter.
-
- Interfaz Virtio (para aplicaciones de alta transferencia de datos): En un alto nivel, virtio es un dispositivo virtual que transmite paquetes entre un pod y vRouter. La interfaz virtio es una solución de memoria compartida (shm) que permite a los pods acceder a las bibliotecas y funciones de DPDK.
Estas interfaces permiten que el vRouter DPDK transmita paquetes entre pods. Las interfaces dan a los pods acceso a funciones de red avanzadas proporcionadas por el vRouter (páginas enormes, búferes de anillo sin bloqueo, controladores del modo de sondeo). Para obtener más información acerca de estas funciones, visite Un viaje al dominio vhost-users.
Las aplicaciones usan DPDK para crear interfaces vhost y virtio. Luego, la aplicación o el pod utilizan bibliotecas DPDK directamente para establecer canales de control mediante sockets de dominio Unix. Las interfaces establecen rutas de datos entre un pod y vRouter mediante vrings de memoria compartida.
Requisitos previos del host vRouter DPDK
Para implementar un vRouter DPDK, debe configurar las siguientes páginas enormes y NIC en el nodo de host. Las páginas enormes permiten que el sistema operativo use páginas de memoria más grandes que los 4KB predeterminados:
-
Configuración de páginas enormes: especifique el porcentaje de memoria de host que se va a reservar para las páginas enormes DPDK. La siguiente línea de comandos muestra páginas enormes configuradas en 2MB:
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0 default_hugepagesz=2M hugepagesz=2M hugepages=8192"
En el siguiente ejemplo, se asignan cuatro páginas enormes de 1 GB y 1024 páginas enormes de 2 MB:GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0 default_hugepagesz=1G hugepagesz=1G hugepages=4 hugepagesz=2M hugepages=1024"
Nota:Recomendamos que asigne 1 GB para el enorme tamaño de las páginas.
-
Habilitar (unidad de gestión de memoria de entrada-salida (IOMMU): Las aplicaciones DPDK requieren soporte de la IOMMU. Configure los ajustes del IOMMU y habilite la IOMMU desde el BIOS. Aplique las siguientes marcas como parámetros de arranque para habilitar la IOMMU:
"intel_iommu=on iommu=pt"
-
Asegúrese de que el controlador de kernel se carga en el puerto adelante 0 (puerto 0) de la NIC del host. Asegúrese de que los controladores DPDK PMD se cargan en el puerto adelante 1 (puerto 1) de la NIC del host.
Nota: En un entorno en el que tanto dpdk como controladores de kernel usan puertos diferentes de una NIC común, recomendamos encarecidamente que implemente un nodo DPDK con controladores de kernel vinculados al puerto 0 en la NIC. Recomendamos además que implemente controladores DPDK PMD vinculados al puerto 1 de esa NIC. Otras configuraciones de asignación de puertos pueden causar problemas de rendimiento. Para obtener más información, consulte la sección 24.9.11 de la siguiente documentación de DPDK: Controlador del modo de sondeo I40E. -
Controlador PCI (vfio-pci, uio_pci_generic): especifique qué controlador PCI se utilizará según el tipo de NIC.
Nota:El vfio-pci está integrado.
uio_pci_generic
-
Instale manualmente el módulo de uio_pci_generic si es necesario:
root@node-dpdk1:~# apt install linux-modules-extra-$(uname -r)
-
Compruebe que el módulo uio_pci_generic está instalado:
root@node-dpdk1:~# ls /lib/modules/5.4.0-59-generic/kernel/drivers/uio/ uio.ko uio_dmem_genirq.ko uio_netx.ko uio_pruss.ko uio_aec.ko uio_hv_generic.ko 'uio_pci_generic.ko' uio_sercos3.ko uio_cif.ko uio_mf624.ko uio_pdrv_genirq.ko
-
Implemente un clúster de Kubernetes con el vRouter DPDK en el nodo de computación
Cloud-Native Contrail Networking utiliza un implementador DPDK para lanzar un clúster de Kubernetes con compatibilidad con DPDK. Este implementador realiza funciones de administración del ciclo de vida y aplica los prerrequisitos de vRouter DPDK. Un recurso personalizado (CR) para el vRouter DPDK es un subconjunto del desplegador. El CR contiene lo siguiente:
-
Controladores para la implementación de recursos nativos de la nube de Contrail Networking
-
Lógica de controlador integrada para el vRouter
Aplique el archivo YAML de implementación DPDK e implemente DPDK vRouter CR con agentModeType: dpdk
el siguiente comando:
kubectl apply -f <vrouter_cr.yaml>
Después de aplicar el archivo CR YAML, el implementador crea un demonio para el vRouter. Este deamonset hace girar un pod con un contenedor DPDK.
Si recibe un mensaje de error, asegúrese de que el clúster tiene la definición de recursos personalizados (CRD) para el vRouter mediante el siguiente comando:
kubectl get crds
A continuación, se muestra un ejemplo de los resultados que recibe:
NAME CREATED AT vrouters.dataplane.juniper.net 2021-06-16T16:06:34Z
Si no hay NINGÚN CRD presente en el clúster, compruebe el implementador mediante el siguiente comando:
kubectl get deployment contrail-k8s-deployer -n contrail-deploy -o yaml
Compruebe la imagen que utiliza el contrail-k8s-crdloader
contenedor. Esta imagen debería ser la imagen más reciente que use el implementador. Actualice la imagen y asegúrese de que su nuevo pod use esta imagen.
Después de comprobar que el nuevo pod está ejecutando la imagen más reciente, utilice el siguiente comando para comprobar que el CRD para el vRouter está presente:
kubectl get crds
Después de comprobar que el CRD para el vRouter está presente, utilice el siguiente comando para aplicar el CR de vRouter:
kubectl apply -f <vrouter_cr.yaml>
Configuración de recursos personalizados de vRouter de DPDK
Puede configurar las siguientes opciones de CR del vRouter:
-
service_core_mask
: especifique una máscara de núcleo de servicio. La máscara de núcleo de servicio le permite asignar dinámicamente núcleos de CPU para servicios. -
Puede introducir los siguientes formatos de entrada:
-
Hexadecimal (por ejemplo, 0xf)
-
Lista de CPU separadas por comas (por ejemplo, 1,2,4)
-
Rango de CPU separados por un guión (por ejemplo, 1-4)
Nota: Los PMD requieren la mayor parte de sus núcleos de CPU disponibles para el procesamiento de paquetes. Como resultado, recomendamos que reserve un máximo de 1 a 2 núcleos de CPU paraservice_core_mask
ydpdk_ctrl_thread_mask
. Estos dos núcleos comparten la potencia de la CPU. -
-
cpu_core_mask
: Especifique una máscara de núcleo de CPU. Los PMD de DPDK utilizan estos núcleos para aplicaciones de procesamiento de paquetes de alta transferencia de datos.Los siguientes son formatos de entrada compatibles:
-
Hexadecimal (por ejemplo, 0xf)
-
Lista de CPU separadas por comas (por ejemplo, 1,2,4)
-
Rango de CPU separados por un guión (por ejemplo, 1-4)
-
-
dpdk_ctrl_thread_mask
: Especifique una máscara de subproceso de control. DPDK utiliza estos subprocesos de núcleo para el procesamiento interno.Los siguientes son formatos de entrada compatibles:
-
Hexadecimal (por ejemplo, 0xf)
-
Lista de CPU separadas por comas (por ejemplo, 1,2,4)
-
Rango de CPU separados por un guión (por ejemplo, 1-4)
Nota:Los PMD requieren la mayor parte de sus núcleos de CPU disponibles para el procesamiento de paquetes. Como resultado, recomendamos que reserve un máximo de 1 a 2 núcleos de CPU para
service_core_mask
ydpdk_ctrl_thread_mask
. Estos dos núcleos comparten la potencia de la CPU. -
-
dpdk_command_additional_args
: Especifique la configuración de vRouter DPDK que no es la configuración predeterminada. Los argumentos que escriba aquí se anexan a la línea de comandos DPDK PMD.A continuación se muestra un argumento de ejemplo:
--yield_option 0
.