RustFS : stockage objet S3 haute performance en Rust

RustFS est un stockage objet S3 haute performance écrit en Rust et distribué sous licence Apache 2.0. Inspiré de l'architecture de MinIO, il promet des performances 2,3x supérieures pour les petits objets (4 Ko) grâce aux optimisations de Rust. Ce guide déploie un cluster distribué 4 nœuds avec erasure coding, teste l'API S3 complète et configure un service systemd, le tout sur des machines virtuelles Ubuntu 24.04 avec RustFS 1.0.1. Il s'adresse à qui sait déjà utiliser un terminal Linux et a entendu parler de S3 ; chaque notion nouvelle est définie en route.

Un projet jeune : évaluez avant de migrer

RustFS a publié sa première version stable (1.0.0) le 16 septembre 2026 ; ce guide utilise la 1.0.1 (3 octobre 2026). Le projet est récent : sa configuration a encore changé entre les versions préliminaires. Évaluez-le sur vos charges réelles avant d'y placer des données critiques, et gardez une sauvegarde ailleurs.

Ce que vous allez apprendre

• Architecture : comprendre le modèle peer-to-peer sans master et l'erasure coding
• Mode single-node : démarrer RustFS sur un seul serveur pour le test
• Cluster distribué : déployer un cluster 4 nœuds avec systemd
• API S3 : créer des buckets, uploader/télécharger des fichiers avec AWS CLI
• Contrôle d'accès : restreindre un utilisateur à un préfixe et brancher une fédération OIDC
• Dépannage : résoudre les problèmes courants (503, convergence, secret RPC, format)

Qu'est-ce que RustFS ?

RustFS est un système de stockage objet distribué open source développé en Rust (compilateur Rust 1.93+). Il fournit une API compatible S3 (avec des limites, voir l'encadré plus bas) et une console d'administration web, le tout dans un unique binaire statique sans dépendance. Le projet a été créé en 2024 et reste en développement actif sur GitHub.

Ce qui distingue RustFS

Deux arguments du tableau ci-dessous ressortent et méritent d'être pesés séparément. Le premier, la performance, reste à confirmer par vos propres mesures, le chiffre « 2,3x plus rapide que MinIO » venant du projet lui-même. Le second, la licence Apache 2.0, est un fait juridique vérifiable et souvent le vrai motif de migration : il évite la clause copyleft de l'AGPLv3 que MinIO impose à quiconque expose son API.

Caractéristique	Description
Haute performance	Écrit en Rust, optimisé pour les petits objets (2,3x plus rapide que MinIO sur 4 Ko)
Peer-to-peer	Pas de nœud maître, tous les nœuds sont égaux et interchangeables
Erasure coding	Reed-Solomon intégré : protège les données avec moins d'espace que la réplication
Binaire unique	Un seul exécutable statique (~270 Mo décompressé), aucune dépendance système
S3 compatible	API S3 compatible, utilisable avec AWS CLI, MinIO Client (mc) et les SDK S3 (quelques requêtes ne sont pas implémentées)
Console web	Interface d'administration intégrée (port 9001)
Apache 2.0	Licence permissive, sans la contrainte copyleft de l'AGPLv3

Glissez pour voir

Compatible MinIO, mais pas identique

RustFS est un stockage objet S3 écrit en Rust sous licence Apache 2.0, avec une API et un modèle IAM compatibles MinIO. Cette compatibilité a des limites : l'OIDC se configure par variables d'environnement, le cluster exige un secret RPC, et certaines requêtes S3 ne sont pas implémentées (un s3cmd setacl --acl-public renvoie 501 NotImplemented). Ce guide sert à mesurer, en lab, où en est le projet.

Architecture et concepts clés

Trois idées suffisent à comprendre le fonctionnement de RustFS : un modèle peer-to-peer sans nœud maître, la protection des données par erasure coding, et une poignée de ports réseau à ouvrir. Le schéma ci-dessous relie ces trois briques ; les sous-sections qui suivent les détaillent une à une.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Modèle peer-to-peer

Contrairement à SeaweedFS (master + volume servers) ou Ceph (monitors + OSDs), RustFS utilise une architecture entièrement décentralisée. Tous les nœuds sont identiques : chacun expose l'API S3 sur le port 9000 et la console web sur le port 9001. N'importe quel nœud peut recevoir les requêtes client.

Les nœuds communiquent entre eux via gRPC pour coordonner les opérations d'écriture et distribuer les fragments d'erasure coding.

Erasure coding (Reed-Solomon)

L'erasure coding est la méthode utilisée par RustFS pour protéger les données. Au lieu de copier 3 fois chaque fichier (réplication 3x), l'erasure coding découpe les données en fragments de données et génère des fragments de parité supplémentaires.

Comment ça fonctionne :

Concept	Explication
Drive	Un disque physique ou un répertoire de stockage sur un nœud
Set (erasure set)	Un groupe de drives répartis sur plusieurs nœuds. Chaque objet vit dans un seul set
Fragments de données	Les morceaux du fichier original, répartis entre les drives du set
Fragments de parité	Des données de correction calculées par l'algorithme Reed-Solomon

Glissez pour voir

Exemple avec 4 nœuds et 1 drive chacun (notre lab) :

• 1 erasure set de 4 drives
• 2 fragments de données + 2 fragments de parité (EC:2)
• Tolérance : jusqu'à 2 drives en panne simultanée sans perte

Comparaison avec la réplication :

Méthode	Stockage pour 1 Go utile	Tolérance de panne
Réplication 3x	3 Go (300 %)	2 copies perdues
Erasure coding EC:2 (4 drives)	2 Go (200 %)	2 drives perdus
EC:4 (configuration 12+4)	1,33 Go (133 %)	4 drives perdus

Glissez pour voir

XFS recommandé

RustFS recommande fortement le système de fichiers XFS pour les disques de stockage, avec une taille d'inode de 512 octets. En production, utilisez les disques en mode JBOD (pas de RAID), l'erasure coding assure la protection des données.

Modes de déploiement

RustFS supporte 3 modes de déploiement :

Mode	Description	Minimum
SNSD (Single-Node Single-Drive)	Un nœud, un disque. Pour le test uniquement	1 nœud, 1 disque
SNMD (Single-Node Multi-Drive)	Un nœud, plusieurs disques. Erasure coding local	1 nœud, 4 disques
MNMD (Multi-Node Multi-Drive)	Plusieurs nœuds, chacun avec 1+ disques. Production	4 nœuds minimum

Glissez pour voir

Ports réseau

RustFS n'ouvre que deux ports, et la confusion entre les deux est une source d'erreur fréquente. Le 9000 porte à la fois l'API S3 des clients et le trafic gRPC entre nœuds : c'est le seul port strictement nécessaire au fonctionnement du cluster. Le 9001 ne sert qu'à la console web et peut rester fermé aux clients, voire restreint à un réseau d'administration.

Port	Usage
9000	API S3 (requêtes client, communication inter-nœuds)
9001	Console web d'administration

Glissez pour voir

Lab : mode single-node (test rapide)

Avant de déployer un cluster complet, commençons par un nœud unique pour valider l'installation et tester l'API S3.

Prérequis

• 1 machine Linux (VM, serveur, WSL)
• Ubuntu 24.04 (ou toute distribution Linux x86_64)
• 2 Go de RAM minimum
• wget et unzip (absents des images Ubuntu minimales : sudo apt install -y wget unzip)
• AWS CLI installé (le paquet awscli n'existe plus dans les dépôts d'Ubuntu 24.04 : suivez le guide AWS CLI)

Installer RustFS

1. Télécharger le binaire :

   Le téléchargement est épinglé à la version testée dans ce guide (v1.0.1) plutôt qu'au flux latest, pour que la sortie de rustfs --version corresponde à ce qui est décrit ici. Le projet publie un fichier de sommes SHA256SUMS avec chaque release sur GitHub : contrôlez l'archive avant de l'extraire. Si la commande sha256sum n'affiche pas OK, arrêtez-vous.

   wget https://dl.rustfs.com/artifacts/rustfs/release/rustfs-linux-x86_64-musl-v1.0.1.zip
   wget https://github.com/rustfs/rustfs/releases/download/1.0.1/SHA256SUMS
   grep rustfs-linux-x86_64-musl-v1.0.1.zip SHA256SUMS | sha256sum --check
   unzip rustfs-linux-x86_64-musl-v1.0.1.zip
   sudo mv rustfs /usr/local/bin/
   sudo chmod +x /usr/local/bin/rustfs

   La vérification doit afficher rustfs-linux-x86_64-musl-v1.0.1.zip: OK. L'archive contient deux exécutables, rustfs et rustfs-cli : seul le premier sert dans ce guide.

   Vérification :

   rustfs --version

   La première ligne de la sortie donne la version, suivie des informations de compilation :

   rustfs 1.0.1

2. Créer le répertoire de données :

   sudo mkdir -p /data/rustfs0
   sudo chown "$USER": /data/rustfs0

   Le chown est nécessaire : le serveur est lancé sous votre compte à l'étape suivante, et un répertoire créé par sudo appartient à root. Sans lui, le démarrage échoue avec Server runtime failed: Io error: Permission denied.

3. Démarrer en mode single-node :

   rustfs --address :9000 \
     --console-enable \
     --access-key rustfsadmin \
     --secret-key rustfsadmin \
     /data/rustfs0

   Le serveur n'affiche rien par défaut et garde le terminal : c'est normal. Depuis un second terminal, la sonde de santé confirme qu'il répond :

   curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:9000/health

   La commande doit afficher 200. Pour suivre le démarrage, relancez le serveur avec RUST_LOG=info devant la commande : il écrit alors un journal JSON sur la sortie d'erreur, qui contient les adresses de l'API et de la console, puis la ligne RustFS server ready.

Tester l'API S3

Ouvrez un second terminal et configurez les variables d'environnement pour AWS CLI :

export AWS_ACCESS_KEY_ID=rustfsadmin
export AWS_SECRET_ACCESS_KEY=rustfsadmin
export AWS_DEFAULT_REGION=us-east-1

Créer un bucket :

aws --endpoint-url http://localhost:9000 s3 mb s3://test-bucket

make_bucket: test-bucket

Uploader un fichier :

echo "Hello RustFS!" > /tmp/test.txt
aws --endpoint-url http://localhost:9000 s3 cp /tmp/test.txt s3://test-bucket/docs/

upload: /tmp/test.txt to s3://test-bucket/docs/test.txt

Lister les objets :

aws --endpoint-url http://localhost:9000 s3 ls s3://test-bucket --recursive

2026-03-01 10:27:16         14 docs/test.txt

Télécharger un fichier :

aws --endpoint-url http://localhost:9000 s3 cp s3://test-bucket/docs/test.txt /tmp/download.txt
cat /tmp/download.txt

Hello RustFS!

Générer une URL pré-signée (accès temporaire sans authentification) :

aws --endpoint-url http://localhost:9000 s3 presign s3://test-bucket/docs/test.txt --expires-in 3600

http://localhost:9000/test-bucket/docs/test.txt?X-Amz-Algorithm=AWS4-HMAC-SHA256&...

Upload multipart (fichiers volumineux) :

dd if=/dev/urandom of=/tmp/bigfile.bin bs=1M count=10 2>/dev/null
aws --endpoint-url http://localhost:9000 s3 cp /tmp/bigfile.bin s3://test-bucket/data/

upload: /tmp/bigfile.bin to s3://test-bucket/data/bigfile.bin

Arrêtez proprement

Stoppez le serveur avec Ctrl+C avant de passer au mode distribué. Nettoyez les données de test avec sudo rm -rf /data/rustfs0, sans /* : le dossier caché .rustfs.sys doit disparaître aussi (voir l'encadré de la section Dépannage).

Lab : cluster distribué 4 nœuds

Le mode distribué est le déploiement réel de RustFS. Il nécessite au minimum 4 serveurs pour former un erasure set fonctionnel.

Prérequis

• 4 machines avec Ubuntu 24.04
• 2 Go de RAM et 1 vCPU par nœud
• Connectivité réseau entre tous les nœuds (port 9000)
• Le binaire RustFS installé sur chaque nœud

Préparer les nœuds

1. Configurer la résolution DNS sur chaque nœud :

   Ajoutez dans /etc/hosts de chaque nœud les 4 adresses :

   sudo tee -a /etc/hosts << 'EOF'
   192.168.122.31 node1
   192.168.122.20 node2
   192.168.122.64 node3
   192.168.122.212 node4
   EOF

   Remplacez les adresses IP par celles de vos machines.

   Vérification : depuis chaque nœud, les 3 autres doivent répondre au ping :

   ping -c1 node1 && ping -c1 node2 && ping -c1 node3 && ping -c1 node4

2. Créer le répertoire de données sur chaque nœud :

   sudo mkdir -p /data/rustfs0
   sudo mkdir -p /var/logs/rustfs

3. Configurer les variables d'environnement :

   Créez le fichier /etc/default/rustfs sur chaque nœud (contenu identique) :

   sudo tee /etc/default/rustfs << 'EOF'
   RUSTFS_ACCESS_KEY=rustfsadmin
   RUSTFS_SECRET_KEY=rustfsadmin
   RUSTFS_VOLUMES="http://node{1...4}:9000/data/rustfs0"
   RUSTFS_ADDRESS=":9000"
   RUSTFS_CONSOLE_ENABLE=true
   RUST_LOG=error
   RUSTFS_OBS_LOG_DIRECTORY="/var/logs/rustfs/"
   RUSTFS_RPC_SECRET="REMPLACEZ-PAR-UN-SECRET-ALEATOIRE"
   EOF

   Remplacez la valeur de RUSTFS_RPC_SECRET par une chaîne aléatoire (par exemple le résultat de openssl rand -base64 24), identique sur les 4 nœuds. Ce secret authentifie les échanges gRPC entre nœuds. Sans lui, et tant que les identifiants restent les valeurs par défaut rustfsadmin / rustfsadmin (qu'il refuse de réutiliser pour en dériver un), le service échoue au démarrage avec endpoints include remote nodes but RPC authentication secret is not configured.

   La syntaxe {1...4} (trois points) est spécifique à RustFS, elle génère automatiquement les URLs pour node1 à node4. Ne confondez pas avec la syntaxe shell {1..4} (deux points).

   Credentials

   En production, utilisez des identifiants forts et uniques. Les valeurs rustfsadmin/rustfsadmin sont uniquement pour le lab.

4. Créer le service systemd :

   Le fichier /etc/systemd/system/rustfs.service est identique sur chaque nœud :

   sudo tee /etc/systemd/system/rustfs.service << 'EOF'
   [Unit]
   Description=RustFS Object Storage Server
   Documentation=https://rustfs.com/docs/
   After=network-online.target
   Wants=network-online.target
   
   [Service]
   Type=notify
   NotifyAccess=main
   User=root
   Group=root
   
   WorkingDirectory=/usr/local
   EnvironmentFile=-/etc/default/rustfs
   ExecStart=/usr/local/bin/rustfs $RUSTFS_VOLUMES
   
   LimitNOFILE=1048576
   TasksMax=infinity
   Restart=always
   RestartSec=10s
   
   [Install]
   WantedBy=multi-user.target
   EOF

   Le Type=notify indique que RustFS notifie systemd une fois prêt à recevoir des requêtes. Le service redémarre automatiquement en cas de crash (Restart=always).

Démarrer le cluster

Démarrage simultané recommandé

Lancez le service sur tous les nœuds en même temps. RustFS attend de pouvoir contacter tous les pairs avant de devenir opérationnel. Un nœud qui démarre seul reste dans l'état activating de systemd et son API répond 503 : il patiente (observé plus de 4 minutes sans abandon) et devient active dès que les autres nœuds le rejoignent.

Démarrez sur les 4 nœuds simultanément :

sudo systemctl enable --now rustfs

Vérification (sur chaque nœud) :

sudo systemctl is-active rustfs

Résultat attendu : active.

Confirmez ensuite que l'API répond sur chaque nœud :

curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:9000/health

La commande doit afficher 200. Avec RUST_LOG=error, le journal systemd (sudo journalctl -u rustfs --no-pager -n 5) ne contient que les lignes Starting rustfs.service et Started rustfs.service, sans message de RustFS : l'absence d'erreur est le signe que tout va bien. Pour voir le détail du démarrage, passez RUST_LOG=info dans /etc/default/rustfs, puis redémarrez le service : les messages, au format JSON, sont écrits dans /var/logs/rustfs/rustfs.log et se terminent par RustFS server ready.

La convergence prend quelques secondes : le temps que chaque nœud contacte les 3 autres et synchronise les métadonnées de format (format.json).

Tester le cluster distribué

Configurez AWS CLI pour pointer vers n'importe quel nœud du cluster :

export AWS_ACCESS_KEY_ID=rustfsadmin
export AWS_SECRET_ACCESS_KEY=rustfsadmin
export AWS_DEFAULT_REGION=us-east-1

Créer un bucket via node1 :

aws --endpoint-url http://node1:9000 s3 mb s3://cluster-bucket

make_bucket: cluster-bucket

Uploader via node1, lire depuis node2 :

echo "Test distribué RustFS" > /tmp/cluster-test.txt
aws --endpoint-url http://node1:9000 s3 cp /tmp/cluster-test.txt s3://cluster-bucket/docs/test.txt
aws --endpoint-url http://node2:9000 s3 ls s3://cluster-bucket --recursive

2026-03-01 10:37:39         23 docs/test.txt

Le fichier uploadé sur node1 est immédiatement accessible depuis node2 : les métadonnées et fragments d'erasure coding sont distribués entre les 4 nœuds.

Télécharger depuis node3 :

aws --endpoint-url http://node3:9000 s3 cp s3://cluster-bucket/docs/test.txt /tmp/dl.txt
cat /tmp/dl.txt

Test distribué RustFS

Upload multipart via node1, vérification depuis node4 :

dd if=/dev/urandom of=/tmp/bigfile.bin bs=1M count=10 2>/dev/null
aws --endpoint-url http://node1:9000 s3 cp /tmp/bigfile.bin s3://cluster-bucket/data/bigfile.bin
aws --endpoint-url http://node4:9000 s3 ls s3://cluster-bucket --recursive

2026-03-01 10:37:50   10485760 data/bigfile.bin
2026-03-01 10:37:39         23 docs/test.txt

Chaque objet est réparti en fragments d'erasure coding sur les 4 drives du cluster. N'importe quel nœud peut servir n'importe quel objet.

Console web

RustFS fournit une interface d'administration web accessible sur le port 9001 :

http://node1:9001/rustfs/console/index.html

Connectez-vous avec les identifiants configurés dans /etc/default/rustfs (rustfsadmin / rustfsadmin). La console permet de parcourir les buckets, gérer les utilisateurs et surveiller l'état du cluster.

Accès console

La console web se pilote depuis un navigateur. Avec curl, la page de connexion (/rustfs/console/index.html) répond 200, mais la racine du port 9001 répond 403 : c'est normal, ne l'utilisez pas comme sonde de santé (la sonde est /health sur le port 9000).

Contrôle d'accès : préfixe, OIDC et STS

RustFS reprend le modèle IAM de MinIO (IAM : la gestion des utilisateurs et de leurs droits) : des politiques au format S3, la restriction par préfixe, la fédération OIDC (se connecter avec un compte d'un fournisseur d'identité externe) et des identifiants temporaires STS (Security Token Service) obtenus par AssumeRoleWithWebIdentity. Les exemples ci-dessous supposent le client mc (MinIO Client), jq, Docker et un fournisseur OIDC existant ; ce sont des extraits à adapter, pas un lab pas à pas. L'OIDC demande une subtilité de configuration propre à RustFS.

Restreindre un utilisateur à un préfixe

La politique cible les objets sous data/equipe-a/* et conditionne le listage avec s3:prefix :

{
  "Version": "2012-10-17",
  "Statement": [
    { "Effect": "Allow", "Action": ["s3:ListBucket"], "Resource": ["arn:aws:s3:::data"],
      "Condition": { "StringLike": { "s3:prefix": ["equipe-a/*"] } } },
    { "Effect": "Allow", "Action": ["s3:GetObject","s3:PutObject","s3:DeleteObject"],
      "Resource": ["arn:aws:s3:::data/equipe-a/*"] }
  ]
}

mc alias set rustfs http://127.0.0.1:9000 <accessKey> <secretKey>
mc admin policy create rustfs equipe-a /tmp/policy-equipe-a.json
mc admin user add rustfs alice AliceSecret123
mc admin policy attach rustfs equipe-a --user alice

L'utilisateur alice lit et écrit alors sous equipe-a/ uniquement ; tout autre préfixe renvoie AccessDenied.

Fédération OIDC via variables d'environnement

L'OIDC de RustFS se configure par variables d'environnement

C'est le piège à connaître : contrairement à MinIO, mc admin config set identity_openid enregistre la config mais ne câble pas le fournisseur à l'exécution (l'échange STS échoue alors avec no OIDC provider configured for issuer). RustFS lit sa configuration OIDC dans des variables d'environnement au démarrage. C'est la seule méthode qui active réellement le fournisseur.

On passe les variables RUSTFS_IDENTITY_OPENID_* au conteneur ou au service. Le claim (une information portée par le jeton d'identité, ici une liste de rôles) désigné par ROLES_CLAIM fournit le nom de la politique attachée aux identifiants temporaires (il doit correspondre à une politique existante) :

docker run -d --name rustfs -p 9000:9000 \
  -e RUSTFS_ACCESS_KEY=<accessKey> -e RUSTFS_SECRET_KEY=<secretKey> -e RUSTFS_VOLUMES=/data \
  -e RUSTFS_IDENTITY_OPENID_ENABLE=true \
  -e RUSTFS_IDENTITY_OPENID_CONFIG_URL="https://sso.example.com/realms/stockage/.well-known/openid-configuration" \
  -e RUSTFS_IDENTITY_OPENID_CLIENT_ID=rustfs \
  -e RUSTFS_IDENTITY_OPENID_CLIENT_SECRET=<secret> \
  -e RUSTFS_IDENTITY_OPENID_SCOPES=openid \
  -e RUSTFS_IDENTITY_OPENID_ROLES_CLAIM=roles \
  rustfs/rustfs:1.0.1@sha256:1803faef57627e2d9c2e7d89d655d712ddded5389040054987163043fecb6a3c

Le tag de l'image est épinglé sur la même version que le binaire installé plus haut, et sur son empreinte (@sha256:...), pour éviter que le flux latest ne fasse dériver le comportement de l'OIDC entre deux exécutions. L'image déclare un volume sur /data : pour arrêter le test sans laisser de volume orphelin, utilisez docker rm -fv rustfs.

Créez ensuite une politique nommée comme la valeur du claim (par exemple s3-read-write si le jeton porte roles: ["s3-read-write"]), scopée au préfixe voulu. L'échange STS se fait en POST :

TOKEN=$(curl -s https://sso.example.com/realms/stockage/protocol/openid-connect/token \
  -d grant_type=password -d client_id=rustfs -d client_secret=<secret> \
  -d username=<user> -d password=<pwd> -d scope=openid | jq -r .access_token)

curl -s -X POST http://127.0.0.1:9000/ \
  --data-urlencode "Action=AssumeRoleWithWebIdentity" \
  --data-urlencode "Version=2011-06-15" \
  --data-urlencode "WebIdentityToken=$TOKEN"
# -> <Credentials> : AccessKeyId, SecretAccessKey, SessionToken temporaires

Les identifiants temporaires portent la politique nommée par le claim : leur détenteur est cloisonné au préfixe et l'accès expire automatiquement.

Bonnes pratiques

Réseau

Comme tous les nœuds sont équivalents, aucun n'est un point d'entrée naturel : c'est à vous de placer un répartiteur devant le cluster et de fiabiliser la résolution de noms. Les trois points ci-dessous couvrent l'entrée du trafic, la résolution et le filtrage.

• Load balancer : en production, placez un reverse proxy (HAProxy, Nginx) devant les nœuds pour distribuer les requêtes en round-robin sur le port 9000
• DNS : utilisez un enregistrement DNS qui résout vers tous les nœuds plutôt que /etc/hosts
• Pare-feu : ouvrez les ports 9000 (S3 inter-nœuds + clients) et 9001 (console, accès restreint)

Dimensionnement

Le dimensionnement d'un cluster d'erasure coding ne se résume pas au nombre de nœuds : le nombre de drives compte tout autant, car c'est lui qui fixe le rapport données/parité et donc la tolérance de panne. Visez plusieurs disques par nœud plutôt qu'un seul gros disque.

• 4 nœuds minimum pour le mode distribué (MNMD)
• Disques XFS en JBOD pour la meilleure performance avec l'erasure coding
• Plusieurs disques par nœud en production : la syntaxe http://node{1...4}:9000/data/rustfs{0...3} crée 4 drives par nœud, soit 16 drives au total pour un meilleur erasure set

Sécurité

RustFS démarre avec des identifiants d'administration en clair et sans chiffrement de transport : les deux réglages par défaut à ne jamais laisser en production. Le premier point ci-dessous est le plus urgent, un rustfsadmin/rustfsadmin exposé donne un accès total au stockage.

• Changez les identifiants par défaut : rustfsadmin/rustfsadmin est uniquement pour le test
• TLS : configurez un certificat pour chiffrer les communications S3 et inter-nœuds
• Réseau dédié : isolez le trafic inter-nœuds sur un VLAN ou réseau privé

Dépannage

La quasi-totalité des blocages en mode distribué se ramène à un même thème : la convergence initiale du cluster, ce moment où les quatre nœuds échangent leur format.json. Tant qu'elle n'a pas abouti, l'API répond 503, le service reste activating et les logs répètent la recherche des formats. Avant tout, vérifiez donc que tous les nœuds tournent et se joignent sur le port 9000 ; la plupart des lignes du tableau en découlent.

Symptôme	Cause probable	Solution
503 Service Unavailable sur S3, service activating	Le cluster n'a pas convergé : au moins un nœud n'est pas démarré ou pas joignable	Démarrez les nœuds manquants : les autres convergent d'eux-mêmes. Si tous tournent, vérifiez /etc/hosts et le port 9000 entre nœuds
load_format_erasure err: ... RemoteClientUnavailable("transport error") dans /var/logs/rustfs/rustfs.log	Un pair ne répond pas pendant la recherche des métadonnées de format (visible avec RUST_LOG=warn ou info, répété toutes les 16 secondes environ)	Vérifiez que tous les nœuds exécutent rustfs, la résolution DNS et la connectivité (port 9000)
endpoints include remote nodes but RPC authentication secret is not configured	Aucun RUSTFS_RPC_SECRET et identifiants par défaut	Ajoutez le même RUSTFS_RPC_SECRET dans /etc/default/rustfs sur chaque nœud
UnsupportedSnsdExpansion dans les logs	Un nœud conserve les données d'un ancien déploiement single-node	Supprimez tout le répertoire, dossier caché .rustfs.sys compris : sudo rm -rf /data/rustfs0
Console web renvoie 403	Accès à la racine du port 9001 avec curl	Normal : ouvrez /rustfs/console/index.html dans un navigateur
WARNING: Host local has more than 0 drives of set	Plus d'un drive du même erasure set sur le même nœud	Acceptable en lab. En production, répartissez les drives sur des nœuds différents
Service systemd échoue au démarrage	Données résiduelles d'un déploiement précédent incompatible	sudo rm -rf /data/rustfs0 && sudo mkdir -p /data/rustfs0, puis redémarrez

Glissez pour voir

Nettoyage des données

Quand vous passez du mode single-node au mode distribué (ou inversement), vous devez supprimer complètement le contenu du répertoire de données, y compris le dossier caché .rustfs.sys. Un simple rm -rf /data/rustfs0/* ne suffit pas, utilisez rm -rf /data/rustfs0 puis recréez-le.

À retenir

• RustFS est un stockage objet S3 haute performance écrit en Rust, sous licence Apache 2.0
• L'architecture peer-to-peer sans master simplifie le déploiement : tous les nœuds sont identiques et interchangeables
• L'erasure coding (Reed-Solomon) protège les données plus efficacement que la réplication, avec 4 drives, 2 peuvent tomber sans perte
• Le mode distribué (MNMD) nécessite au minimum 4 nœuds ; les nœuds se rejoignent à la convergence initiale (un nœud démarré seul attend les autres), avec un RUSTFS_RPC_SECRET identique partout
• La syntaxe d'expansion {1...4} (trois points) est spécifique à RustFS pour décrire les endpoints du cluster
• L'OIDC se configure par variables d'environnement, pas par mc admin config set
• Le projet est stable depuis le 16 septembre 2026 (1.0.0) mais récent : évaluez-le sur vos charges avant d'y placer des données critiques
• En production, utilisez XFS en JBOD, un load balancer devant les nœuds et des identifiants forts

Prochaines étapes

MinIO : stockage objet S3 Serveur S3 haute performance éprouvé en production, architecture similaire

Garage : stockage S3 léger Alternative Rust ultra-légère pour le stockage objet géo-distribué

SeaweedFS : stockage distribué Stockage objet + fichier avec accès O(1) et master HA

Ceph : stockage unifié Stockage distribué bloc, objet et fichiers avec CRUSH

Comparatif des alternatives S3 RustFS face aux moteurs S3 en production : maturité, auth OIDC et préfixe

Ressources

• Site officiel : rustfs.com
• Code source : github.com/rustfs/rustfs
• Documentation : docs.rustfs.com
• Téléchargement : dl.rustfs.com

×

📖 Voir la documentation →