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.

Recherche et restauration d'objets potentiellement perdus

Contributeurs

Il est possible de trouver et de restaurer des objets qui ont déclenché une alarme objets perdus (PERDUS) et une alerte objet perdu et que vous avez identifié comme potentiellement perdus.

Avant de commencer
Description de la tâche

Vous pouvez suivre cette procédure pour rechercher les copies répliquées de l'objet perdu ailleurs dans la grille. Dans la plupart des cas, l'objet perdu est introuvable. Toutefois, dans certains cas, vous pouvez trouver et restaurer un objet répliqué perdu si vous prenez une action rapide.

Important Pour obtenir de l'aide sur cette procédure, contactez le support technique.
Étapes
  1. À partir d'un nœud d'administration, recherchez dans les journaux d'audit les emplacements d'objets possibles :

    1. Connectez-vous au nœud grid :

      1. Saisissez la commande suivante : ssh admin@grid_node_IP

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

      3. Entrez la commande suivante pour passer à la racine : su -

      4. Entrez le mot de passe indiqué dans le Passwords.txt fichier. Lorsque vous êtes connecté en tant que root, l'invite passe de $ à #.

    2. Accédez au répertoire dans lequel se trouvent les journaux d'audit : cd /var/local/audit/export/

    3. Utilisez grep pour extraire le "messages d'audit associés à l'objet potentiellement perdu" et envoyez-les à un fichier de sortie. Entrez : grep uuid-valueaudit_file_name > output_file_name

      Par exemple :

      Admin: # grep 926026C4-00A4-449B-AC72-BCCA72DD1311 audit.log > messages_about_lost_object.txt
    4. Utilisez grep pour extraire les messages d'audit emplacement perdu (LLST) de ce fichier de sortie. Entrez : grep LLST output_file_name

      Par exemple :

      Admin: # grep LLST messages_about_lost_objects.txt

      Un message d'audit LLST ressemble à cet exemple de message.

      [AUDT:\[NOID\(UI32\):12448208\][CBIL(UI64):0x38186FE53E3C49A5]
      [UUID(CSTR):"926026C4-00A4-449B-AC72-BCCA72DD1311"][LTYP(FC32):CLDI]
      [PCLD\(CSTR\):"/var/local/rangedb/1/p/17/11/00rH0%DkRs&LgA%\#3tN6"\]
      [TSRC(FC32):SYST][RSLT(FC32):NONE][AVER(UI32):10][ATIM(UI64):
      1581535134379225][ATYP(FC32):LLST][ANID(UI32):12448208][AMID(FC32):CLSM]
      [ATID(UI64):7086871083190743409]]
    5. Recherchez le champ PCLD et LE champ NOID dans le message LLST.

      Le cas échéant, la valeur de PCLD correspond au chemin complet du disque vers la copie de l'objet répliqué manquante. La valeur de NOID est l'ID de nœud du LDR dans lequel une copie de l'objet peut être trouvée.

    Si vous trouvez un emplacement d'objet, vous pourrez peut-être restaurer l'objet.

    1. Recherchez le nœud de stockage associé à cet ID de nœud LDR. Dans le Gestionnaire de grille, sélectionnez SUPPORT > Outils > topologie de grille. Sélectionnez ensuite Data Center > Storage Node > LDR.

      L'ID de nœud du service LDR se trouve dans le tableau informations sur le nœud. Vérifiez les informations pour chaque nœud de stockage jusqu'à ce que vous trouviez celui qui héberge ce LDR.

  2. Déterminez si l'objet existe sur le nœud de stockage indiqué dans le message d'audit :

    1. Connectez-vous au nœud grid :

      1. Saisissez la commande suivante : ssh admin@grid_node_IP

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

      3. Entrez la commande suivante pour passer à la racine : su -

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

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

    2. Déterminez si le chemin du fichier de l'objet existe.

      Pour le chemin du fichier de l'objet, utilisez la valeur PCLD du message d'audit LLST.

      Par exemple, entrez :

      ls '/var/local/rangedb/1/p/17/11/00rH0%DkRs&LgA%#3tN6'
      Remarque Placez toujours le chemin d'accès au fichier d'objet entre guillemets simples dans des commandes pour échapper à tout caractère spécial.
      • Si le chemin d'accès à l'objet est introuvable, l'objet est perdu et ne peut pas être restauré à l'aide de cette procédure. Contactez l'assistance technique.

      • Si le chemin d'accès à l'objet est trouvé, passez à l'étape suivante. Vous pouvez essayer de restaurer à nouveau l'objet trouvé dans StorageGRID.

  3. Si le chemin d'accès à l'objet a été trouvé, essayez de restaurer l'objet sur StorageGRID :

    1. À partir du même nœud de stockage, modifiez la propriété du fichier objet afin qu'il puisse être géré par StorageGRID. Entrez : chown ldr-user:bycast 'file_path_of_object'

    2. Telnet vers localhost 1402 pour accéder à la console LDR. Entrez : telnet 0 1402

    3. Entrez : cd /proc/STOR

    4. Entrez : Object_Found 'file_path_of_object'

      Par exemple, entrez :

      Object_Found '/var/local/rangedb/1/p/17/11/00rH0%DkRs&LgA%#3tN6'

      Émission du Object\_Found commande informe la grille de l'emplacement de l'objet. Il déclenche également la règle ILM active, qui crée des copies supplémentaires, comme spécifié dans la règle.

      Remarque Si le nœud de stockage sur lequel vous avez trouvé l'objet est hors ligne, vous pouvez le copier sur n'importe quel nœud de stockage en ligne. Placez l'objet dans un répertoire /var/local/rangedb du noeud de stockage en ligne. Ensuite, émettez le Object\_Found commande utilisant ce chemin de fichier pour l'objet.
      • Si l'objet ne peut pas être restauré, le Object\_Found échec de la commande. Contactez l'assistance technique.

      • Si l'objet a été restauré avec succès dans StorageGRID, un message de réussite s'affiche. Par exemple :

        ade 12448208: /proc/STOR > Object_Found '/var/local/rangedb/1/p/17/11/00rH0%DkRs&LgA%#3tN6'
        
        ade 12448208: /proc/STOR > Object found succeeded.
        First packet of file was valid. Extracted key: 38186FE53E3C49A5
        Renamed '/var/local/rangedb/1/p/17/11/00rH0%DkRs&LgA%#3tN6' to '/var/local/rangedb/1/p/17/11/00rH0%DkRt78Ila#3udu'

        Passez à l'étape suivante.

  4. Si l'objet a été restauré dans StorageGRID, vérifiez que de nouveaux emplacements ont été créés.

    1. Entrez : cd /proc/OBRP

    2. Entrez : ObjectByUUID UUID_value

      L'exemple suivant montre qu'il existe deux emplacements pour l'objet avec l'UUID 926026C4-00A4-449B-AC72-BCCA72DD1311.

    ade 12448208: /proc/OBRP > ObjectByUUID 926026C4-00A4-449B-AC72-BCCA72DD1311
    
    {
        "TYPE(Object Type)": "Data object",
        "CHND(Content handle)": "926026C4-00A4-449B-AC72-BCCA72DD1311",
        "NAME": "cats",
        "CBID": "0x38186FE53E3C49A5",
        "PHND(Parent handle, UUID)": "221CABD0-4D9D-11EA-89C3-ACBB00BB82DD",
        "PPTH(Parent path)": "source",
        "META": {
            "BASE(Protocol metadata)": {
                "PAWS(S3 protocol version)": "2",
                "ACCT(S3 account ID)": "44084621669730638018",
                "*ctp(HTTP content MIME type)": "binary/octet-stream"
            },
            "BYCB(System metadata)": {
                "CSIZ(Plaintext object size)": "5242880",
                "SHSH(Supplementary Plaintext hash)": "MD5D 0xBAC2A2617C1DFF7E959A76731E6EAF5E",
                "BSIZ(Content block size)": "5252084",
                "CVER(Content block version)": "196612",
                "CTME(Object store begin timestamp)": "2020-02-12T19:16:10.983000",
                "MTME(Object store modified timestamp)": "2020-02-12T19:16:10.983000",
                "ITME": "1581534970983000"
            },
            "CMSM": {
                "LATM(Object last access time)": "2020-02-12T19:16:10.983000"
            },
            "AWS3": {
                "LOCC": "us-east-1"
            }
        },
        "CLCO\(Locations\)": \[
            \{
                "Location Type": "CLDI\(Location online\)",
                "NOID\(Node ID\)": "12448208",
                "VOLI\(Volume ID\)": "3222345473",
                "Object File Path": "/var/local/rangedb/1/p/17/11/00rH0%DkRt78Ila\#3udu",
                "LTIM\(Location timestamp\)": "2020-02-12T19:36:17.880569"
            \},
            \{
                "Location Type": "CLDI\(Location online\)",
                "NOID\(Node ID\)": "12288733",
                "VOLI\(Volume ID\)": "3222345984",
                "Object File Path": "/var/local/rangedb/0/p/19/11/00rH0%DkRt78Rrb\#3s;L",
                "LTIM\(Location timestamp\)": "2020-02-12T19:36:17.934425"
            }
        ]
    }
    1. Se déconnecter de la console LDR. Entrez : exit

  5. À partir d'un nœud d'administration, recherchez dans les journaux d'audit le message d'audit ORLM correspondant à cet objet pour vous assurer que la gestion du cycle de vie des informations (ILM) a placé des copies, si nécessaire.

    1. Connectez-vous au nœud grid :

      1. Saisissez la commande suivante : ssh admin@grid_node_IP

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

      3. Entrez la commande suivante pour passer à la racine : su -

      4. Entrez le mot de passe indiqué dans le Passwords.txt fichier. Lorsque vous êtes connecté en tant que root, l'invite passe de $ à #.

    2. Accédez au répertoire dans lequel se trouvent les journaux d'audit : cd /var/local/audit/export/

    3. Utilisez grep pour extraire les messages d'audit associés à l'objet dans un fichier de sortie. Entrez : grep uuid-valueaudit_file_name > output_file_name

      Par exemple :

      Admin: # grep 926026C4-00A4-449B-AC72-BCCA72DD1311 audit.log > messages_about_restored_object.txt
    4. Utilisez grep pour extraire les messages d'audit règles objet met (ORLM) de ce fichier de sortie. Entrez : grep ORLM output_file_name

      Par exemple :

      Admin: # grep ORLM messages_about_restored_object.txt

      Un message d'audit ORLM ressemble à cet exemple de message.

    [AUDT:[CBID(UI64):0x38186FE53E3C49A5][RULE(CSTR):"Make 2 Copies"]
    [STAT(FC32):DONE][CSIZ(UI64):0][UUID(CSTR):"926026C4-00A4-449B-AC72-BCCA72DD1311"]
    [LOCS(CSTR):"**CLDI 12828634 2148730112**, CLDI 12745543 2147552014"]
    [RSLT(FC32):SUCS][AVER(UI32):10][ATYP(FC32):ORLM][ATIM(UI64):1563398230669]
    [ATID(UI64):15494889725796157557][ANID(UI32):13100453][AMID(FC32):BCMS]]
    1. Recherchez le champ EMPLACEMENTS dans le message d'audit.

      Le cas échéant, la valeur de CLDI dans LES EMPLACEMENTS est l'ID de nœud et l'ID de volume sur lequel une copie d'objet a été créée. Ce message indique que la ILM a été appliquée et que deux copies d'objet ont été créées à deux emplacements dans la grille.

  6. "Réinitialise le nombre d'objets perdus et manquants" Dans le Gestionnaire de grille.