Se um sistema RAID5 tiver um URE durante a reconstrução, todos os dados serão perdidos?

23

Entendo o argumento sobre a probabilidade aumentada de unidades maiores de experimentar um URE durante uma reconstrução, mas não tenho certeza de quais são as implicações reais para isso. Esta resposta diz que toda a reconstrução falha, mas isso significa que todos os dados estão inacessíveis? Por que isso seria? Certamente, um único URE de um único setor na unidade só afetaria os dados relacionados a alguns arquivos. A matriz ainda não seria reconstruída, apenas com uma pequena corrupção em alguns arquivos?

(Estou especificamente interessado na implementação do RAID5 do ZFS aqui, mas a lógica parece a mesma para qualquer implementação do RAID5.)

raid zfs zfsonlinux

— process91
fonte

1

Em geral, quando a "probabilidade de ocorrer uma URE durante uma reconstrução " é discutida no contexto dos riscos do RAID5, a suposição implícita é que uma corrupção anterior já ocorreu para fazer com que a reconstrução seja necessária. Em outras palavras, o "URE durante a reconstrução" é o segundo URE e, de fato, TODOS os dados serão perdidos.

— Colt

1

@Colt - Entendo que essa é a implicação, mas o que não entendo é por que um único URE (que, na análise de por que o RAID5 não é recomendado, parece se referir a um setor ruim) significaria que todos os dados seriam estar perdido. Em geral, se eu perdi 1 unidade de uma matriz RAID5, ainda tenho todos os dados. Se eu perder adicionalmente um único setor de qualquer uma das unidades restantes, é possível que eu tenha perdido dados armazenados nesse setor, mas se esse setor tiver (por exemplo) espaço livre, não me importo e se esse setor tiver dados, isso poderá afetar apenas alguns arquivos.

— process91

@Colt - Com base nas respostas abaixo, parece que a falha em reconstruir a matriz na presença de um único URE foi uma escolha feita pelos fabricantes de hardware RAID. Na minha opinião, essa foi a escolha errada, mas, felizmente, o ZFS parece diferente.

— process91

Veja a resposta de @ shodanshok para o processo. Quanto ao porquê, o RAID é para fornecer continuidade de acesso a dados confiáveis para outros processos, aplicativos, etc., e não se trata de backup. A razão pela qual muitos controladores de hardware abortam quando o URE ocorre na reconstrução é que o RAID não pode mais fazer o que deveria . Nesse ponto, os backups precisam ser usados para ter dados confiáveis. Outra maneira de usar o RAID é não fazer nenhuma reconstrução, mas apenas usar o RAID para controlar o tempo de recuperação do backup. Além disso, permite tempo para fazer o backup final antes da recuperação.

— Colt

Observe que “a implementação do RAID5 do ZFS” é chamada de “raidz” ou “zraid” e é diferente do RAID5 de hardware. Você geralmente obterá melhores respostas sobre “ZFS RAID5” perguntando sobre “raidz”

— Josh

24

Realmente depende da implementação específica do RAID:

a maioria dos RAID de hardware abortará a reconstrução e alguns também marcarão a matriz como falhada , derrubando-a. A lógica é que, se um URE ocorrer durante uma reconstrução do RAID5, significa que alguns dados serão perdidos; portanto, é melhor parar completamente a matriz em vez de arriscar a corrupção silenciosa de dados. Nota: algum RAID de hardware (principalmente baseado em LSI) perfurará a matriz, permitindo que a reconstrução continue enquanto marca o setor afetado como ilegível (semelhante à maneira como o RAID de software Linux se comporta).
O RAID do software linux pode ser instruído para: a) interromper a reconstrução do array (o único comportamento de compilações "antigas" do MDRAID / kernels) ou b) continuar com o processo de reconstrução, marcando alguns LBA como ruins / inacessíveis. A lógica é que é melhor deixar que o usuário faça sua escolha: afinal, um único URE pode estar no espaço livre, não afetando os dados (ou afetando apenas os arquivos sem importância);
O ZRAID mostrará alguns arquivos como corrompidos, mas continuará com o processo de reconstrução (veja aqui um exemplo). Novamente, a lógica é que é melhor continuar e reportar ao usuário, permitindo que ele faça uma escolha informada.

— shodanshok
fonte

@ process91 Apenas para elaborar um pouco mais. Se a implementação do RAID não tiver as estruturas de dados adicionais necessárias para marcar setores defeituosos, ela deve falhar na reconstrução ou introduzir corrupção silenciosa. Marcar setores individuais como ruins é melhor, mas ainda pode colocar outros setores em risco devido a pessoas que compartilham um setor paritário com o setor ruim.

— kasperd

@kasperd Claro, acho que assumi que a maioria das implementações de RAID tinham a capacidade de alertar o usuário sobre setores defeituosos. Entendo se existe um setor defeituoso em uma unidade que levará a um setor incorreto na nova unidade após uma reconstrução. Dito isto, mesmo que a implementação do RAID não tenha feito nada além de alertar o usuário "Eu reconstruí a unidade da melhor maneira possível, mas experimentei 1 URE no processo" e continuei a permitir gravações tentadas nesse setor, mas não veja como outros setores podem estar em risco. Os únicos setores incorretos possíveis seriam o original, o novo e a paridade.

— process91

Um esclarecimento, com base nos comentários do @Colt acima - no caso do RAID de hardware, quando ele marca a matriz como falhada , ainda permite o acesso aos dados? Mesmo, digamos, acesso somente leitura para fins de tentativa de recuperação?

— process91

@ process91 Permitir que um setor seja corrompido não é uma boa ideia, mesmo que esse fato tenha sido registrado em um arquivo de log. Você não teria idéia de qual arquivo pode estar corrompido. O RAID teria que garantir que, ao ler esse arquivo, você receba um erro. Também é claro que você não deseja substituir apenas o setor defeituoso, porque isso significa que você acabou de perder sua última chance de recuperar os dados. Portanto, você tem um setor ilegível em um disco e um setor no novo disco em que não sabe o que escrever. Podem ser dois arquivos diferentes corrompidos.

— kasperd

1

@ process91 Adicionei uma observação sobre matrizes baseadas em LSI. Dê uma olhada.

— shodanshok

8

Se o URE acontecer, você sofrerá uma corrupção de dados no bloco, que geralmente tem tamanho de 256 KB-1 MB, mas isso não significa que TODOS os dados do seu volume seriam perdidos. O que não é tão bom no RAID5 é uma coisa totalmente diferente: a reconstrução é estressante e há grandes chances de você ter uma segunda falha de disco consecutiva. Nesse caso, todos os dados seriam perdidos.

— BaronSamedi1958
fonte

2

Como uma reconstrução de RAID5 é mais estressante em uma única unidade do que uma reconstrução de RAID1? Vejo que é mais estressante na CPU, mas para qualquer unidade específica, estamos simplesmente lendo todos os dados. Normalmente, o perigo que as pessoas citam com unidades maiores é que elas provavelmente encontrarão um URE durante a reconstrução, mas tudo bem comigo se isso significa apenas que um único setor será corrompido.

— process91

3

É teoria das probabilidades. Com N (onde é o número de unidades), suas chances de falha são N vezes maiores.

— BaronSamedi1958

1

Não é bem assim que o cálculo funcionaria, você realmente gostaria de calcular 1 - probabilidade de não ter uma falha, mas eu entendo essa parte. Parece que interpretei incorretamente sua declaração como sugerindo que o ato de reconstruir um RAID5 é de alguma forma mais estressante no próprio disco (que li em outro lugar), o que aumenta a chance de um URE, mas se não é isso que você ' re dizendo então eu concordo.

— process91

2

Eu explicaria o contrário;

Se o controlador RAID não parar no URE, o que poderia acontecer?

Eu morava em um servidor, o RAID nunca notou o URE e, após a reconstrução, uma corrupção começou a se acumular em todo o volume RAID.

O disco começou a ficar mais danificado após a reconstrução e os dados começaram a ficar corrompidos.

O disco nunca foi iniciado com o volume RAID, a falha do controlador é tarefa para proteger a integridade dos dados.

Esse exemplo foi escrito para fazer você pensar que um controlador não pode impulsionar um volume com o URE, é para a integridade dos dados, pois o volume não é para ser um backup, mas uma resiliência a uma falha no disco

— yagmoth555 - GoFundMe Monica
fonte

1

Vejo que os novos moderadores estão todos constantemente checando o site, procurando coisas para fazer ...

— Ward - Reinstate Monica

1

Por que um único URE criaria corrupção em todo o volume RAID?

— process91

2

Desculpe, reli sua resposta. Parece que você teve um único URE ruim durante a reconstrução, mas esse não foi o problema. O problema era que os setores continuaram mal após a reconstrução e a unidade nunca a informou. Isso parece um problema separado, no entanto, se o controlador RAID notou ou não um URE durante uma reconstrução. O controlador RAID pode observar o URE durante a reconstrução e alertá-lo, mas ainda continua a concluir a reconstrução. Alguns dados sempre seriam melhores que nenhum dado.

— process91

2

Só estou interessado em analisar por que o RAID5 foi considerado "morto" em 2009, que se baseia na probabilidade de um único URE. Meu entendimento agora é que essa análise era matematicamente incorreta e realmente não se aplica da mesma maneira, por exemplo, ao ZFS.

— process91

1

@ RobMoir Acho que sua última afirmação é onde discordo. Obter quase todos os meus dados da matriz pode ser útil, mesmo se eu tivesse outro backup. Talvez esse arquivo não tenha sido importante ou (no caso de RAID de hardware), o erro ocorreu em uma área de espaço livre. Acho que a decisão certa, para o RAID de hardware (onde não se sabe especificamente quais arquivos foram afetados), seria alertar o usuário, concluir a reconstrução e colocar a matriz no modo somente leitura. Não vejo nenhuma desvantagem nisso. (Obviamente, sistemas de arquivos, como ZFS pode até mesmo fazer melhor, uma vez que eles podem relatar os arquivos afetados.)

— process91

1

Sugiro ler esta pergunta e respostas para obter um pouco mais de experiência. Em seguida, leia novamente a pergunta à qual você vinculou .

Quando alguém diz sobre essa situação que "o RAID falhou", significa que você perdeu o benefício do RAID - o acesso contínuo aos dados foi o motivo pelo qual você configurou a matriz RAID em primeiro lugar.

Você não perdeu todos os dados, mas a maneira mais comum de recuperar de uma unidade morta mais (alguns) UREs em (algumas) unidades restantes seria reconstruir completamente a matriz do zero, o que significa restaurar todos os seus dados do backup.

— Ala - Restabelecer Monica
fonte

1

Geralmente, você usa o RAID quando seu objetivo é minimizar o tempo de inatividade. O fato de a matriz continuar com a corrupção desconhecida e não reparada geralmente contraria esse objetivo.

— David Schwartz

1

Obrigado, a primeira pergunta que você vinculou foi muito informativa. Por que eu teria perdido acesso contínuo aos dados? A matriz ainda estaria ativa durante a reconstrução e, se encontrar um URE durante a reconstrução, eu esperaria que ela continuasse, embora com esse setor de dados agora corrompido. Não é este o caso?

— precisa saber é o seguinte