Object  Storage : 10 ans d’évolution, de l’évolutivité à la résilience

Introduction

Dans une nouvelle session Twitch #VeryTechTalk, Rémy (Tech Evangelist) a invité Antonin (Product Manager) et Édouard (IT Team Leader) pour décortiquer la solution Object Storage d’OVHcloud.

Au fil de la discussion, ils ont revisité les débuts du service, expliqué comment il a été repensé autour d’une compatibilité S3, détaillé les mécanismes de résilience et présenté les nouvelles fonctionnalités à venir dans les prochains mois. Cet article de blog reprend les points clés de cette discussion pour vous donner des perspectives sur cette technologie et, qui sait, vous donner envie de la tester !

L’historique du projet

En 2014, OVH proposait HubiC, une offre grand public reposant sur du stockage de fichiers (NAS) accessible via WebDAV. Le modèle fonctionnait tant que les volumes restaient modestes, mais dès que les téraoctets ont commencé à affluer, l’équipe a compris que la mise à l’échelle était limitée.

La solution a alors basculé vers OpenStack Swift, la brique objet du projet OpenStack. Celle-ci a permis de mettre à disposition des clientes et clients une offre d’Object Storage et de gérer les objets à l’échelle du cloud.

En 2020, OVHcloud a racheté OpenIO, une startup déjà experte du stockage compatible S3. Cette acquisition a été le catalyseur du projet.

OpenStack Swift a été conservé pour les usages historiques et une offre compatible S3 a pu voir le jour afin de répondre aux exigences du marché (ex. outils, CI/CD, IA). La première classe compatible S3 a été mise à disposition un an et demi après le rachat, puis d’autres classes (infrequent‑access, hyper‑performance) ont suivi, créant un portfolio multiclasse.

« Il est primordial d’accélérer le développement de cette API  : les outils S3 sont devenus le standard de facto » – Antonin

Le but était de transformer l’Object Storage en une offre générique (multi-usages) capable de couvrir les backups classiques, les workloads de machine learning, les archives légales…

Aujourd’hui, le service se positionne comme le point d’ancrage de nombreuses solutions internes : images d’instances, Logs Data Platform, stockage de logs, etc.

Architecture et évolutivité : un « infini » virtuel

L’équipe gère des centaines de milliers de disques répartis dans les datacenters d’OVHcloud. Cette densité permet de proposer une évolutivité quasi‑infinie. Un des points forts, ainsi qu’une volonté d’OVHcloud, est que l’utilisatrice ou l’utilisateur ne voit jamais le moment où un disque est ajouté ou remplacé, aucune interruption n’est perceptible.

« L’évolution doit être la plus transparente possible. L’utilisatrice ou l’utilisateur ne doit jamais voir un « drop » pendant l’ajout d’un disque. » – Édouard

Toutefois, cette quasi-infinité concernant le volume doit être encadrée, renforcée et tolérante à la panne de certains de ses éléments tout en continuant de fournir un service.

Plutôt que de se contenter de copier les données, le service découpe chaque objet en plusieurs fragments et ajoute des chunks de parité (Erasure Coding). Si une panne survenait sur un disque, un rack ou sur un datacenter entier dans le cas d’un stockage 3-AZ. Les fragments restants permettent de reconstruire le fichier original sans perte. C’est l’un des points forts d’Object Storage.

Dans le cadre du service, OVHcloud assure la durabilité (les données restent intactes) et la disponibilité (accès en permanence) des données. La clientèle, quant à elle, choisit le niveau de résilience  : nombre de copies, réplication asynchrone, versionning, object‑lock…

Cette granularité permet d’ajuster le coût au niveau de criticité des données.

• Durabilité : les données restent intactes grâce à l’Erasure Coding et à la réplication multisite.
• Disponibilité : l’accès aux objets est garanti même lorsqu’une zone de disponibilité (AZ) tombe en panne.

Performance et métriques clés

Dans une infrastructure de cette taille, il existe de nombreuses métriques qu’il est possible d’analyser. Certaines attirent toutefois davantage l’attention des équipes opérationnelles. Édouard nous en détaille trois, qui peuvent également être monitorées si vous possédez une infrastructure dans laquelle vous gérez une plateforme de stockage par vous-même.

Le taux d’erreur, premier signal d’alerte

Le taux d’erreur (500/503) est le premier indicateur de santé du service.

Un pic déclenche immédiatement les mécanismes de retry intégrés aux SDK, de façon transparente pour l’utilisateur ou l’utilisatrice. Ces tentatives successives sont effectuées côté client pour s’assurer que la lecture (ou l’écriture) se déroule dans de bonnes conditions.

Time‑to‑First‑Byte (TTFB) : le vrai baromètre de latence

Le TTFB mesure le temps nécessaire pour délivrer le premier octet, quel que soit le poids du fichier.

Une hausse du TTFB signale souvent une saturation ou un incident dans l’infrastructure. L’équipe surveille ce KPI en temps réel pour anticiper les anomalies. Il s’agit d’un indicateur fort en interne pour la performance et la santé de la plateforme.

IOPS versus capacité disque

Depuis quelques années, les capacités des disques continuent de croître, mais les IOPS restent relativement stables.

Cette évolution crée un IOPS/To décroissant, d’où la nécessité de garder ces métriques sous supervision afin d’anticiper un possible engorgement.

Cas d’usage concrets

Cas n°1 : sauvegarde et archivage

Les clientes et clients peuvent effectuer leurs sauvegardes directement dans un bucket, profiter du versionning et de l’object‑lock, puis restaurer les données en quelques clics. L’archivage sur bande, proposé depuis 2025, offre un coût de 1‑2 €/To avec un TTFB de l’ordre de l’heure, idéal pour les obligations légales de conservation à long terme.

• Versionning : chaque modification crée une nouvelle version, protégeant de la perte causée par les suppressions accidentelles.
• Object Lock (immutabilité) : écriture unique, lecture illimitée ; idéal contre les ransomwares.

Cas n°2 : big data et IA

Les volumes massifs nécessaires à l’entraînement de modèles de machine learning sont stockés en « cold  » sur l’Object Storage, puis déplacés vers les clusters de calcul lorsqu’ils sont requis.

Cas n°3 : services internes d’OVHcloud

Les usages d’Object Storage se démocratisent. Il est normal et nécessaire que les produits OVHcloud aussi tirent parti des bénéfices apportés par cette technologie.

En effet, de nombreux services s’appuient sur elle : images d’instances, logs de la Logs Data Platform, stockage de données froides, etc.

Feuille de route et innovations à venir

Object Storage 2.0

Un backend refondu (nom de code Object Storage 2.0) est en phase de bêta privée. L’objectif est supprimer les soft limits actuelles, réduire le TTFB au minimum et offrir des performances supérieures pour les cas d’usage client à forte granularité (milliers de petits fichiers).

Transparence via la feuille de route publique

Toutes les évolutions sont publiées sur le OVHcloud GitHub. Les utilisateurs et utilisatrices peuvent suivre les tickets, laisser des commentaires et s’inscrire aux versions bêta via le serveur Discord dédié.

Conclusion

L’OVHcloud Object Storage a parcouru un long chemin et est désormais une plateforme multiclasse, capable de gérer des centaines de milliers de disques tout en offrant une résilience de niveau entreprise. L’intégration d’OpenIO a permis d’ajouter une API compatible S3, répondant aux exigences d’interopérabilité du marché. Grâce à l’Erasure Coding, au versionning, à l’object‑lock et aux options de réplication, chaque cliente et client peut ajuster la durabilité et la disponibilité de ses données à son propre coût.

Vous avez un projet cloud native ou avez besoin de sauvegarde à grande échelle ?estez dès maintenant l’Object Storage d’OVHcloud, explorez les différentes stratégies de résilience et partagez vos retours : la communauté technique grandit grâce à vos expériences.

Vous avez aimé cet article ? La vidéo dont il est extrait est accessible sur notre chaîne Youtube, ici : https://www.youtube.com/watch?v=KmS0YhjuYZc