Oracle adapte son réseau pour gérer des HPC de plus de 130 000 GPU

Toujours plus de GPU AMD et Nvidia

Une plateforme AMD Instinct 355X

Il vient aussi d’annoncer la disponibilité générale des instances Bare Metal incluant les GPU AMD Instinct MI355X. 131 072 GPU (64 cartes MI355X par rack) propulseront un supercluster dédié. Avec AMD, Oracle fournira un supercluster de 50 000 GPU de la série Instinct MI450 au troisième trimestre 2026, qu’il agrandira en 2027 « et au-delà ».

Oracle mise sur deux fournisseurs principaux en la matière. Il ne prévoit toutefois pas de développer ses propres puces, contrairement à ses concurrents.  

« Notre rôle consiste à nous assurer que les clients disposent de ce dont ils ont besoin en matière de GPU », affirme Karan Batta, vice-président senior Oracle Infrastructure Cloud.

Il répond là à une question du MagIT concernant la manière dont Oracle gère le manque de GPU disponible sur le marché.

« C’est un sujet beaucoup plus complexe qu’il n’y paraît. Tout le monde se concentre actuellement sur les GPU, mais tous les autres éléments sont importants », ajoute-t-il. « Vous pouvez avoir plus de GPU que nécessaire, mais vous risquez alors de manquer d’espace et d’alimentation électrique. Vous pourriez ne pas avoir suffisamment d’optiques ou de câbles. Vous pourriez déployer un centre de données au milieu de nulle part. Mais vous avez besoin d’une connectivité réseau, vous avez besoin de stockage », liste-t-il.

Acceleron : un Network Fabric pour former un méta-cluster de GPU

En ce sens, le fournisseur présente Acceleron, une architecture réseau RoCe (RDMA over Ethernet) spécifique à Oracle.

Acceleron est « une combinaison de nos logiciels et de notre architecture pour sécuriser et accélérer l’ensemble de nos entrées-sorties (I/O) », affirme Clay Magouyrk, co-CEO d’Oracle. « Elle comprend un réseau Fabric dédié, des cartes d’interfaçage réseau (NIC) convergées, un routage de paquets zéro confiance au niveau de l’hôte et une conception multiplanaire pour améliorer les performances et la disponibilité ».

Dans les HPC, Acceleron doit en premier lieu surmonter les limites des réseaux Clos à trois étages. Cette terminologie décrit une architecture où une colonne de switch centrale est à la fois reliée aux sources de données et aux destinations. Cette topologie doit réduire le nombre d’interconnexions, améliorer la parallélisation des traitements GPU, ainsi que l’efficacité du transfert des données entre le GPU et l’espace de stockage. Selon les ingénieurs d’Oracle, cette topologie supporte bien les superclusters de 130 000 GPU que le fournisseur a déjà déployés.

Or, l’architecture de réseau Clos à 3 étages présente des limites en matière de consommation énergétique et de robustesse du réseau. Plus particulièrement, elle implique de multiplier les switchs, de faire courir des kilomètres de câbles et augmente la latence.

Le réseau Clos à 3 étages mis en place par Oracle interconnecte l’ensemble des NICs clients. Pour aller au-delà des 130 000 GPU, le fournisseur déploie des Network Fabrics « disjoints » – les fameux plans. Chaque plan isolé se connecte à un seul NIC client. « Il y a un petit commutateur dans les NIC les plus récents qui permet à un serveur de faire sortir des données à travers le NIC qui les redistribuent vers quatre switchs différents », explique David Becker, expert réseau chez Oracle, dans une vidéo publiée en marge d’Oracle AI World. À l’inverse, chaque NIC client peut être connecté à quatre plans de ce réseau multiplanaire.

Chaque plan est lui-même architecturé comme un réseau Clos à deux étages. La carte réseau devient un des étages.

Et en ajoutant des plans, la mise à l’échelle est plus aisée. De plus, chaque plan a son propre control plane et data plane. En cas de panne qui affecterait un plan, les autres ne seraient pas affectés. Le trafic peut être automatiquement rerouté à un plan par le firmware du NIC et/ou d’autres éléments logiciels.

Comme ce nombre de ports sur un switch peut limiter la mise à l’échelle, les ingénieurs d’Oracle augmentent le « radix », le degré de connectivité du commutateur (switch) et des NIC. Pour cela, Oracle utilise des breakouts, c’est-à-dire des adaptateurs qui permettent de subdiviser un port Ethernet 400G ou 800 G en plusieurs ports plus petits, tout en divisant la bande passante équitablement par port. Physiquement, une telle approche réclame bien plus de fibre optique en plus de gérer la complexité du câblage. « Nous avons dû proposer une solution de câblage inventive pour connecter les breakouts des switchs et des NIC. Nous l’appelons “shuffle cables” », décrit David Becker. Les brins de fibres nécessaires aux interconnexions entre les deux types d’équipements sont réunis entre les breakouts pour réduire le nombre de câbles. In fine, un seul câble rassemble quatre breakouts à chaque extrémité.

Les DSP, censés réduire les interférences entre les switchs et les NIC sont supprimés. Leurs capacités de stabilisation et de nettoyage du signal de la fibre optique sont désormais prises en charge par les logiciels des « Smart NIC ». Cette approche nommée Linear Pluggable Optics (LPO) permet d’éliminer les ASICs qui propulsent les DSP et leurs ventilateurs. Cela réduirait d’environ 30 % la consommation du lien fibré. Ces gains ainsi que ceux obtenus en supprimant certains switchs permettraient d’allouer davantage de puissance aux GPU.

« Ce concept s’appelle la désintermédiation », affirme Clay Magouyrk. « C’est en réalité assez difficile à mettre en œuvre. Pour cela, il faut disposer d’une architecture logicielle très flexible qui permette de déplacer de manière transparente les fonctions réseau d’un endroit à un autre », poursuit-il lors de son keynote. « Nous y travaillons depuis des années et cette technologie est déjà déployée sur bon nombre de nos différents systèmes réseau. Le résultat net est une réduction significative des coûts ».

Le revers de la médaille de l’approche LPO, c’est qu’elle réintroduit de la latence. Ce n’est pas le plus important avec les GPU, dont le principal est de fournir des transferts de données très haut débit, selon Karan Batta.

« Nous sommes désormais en mesure de disposer de clusters GPU répartis dans plusieurs bâtiments différents et de les connecter entre eux comme s’il s’agissait d’un seul et même cluster », traduit-il, lors d’un briefing presse. « Ainsi, des clients tels qu’OpenAI ou d’autres peuvent exécuter une seule tâche d’entraînement qui s’étend non seulement aux GPU, disons dans cette salle, mais aussi à un autre bâtiment ».

« Finalement, tout le monde achète les mêmes GPU. Ce qui va vraiment faire la différence, c’est l’échelle, mais aussi la disponibilité et le fonctionnement », poursuit-il.

Un effort apprécié par OpenAI. « Vous nous aider à pousser des acteurs plus traditionnels à être plus flexible, vous codéveloppez avec nous, vous faites des compromis tels que le système multiplanaire », liste Peter Hoeschle, vice-président stratégie et opérations d’infrastructure chez OpenAI, lors d’un keynote.

Les NIC clients sont indifféremment ceux proposés par Nvidia (Spectrum-X, par exemple) et AMD (Pensando Pollara 400 AI). « Nous prenons en charge la plupart des NIC clients du marché. Notre architecture est interopérable », affirme Karan Batta.

Améliorer la sécurité et les performances du stockage NVMe

Mais Acceleron ne profitera pas qu’à OpenAI. Ses capacités sont adaptées pour d’autres usages, selon Oracle.

Avec Acceleron, le NIC hôte, le plane client et le control plane cloud sont physiquement sur la même puce, mais sont partitionnés en dur, isolés. Une interface Ethernet sous la forme d’un canal léger « on die » permet les échanges entre les deux pôles. Contrairement au système majoritairement déployé par Oracle avec son infrastructure Gen2, la gestion des paquets à travers MAC/PHY ne dépend pas d’équipements séparés. Le tout se fait à même le Smart NIC.

« La carte réseau convergée Oracle Acceleron permet également une configuration automatique et sécurisée pour la présentation native des périphériques NVMe aux volumes en bloc OCI, ce qui profite directement aux charges de travail des clients dans les environnements à forte intensité I/O », assure un porte-parole d’Oracle.

Cela doit aussi améliorer Zero Trust Packet Routing (ZPR). C’est un moyen pour protéger les accès réseau non autorisés à travers des attributs – des règles – spécifiques. ZPR complète les groupes de sécurité réseau et les listes de contrôle de sécurité avec des règles exprimés à l’aide d’un DSL (ZPL) dont les attributs sont très simples à comprendre et décrits en langage naturel. Un moteur de règles compile ces intentions dans les règles qui protègent les accès à une application et au service Exadata sous-jacent (par exemple). Outre de nouvelles fonctionnalités pour mieux inspecter les paquets, protéger les déploiements multi-VCN, les MySQL et Oracle Database, l’ajout de politique de refus d’accès au niveau du IAM, les règles exprimées à travers le DSL sont désormais appliquées au niveau du NIC hôte.

La disponibilité des technologies Acceleron est progressive. Certaines d’entre elles sont déjà disponibles, d’autres seront déployées au fil de l’eau dès 2025, indique Karan Batta.