Stockage hiérarchisé

Le stockage hiérarchisé de RustFS déplace les objets du stockage local vers un backend distant configuré. Cette page explique les cibles prises en charge et montre comment ajouter et maintenir un niveau RustFS dans la Console.

La hiérarchisation est asynchrone. RustFS conserve localement les métadonnées de l’objet, transfère les données de l’objet vers le niveau distant et continue de servir les lectures S3 via le compartiment (bucket) d’origine et la clé d’objet.

Backends pris en chargeCopy Anchor Link

Le code source de RustFS définit des implémentations de backend warm pour ces types de cibles :

Les charges utiles et les exigences d’identifiants varient selon le fournisseur. Le flux complet ci-dessous utilise le backend RustFS, car le code source de RustFS contient un test de bout en bout, du cluster chaud vers le cluster froid, pour ce chemin.

Avant de commencerCopy Anchor Link

Préparez les éléments suivants :

• Un déploiement RustFS source qui conserve les données chaudes.
• Un déploiement RustFS cible distinct et un compartiment cible existant. Cet exemple utilise my-bucket sur la cible.
• Des identifiants cibles autorisés à charger, lire, lister et supprimer des objets dans ce compartiment.
• L’accès à la Console RustFS du déploiement source.

Utilisez TLS pour les deux déploiements en production. Limitez les identifiants cibles au compartiment de niveau dédié et à son préfixe.

Gérer les niveaux avec rcCopy Anchor Link

Installez et configurez rc, puis listez les niveaux enregistrés sur le déploiement source :

rc bucket lifecycle tier list local

Ajoutez un niveau RustFS avec les mêmes réglages que dans le flux de la Console :

rc bucket lifecycle tier add rustfs COLDTIER local \
  --endpoint <target-rustfs-endpoint> \
  --access-key <your-access-key> \
  --secret-key <your-secret-key> \
  --bucket my-bucket \
  --region us-east-1

Inspectez la configuration du niveau et les statistiques disponibles :

rc bucket lifecycle tier info COLDTIER local

Les commandes de niveau restantes mettent à jour les identifiants ou suppriment un niveau :

rc bucket lifecycle tier edit COLDTIER local \
  --access-key <your-access-key> \
  --secret-key <your-secret-key>
rc bucket lifecycle tier remove COLDTIER local

Consultez Gestion du cycle de vie pour créer des règles de transition, confirmer les transitions et restaurer des copies locales. Exécutez rc bucket lifecycle tier <command> --help pour examiner les options propres au fournisseur avant de modifier un niveau.

Surveiller l’activité des niveauxCopy Anchor Link

Utilisez le point de terminaison de statistiques de niveau avec une requête signée en SigV4 et l’autorisation admin:ListTier :

GET /rustfs/admin/v3/tier-stats?tier=COLDTIER HTTP/1.1
Host: <hot-rustfs-endpoint>

Surveillez les échecs de transition en même temps que la capacité du cluster source et la disponibilité côté cible. Un niveau configuré ajoute le service cible et le chemin réseau au chemin de lecture des objets qui ne disposent pas d’une copie locale restaurée.

Modifier ou supprimer un niveauCopy Anchor Link

L’API d’administration expose ces routes de mutation, qui exigent toutes admin:SetTier :

Avant de modifier ou de supprimer un niveau :

1. Désactivez les règles de cycle de vie qui référencent le niveau.
2. Confirmez qu’aucune tâche de transition ne l’utilise encore.
3. Confirmez qu’aucun objet source ne dépend des données stockées dans son compartiment ou son préfixe cible.
4. Sauvegardez la configuration du niveau et notez l’emplacement cible.

Les mutations de niveau ordinaires vérifient l’utilisation du backend et protègent les cibles non vides. N’utilisez pas d’option force pour contourner ces contrôles, sauf si vous avez démontré de façon indépendante que chaque objet transféré reste récupérable. La suppression de la configuration d’un niveau actif peut rendre les objets transférés illisibles depuis le cluster source.

Référence de l’API d’administrationCopy Anchor Link

Le code source actuel de RustFS enregistre ces routes de niveau :

Toutes les requêtes de l’API d’administration exigent une authentification SigV4. Ces routes forment une interface d’administration, et non des opérations S3 ordinaires sur les compartiments.

Étapes suivantesCopy Anchor Link

Consultez la gestion du cycle de vie et configurez les politiques d’accès pour les administrateurs et les identifiants de service utilisés par le stockage hiérarchisé.