Les serveurs désagrégés
Dossier

Les serveurs désagrégés

Le 07-04-2018

Que faut-il penser de cette nouvelle architecture de serveurs, qui consiste à séparer les ressources de calcul (l’unité centrale), de la mémoire. D’où l’idée de serveurs désagrégés.

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 principe d’éclatement des ressources serveurs en blocs indépendants, qui communiquent par l’intermédiaire d’une matrice de commutation optique à très haut débit.

 

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 du comportement d’un serveur dont les bancs mémoire sont physiquement situés ailleurs. Les critères d’évaluation des temps d’accès et de traitement de la mémoire, ont été modélisés par l’équipe irlandaise du projet dRedBox.

 

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.

Si on considère comme acquis que l’éclatement des ressources peut effectivement améliorer les performances des applications et faciliter leur adaptation dynamique en fonction des besoins, grâce à une granularité réduite, rien ne dit que la « mayonnaise » va prendre.

Il s’en faut même de beaucoup et il y a encore de nombreuses inconnues avant que l’architecture devienne réalité chez les intégrateurs. Les exemples ne manquent d’ailleurs pas pour nous amener à faire preuve de prudence (PureSystems d’IBM). De sorte que l’on ne voit pas les architectures désagrégées déboucher avant 2022/2025.

Ceci d’autant plus que l’on n’est pas du tout certain d’atteindre les objectifs fixés et les promoteurs de dRedBox, ne manquent pas de rappeler que dans leurs simulations, ils se sont fondés sur des prérequis, dont rien ne dit qu’ils seront validés demain.

Cela dit, l’architecture est conceptuellement intéressante et si l’on arrive à contrôler techniquement les intermédiaires de commutation, elle pourrait devenir révolutionnaire. Non pas pour servir un PC dans notre living, mais pour équiper les datacenters et Clouds. Ce ne serait pas pour autant la fin du modèle de Von Neumann, puisqu’il y aura toujours la célèbre trilogie ALU, stockage et mémoire, mais bien le début d’une ère nouvelle dans laquelle la mémoire et le stockage ne pourront plus constituer un obstacle aux performances serveurs. On peut toujours rêver.

On ajoutera enfin que l’architecture ne semble pas adaptée à une infrastructure cluster, avec plusieurs processeurs, susceptibles de contribuer globalement à un même traitement, qu’il faut faire communiquer, entre eux et avec les bancs mémoire, dont on sait depuis les systèmes MIMD (Multiple Instruction Multiple Data) en mode mémoire partagée, toute la charge système d’intermédiation qu’ils peuvent représenter.

Les serveurs désagrégés

Les critères sont évalués de 1 à 5

Marché
Présence réelle sur le marché.
Usage
Intérêt potentiel, hors considérations commerciales
Standards
Niveau de standardisation du sujet
Coût
Intérêt potentiel, hors considérations commerciales
Futur
Niveau de crédibilité prévisible
Maturité
Niveau de maturité atteint actuellement
Abonnez-vous
  • Suivez LeMarson en direct
  • Accédez à des centaines de dossiers et d'articles
  • Visionnez des dizaines d'heures de formations vidéos
  • Téléchargez le Livre des tendances de l'année
Mensuel

$49.99


Facilitez-vous la vie avec un plan mensuel qui peut être annulé en quelques secondes.

Annuel

$449.99


Économisez 25%
sur le tarif mensuel.