1.6 TB/s sur AWS, ce n'est pas le gros titre pour Cloud Native Qumulo

Cloud Native Qumulo est passé à 1,6 TB/s sur AWS, et ce n'est même pas le meilleur. Voici ce que cela signifie pour vous.

Depuis des années, les entreprises clientes expriment les mêmes préoccupations à l'égard de l'informatique dématérialisée :

"Il n'est tout simplement pas assez rapide
"Même si c'était le cas, nous ne pouvons pas obtenir de manière fiable suffisamment de calculs dans une seule zone de disponibilité."

Un client a clairement exprimé le défi :

"Nous devons dépasser 1,5 TB/s de débit continu dans le nuage, sans sacrifier la fiabilité ou la flexibilité

Le "B" majuscule de TB est important. Il s'agit d'octets et non de bits. Un octet équivaut à huit bits, de sorte que 1,5 TB/s correspond à environ 12 térabits par seconde de mouvement continu de données. Et ce débit soutenu est tout aussi important. Il ne s'agit pas d'une rafale de courte durée ou d'un pic assisté par le cache, mais d'un débit continu maintenu dans le temps. 

Pour replacer ce chiffre dans son contexte, la diffusion en continu d'un seul film 4K nécessite généralement environ 25 mégabits par seconde. À 12 Tb/s, le même système pourrait théoriquement prendre en charge près de un demi-million flux 4K simultanés.

Et pour ceux qui se posent la question, Qumulo CNQ a relevé le défi, atteignant 1,6 To/s et 20,7 millions d'IOPS, mais nous y reviendrons plus tard. 

En fait, les chiffres de performance seuls n'ont jamais été la véritable préoccupation. Peu d'entreprises ont besoin de 1,5 TB/s aujourd'hui, mais l'expérience nous montre que planifier uniquement en fonction de la demande actuelle est rarement une bonne chose. Construire des systèmes de haute performance à partir de ressources en nuage est souvent une question de budget, de tolérance au risque et de fragilité du système. En effet, construire uniquement pour la vitesse est un excellent moyen de tutoyer le directeur financier dans de nombreuses organisations - mais pas dans le bon sens du terme. La combinaison de la vitesse et d'une architecture d'infrastructure fragile peut résoudre temporairement un problème, mais elle crée par ricochet de nombreux autres problèmes technologiques et économiques.

La résolution du problème fondamental de la flexibilité architecturale nécessite une nouvelle réflexion. 

La plupart des plateformes de stockage en nuage obligent les clients à prendre rapidement des décisions en matière d'infrastructure à long terme. Les performances, la disponibilité et le coût sont étroitement liés, ce qui nécessite un surprovisionnement pour les pics de demande, la duplication des données pour la résilience ou l'ancrage des charges de travail à des emplacements spécifiques. Une fois ces choix faits, il est difficile et coûteux de les annuler.

En conséquence, le stockage devient la contrainte autour de laquelle les équipes de calcul planifient plutôt qu'une base flexible qui s'adapte à l'évolution des charges de travail.

La meilleure question que les clients devraient se poser n'est pas "Quelle est la vitesse de cet engin ?"

La question est la suivante : L'informatique dématérialisée peut-elle fournir des performances extrêmes quand j'en ai besoin, sans m'enfermer dans des architectures fragiles, un stockage dupliqué ou une infrastructure surprovisionnée en permanence ?

Qumulo a relevé ce défi avec sérieux. Non pas en recherchant un chiffre qui fait la une des journaux, mais en prouvant un modèle opérationnel différent. C'est la raison pour laquelle 1,6 To/s n'est PAS LE CHIFFRE D'AFFAIRES. Vous pourriez vous demander : "Qumulo, si la mise à l'échelle à 1,6 To/s sur AWS, n'est pas le titre, qu'est-ce qui l'est ?"

Et si le vrai titre n'était pas du tout la vitesse, mais la suppression des contraintes zonales sans payer de taxe économique ?

La réponse commence par une architecture "cloud-native", et non par une architecture modernisée.

1import os
2import sys
3from datetime import datetime
4import libnfs
5
6os.environ['LD_LIBRARY_PATH'] = "/var/task/lib:/var/task/libnfs:" + os.environ.get('LD_LIBRARY_PATH', '')
7sys.path.append('/var/task')
8
9def handler(event, context):
10    try:
11        nfs = libnfs.NFS("nfs://YOUR_CNQ_ADDRESS/YOUR_NFS_EXPORT")
12    except Exception as e:
13        return {"statusCode": 500, "body": "Error connecting to NFS export: " + str(e)}
14    
15    try:
16        timestamp = datetime.now().isoformat()
17        message = f"Hello from AWS Lambda via CNQ! - {timestamp}\n"
18        
19        f = nfs.open("/testing-from-lambda.txt", "w+")
20        f.write(message)
21        f.close()
22    except Exception as e:
23        return {"statusCode": 500, "body": "Error writing to file: " + str(e)}
24    
25    try:
26        f = nfs.open("/testing-from-lambda.txt", "r")
27        content = f.read()
28        return {"statusCode": 200, "body": content}
29    except Exception as e:
30        return {"statusCode": 500, "body": "Error reading file: " + str(e)}
31
32Built for the Cloud from the Beginning

L'architecture de Qumulo a été conçue pour l'informatique en nuage, et non adaptée à celle-ci. Cette distinction est importante.

La plupart des systèmes de stockage de fichiers en nuage n'ont pas échoué en raison d'une mauvaise exécution. Ils ont échoué parce qu'ils ont hérité des hypothèses d'une époque définie par le matériel et n'ont jamais été entièrement réarchitecturés pour des opérations basées sur le cloud.

Les systèmes de fichiers traditionnels reposaient sur une vérité physique simple : le matériel de stockage définissait à la fois la capacité et les performances. Plus de disques signifiait plus d'espace, et plus d'espace signifiait plus de débit. La capacité et les performances étaient physiquement liées. Il n'était pas possible de faire évoluer l'un sans l'autre. Ce modèle était parfaitement logique lorsque les entreprises achetaient des disques rotatifs, installaient des serveurs et câblaient leurs propres réseaux.

Lorsque les fournisseurs de services en nuage ont introduit des services de fichiers gérés, bon nombre de ces hypothèses ont été reprises.

Certains services augmentent automatiquement la capacité, mais les performances restent liées à la quantité de données stockées. D'autres exigent que les clients provisionnent la capacité et le débit en tant qu'attributs fixes. L'élasticité existe, mais elle est limitée par le même couplage que celui qui existait dans les locaux.

Comme les performances et la capacité restent liées, les clients se retrouvent avec deux options peu attrayantes :

• Disposition pour le pic : payer pour une performance et une capacité maximales à tout moment, même lorsque l'utilisation est faible

• Provision pour moyenne : économiser de l'argent jusqu'à ce que les charges de travail se heurtent à un mur et que la performance devienne le goulot d'étranglement

La plupart des équipes choisissent la première option parce que le coût des charges de travail ralenties ou des délais non respectés dépasse de loin le coût du surprovisionnement pourrait est à l'opposé de l'économie des nuages.

Le problème s'aggrave lorsque la diversité des protocoles entre en jeu. Les environnements Linux attendent NFS. Les environnements Windows exigent SMB. Les applications modernes s'appuient de plus en plus sur l'accès aux objets via des API compatibles S3.

Il en résulte une fragmentation. Différents services, différents modèles de mise à l'échelle, différents comportements opérationnels. Les équipes qui exécutent des charges de travail mixtes gèrent souvent plusieurs systèmes de stockage, chacun étant optimisé pour un cas d'utilisation restreint.

Au fil du temps, le stockage devient la contrainte autour de laquelle les équipes de calcul planifient.

"Combien d'espace de stockage avons-nous ? Ils demandent : "Que pouvons-nous faire fonctionner ?"

C'est à l'envers. L'infrastructure doit s'adapter aux charges de travail, et non l'inverse.

Cloud Native Qumulo rompt ce couplage.

Dès le départ, CNQ a séparé la performance de la capacité. Le calcul évolue indépendamment du stockage d'objets durables, les performances étant ajoutées ou supprimées en ajustant les ressources de calcul plutôt qu'en pré-attribuant la capacité. Les clients ne paient que pour le stockage qu'ils consomment, tandis que la performance devient un attribut élastique plutôt qu'un engagement fixe.

CNQ peut ainsi prendre en charge de manière économique les services de fichiers d'entreprise à usage général tout en s'adaptant aux charges de travail spécialisées à haute intensité, sans contraindre les clients à un surprovisionnement permanent ou à des silos de stockage fragmentés.

Le titre est donc clair : CNQ conçu pour l'informatique en nuage, pas adapté à celle-ci. Pourtant, il manque quelque chose.

Le défi : Aller plus vite que sur place, sans filet de sécurité

L'exigence du client n'était pas théorique.

Sur site, la charge de travail est exécutée dans un seul centre de données, le calcul étant placé à proximité du stockage pour minimiser la latence. En cas de défaillance de l'infrastructure, qu'il s'agisse de l'alimentation électrique, du refroidissement ou du réseau, la charge de travail s'arrêtait. La reprise après sinistre existait, mais, comme la plupart des systèmes de reprise après sinistre, elle était asynchrone, peu testée et incapable de soutenir les performances complètes de la charge de travail.

Le système a fonctionné, mais il était fragile.

Traditionnellement, le passage à l'informatique dématérialisée n'a jamais été une question de rapidité. Il s'agissait de supprimer les points de défaillance uniques sans introduire de nouvelles contraintes. Mais si cela pouvait être rapide, quel serait l'impact sur les activités de nos clients ?

Dans le nuage, les attentes étaient claires :

• Dépasser les performances sur site

• Éviter la dépendance à l'égard d'une seule zone de disponibilité

• Maintien des performances en cas de défaillance

• Le faire sans doubler les coûts de stockage

C'est sur cette dernière exigence que de nombreux systèmes de fichiers en nuage échouent.

La plupart des offres de zones de disponibilité multiples utilisent la réplication. Des copies complètes des données sont conservées dans chaque zone pour assurer la disponibilité. Bien qu'efficace pour la durabilité, cette approche a des conséquences réelles. Les coûts de stockage augmentent linéairement avec le nombre de zones. Les performances d'écriture sont réduites en raison de la coordination entre les zones. Les clients réservent la solution Multi-AZ aux scénarios de défaillance plutôt qu'au fonctionnement normal.

Dans le même temps, la disponibilité de l'informatique dans le nuage n'est pas uniformément répartie.

Les charges de travail gourmandes en GPU et en CPU sont souvent confrontées à des contraintes de capacité qui varient d'une zone à l'autre et dans le temps. Une conception qui ancre les données dans une seule zone force le calcul à suivre, même si la capacité existe ailleurs dans la région. Les clients finissent par rechercher des instances, réservent des ressources informatiques avant que les données ne soient prêtes (ce qui est coûteux) ou retardent carrément le travail (ce qui allonge le délai d'obtention des résultats).

Le client a mis Qumulo au défi de la vitesse, de la fiabilité et de la résilience. La solution doit offrir de meilleures performances tout en supprimant la dépendance au niveau de la zone, en éliminant la duplication du stockage et en permettant aux charges de travail de s'exécuter là où la capacité de calcul est disponible à tout moment.

Qumulo résout ce problème au niveau de l'architecture, plutôt que de superposer la disponibilité à des hypothèses héritées du passé.

L'architecture : Zone de disponibilité multiple par conception, pas par duplication

Au cœur de ce déploiement se trouvait un cluster CNQ multi-zones, réparti uniformément sur trois zones de disponibilité au sein d'une même région AWS.

Une zone de disponibilité, ou AZ, est un ensemble physiquement séparé d'un ou plusieurs centres de données au sein d'une région AWS. Chaque Z est conçue pour fonctionner de manière indépendante, avec sa propre alimentation, son propre refroidissement et son propre réseau, tout en étant connectée aux autres Z de la région par des liens à large bande passante et à faible latence. Cette séparation permet aux applications de rester disponibles même si un centre de données entier subit une panne.

La durabilité est assurée par Amazon S3 au niveau régional, où les données sont automatiquement protégées dans plusieurs installations. C'est la raison pour laquelle AWS offre une durabilité de 11 neuf (99,999999999%), largement considérée comme la référence du secteur en matière de protection des données.

De par sa conception, l'architecture de CNQ couvre plusieurs zones de disponibilité AWS sans nécessiter de répliques complètes des données des clients dans chaque zone. Il en résulte que :

• Le coût du stockage est identique, que CNQ fonctionne dans une ou plusieurs zones de stockage

• Les performances en écriture ne sont pas pénalisées par la réplication inter-zones

• L'opération Multi-AZ est un état normal et non un mode de défaillance

Note : En règle générale, les services multi-zones coûtent deux fois plus cher que les services mono-zones. Le fait de maintenir le coût au même niveau constitue un avantage économique important. 

Si une zone de disponibilité devient indisponible, le cluster continue de fonctionner dans les zones restantes sans perte de données et sans qu'il soit nécessaire de basculer sur une copie secondaire.

Cette conception est plus simple, plus rapide et matériellement moins chère que les approches multi-AZ basées sur les répliques.

Il serait facile d'en faire le titre : L'architecture CNQ offre une résilience multi-zones sans duplication des données. Ce n'est pas faux. Mais nous pouvons faire encore mieux. 

L'avantage de la zone de multi-disponibilité CNQ pour les charges de travail intensives en GPU

Multi-AZ est généralement considéré comme une fonction de disponibilité, ce qui est très bien, mais de nos jours, la disponibilité est considérée comme un enjeu de table. Ce qui compte vraiment, c'est ce que CNQ débloque pour le calcul, à savoir rendre l'acquisition de GPU et de CPU beaucoup moins pénible. 

La plupart des systèmes de fichiers en nuage, même ceux qui sont commercialisés comme étant multi-zones, ancrent le stockage dans une seule zone primaire. Le calcul doit suivre les données. Si les GPU ou les CPU ne sont pas disponibles dans cette zone, la charge de travail reste bloquée, même si une capacité inutilisée existe ailleurs dans la région.

Cela oblige les équipes à rechercher des GPU et des CPU. Tout d'abord, elles recherchent des instances de calcul rares. Ensuite, elles réservent et paient pour cet ordinateur avant de pouvoir l'utiliser. Vient ensuite le problème des données. Les grands ensembles de données doivent être copiés ou réorganisés là où l'ordinateur a été trouvé. Ce n'est qu'une fois toutes ces étapes terminées que le travail peut reprendre. CNQ supprime cette contrainte.

Avec CNQ, l'informatique dans plusieurs zones de disponibilité peut accéder simultanément au même ensemble de données. Les clients peuvent regrouper la capacité des différentes zones en un seul pool logique sans avoir à copier ou à réorganiser les données.

Si les GPU sont disponibles dans une zone le lundi et dans une autre le mardi, les clients n'ont pas à déplacer les données ou à reconstruire l'infrastructure. Ils orientent simplement le déploiement CNQ existant vers l'endroit où le calcul est disponible.

Du point de vue du client, cela permet :

• Accès plus rapide aux GPU et CPU rares

• Pas de phases de réapprovisionnement ou de copie des données

• Pas de pénalités de réplication

• Pas d'augmentation des coûts de stockage

Le travail peut commencer immédiatement car les données existent déjà dans chaque zone de disponibilité au sein de S3, qui sert de couche de stockage persistant. Contrairement à l'Amazon Elastic Block Store (EBS) ou au stockage rattaché à une instance, cette architecture ne nécessite pas de copier ou de réhydrater les données dans chaque zone avant que le calcul ne puisse commencer. Au lieu de cela, le système de fichiers accède aux données localement dans chaque zone de calcul par l'intermédiaire de NeuralCache. Cette approche élimine les efforts de stockage des données pendant des semaines et permet d'utiliser pleinement les ressources de calcul coûteuses dès le départ.

Une fois de plus, vous vous dites peut-être qu'il ne peut s'agir que du titre de l'article : CNQ et l'art de rendre la chasse au GPU supportable. Nous sommes sur la bonne voie. Voyons si nous pouvons faire mieux.

Augmentez les performances autant que vous le souhaitez, puis réduisez-les

Le client a demandé à dépasser 1,5 To/s de débit soutenu dans le nuage, sans sacrifier la fiabilité ou la flexibilité. Qumulo a créé un déploiement de test qui a finalement dépassé les attentes, atteignant 1,6 To/s de débit agrégé soutenu et 20,7 millions d'IOPS. En effet, ces chiffres sont impressionnants (futurs lecteurs, veuillez consulter la date de publication pour le contexte), mais s'agit-il d'exigences maximales ou moyennes ? Et si vous êtes un client qui lit ceci et que vous êtes intéressé par 1,6 To/s et 20,7 millions d'IOPS, ne vous inquiétez pas, nous avons ce qu'il vous faut ! Voir ci-dessous.

De nombreux clients privilégient la flexibilité et ont besoin de pouvoir augmenter ou diminuer les ressources en fonction de l'évolution de la demande. Comme nous l'avons vu précédemment, les clients choisissent souvent entre le provisionnement pour les pics de demande à un coût élevé ou le dimensionnement pour une utilisation moyenne et le risque d'une baisse des performances. Ce compromis met en évidence la valeur fondamentale de l'informatique dématérialisée : la variabilité. Cette configuration peut coûter environ 5 000 dollars par heure, ce qui la rend précieuse en cas de besoin, mais économiquement irréalisable en continu. La possibilité de ne consommer ce niveau de performance qu'en cas de besoin rend une approche basée sur l'informatique dématérialisée économiquement viable par rapport à une infrastructure sur site.

CNQ permet aux clients d'atteindre une performance maximale sans avoir à payer pour une capacité maximale en permanence. C'est là toute la différence.

Avec de nombreux systèmes de fichiers en nuage, les performances sont liées à la capacité provisionnée en permanence. Si vous dimensionnez votre système en fonction des pics, vous payez le prix des pics en permanence, même lorsque la charge de travail diminue.

CNQ découple ces décisions.

Les clients peuvent faire évoluer les performances de manière agressive pour respecter un délai, une fenêtre de formation ou un pic de production, puis les réduire une fois le pic passé. Vous ne vous enfermez pas dans une configuration "redline" juste pour couvrir des pics occasionnels.

Cette élasticité s'applique non seulement à l'échelle, mais aussi au choix des instances. Dans ce déploiement, les types d'instances ont été ajustés à mi-parcours en raison de contraintes de capacité régionales. Le cluster est simplement passé à 250 nœuds, supportant environ 333 000 connexions, en utilisant une bande passante inférieure par nœud, sans nécessiter de reconception.

Par la suite, les clients peuvent passer à des familles d'instances plus récentes à moindre coût grâce à un remplacement progressif, sans temps d'arrêt ni migration de données.

Ensemble, nous avons enfin découvert le titre : CNQ offre Une performance de pointe sans un engagement de pointe. C'est vrai ? Mais pourquoi quelqu'un aurait-il besoin d'un tel niveau de performance ? 

Les moments qui exigent des performances de pointe extrêmes

Toutes les charges de travail n'ont pas besoin d'un débit extrême, et c'est justement là l'intérêt.

L'objectif de cette architecture n'est pas de toujours fonctionner à 1,6 TB/s. Il s'agit d'avoir la possibilité de fonctionner à cette vitesse lorsque le temps est compté, sans être pénalisé financièrement ou opérationnellement le reste du temps.

Ce qui semble excessif aujourd'hui a l'habitude de devenir la référence de demain. Alors, pourquoi avoir besoin d'une telle performance ? 

Prenons l'exemple d'une entreprise du secteur de l'énergie qui décide de louer un puits d'une valeur d'un milliard de dollars. La question n'est pas de savoir si l'analyse coûte quelques millions de plus en frais d'informatique en nuage. La question est de savoir qui trouvera la réponse en premier. Le fait d'être en avance peut déterminer qui sécurisera l'actif et qui repartira les mains vides.

Dans le domaine des soins de santé, une analyse génomique plus rapide peut faire la différence entre une incertitude prolongée et une décision de traitement salvatrice.

Dans le secteur des médias et du divertissement, la rapidité peut déterminer si un projet atteint sa date de sortie ou si les retards se traduisent par des coûts non planifiés qui réduisent les marges bénéficiaires. Un rendu plus rapide, une analyse plus rapide et une itération plus rapide signifient qu'il y a moins d'équipes créatives inactives en attente d'une infrastructure.

Dans tous ces exemples, la contrainte n'est pas la quantité de données pouvant être stockées. C'est le temps nécessaire à la compréhension et à la prise de décision. Lorsque l'infrastructure fournit des réponses plus rapidement, les entreprises ne se contentent pas d'exécuter les charges de travail plus rapidement, elles obtiennent également des résultats plus rapidement. Elles compriment des cycles de décision entiers et tirent davantage de valeur de leur ressource la plus chère et la plus irremplaçable, le temps des experts. 

Imaginez ce que votre entreprise pourrait réaliser lorsque les performances augmentent et diminuent, que vous cessez de payer pour une marge de manœuvre inutilisée et que vous commencez à payer pour des résultats. 

Le titre doit certainement être : N'attendez plus l'infrastructure. CNQ fournit des résultats plus rapidement. Mais est-ce vraiment le cas ? 

L'effet cumulatif

En fournissant 1,6 To/s de débit de lecture séquentielle agrégée soutenue, Qumulo a dépassé l'objectif de performance initial du client de plus de 50 % par rapport aux systèmes sur site. Atteindre ce niveau de performance a nécessité une architecture cloud-native entièrement construite sur l'infrastructure standard AWS et couvrant trois zones de disponibilité.

Plus important encore, ces travaux montrent que des performances extrêmes ne nécessitent pas de compromis inabordables.

Outre le débit de 1,6 TB/s, le système a atteint 20,7 millions d'IOPS avec une latence inférieure à la milliseconde. 

Mais la valeur réelle va au-delà des chiffres. L'architecture permet aux clients d'appliquer le calcul à toutes les zones de disponibilité au lieu d'être confinés à une seule zone, ce qui facilite considérablement l'acquisition de GPU et de CPU à grande échelle. Elle valide également la résilience de CNQ sur AWS, offrant une disponibilité exceptionnelle des données et une durabilité de onze neuf, sans gonfler les coûts de stockage par la duplication. Les clients conservent la flexibilité de choisir des familles d'instances qui correspondent à leurs besoins de performance et à leurs budgets, en ne payant que pour ce qu'ils utilisent réellement.

Prises ensemble, ces capacités créent un effet cumulatif, que nous appelons l'effet de levier Effet cumulatif.

Peut-être que ce n'est pas un seul titre qui doit attirer votre attention. C'est peut-être l'ensemble des titres.

• Qumulo, une solution native dans le nuage, passe à 1,6 To/s sur AWS 

• CNQ a été conçu pour l'informatique en nuage, mais pas adapté à celle-ci

• L'architecture CNQ offre une résilience multi-zones sans duplication des données

• CNQ et l'art de rendre la chasse au GPU supportable

• CNQ offre une performance de pointe sans engagement de pointe

• N'attendez plus l'infrastructure. CNQ fournit des résultats plus rapidement

C'est cette combinaison qui est à l'origine de l'histoire.

À emporter

Ce déploiement a prouvé qu'un système de fichiers natif de l'informatique en nuage peut offrir des performances extrêmes sans compromis :

• Multi-AZ par conception, pas par duplication

• Des performances qui s'améliorent et se réduisent

• Liberté de fonctionner là où le calcul est disponible, et non pas là où les données sont stockées

• Des résultats plus rapides 

L'informatique dématérialisée ne doit pas se contenter d'être suffisamment rapide. Avec la bonne architecture, il peut être plus souple, plus résilient et plus économique que ne l'ont jamais été les systèmes sur site.