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.

Alignement des ressources du cluster d'usine d'IA avec la segmentation du réseau

Au sein d'un cluster d'IA, nous pouvons segmenter logiquement les ressources avec un contexte de locataire, ce qui permet des quotas de locataire, des 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 de gestion (RBAC). Cependant, les contextes des locataires ne sont pas exposés aux services réseau de base fournissant le trafic entrant et sortant du cluster AI avec le reste du réseau de l'usine AI. Sans ce contexte, fondement de la cybersécurité dans le datacenter, la segmentation du réseau est aveugle. Les méthodes typiques pour exposer les contextes de locataire nécessaires privent considérablement l'usine d'IA de calculs de grande valeur ou ralentissent les chemins réseau en dessous des limites requises pour la latence du service, la bande passante ou la concurrence.  Nous sommes confrontés à de faux choix entre l’utilisation efficace des ressources de l’usine d’IA à haute valeur ajoutée et l’intégration appropriée des locataires avec le réseau.

Dans les infrastructures de cloud public, les conceptions de réseaux multi-locataires orchestrées constituent la base de tous les services d'une région cloud et sont mises en œuvre avec des clouds privés virtuels (VPC). Cette segmentation de réseau virtualisée est essentielle pour la sécurité et la mesure des ressources. Les fournisseurs de cloud public maintiennent cette fonction avec des équipes de développeurs de logiciels réseau et du matériel réseau spécialisé, notamment des SmartNIC et des unités de traitement de données (DPU). Les clusters d’usine d’IA dans les clouds publics sont conçus pour tirer parti de l’orchestration du réseau VPC de l’infrastructure sous-jacente. Le coût de maintenance des VPC est assez important, mais il est au 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 également gérer la segmentation du GPU, car les fournisseurs de GPU prennent en charge les moyens de subdiviser les périphériques GPU en ensembles de cœurs et de mémoire, puis de les attribuer à des machines virtuelles spécifiques. Cependant, la segmentation des périphériques GPU n'est pas dynamique et nécessite un redémarrage de la VM. De plus, cette conception limite la capacité à créer un pool de ressources GPU pouvant être mesurées sur plusieurs locataires. Il s’agit là d’inconvénients importants pour cette solution.

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

Qu'advient-il de nos clusters d'usines d'IA lorsqu'ils ne peuvent plus servir un seul locataire ? Le problème se déplace vers le centre de données. Dans les clusters d'usine AI, par défaut, tout le trafic réseau sortant vers le centre de données reçoit une adresse réseau source traduite (SNAT) vers une adresse IP de nœud de cluster individuelle sur laquelle la charge de travail conteneurisée qui émet la demande réseau s'exécute, masquant ainsi efficacement la véritable source. Le trafic provient alors d’un segment de réseau sur lequel ce nœud a été déployé. Pour un cluster multi-locataire, cela signifie que nous perdons le contexte du locataire et que nous obtenons un flux mixte de trafic de sortie provenant de plusieurs locataires qu'il est impossible de trier, de sécuriser, de dépanner ou d'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 for Kubernetes est entièrement géré via le plan de contrôle Kubernetes et prend en charge l'authentification de gestion Kubernetes, RBAC pour toutes les ressources déclarées, reconnaît la location Kubernetes via des espaces de noms pour prendre en charge la segmentation réseau requise pour le trafic entrant et sortant. C'est essentiel pour les architectures axées sur l'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 les équipes d'ingénierie de la plateforme, BIG-IP Next for Kubernetes allège les ressources de calcul en déchargeant les fonctions réseau telles que le traitement du trafic entrant et sortant des données, ainsi que le NAT source et le pare-feu. Cela permet de réduire les coûts opérationnels tout en maintenant les services disponibles et efficaces.

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.