FRnOG 38 - Xavier Le Vaillant : Disaggregation is the future of data centers
FRnOG 38 - Xavier Le Vaillant : Emergence of new technologies - an opportunity for modular and/or disaggregated systems - Disaggregation is the future of data centers
#HPC #Servers #datacenter #FRnOG
#HPC #Servers #datacenter #FRnOG
Transcript
00:00 Bonjour, Xavier Le Vaillant, 2CRSI.
00:03 Pour ceux qui ne connaissent pas 2CRSI,
00:06 c'est une société basée à Strasbourg.
00:09 On est fabricant de matériel informatique,
00:11 donc on fait des serveurs.
00:12 Plutôt orienté pour le calcul,
00:15 on fait notamment des solutions
00:17 qui s'adaptent à tous les types d'enfroidissement,
00:19 air, liquide, immersion.
00:21 Donc si vous avez des questions
00:22 sur comment plonger un serveur dans l'immersion,
00:24 on peut vous répondre.
00:25 Alors, petite anecdote,
00:28 c'est mon premier EFERNOG.
00:30 Je ne suis pas du tout un spécialiste, finalement,
00:32 de la partie réseau ou data center.
00:35 Je viens plutôt du monde du calcul,
00:38 et notamment du HPC.
00:40 Et... Comment dire ?
00:43 Là, je vais...
00:45 Je vais vous parler d'un sujet dont...
00:48 On ne l'utilise pas au quotidien, 2CRSI,
00:51 mais c'est quelque chose
00:52 qu'on regarde depuis plusieurs années maintenant.
00:54 Et je pense que c'est quelque chose
00:56 qui vous intéressera du point de vue du data center.
00:58 Donc on va parler des agrégations
01:00 et est-ce que ça est le futur
01:04 ou un des futurs du data center.
01:06 Alors, j'ai commencé par une news fracassante
01:11 de CRSI, où on vient de lancer
01:14 sa gamme de serveurs Mona.
01:17 Voilà, une belle boîte en serveurs 1U,
01:21 auquel on peut intégrer jusqu'à 32 serveurs haut de gamme.
01:26 Donc on est basé sur du processeur AMD,
01:29 des canaux mémoire qu'il en faut,
01:32 quelques slots PCI.
01:34 Alors, vous l'aurez bien compris,
01:37 il n'y a pas de secret, c'est une slide marketing.
01:40 Donc l'objectif de la slide, c'était
01:43 2 objectifs, faire plaisir au marketing
01:46 en annonçant la gamme Mona,
01:48 et aussi piquer un peu votre curiosité,
01:50 un serveur 1U ou pizza box, comme on les appelle,
01:53 intégrant 32 GPU, ça c'est jamais vu.
01:56 Donc, effectivement, ça manque un peu de contexte,
01:59 et j'aurais dû parler du premier système
02:03 permettant de supporter jusqu'à 32 GPU
02:05 au niveau d'un serveur.
02:07 En fait, la solution, elle est portée
02:09 par une société qui s'appelle GigaIO.
02:12 Alors, il en existe d'autres, mais je présente celle-ci
02:15 parce que c'est celle qui communique le plus,
02:17 ou sur laquelle on trouve le plus d'informations,
02:19 en tout cas, qu'on peut présenter.
02:21 Donc la solution se compose de Switch,
02:25 de boîtiers intégrant du stockage,
02:29 des accélérateurs ici qui sont des GPU,
02:32 et vous êtes raccordé finalement à quelques serveurs.
02:36 Donc ici 1, ce serveur pouvant être un Mona,
02:39 si vous le souhaitez.
02:42 À votre droite, vous trouvez, par exemple,
02:45 alors je ne suis pas sûr que ça se voit très bien à l'écran,
02:47 mais un terminal où on a listé finalement les 32 GPU
02:51 qui sont des AMD M200, dans ce cas-là.
02:55 Et ils sont vus de manière native au niveau d'un seul hôte.
03:00 Donc la société a publié quelques résultats,
03:03 notamment sur des benchmarks, que ce soit de l'IA ou de la CFD.
03:07 Les résultats sont plutôt intéressants,
03:10 mais je vous laisserai aller les consulter
03:12 si vous avez des avis.
03:15 Je ne vais pas faire plus de publicité,
03:17 tant qu'à présent.
03:19 On peut quand même se demander pourquoi
03:22 on va aller jusqu'à mettre 32 GPU pour un serveur.
03:28 Donc avant de parler un peu des agréations,
03:32 on va parler pourquoi tous ces GPU.
03:35 Alors bien avant, finalement,
03:37 chaque GPT et le phénomène IA génératif,
03:40 la communauté du HPC s'intéressait aux GPU
03:44 pour ses besoins de simulation numérique.
03:48 Et en effet, les centres de calcul,
03:51 que ce soit les petits comme les très très gros,
03:54 s'attachent à offrir le plus de performances possible
03:57 à ses utilisateurs, et ça de manière continue,
04:01 tout en respectant certaines contraintes,
04:05 que ce soit techniques ou financières.
04:08 Et à partir de 2005, on a vu arriver les GPU de Nvidia, notamment,
04:13 qui ont permis de faire des bons en termes de performances,
04:19 et depuis lors, leur adoption n'a cessé de croître.
04:23 Ces dernières années, on a vu aussi apparaître
04:27 d'autres types de GPU que ceux de Nvidia ou de AMD,
04:31 on va appeler ça accélérateurs,
04:34 puisqu'ils couvrent à la fois ce qu'on appelle des FPGA,
04:38 on peut les appeler IPU, suivant les gars.
04:42 Et voilà, tous ces accélérateurs ont pour but
04:45 de fournir de la performance et de l'efficacité.
04:49 Certains sont designés pour permettre de...
04:53 pour gagner spécifiquement en efficacité
04:56 sur certains domaines d'application,
04:59 et ces domaines d'application ont, on va dire,
05:05 tout intérêt à utiliser ce type d'équipement
05:10 pour pouvoir continuer à progresser en termes d'efficacité
05:13 sur le long terme.
05:15 Alors, ces équipements, qui sont des accélérateurs
05:19 en format PCI, vous pouvez aussi en trouver
05:23 au format beaucoup plus spécialisé en termes de grosse boîte,
05:26 ici, comme un DGX de chez Nvidia,
05:29 ou alors une Illex de chez Cerebras,
05:32 ou encore Tsambanova, là, on parle de systèmes
05:35 à très grande taille, quand même.
05:39 Et par contre, qui ont, selon moi,
05:42 des usages très bien qualifiés et assez bien définis,
05:45 et qui ne vont pas forcément correspondre
05:48 à tous les usages qu'on va attendre dans un data center.
05:51 Et ni de la part des utilisateurs, dans mon cas, côté HPC.
05:57 Ce qu'attendent finalement les utilisateurs,
06:03 c'est que la plateforme s'adapte un peu à leurs besoins.
06:06 Prenons le cas d'université,
06:09 j'ai plusieurs groupes de chercheurs, chacun dans leur domaine
06:12 a des besoins spécifiques en termes d'unités de calcul,
06:16 de mémoire, de stockage,
06:19 mais en termes de gestion hardware, je ne vais pas être en mesure
06:23 de fournir toutes les variantes possibles à mes utilisateurs.
06:26 Donc l'idée, c'est de trouver un moyen
06:29 de distribuer ou de générer, finalement,
06:36 un hardware en fonction de mon cas d'usage.
06:39 D'utiliser toutes les ressources les plus adaptées à mon besoin,
06:45 et de pouvoir grossir en fonction de si j'ai besoin du stockage,
06:50 d'accélérateur, d'autre chose.
06:54 Et c'est là que vient se glisser la notion
06:57 d'infrastructure composable des agrégés.
07:00 Alors, j'utiliserai l'acronyme CDI
07:04 pour la simplicité.
07:07 Alors, le terme des agrégations, il n'est pas nouveau
07:11 dans les centres de données.
07:13 Il y a un certain nombre de fabricants
07:15 qui cherchent à exploiter ce concept-là
07:17 depuis maintenant un certain temps.
07:19 Au niveau du stockage, ça existe.
07:22 Finalement, le Fiber Channel, c'en est un.
07:25 Maintenant, avec les NVMe et les NVM overfabric,
07:28 c'est aussi de la désagrégation.
07:31 L'idée ici, c'est de pousser le concept plus loin
07:37 et d'appliquer la désagrégation à d'autres composants,
07:42 que ce soit l'unité de calcul, la mémoire, le stockage,
07:45 les accélérateurs.
07:48 Donc là, on peut parler maintenant
07:51 de Software Defined Hardware.
07:53 Ça peut paraître étrange, mais c'est le but recherché.
07:58 Alors, je vais prendre un exemple.
08:00 En fait, c'est le cas d'usage qui reflète
08:04 la solution de Jigaeo qui était présente
08:06 à la deuxième slide.
08:08 Considérons un rack avec ici trois serveurs,
08:12 chacun constitué d'un CPU de la mémoire.
08:16 À l'intérieur, j'ai intégré un GPU, un NVMe,
08:20 et j'y ai aussi attaché ce que je vais appeler J-Bog,
08:24 qui est un boîtier d'extension PCI
08:28 où j'ai intégré plusieurs GPU.
08:31 Et de la même façon,
08:33 j'ai connecté un boîtier d'extension
08:37 avec du NVMe que j'ai appelé J-Bog.
08:40 Donc, assez simplement, on peut considérer que...
08:44 Alors, juste là aussi,
08:47 les serveurs sont connectés à un ou plusieurs réseaux.
08:50 Ici, Internet ou InfiniBand,
08:52 mais je parle vraiment d'un réseau où je vais transporter de la donnée,
08:56 pas forcément la partie administration.
08:59 Et finalement, ces trois serveurs
09:03 peuvent être vus comme des ILO, de ressources de calcul,
09:07 pour lesquelles j'utilise le réseau
09:09 pour faire des échanges de données.
09:13 Alors, si je rajoute un peu de complexité
09:17 et que je mets un switch intégrant,
09:20 par exemple, un switch PCI à l'intérieur,
09:23 je vais pouvoir déporter, par exemple,
09:26 certaines de mes extensions de stockage
09:30 et de GPU, d'accélérateur.
09:33 Je vais pouvoir faire un certain assignement
09:37 tel que présenté, où j'ai mis une J-Bog,
09:41 deux J-Bof au premier serveur, etc.
09:44 Par contre, il y a plusieurs défauts
09:48 à ce type de solution, de configuration.
09:51 Les GPU et NVMe qui sont intégrés physiquement dans les serveurs
09:55 ne sont toujours pas accessibles aux autres unités de calcul,
09:58 aux autres serveurs, pour être générique.
10:01 Chaque J-Bof et chaque J-Bog agit finalement comme une ressource unique.
10:06 Je ne peux pas utiliser indépendamment
10:09 les NVMe ou les GPU qui sont compris dans ces boîtes
10:12 de façon indépendante.
10:15 Et mes serveurs ont toujours besoin de se reposer
10:19 sur un lien réseau Ethernet infini-bande
10:22 pour s'échanger des volumes de données.
10:25 Les solutions actuelles de fabriques réseau-PCI
10:30 telles que celles de GigaIO ou Liquid, par exemple,
10:34 qui sont aujourd'hui les plus avancées,
10:37 je vais dire ça comme ça,
10:41 répondent ou arrivent à résoudre ces trois défauts.
10:45 Déjà, si on veut profiter pleinement de la composabilité,
10:51 il faut transformer ces J-Bog et ces J-Bof en serveurs.
10:56 Dans le sens où ça implique d'avoir
11:00 ce qu'on appelle le root complexe processor dans ces boîtiers
11:04 avec l'objectif d'énumérer toutes les devices PCI
11:09 de chaque boîtier et de les présenter aux contrôleurs de la fabrique.
11:14 Afin qu'ils puissent faire un mapping complet
11:17 et il leur charge après de router
11:21 les communications entre les devices.
11:25 Cette configuration autorise notamment
11:29 les communications entre les devices PCI,
11:33 que ce soit les GPU à travers du protocole GPU direct
11:37 ou les NVMe à travers le protocole NVMe overfabrique.
11:42 Ces deux voies de communication utilisent ce qu'on appelle
11:45 les opérations DMA, direct memory access,
11:48 et qui n'impliquent pas du tout les CPU.
11:51 Par ailleurs, cette configuration permet aussi
11:54 à deux CPU de communiquer ensemble,
11:57 dans deux boîtiers différents.
12:02 Si bien que vous l'aurez constaté,
12:08 on a supprimé la partie réseau Ethernet infini-band
12:12 qui n'était plus nécessaire pour faire communiquer mes serveurs
12:15 au niveau de transfert de données.
12:17 Je m'entends qu'au niveau de l'administration, on en aura encore besoin.
12:22 Tous ces transferts de données se font à la vitesse native du PCI,
12:27 dépendant forcément de la génération des équipements.
12:31 Aujourd'hui, on l'a vu dans l'exemple,
12:35 on arrive à connecter des CPU avec des devices PCI,
12:41 que ce soit des GPU, ça peut être autre chose, des NIC, bref,
12:46 des serveurs entre eux, ou même des GPU entre eux.
12:52 Mais pour arriver à un système complètement désagrégé,
12:55 il manque quand même un élément majeur, c'est la mémoire.
12:59 Au niveau de la mémoire, il y a quelques challenges à l'horizon,
13:05 avec notamment la décroissance de la bande passante mémoire par cœur,
13:09 un gap entre la mémoire qui est rattachée au CPU,
13:17 soit de manière très proche ou en DRAM,
13:19 par rapport aux latences des SSD et stockage similaire,
13:24 le coût des mémoires pour arriver à ce type de densité,
13:28 l'optimisation des ressources que j'ai intégrées dans toutes mes boîtes,
13:37 un besoin de décorréler la mémoire,
13:41 de trouver de nouvelles architectures pour adresser ces challenges
13:46 au niveau de la consommation de mémoire.
13:48 C'est là qu'entre en jeu CXL.
13:51 C'est une norme ouverte
13:56 qui vise à l'interconnexion cohérente du cache
14:00 entre les processeurs, les accélérateurs, ou GPU,
14:03 les différents périphères intelligents du type DPU ou le stockage, la mémoire vive.
14:07 Au départ, c'était un projet piloté par Intel,
14:12 et en 2019, il est passé sous la tutelle du CXL Consortium,
14:20 qui finalement regroupe toutes les entreprises
14:25 qui s'intéressent de près ou de loin au micropus.
14:28 Il y a toute une industrie qui supporte cette norme.
14:32 Les premières itérations du protocole CXL
14:36 se concentrent sur la mémoire, sur la mémoire assez proche du CPU.
14:41 Juste pour la compréhension,
14:46 aujourd'hui, si on prend un serveur classique avec deux CPU de la RAM attachée,
14:52 la latence pour le CPU de gauche d'accéder à la RAM du CPU de droite
14:59 est de l'ordre de 180 ns.
15:01 L'objectif avec le CXL 1.1
15:08 est que ce CPU puisse accéder à de la mémoire CXL
15:14 avec la même ordre de grandeur ou une latence sensiblement équivalente.
15:21 Suivant la littérature, on y est,
15:27 et il nous reste encore un peu de travail.
15:31 C'est l'objectif.
15:34 Une chose intéressante, c'est que la partie CXL
15:39 a déplacé la mémoire derrière un contrôleur
15:42 qui nous permet aussi d'adresser différents types de mémoire.
15:46 Dans l'objectif de la norme CXL, il y a plusieurs étapes.
15:55 Aujourd'hui, on est au CXL 1.1 comme explicité
16:01 puisque c'est la norme que supportent les derniers processeurs,
16:05 que ce soit Intel ou AMD.
16:07 Mais les normes à venir, que ce soit CXL2 ou CXL3.0,
16:13 permettent d'étendre la portée et la façon d'accéder à ces mémoires
16:17 qui soient distantes ou partagées entre les autres.
16:21 Il y a déjà des sociétés qui sont plus que prêts pour le CXL2
16:24 qui ont des boîtiers sur lesquels vous pouvez vous connecter
16:27 de manière distante, partagée.
16:29 Certaines sont déjà prêtes au niveau logiciel à surcharger le CXL2
16:34 pour avoir une cohérence de cache entre différentes hôtes
16:38 et finalement supporter presque la norme 3.0
16:40 alors qu'elle n'est pas encore écrite.
16:42 Il y a tout un pan de l'industrie qui travaille là-dessus.
16:48 CXL va aussi pouvoir combler un gap qui existe aujourd'hui
16:53 entre la mémoire qui est attachée au chip,
16:57 que ce soit de la mémoire HBM ou de la DRAM,
17:00 par rapport au SSD, évidemment.
17:04 On va avoir toute une étagère de composants de mémoire CXL à venir
17:11 avec différents niveaux de performance en termes de latence
17:14 et ça va induire finalement un système de tearing
17:19 comme on l'a vu pour le stockage.
17:21 Donc là aussi, toute l'industrie au niveau logiciel s'engouffre sur ce point
17:26 pour être prête à en tirer les avantages quand ce sera prêt.
17:29 Il me reste ? C'est déjà fini.
17:32 Finalement, le CXL ou PCI repose sur une fabrique.
17:38 Ici, c'est le CXL switch, mais derrière, il y a une fabrique.
17:43 Certains voient même cette fabrique comme étant la seule fabrique à l'échelle du rack.
17:47 Tout à l'heure, j'ai supprimé la partie Ethernet InfiniBand
17:50 parce que certains y voient déjà que ce ne sera plus le canal utilisé
17:54 pour le transfert de données.
17:57 Le CXL nécessitera forcément de la fibre,
18:03 au vu des caractéristiques du câble cru,
18:06 en termes de propagation ou de taille.
18:10 On sera forcément sur de la fibre optique,
18:12 mais même là, juste sur un test du SuperNode,
18:17 avec finalement très peu de GPU,
18:19 l'armoire est déjà saturée.
18:22 Donc on en sera forcément là.
18:25 On a facilement fait la partie extension,
18:30 boîtier d'extension avec des GPU qui étaient en nombre limité.
18:34 Là, pour le coup, il y en avait un.
18:36 On a créé une fabrique PCI,
18:38 avec laquelle on est arrivé jusqu'à 32 GPU.
18:41 Cela permet une certaine flexibilité.
18:44 Par contre, pour aller au-delà,
18:47 certains imaginent même pouvoir connecter
18:49 jusqu'à 200 GPU sur un seul serveur.
18:52 Il y a toute une réflexion et toute une architecture
18:55 au niveau de la fabrique elle-même,
18:57 qui ne sera sans doute ni PCI ni CXL,
19:00 mais qui fera l'interface entre ces protocoles-là
19:03 pour supporter ces GCL.
19:05 Il y a donc plein d'avantages à la déségregation,
19:08 à la composabilité,
19:10 de l'argent, de l'optimisation,
19:14 des cycles de vie des produits.
19:17 Mais il y a beaucoup d'interrogations
19:19 sur comment j'opère, c'est quoi les performances,
19:22 quels impacts sur mes applications.
19:25 - Super, merci.
19:28 J'ai une question.
19:30 On voyait un switch dans un de test-slide.
19:35 C'est quel genre de switch ?
19:37 C'est du 48 ports 800 Gigs ?
19:41 Il faut à la fois beaucoup de débit, de bonne latence ?
19:46 - Je ne sais pas si on voit bien.
19:49 Là, si on voit bien.
19:51 Là, il y a 24 ports qui sont des PCI par 4.
19:55 A chaque connectique, il y en a un PCI par 4.
19:58 Donc si on veut profiter d'un PCI par 16, d'un GPU,
20:01 on doit déjà mettre 4 câbles.
20:04 - Mais quelle génération ?
20:06 - Là, c'est 4.
20:08 Donc ça fait...
20:10 On est largement...
20:12 On est à combien ?
20:15 Je ne sais plus.
20:17 - Là, une PCI G4.
20:19 Ça parle à quelqu'un.
20:21 - J'ai un trou.
20:23 - 16 Giga.
20:26 - Merci.
20:28 - Pour faire 4, ça fait 4 fois 64.
20:31 Donc on est sur du 400 G par port.
20:34 Quelque chose comme ça.
20:36 Ça va être des switches qui...
20:39 - Oui.
20:41 Je pense qu'à l'intérieur du boîtier GigaIO,
20:44 il y a du micro-Semi.
20:46 Je pense que c'est...
20:48 Le papier technique est publié chez eux, par exemple,
20:52 pour trouver quel type de switch...
20:54 Ça peut être un switch, parce que c'est plus intelligent que ça.
20:57 Qu'ils utilisent.
20:59 - Super. Merci.
21:01 (Applaudissements)