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

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.

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.

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

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