BLOG

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

John Gruber Miniature
John Gruber
Publié le 31 décembre 2024

Pendant des années, la segmentation du réseau a été le pivot qui facilite l’isolement des menaces, la différenciation de la qualité de service, la réponse et l’analyse des incidents, l’audit de conformité et de nombreuses autres fonctions clés d’interopérabilité. Pourtant, alors que nous prônons les principes de confiance zéro et que nous déployons dans la précipitation l’IA, avons-nous négligé cet élément essentiel de infrastructure réseau qui sert de fondement à la cybersécurité et aux opérations de service modernes ?

Plus tôt dans notre série sur les usines d’IA, nous avons défini une usine d’IA comme un investissement massif en matière de stockage, de réseau et de calcul répondant à des exigences de formation et d’inférence à haut volume et à hautes performances. Pour rentabiliser cet investissement, les usines d’IA planifient de manière dynamique l’utilisation d’unités de traitement graphique (GPU) et de calcul à haute valeur ajoutée pour effectuer cette formation et cette inférence. La planification des GPU nécessite l’architecture de plusieurs « locataires » de services d’IA par cluster d’IA. Cela soulève un problème que de nombreuses équipes opérationnelles ne voient pas venir jusqu’à ce qu’il soit souvent trop tard.

Aligner les ressources du cluster d'usine d'IA avec la segmentation réseau

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.

Alignement de la segmentation du réseau avec les clusters d'usines d'IA multi-locataires

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.

diagramme nœud-gris-soupe

Par défaut, le contexte du locataire du cluster est perdu lors de la sortie.

Ce problème est intensifié lorsque le trafic entrant est inclus. Bien que le trafic entrant puisse être plus facile à gérer car il est dirigé depuis un centre de données déjà segmenté, comment corréler le trafic entrant d'un seul locataire à son trafic sortant ? La réponse s’articule autour de la génération augmentée de récupération ( RAG ) et des services d’agents, qui communiquent intensément pour acquérir des données externes et utiliser des services externes. Cela devient un effort inter-équipes avec des ingénieurs de plate-forme et NetOps identifiant un problème pour un client ou tentant de réussir des audits de sécurité.  

Les entreprises peuvent se demander : « Pourquoi ne pouvons-nous pas simplement utiliser la technologie de superposition de réseau défini par logiciel (SDN) et créer des réseaux VPC comme le font les hyperscalers ? » C'est certainement possible, mais cela déplace les coûts de maintenance des réseaux SDN VPC sur l'infrastructure existante du centre de données. Si la segmentation de la couche 2 (par exemple, VxLAN) est souhaitée, l'orchestration des tunnels avec une commutation de niveau supérieur et le provisionnement de ces commutateurs pour correspondre à la segmentation du réseau deviennent le problème. C'est pourquoi les hyperscalers ont choisi les SmartNIC et sont passés à une orchestration au niveau hôte à hôte, laissant les réseaux de centres de données rapides et peu intelligents.

La plupart des organisations ne disposent pas du talent de programmation réseau ni du désir de posséder une orchestration aussi complexe au niveau de l’hôte, ou elles ne peuvent tout simplement pas perdre la visibilité du réseau principal requise pour la qualité de service. Les solutions de routage proposées, couche 3 (par exemple, IP), pour résoudre ces problèmes ont conduit les équipes réseau à faire de chaque nœud de cluster d'IA un pair de routage dynamique (BGP) vers le centre de données avec plusieurs réflecteurs de route essayant de fournir une location de sous-réseau IP de base. Cela expose également les opérateurs à des problèmes de routage et à des audits de sécurité très complexes et a entraîné des pannes à l’échelle régionale.

Segmentation de réseau orchestrée prenant en compte les clusters pour les usines d'IA

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.

diagramme nœud-gris-soupe

BIG-IP Next pour Kubernetes permet à NetOps d'associer des locataires de cluster à des segments de réseau.

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.

La montée en puissance du DPU

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 ».

Usines IA propulsées par F5

Lors d’un investissement dans des usines d’IA, il n’est pas négociable de s’assurer que l’infrastructure est optimisée, efficace et évolutive. F5 BIG-IP Next pour Kubernetes déployé sur les DPU NVIDIA BlueField-3 fournit la segmentation réseau requise pour la planification dynamique du GPU et du calcul tout en offrant une évolutivité hautes performances pour maximiser le retour sur investissement de l'IA. Pour en savoir plus, contactez F5 pour entrer en contact avec votre gestionnaire de compte F5 et votre ingénieur ou architecte de solutions.