chokmoso - Fotolia

Stockage : StorPool revendique d’éditer le SDS le plus rapide

Le système de la société bulgare ne partage que du stockage en mode bloc et réécrit les pilotes NVMe pour maximiser les accès parallèles. Il est désormais disponible sur AWS, en plus de ses versions datacenter.

Cet article est extrait d'un de nos magazines. Téléchargez gratuitement ce numéro de : STORAGE: Storage 34 – Les initiatives européennes pour stocker les données

Dix fois moins de latence que les autres solutions de stockage et 1 million d’IOPS depuis un seul nœud. Tels sont les arguments de StorPool, un éditeur de stockage distribué et virtualisé (SDS, pour Software Defined Storage) qui propose d’installer sa technologie dans les datacenters et, désormais, sur AWS.

« C’est AWS lui-même qui est venu nous chercher pour proposer une offre extrêmement performante à côté de ses services de stockage en ligne », affirme Boyan Ivanov, le PDG de l’éditeur, que leMagIT a pu rencontrer à l’occasion d’un récent événement IT Press Tour.

« En l’occurrence, une unité StorPool sur AWS permet à vos applications en ligne d’atteindre 1200 IOPS, quand EBS, le service de stockage directement rattaché à vos VMs, n’offre que 250 IOPS », ajoute-t-il. 

Il précise qu’AWS ne commercialise pas lui-même StorPool parmi ses services de stockage. C’est StorPool qui propose d’installer lui-même son système sur des VMs AWS.

« La meilleure mesure de performance, désormais, c’est la latence, c’est-à-dire à quelle vitesse votre stockage répond à votre application ou votre système. C’est dans ce sens que nous avons développé notre SDS. »
Boyan IvanovPDG, StorPool

Le SDS de StorPool serait aussi performant, d’abord, parce qu’il ne s’encombre pas avec toutes les fonctions de stockage possibles. Cette solution ne propose aux serveurs que du mode bloc, celui qu’utilisent les bases de données transactionnelles (les applications qui ont le plus besoin d’IOPS), et celui des systèmes d’exploitation quand ils lisent ou enregistrent les volumes de leurs machines virtuelles ou de leurs containers persistants.  

« Les baies de stockage traditionnelles sont trop complexes, trop peu élastiques et trop chères pour les usages modernes. La meilleure mesure de performance, désormais, c’est la latence, c’est-à-dire à quelle vitesse votre stockage répond à votre application ou votre système. C’est dans ce sens que nous avons développé notre SDS », dit Boyan Ivanov.

Il précise que les entreprises sont libres d’ajouter sur StorPool des services de fichiers tiers pour qu’une partie des disques servent de NAS. « L’important est que vous ayez un pool de stockage le plus rapide possible à la base », assure-t-il.  

Comment StorPool parvient-il à de telles performances ?

Le principe de fonctionnement du logiciel est de s’installer sur au moins trois serveurs connectés en réseau et de présenter leurs disques comme un gros SAN virtuel aux autres machines du réseau local. Exactement comme le fait tout autre SDS, de VMWare vSAN à DataCore SANsymphony. En revanche, StorPool revendique un code plus optimisé et, surtout, concède que ses bonnes performances sont surtout dues à une utilisation plus importante de la RAM de chaque nœud dans le cluster.

« Nous utilisons 1 Go de RAM et une machine virtuelle complète par nœud pour gérer jusqu’à 1 Po de données », finit par concéder Boyan Krosnov, le directeur technologique de l’éditeur. « Mais c’est la clé pour proposer des performances meilleures que celles des baies Pure Storage, ou NetApp 100 % Flash. »

Quand les applications sont embarquées dans le même serveur que celui qui exécute la VM StorPool, la latence serait aussi basse que 70 microsecondes pour atteindre des données stockées sur un autre nœud. Soit une fois et demie seulement la latence que l’on rencontre quand l’application accède directement aux SSD NVMe du serveur qui l’héberge. Et, justement, lorsque les données sont sur le même serveur, leur latence sous StorPool serait divisée par deux par rapport à un accès direct. En cause, des accès NVMe parallélisés avec StorPool, mais pas avec le système d’exploitation hôte.

« StorPool utilise [les pilotes] que nous avons développés et qui autorisent une sorte de RAID optimisé pour les SSD NVMe, mais aussi pour les cartes réseau qui interconnectent les nœuds entre eux. »
Boyan IvanovPDG, StorPool

« En l’occurrence, StorPool n’utilise pas les pilotes du système d’exploitation hôte. Il utilise ceux que nous avons développés et qui autorisent une sorte de RAID optimisé pour les SSD NVMe, mais aussi pour les cartes réseau qui interconnectent les nœuds entre eux », explique Boyan Krosnov.

Dans la version la plus récente du système, la v20, StorPool prend en charge le NVMe/TCP. À la fois au niveau des tiroirs de disques externes qui sont reliés à ses nœuds, mais aussi en tant que cible SAN NVMe/TCP pour les autres serveurs du réseau local. Le NVMe/TCP présente l’intérêt d’un réseau peu cher, mais à la vitesse maximale que peuvent atteindre des SSD. StorPool assure qu’une application connectée via une connexion Ethernet 100 Gbit/s au cluster peut réellement charger des données à la vitesse de 10 Go/s, soit le maximum autorisé par une telle connexion.

Par ailleurs, StorPool tranche avec ses habitudes en proposant lui-même sans sa v20 un service NAS, au protocole NFS. La capacité maximale que ce service peut partager est de 50 To.

Qui utilise StorPool ?

Solution d’avant-garde oblige, StorPool aurait comme client les chercheurs de la NASA, de l’ESA et du Cern. Atos serait déjà l’un de ses intégrateurs pour déployer la solution à côté d’un supercalculateur.

Son SDS est donc aussi à présent disponible sur AWS, moyennant son installation sur une VM i3en.metal ou r5n qui reste à la charge de l’entreprise utilisatrice. Selon toute une série de tests effectués par l’éditeur, un tel service (mesuré toutefois chez un autre hébergeur, le Britannique Katapult) resterait sous la barre des 4 millisecondes de temps de réponse avec des bases de données qui effectuent 10 000 requêtes par seconde. Comparativement, EBS, le service de stockage bloc natif d’AWS, serait limité à 4000 requêtes. Et ses concurrents à moins de 2000.

« Le problème des services de stockage en mode bloc dans le cloud est qu’ils ne sont pas élastiques. Dès que vous dépassez une certaine quantité d’accès, le serveur utilise d’autres SSD, voire des SSD qui ne sont plus directement branchés sur ses bus PCIe. Dès lors, votre application passe par le goulet d’étranglement du pilote de l’OS hôte », assure Boyan Krosnov.

Pour approfondir sur Software Defined Storage

Close