Si un système RAID5 rencontre un URE pendant la reconstruction, toutes les données sont-elles perdues?

23

Je comprends l'argument concernant la probabilité accrue de disques plus gros de rencontrer un URE pendant une reconstruction, mais je ne suis pas sûr de ce que les implications réelles sont pour cela. Cette réponse indique que la reconstruction entière échoue, mais cela signifie-t-il que toutes les données sont inaccessibles? Pourquoi serait-ce? Un URE unique provenant d'un seul secteur sur le disque n'aurait sûrement qu'un impact sur les données liées à quelques fichiers, tout au plus. Le tableau ne serait-il pas encore reconstruit, juste avec une corruption mineure de quelques fichiers?

(Je suis spécifiquement intéressé par la mise en œuvre de ZFS de RAID5 ici, mais la logique semble la même pour toute mise en œuvre de RAID5.)

raid zfs zfsonlinux

— process91
source

1

En général, lorsque la "probabilité de rencontrer un URE pendant une reconstruction " est discutée dans le contexte des risques RAID5, l'hypothèse implicite est qu'une corruption antérieure s'est déjà produite pour rendre la reconstruction nécessaire. En d'autres termes, le "URE pendant la reconstruction" est le deuxième URE, et en effet TOUTES les données seront perdues.

— Colt

1

@Colt - Je comprends que c'est l'implication, mais ce que je ne comprends pas, c'est pourquoi un seul URE (qui, dans l'analyse des raisons pour lesquelles RAID5 n'est pas recommandé, semble se référer à un mauvais secteur) signifierait que toutes les données seraient être perdu. En général, si j'ai perdu 1 lecteur d'une matrice RAID5, j'ai encore toutes les données. Si je perds en outre un seul secteur de l'un des disques restants, il est possible que j'ai perdu des données qui étaient stockées dans ce secteur, mais si ce secteur était (par exemple) de l'espace libre, alors je m'en fiche, et si ce secteur avait des données dessus, cela ne peut avoir d'impact que sur quelques fichiers.

— process91

@Colt - Sur la base des réponses ci-dessous, il semble que l'échec de la reconstruction de la baie sous le prétexte d'un seul URE soit un choix fait par les fabricants de matériel RAID. À mon avis, ce n'était pas le bon choix, mais heureusement, il semble que ZFS le fasse différemment.

— process91

Voir la réponse de @ shodanshok pour le processus. Quant au pourquoi, le RAID vise à fournir une continuité d'accès à des données fiables pour d'autres processus, applications, etc., et ne concerne pas la sauvegarde. La raison pour laquelle de nombreux contrôleurs matériels (la plupart?) Abandonnent une fois que l'URE se produit lors de la reconstruction est que le RAID ne peut plus faire ce qu'il est censé faire . À ce stade, les sauvegardes doivent être utilisées pour disposer de données fiables. Une autre façon d'utiliser RAID est de ne pas effectuer de reconstruction du tout, mais simplement d'utiliser RAID pour contrôler le moment de la récupération à partir de la sauvegarde. En outre, il laisse le temps de faire la sauvegarde finale avant la restauration.

— Colt

Notez que «l'implémentation ZFS de RAID5» est appelée «raidz» ou «zraid» et est différente de RAID5 matériel. Vous obtiendrez généralement de meilleures réponses sur "ZFS RAID5" en vous renseignant sur "raidz"

— Josh

24

Cela dépend vraiment de l'implémentation RAID spécifique:

la plupart des RAID matériels abandonneront la reconstruction et certains marqueront également la baie comme ayant échoué , la mettant hors service. La raison en est que si un URE se produit pendant une reconstruction RAID5, cela signifie que certaines données sont perdues, il est donc préférable d'arrêter complètement la baie plutôt que de risquer une corruption silencieuse des données. Remarque: certains RAID matériels (principalement basés sur LSI) perforeront la baie, permettant à la reconstruction de se poursuivre tout en marquant le secteur affecté comme illisible (similaire au comportement du RAID logiciel Linux).
Le RAID logiciel Linux peut être chargé: a) d'arrêter la reconstruction de la baie (le seul comportement des builds "anciens" MDRAID / kernels) ou b) de poursuivre le processus de reconstruction en marquant certains LBA comme mauvais / inaccessibles. La raison est qu'il vaut mieux laisser l'utilisateur faire son choix: après tout, un seul URE peut être sur l'espace libre, sans affecter du tout les données (ou n'affectant que les fichiers sans importance);
ZRAID affichera certains fichiers comme corrompus, mais il continuera avec le processus de reconstruction (voir ici pour un exemple). Encore une fois, la justification est qu'il est préférable de continuer et de faire rapport à l'utilisateur, lui permettant de faire un choix éclairé.

— shodanshok
source

@ process91 Juste pour développer un peu plus. Si l'implémentation RAID n'a pas les structures de données supplémentaires nécessaires pour marquer les secteurs individuels comme mauvais, elle doit soit échouer la reconstruction soit introduire une corruption silencieuse. Marquer les secteurs individuels comme étant mauvais est préférable, mais pourrait tout de même mettre d'autres secteurs en danger en raison de ceux qui partagent un secteur paritaire avec le mauvais secteur.

— kasperd

@kasperd Bien sûr, je suppose que j'ai supposé que la plupart des implémentations RAID avaient la capacité d'alerter l'utilisateur sur les secteurs défectueux. Je comprends s'il y a un secteur défectueux dans un lecteur qui conduira à un secteur incorrect dans le nouveau lecteur après une reconstruction. Cela dit, même si l'implémentation RAID n'a rien fait de plus que d'alerter l'utilisateur "J'ai reconstruit le disque du mieux que j'ai pu, mais j'ai rencontré 1 URE dans le processus", puis j'ai continué à autoriser les tentatives d'écriture dans ce secteur, je ne le fais pas voir comment d' autres secteurs pourraient être menacés. Les seuls secteurs incorrects possibles seraient l'original, le nouveau et la parité.

— process91

Une précision, basée sur les commentaires de @Colt ci-dessus - dans le cas du RAID matériel, quand il marque la baie comme défaillante, autorise-t-il toujours l'accès aux données? Même, disons, un accès en lecture seule à des fins de tentative de récupération?

— process91

@ process91 Permettre à un secteur d'être corrompu n'est pas considéré comme une bonne idée, même si ce fait a été enregistré dans un fichier journal. Vous n'auriez aucune idée du fichier qui pourrait être corrompu. Le RAID devrait s'assurer qu'à la lecture de ce fichier, vous obtenez une erreur. Il est également clair que vous ne voulez pas simplement écraser le mauvais secteur, car cela signifierait que vous venez de perdre votre dernière chance de récupérer les données. Vous avez donc un secteur illisible sur un disque et un secteur sur le nouveau disque où vous ne savez pas quoi écrire. Cela pourrait être deux fichiers différents corrompus.

— kasperd

1

@ process91 J'ai ajouté une note sur les tableaux basés sur LSI. Donnez-lui un coup d'oeil.

— shodanshok

8

Si URE se produit, vous rencontrerez une corruption de données sur le bloc, qui est généralement de 256 Ko à 1 Mo, mais cela ne signifie pas que TOUTES les données de votre volume seront perdues. Ce qui n'est pas si génial avec RAID5 est une chose totalement différente: la reconstruction elle-même est stressante et il y a de fortes chances que vous obteniez une deuxième défaillance de disque d'affilée. Dans un tel cas, toutes les données seraient perdues.

— BaronSamedi1958
source

2

Comment une reconstruction RAID5 est-elle plus stressante sur un seul disque qu'une reconstruction RAID1? Je vois que c'est plus stressant pour le processeur, mais pour tout lecteur spécifique, nous lisons simplement toutes les données. Normalement, le danger que les gens citent avec des disques plus gros est qu'ils rencontreront probablement un URE pendant la reconstruction, mais cela me convient si cela signifie simplement qu'un seul secteur sera corrompu.

— process91

3

C'est la théorie des probabilités. Avec N (où il s'agit du nombre de disques), vos chances d'échec sont N fois plus élevées.

— BaronSamedi1958

1

Ce n'est pas tout à fait comme cela que le calcul fonctionnerait, vous voudriez en fait calculer 1 probabilité de ne pas avoir de défaillance, mais je comprends cette partie. Il semble que j'ai mal interprété votre déclaration comme suggérant que l'acte de reconstruire un RAID5 est en quelque sorte plus stressant sur le disque lui-même (que j'ai lu ailleurs), ce qui augmente donc les chances d'un URE, mais si ce n'est pas ce que vous '' re disant alors je suis d'accord.

— process91

2

Je l'expliquerais dans l'autre sens;

Si le contrôleur RAID ne s'arrête pas sur URE, que pourrait-il arriver?

Je l'ai vécu sur un serveur, le RAID n'a jamais remarqué l'URE et après la reconstruction, une corruption a commencé à s'accumuler sur l'ensemble du volume RAID.

Le disque a commencé à obtenir un secteur plus défectueux après la reconstruction et les données ont commencé à être corrompues.

Le disque n'a jamais été lancé du volume RAID, l'échec du contrôleur est un travail pour protéger l'intégrité des données.

Cet exemple est écrit pour vous faire penser qu'un contrôleur ne peut pas du tout propulser un volume avec URE, c'est pour l'intégrité des données, car le volume n'est pas censé être une sauvegarde mais une résilience à une panne de disque

— yagmoth555 - GoFundMe Monica
source

1

Je vois que les nouveaux modérateurs vérifient tous en permanence le site, à la recherche de choses à faire ...

— Ward - Réinstalle Monica

1

Pourquoi un seul URE accumulerait-il de la corruption dans tout le volume RAID?

— process91

2

Désolé, j'ai relu votre réponse. Il semble que vous ayez eu une seule mauvaise URE pendant la reconstruction, mais ce n'était pas le problème. Le problème était que les secteurs ont continué à mal tourner après la reconstruction, et le lecteur ne l'a jamais signalé. Cela semble cependant être un problème distinct, de savoir si le contrôleur RAID remarque ou non un URE pendant une reconstruction. Le contrôleur RAID peut remarquer l'URE pendant la reconstruction et vous alerter mais continuez à terminer la reconstruction. Certaines données seraient toujours meilleures que pas de données.

— process91

2

Je suis seulement intéressé à analyser pourquoi RAID5 a été considéré comme "mort" en 2009, ce qui repose sur la probabilité d'un seul URE. Je comprends maintenant que cette analyse était à la fois mathématiquement incorrecte et ne s'applique pas vraiment de la même manière, par exemple, à ZFS.

— process91

1

@RobMoir Je suppose que votre dernière déclaration est là où je ne suis pas d'accord. Retirer presque toutes mes données de la baie pourrait être utile, même si j'avais une autre sauvegarde. Peut-être que ce fichier n'était pas important, ou (dans le cas d'un RAID matériel), l'erreur s'est produite dans une zone d'espace libre. Je pense que la bonne décision, pour un RAID matériel (où il ne sait pas spécifiquement quels fichiers ont été affectés) serait d'alerter l'utilisateur, de terminer la reconstruction et de basculer la baie en mode lecture seule. Je ne vois aucun inconvénient à cela. (De toute évidence, les systèmes de fichiers tels que ZFS peuvent même faire mieux, car ils peuvent signaler les fichiers affectés.)

— process91

1

Je suggère de lire cette question et ses réponses pour un peu plus de contexte. Ensuite, relisez la question à laquelle vous avez lié .

Quand quelqu'un dit à propos de cette situation que "le RAID a échoué", cela signifie que vous avez perdu l'avantage du RAID - vous avez perdu l'accès continu aux données qui était la raison pour laquelle vous avez configuré la matrice RAID en premier lieu.

Vous n'avez pas perdu toutes les données, mais la façon la plus courante de récupérer à partir d'un disque mort plus (certains) URE sur (certains) des disques restants serait de reconstruire complètement la matrice à partir de zéro, ce qui signifie restaurer toutes vos données à partir de la sauvegarde.

— Quartier - Réintégrer Monica
source

1

Généralement, vous utilisez RAID lorsque votre objectif est de minimiser les temps d'arrêt. Faire en sorte que la baie continue de fonctionner avec une corruption inconnue et non réparée est généralement contraire à cet objectif.

— David Schwartz

1

Merci, cette première question à laquelle vous avez lié était très informative. Pourquoi aurais-je perdu l'accès continu aux données? Le tableau serait toujours actif pendant la reconstruction, et s'il rencontre un URE pendant la reconstruction, je m'attendrais à ce qu'il continue, même si ce secteur de données est maintenant corrompu. Ce n'est pas le cas?

— process91