Stockage : Pliops adapte sa carte accélératrice aux applications
La carte XDP se contentait jusqu’ici d’offrir une accélération brute aux SSD. L’arrivée de nouveaux services de stockage dans son firmware démultiplie les performances selon les usages, mais les applications doivent utiliser son API.
Pliops, la startup israélienne qui veut piloter les SSD NVMe comme on pilotait autrefois les disques SCSI – avec une carte contrôleur dédiée – spécialise à présent son produit par application. Il existe désormais une carte contrôleur XDP-AccelKV qui accélère par 20 les accès des bases de données NoSQL qui se basent sur des moteurs de type Key-Value, par exemple RocksDB. Mais aussi une carte XDP-RAIDplus qui fait du RAID 5 sans consommer d’espace de stockage pour la redondance. Et puis une carte XDP-AccelDB qui multiplie par trois les accès des bases SQL et leur apporte six fois plus d’espace de stockage grâce à une compression à la volée.
« Pour être tout à fait honnête, il s’agit de la même carte à chaque fois : notre carte XDP qui est équipée d’un FPGA pour compresser et chiffrer les données à la volée, ainsi que d’un processeur ARM pour optimiser les flux de données. Ce qui change, en revanche, c’est le logiciel », révèle Uri Beitler, le PDG de la startup, que LeMagIT a rencontré à l’occasion d’un événement IT Press Tour consacré aux startups israéliennes qui innovent en matière de stockage.
« Nous travaillons avec les principaux fournisseurs d’applications critiques en matière de stockage, Oracle par exemple, pour développer une version de leur produit qui tire parti de l’accélération de notre carte. Puis, leur application est vendue en bundle avec notre carte », ajoute-t-il.
Plus exactement, Pliops semble pour l’heure ne considérer les entreprises qu’à la marge. Sa carte est plutôt déployée chez les hébergeurs qui proposent ces bases de données en SaaS et chez ceux qui proposent des services IaaS de stockage en mode bloc dans leur cloud. Hormis ces profils de partenaires, Pliops revendique avoir fourni sa carte à de grands supercalculateurs et à quelques géants d’Internet – qui éditent des réseaux sociaux – lesquels ont les mêmes problématiques que les géants du cloud.
Un processeur ARM pour mieux calculer le travail interne d’un SSD
« Les derniers CPUs ont plus de cœurs pour exécuter des fonctions applicatives en parallèle, mais chaque cœur individuel se traîne tout autant qu’il y a dix ans. »
Uri BeitlerPDG, Pliops
Uri Beitler justifie la raison d’être de sa carte XDP : « en quelques années à peine, les SSDs NVMe ont apporté mille fois plus de performances que les anciens disques durs, mais la rapidité des processeurs n’a pas évolué autant. » Selon lui, elle n’aurait même pas évolué du tout : « les derniers CPUs ont plus de cœurs pour exécuter des fonctions applicatives en parallèle, mais chaque cœur individuel se traîne tout autant qu’il y a dix ans ».
Donc, la carte contrôleur XDP vient au secours des processeurs pour accélérer par 40 les accès par paquets de 4 Ko et par 64 ceux qui se font par paquets de 64 Ko. Il s’agit d’une accélération moyenne. En vérité, la carte XDP implémente toute la logique qui mine normalement un SSD : pour gérer l’usure de ses cellules, il devrait calculer l’emplacement de celles les moins utilisées, mais il ne fait pas correctement, car cela demande trop de puissance de calcul.
À la place, il se retrouve trop souvent à devoir réécrire des cellules déjà utilisées (sur un SSD QLC, une cellule peut contenir jusqu’à quatre bits), ce qui suppose de mettre de côté leur contenu, de les effacer, puis de les écrire avec l’ancien et le nouveau contenu. Ces opérations créent de la latence, laquelle ralentit les applications. Et ce ralentissement est d’autant plus important au fur et à mesure que le SSD se remplit.
Au sein de la carte XDP, un processeur ARM calcule bien plus efficacement vers quelles cellules écrire. La puce ARM est à ce point efficace qu’il n’est plus besoin d’utiliser la capacité excédentaire qu’ont tous les SSD en guise de réserve fantôme pour prolonger leur durée de vie. C’est justement parce que cette capacité fantôme est utilisée à autre chose – la redondance des données – que la carte XDP est le seul contrôleur capable de constituer un RAID 5 sans sacrifier un disque entier. Cette technique permettrait de rallonger la durée de vie des SSD TLC par un facteur 4,7 et celle des SSD QLC par un facteur… 18 !
Mieux : en cas de problème sur un SSD, le RAID de la carte XDP est cinq fois plus rapide qu’un algorithme RAID 5 exécuté par le processeur du serveur, car la puce ARM ne reconstruit que les données perdues lors de la panne et non un SSD entier. Quant aux accès parallèles sur le RAID, ils seraient jusqu’à 23 fois meilleurs avec une carte XDP.
Avec un SSD dont la capacité n’est pas sacrifiée et une puce FPGA qui se charge de compresser les données à la volée, la capacité d’un RAID piloté par une carte XDP serait aussi plus importante que sur un RAID de base. Par exemple, en RAID 10, quatre SSD de 1,92 To chacun donnent normalement une capacité totale de 3,84 To, laquelle devient 5,76 To avec une carte XDP sans compression, laquelle atteint 12 To avec une carte XDP et la compression activée.
Dans cet exemple, Pliops active une compression spécialement adaptée à l’application, laquelle est, dans le benchmark présenté au MagIT, MongoDB.
Des implémentations optimisées par application
Ces accélérations brutes se transforment en accélérations applicatives dès lors que le logiciel a été réécrit pour envoyer les données à l’API de la carte XDP plutôt qu’à la couche de stockage du système d’exploitation hôte. API que Pliops revendique améliorer au fil du temps, justement pour prendre en compte les exigences particulières des applications.
Ainsi, XDP-AccelDB est plus exactement un nouveau service de stockage dans le firmware de la carte XDP qui présente une API étendue aux bases de données SQL, dont MySQL, MariaDB et autres PostgreSQL. D’une manière générale, les benchmarks de Pliops mesurent, en moyenne, un débit 2,5 fois supérieur, une latence 8 fois inférieure, une capacité multipliée par 6 et, somme toute, 30 % de temps CPU libéré quand ces bases utilisent la carte XDP.
Mais cela dépend des implémentations. En travaillant avec Oracle, les deux équipes sont parvenues à multiplier par 3,4 le nombre de transactions de MySQL. Ces comparaisons se basent sur deux machines disposant de la même configuration CPU, RAM et SSD, l’une ayant une carte XDP et pas l’autre.
« Notre carte fournit finalement aux bases NoSQL des performances similaires au stockage des données en RAM, sauf que les SSD coûtent une fraction des barrettes de RAM. »
Uri BeitlerPDG, Pliops
Les chiffres sont encore meilleurs avec le service de stockage XDP-AccelKV, spécifiquement adapté aux bases NoSQL. Dans ce cas, Pliops mesure un débit multiplié par 20, une latence divisée par 100 et 10 fois plus de temps CPU libéré. La capacité, elle, reste 6 fois plus importante, puisque le FPGA applique le même algorithme de compression.
« Ce qu’il faut comprendre, c’est que notre carte fournit finalement aux bases NoSQL – par exemple Redis – des performances similaires au stockage des données en RAM, sauf que les SSD coûtent une fraction des barrettes de RAM », insiste Uri Beitler.
En attendant les configurations pour les entreprises
Reste à savoir quand le produit de Pliops fera son chemin dans le datacenter du tout venant des entreprises. A priori, cela passera par des partenariats avec les fabricants de baies de stockage.
Il existe en effet quatre constructions possibles d’un système de stockage avec une carte XDP et chacun doit comprendre un minimum de développement au niveau du firmware du matériel.
La première architecture consiste à installer la carte dans un serveur x86 de stockage en mode bloc (SAN) qui intègre de nombreux SSD en RAID. La seconde consiste à développer un serveur de stockage en mode bloc, qui n’a même plus de processeur x86, mais se base uniquement sur la carte XDP pour assurer à la fois le contrôle des disques et une connexion NVMe-over-Fabrics avec les serveurs du réseau. Pliops assure pouvoir gérer une telle connexion, sans toutefois préciser quel protocole aurait été implémenté dans sa carte (NVMe/TCP, NVMe/RoCE ou NVMe/FC).
Dans la troisième architecture, il s’agit plutôt de mettre une carte XDP dans chaque serveur du réseau pour accélérer ses accès NVMe-over-Fabrics vers un tiroir de SSD (JBOF) compatible avec ce protocole. La quatrième architecture évoque la possibilité de mettre plusieurs cartes XDP dans un serveur pour répartir la charge entre plusieurs tiroirs JBOFs. Dans cette configuration, la carte XDP serait capable de construire une sorte de RAID à cheval entre les différents JBOF.
