Como o RAID pode lidar com dados inconsistentes?

Question

O RAID 1 e o RAID 5 (e seus irmãos 10 e 50) obtêm redundância de dados, respectivamente, através do espelhamento e da verificação de paridade. Isso permite que uma matriz RAID ainda acesse dados quando um setor em um disco (ou um disco inteiro) se torna ilegível. O RAID 6 (ou 60) usa uma verificação adicional para permitir duplas falhas.

Mas como uma matriz RAID pode lidar com dados que não são totalmente ilegíveis, mas simplesmente inconsistentes?

Se algum erro ocorrer de tal forma que f.e. os dados em uma faixa são alterados em um disco, mas a alteração não é propagada para outra (s), a faixa inteira se tornaria inconsistente. Se, em um conjunto espelhado, um disco disser "esse bit é 0", enquanto o outro disco diz "esse bit é 1", como um controlador RAID sabe qual é o certo? O mesmo raciocínio poderia ser aplicado a uma faixa RAID-5, com a complexidade adicional de que você não pode saber facilmente que qual setor está errado na faixa. Além disso, o RAID 6 atenua esse problema com seus double ckecks ou ainda pode ter problemas se recuperando da corrupção de dados quando os dados são realmente legíveis, mas está errado em algum lugar, especialmente porque os arrays RAID 6 tendem a ter muitos discos?

Isso teoricamente poderia ser resolvido por checksums, para garantir que qual cópia dos dados (ou paridade) é a correta; mas será que algum controlador RAID realmente implementa esse tipo de soma de verificação (o que, é claro, ocuparia espaço adicional)? Ou precisa ser tratado no nível do SO, onde a maioria dos sistemas de arquivos pode e irá verificar seu conteúdo? E se este for o caso, como eles podem dizer ao controlador RAID "dados no setor X no disco Y na faixa Z está errado", quando a abordagem geral de um controlador RAID é abstrair o sistema operacional de a camada de armazenamento subjacente, tanto quanto possível?

    

Answer 1

RAID VOLUMES WITH PARITY STRIPE

Nos controladores Areca que usamos (e todos os controladores RAID de hardware modernos) durante uma verificação de consistência, o controlador pode detectar se a corrupção está com os dados de paridade, os dados físicos no disco ou ambos. A maioria dos controladores realiza isso com bits de soma de verificação simples para os dados de paridade e dados em disco.

No caso dos dados de paridade serem corrompidos, o controlador notará o problema quando você executar uma verificação de consistência e reler o disco físico para os bits corretos e reescrever a distribuição de paridade. Os usuários não verão problemas porque estão lendo dados no disco ao abrir os arquivos. Salvar tudo o que fizer com que a faixa de paridade corrompida seja reescrita também corrigirá o problema.

Se ocorrer o oposto, e um pouco de dados reais no disco, o controlador examinará a faixa de paridade durante uma verificação de consistência para ver se ela foi alterada. Nesse caso, o controlador sobrescreverá os dados no disco para corresponder aos dados de paridade, o que pode confirmar que está inalterado / bom. Os usuários receberão um erro de CRC ou um arquivo corrompido, dependendo de quais são os dados, até que uma verificação de consistência seja executada e corrija o erro.

Como os dados de paridade para dados específicos no disco nunca são armazenados na mesma unidade que os dados reais, uma única falha na unidade não deve causar problemas de corrupção de dados. Ou dois discos para o RAID6, etc.

As verificações de consistência mantêm seus dados mais precisos possíveis e, se você permitir que dados corrompidos permaneçam no seu volume por tempo suficiente, eles poderão ser gravados em dados de paridade, o que significa que o arquivo está corrompido e precisará ser restaurado de um backup. Se uma unidade estiver em um estado anterior à falha, em que está mostrando erros durante as verificações de consistência, substitua a unidade imediatamente, em vez de esperar que o controlador a marque como falha. Nós executamos verificações de consistência diariamente em volumes menores e semanalmente nos maiores.

RAID VOLUMES WITHOUT PARITY STRIPE (EX. RAID1)

O controlador / firmware do disco rígido pode corrigir o problema. Se isso não for possível, o controlador RAID terá dificuldade em corrigir o problema. Nesse caso, você provavelmente teria que ler as unidades individualmente para recuperar os dados.

GENERALLY SPEAKING

Execute verificações de consistência no intervalo recomendado pelo seu cartão RAID mfg. Se você estiver realmente preocupado com a corrupção, também poderá empilhar um sistema de arquivos resiliente em um volume RAID. Os sistemas de arquivos resilientes modernos podem corrigir muitos desses problemas de integridade de dados e o empilhamento de um FS resiliente sobre o RAID6 ofereceria excelente tempo de atividade dos dados, sem corrupção. E mesmo com 2 falhas simultâneas no drive, você ainda teria dados de paridade do FS disponíveis para evitar apresentar dados corrompidos ao usuário.

    

Answer 2

Você descreve efetivamente a situação, em que um disco grava (ou lê) um erro. O controlador RAID não tem nenhuma maneira prática (por exemplo, escrever e ler de volta mataria seu desempenho) para se proteger contra essa situação. Ele precisa contar com os discos capazes de detectar esse tipo de erro e usar um bloco diferente ou salvar o volume - causando uma degradação do RAID.

Se você pensar na situação de disco único, a única proteção contra gravações inconsistentes (ou leituras) é o próprio disco. O RAID se baseia nisso, mas não introduz uma proteção adicional.

N.B. Eu sei por experiência que o XFS reage de forma bastante sensata a discos errados em um array. Então, pelo menos meus controladores não-low-end e o sistema operacional reconheceram, mas não protegeram, contra essa inconsistência (um disco defeituoso foi adicionado com força a um volume).