3 Une hypothèse tenace est ancrée dans la façon dont la plupart des entreprises planifient aujourd’hui leur infrastructure d’IA : pour obtenir un débit sérieux, il faut du 100 % flash. Tout le reste est relégué au niveau froid. Cette hypothèse mérite d’être examinée de près. Nous avons mené une validation de performances structurée sur un déploiement de production de Scality RING chez un grand fournisseur de cloud d’IA souverain, et les chiffres racontent une autre histoire. Avec Scality RING sur des serveurs de stockage à base de HDD, les supports flash (SSD) n’étant utilisés que pour les métadonnées, sur un véritable chemin de production avec chiffrement TLS, répartiteurs de charge et trafic traversant trois zones de disponibilité, le système a fourni un débit de lecture soutenu via l’API S3 d’environ 420 Go par seconde et un débit d’écriture soutenu d’environ 250 Go par seconde. Un niveau maintenu de façon stable pendant deux heures en continu. Sans aucune erreur au niveau du stockage. C’est une bande passante traditionnellement associée aux systèmes de fichiers parallèles, mais obtenue ici sur des disques ! Le dilemme de l’architecte : un débit digne de l’IA sans l’économie du 100 % flash Si vous concevez une infrastructure pour des pipelines d’IA, de la génération augmentée par récupération (RAG), de l’analytique à grande échelle ou une sauvegarde consolidée, vous savez déjà que le débit agrégé est devenu la contrainte déterminante. Les clusters d’inférence ont besoin de récupérer en parallèle embeddings, checkpoints et artefacts intermédiaires à des centaines de Go/s. Les plateformes d’analytique génèrent des schémas distribués de lecture et d’écriture sur les clusters de calcul. Les environnements de sauvegarde consolident des jeux de données de plusieurs pétaoctets dans des fenêtres qui ne cessent de se réduire. Le réflexe par défaut consiste à placer les données sensibles aux performances sur de la flash et à utiliser le HDD pour la capacité froide. Mais à l’échelle du pétaoctet et de l’exaoctet, le surcoût du 100 % flash finit par dominer le budget, et il oblige les architectes à maintenir plusieurs niveaux de stockage uniquement pour satisfaire des besoins de bande passante que, comme on le constate, le stockage objet sur HDD peut déjà couvrir. La question n’a jamais vraiment été de savoir si les HDD disposent d’une bande passante agrégée brute suffisante. Il s’agit de savoir si un système de stockage objet peut exploiter cette bande passante dans des conditions de déploiement réalistes, avec chiffrement, répartition de charge et architecture multi-AZ sur le chemin des données. C’est à cette question que cette validation entendait répondre. Tester le stockage objet sur HDD sous une charge réaliste de production Le déploiement exécutait Scality RING 9.5 sur un peu plus de 100 nœuds x86 équipés de supports de stockage HDD, répartis sur trois zones de disponibilité dans une configuration géo-étendue synchrone (geo-stretched). La charge était générée par 120 VM d’injection réparties sur les trois zones, avec jusqu’à 35 000 opérations S3 simultanées sur 696 buckets en parallèle. Tout le trafic passait par un point de terminaison DNS global en HTTPS, en empruntant la même infrastructure de répartition de charge, de TLS et de routage inter-zones que les charges de travail de production. À noter qu’avec un RING géo-étendu, toutes les opérations d’écriture sont synchrones, afin que le système puisse maintenir un service complet et une cohérence totale même si l’un des sites est perdu ou devient indisponible (coupure d’alimentation, problème de connectivité réseau ou sinistre sur site). La charge de travail principale utilisait des objets de 10 Mo, représentatifs de la distribution de jeux de données d’IA et des transferts des pipelines analytiques. Point essentiel, la validation portait sur le débit soutenu pendant deux heures, et non sur des pics de courte durée. L’injection et la récupération des données ont été réalisées avec un outil de test S3 open source tiers couramment utilisé. Un standard du secteur, et non un banc d’essai propriétaire. Le résultat : des centaines de Go/s via S3, en continu Mesurées au niveau des répartiteurs de charge, et donc représentatives du trafic chiffré visible de l’extérieur, tel que le perçoivent réellement les applications, les lectures soutenues se sont maintenues à près de 420 Go/s, avec des pics approchant 450 Go/s. Les écritures soutenues se sont maintenues à environ 250 Go/s. Le débit est resté stable pendant les deux heures. La latence a augmenté de façon prévisible à mesure que la concurrence approchait de la saturation, mais la bande passante agrégée ne s’est jamais effondrée, ce qui traduit une saturation maîtrisée plutôt qu’une instabilité. Le système a servi 20 000 à 40 000 opérations sur gros objets par seconde sous charge soutenue, sans aucune erreur au niveau du stockage. Un second profil utilisant des objets de 4 Ko a validé le comportement à des taux de requêtes élevés : 173 456 PUT S3 par seconde et 151 091 GET S3 par seconde, là encore sans erreur. Une forme de charge de travail différente, un même comportement stable. Ce que cela signifie pour l’architecture d’IA, d’analytique et de sauvegarde Pour les architectes, ce résultat remet en cause une hypothèse par défaut : tous les problèmes de performances ne sont pas des problèmes de latence. Certaines charges de travail sont limitées par la bande passante agrégée soutenue, ce qui change le rôle que peut jouer le stockage objet sur HDD dans l’architecture d’IA, d’analytique et de sauvegarde. Pour les pipelines de données d’IA et les charges de travail de récupération RAG, des lectures soutenues de l’ordre de 420 à 450 Go/s maintiennent les GPU alimentés et les temps de réponse de la récupération prévisibles lorsque de nombreux services sollicitent simultanément le stockage objet. La bande passante de lecture agrégée est la contrainte déterminante lorsque le stockage objet constitue la couche de données principale de l’IA, et ces résultats franchissent la barre. Pour la sauvegarde et la protection des données, un débit d’écriture soutenu de 230 à 250 Go/s (près de 900 To par heure !) réduit considérablement les fenêtres de sauvegarde des environnements de plusieurs pétaoctets, tandis que des lectures à 420 Go/s (1 500 To/heure) accélèrent nettement les restaurations à grande échelle, ce qui est essentiel pour rétablir l’activité après une cyberattaque majeure. Les équipes sauvegarde qui prévoyaient des niveaux d’ingestion 100 % flash pour des raisons de performances devraient refaire leurs calculs. Pour les data lakes et l’analytique, la validation confirme que les schémas distribués de lecture et d’écriture des grands clusters de calcul peuvent s’exécuter sur un stockage objet à base de HDD sans que le stockage ne devienne le goulet d’étranglement — même avec du chiffrement et du trafic multi-AZ sur le chemin. L’enseignement pour l’architecture : bande passante et latence ne sont pas le même problème Rien de tout cela ne signifie que la flash est inutile. Les charges de travail sensibles à la latence en bénéficient toujours, et certaines continueront d’en avoir besoin. Mais le réflexe du secteur qui consiste à assimiler performances et 100 % flash, et à reléguer le HDD à la capacité froide, est de plus en plus dépassé. À grande échelle, le stockage objet sur HDD peut réellement fournir un débit soutenu qui change l’économie de l’architecture d’IA, d’analytique et de sauvegarde. La conséquence pour les architectes est claire : les pipelines d’IA, l’analytique à grande échelle et la sauvegarde consolidée peuvent s’exécuter sur un socle unique de stockage objet à haut débit, sans ajouter de niveaux de stockage uniquement pour courir après la bande passante. L’écart de coût à l’échelle du pétaoctet et de l’exaoctet est considérable. La pénalité en performances, d’après cette validation, ne l’est pas. Avant d’opter par défaut pour une architecture 100 % flash, les architectes devraient vérifier si la charge de travail a réellement besoin d’une latence de niveau flash ou si le véritable besoin est une bande passante agrégée soutenue à grande échelle. Lire la validation complète Le livre blanc complet sur les performances (en anglais) détaille l’environnement de test, la méthodologie, l’intégrité des mesures au niveau du stockage et des répartiteurs de charge, ainsi que les résultats détaillés, notamment le comportement du système sous charge soutenue et le profil sur petits objets. Si vous concevez une infrastructure pour l’IA, l’analytique ou la protection des données à grande échelle, sa lecture en vaut la peine.
