Périphériques d’E/S et problèmes de latence

Périphériques d’E/S et latence

• Les périphériques de stockage non volatils sont un élément central des systèmes informatiques modernes, car ils peuvent conserver les données même lorsque l’alimentation est coupée. Contrairement aux dispositifs de stockage volatils comme les registres CPU, le cache CPU et la RAM, ils n’ont pas besoin d’une alimentation continue.

Stockage sur bande

• Depuis les années 1950, les ordinateurs utilisent des lecteurs de bande pour le stockage numérique non volatil. La bande convient au stockage de longues séquences de données et est adaptée aux situations où il faut conserver de gros volumes de données en toute sécurité sans avoir besoin de les lire fréquemment.
• La bande offre un coût faible et une longue durée de vie, et elle est encore utilisée dans de grands dépôts de données comme ceux du CERN et d’AWS.

Disque dur (HDD)

• Les disques durs offrent un accès aux données plus rapide que les bandes et stockent les données sur des disques métalliques circulaires. Toute la surface du disque étant disponible en permanence, la latence de lecture et d’écriture des données est réduite.
• Les HDD prennent en charge la mise en file de commandes, ce qui permet d’exécuter plusieurs commandes en parallèle.

Disque SSD

• Les SSD lisent et écrivent les données électroniquement, sans composants mécaniques, et utilisent la mémoire flash NAND pour fournir un stockage non volatil.
• Les SSD peuvent optimiser les performances grâce au traitement parallèle et au garbage collection. L’agencement des données peut influencer les performances.

Stockage dans le cloud

• Le passage au cloud a entraîné des changements dans les performances d’E/S, et de nombreuses entreprises y ont migré leurs serveurs et leurs systèmes de base de données.
• Dans les environnements cloud, la séparation du stockage et du calcul est courante : elle apporte sécurité des données et flexibilité, mais peut aussi provoquer une baisse de performance.

Séparation du stockage et du calcul

• Traditionnellement, les serveurs utilisaient des périphériques de stockage non volatils directement connectés, mais dans le cloud, il est courant de connecter le stockage via le réseau.
• Le stockage connecté au réseau offre une meilleure sécurité des données, mais peut avoir un impact négatif sur les performances d’E/S.

Stockage local vs stockage réseau

• Les SSD NVMe locaux offrent des vitesses d’E/S très élevées et une latence plus faible que le stockage connecté au réseau.
• Le stockage connecté au réseau peut imposer des limites sur les opérations d’E/S, ce qui peut entraîner une dégradation des performances.

Solution : Metal

• Metal est une solution proposée par PlanetScale qui utilise des SSD NVMe directement connectés pour offrir d’excellentes performances et une grande évolutivité.
• Un cluster Metal est composé par défaut d’un serveur principal et de deux réplicas, garantissant la durabilité des données, et la capacité de stockage peut être étendue facilement.
• Les bases de données Metal n’imposent aucune limite artificielle sur les opérations d’E/S et peuvent les exécuter avec une latence minimale.

[GN⁺]

Commentaires Hacker News

• Mentionne que l’auteur du blog a manifestement pris beaucoup de plaisir à écrire cet article. Il a créé des visuels interactifs à l’aide de milliers de lignes de JavaScript
• Indique soutenir SQLite+NVMe depuis longtemps. C’est un nouveau modèle qui offre la possibilité de résoudre des problèmes sans mise à l’échelle horizontale
  • Pour les problèmes de performance, la latence est ce qui compte le plus
  • C’est encore plus important lorsqu’un traitement séquentiel est nécessaire
  • Faire tourner SQLite sur NVMe permet d’obtenir des avantages de latence qu’aucun autre fournisseur ne peut offrir
  • Dans la plupart des cas d’usage réels, l’exécution en mémoire n’apporte pas d’avantage majeur par rapport à la persistance sur NVMe
• Fait l’éloge de la richesse informative au point d’en oublier qu’il s’agit d’une promotion produit. Mentionne l’excellence des visuels et de l’interactivité
• Le visionnage de l’animation des E/S disque lui a rappelé Melvin Kaye
  • Mel n’écrivait pas de boucle d’attente temporisée
  • Il en allait de même lorsque le Flexowriter nécessitait un délai entre les caractères en sortie
  • Il plaçait les instructions sur le tambour de sorte qu’elles se retrouvent juste derrière la tête de lecture au moment voulu
  • Le tambour devait effectuer une rotation complète pour trouver l’instruction suivante
• Dit que le blog est bon. Souligne que le stockage cloud est généralement « anormalement lent »
  • Mentionne avoir récemment ajouté la prise en charge du stockage d’index incrémentaux sur S3/object storage
  • La raison pour laquelle ils ont utilisé NVMe plus longtemps tient aux avantages de performance mentionnés dans un article précédent
  • Dit espérer que quelqu’un bouleverse ce domaine avec une meilleure offre
• Souligne un point que l’article ne traite pas suffisamment au sujet du stockage distribué
  • Certains systèmes ne prennent pas en charge la réplication de base
  • Un cluster Cassandra et MySQL peuvent faire de la réplication maître-esclave, mais beaucoup de systèmes ne le peuvent pas
  • Lorsqu’on utilise du stockage NVMe dans le cloud, il faut respecter les fenêtres de maintenance et les drains déclenchés par le cloud
  • Séparer le stockage du calcul permet à l’opérateur cloud de déplacer le calcul selon les besoins
  • Comme les données sont indépendantes du calcul, l’opérateur cloud peut gérer le système de données et les drains
• Metal a l’air très impressionnant. Mentionne avoir rencontré de graves problèmes de fiabilité en essayant d’utiliser les SSD locaux d’instance de GCP dans un emploi précédent
  • Certains blocs du périphérique perdaient des données
  • Se demande si la situation s’est améliorée
  • Demande quel type de machine est utilisé
  • Mentionne comme solution l’usage du disque réseau de Discord
• PlanetScale Metal semble très robuste. Il est toujours intéressant de voir une forte baisse de la latence dans une release
• Très bon article. La visualisation des écritures aléatoires est très réussie
  • Un autre problème du stockage connecté en réseau dans le cloud est la limite d’IOPS
  • De nombreux fournisseurs cloud, dont AWS et Google Cloud, utilisent ce modèle et limitent la quantité d’opérations d’E/S pouvant être envoyées
  • Lorsque le stockage est directement attaché à l’instance de calcul, il n’y a pas de limite artificielle sur les opérations d’E/S
  • On peut lire et écrire aussi vite que le matériel le permet
  • Se demande si la limite d’« IOPS » correspond à une limite sur un certain trafic réseau
  • Demande s’il s’agit du trafic réseau des volumes EBS
  • Se demande s’il est possible de réduire les coûts, si cela vient d’un étrange arbitrage chez AWS, ou si l’efficacité provient d’un moindre usage du réseau EBS
  • Voit clairement l’avantage, du point de vue de la latence, à placer stockage et calcul sur la même machine
  • Se demande s’il y a aussi un avantage en débit par rapport au coût
• Se demande comment les fournisseurs de bases de données « serverless » peuvent faire la promotion d’un accès « à faible latence »
  • Ils utilisent un object storage comme S3, dont on s’attend à ce que la latence soit bien pire que celle du stockage réseau
  • Mentionne avoir construit une couche de cache et indique vouloir conserver les données sur un NVMe attaché localement