C’est IBM qui a mis le feu aux poudres. Lors de la conférence « High Performance and Embedded Architecture and Compilation » (HIPEAC) de 2017, le constructeur a présenté un projet particulièrement novateur, dRedDBox, une initiative de la Communauté Européenne, prise dans le cadre du programme d’innovation et de recherche à horizon 2020.

A vrai dire, le concept de désagrégation des serveurs n’est pas nouveau et Intel depuis près de dix ans, milite sur le sujet, partant du principe qu’il y a de fortes motivations à imaginer un nouveau modèle d’architecture serveur, comme l’amélioration des performances, un meilleur contrôle de la consommation d’énergie et la réduction de cette consommation, mais aussi la diminution des efforts de migration, avec une granularité plus fine des éléments de configuration, quand on veut augmenter les ressources serveurs, que l’on va rendre plus dynamiques et enfin, permettre à une application d’accéder à un volume mémoire plus important.

Mais attention, ce n’est pour l’instant qu’une tendance et s’il existe des projets chez IBM, Intel, HPE et Cisco, cela ne veut pas dire que tous les datacenters de la planète vont être impactés par cette nouvelle organisation.

Séparation des briques de serveurs

En termes d’architectures, plutôt que de considérer un serveur comme un bloc monolithique, constitué d’une unité de traitement, de moyens de stockage, d’une mémoire et d’interfaces de communications réseaux, on peut le considérer comme l’assemblage de ces ressources, sans obligation de les placer physiquement au même endroit et faire en sorte qu’elles soient partageables et communicantes. Car si le projet dRedBox suivi par IBM Irlande, ne concerne pour l’instant que la dissociation de la mémoire, rien n’empêche sur le principe de faire le même raisonnement pour chacune des briques du serveur. C’est d’ailleurs plutôt dans cette direction que se dirigent HPE et Cisco.

L’objectif affiché par ces architectes « avant gardistes », est d’imaginer une organisation Cloud ou datacenter, dans laquelle les processeurs de traitement se partageraient d’énormes blocs de mémoire (dans un premier temps), qu’ils utiliseraient sans contraintes, ni limites et ne feraient « payer » qu’à la consommation.

Le principal écueil de cette architecture est le lien de communication entre les briques de traitement clientes et les briques de services, mémoire et stockage.

Et ici tout dépendra de la bande passante accessible par les clients et la vitesse de commutation de la matrice intermédiaire. L’objectif étant d’obtenir les mêmes performances que pour un système local. Tout en bénéficiant des avantages de l’éclatement, tels que ceux indiqués précédemment.

La simulation des accès mémoire désagrégée

L’équipe dRedBox a effectué diverses simulations et modélisé les éléments qui contribuent à ce que le temps de réaction des briques mémoires éloignées, soit bon ou mauvais.

Il s’agit par exemple du temps nécessaire pour qu’un client (ressource de calcul) prépare une requête à destination de la mémoire et l’encapsule dans une trame. Il s’agit aussi du temps nécessaire pour que le banc mémoire traite la requête en question et de la durée pour la traiter, voire en sens inverse des temps nécessaires pour retourner les résultats aux clients demandeurs.

Elle a également suggéré un ensemble de formules qui tiennent compte de ces paramètres et effectué les mesures en faisant varier les critères de base : bande passante en Gbps, temps de préparation des requêtes, exprimé en cycles, entre autres.

Elle a ainsi pu montrer que le critère le plus important est sans équivoque le temps de préparation des requêtes : pkPrep, directement lié au nombre de blocs de traitement qui vont jouer un rôle dans la file d’attente des requêtes, prêtes à être traitées, mais aussi au nombre de « cores » des clients de traitement et à la présence d’unités dédiées à cette préparation, les FGPA.

En combinant ensuite les valeurs de pkPrep et de bande passante, l’équipe a appliqué le modèle à quatre applications tests et a montré que la charge système (overhead) liée à un pkPrep de 300 cycles pouvait atteindre 66,88 % du total, au moins pour l’une des applications.

Bien entendu, il ne faut pas accorder trop d’importance à ces chiffres, qui n’ont d’intérêt que de montrer où se trouvent les points d’achoppement d’une architecture désagrégée. Ce qui n’est déjà pas si mal…

Ils ont aussi l’intérêt de montrer qu’il ne faut pas se faire trop d’illusions et que les 25 à 50 % de gains annoncés par les « pionniers » sur l’exécution des charges de travail, ne sont sans doute pas pour demain.

Les projets concrets

C’est ce que proposent de faire les participants européens du projet dRedBox, menés par IBM Irlande, qui ont conçu une architecture avec des unités centrales dotées de processeurs SoC et d’interface FGPA, qui communiquent avec des briques de mémoires à hautes performances, via une matrice de commutation optique, capable d’atteindre un débit de 200 Gbps, pour une latence inférieure à 10 nsec. Côté processeurs, ce sont les interfaces FGPA qui « fabriquent » les paquets à destination de la mémoire, ceux-ci étant pris en charge par la matrice de commutation et acheminés à la bonne brique mémoire.

L’architecture mise en place comporte une pile logicielle d’orchestration des ressources et a nécessité une modification de l’OS, pour lui permettre de prendre en compte les briques de mémoire éloignées.

Selon les promoteurs IBM du projet, les résultats ont été spectaculaires, qui ont permis d’améliorer par un facteur 2,5 le comportement général de la mémoire, avec des temps de réponse améliorés de 10 %, comparativement à un système traditionnel équivalent, doté d’une mémoire locale dédiée.

Pour ce qui est du principal inconvénient de ce type d’architecture, la charge système induite par l’éloignement de la mémoire, il n’a été que de 3 %, essentiellement pour créer de nouvelles machines virtuelles dans les briques mémoires éloignées.

Apparemment, tout est donc parfait dans le meilleur des mondes.

Sauf, que les mêmes acteurs du projet se sont livrés à des simulations poussées et ont modélisé l’interface entre les clients et les briques de mémoire (ici). D’où il ressort que rien n’est acquis, car pour rester dans les mêmes eaux de performances que celles annoncées, il va falloir améliorer certains aspects de cette interface : la possibilité d’émettre simultanément avec des bandes passantes différentes et surtout un nouveau protocole de « packetisation », pour réduire au maximum la latence induite par l’interface de communication optique.

D’autres projets ont été lancés qui vont dans le même sens de la désagrégation.

Le projet de recherche « The Machine » d’HPE était à l’origine destiné à concevoir une machine  motorisée avec 160 TB de mémoire. Mais ce projet a dérivé et prend également en compte l’éclatement de ces ressources mémoire. Il rejoint donc dans l’esprit les travaux d’IBM Irlande.

Chez Intel, le projet RSD (Rack Scale Design) s’est fortement orienté vers l’accès à des moyens de stockage éloignés et pas vers une mémoire éclatée. Intel a également conçu une API, dite Redfish, pour permettre aux développeurs d’imaginer des applications adaptées et d’exploiter le concept d’éloignement du stockage. C’est la même API qu’Intel espère voir adopter par d’autres fournisseurs pour assurer l’interopérabilité de leurs solutions avec la sienne, celle de l’US Department Energy, par exemple et son Exascale Computing Project.