Stockage : la norme NVMe 2.0 est désormais ratifiée
Les SSD NVMe 2.0 promettent d’atteindre entre 5 et 10 Go/s grâce à l’utilisation du bus PCIe 5.0. Ils disposeront aussi de fonctions d’optimisation selon les usages. Mais pas avant 2025.
Les bus PCIe 5.0 arriveront l’année prochaine dans les serveurs et ils amèneront avec eux une nouvelle version 2.0 du protocole de stockage NVMe. Le consortium NVM Express Inc. vient en effet de finaliser les caractéristiques de la prochaine génération de SSD connectés directement en PCIe. Au-delà du bénéfice d’un débit plus important directement lié au nouveau bus PCIe, le NVMe 2.0 apporte notamment le support des dispositifs Key-Value (KV) et Zoned Namespace (ZNS).
Avec le dispositif Key-Value, un fichier n’est plus stocké dans une quantité de secteurs à la taille fixe, mais dans une zone qui correspond à la taille du fichier. Cela permettrait d’accélérer par trois l’accès aux données dans un système de stockage objet, car il n’est plus nécessaire de passer par un système de fichiers sous-jacent. Grâce au ZNS, les écritures ne se font plus à un endroit aléatoire du SSD, elles sont regroupées par zones pour limiter le vieillissement des cellules NAND dans le cas des bases de données SQL.
La standardisation de ces techniques, sur lesquelles planchaient déjà différents fabricants de SSD, permet de garantir qu’elles fonctionneront aussi bien sur les SSD internes à un serveur, comme sur ceux situés dans une baie externe et reliée en NVMe-over-Fabrics (NVMe/RoCE, NVMe/TCP, NVMe/FC, etc.).
Pour sa part, le bus PCIe 5.0 double les débits de son prédécesseur. La nomenclature parle d’un passage de 16 giga-transferts par seconde à 32 giga-transferts par seconde sur quatre canaux, ce qui correspond environ à un nouveau débit de 10 Go/s maximum en lecture pour les SSD NVMe sur quatre canaux, contre 5 Go/s maximum auparavant. Un slot PCIe 5.0 supportera, comme en PCIe 4.0, un maximum de 16 canaux en parallèle. Toutefois, cette bande passante quadruplée est d’ordinaire utilisée par les cartes d’accélération GPU plutôt que par des unités de stockage.
Les SSD NVMe 2.0 ne seront pas vraiment disponibles avant 2025
Les SSD fonctionnant en NVMe 2.0 ne seront pas annoncés avant fin 2022, voire quelque part en 2023. Le processus d’implémentation du standard dans des produits de série est long. Par exemple, le consortium PCI-SIG, qui ratifie les fonctions liées au PCIe, a standardisé le PCIe 5.0 en 2019, mais Marvell ne livre que depuis quelques semaines le contrôleur Bravera SC5 qui permet aux fabricants de SSD et de cartes d’extension d’exploiter ce bus. Les designs autour de ce contrôleur n’ont même pas encore commencé, ou débutent à peine.
Tom CoughlinAnalyste, Coughlin Associates
Côté serveur, le bus PCIe 5.0 ne sera de toute façon pas exploitable tant que le processeur ne le prendra pas en compte. Le premier à le faire devrait être le Xeon « Sapphire Rapids » dont Intel devrait lancer la production au début de l’année 2022, pour une livraison aux fabricants de serveurs estimée au deuxième trimestre 2022. De son côté, AMD n’a pas encore indiqué de date de support. Pour mémoire, le bus PCIe 4.0 avait été ratifié en 2017, les processeurs AMD l’ont supporté dès 2019, tandis qu’il a fallu attendre 2021 pour voir des processeurs Intel compatibles.
L’analyste Tom Coughlin, du cabinet Coughlin Associates, n’est pas très optimiste sur la disponibilité : « à mon avis, même si des produits PCIe 5.0 sont annoncés fin 2022 ou en 2023, je ne pense pas qu’ils soient commercialisés en grande quantité avant 2025, voire 2026 », commente-t-il.
Pourquoi implémenter NVMe 2.0 sera long
« Concernant NVMe 2.0, c’est encore plus compliqué. Car au-delà du simple gain de vitesse, la prise en charge de KV et de ZNS nécessite une toute nouvelle implémentation logicielle pour que les applications en profitent », ajoute pour sa part l’analyste Jim Handy, du cabinet d’études Objective Analysis.
Des SSD ZNS sont déjà en cours de développement chez Western Digital et Samsung. Eric Pike, en charge de produits Flash chez le premier, constate en effet que la mise au point d’une pile logicielle pour tenir compte de toutes les subtilités du ZNS est « assez longue. » Et pour cause : la raison d’être du ZNS est d’optimiser le stockage complexe des bases de données de type SQL pour rallonger la durée de vie des SSD, particulièrement mise à mal dans ce type d’applications. Soit ZNS y parvient complètement, soit il est inutile. Il n’y a pas de demi-mesure.
De son côté, KV, qui est une initiative de Samsung et NetApp, doit servir à optimiser le stockage objet. Mais encore faut-il valider qu’il fonctionnera avec tous les stockages objet. Et même qu’il fonctionnera avec les systèmes de stockage qui font de l’objet et qui, dans le même temps, se servaient déjà de techniques reprises dans KV pour optimiser leurs accès. C’est par exemple le cas du système Ceph et de RocksDB, le système de stockage de la base de données éponyme (et non-SQL).
En pratique, les fabricants devront mettre au point des SSD NVMe 2.0 que les utilisateurs pourront découper en partitions qui seront soit de type ZNS, soit de type KV, soit ni l’un ni l’autre, et qui fonctionneront comme les SSD actuels.
Cependant, pour simplifier les efforts de développement, le consortium NVM Express a découpé le nouveau standard en trois tranches indépendantes : la Base, le Command-Set et le Transport. Les dispositifs ZNS et KV faisant partie du Command-Set, les fabricants pourront implémenter l’un ou l’autre tout en ayant l’ensemble des fonctions de base et de transport, voire en n’implémentant que les fonctions de transport par PCIe sans celles de transport par TCP.
Il est ainsi possible que des futurs modèles de SSD NVMe 2.0 soient dédiés à un usage unique, typiquement le stockage objet grâce à l’implémentation du KV, et ne soient plus utilisables dans les autres cas de figure. À l’heure actuelle, limiter certains SSD à certains cas d’usage – par exemple ceux à cellules NAND QLC pour les grandes capacités peu accédées – est une bonne pratique. Demain, cela pourrait devenir une contrainte technique.
KV, pour accélérer le stockage objet
Dans le principe, KV permet de récupérer plus rapidement une donnée, car, à chaque requête d’accès formulée au niveau du système de stockage objet, correspond un code unique qui indique directement l’emplacement de cette donnée sur le SSD.
Sans KV, les données sont aujourd’hui des fichiers avec un nom correspondant à un numéro dans la base de métadonnées du système objet. À chaque requête, ce système doit chercher dans sa base la correspondance entre l’objet demandé et le nom du fichier qui lui correspond, puis interroger le système de fichiers sous-jacent pour savoir dans quels blocs se trouve ce fichier. Pire, contrairement aux disques durs dont les blocs sont physiquement définis par le formatage, les SSD utilisent un système de blocs logiques qui pointent vers des blocs physiques, imposant une étape de translation supplémentaire.
Le protocole KV supprime toutes les étapes intermédiaires, ce qui non seulement améliore les performances, mais économise aussi l’espace de stockage dévolu aux translations.
Supporter des disques durs… NVMe ?
Parmi les autres apports de NVMe 2.0, on trouve, paradoxalement, le support des disques durs mécaniques. Cette fonction est censée permettre de brancher des contrôleurs de disques durs au même niveau que les SSD NVMe et d’identifier les uns et les autres, pour que le système hôte ou l’application décide simplement sur quel support il est préférable d’écrire.
Pour autant, cette fonctionnalité est débattue. Certains argumentent qu’il s’agit d’un effort de simplification pour les logiciels à venir. D’autres font remarquer que cela ne servirait qu’à ralentir un peu plus l’accès aux disques durs, lesquels sont parfaitement pris en compte par tous les logiciels depuis leur actuelle interface SAS/SATA. Parmi les fabricants, Toshiba s’est dit vivement intéressé de suivre de très près le développement et la standardisation de tels « disques durs NVMe », mais a précisé qu’il ne comptait pas en développer.
Citons par ailleurs la possibilité d’étiqueter des zones pour indiquer une qualité de service, celle de copier directement des blocs logiques vers d’autres sans passer par le système d’exploitation du serveur, ou encore la gestion d’une clé de chiffrement par application.