Solution Architecture

Fabric back-end de GPU

La fabric back-end des GPU fournit l’infrastructure permettant aux GPU de communiquer entre eux au sein d’un cluster, à l’aide de RDMA sur Ethernet convergé (RoCEv2). RoCEv2 améliore l’efficacité des datacenters, réduit la complexité et optimise la livraison des données sur les réseaux Ethernet haut débit.

Contrairement à la fabric front-end, la fabric back-end GPU achemine un trafic de plan de données qui consomme beaucoup de bande passante et est sensible à la latence. La perte de paquets, une latence excessive ou une gigue peuvent avoir un impact significatif sur les délais d’exécution des tâches et doivent donc être évitées.

Par conséquent, l’un des principaux objectifs de conception du fabric de back-end GPU est de fournir une fabric Ethernet proche de l’sans perte, tout en offrant une débit maximale, une latence minimale et une interférence réseau minimale pour le trafic GPU à GPU. RoCEv2 fonctionne plus efficacement dans les environnements où la perte de paquets est minimisée, ce qui contribue directement à optimiser les délais d’exécution des tâches.

La fabric back-end GPU de cette JVD a été conçue pour répondre à ces exigences. La conception suit une architecture IP Clos à 3 niveaux, Rail Optimized Stripe, comme illustré sur la figure 5. Les détails de l’architecture Rail Optimized Stripe sont décrits dans une section ultérieure.

Figure 5 : Architecture fabric backend GPU

La structure fonctionne comme une structure IP L3 avec EBGP pour la publication de route avec adressage IP et les détails de configuration EBGP décrits dans la section réseau de ce document.

Dans une architecture rail-optimized (rail-optimized), le nombre de nœuds Leaf est déterminé par le nombre de GPU par serveur, qui est de 8 pour les serveurs AMD inclus dans cette JVD. Le nombre de nœuds spine, ainsi que la vitesse et le nombre de liaisons entre les serveurs GPU et les nœuds leaf, et entre les nœuds leaf et spine, déterminent la bande passante effective et les caractéristiques de surabonnement de la fabric back-end GPU.

Contrairement à la fabric front-end, la fabric back-end GPU cible généralement une conception sans surabonnement (1:1) ou un taux de surabonnement très faible. Cela garantit une bande passante suffisante pour des opérations collectives simultanées et évite la congestion qui pourrait introduire une perte de paquets ou une variation de latence.

Il s’agit d’une structure IP de couche 3 qui utilise EBGP pour l’annonce de route avec adressage IP et les détails de configuration EBGP décrits dans la section mise en réseau de ce document. La distribution du trafic au sein de la fabric back-end de GPU repose sur ECMP sur plusieurs chemins L3 à coût égal, combiné à des techniques d’équilibrage de charge avancées telles que l’équilibrage de charge dynamique (DLB), l’équilibrage de charge global et l’équilibrage de charge adaptatif (ALB). Ils sont décrits dans la section Équilibrage de charge de ce document.

Étant donné que le fabric back-end GPU transporte un trafic RoCEv2 sensible aux pertes et aux latence, la conception intègre DCQCN (Data Center Quantized Congestion Notification), qui exploite l’ECN (Explicit Congestion Notification) et peut éventuellement utiliser PFC (Priority Flow Control) pour obtenir un comportement sans perte ou quasi sans perte pour le trafic RDMA. Ces mécanismes sont décrits en détail dans la section Classe de service du présent document.

Les appareils et la connectivité dans la fabric front-end validée dans cette JVD sont résumés dans les tableaux suivants :

Tableau 8 : équipements de gestion et serveurs GPU validés connectés à la fabric back-end GPU

Serveurs GPU,	périphériques de stockage	, serveurs de tête de réseau
Supermicro AS-8125GS-TNMR2 GPU AMD Instinct MI300X 192 Go OAM	Vaste CBOX (QUAD-4N-IL-2NIC) Nœuds C PowerEdge C6520 Cérès DBOX (DF-3015) 22 disques SSD NVMe de 15,363 To	Supermicro SYS-6019U-TR4

Tableau 9 : nœuds leaf de la fabric back-end GPU validés

Modèle de commutateur de nœuds leaf de la fabric back-end GPU
QFX5220-32CD
QFX5230-64CD
QFX5240-64OD
QFX5241-64OD

Tableau 10 : nœuds de cœur de fabric back-end GPU validés

Modèle de commutateur de nœuds

de fabric spine back-end GPU
QFX5230-64CD
QFX5240-64OD
QFX5241-64OD
PTX10008 LC1201
PTX10008 LC1301

Tableau 11 : connexions validées entre les serveurs GPU et les nœuds Leaf dans la fabric back-end de GPU

Liens par serveur GPU vers la connexion leaf	Type de serveur
1 x liens 400GE par serveur GPU vers connexion leaf	AMD MI300

Tableau 12 : connexions validées entre les nœuds leaf et spine dans la fabric back-end de GPU

Liaisons par connexion leaf et spine	Modèle de nœud leaf Modèle de nœud spine
1 x 400GE	QFX5220-32CD	QFX5230-32CD
1 x 400GE	QFX5230-32CD	QFX5230-32CD
2 x 400GE	QFX5240-64OD	QFX5240-64OD
1 x 800GE	QFX5240-64OD	QFX5240-64OD
1 x 400GE	QFX5220-32CD	PTX10008 LC1201
1 x 400GE	QFX5230-32CD	PTX10008 LC1201
1 x 800GE	QFX5240-64OD	PTX10008 LC1301
2 x 800GE	QFX5240-64OD	PTX10008 LC1301

Cette JVD a été testée sur 4 serveurs GPU MI300 reliés à deux bandes, comme illustré :

Figure 6 : Topologie de test JVD back-end GPU

• Chaque serveur GPU AMD MI300X est connecté aux nœuds Leaf à l’aide d’interfaces 400G (cartes réseau Thor2 et Pollara).

validated_optics_summary.html#Toc222928841__DAC_5m ont été testés avec des cartes Broadcom Thor2 et connectés comme indiqué sur le schéma ci-dessous.

Tableau 13 : Bande passante serveur-leaf par bande

Bande	Nombre de serveurs par Stripe	Nombre de serveurs <=> liens leaf par serveur (nombre de nœuds Leaf et nombre de GPU par serveur)	< serveur = bande passante de liaison leaf > [Gbit/s]	Nombre total de serveurs <=> liens de branche Bande passante par bande [Tbit/s]
1	2 MI300	8	400 Gbit/s	2 x 8 x 400 Gbit/s = 6,4 Tbit/s
2	2 MI300	8	400 Gbit/s	2 x 8 x 400 Gbit/s = 6,4 Tbit/s
< serveur total = bande passante leaf >				12,8 Tbit/s

Tableau 14 : bande passante leaf-spine par bande avec QFX5240 en tant que leaf et spines

Bande	Nombre de nœuds Leaf	Nombre de nœuds spine	Nombre de 400 Gbit/s < leaf = > liens spine par nœud Leaf	Serveur <=> Leaf Bande passante de liaison [Gbit/s]	Bande passante Leaf <=> dos par bande [Tbit/s]
1	8	4	2	400	8 x 2 x 2 x 400 Gbit/s = 12,8 Tbit/s
2	8	4	2	400	8 x 2 x 2 x 400 Gbit/s = 12,8 Tbit/s
Total des serveurs < = > bande passante leaf					25,6 Tbit/s

Facteur d’abonnement à la fabric back-end GPU

Le facteur de souscription est simplement calculé en comparant les chiffres des deux tableaux ci-dessus :

Dans l’environnement de test JVD, la bande passante entre les serveurs et les nœuds leaf est de 6,4 Tbit/s par bande, tandis que la bande passante disponible entre les nœuds leaf et spine est de 12,8 Tbit/s par bande. Cela signifie que la fabric dispose d’une capacité suffisante pour traiter tout le trafic entre les GPU, même lorsque ce trafic est 100 % inter-bandes, tout en disposant d’une capacité supplémentaire pour accueillir des serveurs supplémentaires sans surabonnement. Le facteur d’abonnement dans ce cas est de 1:2.

Figure 7 : Facteur d’abonnement 1:2 (surprovisionné)

Pour exécuter des tests de surabonnement, certaines interfaces entre le commutateur Leaf et le commutateur Spine ont été désactivées, ce qui a réduit la bande passante disponible, comme le montre l’exemple de la figure 8 :

Figure 8 : Facteur d’abonnement 1:1

De plus, un générateur de trafic Ixia émulant des appareils RoCEv2 était également connecté à la fabric, comme le montre l’exemple de la figure 9.

Figure 9 : Facteur d’abonnement 1:1

Cela ajoute 800 G de trafic supplémentaire aux branches 2 et 4 sur les bandes 1 et 2.

Optimisation de la communication GPU à GPU

L’optimisation dans les topologies rail-optimized fait référence à la façon dont la communication GPU est gérée pour minimiser la congestion et la latence tout en maximisant le débit. Un élément clé de cette stratégie d’optimisation consiste à maintenir le trafic local dans la mesure du possible. En veillant à ce que la communication du GPU reste sur le même rail ou la même bande, ou même au sein du serveur, le besoin de traverser des spines ou des liaisons externes est réduit, ce qui diminue la latence, minimise la congestion et améliore l’efficacité globale.

Bien que la localisation du trafic soit une priorité, la communication entre bandes sera nécessaire dans les grands clusters de GPU. La communication entre les bandes est optimisée au moyen de techniques de routage et d’équilibrage appropriées sur les liaisons disponibles afin d’éviter les goulots d’étranglement et la perte de paquets.

L’essence de l’optimisation réside dans l’utilisation de la topologie pour diriger le trafic sur les chemins les plus courts et les moins encombrés, garantissant ainsi des performances constantes même lorsque le réseau évolue. Le trafic entre GPU sur les mêmes serveurs peut être transféré localement sur la fabric interne du serveur (selon le fournisseur), tandis que le trafic entre GPU sur différents serveurs s’effectue sur l’infrastructure backend GPU externe. La communication entre les GPU de différents serveurs peut se faire intra-rail ou interrail/interbande.

Le trafic intrarail est commuté (traité au niveau de la couche 2) sur le nœud Leaf local. Ainsi, les données entre les GPU de différents serveurs (mais dans la même bande) sont toujours déplacées sur le même rail et sur un seul commutateur. Cela garantit que les GPU sont à 1 saut les uns des autres et créera des canaux indépendants distincts à large bande passante, ce qui minimise les conflits et optimise les performances. D’autre part, le trafic interrail/interbande est acheminé à travers les interfaces IRB sur les nœuds leaf et les nœuds spine reliant les nœuds leaf (traité en couche 3).

Prenons l’exemple illustré à la figure 10

• La communication entre le GPU 1 et le GPU 2 dans le serveur 1 s’effectue sur la fabric interne du serveur (1),
• La communication entre les GPU 1 des serveurs 1 à 4 et entre les GPU 8 des serveurs 1 à 4 se produit respectivement sur les branches 1 et 8 (2), et
• La communication entre les GPU 1 et GPU 8 (dans les serveurs 1 à 4) s’effectue à travers leaf1, les nœuds spine et leaf8 (3)

Figure 10 : Communication GPU-GPU interrail et intrarail

La figure 10 représente une topologie avec une bande et 8 rails reliant les GPU 1 à 8 sur les commutateurs leaf 1 à 8, respectivement.

La communication entre le GPU 7 et le GPU 8 du serveur 1 s’effectue sur la fabric interne, tandis que la communication entre le GPU 1 du serveur 1 et le GPU 1 du serveur N1 s’effectue via le commutateur leaf 1 (dans le même rail).

Notez que si une communication entre des GPU de différentes bandes et différents serveurs est nécessaire (par exemple, un GPU 4 dans le serveur 1 communiquant avec le GPU 5 dans le serveur N1), les données sont d’abord déplacées vers une interface GPU dans le même rail que le GPU de destination, envoyant ainsi les données au GPU de destination sans traverser les rails.

Ainsi, les données entre les GPU de différents serveurs (mais dans la même bande) sont toujours déplacées sur le même rail et sur un seul commutateur, ce qui garantit que les GPU sont distants d’un saut les uns des autres et crée des canaux indépendants distincts à large bande passante, ce qui minimise les conflits et optimise les performances.

Sur les serveurs GPU AMD, les GPU sont interconnectés via la fabric AMD Infinity, qui fournit 7 x 128 Go/s de bande passante GPU à GPU à bande passante élevée, à faible latence et une communication bidirectionnelle GPU à GPU au sein d’un seul serveur, comme illustré sur la Figure 11.

Graphique 11. Architecture AMD MI300X.

Pour plus de détails, reportez-vous à la microarchitecture AMD Instinct™ MI300 Series - Documentation ROCm

Les GPU AMD MI300X exploitent Infinity fabric, fournissant une communication à haut débit et à faible latence entre les GPU, les CPU et d’autres composants. Cette interconnexion peut gérer dynamiquement la hiérarchisation du trafic sur les liaisons, fournissant ainsi un chemin optimisé pour la communication au sein du nœud.

Par défaut, les appareils AMD MI300X mettent en œuvre une optimisation locale afin de minimiser la latence du trafic GPU à GPU. Les communications entre les GPU des mêmes serveurs sont transmises sur la fabric Infinity et restent à l’intérieur du nœud et ne traversent pas la fabric Ethernet externe. Le trafic entre GPU de même rang sur plusieurs serveurs reste intrabande.

La figure 12 montre un exemple où le GPU 1 du serveur 1 communique avec le GPU 1 du serveur 2. Le trafic est acheminé par le nœud Leaf 1 et reste sur le rail 1.

De plus, si le GPU 4 du serveur 1 souhaite communiquer avec le GPU 5 du serveur 2 et que le GPU 5 du serveur 1 est disponible en tant que saut local dans la fabric Infinity d’AMD, le trafic préfère naturellement ce chemin pour optimiser les performances et maintenir la communication GPU à GPU à l’intérieur du rail.

Figure 12 : Communication interrail de GPU à GPU entre deux serveurs avec optimisation locale.

Si l’optimisation locale n’est pas réalisable en raison de contraintes de charge de travail, par exemple, le trafic doit contourner les sauts locaux (fabric interne) et utiliser RDMA (communication basée sur des NIC hors nœud). Dans ce cas, le GPU 4 du serveur 1 communique avec le GPU 5 du serveur 2 en envoyant des données directement sur la NIC à l’aide de RDMA, qui sont ensuite transmises à travers la structure, comme illustré à la figure 13.

Figure 13 : Communication interrail de GPU à GPU entre deux serveurs sans optimisation locale.

L’exemple montre que la communication entre le GPU 4 du serveur 1 et le GPU 5 du serveur N1 passe par le commutateur leaf 1, les nœuds Spine et le commutateur leaf 5 (entre deux rails différents).

Architecture optimisée pour le rail GPU back-end

Comme décrit précédemment, une architecture Rail Optimized Stripe assure un transfert de données efficace entre les GPU, en particulier lors de tâches gourmandes en calcul telles que les charges de travail d’entraînement des grands modèles de langage (LLM) de l’IA, où un transfert transparent des données est nécessaire pour accomplir les tâches dans un délai raisonnable. Une topologie rail-optimized vise à maximiser les performances en minimisant les conflits de bande passante, la latence et les interférences réseau, garantissant ainsi une transmission efficace et fiable des données sur le réseau.

Dans une architecture optimisée pour le rail, il existe deux concepts importants : le rail et le stripe.

Les GPU d’un serveur sont numérotés de 1 à 8, où le nombre représente la position du GPU sur le serveur, comme illustré sur la Figure 14. Ce nombre est parfois appelé rang ou plus précisément « rang local » par rapport aux GPU du serveur où se trouve le GPU, ou « classement global » par rapport à tous les GPU (dans plusieurs serveurs) affectés à une seule tâche.

Un rail relie des GPU du même ordre sur l’un des nœuds Leaf de la fabric ; c’est-à-dire que le rail Nth connecte tous les GPU en position Nth sur tous les serveurs, au nœud Leaf Nth, comme illustré sur la Figure 14.

Figure 14 : Rails dans une architecture optimisée pour le rail

Une bande fait référence à un module ou à un bloc de construction, composé de plusieurs rails, et comprend des nœuds Leaf et des serveurs GPU, comme illustré à la figure 15. Ce bloc modulaire peut être répliqué pour mettre à l’échelle le cluster d’IA.

Figure 15 : Rayures dans une architecture optimisée pour le rail

Tout le trafic entre GPU de même rang (trafic intra-rail) est transféré au niveau du nœud Leaf, comme illustré à la Figure 16.

Figure 16 : Exemple de trafic intrarail.

Une bande peut être répliquée pour augmenter le nombre de serveurs (N₁) et de GPU (N₂) dans un cluster d’IA. Plusieurs bandes (N₃) sont ensuite connectées sur les commutateurs Spine, comme illustré sur la Figure 17.

Figure 17 : Plusieurs bandes connectées via des nœuds Spine

Le trafic interrail et interbande sera acheminé à travers les nœuds de spines, comme le montre la figure 18.

Graphique 18. Exemple de trafic interrail et interbande de GPU à GPU.

Calcul du nombre de nœuds leaf et spine, de serveurs et de GPU dans une architecture rail-optimized

Le nombre de nœuds Leaf dans une seule bande dans une architecture optimisée pour les rails est défini par le nombre de GPU par serveur (nombre de rails). Chaque serveur GPU AMD MI300X comprend 8 GPU AMD Instinct MI300X. Par conséquent, une seule bande comprend 8 nœuds leaf (8 rails).

Nombre de nœuds Leaf = nombre de GPU x serveur = 8

Le nombre maximal de serveurs pris en charge dans une seule bande (N1) est défini par le nombre de ports disponibles sur le nœud Leaf, qui dépend du modèle du commutateur.

Pour maintenir un ratio d’abonnement de 1:1, la bande passante totale entre les serveurs GPU et les nœuds Leaf doit correspondre à la bande passante totale entre les nœuds Leaf et Spine.

En supposant que toutes les interfaces du nœud Leaf fonctionnent à la même vitesse, la moitié des interfaces sera utilisée pour se connecter aux serveurs GPU et l’autre moitié pour se connecter aux spines. Ainsi, le nombre maximal de serveurs dans une bande est calculé comme la moitié du nombre de ports disponibles sur chaque nœud Leaf.

Graphique 19. Nombre de liaisons montantes et descendantes pour un facteur d’abonnement 1:1

Sur le diagramme, X représente le nombre de liaisons descendantes (liaisons entre les nœuds leaf et les serveurs GPU), tandis que Y représente le nombre de liaisons montantes (liaisons entre les nœuds leaf et les nœuds spine). Pour permettre un facteur d’abonnement de 1:1, X doit être égal à Y.

Le nombre de ports disponibles sur chaque nœud Leaf est égal à X + Y ou 2 * X.

Étant donné que tous les serveurs d’une bande ont un port connecté à chaque branche de la bande, le nombre maximal de serveurs dans la bande (N₁) est égal à X.

N₁ (nombre maximal de serveurs par bande) = nombre de ports disponibles ÷ 2

Le nombre maximal de GPU dans la bande est calculé en multipliant simplement le nombre de GPU par serveur.

N2 (nombre maximal de GPU) = N1 (nombre maximal de serveurs par bande) * 8

Le nombre total de ports disponibles dépend du modèle de commutateur utilisé pour le nœud Leaf. Le tableau 15 en donne quelques exemples.

Tableau 15 : nombre maximal de GPU pris en charge par bande

Nœud Leaf Modèle du commutateur QFX	nombre de ports 400GE disponibles par commutateur	Nombre maximal de serveurs pris en charge par bande pour un abonnement 1:1 (N1)	GPU par serveur	Nombre maximal de GPU pris en charge par bande (N2)
QFX5220-32CD	32	32 ÷ 2 = 16	8	16 serveurs x 8 GPU/serveur = 128 GPU
QFX5230-64CD	64	64 ÷ 2 = 32	8	32 serveurs x 8 GPU/serveur = 256 GPU
QFX5240-64OD QFX5241-64OD	128	128 ÷ 2 = 64	8	64 serveurs x 8 GPU/serveur = 512 GPU

• Les commutateurs QFX5220-32CD sont équipés de 32 ports 400GE = > 16 ports pour se connecter aux serveurs et 16 pour les nœuds spine.
• Les commutateurs QFX5230-64CD offrent jusqu’à 64 ports 400GE = > 32 ports pour se connecter aux serveurs et 32 pour se connecter aux nœuds spine.
• Les commutateurs QFX5240-64OD offrent jusqu’à 128 ports 400GE = > 64 ports pour se connecter aux serveurs et 64 pour se connecter aux nœuds spine.

Pour obtenir des échelles plus grandes, plusieurs bandes (N₃) peuvent être connectées à l’aide d’un ensemble de nœuds Spine (N₄), comme illustré sur la Figure 20.

Graphique 20. Plusieurs bandes connectées sur les nœuds Spine

Le nombre de bandes requises (N₃ ) est calculé en fonction du nombre requis de GPU et du nombre maximal de GPU par bande (N₂).

Par exemple, supposons que le nombre requis de GPU (GPU) est de 16 000 et que la fabric utilise QFX5240-64OD comme nœuds Leaf.

Le nombre de ports 400G disponibles est de 128, ce qui signifie que :

• nombre maximal de serveurs par bande (N₁) = 64
• nombre maximal de GPU par bande (N₂) = 512

Le nombre de bandes (N₃) requis est calculé en divisant le nombre de GPU requis et le nombre de GPU par bande comme indiqué :

N ₃ (nombre de bandes requises) = GPU ÷ N ₂ (nombre maximal de GPU par bande) = 16000 ÷ 512 = 32 bandes (arrondi à l’unité supérieure)

• Avec 32 bandes et 64 serveurs par bande, le cluster peut fournir 16 384 GPU.

Connaissant le nombre de bandes requises (N ₃₎ et le nombre de ports de liaison montante par nœud Leaf (Y_), vous pouvez calculer le nombre de nœuds spine nécessaires.

Rappelez-vous X = Y = N1

Tout d’abord, le nombre total de nœuds feuilles peut être calculé en multipliant le nombre de bandes requises par 8 (nombre de nœuds feuilles par bande).

Nombre total de nœuds leaf = N₃ x 8 = 32 x 8 = 256

On peut alors obtenir le nombre total de liaisons montantes en multipliant le nombre de liaisons montantes par nœud Leaf (N₁₎ et le nombre total de nœuds Leaf.

Nombre total de liaisons montantes = N₁ x 256 = 64 x 256 = 16384

Le nombre de cœurs requis (N₄ ) peut ensuite être déterminé en divisant le nombre total de liaisons montantes par le nombre de ports disponibles sur chaque nœud Spine, qui, comme pour les nœuds Leaf, dépend du modèle de commutateur utilisé pour le rôle Spine.

Nombre de cœurs de réseau requis (N₄ ) = 16384 / nombre de ports disponibles sur chaque nœud de cœur de réseau

Par exemple, si les nœuds spine sont QFX5240/41, le nombre de ports disponibles sur chaque nœud spine est de 128.

Tableau 16 : Nombre de nœuds d’épines pour deux bandes.

Nœud Spine Modèle du commutateur QFX	Nombre maximal d’interfaces 400GE par commutateur	Nombre de cœurs de réseau requis (N4) avec 64 bandes
QFX5240-64OD	128	16384 ÷ 128 = 128
PTX10008 LC1201	288	16384 ÷ 288 ~ 57
PTX10008 LC1301	576	16384 ÷ 576 ~ 29

fabric back-end de stockage

La fabric back-end de stockage fournit l’infrastructure de connectivité pour que les périphériques de stockage soient accessibles à partir des serveurs GPU.

Les performances de l’infrastructure de stockage ont un impact significatif sur l’efficacité des workflows d’IA. Un système de stockage qui fournit un accès rapide aux données peut réduire considérablement le temps nécessaire à l’entraînement des modèles d’IA. De même, un système de stockage qui prend en charge l’interrogation et l’indexation efficaces des données peut minimiser le temps de prétraitement et d’extraction des caractéristiques dans un workflow d’IA.

Dans les petits clusters, il peut suffire d’utiliser le stockage local sur chaque serveur GPU ou de l’agréger à l’aide d’un logiciel open source ou commercial. Dans les clusters plus grands avec des charges de travail plus lourdes, un système de stockage externe dédié est nécessaire pour assurer la mise en relation du jeu de données pour l’ingestion et pour le point de contrôle du cluster pendant l’entraînement.

Deux plates-formes de premier plan, WEKA et Vast Storage, fournissent des solutions de pointe pour le stockage partagé dans les environnements GPU. Bien que nous ayons testé les deux solutions dans notre laboratoire, cette JVD se concentre sur la solution de stockage Vast. Ainsi, le reste de ceci, ainsi que d’autres sections de ce document, couvrira des détails sur les périphériques Vast Storage et la connectivité à la fabric backend de stockage.

Les détails sur le stockage WEKA sont inclus dans le réseau Datacenter IA avec Juniper Apstra, les GPU NVIDIA et le stockage WEKA - Conception validée Juniper (JVD).

La conception du fabric back-end de stockage de la JVD suit également une architecture IP Clos à 3 niveaux, comme illustré à la figure 21. Il n’existe pas de concept d’optimisation rail dans un cluster de stockage. Chaque serveur GPU dispose d’une connexion unique aux nœuds Leaf, au lieu d’une connexion par GPU.

Figure 21 : Architecture fabric backend de stockage

Le nombre de nœuds Leaf dépend du nombre de GPU de serveurs et de périphériques de stockage dans le cluster d’IA.

Le nombre de nœuds spine dépend du facteur d’abonnement souhaité pour la conception. Comme le fabric de back-end GPU, le fabric de stockage nécessite une conception sans surabonnement (facteur d’abonnement 1:1) afin de garantir une bande passante suffisante pour le trafic volumineux et d’éviter les congestion, les pertes de paquets et les latence excessives.

Le trafic de stockage peut utiliser différents mécanismes de transport, notamment NFS, POSIX et RoCEv2. Pour RoCEv2, les mêmes mécanismes d’équilibrage de charge et de classe de service que ceux décrits pour la fabric back-end des GPU doivent être implémentés. Ils sont décrits dans les sections Équilibrage de charge et Classe de service de ce document.

Les périphériques et la connectivité de la Storage Fabric validée dans cette JVD sont résumés dans les tableaux suivants :

Tableau 17 : Validation du stockage fabric nœuds leaf et spine

Modèle

Modèle de commutateur de nœuds leaf de fabric de stockage	de commutateur de nœuds spine de fabric de stockage
QFX5130-32CD	QFX5130-32CD
QFX5220-32CD	QFX5220-32CD
QFX5230-32CD	QFX5230-32CD
QFX5240-64OD	QFX5240-64OD

Tableau 18 : connexions validées entre les serveurs GPU, les périphériques de stockage et les nœuds Leaf dans la fabric de stockage

Liens par serveur GPU vers la connexion leaf	Type de serveur
1 x 100GE	nœuds C VAST
1 x 200GE	Serveurs GPU AMD MI300

Tableau 19 : connexions validées entre les nœuds leaf et spine dans la fabric de stockage

Modèle

Liens par connexion leaf et spine	Modèle de nœud leaf	de nœud spine
2 x 400GE, 3 x 400GE	QFX5130-32CD	QFX5130-32CD
2 x 400GE, 3 x 400GE	QFX5130-32CD	QFX5130-32CD
2 x 400GE, 3 x 400GE	QFX5240-32CD QFX5241-32CD	QFX5240-32CD QFX5241-32CD

Les tests de cette JVD ont été réalisés sur 4 serveurs GPU AMD Instinct MI300X et 8 périphériques de stockage VAST, connectés à 4 nœuds Leaf, eux-mêmes connectés à 2 nœuds Spine, comme illustré sur la Figure 22 :

Figure 22 : Topologie de test des JVD de la fabric de stockage

Tableau 20 : Nombre total de liaisons de stockage et bande passante testée

Serveurs GPU <=> nœuds leaf de stockage	nœuds leaf de stockage <=> nœuds spine front-end
Nombre total de liaisons 200GE entre Serveurs GPU et nœuds leaf de stockage = 4 (1 lien par serveur) + Nombre total de liaisons 100GE entre Vastes périphériques de stockage et nœuds leaf de stockage (2 liens par appareil) = 16	Nombre total de liaisons 400GE entre nœuds leaf et spine front-end = 16 (2 liens par connexion Leaf vers le cœur de réseau)
Bande passante totale = 2,4 Tbit/s	Bande passante totale = 6,4 Tbit/s
	Pas de surabonnement.

Mise à l’échelle de la fabric back-end GPU

La taille d’un cluster d’IA varie considérablement en fonction des exigences spécifiques de la charge de travail. Le nombre de nœuds dans un cluster d’IA dépend de facteurs tels que la complexité des modèles de machine learning, la taille des jeux de données, la vitesse d’entraînement souhaitée et le budget disponible. Le nombre varie d’un petit cluster de moins de 100 nœuds à un cluster à l’échelle d’un datacenter comprenant des milliers de nœuds de calcul, de stockage et de réseau. Un minimum de 4 spines doit toujours être déployé pour diversifier les chemins et réduire les chemins de défaillance des PFC.

Tableau 21 : Mise à l’échelle de la fabric - Dispositifs et positionnement

Mise à l’échelle de la fabric
Petit,	Moyen,	Grand
jusqu’à 4 096 GPU	jusqu’à 8 192 GPU	8192 et jusqu’à 73 728 GPU
Prend en charge jusqu’à 4 096 GPU avec Juniper QFX5240-64CD comme nœuds spine et QFX5230-64CD comme nœuds leaf (implémentations à une ou plusieurs bandes). Ce tissu ferroviaire à 3 étages se compose de 32 nœuds Spines et 128 nœuds Leaf, ce qui permet de maintenir un abonnement 1:1. La structure fournit une connectivité physique pour un maximum de 16 bandes, avec 32 serveurs (256 GPU) par bande, pour un total de 4 096 GPU.	Prend en charge plus de 4 096 GPU et jusqu’à 8 192 GPU avec Juniper QFX5240-64CD comme nœuds Spine et Leaf. Ce tissu sur rail à 3 étages comprend jusqu’à 64 épines et jusqu’à 128 nœuds leaf, ce qui permet de maintenir un abonnement 1:1. La structure fournit une connectivité physique pour un maximum de 16 Stripes, avec 64 serveurs (512 GPU) par bande, pour un total de 8 192 GPU	Prise en charge de plus de 8192 GPU et jusqu’à. 73 728 GPU avec Juniper châssis PTX10000 comme nœuds spine et Juniper QFX5240 à 64CD comme nœuds leaf. Ce tissu ferroviaire à 3 étages se compose de 64 épines et de 1 152 nœuds leaf, ce qui permet de maintenir un abonnement 1:1. La structure fournit une connectivité physique pour un maximum de 144 Stripes, avec 64 serveurs (512 GPU) par stripe, pour un total de 73 728 GPU.

Composants matériels et logiciels validés de la solution Juniper

Les produits et versions logicielles de Juniper répertoriés ci-dessous se rapportent à la dernière configuration validée pour le cas d’usage du datacenter IA. Dans le cadre d’un processus de validation continu, nous testons régulièrement différents modèles matériels et versions logicielles et mettons à jour les recommandations de conception en conséquence.

La version de Juniper Apstra dans le setup est la 6.1.

Le tableau suivant récapitule les appareils Juniper validés pour cette JVD et inclut les appareils testés pour le réseau de datacenter IA avec Juniper Apstra, des GPU NVIDIA et un stockage WEKA – Conception validée par Juniper (JVD).

Tableau 22 : Dispositifs validés et positionnement

	FABRIC FRONT-END DE L’APPAREIL		, GPU, FABRIC BACK-END, FABRIC DE		STOCKAGE
	FEUILLE	Colonne vertébrale	FEUILLE	Colonne vertébrale	FEUILLE	Colonne vertébrale
QFX5130-32CD	X	X			X	X
QFX5220-32CD	X	X	X		X	X
QFX5230-32CD			X		X	X
QFX5230-64CD			X	X	X	X
QFX5240-64OD			X	X	X	X
QFX5241-64OD			X	X	X	X
PTX10008 JNP10K-LC1201				X
PTX10008 JNP10K-LC1301				X

Le tableau suivant récapitule les versions logicielles testées et validées par rôle.

Tableau 23 : Version recommandée pour la plate-forme

Version

Rôle	de plate-forme	de Junos OS
QFX5240-64CD	Leaf back-end GPU	23,4 x 100 à D31
QFX5240-64OD/QD	Spine back-end GPU	23,4 X 100 À D42
QFX5220-32CD	Leaf back-end GPU	23,4 X 100 À D20
QFX5230-64CD	Leaf back-end GPU	23,4 X 100 À D20
QFX5240-64CD	Spine back-end GPU	23,4 x 100 à D31
QFX5240-64OD/QD	Spine back-end GPU	23,4 X 100 À D42
QFX5230-64CD	Spine back-end GPU	23,4 X 100 À D20
PTX10008 avec LC1201	Spine back-end GPU	23.4R2-S3
QFX5130-32CD	Leaf front-end	23.43R2-S3
QFX5130-32CD	Front-end Spine	23.43R2-S3
QFX5220-32CD	Leaf back-end de stockage	23,4 X 100 À D20
QFX5230-64CD	Leaf back-end de stockage	23,4 X 100 À D20
QFX5240-64CD	Leaf back-end de stockage	23,4 X 100 À D20
QFX5240-64OD/QD	Leaf back-end de stockage	23,4 X 100 À D42
QFX5220-32CD	Back-end de stockage au cœur de réseau	23,4 X 100 À D20
QFX5230-64CD	Back-end de stockage au cœur de réseau	23,4 X 100 À D20
QFX5240-64CD	Back-end de stockage au cœur de réseau	23,4 X 100 À D20
QFX5240-64OD/QD	Back-end de stockage au cœur de réseau	23,4 X 100 À D42