La importancia de la segmentación de red para las fábricas de IA

Dentro de un clúster de IA, podemos segmentar recursos de forma lógica con un contexto de inquilino, lo que permite cuotas de inquilinos, límites de consumo de recursos, seguridad del sistema host y control de acceso basado en roles de gestión (RBAC). Sin embargo, los contextos de inquilinos no están expuestos con los servicios de red básicos que proporcionan el ingreso y egreso de tráfico del clúster de IA con el resto de la red de la fábrica de IA. Sin este contexto, la base de la ciberseguridad en el centro de datos, la segmentación de la red es ciega. Los métodos típicos para exponer los contextos de inquilinos necesarios privan significativamente a la fábrica de IA de computación de alto valor o ralentizan las rutas de red por debajo de los límites requeridos para la latencia del servicio, el ancho de banda o la concurrencia.  Nos enfrentamos a falsas elecciones entre utilizar de manera eficiente los recursos de la fábrica de IA de alto valor y la integración adecuada de los inquilinos con la red.

En las infraestructuras de nube pública, los diseños de redes multiinquilino orquestados son la base de todos los servicios en una región de nube y se implementan con nubes privadas virtuales (VPC). Esta segmentación de red virtualizada es clave para la seguridad y la medición de recursos. Los proveedores de nube pública mantienen esta función con equipos de desarrolladores de software de red y hardware de red especializado, incluidos SmartNIC y unidades de procesamiento de datos (DPU). Los clústeres de fábricas de IA en nubes públicas están diseñados para aprovechar la orquestación de la red VPC de la infraestructura subyacente. El costo de mantener las VPC es bastante sustancial, pero es fundamental para el modelo de negocio de la nube pública.  

Surge la pregunta: ¿Cómo puede una organización maximizar su inversión en una fábrica de IA y programar dinámicamente las GPU y el procesamiento sin el mismo nivel de inversión que un proveedor de nube pública?

La primera parada de la industria en este viaje fue utilizar la virtualización de servidores para crear máquinas virtuales (VM). Las máquinas virtuales utilizan el paso a través de hardware para conectarse a redes de centros de datos segmentados. Simplemente coloque todas las máquinas virtuales en las mismas VLAN y continuaremos con las operaciones de manera normal si solo nos preocupa un solo inquilino en un solo clúster de IA.

Las máquinas virtuales también pueden abordar la segmentación de GPU, ya que los proveedores de GPU admiten formas de subdividir los dispositivos GPU en conjuntos de núcleos y memoria, y luego asignarlos a máquinas virtuales específicas. Sin embargo, la segmentación de los dispositivos GPU no es dinámica y requiere reiniciar la máquina virtual. Además, este diseño limita la capacidad de crear un grupo de recursos de GPU que puedan distribuirse entre muchos inquilinos. Estos son inconvenientes importantes de esta solución.

¿Qué sucede con nuestros clústeres de fábricas de IA cuando ya no pueden atender a un solo inquilino? El problema se traslada al centro de datos. En los clústeres de fábricas de IA, de manera predeterminada, todo el tráfico de red que sale hacia el centro de datos obtiene la dirección de red de origen traducida (SNAT) a la dirección IP de un nodo de clúster individual que la carga de trabajo en contenedores que emite la solicitud de red está ejecutando, enmascarando de manera eficaz la fuente real. Luego, el tráfico proviene de un segmento de red en el que se implementó ese nodo. En un clúster de múltiples inquilinos, esto significa que perdemos el contexto del inquilino y obtenemos un flujo mixto de tráfico de salida de múltiples inquilinos que es imposible de ordenar, proteger, solucionar problemas o auditar.

Las fábricas de IA deben planificar una solución de red rica en funciones, programable, segura y de baja latencia que sea escalable tanto en ancho de banda como en concurrencia. Los contextos de inquilinos en la capa 2 (por ejemplo, VLAN, VxLAN) y la capa 3 (por ejemplo, subredes, interfaces IPSEC) deben presentarse desde dentro de un clúster a la red de la fábrica de IA. Las métricas de observabilidad, los registros y las herramientas de depuración deben estar disponibles para NetOps.

Tradicionalmente, muchas de estas soluciones de visibilidad y arrendamiento de aplicação son proporcionadas por F5 BIG-IP . F5 BIG-IP Container Ingress Services (CIS) descubre dinámicamente los servicios de Kubernetes y los expone a los centros de datos como servidores virtuales, un objeto de configuración con el que los administradores de BIG-IP estarán familiarizados por haberlos configurado para presentar servidores físicos y máquinas virtuales. Si bien BIG-IP cumple con muchos de los requisitos que buscamos en una solución, no administra el tráfico de salida del clúster de IA a la red de la fábrica de IA, que es necesaria para mantener la segmentación.

Para abordar este problema, diseñamos F5 BIG-IP Next para Kubernetes , una solución para clústeres de cómputo de múltiples inquilinos construida sobre nuestra plataforma de próxima generación BIG-IP Next.

BIG-IP Next para Kubernetes se administra completamente a través del plano de control de Kubernetes y admite la autenticación de administración de Kubernetes, RBAC para todos los recursos declarados, reconoce la tenencia de Kubernetes a través de espacios de nombres para admitir la segmentación de red requerida tanto para el tráfico de entrada como de salida. Esto es clave para las arquitecturas que priorizan la orquestación, como las fábricas de IA.

BIG-IP Next para Kubernetes proporciona una forma simplificada para que NetOps declare las asignaciones entre los espacios de nombres de Kubernetes y los segmentos de red. El intercambio de rutas dinámicas entre la red de la fábrica de IA y las instancias de BIG-IP Next utiliza una sintaxis de configuración de rutas familiar. Los equipos de NetOps tienen la capacidad única de solucionar de forma segura los problemas de las transmisiones de red en vivo durante el ingreso y egreso del clúster. Los equipos de SecOps obtienen listas de control de acceso de firewall de entrada y salida (ACL) por cada inquilino del clúster, capacidades de denegación de servicio distribuida (DDoS) e IPS.

Para los equipos de ingeniería de plataformas, BIG-IP Next for Kubernetes alivia los recursos computacionales al descargar funciones de red como el procesamiento del tráfico de entrada y salida de datos, además del NAT de origen y el firewall. Esto ayuda con los costos operativos, al tiempo que mantiene los servicios disponibles y eficientes.

BIG-IP Next para Kubernetes también es compatible con Kubernetes Gateway API, la primera API de ingreso a la comunidad modelada para roles organizacionales específicos en NetOps, ingeniería de plataformas, DevOps y MLOps. A través de la API de puerta de enlace, BIG-IP Next para Kubernetes extiende los servicios de ingreso de ruta HTTP(S) basados en puertos de capa 4 o de capa 7 a un conjunto para DevOps/MLOps, a saber, TCPRoute, UDPRoute, HTTPRoute, TLSRoute y GRPCRoute, todos los cuales se controlan a través de la misma automatización de CI/CD en los principales marcos de IA.

Desde una perspectiva de gestión, BIG-IP Next para Kubernetes mantiene a NetOps, SecOps, ingeniería de plataforma, DevOps y MLOps trabajando juntos de manera efectiva a través de las declaraciones de API de Kubernetes. Es todo lo que espera de BIG-IP, pero a través de la lente de Kubernetes y al mismo tiempo admitiendo la segmentación de red.

Las unidades de procesamiento de datos (DPU) han ganado una tracción exponencial dentro de las fábricas de IA. Definida en una publicación de blog anterior dentro de nuestra serie de fábrica de IA , una DPU es un procesador programable diseñado para manejar un gran movimiento y procesamiento de datos a través de la aceleración de hardware a la velocidad de la línea de red. Gracias a la innovación de productos en F5 y la colaboración con NVIDIA, lanzamos BIG-IP Next para Kubernetes para descargar los flujos de datos para el tráfico de entrada y salida y, al mismo tiempo, respaldar la segmentación de la red, así como las funciones de seguridad mediante la implementación en las DPU NVIDIA BlueField-3 mediante las API DOCA de NVIDIA. Esto maximiza la inversión en una fábrica de IA al garantizar que los clústeres de IA estén “alimentados con datos”.