Qumulo, solution native du cloud, a atteint une capacité de 1.6 To/s sur AWS, et ce n'est pas tout ! Voici ce que cela signifie pour vous.
Depuis des années, les entreprises clientes expriment la même préoccupation concernant le cloud :
« Ce n'est tout simplement pas assez rapide. »
« Même si c'était le cas, nous ne pouvons pas garantir une puissance de calcul suffisante dans une seule zone de disponibilité. »
Un client a clairement exprimé le problème :
« Nous devons dépasser 1.5 To/s de débit soutenu dans le cloud, sans sacrifier la fiabilité ni la flexibilité. »
Le « TB » majuscule est important. Il s'agit d'octets, et non de bits. Un octet équivaut à huit bits ; ainsi, 1.5 TB/s correspond à environ 12 térabits par seconde de transfert de données continu. Et le caractère continu est tout aussi important. Il ne s'agit pas d'une brève accélération ni d'un pic dû à la mise en cache, mais d'un débit constant maintenu dans le temps.
Pour mettre ce chiffre en perspective, la lecture en continu d'un seul film 4K nécessite généralement environ 25 mégabits par seconde. À 12 Tbit/s, le même système pourrait théoriquement supporter près de 12 Tbit/s. 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 reviendrons sur ce point plus tard.
En réalité, les performances pures n'ont jamais été le seul enjeu. Rares sont les entreprises qui ont besoin de 1.5 To/s aujourd'hui, mais l'expérience nous apprend que planifier uniquement en fonction de la demande actuelle se solde rarement par un succès. La construction de systèmes haute performance à partir de ressources cloud est souvent une question de budget, de tolérance au risque et de fragilité du système. En effet, privilégier la vitesse à tout prix est un excellent moyen de se mettre à dos le directeur financier dans de nombreuses organisations – et pas forcément de la meilleure façon. Combiner vitesse et architecture d'infrastructure fragile peut certes résoudre temporairement un problème, mais cela engendre de nombreux autres défis technologiques et économiques en cascade.
Résoudre le problème fondamental de la flexibilité architecturale exige une nouvelle approche.
La plupart des plateformes de stockage cloud obligent leurs clients à prendre des décisions d'infrastructure à long terme très tôt. Performance, disponibilité et coût sont étroitement liés, ce qui implique de surdimensionner les ressources pour faire face aux pics de demande, de dupliquer les données pour assurer la résilience, ou encore d'ancrer les charges de travail à des emplacements spécifiques. Une fois ces choix effectués, il est difficile et coûteux de les modifier.
De ce fait, le stockage devient la contrainte autour de laquelle les équipes informatiques planifient leurs ressources, plutôt qu'une base flexible qui s'adapte à l'évolution des charges de travail.
La question que les clients devraient se poser n'est pas : « À quelle vitesse peut aller cet engin ? »
La question est la suivante : le cloud peut-il fournir des performances extrêmes lorsque j'en ai besoin, sans m'enfermer dans des architectures fragiles, un stockage dupliqué ou une infrastructure surdimensionnée en permanence ?
Qumulo a relevé ce défi avec sérieux. Non pas en cherchant à tout prix un chiffre impressionnant, mais en prouvant l'efficacité d'un modèle opérationnel différent. C'est pourquoi 1.6 To/s n'est PAS LE CHIFFRE D'AFFICHAGE. Vous pourriez vous demander : « Qumulo, si passage à une capacité de 1.6 To/s sur AWS, « Ce n'est pas le titre, c'est quoi ? »
Et si le vrai sujet n'était pas du tout la vitesse, mais la suppression des contraintes zonales sans payer de taxe économique ?
La solution réside dans une architecture native du cloud, et non dans une architecture adaptée a posteriori.
Conçu pour le cloud dès le départ
L'architecture de Qumulo a été conçue pour le cloud, et non adaptée à celui-ci. Cette distinction est importante.
La plupart des systèmes de stockage de fichiers dans le cloud n'ont pas échoué en raison d'une mauvaise exécution. Leur échec est dû au fait qu'ils ont hérité d'hypothèses d'une ère où le matériel était prédominant et qu'ils n'ont jamais été entièrement repensés pour les opérations dans le cloud.
Les systèmes de fichiers traditionnels reposaient sur un principe physique simple : le matériel de stockage déterminait à la fois la capacité et les performances. Plus de disques signifiaient plus d’espace, et plus d’espace signifiait un débit plus élevé. Capacité et performances étaient physiquement liées. Il était impossible d’augmenter l’une sans l’autre. Ce modèle était parfaitement logique à l’époque où les entreprises achetaient des disques durs, installaient leurs serveurs en rack et câblaient leurs propres réseaux.
Lorsque les fournisseurs de services cloud ont introduit les services de fichiers gérés, bon nombre de ces mêmes hypothèses ont été conservées.
Certains services adaptent automatiquement leur capacité, mais leurs performances restent liées à la quantité de données stockées. D'autres exigent que les clients configurent conjointement la capacité et le débit comme des attributs fixes. L'élasticité existe, mais elle est limitée par le même couplage qu'auparavant.
Étant donné que les performances et la capacité restent liées, les clients se retrouvent avec deux options peu attrayantes :
- Dispositions pour les périodes de pointe : Rémunérer en permanence pour une performance et une capacité maximales, même en cas de faible utilisation.
- Provision pour moyenne : Économisez de l'argent jusqu'à ce que la charge de travail atteigne un plafond et que les performances deviennent le goulot d'étranglement.
La plupart des équipes choisissent la première option car le coût des charges de travail réduites ou des délais non respectés dépasse largement le coût du surdimensionnement ; cependant, payer pour ce que vous pourrait Le besoin est l'opposé de l'économie du cloud.
Le problème se complexifie avec la diversité des protocoles. Les environnements Linux privilégient NFS, tandis que les environnements Windows requièrent SMB. Les applications modernes, quant à elles, 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 exécutant des charges de travail mixtes gèrent souvent plusieurs systèmes de stockage, chacun optimisé pour un cas d'utilisation spécifique.
Avec le temps, le stockage devient la contrainte autour de laquelle les équipes informatiques planifient leurs opérations.
« De quelle capacité de stockage disposons-nous ? » demandent-ils. « Que pouvons-nous exécuter ? »
C'est une approche erronée. L'infrastructure doit s'adapter aux charges de travail, et non l'inverse.
Qumulo, solution native du cloud, rompt ce couplage.
Dès sa conception, CNQ a dissocié les performances de la capacité. La puissance de calcul évolue indépendamment du stockage objet durable ; les performances sont ajustées en fonction des ressources de calcul, sans préallocation de capacité. Les clients ne paient que pour le stockage qu’ils consomment, les performances devenant ainsi une caractéristique flexible et non un engagement fixe.
Cela permet à CNQ de prendre en charge les services de fichiers d'entreprise à usage général de manière économique, tout en s'adaptant aux charges de travail spécialisées et intensives sans contraindre les clients à un surdimensionnement permanent ou à des silos de stockage fragmentés.
Voilà qui rend le titre clair : CNQ conçu pour le cloud, et non adapté à celui-ci. Pourtant, j'ai l'impression qu'il manque quelque chose.
Le défi : aller plus vite qu’en présentiel, sans filet de sécurité
Le besoin du client n'était pas théorique.
Sur site, la charge de travail s'exécutait dans un seul centre de données, les serveurs de calcul étant situés à proximité du stockage afin de minimiser la latence. En cas de défaillance de l'infrastructure (alimentation électrique, refroidissement ou réseau), la charge de travail s'arrêtait. Un plan de reprise d'activité existait, mais, comme la plupart des systèmes de ce type, il était asynchrone, peu testé et incapable de maintenir les performances maximales de la charge de travail.
Le système fonctionnait, mais il était fragile.
Traditionnellement, la migration vers le cloud n'était pas une question de rapidité. Il s'agissait d'éliminer les points de défaillance uniques sans introduire de nouvelles contraintes. Mais si elle pouvait être rapide, quel impact cela aurait-il sur les activités de nos clients ?
Dans le cloud, les attentes étaient claires :
- Dépasser les performances sur site
- Évitez de dépendre d'une seule zone de disponibilité.
- Maintenir des performances optimales en cas de panne
- Faites-le sans doubler les coûts de stockage
C’est sur ce dernier point que de nombreux systèmes de fichiers cloud pêchent.
La plupart des offres multizones utilisent la réplication. Des copies complètes des données sont conservées dans chaque zone pour garantir la disponibilité. Bien qu'efficace pour la durabilité, cette approche a des conséquences non négligeables. 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 interzone. Le multizone devient alors une solution réservée aux situations de panne plutôt qu'au fonctionnement normal.
Parallèlement, la disponibilité des ressources de calcul dans le cloud n'est pas répartie de manière uniforme.
Les charges de travail gourmandes en ressources GPU et CPU sont souvent confrontées à des contraintes de capacité variables selon la zone et dans le temps. Une architecture qui associe les données à une seule zone impose une adaptation des ressources de calcul, même lorsque des capacités existent ailleurs dans la région. Les clients finissent par rechercher des instances, réserver des ressources de calcul avant même que les données ne soient prêtes (ce qui est coûteux), ou reporter purement et simplement leurs travaux (ce qui allonge les délais d'obtention des résultats).
Le client a mis Qumulo au défi en matière de vitesse, de fiabilité et de résilience. La solution devait offrir des performances supérieures tout en supprimant la dépendance au niveau des zones, en éliminant la duplication du stockage et en permettant aux charges de travail de s'exécuter partout où la capacité de calcul est disponible.
Qumulo résout ce problème au niveau architectural, plutôt que de superposer la disponibilité à des hypothèses héritées.
L'architecture : une zone à disponibilité multiple conçue, et non dupliquée
Au cœur de ce déploiement se trouvait un cluster CNQ multi-AZ, réparti uniformément sur trois zones de disponibilité au sein d'une seule région AWS.
Une zone de disponibilité (AZ) est un ensemble physiquement distinct d'un ou plusieurs centres de données au sein d'une région AWS. Chaque AZ est conçue pour fonctionner indépendamment, avec sa propre alimentation électrique, son système de refroidissement et son réseau, tout en étant connectée aux autres AZ de la région par des liaisons à haut débit et faible latence. Cette séparation permet aux applications de rester disponibles même en cas de panne d'un centre de données entier.
La durabilité est assurée par Amazon S3 au niveau régional, où les données sont automatiquement protégées sur plusieurs sites. C'est pourquoi AWS offre une disponibilité de 99.999999999 % (11 neuf), 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 s'étend sur plusieurs zones de disponibilité AWS sans nécessiter de répliques complètes des données client dans chaque zone. Par conséquent :
- Les coûts de stockage sont identiques, que CNQ s'exécute dans une seule zone de disponibilité ou dans plusieurs.
- Les performances d'écriture ne sont pas pénalisées par la réplication inter-zones.
- Le fonctionnement multi-AZ est l'état normal, et non un mode de défaillance.
Remarque : En règle générale, les services multi-AZ coûtent deux fois plus cher que leurs équivalents mono-AZ. Maintenir le même coût représente un avantage économique considérable.
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 vers une copie secondaire.
Cette conception est plus simple, plus rapide et matériellement moins coûteuse que les approches multi-AZ basées sur des répliques.
Il serait facile d'en faire le titre : L'architecture CNQ offre une résilience multi-AZ sans duplication des données. Pas faux. Mais nous pouvons faire encore mieux.
L'avantage des zones de disponibilité multiples CNQ pour les charges de travail intensives en GPU
Le multi-AZ est généralement présenté comme une fonctionnalité de disponibilité, ce qui est tout à fait acceptable, mais aujourd'hui, la disponibilité est devenue un prérequis. Ce qui compte réellement, c'est ce que CNQ permet en matière de calcul, notamment en simplifiant considérablement l'acquisition de GPU et de CPU.
La plupart des systèmes de fichiers cloud, même ceux commercialisés comme multi-AZ, ancrent le stockage à une seule zone principale. Les ressources de calcul doivent suivre les données. Si les GPU ou les CPU sont indisponibles dans cette zone, la charge de travail est bloquée, même si des capacités inutilisées existent ailleurs dans la région.
Cela oblige les équipes à rechercher activement des GPU et des CPU. Elles doivent d'abord trouver des instances de calcul disponibles, puis les réserver et les payer avant de pouvoir les 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ù les ressources de calcul ont été trouvées. Ce n'est qu'une fois toutes ces étapes terminées que le travail peut reprendre. CNQ supprime cette contrainte.
Grâce à CNQ, les ressources de calcul réparties dans plusieurs zones de disponibilité peuvent accéder simultanément au même ensemble de données. Les clients peuvent ainsi agréger la capacité de plusieurs zones au sein d'un pool logique unique, sans avoir à copier ni à réorganiser les données.
Si des GPU sont disponibles dans une zone le lundi et dans une autre zone le mardi, les clients n'ont pas besoin de déplacer leurs données ni de reconstruire leur infrastructure. Il leur suffit de rediriger leur déploiement CNQ existant vers l'endroit où la puissance de calcul est disponible.
Du point de vue du client, cela permet :
- Accès plus rapide aux GPU et CPU rares
- Aucune phase de réorganisation ou de copie des données
- Aucune pénalité de réplication
- Aucun accroissement des coûts de stockage
Le travail peut commencer immédiatement car les données existent déjà dans chaque zone de disponibilité S3, qui sert de couche de stockage persistant. Contrairement à Amazon Elastic Block Store (EBS) ou au stockage attaché à l'instance, cette architecture ne nécessite aucune copie ni réhydratation des données dans chaque zone avant le démarrage du calcul. Le système de fichiers accède aux données localement dans chaque zone de disponibilité via NeuralCache. Cette approche élimine les longs processus de préparation des données et permet une utilisation optimale des ressources de calcul dès le départ.
Vous vous dites peut-être encore une fois : voilà sûrement le titre qui fera la une : CNQ et l'art de rendre la chasse aux 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 souhaitait un débit soutenu supérieur à 1.5 To/s dans le cloud, sans compromis sur la fiabilité ni la flexibilité. Qumulo a mis en place un déploiement de test qui a finalement dépassé les attentes, atteignant un débit agrégé soutenu de 1.6 To/s et 20.7 millions d'IOPS. Ces chiffres sont impressionnants (les futurs lecteurs pourront se référer à la date de publication pour plus de contexte), mais correspondent-ils aux exigences maximales ou moyennes ? Si vous êtes client et que vous recherchez un débit de 1.6 To/s et 20.7 millions d'IOPS, rassurez-vous, nous avons la solution ! Voir ci-dessous.
De nombreux clients privilégient la flexibilité et ont besoin de pouvoir adapter leurs ressources à la hausse comme à la baisse en fonction de la demande. Comme évoqué précédemment, ils doivent souvent choisir entre provisionner les ressources pour les pics de demande, au prix d'un coût élevé, ou les dimensionner pour une utilisation moyenne, au risque de subir des baisses de performance. Ce compromis met en lumière la principale valeur du cloud : sa variabilité. Cette configuration peut coûter environ 5 000 $ par heure, ce qui la rend intéressante en cas de besoin, mais économiquement non viable en continu. La possibilité de consommer ce niveau de performance uniquement lorsque cela est nécessaire rend une approche cloud économiquement avantageuse par rapport à une infrastructure sur site.
CNQ permet aux clients d'atteindre des performances optimales sans payer systématiquement pour une capacité maximale. Voilà toute la différence.
Avec de nombreux systèmes de fichiers cloud, les performances sont liées à la capacité provisionnée en permanence. Si vous dimensionnez votre système pour les pics de charge, vous payez le prix fort en permanence, même lorsque la charge diminue.
CNQ dissocie ces décisions.
Les clients peuvent augmenter considérablement les performances pour respecter une échéance, une période de formation ou un pic de production, puis les réduire une fois le pic passé. Vous n'êtes pas contraint à une configuration maximale pour simplement gérer des pics ponctuels.
Cette flexibilité s'applique non seulement à la mise à l'échelle, mais aussi au choix des instances. Dans ce déploiement, les types d'instances ont été ajustés en cours de conception en raison de contraintes de capacité régionales. Le cluster a ainsi pu atteindre 250 nœuds, supportant environ 333 000 connexions, tout en consommant moins de bande passante par nœud, sans nécessiter de refonte.
Par la suite, les clients peuvent passer à des familles d'instances plus récentes à moindre coût grâce au remplacement progressif, sans interruption de service ni migration de données.
Ensemble, nous avons enfin trouvé le titre : CNQ propose Performance optimale sans engagement maximal. N'est-ce pas ? Mais pourquoi quelqu'un aurait-il besoin d'un tel niveau de performance optimale ?
Les moments qui exigent une performance de pointe extrême
Toutes les charges de travail n'ont pas besoin d'un débit extrême, et c'est précisément là l'essentiel.
Cette architecture n'a pas pour but de fonctionner en permanence à 1.6 To/s. Il s'agit d'avoir la possibilité d'atteindre cette vitesse lorsque le temps est compté, sans que cela n'entraîne de conséquences financières ou opérationnelles le reste du temps.
Ce qui paraît excessif aujourd'hui a tendance à devenir la norme demain. Alors, à quoi bon une telle performance ?
Prenons l'exemple d'une entreprise énergétique qui doit décider 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 dépenses cloud. La question est de savoir qui trouvera la réponse en premier. Être parmi les premiers peut faire la différence entre obtenir le puits et le laisser filer les mains vides.
Dans le domaine de la santé, une analyse génomique plus rapide peut faire la différence entre une incertitude prolongée et une décision de traitement qui sauve des vies.
Dans le secteur des médias et du divertissement, la rapidité d'exécution est cruciale pour le respect des délais de sortie d'un projet. Les retards peuvent engendrer des coûts imprévus et anéantir les marges bénéficiaires. Un rendu, une analyse et des itérations plus rapides permettent de réduire le temps d'attente des équipes créatives en raison des problèmes d'infrastructure.
Dans tous ces exemples, la contrainte ne réside pas dans la quantité de données stockables, mais dans le délai d'obtention d'informations et de prise de décision. Lorsque l'infrastructure fournit des réponses plus rapidement, les organisations ne se contentent pas d'exécuter leurs charges de travail plus vite ; elles obtiennent également des résultats plus rapidement. Elles raccourcissent les cycles de décision et tirent davantage de valeur de leur ressource la plus précieuse et irremplaçable : le temps de leurs experts.
Imaginez ce que votre entreprise pourrait accomplir lorsque les performances s'adaptent à la hausse comme à la baisse, que vous cessez de payer pour une marge de manœuvre inutilisée et que vous commencez à payer pour les résultats.
Le titre doit assurément être : N'attendez plus pour les infrastructures. CNQ obtient des résultats plus rapidement. Mais cela permet-il vraiment de tout comprendre ?
L'effet quantitatif
En atteignant un débit de lecture séquentielle agrégé soutenu de 1.6 To/s, Qumulo a dépassé de plus de 50 % l'objectif de performance initial du client par rapport aux systèmes sur site. Ce niveau de performance a nécessité une architecture native du cloud, entièrement construite sur l'infrastructure AWS standard et répartie sur trois zones de disponibilité.
Plus important encore, ce travail démontre que des performances extrêmes n'impliquent pas nécessairement des compromis inabordables.
Outre un débit de 1.6 To/s, le système a atteint 20.7 millions d'IOPS avec une latence inférieure à la milliseconde.
Mais la véritable valeur ajoutée va bien au-delà des chiffres. L'architecture permet aux clients de répartir la puissance de calcul sur toutes les zones de disponibilité, au lieu d'être limités à une seule, ce qui simplifie considérablement l'acquisition de GPU et de CPU à grande échelle. Elle confirme également la résilience de CNQ sur AWS, garantissant une disponibilité des données exceptionnelle et une durabilité de 99,9 ...
Prises ensemble, ces capacités créent un effet cumulatif, que nous appelons le Effet quantitatif.
Peut-être que ce n'est pas un seul titre qui devrait retenir votre attention. Peut-être que ce sont tous.
- Qumulo, solution native du cloud, passe à une capacité de 1.6 To/s sur AWS
- CNQ conçu pour le cloud, pas adapté à celui-ci
- L'architecture CNQ offre une résilience multi-AZ sans duplication des données
- CNQ et l'art de rendre la chasse aux GPU supportable
- CNQ offre des performances optimales sans engagement maximal
- N'attendez plus pour les infrastructures. CNQ obtient des résultats plus rapidement.
C'est cette combinaison qui fait toute l'histoire.
A Retenir
Ce déploiement a prouvé qu'un système de fichiers natif du cloud peut offrir des performances extrêmes sans compromis :
- Multi-AZ par conception, et non par duplication
- Des performances qui s'adaptent à la hausse comme à la baisse
- Liberté d'exécution là où la puissance de calcul est disponible, et non là où les données sont bloquées.
- Ce qui permet d'obtenir des résultats plus rapidement.
Le cloud ne doit pas seulement être suffisamment rapide. Avec une architecture adaptée, il peut être plus flexible, plus résilient et plus économique que ne l'ont jamais été les systèmes sur site.
