VNX/Unity : Compréhension des secteurs non corrigeables et des erreurs de parité (utilisateur corrigeables)

Compréhension des secteurs non corrigeables et des erreurs de parité sur une baie CLARiiON, VNX ou Unity.

Les messages du journal d’événements, tels que les suivants, peuvent également s’afficher sous la forme Dial Home :

VNX1
code d’erreur : code d’erreur de secteur de parité 0x953 non réparable
: code d’erreur du secteur de données 0x957 non réparable
: code d’erreur de secteur de parité 0x68A non réparable
: code d’erreur du secteur de données 0x695 non réparable
: le cache B26 invalidée du secteur de données 0x840
a émis CORRUPT_CRC. Lun = 309 ca_sync. c 0 309 2


Groupe RAID de secteur VNX2 71688003 non réparable : Position %2 : ADRESSE LBA %3 : %4 blocs : %5 info erreur : %6 infos supplémentaires : %7
71688008 groupe RAID de secteur non réparable : 10 positions : 1 LBA : blocs D180 : 8 infos sur l’erreur : 0 infos supplémentaires : e [r5_rb grippe 8224 r5_rb]
71688008 groupe RAID de secteur non corrigeable : 10 positions : 1 LBA : blocs D170 : 8 infos sur l’erreur : 0 infos supplémentaires : e [r5_rb grippe 8224 r5_rb]
71688001 groupe RAID invalided : 10 positions : 1 LBA : blocs D121 : 7 infos sur l’erreur : 0 infos supplémentaires : e [r5_rb grippe 8224 r5_rb]

Des erreurs non corrigeables se produisent lorsque deux disques différents d’un même groupe RAID, appartenant au même secteur, ont des erreurs de support. 
Par exemple, lorsqu’un disque contenant des erreurs de support est en cours de copie vers un secours, et qu’un autre disque dans le même groupe RAID, dans le même secteur, comporte également des erreurs de média, cela peut entraîner une erreur ou un secteur non réparable. 

Les codes d’événement décrits ci-dessus sont consignés lorsque le système ne parvient pas à lire les secteurs de données à partir d’un disque, et les tentatives ultérieures de reconstruction des données à partir d’un autre disque dans le groupe RAID échouaient. Les messages « non corrigeables » indiquent le ou les disques qui n’ont pas pu lire correctement les secteurs à partir de et les messages « invalidés » indiquent quels disques ont été marqués comme étant non valides d’informations valides dans un emplacement spécifique. Cette opération est effectuée afin de s’assurer qu’aucune donnée non valide n’est renvoyée à un système hôte. Les tentatives de lecture à partir d’un emplacement invalidé entraîneront une erreur matérielle renvoyée à un hôte.
Les tentatives d’écriture dans un emplacement non validé s’achèvent avec succès et, en règle générale, « remplir » (écraser) l’emplacement non valide, ce qui permet de corriger efficacement l’erreur. C’est la raison pour laquelle les erreurs non corrigeables ne disparaissent pas après qu’un hôte a remplacé ces secteurs par de nouvelles données correctes.

Pour VNX :
Une fois que tous les problèmes matériels ont été résolus, Dell EMC le support technique doit exécuter une vérification de l’arrière-plan manuelle en lecture seule (ROBV) si le ou les LUN internes concernés dans le pool affecté. ROBV lit et vérifie les données de uncorrectables sur l’ensemble du LUN (interne), y compris l’espace non utilisé afin de déterminer le nombre de secteurs uncorrectables qui peuvent encore exister.
Une fois que ROBV est terminé, si les uncorrectables sont toujours présents, votre ingénieur de support technique Dell EMC devez exécuter des étapes supplémentaires, notamment la collecte et l’analyse des informations de tableau d’allocation de stockage (Sam) afin d’identifier le ou les LUN d’utilisateurs spécifiques concernés (les LUN internes où le uncorrectables a été trouvé sont mappées aux LUN utilisateur).
Pour obtenir une description détaillée et les conditions préalables nécessaires à l’exécution d’un ROBV, consultez l’article 466638, VNX : Explication de la vérification en arrière-plan en lecture seule (ROBV) (utilisateur corrigeable)

Lorsqu’un secteur non réparable se trouve dans un LUN utilisateur, les données utilisateur doivent être vérifiées par l’application hôte afin de déterminer si les données utilisateur sont corrompues ou si l’erreur se trouve dans l’espace inutilisé. Tout processus qui lira les données, comme une sauvegarde, serait en mesure d’identifier/signaler la corruption possible.
En cas de corruption, les données peuvent être restaurées à partir d’une bonne sauvegarde, avec une restauration complète ou une restauration partielle du ou des fichiers concernés.
S’il n’existe pas de bonne sauvegarde, vous devez utiliser une autre méthode de l’application hôte pour restaurer ou recréer les données. 

Si l’erreur non corrigible ne se trouve pas dans les données utilisateur, les processus en arrière-plan peuvent toujours détecter l’erreur à l’avenir, si les e/s de l’hôte ne remplacent pas le secteur. Cela peut mener à une évaluation incorrecte qu’il s’agit d’une nouvelle erreur et provoque des retards lors de l’analyse et de la correction d’une ancienne erreur qui n’a pas été entièrement résolue.
Dans ce cas, il est fortement recommandé de déplacer les données correctes vers un autre LUN et de supprimer le LUN affecté d’origine.

Pour Unity, d’autres méthodes peuvent exister pour tenter de résoudre ce problème. Veuillez consulter les articles supplémentaires spécifiques à Unity.

Questions fréquemment posées :

L' ingénierie a-t-elle une autre méthode pour récupérer les données du client si une application hôte du client n’écrase pas les données et si une restauration à partir d’une sauvegarde ne fonctionne pas ? 
Il n’existe aucun autre moyen de restaurer les données autres qu’une opération de restauration ou de recréer les données à partir de l’application.
Étant donné que les données non corrigeables ne sont pas réellement manquantes, il n’y a aucun moyen de savoir quelles données doivent être réécrites pour pouvoir les réécrire.  C’est pourquoi le secteur est « invalidé » et une erreur matérielle est renvoyée à l’hôte. Il est préférable de renvoyer une erreur matérielle à des données incorrectes. 

Existe-t-il un secteur non validé pour modifier les emplacements sur un disque ? 
Dans le cas d’une LUN standard, le secteur de données non valide reste toujours le même.
Dans le cas d’un pool LUN avec la hiérarchisation automatisée activée, il peut se déplacer si la tranche est déplacée.

Existe-t-il un moyen de trouver l’emplacement réel d’un secteur non validé ?  
Il est très difficile de localiser la position d’un secteur non validé, en fonction de la façon dont les LUN sont mappées au sein des pools ou groupes RAID, ainsi que des informations disponibles dans les journaux d’événements.
Contactez le support Dell EMC afin d’obtenir de l’aide pour identifier les blocs contenant le secteur non validé.  L’équipe de support devra tout d’abord passer par le processus de restauration non réparable, puis faire remonter le problème à l’équipe de restauration. . 

Si les secteurs invalidés n’apparaissent pas à l’impact sur la zone de données du client, existe-t-il un moyen de l’éliminer sans lier la LUN ?
Une certaine réussite a été signalée lors de l’écriture de données temporaires pour remplir la LUN, puis de la suppression des données temporaires.  Si la zone invalidée est écrite dans avec des données temporaires, le ou les emplacements invalidés sont renseignés, ce qui restaure le secteur non valide avec des données valides. 

Un client peut-il exécuter uniquement un CHKDSK ou un FSCK pour vérifier l’intégrité des données dans le système de fichiers si des erreurs non corrigeables sont signalées par la vérification en arrière-plan en lecture seule ? 
En cas de problème de secteurs non corrigeables, les données du client doivent être vérifiées pour déterminer s’il existe une corruption des fichiers. Pour ce faire, exécutez un certain type d’application ou de programme qui lit tous les secteurs utilisés dans l’espace LUN. Le type de méthode le plus courant est une sauvegarde complète des données. Il n’est pas recommandé d’exécuter la commande FSCK (UNIX) ou CHKDSK (Windows), car ces utilitaires vérifient uniquement la zone de métadonnées des fichiers. Si les secteurs non corrigeables ne se trouvent pas dans l’espace de métadonnées, le client sera à l’esprit de l’impression que les données sont OK lorsqu’elles ne le sont pas.

Autres questions fréquentes :

Pourquoi la désactivation de la compression des données est-elle nécessaire ?
La compression des données est une fonction qui analyse les données sur un disque et applique des algorithmes qui réduisent la taille des séquences répétitives de bits inhérentes à certains types de fichiers. Lors de l’opération de compression pour un groupe RAID LUN, le logiciel migre et compresse les données LUN vers un LUN dynamique d’un pool. La LUN devient une LUN Thin compressée. Les opérations de compression pour les LUN de pool (Thick et Thin) s’effectuent dans le pool dans lequel se trouve la LUN compressée. Chaque fois que les données sont compressées, il existe un déplacement des données au sein du pool, qui ne permet pas d’identifier le bon MLU qui est affecté en cas de Uncorrectables ou de cohérence inattendue. La fonction doit donc être interrompue.

Pourquoi la désactivation de la hiérarchisation automatisée est-elle nécessaire ?
La fonction de hiérarchisation automatisée migre les données entre les niveaux de stockage ou différents supports de stockage (EFD, FC & SATA). L’objectif du stockage hiérarchisé est de conserver les données les plus fréquemment utilisées ou les plus importantes sur des disques rapides, hautes performances (plus coûteux), et de déplacer les données moins fréquemment utilisées et moins importantes sur des disques basse performance (moins onéreux). À l’instar de la compression des données, il existe un déplacement de données impliqué dans la hiérarchisation automatisée, qui ne nous aidera pas à identifier le secteur des MLU qui sont affectés en cas de Uncorrectables ou de cohérence inattendue, si elle n’est pas désactivée. Par conséquent, la réaffectation doit être arrêtée et la planification doit être désactivée.

Pourquoi la désactivation de Fast cache est-elle nécessaire ?
Fast cache doit uniquement être désactivé si l’erreur de secteur non réparable est signalée dans Fast cache

pourquoi est-il nécessaire d’exécuter ROBV sur l’ensemble du groupe RAID (RG) et non sur le LUN spécifique ?
Vous devez exécuter ROBV sur l’ensemble du RG pour que certaines autres LUN client du même RG ne soient pas affectées.

Pourquoi est-il nécessaire d’exécuter ROBV sur le pool, et pas seulement sur le groupe RAID ?
Vous devez exécuter ROBV sur l’ensemble d’un pool en cas d’exécution d’une planification de hiérarchisation automatisée depuis le moment où un rapport n’est pas corrigeable et la ROBV est planifiée pour commencer.  Cela est nécessaire car les tranches de données peuvent déplacer le disque non corrigeable vers un autre secteur si la tranche de données est déplacée vers un autre niveau.
 
Pourquoi est-il nécessaire de recueillir des informations sur le tableau d’allocation de stockage SAT ?
Les informations SAT qui se trouvent dans le cadre de la prise en charge des outils utilisés par Dell EMC la prise en charge du client déterminent le LUN/MLU du client qui se trouve dans le secteur non réparable.  Cela indique également si le problème se trouve dans l’espace de données ou dans l’espace de métadonnées de la LUN du client.