Stockage en cloud : ZettaLane propose des services alternatifs

Une licence + une VM + du stockage bas coût = du stockage haut de gamme moins cher

Techniquement, MayaNAS et MayaScale reposent sur les services de stockage « premiers prix » que proposent AWS, GCP et Azure. Mais leur utilisation est dopée par les logiciels contrôleurs que ZettaLane Systems a mis au point et qui s’exécutent depuis des machines virtuelles hébergées dans le même cloud.

L’intérêt économique repose sur le fait que ces services basiques, les VM qui les contrôlent et les licences des logiciels de ZettaLane Systems embarqués dans ces VM coûteraient ensemble beaucoup moins cher que les services haut de gamme commercialisés clés en main par les hyperscalers, alors que les vitesses atteintes sont similaires.

Précisons que LeMagIT s’est efforcé de simuler des tarifs comparatifs entre les offres de ZettaLane Systems et les services de stockage des hyperscalers. Mais ces derniers compliquent tellement le calcul avec tantôt des éléments granulaires (au Go ou à l’IOPS près), tantôt au forfait selon la période que nous avons dû jeter l’éponge. ZettaLane Systems invite les entreprises à le contacter pour des comparatifs personnalisés.

En termes financiers, MayaNAS et MayaScale sont facturés comme une option dans les catalogues des hyperscalers, en sus des machines virtuelles et des services de stockage auxquels l’entreprise cliente doit aussi souscrire pour les faire fonctionner.

Le coût des logiciels de ZettaLane Systems est fonction du nombre de vCPU dans les machines virtuelles qui les exécute. Il faut compter d’environ 35 dollars par mois et par vCPU pour MayaNAS et environ 75 $/mois/vCPU pour MayaScale.

ZFS conjugué à un pilote maison pour transformer de l’objet en super fichier

MayaNAS se sert de la capacité des services AWS S3, GCP GCS (Google Cloud Storage) et Azure Blob, soit du stockage objet, pour exposer des fichiers au protocole NFS, via des machines virtuelles qui exécutent une version améliorée du système de stockage Open source ZFS. C’est sur GCP que les performances sont les meilleures :

• 2,9 Go/s en lecture et 2,3 Go/s en écriture via une VM contrôleur de 16 vCPU et 64 Go de RAM (soit un coût d’environ 550 $/mois pour la licence du logiciel)
• 3,5 Go/s en lecture et 2,9 Go/s en écriture via une VM contrôleur de 32 vCPU et 128 Go de RAM (soit environ 1100 $/mois pour la licence)
• 4 Go/s en lecture et 3,1 Go/s en écriture via une VM contrôleur de 48 vCPU et 192 Go de RAM (1650 $/mois pour la licence).

Sur AWS, une VM contrôleur de 36 vCPU et 96 Go de RAM permettra aux applications d’accéder à leurs fichiers à la vitesse de 3 Go/s en lecture et environ 2,35 Go/s en écriture. Que ce soit chez AWS comme chez GCP, MayaNAS peut en option utiliser deux VM contrôleur pour un fonctionnement actif-actif qui double pratiquement les débits en lecture et en écriture d’une connexion NFS.

Concernant Azure, une première version est évoquée, mais avec des performances, pour l’heure, bizarrement faibles : la startup indique un débit en lecture compris entre 400 et 800 Mo/s. Il est probable qu’il s’agisse des performances mesurées sur une configuration dotée de seulement 4 vCPU et 16 Go de RAM, celle-ci étant mentionnée (avec d’autres, plus puissantes) dans la documentation préliminaire de MayaNAS sur Azure. La possibilité de doubler les débits avec deux VM n’est pas encore citée sur le cloud de Microsoft.

Le secret des bonnes performances de MayaNAS tient en partie à l’utilisation par ZFS de blocs de données de très grande taille, jusqu’à 1 Mo, là où les systèmes de fichiers ordinaires utilisent plutôt des tailles de 4 Ko ou 64 Ko. Cette particularité fait de MayaNAS un service de stockage surtout conçu pour l’utilisation de gros fichiers, d’où le fait qu’il s’adresse plutôt à des entreprises dans les médias, ou pour l’entraînement d’IA à partir d’importantes bases de données vectorielles qu’il faut charger d’un coup en mémoire.

Surtout, le code Open source de ZFS est combiné ici à un pilote appelé objbacker.io, développé par Zettalane Systems. C’est ce pilote qui permet à ZFS de lire/écrire des blocs de fichiers dans un stockage objet.

« D’ordinaire, pour présenter le contenu d’un stockage objet sous la forme d’un système de fichiers, il faut passer par un pilote FUSE, de sorte que ZFS communique avec FUSE, lequel communique avec un système de stockage objet générique. Mais ce fonctionnement est un double goulet d’étranglement », explique Sam Sammandan.

« Objbacker.io annule ce ralentissement en étant, d’une part, un module VDEV intégré au fonctionnement de ZFS et en étant, d’autre part, compilé avec les SDK d’AWS et de GCP pour parler à leurs systèmes de stockage au plus bas niveau, sans même passer par les commandes S3 de haut niveau », ajoute-t-il.

MayaScale pour transformer un cluster de VM en SDS

MayaScale est pour sa part l’équivalent d’un SDS (Software-Defined Storage), soit une baie de stockage virtuelle, accessible en mode bloc via les protocoles iSCSI ou NVMe/TCP. Son usage principal est d’héberger les contenus des bases de données SQL, mais aussi les images disques d’un cluster VMware ou Hyper-V.

Cette baie est assemblée à partir des SSD NVMe directement accrochés à autant de VM que nécessaires pour former un seul pool de stockage. Contrairement à MayaNAS, les VM utilisées servent ici autant de nœuds de contrôle que de nœuds de stockage. Il n’y a pas de stockage supplémentaire à souscrire. Et l’on n’est plus limité à deux contrôleurs pour un stockage : comme dans une infrastructure hyperconvergée, on peut en ajouter à l’infini.

Cette fois-ci, les performances sont similaires entre GCP et AWS, mais les nœuds d’AWS offrent beaucoup plus de capacité de stockage (pour un prix également plus élevé, précise la startup). Par exemple :

• GCP : 2,3 millions d’IOPS en lecture et 733 000 IOPS en écriture sur chaque nœud de 64 vCPU apportant 6 To de stockage NVMe au pool
• AWS : 1,35 million d’IOPS en lecture et 528 000 IOPS en écriture sur chaque nœud de 48 vCPU apportant 30 To de stockage NVMe au pool
• GCP :  900 000 IOPS en lecture et 350 000 IOPS en écriture sur chaque nœud de 32 vCPU apportant 3 To de stockage NVMe au pool
• AWS :  922 000 IOPS en lecture et 368 000 IOPS en écriture sur chaque nœud de 24 vCPU apportant 15 To de stockage NVMe au pool

Comme pour MayaNAS, MayaScale est encore en test sur Azure. Les chiffres préliminaires partagés par ZettaLane Systems suggèrent des performances similaires aux deux autres clouds et des capacités par nœud comparables à celles d’AWS.

Sur le plan technique, en plus d’exposer un accès en mode bloc aux autres machines virtuelles et containers du même hyperscaler, le logiciel de ZettaLane Systems embarqué dans les VM de contrôle/stockage peut aussi effectuer une sorte de RAID 1 entre deux nœuds, soit une utilisation en miroir des SSD.

Cela signifie deux choses. D’abord, sur un pool de dix nœuds cumulant, par exemple, 150 To de stockage brut, seuls 75 To sont utilisables dans ce mode, puisque les nœuds sont redondants deux à deux. Ensuite, outre garantir qu’il existe encore une copie des données accessible en cas de plantage d’un nœud, cette redondance sert surtout à équilibrer la charge : un nœud peut répondre à une requête de lecture pendant que son jumeau termine une écriture.

« Le RAID n’est pas intégré dans les services de stockage en mode bloc des hyperscalers. Pour assurer la redondance, il faut que les VM clientes écrivent deux fois vers une paire de nœuds. Avec notre système, le client n’écrit qu’une fois et, en tâche de fond, le nœud qui vient de recevoir des données les copie vers son jumeau. Encore une fois, cela réduit les goulets d’étranglement au profit des applications », explique Sam Sammandan.

Demain, un cluster de contrôleurs pour MayaNAS et du Kubernets pour MayaScale

Point particulier, même s’il s’agit d’un service de stockage en mode bloc, MayaScale peut aussi s’utiliser en mode fichier. Soit par l’intermédiaire d’un pilote spécialement développé par Zettalane Systems pour AWS, qui fait passer MayaScale pour un service de fichiers FSx. Soit simplement par l’activation de la couche ZFS déjà utilisée dans MayaNAS.

L’intérêt d’utiliser plusieurs contrôleurs montés en parallèle dans MayaScale + ZFS, plutôt qu’un ou deux contrôleurs dans MayaNAS est de paralléliser les accès entre clients. Cela dit, cette possibilité sera bientôt aussi accessible aux utilisateurs du moins cher MayaNAS avec l’arrivée du support de pNFS qui permettra à MayaNAS de fonctionner avec un cluster de contrôleurs.

Parmi les autres développements en cours, citons l’arrivée d’un partage au protocole Lustre pour MayaNAS, ce qui revient peu ou prou à du pNFS, à la différence que Lustre est utilisé par les applications de supercalcul.

MayaScale devrait de son côté gagner un pilote CSI qui permettra d’utiliser son stockage bloc depuis des containers Kubernetes. Zettalane Systems ne s’est pas prononcé sur des dates de disponibilité.