Stockage Scaleway : Block, File ou Object, la carte avant de construire

Le choix entre Block, File et Object ne se joue pas sur le volume de données, il se joue sur la façon dont on y accède. Un système d'exploitation veut un disque, plusieurs machines qui partagent des fichiers veulent un système de fichiers, une application qui manipule des documents veut une API. Cette leçon ouvre le bloc stockage : elle pose les trois familles, leurs plafonds de départ, et surtout les décisions qu'on ne peut plus reprendre une fois la ressource créée. Elle ne construit rien, c'est la carte qu'on lit avant de partir.

Ce que vous allez apprendre

• Départager les trois familles sur le mode d'accès, pas sur la taille.
• Situer chacune en portée zonale ou régionale, et en tirer les conséquences sur la résilience.
• Connaître les plafonds qui décident d'une architecture, avant de les rencontrer.
• Repérer les décisions irréversibles, celles qui imposent de recréer et de migrer.

Quelle famille pour quel besoin ?

Une seule question suffit à trancher dans la grande majorité des cas : combien de machines doivent écrire en même temps ? Le reste en découle.

Besoin	Choix	Pourquoi
Un disque pour une seule machine	Block Storage	attachement exclusif, performance dédiée au volume
Des fichiers écrits par plusieurs machines	File Storage	montage simultané, sémantique de système de fichiers
Des données consommées par une application via API	Object Storage	pas de montage, accès HTTP, capacité sans plafond pratique
Du ReadWriteMany pour des pods Kubernetes	File Storage et son pilote CSI	seule des trois à l'offrir
Des sauvegardes et des archives	Object Storage	classes de stockage et règles de cycle de vie

Glissez pour voir

Le piège classique est de choisir Object Storage pour tout, parce qu'il est le moins cher au gigaoctet et qu'il n'a pas de limite de capacité. C'est un excellent choix pour ce qu'une application écrit et relit par API. C'en est un mauvais dès qu'un logiciel existant attend un chemin de fichiers : monter du stockage objet comme un disque produit des performances et une sémantique qui ne correspondent à aucune des deux familles.

Zonal ou régional : qu'est-ce qui survit à une panne ?

La portée décide de ce qui survit à une panne, et elle est plus importante que la performance dans une décision d'architecture.

Brique	Portée	Ce qui est facturé	Réplication
Block Storage	zonale	l'espace provisionné et le palier d'IOPS	3 répliques
File Storage	régionale, mais réplication intra-zone	l'espace provisionné	3 répliques, dans une seule zone
Object Storage	régionale	l'espace réellement stocké, plus les requêtes et le trafic sortant	selon la classe choisie

Glissez pour voir

Trois conséquences en découlent, et ce sont elles qu'il faut retenir.

Block et File se facturent sur ce que vous réservez, pas sur ce que vous remplissez. Un volume de 500 Go vide coûte le prix de 500 Go. Object Storage est le seul des trois à facturer l'occupation réelle, ce qui en fait le choix naturel pour des volumes dont on ne sait pas prédire la croissance.

File Storage n'est pas une brique de haute disponibilité inter-zones. Sa réplication triple protège de la panne d'un disque ou d'un nœud, à l'intérieur d'une seule zone de disponibilité. Une architecture répartie sur trois zones dont toutes les machines montent le même partage n'a pas la résilience qu'elle croit.

Object Storage facture trois choses, pas une. Le stockage, les requêtes et le trafic sortant. Sur une charge de lecture intense, la ligne des requêtes peut dépasser celle du stockage, et c'est ce qui surprend à la première facture.

Quelles décisions ne pourrez-vous plus reprendre ?

Quatre décisions se prennent à la création et ne se reprennent pas. Les autres, taille, classe de stockage, règles de cycle de vie, se corrigent en production sans douleur. Concentrez donc votre attention sur ces quatre-là.

Décision	Pourquoi elle est irréversible	Ce que coûte l'erreur
La famille	on ne convertit pas un volume Block en partage de fichiers	recréer, puis recopier toutes les données
La région, ou la zone pour Block	une ressource ne se déplace pas	transfert facturé et interruption de service
Le nom d'un bucket	il est unique sur toute la plateforme et non modifiable	recréer et re-pointer les applications
La réduction d'un volume Block	l'agrandissement seul est possible	surprovisionner définitivement, ou migrer

Glissez pour voir

Vérifiez la compatibilité de vos Instances avant de choisir File Storage

Tous les types d'Instance n'acceptent pas de système de fichiers, et l'Instance la moins chère du catalogue en fait partie. Le champ max_file_systems vaut 0 sur DEV1-S : elle n'attachera jamais de partage, quoi que vous tentiez.

Le contrôle se fait en lecture seule, sans rien créer :

scw instance server-type list zone=fr-par-1 -o json \
  | python3 -c 'import json,sys
for s in json.load(sys.stdin):
    print(f"{s[\"name\"]:22s} {s.get(\"max_file_systems\", 0)}")' | head -20

La sortie doit afficher un nombre par type. Relevé le 10 septembre 2026 : 89 types compatibles sur 125 en fr-par-1.

Regarder le terrain avant de construire

Une carte se lit d'autant mieux qu'on a vu le terrain une fois. Ces trois commandes ne créent rien et ne coûtent rien : elles vous montrent ce que votre compte propose réellement, ce qui vaut mieux que n'importe quel tableau.

Commencez par les paliers de performance du stockage bloc, qui sont un choix à la création :

scw block volume-type list zone=fr-par-1 -o json

La sortie doit lister les types disponibles avec leurs caractéristiques d'IOPS. Vous y verrez les deux paliers, 5 000 et 15 000, et c'est là qu'il faut noter que le palier haut suppose une Instance capable de le soutenir.

Regardez ensuite si des systèmes de fichiers existent déjà dans votre Organisation :

scw file filesystem list -o json

Sur un compte neuf, la sortie doit être une liste vide, []. Si elle ne l'est pas, notez la taille provisionnée de chacun : c'est elle qui est facturée, et elle compte dans le quota d'Organisation.

Terminez par vos buckets :

scw object bucket list

La sortie doit lister les buckets existants avec leur date de création. Un compte neuf n'en a aucun.

Comment se décide un choix de stockage, en pratique

Un choix de stockage se prend dans un ordre précis, et le volume de données n'arrive qu'en dernier. On commence par identifier qui écrit : une seule machine, plusieurs machines, ou une application qui passe par une API. Cette réponse désigne à elle seule la famille dans la grande majorité des cas. On regarde ensuite ce qui doit survivre à la perte d'une zone de disponibilité, question qui écarte immédiatement le stockage bloc pour les données critiques et qui oblige à connaître la nuance de la réplication intra-zone du stockage de fichiers. On vérifie alors la compatibilité des machines retenues, parce qu'un type d'Instance mal choisi rend un partage inattachable. On situe enfin le besoin par rapport aux plafonds, en gardant en tête que ceux qui bloquent ne sont presque jamais ceux qu'on surveille. Le volume ne sert qu'à dimensionner une fois la famille arrêtée, et sur deux des trois familles il détermine aussi la performance.

Limites, quotas et plafonds

Ces plafonds décident d'une architecture avant même le premier octet écrit. Ils viennent des trois leçons de construction de ce volet, où chacun a été relevé à sa source.

Plafond	Valeur	Famille
Taille d'un volume Block	15 To	Block
Volumes par Instance	16, volume de démarrage compris, donc 15 Block	Block
Paliers d'IOPS Block	5 000 ou 15 000	Block
Taille d'un système de fichiers	25 Go à 50 To	File
Total provisionné par Organisation	500 Go à 100 To	File
IOPS d'un partage	1 000 à 25 Go, puis +12 par Go, plafond 25 000 à 2 To	File
Buckets par Organisation	100	Object
Taille d'un objet	5 To	Object
Versions par objet	1 000	Object

Glissez pour voir

Deux de ces lignes se rencontrent plus vite que les autres. Les 16 volumes par Instance bloquent les architectures qui multiplient les disques plutôt que d'en agrandir un seul. Et le total provisionné de File Storage se consomme très vite : vingt partages de 25 Go atteignent déjà le plancher de 500 Go alors qu'aucun n'est rempli.

Où la facture de stockage dérape-t-elle vraiment ?

Le poste qui surprend n'est jamais celui qu'on surveille. Sur Block et File, c'est l'espace réservé et oublié ; sur Object, ce sont les requêtes et le trafic sortant.

Un ordre de grandeur, relevé au catalogue public le 10 septembre 2026 : un système de fichiers se facture 0,000221 € par gigaoctet, ce qui met le minimum de 25 Go à un peu moins de 4 € par mois. C'est peu, et c'est précisément pourquoi ces partages s'oublient.

La dérive classique ne vient pas du stockage lui-même mais de ce qui l'entoure. Un volume Block détaché continue d'être facturé, un instantané survit à la suppression de son volume, un bucket non vidé conserve ses objets, et un partage de fichiers reste facturé même si plus aucune Instance ne le monte. Aucun de ces restes n'apparaît dans la liste des serveurs, ce qui explique qu'on les découvre à la facture.

Le stockage sous l'angle Well-Architected

Reliability : que se passe-t-il si la zone tombe ?

La question clé : chacune de vos données survit-elle à la perte de la zone de disponibilité qui l'héberge ?

Un volume Block est zonal : il disparaît avec sa zone. Un partage File est joignable depuis toute la région, mais ses trois répliques vivent dans une seule zone. Seul Object Storage offre une portée réellement régionale.

La discipline : identifier ce qui doit survivre à la perte d'une zone, et s'assurer que ces données existent aussi dans un stockage objet, quelle que soit la brique qui les sert au quotidien.

Cost Optimization : payez-vous de l'espace que personne ne remplit ?

La question clé : quel est l'écart entre l'espace provisionné et l'espace occupé, sur chacun de vos volumes et partages ?

Block et File facturant le réservé, cet écart est du gaspillage direct. Object Storage ne pose pas ce problème, mais en pose un autre : les objets qu'on ne relit jamais restent dans une classe chaude faute de règle de cycle de vie.

La discipline : comparer périodiquement l'occupation réelle à la taille réservée, et poser une règle de cycle de vie sur tout bucket dès sa création.

Performance : la performance suit-elle la bonne variable ?

La question clé : savez-vous quelle grandeur augmente la performance de la brique que vous avez choisie ?

Elles ne fonctionnent pas de la même façon. Sur Block, la performance est un palier choisi à la création, 5 000 ou 15 000 IOPS. Sur File, elle suit linéairement la capacité provisionnée, et un partage lent se corrige en l'agrandissant. Sur Object, elle dépend du parallélisme des requêtes, pas d'un réglage.

La discipline : dimensionner sur la grandeur qui compte pour la brique retenue, et non par analogie avec une autre.

Pièges courants

Ces situations se rencontrent avant même d'avoir construit quoi que ce soit, au moment du choix. Les messages sont ceux relevés en lab le 10 septembre 2026 avec scw 2.62.0, dans les leçons de ce volet.

Symptôme	Cause	Solution
'size' does not respect constraints à la création d'un partage	la taille demandée est sous le minimum de 25 Go	provisionner au moins 25 Go, sachant que la performance suit la capacité
mount: wrong fs type, bad option, bad superblock	l'Instance n'a pas redémarré depuis l'attachement du partage	redémarrer, puis vérifier que /sys/fs/virtiofs/ existe
cannot delete fs with attachments	le partage est encore attaché à une Instance	détacher d'abord, supprimer ensuite
Un volume Block refuse d'être réduit	seul l'agrandissement existe	recréer au bon format et recopier, ou assumer le surdimensionnement
Un type d'Instance n'accepte aucun partage	max_file_systems vaut 0, ce qui est un refus explicite	choisir un type compatible, vérifié dans server-type list

Glissez pour voir

Antipatterns à éviter

Ces cinq erreurs partagent la même origine : un choix de famille fait sur le volume de données plutôt que sur le mode d'accès.

Antipattern	Conséquence	Discipline
Monter du stockage objet comme un disque	performances et sémantique décevantes, sans être celles d'aucune des deux familles	choisir File Storage quand un chemin de fichiers est nécessaire
Multiplier les volumes Block plutôt que d'en agrandir un	le plafond de 16 volumes par Instance arrive vite	agrandir, l'opération est possible en ligne
Compter sur File Storage pour survivre à une panne de zone	la réplication est intra-zone : le partage disparaît avec elle	sauvegarder vers un stockage objet
Surprovisionner « au cas où » sur Block ou File	l'espace réservé est facturé, rempli ou non	provisionner au besoin mesuré, agrandir ensuite
Créer un bucket sans règle de cycle de vie	les objets froids restent en classe chaude indéfiniment	poser la règle à la création, pas en rattrapage

Glissez pour voir

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• Le mode d'accès décide de la famille, pas le volume : un disque pour une machine, un partage pour plusieurs, une API pour une application.
• Block est zonal, Object est régional, File est régional avec une réplication intra-zone. C'est cette dernière nuance qui trompe le plus.
• Block et File facturent le provisionné, Object facture l'occupation réelle plus les requêtes et le trafic sortant.
• Quatre décisions sont irréversibles : la famille, la localisation, le nom d'un bucket, et le fait qu'un volume Block ne se réduit jamais.
• max_file_systems vaut 0 sur DEV1-S : vérifiez la compatibilité avant de bâtir une architecture sur File Storage.
• 16 volumes par Instance et 500 Go de plancher provisionné pour File Storage sont les deux plafonds qui arrivent le plus vite.
• La performance ne suit pas la même variable selon la famille : un palier sur Block, la capacité sur File, le parallélisme sur Object.
• Les restes coûteux ne sont pas visibles dans la liste des serveurs : volume détaché, instantané orphelin, bucket non vidé, partage plus monté par personne.

Pour aller plus loin

• Images, cloud-init et snapshots : les instantanés sont la face cachée du stockage bloc, et la première source de restes facturés.
• File Storage : un stockage monté par plusieurs Instances : la seule des trois familles qui accepte plusieurs écrivains, avec le redémarrage obligatoire que rien n'annonce.

Ressources externes

• Documentation Block Storage : les paliers d'IOPS, les instantanés et le redimensionnement.
• Documentation Object Storage : les classes de stockage, le versionnage et les règles de cycle de vie.
• Documentation File Storage : la compatibilité des Instances et la mise à l'échelle des performances.
• Quotas d'Organisation : les plafonds de départ, à relire avant de dimensionner.

×

📖 Voir la documentation →