Skip to main content
Une version plus récente de ce produit est disponible.
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Remonter et reformater les volumes de stockage StorageGRID (étapes manuelles)

PDF

Vous devez exécuter manuellement deux scripts pour remonter les volumes de stockage préservés et reformater les volumes de stockage défaillants. Le premier script remonte les volumes correctement formatés en tant que volumes de stockage StorageGRID. Le second script reformate les volumes non montés, reconstruit Cassandra si nécessaire et démarre les services.

Avant de commencer

  • Vous avez déjà remplacé le matériel de tous les volumes de stockage défaillants dont vous savez qu'ils nécessitent un remplacement.

    L'exécution du script sn-remount-volumes pourrait vous aider à identifier d'autres volumes de stockage défaillants.

  • Vous avez vérifié qu'aucune mise hors service d'un nœud de stockage n'est en cours, ou vous avez suspendu la procédure de mise hors service du nœud. (Dans le Grid Manager, sélectionnez Maintenance > Tasks > Decommission.)

  • Vous avez vérifié qu'aucune extension n'est en cours. (Dans le Grid Manager, sélectionnez Maintenance > Tasks > Expansion.)

  • Vous avez "examiné les avertissements concernant la récupération du disque système du nœud de stockage".

    Avertissement Contactez le support technique si plusieurs nœuds de stockage sont hors ligne. N'exécutez pas le sn-recovery-postinstall.sh script.
À propos de cette tâche

Pour mener à bien cette procédure, vous effectuez les tâches de haut niveau suivantes :

  • Connectez-vous au nœud de stockage récupéré.

  • Exécutez le sn-remount-volumes script pour remonter les volumes de stockage correctement formatés. Lorsque ce script s'exécute, il effectue les opérations suivantes :

    • Monte et démonte chaque volume de stockage pour rejouer le journal XFS.

    • Effectue un contrôle de cohérence du système de fichiers XFS.

    • Si le système de fichiers est cohérent, détermine si le volume de stockage est un volume de stockage StorageGRID correctement formaté.

    • Si le volume de stockage est correctement formaté, le volume de stockage est remonté. Toutes les données existantes sur le volume restent intactes.

  • Vérifiez le résultat du script et résolvez les problèmes éventuels.

  • Exécutez le sn-recovery-postinstall.sh script. Lorsqu'il s'exécute, ce script effectue les opérations suivantes.

    Avertissement Ne redémarrez pas un nœud de stockage pendant la récupération avant d'avoir exécuté sn-recovery-postinstall.sh pour reformater les volumes de stockage défaillants et restaurer les métadonnées des objets. Le redémarrage du nœud de stockage avant que sn-recovery-postinstall.sh ne soit terminé provoque des erreurs pour les services qui tentent de démarrer et entraîne la sortie du mode maintenance des nœuds d'appliance StorageGRID. Consultez l'étape pour script post-installation.

    • Reformate tous les volumes de stockage que le script sn-remount-volumes n'a pas pu monter ou qui ont été trouvés mal formatés.

      Remarque Si un volume de stockage est reformaté, toutes les données qu'il contient sont perdues. Vous devez effectuer une procédure supplémentaire pour restaurer les données d'objet à partir d'autres emplacements dans la grille, à condition que les règles ILM aient été configurées pour stocker plus d'une copie d'objet.

    • Reconstruit la base de données Cassandra sur le nœud, si nécessaire.

    • Démarre les services sur le nœud de stockage.

Étapes

  1. Connectez-vous au nœud de stockage récupéré :

    1. Saisissez la commande suivante : ssh admin@grid_node_IP

    2. Saisissez le mot de passe indiqué dans le fichier Passwords.txt.

    3. Saisissez la commande suivante pour passer en mode superutilisateur : su -

    4. Saisissez le mot de passe indiqué dans le fichier Passwords.txt.

    Lorsque vous êtes connecté en tant que root, l'invite passe de $ à #.

  2. Exécutez le premier script pour remonter les volumes de stockage correctement formatés.

    Remarque Si tous les volumes de stockage sont neufs et doivent être formatés, ou si tous les volumes de stockage sont défaillants, vous pouvez ignorer cette étape et exécuter le deuxième script pour reformater tous les volumes de stockage non montés.

    1. Exécutez le script : sn-remount-volumes

      L'exécution de ce script peut prendre plusieurs heures sur des volumes de stockage contenant des données.

    2. Au fur et à mesure de l'exécution du script, examinez la sortie et répondez à toutes les invites.

      Remarque Si nécessaire, vous pouvez utiliser la commande tail -f pour surveiller le contenu du fichier journal du script (/var/local/log/sn-remount-volumes.log. Le fichier journal contient des informations plus détaillées que la sortie de la ligne de commandes. 
      root@SG:~ # sn-remount-volumes
The configured LDR noid is 12632740

====== Device /dev/sdb ======
Mount and unmount device /dev/sdb and checking file system consistency:
The device is consistent.
Check rangedb structure on device /dev/sdb:
Mount device /dev/sdb to /tmp/sdb-654321 with rangedb mount options
This device has all rangedb directories.
Found LDR node id 12632740, volume number 0 in the volID file
Attempting to remount /dev/sdb
Device /dev/sdb remounted successfully

====== Device /dev/sdc ======
Mount and unmount device /dev/sdc and checking file system consistency:
Error: File system consistency check retry failed on device /dev/sdc.
You can see the diagnosis information in the /var/local/log/sn-remount-volumes.log.

This volume could be new or damaged. If you run sn-recovery-postinstall.sh,
this volume and any data on this volume will be deleted. If you only had two
copies of object data, you will temporarily have only a single copy.
StorageGRID will attempt to restore data redundancy by making
additional replicated copies or EC fragments, according to the rules in
the active ILM policies.

Don't continue to the next step if you believe that the data remaining on
this volume can't be rebuilt from elsewhere in the grid (for example, if
your ILM policy uses a rule that makes only one copy or if volumes have
failed on multiple nodes). Instead, contact support to determine how to
recover your data.

====== Device /dev/sdd ======
Mount and unmount device /dev/sdd and checking file system consistency:
Failed to mount device /dev/sdd
This device could be an uninitialized disk or has corrupted superblock.
File system check might take a long time. Do you want to continue? (y or n) [y/N]? y

Error: File system consistency check retry failed on device /dev/sdd.
You can see the diagnosis information in the /var/local/log/sn-remount-volumes.log.

This volume could be new or damaged. If you run sn-recovery-postinstall.sh,
this volume and any data on this volume will be deleted. If you only had two
copies of object data, you will temporarily have only a single copy.
StorageGRID will attempt to restore data redundancy by making
additional replicated copies or EC fragments, according to the rules in
the active ILM policies.

Don't continue to the next step if you believe that the data remaining on
this volume can't be rebuilt from elsewhere in the grid (for example, if
your ILM policy uses a rule that makes only one copy or if volumes have
failed on multiple nodes). Instead, contact support to determine how to
recover your data.

====== Device /dev/sde ======
Mount and unmount device /dev/sde and checking file system consistency:
The device is consistent.
Check rangedb structure on device /dev/sde:
Mount device /dev/sde to /tmp/sde-654321 with rangedb mount options
This device has all rangedb directories.
Found LDR node id 12000078, volume number 9 in the volID file
Error: This volume does not belong to this node. Fix the attached volume and re-run this script.

      Dans l'exemple de sortie, un volume de stockage a été remonté avec succès et trois volumes de stockage ont rencontré des erreurs.

      • /dev/sdb a passé le contrôle de cohérence du système de fichiers XFS et présentait une structure de volume valide, il a donc été remonté avec succès. Les données des périphériques remontés par le script sont préservées.

      • `/dev/sdc`Le contrôle de cohérence du système de fichiers XFS a échoué car le volume de stockage était nouveau ou corrompu.

      • /dev/sdd n'a pas pu être monté car le disque n'était pas initialisé ou le superbloc du disque était corrompu. Lorsqu'un script ne parvient pas à monter un volume de stockage, il vous demande si vous souhaitez exécuter une vérification de cohérence du système de fichiers.

        • Si le volume de stockage est connecté à un nouveau disque, répondez N à l'invite. Vous n'avez pas besoin de vérifier le système de fichiers sur un nouveau disque.

        • Si le volume de stockage est connecté à un disque existant, répondez Y à l'invite. Vous pouvez utiliser les résultats de la vérification du système de fichiers pour déterminer la source de la corruption. Les résultats sont enregistrés dans le /var/local/log/sn-remount-volumes.log fichier journal.

      • /dev/sde a réussi le contrôle de cohérence du système de fichiers XFS et possédait une structure de volume valide ; cependant, l’ID du nœud LDR dans le fichier volID ne correspondait pas à l’ID de ce nœud de stockage (le configured LDR noid affiché en haut). Ce message indique que ce volume appartient à un autre nœud de stockage.

  3. Vérifiez le résultat du script et résolvez les problèmes éventuels.

    Avertissement Si un volume de stockage n'a pas passé le contrôle de cohérence du système de fichiers XFS ou n'a pas pu être monté, examinez attentivement les messages d'erreur affichés dans la sortie. Vous devez comprendre les implications de l'exécution du sn-recovery-postinstall.sh script sur ces volumes.

    1. Vérifiez que les résultats incluent bien une entrée pour tous les volumes attendus. Si un volume n'est pas répertorié, relancez le script.

    2. Vérifiez les messages de tous les périphériques montés. Assurez-vous qu'aucune erreur n'indique qu'un volume de stockage n'appartient pas à ce Storage Node.

      Dans cet exemple, le résultat pour /dev/sde inclut le message d'erreur suivant :

      Error: This volume does not belong to this node. Fix the attached volume and re-run this script.
      Avertissement Si un volume de stockage est signalé comme appartenant à un autre nœud de stockage, veuillez contacter le support technique. Si vous exécutez le script sn-recovery-postinstall.sh, le volume de stockage sera reformaté, ce qui peut entraîner une perte de données.

    3. Si des périphériques de stockage n'ont pas pu être montés, notez le nom du périphérique et réparez-le ou remplacez-le.

      Remarque Vous devez réparer ou remplacer tout périphérique de stockage qui n'a pas pu être monté.

      Vous utiliserez le nom du périphérique pour rechercher l'ID du volume, qui est une entrée requise lorsque vous exécuterez le script repair-data pour restaurer les données de l'objet sur le volume (la procédure suivante).

    4. Après avoir réparé ou remplacé tous les périphériques non montables, exécutez le script sn-remount-volumes à nouveau pour confirmer que tous les volumes de stockage pouvant être remontés l'ont été.

      Avertissement Si un volume de stockage ne peut pas être monté ou est mal formaté, et que vous passez à l'étape suivante, le volume et toutes les données qu'il contient seront supprimés. Si vous aviez deux copies des données d'objet, vous n'en aurez plus qu'une seule jusqu'à ce que vous ayez terminé la procédure suivante (restauration des données d'objet).
    Avertissement N’exécutez pas le sn-recovery-postinstall.sh script si vous pensez que les données restantes sur un volume de stockage défaillant ne peuvent pas être reconstruites à partir d’autres éléments de la grille (par exemple, si votre stratégie ILM utilise une règle qui ne crée qu’une seule copie ou si des volumes sont défaillants sur plusieurs nœuds). Contactez plutôt le support technique pour déterminer comment récupérer vos données.

  4. Exécutez le sn-recovery-postinstall.sh`script : `sn-recovery-postinstall.sh

    Ce script reformate tous les volumes de stockage qui n'ont pas pu être montés ou qui se sont avérés mal formatés ; reconstruit la base de données Cassandra sur le nœud, si nécessaire ; et démarre les services sur le nœud de stockage.

    Veuillez prendre connaissance des points suivants :

    • L'exécution du script peut prendre plusieurs heures.

    • En règle générale, vous devez laisser la session SSH intacte pendant l'exécution du script.

    • N’appuyez pas sur Ctrl+C pendant que la session SSH est active.

    • Le script s'exécutera en arrière-plan en cas de perturbation du réseau et mettra fin à la session SSH, mais vous pouvez suivre la progression depuis la page de récupération.

    • Si le nœud de stockage utilise le service RSM, le script peut sembler bloqué pendant 5 minutes, le temps que les services du nœud redémarrent. Ce délai de 5 minutes est attendu chaque fois que le service RSM démarre pour la première fois.

      Remarque Le service RSM est présent sur les nœuds de stockage qui incluent le service ADC.
    Remarque Certaines procédures de récupération StorageGRID utilisent Reaper pour effectuer les réparations Cassandra. Les réparations se produisent automatiquement dès que les services associés ou requis ont démarré. Vous pourriez remarquer dans la sortie du script des mentions telles que « reaper » ou « réparation Cassandra ». Si un message d’erreur indique que la réparation a échoué, exécutez la commande indiquée dans le message d’erreur.

  5. Au fur et à mesure que le script sn-recovery-postinstall.sh s’exécute, surveillez la page Recovery dans le Grid Manager.

    La barre de progression et la colonne Étape de la page Récupération fournissent un aperçu général de l'état du sn-recovery-postinstall.sh script.

    Capture d'écran montrant la progression de la récupération dans l'interface de gestion du grid

  6. Après que le sn-recovery-postinstall.sh script a démarré les services sur le nœud, vous pouvez restaurer les données d'objet sur tous les volumes de stockage qui ont été formatés par le script.

    Le script vous demande si vous souhaitez utiliser le processus de restauration de volume de Grid Manager.

    • Dans la plupart des cas, vous devriez "restaurer les données d'objet à l'aide de Grid Manager". Répondez y pour utiliser le Gestionnaire de grille.

    • Dans de rares cas, par exemple sur instruction du support technique ou lorsque vous savez que le nœud de remplacement dispose de moins de volumes disponibles pour le stockage d'objets que le nœud d'origine, vous devez "restaurez manuellement les données de l'objet" en utilisant le script repair-data. Si l'un de ces cas s'applique, répondez n.

      Remarque

      Si vous répondez n à l'utilisation du processus de restauration de volume de Grid Manager (restaurez les données d'objet manuellement) :

      • Vous ne pouvez pas restaurer les données d'objet à l'aide de Grid Manager.

      • Vous pouvez suivre l'avancement des tâches de restauration manuelle à l'aide de Grid Manager.

      Une fois votre sélection effectuée, le script se termine et les étapes suivantes pour récupérer les données de l'objet s'affichent. Après avoir pris connaissance de ces étapes, appuyez sur n'importe quelle touche pour revenir à la ligne de commandes.