ZNS, la nouvelle norme qui doit réduire le coût des disques NVMe

Résoudre les problèmes du stockage Flash

Un SSD soufre de plusieurs défauts. Tout d’abord, les données y sont écrites de manière séquentielle mais doivent être effacées avant d'être réécrites. Pire, les données sont écrites sur une page NAND mais effacées au niveau de ses blocs. De plus, un SSD ne supporte qu'un nombre limité de cycles d’écriture/effacement avant que ses cellules ne commencent à tomber en panne. S'ils ne sont pas correctement gérés, tous ces problèmes réduisent prématurément la durée de vie d’un SSD.

D’ordinaire, les SSD sont équipés dans leur contrôleur d’un dispositif FTL (Flash Translation Layer) qui opère régulièrement des tâches de maintenance pour limiter les dégâts ; il s’agit en particulier de niveler l’usure en répartissant les données.

Hélas, les opérations du FTL peuvent avoir un effet négatif sur le débit du SSD, augmenter ses temps de latence et, par effet domino, inciter les entreprises à muscler leurs baies avec des unités de stockage en plus pour éviter les pertes de performance. Certaines baies proposent de gérer elles-mêmes les opérations du FTL, mais l’équation économique revient au même puisque, dans ce cas, la baie doit disposer de plus de mémoire cache que d’ordinaire.

Pour pallier les ralentissements inhérents au FTL, surtout visibles dans les grands clusters de stockage, des acteurs comme Alibaba, Microsoft, NetApp et Western Digital ont planché sur la gestion des SSD en amont du stockage. C’est dans le cadre de cet effort commun que le consortium NVM Express Technical Working Group a développé la norme ZNS, dans le but d’aligner directement les besoins des serveurs avec les capacités des SSD.

L'interface ZNS étend le protocole NVMe en lui ajoutant un espace d'adresses logiques, à la manière des adresses en RAM, qui permet aux logiciels côté serveur de cibler des zones spécifiques sur les SSD.

Vers un stockage par zone depuis les serveurs

Les commandes ZNS intègrent de nombreux principes de fonctionnement issus des architectures Open-Channel précédemment conçues pour améliorer les contrôleurs internes des SSD. Un SSD avec contrôleur Open-Channel expose son espace de stockage sous la forme de blocs ayant chacun une adresse ; c’est le LBA, ou Logical Block Address. Le contrôleur s’en sert pour mieux gérer le placement des données, les opérations d’entrée-sortie et d'autres processus.

Le LBA est divisé en chunks – des « morceaux » – qui regroupent des blocs de cellules NAND et dont la taille est définie par la taille des secteurs dans le firmware du SSD. Les blocs doivent être écrits les uns après les autres dans l’ordre de leur adressage, mais ils peuvent être lus dans n’importe quel ordre.

En adaptant les commandes internes de l’Open-Channel au protocole NVMe piloté par le serveur, ce dernier a donc tout le loisir d’écrire lui-même des données aux endroits qui ne sont pas en cours de maintenance par le FTL ou vers certains chunks afin de minimiser les interventions du FTL. Le ZNS divise le LBA en zones de la même manière que l’Open-Channel le divise en chunks. La connaissance de ces zones côté serveur permet ainsi de regrouper physiquement les écritures par application, ce que ne sait pas faire un SSD.

Le jeu de commandes ZNS s'aligne par ailleurs sur les jeux de commandes ZBC (Zoned Block Command) et ZAC (Zoned-device ATA Command) qui servaient déjà prendre en charge l’alignement SMR des pistes sur les disques durs SAS et SATA. Le principe du SMR n’a rien à voir avec les disques SSD – il consiste à juxtaposer les pistes, à la manière des tuiles sur un toit, pour maximiser la capacité d’un disque dur magnétique. En revanche, il implique de la même manière que le contrôleur du disque, voire le système de fichiers du serveur, prennent en compte de la même manière des zones où il vaut mieux écrire les nouvelles données.

La correspondance du jeu de commandes ZNS avec ceux de ZBC et ZAC doit faciliter l'intégration de ZNS dans les systèmes qui prennent déjà en charge le SMR. En théorie, les systèmes de fichiers compatibles SMR devraient pouvoir fonctionner avec le ZNS moyennant un minimum de modifications. Il devrait même être également plus facile de développer des systèmes de fichiers qui prennent directement en charge à la fois des SSD et des disques durs traditionnels dans un même volume.

Les bénéfices pratiques de ZNS

ZNS promet d'offrir plusieurs avantages pratiques. Les écritures devraient prendre moins de temps car les zones s'alignent mieux sur la géométrie physique des SSD, ce qui élimine la nécessité de déplacer, d'effacer et de réécrire constamment les données. De plus, cette meilleure répartition devrait permettre de mieux économiser l’espace et donc éviter aux entreprises de se suréquiper en SSD.

Un autre avantage du ZNS est que les besoins en mémoire cache pour accélérer les accès et en temps de calcul pour savoir où écrire les données sont déplacés sur les serveurs, ce qui permet de produire des baies de stockage moins musclées et, donc, moins chères. Ces charges de travail étant minimales pour un serveur, elles devraient être sans conséquence sur ses performances, mais elles améliorent les performances et la durée de vie du stockage.

Les bénéfices de ZNS se feront surtout ressentir sur les grands clusters de stockage et, de fait, son développement vise surtout à répondre aux besoins des grands fournisseurs de cloud public, les « hyperscalers », qui ont l’impératif de rentabiliser le moindre élément d’infrastructure.

L’adoption à grande échelle n’est pas pour tout de suite

Reste que l’implémentation de ZNS doit se faire à chaque extrémité du protocole NVMe, dans les systèmes des serveurs, mais aussi dans les SSD eux-mêmes. Western Digital propose déjà un prototype. Radian Memory Systems, Samsung et SK Hynix planchent activement sur le leur. Par ailleurs, l’éditeur SANBlaze Technology, un spécialiste des tests de protocoles de stockage, a récemment annoncé qu'il ajoutait la prise en charge de ZNS à sa plateforme de validation et de tests.

D'autres fournisseurs devraient se lancer, maintenant que la spécification ZNS a été ratifiée. Néanmoins, il est probable que le chemin à parcourir jusqu’à une large adoption soit encore long. Voire qu’il soit semé d’embûches : l’Open-Channel était lui-même censé devenir une norme, mais les implémentations diffèrent finalement d’un fabricant de SSD à l’autre. Le consortium NVM Express que cela ne se reproduira pas avec les implémentations de ZNS.