L'importance de la segmentation du réseau pour les usines d'IA

Dans un cluster IA, nous segmentons logiquement les ressources grâce à un contexte locataire, ce qui vous permet de gérer les quotas, les limites de consommation de ressources, la sécurité du système hôte et le contrôle d’accès basé sur les rôles (RBAC) pour la gestion. Cependant, les services réseau de base qui gèrent l’entrée et la sortie du trafic du cluster IA avec le reste du réseau de l’usine IA ne révèlent pas le contexte locataire. Sans ce contexte, élément fondamental de la cybersécurité en centre de données, la segmentation réseau ne peut être efficace. Les méthodes classiques pour exposer les contextes nécessaires privent l’usine IA de ressources de calcul précieuses ou ralentissent les chemins réseau au point de compromettre la latence, la bande passante ou la concurrence requises.  Vous êtes donc confronté à un faux dilemme : exploiter efficacement les ressources à haute valeur de l’usine IA ou intégrer correctement les locataires au réseau.

Dans les infrastructures de cloud public, nous basons tous les services d’une région cloud sur des réseaux multi-locataires orchestrés, mis en œuvre via des clouds privés virtuels (VPC). Cette segmentation réseau virtualisée garantit la sécurité et la comptabilisation précise des ressources. Les fournisseurs de cloud public s’appuient sur des équipes de développeurs logiciels réseau et du matériel spécialisé, notamment des SmartNIC et data processing units (DPU), pour gérer cette fonction. Les clusters d’usines d’IA dans les clouds publics exploitent pleinement l’orchestration réseau VPC de l’infrastructure sous-jacente. Maintenir les VPC représente un coût important, mais cela constitue le cœur du modèle économique du cloud public.  

La question se pose : Comment une organisation peut-elle maximiser son investissement dans une usine d'IA et planifier de manière dynamique les GPU et les calculs sans le même niveau d'investissement qu'un fournisseur de cloud public ?

La première étape de ce parcours pour l’industrie a été d’utiliser la virtualisation des serveurs pour créer des machines virtuelles (VM). Les machines virtuelles utilisent le transfert matériel pour se connecter aux réseaux de centres de données segmentés. Placez simplement toutes les machines virtuelles sur les mêmes VLAN et nous poursuivons nos opérations normalement si nous ne nous préoccupons que d’un seul locataire dans un seul cluster AI.

Les machines virtuelles peuvent aussi prendre en charge la segmentation GPU, car les fournisseurs proposent des moyens de subdiviser les dispositifs GPU en groupes de cœurs et de mémoire, puis de les attribuer à des machines virtuelles spécifiques. Cependant, segmenter les dispositifs GPU n’est pas dynamique et exige que vous redémarriez la machine virtuelle. En outre, cette approche limite votre capacité à constituer un pool de ressources GPU mesurable et partagé entre plusieurs locataires. Ces contraintes représentent des inconvénients majeurs pour cette solution.

Que deviennent nos clusters d’usines IA quand ils ne peuvent plus desservir un locataire ? Le problème se déplace alors vers le centre de données. Dans les clusters d’usines IA, par défaut, nous traduisons toutes les adresses réseau source (SNAT) du trafic sortant vers le centre de données en l’adresse IP d’un nœud spécifique du cluster où s’exécute la charge conteneurisée à l’origine de la requête, ce qui masque la source réelle. Le trafic est donc émis depuis un segment réseau sur lequel ce nœud est déployé. Dans un cluster multi-locataire, cela fait perdre le contexte du locataire et crée un mélange confus de trafic sortant provenant de plusieurs locataires, qu’il est impossible de trier, sécuriser, dépanner ou auditer.

Les usines d'IA doivent prévoir une solution réseau riche en fonctionnalités, programmable, sécurisée et à faible latence, évolutive en termes de bande passante et de simultanéité. Les contextes des locataires au niveau de la couche 2 (par exemple, les VLAN, VxLAN) et de la couche 3 (par exemple, les sous-réseaux, les interfaces IPSEC) doivent être présentés depuis un cluster vers le réseau de l'usine AI. Les mesures d’observabilité, les journaux et les outils de débogage doivent être disponibles pour NetOps.

Traditionnellement, la plupart de ces solutions de location et de visibilité des application sont fournies par F5 BIG-IP . F5 BIG-IP Container Ingress Services (CIS) découvre dynamiquement les services Kubernetes et les expose aux centres de données en tant que serveurs virtuels, un objet de configuration que les administrateurs BIG-IP connaîtront depuis leur configuration jusqu'à la présentation de serveurs physiques et de machines virtuelles. Bien que BIG-IP réponde à la plupart des exigences que nous recherchons dans une solution, il ne gère pas le trafic de sortie du cluster d'IA vers le réseau de l'usine d'IA, ce qui est nécessaire pour maintenir la segmentation.

Pour résoudre ce problème, nous avons conçu F5 BIG-IP Next pour Kubernetes , une solution pour les clusters de calcul multi-locataires construite sur notre plateforme nouvelle génération BIG-IP Next.

BIG-IP Next pour Kubernetes s’administre entièrement via le plan de contrôle Kubernetes. Il gère l’authentification Kubernetes, applique le RBAC à toutes les ressources déclarées et identifie la location Kubernetes par les espaces de noms pour assurer la segmentation réseau nécessaire au trafic entrant et sortant. Ceci est crucial pour les architectures orientées orchestration, comme les usines d’IA.

BIG-IP Next for Kubernetes fournit un moyen simplifié pour NetOps de déclarer les mappages entre les espaces de noms Kubernetes et les segments de réseau. L'appairage de route dynamique entre le réseau de l'usine AI et les instances BIG-IP Next utilise une syntaxe de configuration de route familière. Les équipes NetOps ont la capacité unique de dépanner en toute sécurité les flux réseau en direct pour l'entrée et la sortie du cluster. Les équipes SecOps bénéficient de listes de contrôle d'accès (ACL) d'entrée et de sortie du pare-feu par locataire de cluster, de capacités de déni de service distribué (DDoS) et d'IPS.

Pour vos équipes d'ingénierie plateforme, BIG-IP Next pour Kubernetes libère les ressources de calcul en prenant en charge les fonctions réseau, comme le traitement du trafic entrant et sortant, ainsi que le NAT source et le pare-feu. Vous réduisez ainsi vos coûts opérationnels tout en assurant la disponibilité et la performance des services.

BIG-IP Next for Kubernetes prend également en charge l'API Kubernetes Gateway, la première API d'entrée communautaire modélisée pour des rôles organisationnels spécifiques dans NetOps, l'ingénierie de plate-forme, DevOps et MLOps. Grâce à l'API Gateway, BIG-IP Next for Kubernetes étend les services d'entrée de route HTTP(S) de couche 4 typiques ou de couche 7 basés sur les ports à une suite pour DevOps/MLOps, à savoir TCPRoute, UDPRoute, HTTPRoute, TLSRoute et GRPCRoute, tous contrôlés via la même automatisation CI/CD dans les principaux frameworks d'IA.

D'un point de vue de gestion, BIG-IP Next for Kubernetes permet à NetOps, SecOps, l'ingénierie de la plate-forme, DevOps et MLOps de travailler ensemble efficacement via les déclarations d'API Kubernetes. C'est tout ce que vous attendez de BIG-IP, mais à travers l'objectif Kubernetes tout en prenant en charge la segmentation du réseau.

Les unités de traitement de données (DPU) ont gagné en popularité exponentielle au sein des usines d’IA. Défini dans un article de blog précédent de notre série sur les usines d'IA , un DPU est un processeur programmable conçu pour gérer de vastes mouvements et traitements de données via une accélération matérielle au débit de la ligne réseau. Grâce à l'innovation produit chez F5 et à la collaboration avec NVIDIA, nous avons publié BIG-IP Next pour Kubernetes afin de décharger les flux de données pour le trafic entrant et sortant tout en prenant en charge la segmentation du réseau, ainsi que les fonctions de sécurité en déployant sur les DPU NVIDIA BlueField-3 à l'aide des API DOCA de NVIDIA. Cela maximise l’investissement dans une usine d’IA en garantissant que les clusters d’IA sont « alimentés par des données ».