Découvrez comment transformer AWS EBS sc1 en un support de stockage puissant pour vos charges de travail de production.

Début 2020, nos clients nous ont fait savoir qu'ils voulaient stocker plus de données de fichiers dans le cloud sur Qumulo, mais le coût de l'infrastructure AWS EBS st1 a explosé à mesure qu'il dépassait 50 To environ. Nous avons décomposé le coût de notre solution, l'avons examiné sous de nombreux angles différents et avons constaté que, à mesure que vous augmentiez la capacité, le coût était dominé par EBS. Plus tard dans l'année, après plus de tests et quelques changements dans la façon dont notre produit gère les disques à latence élevée, nous avons pu proposer des configurations qui ont fait baisser le prix jusqu'à 70%. Comment avons-nous fait cela?

Tout d'abord, un peu de contexte. 

Le Plateforme de données de fichiers Qumulo est un système de fichiers distribué hautement disponible qui s'exécute sur plusieurs nœuds configurés de manière identique dans un cluster. Chaque nœud du cluster est un participant égal, et d'autres machines ou utilisateurs ayant besoin d'accéder aux données d'un système Qumulo peuvent le faire à partir de n'importe quel nœud - et ils verront tous exactement le même état. 

Cela vous permet d'évoluer pour servir des milliers de clients connectés, et certaines configurations peuvent atteindre plus de 1 M IOPS et des dizaines de Go / s. Vos données sont protégées contre la perte d'un volume EBS (EBS annonce un taux de défaillance annuel de 0.1% -0.2%) et sont toujours accessibles même si un nœud est redémarré ou arrêté temporairement (c'est-à-dire pour maintenance).

Les deux principaux modes de fonctionnement de Qumulo sont tous SSD, ce qui signifie que vos données sont écrites et lues à partir de SSD et ne sont jamais déplacées ailleurs. Considérez cela comme une plate-forme à un seul niveau conçue pour fournir une faible latence cohérente pour des éléments tels que le montage vidéo, la lecture et le rendu. Nous avons également un mode à deux niveaux qui consiste en une fine couche de disques SSD qui agissent comme un cache persistant, et le «stockage» est en fait soutenu par une grande banque de disques durs moins chers. C'est la configuration sur laquelle nous nous sommes attachés à rendre plus rentable pour les clients.

Notre produit AWS utilise des volumes EBS gp2 pour les disques SSD et st1 pour les disques durs. À mesure que vous augmentez la capacité de votre cluster Qumulo de 50 To, à 100 To, à 200 To, à 400 To, le coût de st1 commence à dominer le coût de l'ensemble de la solution. Et ça coûte très vite. 

Maintenant, si vous savez quelque chose sur AWS EBS, vous savez peut-être qu'AWS propose une autre classe de disque dur moins chère appelée sc1. Il est annoncé comme: «Celles-ci (sc1) sont idéales pour les charges de travail rarement utilisées avec de grands ensembles de données froids avec de grandes tailles d'E / S, où l'attribut de performance dominant est le débit (Mio / s).»

Qumulo a expérimenté avec sc1 dès le début, mais a vu des données troublantes. La latence était beaucoup plus élevée et le coût ne semblait pas refléter la différence de performances. 

Tests de performance IO Latency SC1 vs ST1 début 2020

Lire Écrire
Séquentiel + 72% + 159%
aléatoire + 162% + 213%

 

De plus, nous savions déjà que nos performances étaient affectées par la surcharge de latence d'E / S d'EBS étant connecté au réseau. Certains tests anecdotiques avec notre logiciel ne semblaient pas non plus prometteurs. Nous avons déclaré que sc1 était trop risqué à suggérer aux clients à ce moment-là.

Les clients veulent un stockage d'entreprise rentable sur AWS EBS sc1

À la fin de l'année dernière, Qumulo a de nouveau regardé après avoir passé plusieurs cycles de développement longs et coûteux à régler les performances de son système. Et, parce que nous avions des clients qui nous demandaient spécifiquement sc1, nous avons dit; eh bien, essayons encore une fois. Nous avons fait des tests, trouvé des goulots d'étranglement dans notre code que nous devrions régler, puis avons commencé à effectuer des analyses comparatives pour avoir une idée de l'endroit où nous avons atterri.

Nous avons été agréablement surpris.

Les performances multi-flux maximales sur un cluster avec sc1 comme support correspondent et dépassent parfois les performances d'un cluster équivalent exécutant st1. Bien que nous nous rendions compte que cela ne se produira pas toujours pour chaque charge de travail, cela montre à quel point notre technologie est venue pour aider à masquer l'effet de l'utilisation de niveaux de stockage rentables dans un système de fichiers d'entreprise.

Niveaux rentables dans un système de fichiers d'entreprise

 Un échantillon de sc1 versus st1 en 2021

Grappe Coût par mois AWS Infra (us-west-2) Mo / s d'écriture multi-flux maximum Lecture multi-flux maximale (mise en cache ou à partir du SSD) Mo / s Lecture multi-flux maximale depuis le disque dur Mo / s
M5.12x grand 4x55TiB st1 $17,989.28 1635 Mio / s 3192 Mio / s 3202 Mio / s
M5.12x grand 4x55TiB sc1 $ 11,230.88 (-37%) 1683 Mio / s 3135 Mio / s 3194 Mio / s

Les valeurs du tableau ci-dessus sont fournies à titre informatif uniquement et sont représentatives d'un seul test multi-flux Qumulo réalisé avec un cluster à 4 nœuds et des instances m5.12xlarge. Les prix varient en fonction des accords d'entreprise et de la région de déploiement souhaitée. Les performances peuvent varier en fonction de la latence du réseau, du type d'instance et du nombre de nœuds.

Comment est-ce possible aujourd'hui? 

Depuis sa création, Qumulo s'est concentré sur l'optimisation du produit et l'amélioration des performances. Avec notre solution définie par logiciel, le seul levier à tirer est de rendre notre logiciel plus intelligent, meilleur et plus rapide. Cela peut sembler un inconvénient (pourquoi ne pas simplement tricher avec du matériel propriétaire?), Mais l'avantage est que nous obtenons cette valeur et cet effort partout, pas seulement sur site.

L'optimisation chez Qumulo signifie que nous:

  1. Toujours écrire dans le flash, point. Nous n'impliquons jamais de disques durs lents dans le chemin d'accès rapide à l'écriture de données.
  2. Mettez toujours en cache toutes les données que vous écrivez aussi en mémoire, juste au cas où vous demanderiez les mêmes données tout de suite, nous n'avons même pas besoin d'aller lire un disque ou de demander les mêmes données à d'autres nœuds.
  3. Déplacer les données sur le disque dur en arrière-plan, hors de vue, hors de l'esprit, au besoin, automatiquement. Considérez cela comme une hiérarchisation automatisée vers un stockage moins cher. Nous déplaçons toujours les données les plus froides, et nous le faisons sous le système de fichiers, au niveau du bloc. Par conséquent, si vous exécutez la commande de fichier Linux à plusieurs reprises et que vous ne lisez que les premiers 4 Ko d'un fichier, nous traiterons ce premier bloc comme chaud et le reste du fichier comme non chaud. Cela maximise l'utilisation du cache SSD.
  4. Essayez SSD lorsque vous demandez des données qui ne sont pas dans le cache. S'il n'est pas sur SSD, nous le lisons à partir du disque dur, mais nous commençons également à pré-lire le bloc suivant dans un fichier afin qu'il soit déjà dans notre cache mémoire si vous ne l'avez pas encore demandé. Pourquoi? Pour vous battre avant de le demander. Cela rend la lecture à partir du disque dur rapide, car elle est masquée par le prefetcher. Nous faisons également cela si vous lisez des fichiers séquentiellement dans un répertoire.
  5. Déplacez les blocs que vous avez lus du disque dur plusieurs fois vers le SSD. Pourquoi? Aucune raison de le conserver sur le support le plus lent si vous continuez à demander ces données. Nous en faisons automatiquement la promotion pour vous - aucun réglage ou politique requis.
  6. Optimiser notre système d'allocation de blocs de sorte qu'aucun temps n'attend une adresse pour écrire des données.
  7. Posséder presque toute la pile de code pour tout ce qui se trouve dans le produit, jusqu'aux structures de données et aux algorithmes. Nous pouvons régler un mauvais tri ou une carte de hachage qui atteint de mauvaises lignes de cache comme personne ne le fait. Nous avons même écrit les implémentations NFS et SMB à partir de zéro, et sommes capables de tout régler de haut en bas dans notre pile.
  8. Exécuter entièrement dans l'espace utilisateur, ayez notre propre planificateur de tâches pour éviter le changement de contexte du noyau, et faites tout via des E / S asynchrones.

Transformer AWS EBS sc1 en un support de stockage puissant pour vos charges de travail de production

Il faut du temps pour créer un système de stockage évolutif comme la plate-forme de données de fichiers de Qumulo. Mais la valeur de faire cela montre. Nous transformons efficacement sc1, un type de volume EBS qu'Amazon ne recommande pas pour les «charges de travail actives» en un support de stockage puissant pour vos charges de travail de production. À 0.015 USD par Gio-mois et S3 à 0.021 USD par Gio-mois au moins cher, EBS sc1 est en fait 28% de moins que la norme S3, et ce n'est que du stockage! S3 facture les appels d'API en plus du stockage.

Apprendre encore plus

Réduisez les coûts et gagnez en flexibilité sur AWS avec Qumulo Cloud Q
Qumulo sur AWS : services de cloud vidéo pour les studios créatifs de M&E
Testez le Qumulo Shift ! Déplacez vos données vers Amazon S3

Contacte-nous

Faites un essai routier. Faites une démonstration d'un cluster Qumulo ou déplacez vos données vers Amazon S3 dans l'un de nos ateliers pratiques.
Abonnez-vous au blog Qumulo pour les témoignages clients, les informations techniques, les tendances du secteur et les actualités sur les produits