SmartNIC en el alojamiento web: cómo evaluar correctamente la aceleración de red

Cómo situar correctamente las SmartNIC en el ámbito del alojamiento web

El término SmartNIC No se trata de un nombre de producto estandarizado de forma uniforme. Por lo tanto, a la hora de planificar el alojamiento, lo decisivo no es la etiqueta, sino la función demostrable en la ruta de datos: ¿qué paquetes, reglas y túneles puede procesar la tarjeta, qué tareas corresponden al servidor y qué software controla las funciones? Una alta velocidad de puerto no responde a estas preguntas.

Una tarjeta de red clásica proporciona, sobre todo, la conexión Ethernet y admite funciones básicas de descarga habituales, como sumas de comprobación o segmentación. Una SmartNIC amplía este marco con funciones especializadas o programables de ruta de datos. Entre ellas pueden figurar reglas de flujo, funciones de conmutación virtual, SR-IOV, procesamiento de túneles o tareas criptográficas. Sin embargo, la disponibilidad de estas funciones depende conjuntamente del modelo, el firmware, los controladores y la integración con la plataforma.

A DPU suele tener una arquitectura más compleja: además del ASIC de red, cuenta con recursos de cálculo propios y puede gestionar una ruta de datos de infraestructura independiente. NVIDIA describe para BlueField un modo DPU, en el que el sistema ARM integrado controla los recursos de la NIC y la ruta de datos, así como un modo NIC, en el que la tarjeta se comporta como un adaptador frente al host externo. De este modo, dependiendo del modo de funcionamiento, se crea también un ámbito de gestión y confianza propio.

Esta clasificación tiene consecuencias prácticas para la adquisición y el funcionamiento. Una tarjeta con su propia lógica de cálculo no es automáticamente la mejor opción cuando solo se necesitan descargas básicas sencillas. Por el contrario, una ruta de infraestructura externalizada puede resultar útil para la segregación de clientes o las funciones de seguridad, pero entonces requiere mantenimiento del firmware, conceptos de acceso, supervisión y procesos de recuperación para componentes adicionales.

Ni siquiera un puerto de 100 GbE o más rápido garantiza una aceleración de las reglas del cortafuegos, las superposiciones o el cifrado. Los factores decisivos son el tamaño de los paquetes, el número de flujos paralelos, el alcance de las reglas y si las acciones necesarias pueden realmente implementarse en el hardware. Solo cuando se demuestre que la CPU del servidor supone una limitación en la ruta de datos de la red, la lista de funciones se convierte en una posible ganancia de capacidad.

Cómo la descarga de hardware modifica la ruta de los datos

Sin una descarga adicional, un paquete llega primero a la tarjeta de red física (NIC) y, a continuación, es procesado por el host. Dependiendo de la arquitectura, pasa por la pila de red del kernel, el cortafuegos, el puente o el conmutador virtual, el enrutamiento y, si procede, la encapsulación para una superposición. Solo entonces llega a una máquina virtual, un contenedor u otro puerto físico. Cada paso puede generar tiempo de CPU y colas.

Esta ruta cobra especial relevancia cuando hay muchos paquetes pequeños, numerosas conexiones de corta duración o políticas de clientes muy extensas. No es solo el volumen de datos transmitidos lo que sobrecarga el servidor, sino también el procesamiento repetido de paquetes y flujos individuales. Por eso, aceleración de red No se trata de una característica general de un servidor, sino de una reducción específica de la carga en una ruta de datos concreta e identificada.

En Descarga de hardware Los componentes de control pueden transferir las reglas de reenvío y filtrado permitidas a una ruta de datos de hardware. El modelo «switchdev» de Linux describe, a este respecto, el traslado de la ruta de datos de reenvío desde el núcleo a un dispositivo de conmutación. Las reglas que se aplican realmente dependen de la tarjeta concreta, de su controlador y de la integración de red superior.

La documentación de OVS en la rama de desarrollo 4.0.90 describe expresamente, en una sección dedicada a la descarga de hardware de Flow, que se trata de una función experimental. Precisamente para esta configuración de OVS con DPDK, distingue entre la descarga completa de coincidencias y acciones y la descarga parcial, en la que solo se descargan las coincidencias. Esta descripción no constituye una prueba de compatibilidad estable y de carácter general para otras versiones de OVS, tarjetas de red o plataformas.

Por lo tanto, en la práctica, cada declaración de descarga debe especificar la ruta de datos concreta: versión del software utilizado, controladores, firmware, campos de coincidencia y acciones. El hecho de que un conmutador esté activado no demuestra ni que los flujos relevantes se hayan descargado, ni que se sigan cumpliendo sin cambios los requisitos de seguridad y la semántica de la red. En el caso del filtrado de VLAN, por ejemplo, switchdev exige que el hardware cumpla las reglas de VLAN de puente y descarte los ID de VLAN no autorizados. La descarga es, por tanto, la aplicación técnica de las reglas existentes, no una vía alternativa para eludirlas.

Cuándo resulta conveniente utilizar SmartNICs en el alojamiento web

Las SmartNIC resultan especialmente adecuadas en plataformas de virtualización con numerosas máquinas virtuales y decisiones de reenvío recurrentes. SR-IOV puede asignar una función virtual a una máquina virtual; en una arquitectura switchdev, las interfaces «representor» representan funciones físicas o virtuales en el sistema operativo. De este modo, las reglas que rigen el tráfico entre estos puertos pueden implementarse en el hardware. No obstante, la utilidad depende de las funciones que requiera la máquina virtual.

Redes superpuestas con capacidad para múltiples clientes y Microsegmentación son otro punto de partida. Si muchas redes de clientes aplican repetidamente asignaciones de VLAN o de superposición, reglas de control de acceso y decisiones similares sobre flujos, una ruta de datos de hardware adecuada puede aliviar la carga de las CPU de los hosts. El requisito previo sigue siendo que el número de reglas, los campos de coincidencia y las acciones estén disponibles en la tarjeta seleccionada, incluido el controlador, y que se mantenga íntegramente la semántica de las políticas.

Para OpenShift Container Platform 4.22, Red Hat documenta la descarga de hardware para nodos bare-metal con una SmartNIC compatible y un Network Operator SR-IOV activo. Solo se admite la comunicación de pod a pod, así como la comunicación de pod a servicio ClusterIP con pods normales; las aplicaciones DPDK no son compatibles con esta función. Además, la ventaja se limita a los tramos de comunicación en los que los nodos implicados utilizan SmartNIC compatibles.

En el caso de redes de host o de ubicación cifradas, la descarga de IPsec puede encargarse de tareas parciales o de todo el proceso de encapsulación, desencapsulación, cifrado y protección contra la repetición de paquetes. NVIDIA documenta diferentes tipos de descarga para este fin, entre ellos la descarga criptográfica y la descarga completa. Sin embargo, esto no implica una idoneidad universal: la compatibilidad y los límites de rendimiento dependen del modelo, del firmware y del método criptográfico.

Un servidor de alojamiento web sencillo es, a propósito, un contraejemplo. Si envía principalmente un número reducido de respuestas HTTP de gran tamaño y no muestra carga de CPU en la ruta de los paquetes, se puede utilizar un servidor más especializado hardware de servidor solo suponen una carga operativa adicional. En primer lugar, hay que aclarar si el cuello de botella se debe a la aplicación, la base de datos, el almacenamiento o la red. Las SmartNIC no son una alternativa viable para este diagnóstico.

Comparar los casos de uso desde el punto de vista técnico

Lo que determina si una SmartNIC resulta útil no es la velocidad nominal del puerto, sino la ruta concreta de los datos. Su uso resulta especialmente recomendable cuando hay muchas reglas recurrentes, un elevado número de flujos o funciones de superposición y de seguridad que consumen constantemente tiempo de la CPU del host. La ventaja sigue siendo dependiente de la trayectoria: Un tramo acelerado solo beneficia a las conexiones que realmente se ejecutan mediante hardware compatible y reglas admitidas.

En el caso de las plataformas de máquinas virtuales, SR-IOV Un enfoque típico: las funciones virtuales se asignan a una máquina virtual, mientras que las interfaces «Representor» del sistema operativo mapean los puertos de dichas funciones. De este modo, las reglas de reenvío entre puertos virtuales y físicos pueden implementarse en hardware dentro de una arquitectura orientada a «switchdev». Sin embargo, esto no sustituye a la comprobación de si se mantienen la separación de clientes deseada y el modelo operativo.

Kubernetes es lo contrario a una promesa general de aceleración. Para la integración documentada con OpenShift 4.22 se aplican determinadas rutas de tráfico compatibles, nodos SmartNIC compatibles y requisitos de carga de trabajo. Si un nodo con capacidad de descarga comunica con un nodo normal, este último procesa su parte en el núcleo, lo que limita así la ruta total. Por lo tanto, una implementación debería tener en cuenta, en primer lugar, un conjunto de nodos delimitado y vías de comunicación reales.

En el caso de redes de host o de ubicación cifradas, estos términos deben utilizarse con especial precisión. Las variantes documentadas de IPsec van, según la plataforma, desde la descarga de cifrado (Crypto-Offload) hasta la descarga completa (Full Offload) para la encapsulación, la desencapsulación, el cifrado y la protección contra la repetición de paquetes. De ello no se deriva ninguna garantía general de rendimiento: el modelo, el firmware, los algoritmos utilizados y las limitaciones propias del producto determinan qué parte del procesamiento se externaliza realmente.

Comprobar la compatibilidad antes del lanzamiento

La adquisición comienza con un análisis inicial sin modificaciones, no con la activación de opciones de descarga. Registra el modelo exacto de la tarjeta, incluyendo el ID PCI, la versión del firmware, los controladores y el núcleo. Además, es necesario conocer el modo eSwitch, así como la versión y la configuración de Open vSwitch, OVN, el hipervisor o la plataforma Kubernetes, ya que la capacidad de la tarjeta por sí sola no garantiza una integración completa del software.

La semántica de las reglas necesarias debería estar disponible de antemano como descripción de la ruta de datos: por ejemplo, asignación de VLAN, IPv4 o IPv6, TCP o UDP, tipo de túnel, modificación de la cabecera, reenvío o descarte. La documentación experimental de OVS 4.0.90 muestra, en relación con su configuración DPDK, que la ausencia de acciones de hardware puede dar lugar a una descarga parcial. De ello se deduce que, para cualquier otra versión o plataforma, solo se trata de una tarea de comprobación, sin garantía alguna sobre su alcance funcional.

Las matrices de plataforma son Certificados de compatibilidad específicos para cada versión, no se hacen afirmaciones generales sobre una familia de tarjetas de red. OpenShift 4.22 especifica tarjetas de red concretas para su integración de descarga de hardware, entre las que se incluye BlueField-2 en modo ConnectX-6. De ello no se puede deducir ni la compatibilidad con otro firmware, ni con otro modo de DPU, ni con una distribución diferente. Por lo tanto, documenta por separado cada combinación de hardware, firmware, controlador y versión de la plataforma.

Para Linux-switchdev también es fundamental que el hardware respete la semántica de la red de software. En el filtrado de VLAN, por ejemplo, un conmutador que realiza la descarga debe respetar las reglas de VLAN del puente y descartar los ID de VLAN no permitidos. Este requisito pone de manifiesto por qué es necesario comprobar conjuntamente las listas de funciones y la política de seguridad: la aceleración no debe generar una segmentación de red diferente.

Sopesar las ventajas de SmartNIC frente a la CPU y el software

Una SmartNIC es solo una de las varias opciones cuando el procesamiento de red es limitado. En primer lugar, conviene comprobar si una mayor capacidad de la CPU, un número adecuado de colas, el RSS, la distribución de IRQ o el ajuste del núcleo ya resuelven el cuello de botella. Para comprender mejor el funcionamiento de las SoftIRQ, las colas y la distribución de interrupciones, consulta el artículo sobre Rendimiento de la CPU y del tráfico de red en el alojamiento web Conceptos básicos adicionales. Sin pruebas que demuestren la existencia de un cuello de botella en la red, el hardware especial adicional no deja de ser una suposición.

DPDK y AF_XDP pueden acortar las rutas de software en las CPU del host, pero cada uno requiere una planificación específica de la arquitectura y la CPU. La afirmación sobre el sondeo continuo no puede aplicarse de forma generalizada a ambos enfoques: En la documentación de OVS-DPDK para la configuración descrita, un hilo sondea continuamente los dispositivos DPDK y, al hacerlo, ocupa por completo un núcleo de la CPU. Por lo tanto, la asignación NUMA, el aislamiento de núcleos y las versiones concretas de OVS y DPDK siguen formando parte del diseño.

Una tarjeta de red clásica para servidor también puede proporcionar una descarga de carga suficiente para sumas de comprobación, segmentación o características específicas de los túneles. Esta opción resulta adecuada cuando no se requieren reglas de conmutación virtual complejas, segregación de clientes ni rutas de datos de seguridad en el hardware. Las SmartNIC cobran especial sentido cuando las funciones requeridas van más allá de esas características básicas y son recurrentes a largo plazo.

El concepto de capacidad es sencillo, pero importante: si los núcleos de la CPU de un host están ocupados procesando paquetes y se puede descargar por completo una parte representativa de esos paquetes, es posible que se genere margen de CPU. Sin embargo, este margen solo se considera capacidad utilizable si ni la aplicación, ni la memoria, ni el almacenamiento, ni un plan de contingencia de software constituyen el siguiente cuello de botella. No se trata de una derivación directa de la velocidad del enlace ni del precio de la tarjeta.

Por lo tanto, compara las alternativas basándote en el mismo perfil de carga: tamaño de los paquetes, velocidad de conexión, número de reglas, túneles, cifrado y carga máxima prevista. Para ello, analiza por separado la participación de la CPU en la ruta de datos y en el trabajo de la aplicación, y comprueba qué flujos se ejecutan realmente en el hardware. Un Cuello de botella de la CPU El uso de un cortafuegos, una red superpuesta o un reenvío virtual constituye un motivo válido para la evaluación; una carga elevada general del sistema no lo es.

Hacer visible la descarga durante el funcionamiento

Tras la puesta en marcha, no basta con comprobar que la opción de descarga esté activa. Una prueba de funcionamiento fiable vincula el Estado del flujo con los contadores de la tarjeta, las tasas de pérdida y de error, la utilización de la CPU, así como un perfil de carga similar al tráfico posterior. Solo en conjunto, estos datos revelan si los flujos relevantes se procesan realmente en el hardware o si el host sigue asumiendo la mayor parte de la ruta de datos.

Para realizar la comparación, los operadores deben tener en cuenta los mismos tamaños de paquetes, protocolos, número de conexiones y políticas, tanto antes como después de un cambio. El rendimiento puro en gigabits puede ocultar fácilmente un cuello de botella en el caso de paquetes pequeños o de muchos flujos paralelos. Son igualmente importantes la latencia, el tiempo de CPU por host implicado, la carga de Softirq, las pérdidas en la cola y la distribución del tráfico entre nodos y puertos.

Los siguientes comandos no modifican ninguna configuración. La primera consulta tiene en cuenta tanto los dispositivos PCI que aparecen como «Ethernet controller» como los que aparecen como «Network controller». ethtool -k Muestra las funciones de descarga disponibles o activadas en Netdev, pero no confirma de forma completa ni la descarga de eSwitch, ni la de SmartNIC, ni la de flujos. El resto de los resultados son datos de inventario y configuración, y no constituyen una prueba de que una regla concreta se haya descargado por completo.

lspci -nn | grep -Ei 'Ethernet controller|Network controller'
ethtool -k <interface>
ethtool -i <interface>
devlink dev show
ovs-vsctl get Open_vSwitch . other_config

En el caso de Open vSwitch, hay que distinguir especialmente entre la aceleración por hardware configurada y el resultado observado. La documentación de desarrollo de OVS 4.0.90 califica su descarga de flujo en hardware como experimental y describe la descarga total o parcial únicamente para esta configuración de OVS con DPDK. Por lo tanto, para el funcionamiento en producción, la información de flujos y los contadores de hardware deben evaluarse junto con los contadores de software del host.

Además, la supervisión requiere una referencia temporal. Una prueba breve puede confirmar ciertas reglas, mientras que un perfil cercano a la producción puede desencadenar posteriormente problemas de capacidad de las tablas, rutas de registro poco frecuentes o reconfiguraciones. Por lo tanto, es recomendable registrar los valores normales y las anomalías por modelo de tarjeta, firmware, controlador y versión de la plataforma. De este modo, tras las actualizaciones, se puede comprobar si el Ruta de datos o simplemente ha variado la carga observada.

En la integración con OpenShift 4.22, la vista debe abarcar además toda la ruta de comunicación. La compatibilidad documentada con la descarga de hardware solo se aplica a determinadas cargas de trabajo y tipos de comunicación. Si un nodo compatible se comunica con un nodo que no dispone de una SmartNIC adecuada, este último procesa su tramo en el núcleo; en ese caso, los puntos de medición en un solo host pueden ofrecer una visión incompleta de la ruta de extremo a extremo.

Casos típicos de fallo y vías de recuperación

El error más frecuente es descarga incompleta. Un flujo puede identificarse en el hardware a partir de características sencillas; sin embargo, en el caso de una acción no compatible, debe volver, total o parcialmente, a la ruta de software. La documentación experimental de OVS 4.0.90 describe esta descarga parcial para su configuración DPDK. No se trata de una afirmación generalizable a todas las instalaciones de OVS, pero pone de manifiesto el punto de verificación necesario en cada integración concreta.

El diagnóstico comienza a lo largo de la ruta real: puerto de entrada, función virtual o representador, regla de conmutación, procesamiento del túnel o de la política y carga de trabajo de destino. Si los contadores situados antes y después de una etapa no coinciden de forma plausible, esto constituye un motivo para comprobar las coincidencias, las acciones y el mecanismo de reserva. Una función activada no sustituye a esta asignación, ya que la capacidad de la tarjeta no abarca todas las combinaciones de reglas deseadas.

Los clústeres heterogéneos dificultan la comparación. En OpenShift 4.22, la descarga de hardware solo se produce si los pods y servicios implicados están asignados a nodos con una SmartNIC compatible. Si una ruta de este tipo se encuentra con un nodo normal, su procesamiento se lleva a cabo en el núcleo, lo que limita la comunicación total. Por lo tanto, un único nodo acelerado no ocupa una ruta de clúster totalmente acelerada.

Una configuración inadecuada de los pods o de la red también puede impedir que se produzca el efecto esperado. Red Hat señala expresamente, en relación con la función de OpenShift 4.22, que la descarga de hardware activada sin unos pods configurados adecuadamente puede reducir el rendimiento de los pods. Por lo tanto, los administradores no deberían intentar solucionar una anomalía activando más opciones, sino que deberían comprobar primero la conexión de la carga de trabajo, el modo de red y los flujos realmente alcanzados.

La capacidad de regulación y las desviaciones del firmware pertenecen a la misma clase de errores: en el caso de muchos clientes, conexiones de corta duración o políticas dinámicas, el volumen de flujo relevante puede crecer de forma diferente a la esperada. Además, un controlador vinculado a una versión concreta o un firmware diferente pueden ofrecer funciones distintas a las de la combinación de plataformas prevista. Por ello, los datos de inventario y los contadores deben archivarse siempre junto con el conjunto concreto de reglas.

A ruta de retroceso controlada permite diagnosticar el funcionamiento. Implica que el procesamiento por software se mantiene como alternativa prevista y que los cambios se implementan de forma gradual, con ventanas de comparación y criterios de interrupción claros. El «fallback» de software no es, por sí mismo, un defecto, sino que puede constituir el tratamiento previsto para aquellas acciones que la ruta de hardware elegida no admite por completo.

Tomar decisiones realistas sobre la adquisición y la explotación

Una decisión de adquisición debe partir de la carga de trabajo, no de la velocidad del puerto ni de la denominación del producto. El uso de hardware especializado resulta plausible cuando se demuestra que el procesamiento recurrente de paquetes consume tiempo de CPU: por ejemplo, en el caso de numerosas redes virtuales, conjuntos de políticas estables, tráfico de superposición o una ruta de cifrado definida. A falta de esta evidencia, el ajuste de la CPU y de las colas, o una tarjeta de red clásica con descargas básicas adecuadas, pueden ser la solución más sencilla.

A continuación, hay que... Certificado de compatibilidad que funcionen para la combinación concreta: modelo de tarjeta y modo de funcionamiento, firmware, controladores, núcleo, conmutador virtual o CNI, así como las funciones de coincidencia y acción necesarias. Los aceleradores de infraestructura programables pueden, por ejemplo, proporcionar descarga de flujos para funciones relacionadas con el estado o la sesión; sin embargo, esto no implica que todas las SmartNIC o todas las plataformas ofrezcan la misma función.

La reducción prevista de la carga de la CPU solo estará disponible como capacidad cuando el procesamiento de paquetes haya sido el cuello de botella y los núcleos liberados puedan utilizarse de forma adecuada. Si, por ejemplo, se asignan a bases de datos, web workers o reservas, se trata de una decisión arquitectónica, no de una mejora automática del rendimiento. Por lo tanto, el resto del equipamiento del servidor sigue siendo fundamental; la CPU, la memoria RAM y el almacenamiento deben adaptarse a la aplicación tanto como la red. El artículo sobre Hardware de servidor relevante para el rendimiento en el alojamiento web.

En el caso de IPsec, la comprobación es especialmente concreta: las variantes de descarga documentadas van desde la descarga criptográfica hasta la externalización completa de la encapsulación, la desencapsulación, el cifrado y la protección contra la repetición. La variante que se pueda utilizar depende del modelo, la generación, el firmware y la configuración criptográfica. Además, las indicaciones específicas del producto pueden incluir limitaciones para determinadas generaciones o anchos de banda; estas deben tenerse en cuenta en la comprobación de autorización antes de la implantación.

Una DPU amplía la decisión con un ámbito propio de gestión y confianza. En el modo BlueField-DPU, el sistema Arm integrado controla los recursos de la NIC y la ruta de datos, en lugar de que la tarjeta funcione únicamente como adaptador del host. Esto permite separar las tareas de infraestructura del host, pero requiere un diseño sólido en cuanto a derechos de acceso, imágenes, actualizaciones, supervisión y recuperación.

Por lo tanto, desde el punto de vista económico, no solo cuenta el precio de la tarjeta. Hay que tener en cuenta también la capacidad de la CPU del host que se ahorra o se evita utilizar, la vida útil prevista de la plataforma, así como los costes adicionales derivados de la certificación, las piezas de recambio, el mantenimiento del firmware y la recuperación ante incidentes. Una SmartNIC resulta útil cuando este cálculo se basa en una ruta de datos reproducible y en un ciclo de vida controlable a largo plazo, y no porque el hardware especializado parezca, en principio, más rápido.