Stockage : StorPool revient pour battre des records de vitesse en SDS
Cette startup bulgare a fait évoluer sa solution de baie SAN virtuelle pour qu’elle ne travaille plus qu’avec des SSD NVMe et délivre ainsi jusqu’à 1 million d’IOPS par nœud.
De la performance brute pour le stockage. Parmi les startups qui cherchent à innover dans les baies de disque, la société bulgare StorPool entend faire parler de son système SDS (Software-Defined Storage) qui permettrait d’atteindre 1 million d’IOPS sur un serveur quand il est installé tout seul, ou 250 000 IOPS sur le nœud d’une infrastructure hyperconvergée occupée par ailleurs à exécuter des machines virtuelles.
Le secret ? StorPool ne s’embarrasse pas de fonctions de haut niveau, comme un service de fichiers ou la gestion d’un tiering, et il est optimisé pour une seule configuration : un serveur Linux avec des SSD NVMe. Cette caractéristique, qui fait aujourd’hui sa force, n’existait pas lorsque LeMagIT avait rencontré la première fois la startup, en 2014. À cette époque, StorPool envisageait de supporter différentes classes de stockage, y compris les plus lentes.
« Nos clients sont des entreprises suffisamment technophiles pour bâtir un cloud privé dans leur datacenter, soit l’Agence Spatiale Européenne, la NASA, le Cern… mais aussi, le plus souvent, des hébergeurs qui proposent des services de cloud privé aux entreprises », explique Boyan Ivanov, le PDG de StorPool, à l’occasion d’une rencontre organisée dans le cadre de l’IT Press Tour, un événement consacré aux acteurs innovants du stockage et auquel LeMagIT a pu participer.
« Grâce à notre solution, l’hébergeur britannique Krystal peut proposer dans ses services d’IaaS une offre de stockage en ligne Katapult qui permet d’atteindre 113 447 IOPS et 3,2 Go/s par machine virtuelle, moyennant 0,15 $/Go par mois. Comparativement, Google propose dans son cloud le service de stockage bloc Persistent Disk (0,17 $/Go par mois) qui n’atteint que 15 400 IOPS et 500 Mo/s par VM. Avec son service EBS (0,10 $/Go par mois), AWS n’atteint que 3 120 IOPS et 250 Mo/s. Quant à Azure, son service Premium SSD (0,12 $/Go par mois) donne à chaque VM 5140 IOPS et 190 Mo/s », lance pour sa part Boyan Krosnov, le responsable des produits chez StorPool.
Un SDS qui consomme au minimum 1 cœur et 4 Go de RAM par nœud
Dans le principe, le système de StorPool est comparable à SANsymphony de DataCore : il simule une baie de disques en mode bloc (SAN) à partir des SSD NVMe installés dans des serveurs et il a la capacité d’agglomérer logiquement plusieurs serveurs pour simuler une seule baie de grande taille.
« L’avantage d’un tel système par rapport à une vraie baie SAN physique est que nous pouvons attribuer une unité de disque (une LUN) à une seule machine virtuelle pour optimiser les accès. »
Boyan KrosnovPDG, StorPool
« L’avantage d’un tel système par rapport à une vraie baie SAN physique est que nous pouvons attribuer une unité de disque (une LUN) à une seule machine virtuelle pour optimiser les accès, alors qu’une baie SAN va partager l’accès vers une LUN entre plusieurs machines virtuelles », argumente Boyan Krosnov, en précisant que, bien évidemment, la LUN est ici aussi virtuelle.
En lui-même, StorPool est juste un pilote de stockage pour Linux. Sa particularité est qu’il s’accapare, à lui seul, un à quatre cœurs de processeur x86 par nœud. Il se sert de cette puissance pour dialoguer avec les autres nœuds de cluster, sur lesquels un autre pilote StorPool est installé et pour présenter aux serveurs applicatifs des unités SCSI virtuelles. Il utilise également 4 Go de RAM par cœur pour mettre en cache les données que les serveurs applicatifs lui demandent de lire et d’écrire.
Pour atteindre son grand nombre d’IOPS, StorPool répartit les blocs de ses disques virtuels sur chacun des nœuds qui constituent son cluster. Au final, lorsqu’un serveur applicatif – éventuellement une machine virtuelle – souhaite lire un fichier composé d’une suite continue de blocs, plusieurs groupes de blocs sont lus en parallèle, accélérant de fait radicalement la lecture. Pour fonctionner, StorPool nécessite au minimum trois nœuds.
« Lorsque l’on ajoute un nœud au cluster, celui-ci est automatiquement pris en charge et tous les fichiers créés ensuite auront un segment qui sera enregistré dessus », indique Boyan Krosnov, en suggérant que plus le nombre de nœuds augmente, plus les performances sont importantes. Toutefois, des limites s’appliquent, car la taille minimale d’un segment est de 1 Mo, signifiant qu’un fichier de 4 Mo, par exemple, ne sera pas lu plus vite sur un cluster de cinq nœuds. À l’inverse, les fichiers de moins de 1 Mo ne bénéficieront d’aucun accès parallèle, même s’ils sont tout de même écrits sur trois nœuds à la fois pour des questions de redondance.
Uniquement des SSD NVMe, uniquement de l’hyperconvergence Linux
Lorsqu’il est utilisé seul sur un nœud, le pilote StorPool peut s’accaparer jusqu’à un maximum de quatre cœurs de processeurs et 16 Go de RAM, pour grimper jusqu’à 1 million d’IOPS sur ce nœud. Le stockage est en l’occurrence accessible aux autres machines du réseau en iSCSI, via une connectique Ethernet en 25 Gbit/s ; StorPool indique qu’une connexion en 10 Gbit/s est possible, mais n’indique pas de mesures de performances dans ce cas-là. Tous les serveurs – Windows, Linux… – et toutes les infrastructures de virtualisation – KVM, VMware ESXi, Microsoft Hyper-V… – peuvent accéder en iSCSI à ce stockage StorPool.
On notera que StorPool ne propose pas d’accès en NVMe-over-RoCE, ni même en NVMe-over-TCP, des versions plus modernes des protocoles SAN qui prennent directement en compte des ordres NVMe pour accélérer les échanges vers les SSD de ce type. Selon la startup, ce protocole reste encore peu supporté sur les serveurs et StorPool offrirait déjà suffisamment de performances en iSCSI.
L’autre mode d’utilisation est de se servir de StorPool comme du pilote de stockage d’une infrastructure hyperconvergée, c’est-à-dire d’installer StorPool sur des nœuds qui servent également à exécuter des machines virtuelles. C’est dans ce cas que StorPool n’utilise plus qu’un seul cœur et juste 4 Go de RAM, laissant le reste des ressources utilisables par l’hyperviseur des VMs. La quantité maximale d’accès au stockage d’un nœud descend dès lors à 250 000 IOPS, que ce soit en interne, pour le système fonctionnant sur ce nœud, comme en externe, pour les serveurs qui y accèdent en iSCSI.
Le problème, en revanche, est que StorPool ne fonctionne que sur les infrastructures hyperconvergées qui reposent sur l’hyperviseur KVM de Linux. Il n’est donc pas possible de l’intégrer dans ce cas à VMware ESXi ou Microsoft Hyper-V. En revanche, son pilote est prévu pour s’interfacer directement avec le pilote Cinder d’OpenStack.
« Outre OpenStack, nous prenons en charge plusieurs infrastructures de virtualisation qui reposent sur KVM, comme CloudStack et OpenNebula [deux concurrents open source d’OpenStack, mis au point par les développeurs d’Apache, N.D.R.], mais aussi l’orchestrateur de containers Kubernetes. À ce titre, nous nous considérons comme un SDS de seconde génération, car notre système permet véritablement de construire des infrastructures hyperconvergées qui n’exécutent plus de machines virtuelles, mais seulement des containers », assure le chef produit.
Pour mémoire, les containers sont des instances virtuelles qui ne contiennent que l’application à exécuter, ce qui les rend beaucoup plus légers que les machines virtuelles, autorisant de fait à en exécuter un plus grand nombre par nœud serveur.
« Notre logiciel ne pilote que du stockage NVMe. »
Boyan IvanovPDG, StorPool,
Concernant les disques eux-mêmes, StorPool concède que son système n’atteint de telles performances que si la mémoire cache qu’il utilise s’interface avec des unités ayant moins de 100 microsecondes de latence, soit obligatoirement des SSD avec connectique NVMe. Et l’équipe de préciser : n’importe lesquels du moment qu’ils sont rapides.
« Nous ne faisons par exemple pas de différence entre un SSD NVMe conventionnel et un SSD Optane. D’ailleurs, nous ne gérons pas la nature du stockage et c’est pourquoi nous n’offrons aucune forme d’auto-tiering : StorPool n’exploitera pas plus les disques virtuels en RAM – comme ceux d’une mémoire persistance telle que l’Optane PMEM – que les disques durs SATA. Notre logiciel ne pilote que du stockage NVMe », affirme Boyan Krosnov.
