Cet article fait partie de notre guide: Faire le point sur NVMe-over-Fabrics, le nouveau stockage SAN

Pourquoi les baies de stockage NVMe sont plus lentes que prévu

Les baies NVMe dernier cri ont un problème : leur logiciel n’est pas encore adapté aux performances de leurs unités de stockage. Les fournisseurs proposent trois palliatifs peu efficaces.

Le NVMe a beaucoup à apporter aux systèmes de stockage des entreprises. La technologie améliore les performances du stockage Flash en augmentant le nombre de requêtes transférables simultanément, grâce au bus PCIe qui sert ici d’interconnexion. Ce protocole fonctionne pour le stockage interne, le stockage externe et même en réseau pour les espaces disques partagés.

L’amélioration que la majorité des entreprises constateront est une réduction de la latence. Cette réduction est si importante que l'on se rend pour la première fois compte qu'il existe d'autres goulets d’étranglement.

24 disques NVMe à 500 000 IOPS chacun totalisent... un seul million d’IOPS

Les baies de stockage se composent de plusieurs éléments. Il y a d'abord les médias de stockage, que l'on appelle de manière générique des disques. Ce sont ici en l’occurrence des unités Flash NVMe. On y trouve aussi un logiciel pour piloter l’ensemble, le système de stockage. Et puis, il y a la connectique réseau, qui relie la baie de stockage aux autres machines du datacenter, principalement les serveurs.

À l’époque des disques durs, et même à celle des disques SSD reliés en SAS (Serial attached SCSI), les performances du logiciel et de la connectique ne faisaient pas débat puisque la latence des unités de stockage était le principal goulet d’étranglement. Mais à l’ère des unités Flash NVMe, au contraire, la latence des unités de stockage est pour ainsi dire devenue inexistante.

Pour se rendre compte du pas franchi en matière de latence, il suffit de comparer la performance individuelle des disques Flash NVMe et celle de la baie qui les embarque. Plusieurs modèles de disques NVMe atteignent plus de 500 000 IOPS. Mais selon les chiffres des constructeurs, la plupart des baies de stockage, même si elles contiennent 24 de ces disques, n’atteignent que 10 % de leur performance cumulée, soit moins d’un million d’IOPS. En clair, elles sont loin d’atteindre les 12 millions d’IOPS possibles et ce n'est pas la faute des médias de stockage.

Le problème se situe d’abord au niveau de la connectique réseau : elle est sous-dimensionnée. Néanmoins, il n'y a rien d'alarmant, car l’arrivée prochaine du protocole NVMe over Fabrics, épaulé par des processeurs dont la puissance s’accroît sans cesse, devrait résoudre la situation.

Le véritable inconvénient est l’absence d’optimisation dans les logiciels qui pilotent ces baies. Et, pour l’heure, les fournisseurs contournent le problème avec des palliatifs dont l’efficacité est discutable.

Attention aux palliatifs imaginés par les fournisseurs

L’astuce la plus courante des fournisseurs est d’équiper la baie des plus récents et plus puissants processeurs, puisqu’ils sont censés, par définition, accélérer les logiciels. Sauf qu’Intel et les autres fabricants de processeurs améliorent les processeurs en multipliant leurs cœurs, pas en les accélérant. Et si le système de stockage n’est pas développé en multithread, le bénéfice pratique d’utiliser des processeurs récents sera quasiment nul.

Une autre astuce consiste à faire exécuter les fonctions de pilotage du stockage par un FPGA, ou, mieux, par un ASIC. Certes, confier ces fonctions à une puce dédiée, plus efficace qu’un cœur générique, donnera sur le papier de meilleurs résultats aux tests de performances. Néanmoins, déplacer le système du logiciel au matériel est juste l’inverse de la stratégie populaire actuelle, dite de Software-Defined, et qui vise plutôt à rendre le stockage, si ce n’est le datacenter entier, entièrement pilotable par logiciel.

La troisième astuce est de limiter le rôle du logiciel, c’est-à-dire de réduire le nombre de fonctions disponibles : la déduplication, la compression, les snapshots... Après tout, pourquoi pas, les applications qui ont besoin de hautes performances intègrent en général elles-mêmes ce type de fonctions. Et comme elles fonctionnent en cluster, le goulet d’étranglement au niveau du stockage serait en définitive réparti au niveau des serveurs.

Mais encore faudrait-il que toutes les applications proposent les fonctions de stockage qu’utilisent les entreprises. Or, ce n’est pas le cas. Et quand elles le font, elles exécutent chacune de ces fonctions à leur manière, sans aucun standard. En clair, la complexité d’administration du stockage sera relative au nombre d'applications dans le SI.

Résoudre les problèmes de lenteur prendra du temps

Améliorer les performances des systèmes de stockage pour profiter de la vitesse du NVMe promet de prendre du temps. Les développeurs doivent réécrire leurs codes, éventuellement depuis le début, pour les rendre véritablement parallélisables. Bien entendu, nombre de fournisseurs se targuent d’avoir déjà implémenté du multhreading. Mais, dans la plupart des cas, ils se sont surtout contentés d’attribuer certaines tâches à des cœurs en particulier, ce qui n’est absolument pas un moyen optimal d’exploiter la puissance d’un processeur. Les dernières générations ayant plus d’une vingtaine de cœurs, un système de stockage se retrouve ainsi avec plus de cœurs que de tâches à traiter en parallèle.

À la place, les fournisseurs devraient s’efforcer de répartir les fonctions d’entrées-sorties sur tous les cœurs présents, ce qui garantirait qu’ils soient tous utilisés de manière égale.

Outre la parallélisation du fonctionnement, il convient aussi de réécrire les algorithmes qui constituent les fonctions basiques du stockage et qui n’ont pas évolué depuis des décennies. Et cela promet de prendre encore plus de temps. Ces algorithmes sont ceux du RAID, des snapshots, de la déduplication, de la réplication, ou encore du Thin Provisioning. Aucun ne prend en charge ni le grand nombre de cœurs au sein des processeurs, ni la faible latence des unités de stockage modernes.

Les entreprises face à des offres qui ne répondent pas encore à la demande

La lenteur des baies de disques NVMe est à relativiser. Mis à part les traitements de Machine Learning et autres processus d’intelligence artificielle, peu d’entreprises utilisent des applications qui ont déjà besoin des performances du NVMe. Certaines entreprises penseront donc qu’elles ont plutôt intérêt à continuer d’utiliser des baies Flash dont les disques SSD sont traditionnellement connectés en SAS. Ces équipements répondent en effet aux exigences des applications actuelles.

Néanmoins, les départements informatiques ont hâte de tirer profit du NVMe pour densifier les machines virtuelles par serveur physique. En effet, plus la quantité de VMs dans un serveur est importante, plus la charge sur les entrées-sortie est considérable et, donc, plus il est pertinent d'utiliser des médias de stockage avec une très faible latence. A ce titre, les unités NVMe et le protocole réseau NVMe over Fabrics promettent d’apporter les bandes passantes adaptées pour déployer plusieurs centaines de VMs par nœud. Mais attention, ne perdons pas de vue que les systèmes de stockage ne suivent pas.

De fait, les entreprises tentées de franchir dès à présent le pas du NVMe devront payer un supplément pour obtenir des baies équipées des derniers processeurs, mais elles ne rentabiliseront pas cet investissement tant que le logiciel n'est pas aligné sur le matériel.

Dans tous les cas, il convient de rester attentif aux offres qui sortiront sur le marché et qui proposeront des systèmes hautement parallélisés, avec des algorithmes de stockage réécrits. Ces solutions-là permettront réellement d’atteindre les performances promises et, qui plus est, avec moins d’unités NVMe qu’il y a habituellement de disques.

Pour approfondir sur Flash

- ANNONCES GOOGLE

Close