File Storage Scaleway : un même stockage monté par plusieurs Instances

Deux Instances qui doivent lire et écrire les mêmes fichiers n'ont que trois options : synchroniser, monter un serveur NFS, ou utiliser un stockage conçu pour ça. File Storage est la troisième, et il évite d'exploiter soi-même un serveur de fichiers. Cette leçon crée un partage, l'attache à deux Instances, le monte, et prouve l'écriture croisée. Elle insiste surtout sur l'étape que rien n'annonce et qui fait échouer le premier essai de presque tout le monde : le redémarrage obligatoire entre l'attachement et le montage.

Ce que vous allez apprendre

• Vérifier qu'un type d'Instance accepte un système de fichiers, avant de payer pour le découvrir.
• Créer un partage et l'attacher à plusieurs Instances.
• Monter en virtiofs, et comprendre pourquoi un redémarrage est indispensable.
• Prouver l'écriture croisée, au lieu de la supposer.
• Détacher et supprimer dans l'ordre imposé par les dépendances.

Quand File Storage plutôt que Block ou Object ?

Le critère de choix est le nombre d'écrivains simultanés, pas le volume. Un volume Block ne s'attache qu'à une seule Instance à la fois : c'est un disque. Le stockage Objet accepte tout le monde, mais par une API, pas par un chemin de fichiers. File Storage occupe la case restante.

Besoin	Choix	Pourquoi
Un disque pour une seule machine	Block Storage	performance par volume, attachement exclusif
Des fichiers lus et écrits par plusieurs machines	File Storage	montage simultané, sémantique POSIX
Des objets consommés par une application via API	Object Storage	pas de montage, accès HTTP, pas de limite de volume
Un partage entre pods Kubernetes en écriture multiple	File Storage via son pilote CSI	c'est le seul des trois qui donne du ReadWriteMany

Glissez pour voir

La contrainte à connaître avant de choisir est la portée. File Storage réplique vos données en trois exemplaires, mais à l'intérieur d'une seule zone de disponibilité. Ce n'est donc pas une brique de haute disponibilité inter-zones : la perte de la zone emporte le partage. Pour une architecture multi-zone, ce n'est pas ce composant qui vous sauvera.

Disponible en région de Paris seulement

Au 10 septembre 2026, File Storage n'existe qu'en région fr-par, ce que confirment le catalogue public et la FAQ officielle, qui annonce Amsterdam pour plus tard. Vérifiez-le au moment de votre projet avec la méthode de régions et zones : ce genre de ligne change sans préavis.

Quelles Instances acceptent un système de fichiers ?

Toutes ne l'acceptent pas, et l'Instance la moins chère du catalogue en fait partie. C'est la vérification à faire en premier, sous peine de créer deux machines qui ne pourront rien attacher.

L'information est exposée par l'API, dans le champ max_file_systems de chaque type. C'est la source à interroger, plutôt que le tableau de la documentation qui vieillira :

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

La sortie doit lister les types compatibles avec le nombre de systèmes de fichiers qu'ils acceptent. Relevé le 10 septembre 2026 en fr-par-1 : 89 types compatibles sur 125.

Type	max_file_systems	Conséquence
DEV1-S	0	ne peut rien attacher, malgré son prix attractif
BASIC3-X2C-4G	1	le moins cher qui fonctionne, à 0,03945 €/h
BASIC3-X4C-16G	2	deux partages simultanés

Glissez pour voir

Le champ vaut zéro, pas une absence : c'est un refus explicite, pas un oubli de l'API. Un type à zéro n'attachera jamais de système de fichiers, quel que soit ce que vous tentez.

Créer le partage

La taille se provisionne, et c'est elle que vous payez, pas ce que vous utilisez. Le minimum est de 25 Go, le maximum de 50 To par système.

1. Créez le système de fichiers. La taille s'exprime en octets, avec une granularité au gigaoctet décimal.

   FS_ID=$(scw file filesystem create name=partage-applicatif \
     size=25000000000 -o json | jq -r .id)
   scw file filesystem get filesystem-id="$FS_ID" -o json

   La sortie doit afficher "status":"creating" puis, quelques secondes plus tard, "status":"available", avec "number_of_attachments":0. Notez l'id.

2. Vérifiez son état avant d'aller plus loin.

   scw file filesystem list -o json

   La sortie doit lister votre partage avec available et sa taille en octets.

Descendre sous le minimum est refusé, avec un message qui ne nomme pas la valeur attendue :

Invalid arguments 'size'
Details:
- 'size' does not respect constraints

Attacher, puis redémarrer : l'étape que rien n'annonce

C'est le cœur de cette leçon, et l'endroit où presque tout le monde échoue au premier essai. L'attachement réussit, la commande répond sans erreur, et le montage échoue quand même.

1. Créez les deux Instances qui partageront le système de fichiers. Le type compte : DEV1-S afficherait max_file_systems: 0 et refuserait l'attachement.

   SERVEUR_1=$(scw instance server create name=partage-1 type=BASIC3-X2C-4G \
     image=ubuntu_noble zone=fr-par-1 -o json | jq -r .id)
   SERVEUR_2=$(scw instance server create name=partage-2 type=BASIC3-X2C-4G \
     image=ubuntu_noble zone=fr-par-1 -o json | jq -r .id)
   scw instance server list zone=fr-par-1 -o json

   La sortie doit lister deux Instances en running, chacune avec son adresse publique.

2. Attachez le partage à la première Instance. Attention à la syntaxe : l'identifiant du serveur est un argument nommé.

   scw instance server attach-filesystem \
     server-id="$SERVEUR_1" filesystem-id="$FS_ID" zone=fr-par-1

   La sortie doit afficher les métadonnées du serveur. Un identifiant passé en positionnel produit Unknown argument '<uuid>'.

3. Répétez pour la seconde Instance. Un même système de fichiers s'attache à plusieurs machines, c'est tout son intérêt.

4. Vérifiez côté API que le partage est bien vu comme partagé.

   scw file attachment list filesystem-id="$FS_ID" -o json

   La sortie doit lister deux attachements de type instance_server, dans la même zone.

5. Redémarrez les deux Instances. C'est l'étape manquante.

   scw instance server reboot "$SERVEUR_1" zone=fr-par-1
   scw instance server reboot "$SERVEUR_2" zone=fr-par-1

Pourquoi le montage échoue avant redémarrage, et pourquoi c'est piégeux

Le périphérique virtiofs n'est exposé à l'Instance qu'au démarrage. Attacher un système de fichiers à une machine déjà en marche ne le rend donc pas montable immédiatement, et rien ne le signale.

Avant redémarrage, mesuré le 10 septembre 2026 :

# ls /sys/fs/virtiofs/
ls: cannot access '/sys/fs/virtiofs/': No such file or directory

# mount -t virtiofs <id-du-systeme-de-fichiers> /mnt/partage
mount: /mnt/partage: wrong fs type, bad option, bad superblock on <id>,
       missing codepage or helper program, or other error.

La suite est la vraie punition. Le montage ayant échoué, /mnt/partage reste un simple répertoire du disque local. Vous y écrivez un fichier : l'écriture réussit, ls l'affiche, tout semble normal. Ce n'est qu'en lisant depuis la seconde Instance que vous découvrez qu'il n'y a rien, et la conclusion naturelle, fausse, est que le partage ne fonctionne pas.

Le contrôle qui tranche en une seconde : après redémarrage, le répertoire /sys/fs/virtiofs/ existe et contient un tag, qui est l'identifiant du système de fichiers. S'il est absent, ne montez pas, redémarrez.

Monter et prouver le partage

Le tag de montage est l'identifiant du système de fichiers, et le type est virtiofs. Aucun réseau, aucun export NFS, aucun paquet à installer : le transport est géré par la plateforme.

1. Montez sur chaque Instance, dans un sous-répertoire dédié plutôt que directement dans /mnt.

   mkdir -p /mnt/partage
   mount -t virtiofs "$FS_ID" /mnt/partage
   df -hT /mnt/partage

   La sortie de df doit afficher le type virtiofs et une taille utile de 24 Go pour 25 Go provisionnés.

2. Écrivez depuis la première Instance.

   echo 'ecrit-par-n1' > /mnt/partage/depuis-n1.txt && sync

3. Lisez depuis la seconde. C'est la seule preuve qui compte.

   cat /mnt/partage/depuis-n1.txt

   La sortie doit afficher ecrit-par-n1. Si elle affiche No such file or directory, le montage a échoué quelque part : reprenez au contrôle de /sys/fs/virtiofs/.

4. Faites le chemin inverse, pour écarter tout doute sur le sens de la synchronisation.

   # sur la seconde
   echo 'reponse-de-n2' > /mnt/partage/depuis-n2.txt && sync
   # sur la première
   cat /mnt/partage/depuis-n2.txt
   ls -1 /mnt/partage/

   La dernière commande doit lister les deux fichiers.

Le montage se vérifie aussi dans la table des montages, ce qui lève toute ambiguïté sur ce qui est réellement monté :

mount | grep partage

La sortie doit ressembler à <id> on /mnt/partage type virtiofs (rw,relatime).

Combien de performance pour quelle taille ?

Les performances augmentent linéairement avec la capacité provisionnée, et c'est un choix d'architecture, pas un réglage. Vous ne réglez pas les IOPS séparément : vous provisionnez de l'espace, et la performance suit.

Capacité provisionnée	IOPS	Débit
25 Go, le minimum	1 000	palier de base
100 Go	1 900, soit 1 000 + 75 × 12	proportionnel
2 To et au-delà	25 000, plafond	200 Mo/s, plafond

Glissez pour voir

La règle est de +12 IOPS par gigaoctet provisionné au-dessus du palier de base. Au-delà de 2 To, provisionner davantage ajoute de l'espace mais plus aucune performance : les deux plafonds sont atteints.

La conséquence pratique est qu'un partage lent se corrige en l'agrandissant, ce qui est inhabituel. Si votre application sature à 1 000 IOPS sur un partage de 25 Go, la réponse n'est pas d'optimiser le code en premier, c'est de vérifier si le palier de performance correspond au besoin.

Comment une application se sert-elle réellement d'un partage ?

Le cycle complet d'un partage compte quatre moments, et trois d'entre eux se préparent avant la mise en service. On crée d'abord le système de fichiers en choisissant sa capacité, décision qui fixe à la fois l'espace et la performance, puisque les deux sont liés chez ce produit. On l'attache ensuite à chaque Instance qui devra le lire ou l'écrire, en ayant vérifié au préalable que leur type l'accepte. On redémarre alors ces Instances, étape sans laquelle le périphérique n'apparaît pas, puis on inscrit le montage dans leur configuration de démarrage pour qu'il survive au prochain redémarrage, planifié ou non. Vient enfin l'exploitation, où le partage se comporte comme un système de fichiers ordinaire pour l'application, qui n'a aucune conscience d'écrire sur un stockage réseau. C'est cette transparence qui fait l'intérêt du produit, et c'est aussi ce qui rend son diagnostic déroutant : quand le montage échoue, l'application ne signale rien, elle écrit simplement ailleurs.

Limites, quotas et plafonds

Limite	Valeur	Source
Taille d'un système de fichiers	25 Go à 50 To	FAQ officielle, minimum confirmé en lab
Total provisionné par Organisation	500 Go à 100 To	FAQ officielle
IOPS maximum	25 000, atteints à 2 To	documentation de mise à l'échelle
Débit maximum	200 Mo/s, atteints à 2 To	documentation de mise à l'échelle
Systèmes par Instance	0 à 2 selon le type	max_file_systems, relevé le 2026-09-10
Réplication	triple, dans une seule zone	FAQ officielle

Glissez pour voir

Le quota d'Organisation est celui qu'on oublie : il porte sur le total provisionné, tous systèmes confondus. Vingt partages de 25 Go consomment 500 Go de quota, soit le plancher, alors qu'aucun n'est rempli.

Ce que ça coûte

Vous payez l'espace provisionné, pas l'espace utilisé. C'est la caractéristique tarifaire à retenir : un partage de 2 To vide coûte le même prix qu'un partage de 2 To plein.

Le tarif relevé au catalogue public le 10 septembre 2026 est de 0,000221 € par gigaoctet. Sur le minimum de 25 Go, cela met le partage à quelques millièmes d'euro de l'heure, soit un peu moins de 4 € par mois.

Le poste dominant n'est donc pas le partage, ce sont les Instances qui l'utilisent. Une BASIC3-X2C-4G, le type compatible le moins cher, coûte 0,03945 € de l'heure, soit près de dix fois le partage lui-même. Dimensionnez donc le calcul avec autant de soin que le stockage.

File Storage sous l'angle Well-Architected

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

La question clé : votre partage survit-il à la perte de la zone de disponibilité qui l'héberge ?

Non. La triple réplication protège de la panne d'un disque ou d'un nœud, à l'intérieur d'une seule zone. Une architecture qui répartit ses Instances sur trois zones pour survivre à la perte de l'une d'elles, mais dont toutes montent le même partage, n'a pas la résilience qu'elle croit avoir.

La discipline : traiter File Storage comme un composant zonal, et prévoir une sauvegarde vers un stockage objet si le contenu compte.

Operational Excellence : votre montage survit-il à un redémarrage ?

La question clé : après un redémarrage non planifié, l'application retrouve -t-elle son partage, ou faut-il une intervention ?

Un mount lancé à la main disparaît au redémarrage suivant. C'est acceptable en lab, jamais en production.

La discipline : inscrire le montage dans la configuration de démarrage de la machine, et vérifier qu'il tient en redémarrant volontairement une fois, avant la mise en service.

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 réellement occupé sur chacun de vos partages ?

La facturation portant sur le provisionné, cet écart est du gaspillage pur. Et comme la performance dépend de la taille, la tentation est de surprovisionner « pour la vitesse », ce qui est parfois justifié mais doit être décidé.

La discipline : comparer périodiquement df sur les Instances à la taille provisionnée, et savoir dire si le surdimensionnement est un choix de performance ou un oubli.

Pièges courants

Ces situations ont toutes été provoquées en lab le 10 septembre 2026 avec scw 2.62.0.

Symptôme	Cause	Solution
mount: /mnt/partage: wrong fs type, bad option, bad superblock	l'Instance n'a pas redémarré depuis l'attachement	redémarrer, puis vérifier que /sys/fs/virtiofs/ existe
L'écriture réussit mais l'autre Instance ne voit rien	le montage a échoué, le répertoire est resté local	contrôler mount | grep partage avant d'écrire
Unknown argument '<uuid>'	l'identifiant du serveur a été passé en positionnel	utiliser server-id=
Instance must be in state stopped, stopped in place or running to change filesystems.	l'Instance était encore en train de démarrer	attendre l'état running avant d'attacher
cannot delete fs with attachments	le partage est encore attaché à une Instance	détacher d'abord, supprimer ensuite
'size' does not respect constraints	la taille demandée est sous le minimum	25 Go au minimum

Glissez pour voir

Antipatterns à éviter

Ces erreurs ont un point commun : elles traitent un partage réseau comme un disque local.

Antipattern	Conséquence	Discipline
Monter à la main sans inscrire le montage au démarrage	le partage disparaît au premier redémarrage, en production	déclarer le montage dans la configuration de la machine
Écrire sans avoir vérifié que le montage a réussi	les données partent sur le disque local, et personne ne s'en aperçoit	contrôler mount avant la première écriture
Compter sur File Storage pour survivre à la perte d'une zone	la réplication est intra-zone : le partage disparaît avec elle	sauvegarder vers un stockage objet
Choisir l'Instance la moins chère sans vérifier max_file_systems	deux machines créées, payées, incapables d'attacher quoi que ce soit	lire le champ avant de créer
Provisionner petit puis se plaindre de la lenteur	la performance est liée à la capacité, pas réglable à part	dimensionner sur les IOPS visées, pas sur l'espace occupé

Glissez pour voir

Nettoyer

L'ordre est imposé par les dépendances : un partage attaché ne se supprime pas.

1. Détachez le partage de chaque Instance.

   scw instance server detach-filesystem \
     server-id="$SERVEUR_1" filesystem-id="$FS_ID" zone=fr-par-1

2. Supprimez les Instances, avec leurs volumes et leurs adresses, sans quoi ces deux-là continuent d'être facturés.

   scw instance server terminate "$SERVEUR_1" zone=fr-par-1 \
     with-block=true with-ip=true

3. Supprimez le système de fichiers.

   scw file filesystem delete filesystem-id="$FS_ID"

   La sortie doit afficher « Filesystem has been successfully deleted. »

4. Vérifiez le retour à zéro sur les quatre familles concernées.

   scw file filesystem list -o json
   scw instance server list zone=fr-par-1 -o json
   scw instance volume list zone=fr-par-1 -o json
   scw instance ip list zone=fr-par-1 -o json

   Les quatre sorties doivent être des listes vides.

La suppression d'une Instance est asynchrone

terminate répond « Success » avant que la machine ait fini de disparaître. Une liste demandée dans la foulée peut encore l'afficher, ce qui fait croire à un échec du nettoyage. Mesuré pendant ce lab : le serveur était absent de la liste quelques dizaines de secondes plus tard.

Attendez, puis relistez, plutôt que de relancer la suppression.

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 critère de choix est le nombre d'écrivains simultanés : Block pour une machine, File Storage pour plusieurs, Object pour un accès par API.
• Tous les types d'Instance n'acceptent pas de partage : max_file_systems vaut 0 sur DEV1-S. Lisez le champ avant de créer quoi que ce soit.
• Un redémarrage est obligatoire entre l'attachement et le montage : le périphérique virtiofs n'est exposé qu'au démarrage.
• Un montage échoué ne se voit pas à l'écriture : le répertoire reste local, l'écriture réussit, et seule la lecture depuis la seconde machine révèle le problème.
• Le tag de montage est l'identifiant du système de fichiers, et le type est virtiofs, sans NFS ni réseau à configurer.
• La performance suit la capacité provisionnée : 1 000 IOPS à 25 Go, +12 par Go, plafond de 25 000 IOPS et 200 Mo/s atteint à 2 To.
• Vous payez le provisionné, pas l'utilisé, et le quota d'Organisation porte sur le total provisionné, de 500 Go à 100 To.
• La réplication est triple mais intra-zone : le partage ne survit pas à la perte de sa zone de disponibilité.

Pour aller plus loin

• Sécurité et identité Scaleway : la carte avant de construire : qui a le droit de créer et d'attacher un partage se décide dans IAM.
• Infrastructure as Code : qui fait quoi : un partage et ses attachements se déclarent, plutôt que de se recréer à la main.

Ressources externes

• Documentation File Storage : les concepts, les guides de montage et la référence de l'API.
• Mise à l'échelle des performances : la formule exacte qui relie capacité provisionnée, IOPS et débit.
• Compatibilité des types d'Instances : le tableau officiel, à croiser avec le champ max_file_systems de l'API.
• File Storage avec Kubernetes Kapsule : le pilote CSI qui donne du ReadWriteMany aux pods.

×

📖 Voir la documentation →