jules - Fotolia
Les systèmes de stockage s’adaptent à l’émergence de NVMe et NVMe over Fabrics
La montée en puissance des technologies Flash NVMe et les besoins en matière de latence et d’IOPS devraient se traduire par une évolution en profondeur des architectures de baies de stockage dans les prochaines années.
Au cours des 5 dernières années, l’adoption de la mémoire Flash dans les systèmes de stockage a largement été transparente. La raison est relativement simple. La plupart des baies de stockage se sont contentées de remplacer des disques durs au format SAS par des disques Flash à interface SAS.
Cette transition en douceur touche aujourd’hui à ses limites. Le bus SAS est en bout de course. Et, surtout, il est devenu un goulet d’étranglement pour tirer la quintessence de la Flash et des nouvelles technologies de stockage en mémoire émergente - comme la mémoire Optane d’Intel.
Peu à peu, les constructeurs se convertissent aux joies du bus NVMe et de sa déclinaison réseau NVMe over Fabrics. L’émergence de ces technologies devrait amener les constructeurs à revoir en profondeur la façon dont ils approchent le stockage Flash.
NVMe : un protocole de stockage optimisé pour la Flash
NVMe est un nouveau protocole spécifiquement optimisé pour les technologies de stockage en mémoire persistantes comme la Flash ou Optane. Il s’appuie sur le bus PCI Express comme interface. C’est pourquoi le mot « express » figure dans le nom NVM Express - NVM signifiant bien sûr « mémoire non volatile », qui est l’autre dénomination pour le stockage persistant en mémoire.
Les bénéfices du NVMe sont un niveau accru d’IOPS par cycle CPU, une latence plus faible du fait de la simplification de la pile logicielle d’E/S sur les serveurs, et un niveau de parallélisme accru pour les requêtes d’Entrées/Sorties
Les SSD NVMe utilisent un jeu de commandes simplifié qui permet de réduire le nombre d’instructions CPU nécessaire pour traiter une demande d’E/S par rapport aux disques SAS et SATA. Le protocole NVMe prend en charge jusqu’à 64.000 commandes par file d’attente et jusqu’à 64.000 files d’attente par périphérique, alors que les disques SAS standards ne prennent en charge que 256 commandes dans une seule file d’attente et les lecteurs SATA ne supportent que 32 commandes par file.
Le niveau de performance est spectaculaire. Typiquement, un unique SSD PCIe Micron peut délivrer 750 000 IOPS en lecture et 300 000 IOPS en écriture aléatoire de blocs de 4K.
Mais insérez 24 de ces périphériques dans une baie de stockage ou un serveur et vous vous retrouvez devant un problème de taille : pour la première fois depuis longtemps, le processeur redevient un goulet d’étranglement. Le système n’a tout simplement pas assez de bande passante ou de cycles CPU pour soutenir un tel déluge de données sans affecter la latence d’accès et le nombre d’IOPS.
La situation est encore pire lorsque l’on met en œuvre NVMe over Fabrics. Comme son nom l’indique, NVMeoF a été conçu pour déporter l’usage de NVMe au-dessus d’un réseau Ethernet, Fibre Channel ou Infiniband. Avec NVMe over Fabrics, il devient ainsi possible raccorder des dizaines voire des centaines de périphériques NVMe à un même système.
Des architectures de stockage proche de leurs limites
La question se pose. Comment mettre en œuvre des architectures pour tirer parti de ces capacités et mettre à disposition des utilisateurs le plein potentiel des disques NVMe ?
Pour l’instant, force est de constater que la plupart des constructeurs ont fait une place aux disques NVMe dans leurs systèmes, mais qu’ils sont loin d’en tirer le plein potentiel.
Pure Storage par exemple a annoncé ses baies NVMe FlashArray//X70. Il s’agit de baies traditionnelles bi-contrôleurs, équipées en standard de disques NVMe et délivrant les mêmes services avancés que les autres baies de la marque (thin provisioning, compression, réduplication, snapshots, clones, réplication synchrone et asynchrone, etc.).
Avec 20 modules NVMe, une telle baie devrait être théoriquement capable de délivrer des millions d’IOPS. Mais dans la réalité, selon Pure Storage, la performance IOPS avec des blocs de 8K (avec un ratio de 75 % de lectures et 25 % d’écritures) n’atteint « que » 175 000 IOPS.
Ce simple chiffre illustre le chemin que les constructeurs doivent encore parcourir pour extraire la quintessence des capacités des SSD NVMe.
A la décharge de Pure Storage, 175 000 IOPS sont largement suffisants pour servir les besoins de 90 % des applications d’entreprises. Un tout petit nombre de scénarios ont vraiment un besoin supérieur en matière d’IOPS et de latence. Ceci étant, selon Gartner, les besoins en IOPS augmentent à un rythme de 70 à 100 % par an.
Le constat général est que si les disques durs ont longtemps été l’obstacle à la performance des baies de stockage, les processeurs sont aujourd’hui les composants qui limitent la performance du stockage pour les besoins les plus extrêmes.
Ils le sont d’autant plus que, dans une baie, leur rôle ne se limite pas à transmettre des requêtes d’I/O. Les processeurs délivrent aussi les services riches auxquels se sont habitués les utilisateurs. La compression ou la déduplication sont ainsi des services très consommateurs en ressources CPU et les cycles processeurs qu’ils consomment sont autant de cycles qui ne sont pas disponibles pour traiter des I/O.
L’alternative de baies rapides, mais dépourvues de services avancés
Pour délivrer des performances élevées, l’un des premiers choix d’architecture envisageable est donc d’éliminer ces services avancés. C’est le pari effectué par certains pionniers comme Mangstor qui promet plusieurs millions d’IOPS avec une baie de qui n’est rien d’autre qu’un serveur bourré de cartes NVMe accessibles au travers du réseau Ethernet via le protocole NVMe over Fabrics.
Mais cette approche de type Formule 1 est fragile. Il revient aux applications de gérer la protection des données et les problèmes de résilience. Cela peut être acceptable si l’application est capable de fournir cette redondance - ce qui est le cas d’un moteur de base de données comme Oracle (avec ASM) ou si cette redondance est tout simplement inutile - mais la réalité est que peu d’applications sont adaptées à une telle approche.
Vers une couche de contrôle distribuée
L’autre approche architecturale, qui semble prometteuse, est une approche distribuée. Si quelques CPU ne suffisent pas à délivrer le nombre d’IOPS permis par l’agglomération de multiples disques NVMe, pourquoi ne pas distribuer la charge de contrôle entre de multiples nœuds contrôleurs ?
En clair, pourquoi ne pas créer une architecture de contrôleurs en mode scale-out pour délivrer les services de stockage avancés auxquels sont habitués les clients sans (trop) sacrifier la performance que peuvent délivrer les disques NVMe ?
Le premier à avoir mis en œuvre cette approche est la start-up israélienne E8 Storage. Sa technologie repose sur une baie de stockage rack très standard avec deux contrôleurs reliés à 24 SSD NVMe. Mais la mission de ces deux contrôleurs n’est pas de délivrer des services, plutôt d’assurer une redondance des chemins d’accès aux disques NVMe.
L’essentiel des fonctions de contrôle est distribué dans chacun des serveurs accédant à la baie E8. Un maximum de 96 serveurs peuvent ainsi se connecter simultanément à la baie via un pilote qui est, en fait, une instance distribuée du plan de contrôle de la baie E8. Résultat, la performance agrégée peut atteindre 10 millions d’IOPS et une bande passante agrégée de 40 Go/s en lecture.
Une autre start-up, Excelero, a fait un pari assez similaire mais en faisant totalement l’impasse sur la baie de stockage externe. Son logiciel se déploie sur des serveurs traditionnels chacun équipé de quelques disques NVMe. Ensemble, ces serveurs créent un pool de stockage Flash distribué à haute performance. Un cluster de 10 serveurs avec un total de 80 disques NVMe est ainsi capable de délivrer plus de 20 millions d’IOPS et de soutenir une bande passante agrégée en lecture de 230 Go/s.
Sans aller jusqu’à ces extrêmes des acteurs du stockage plus établis ont pris notes des approches de ces nouveaux venus et ont bien l’intention de s’en inspirer pour le futur. NetApp, Kaminario et Pure Storage semblent ainsi avoir des approches similaires pour transformer leurs architectures existantes.
L’idée de ces constructeurs est la suivante. La première étape consiste à éliminer le recours aux interfaces SAS dans leurs contrôleurs de stockage pour les remplacer par PCIe pour les périphériques internes et Ethernet (en fait NVMe over Ethernet) pour la connexion de tiroirs de disques externes. Ensuite les tiroirs de disques externes SAS sont remplacés par des tiroirs externes NVMe over fabrics, ce que l’on appelle désormais des JBOF (pour « just a bunch of Flash »). Un JBOF est un serveur minimaliste doté de multiples interfaces Ethernet à très haut débit et de contrôleurs minimalistes x86 ou ARM offrant suffisamment de ports PCIe pour gérer 24 SSD NVMe et délivrant suffisamment de performances pour traiter les requêtes I/O provenant des contrôleurs.
L’enjeu est ensuite de réécrire l’OS des contrôleurs afin de distribuer la couche de services de stockage entre de multiples contrôleurs. Le client pourra ensuite déployer autant de contrôleurs que nécessaire en mode scale-out pour délivrer la performance requise par son environnement.
Dans cette course à la transformation, Kaminario a pris une petite longueur d’avance. Le constructeur devrait proposer une première version commerciale de sa technologie dans le courant du premier semestre 2018.
Pure Storage a évoqué une vision similaire lors de sa conférence Pure Accelerate en mai 2017. Mais à ce jour, son OS n’a pas encore été modifié pour fonctionner en mode scale-out. L’arrivée d’un OS en mode scale-out pour piloter de future baies FlashArray semble en tout cas inévitable.
Enfin, NetApp ne cache pas son intention d’évoluer dans la même direction. Son avantage est que son système d’exploitation OnTap fonctionne déjà en mode scale out. Cela ne veut toutefois pas dire qu’un système NVMe over Fabrics arrivera rapidement chez le constructeur. NetApp semble en effet estimer qu’une telle approche reste pour l’instant hors de portée de la plupart des bourses. Et si sa technologie logicielle est théoriquement prête, la firme ne se lancera sans doute que lorsque le marché sera jugé suffisamment gros pour justifier la production d’une nouvelle baie.
La question est désormais de savoir à quelle vitesse vont continuer à progresser les besoins en IOPS des entreprises et leur appétit pour moins de latence. Au rythme actuel, ces futures architectures pourraient devenir banales dans les trois prochaines années.