VNX/Unity: Noções básicas sobre setores incorrigível e erros de paridade (usuários que podem ser corrigidos)

Entender os setores incorrigível e os erros de paridade em um array CLARiiON, VNX ou Unity.

Mensagens de log de eventos, como a seguir, também podem aparecer como dial Homes:

VNX1
código de erro: código de erro incorrigível do setor de paridade do 0x953
: código de erro incorrigível do setor de dados do 0x957
: código de erro incorrigível do setor de paridade do 0x68A
: código de erro incorrigível do setor de dados do 0x695
: o B26 cache de 0x840 de dados invalidado
foi emitido CORRUPT_CRC. LUN = 309 ca_sync. c 0 309 2

Grupo de RAID do setor não corrigível do VNX2
71688003: posição %2: LBA DE %3: %4 Blocks: %5 informações de erro: %6 informações adicionais: %7
71688008 grupo de RAID do setor não corrigível: 10 posições: 1 LBA: d180 Blocks: 8 informações de erro: 0 informação extra: e [r5_rb FLU 8224 r5_rb]
71688008 grupo de RAID do setor não corrigível: 10 posições: 1 LBA: d170 Blocks: 8 informações de erro: 0 informação extra: e [r5_rb FLU 8224 r5_rb]
71688001 setor de dados invalidado grupo de RAID: 10 posições: 1 LBA: d121 Blocks: 7 informações de erro: 0 info extra: e [r5_rb FLU 8224 r5_rb]

Erros incorrigível ocorrem quando dois discos diferentes no mesmo grupo de RAID, no mesmo setor, têm erros de mídia. 
Um exemplo, quando um disco com erros de mídia são copiados para um hot spare e outro disco no mesmo grupo de RAID, no mesmo setor, também tem erros de mídia, isso resultava em um erro/setor incorrigível. 

Os códigos de evento descritos acima são registrados quando o sistema não consegue ler os setores de dados de um disco e as tentativas subsequentes de reconstruir os dados de outro disco no grupo de RAID falharam. As mensagens "não corrigível" indicam quais discos não conseguiram ler com sucesso os setores do, e as mensagens "invalidadas" indicam quais setores de disco foram marcados como void de informações válidas em um local específico. Essa marca é feita para garantir que nenhum dado inválido será retornado para um sistema host. As tentativas de ler a partir de um local invalidado resultarão em um erro físico ao ser devolvido a um host.
As tentativas de gravação em um local invalidado serão concluídas com sucesso e, geralmente, "Fill" (sobregravar) o local de void, corrigindo efetivamente o incorrigível. Esse é o motivo pelo qual algumas vezes os erros incorretos desaparecem depois de um host sobregravar esses setores com novos dados bons.

Por VNX:
Uma vez que todos os problemas de hardware sejam resolvidos, Dell EMC suporte técnico precisará executar uma verificação de segundo plano (ROBV) de somente leitura manual se o (s) LUN (s) interno afetado (s) no pool afetado. O ROBV lê e verifica os dados por uncorrectables em todo o LUN (interno), incluindo espaço não utilizado para determinar quantos setores uncorrectables ainda podem existir.
Depois que o ROBV for concluído, se os uncorrectables ainda estiverem ocorrendo, seu Dell EMC engenheiro de suporte técnico precisará executar etapas adicionais, inclusive coletar e analisar as informações da tabela de alocação de armazenamento (SAT) para identificar o (s) LUN usuário (s) específico (s) afetado (os LUNs internos onde o uncorrectables foi encontrado serão associados às LUNs do usuário).
Para obter uma explicação completa e os pré-requisitos necessários para executar um ROBV, consulte o artigo 466638, VNX: Explicação de verificação de segundo plano de somente leitura (ROBV) (usuário corrigível)

Se um setor incorrigível for encontrado em uma LUN de usuário, os dados do usuário precisarão ser verificados pelo aplicativo host para determinar se os dados do usuário estão corrompidos ou se o erro reside em espaço não utilizado. Qualquer processo que leia os dados, como um backup, se adequaria à identificação/indicador de possível corrupção.
Se houver corrupção, os dados podem ser restaurados a partir de um bom backup, com uma restauração completa ou uma restauração parcial apenas dos arquivos afetados.
Se não houver um bom backup, outro meio do aplicativo host deve ser usado para restaurar ou recriar os dados. 

Se o erro incorrigível não for encontrado nos dados do usuário, os processos de segundo plano ainda poderão detectar o erro no futuro, se o I/O do host não sobregravar o setor. Isso pode levar a uma avaliação incorreta de que esse é um novo erro e causa atrasos na análise e na remediação de um erro antigo que não foi completamente resolvido.
Nesse caso, é altamente recomendável mover os dados bons para outro LUN e excluir os LUNs afetados originais.

Para o Unity, podem existir outros métodos para tentar ajudar a resolver esse problema. Verifique se há mais artigos específicos do Unity.

Perguntas frequentes:

A engenharia tem outra maneira de recuperar dados perdidos do cliente se um aplicativo host do cliente não sobregravar os dados e se uma restauração do backup não funciona? 
Não existe outra maneira de recuperar os dados que não sejam uma operação de restauração ou recriar os dados do aplicativo.
Como os dados incorretos estão, na verdade, os dados ausentes, não é possível saber quais são os dados para gravá-los de volta.  Esse é o motivo pelo qual o setor é "invalidado" e um erro físico é retornado para o host. É melhor retornar um erro físico do que os dados incorretos. 

É possível que um setor invalidado altere locais em um disco? 
Para um LUN padrão, o setor de dados inválido sempre permanecerá o mesmo.
Para um pool LUN com classificação automática por níveis habilitada, ele pode mover se a fatia for realocada.

Há uma maneira de calcular o local real de um setor invalidado?  
É muito difícil localizar a posição de um setor invalidado, devido ao modo como as LUNs são mapeadas em grupos de RAID ou pools e quais informações estão disponíveis nos logs de eventos.
Entre em contato com o suporte da Dell EMC para obter mais ajuda para identificar os Blocks que contêm o setor invalidado.  A equipe de suporte será necessária primeiro pelo processo de recuperação incorrigível e, em seguida, escalonar o problema para a equipe de recuperação. . 

Se o setor invalidado não aparecer para afetar a área de dados do cliente, há uma maneira de eliminá-lo sem desvincular o LUN?
Algum sucesso foi relatado durante a gravação de dados temporários para preencher o LUN e, em seguida, excluir os dados temporários.  Se a área invalidada for gravada em dados temporários, o (s) local (is) void (s) será preenchido, restaurando, assim, o setor inválido com dados válidos. 

Um cliente pode executar apenas um CHKDSK ou FSCK para verificar a integridade dos dados no sistema de arquivos se erros incorrigívels são relatados pela verificação de segundo plano somente leitura? 
Quando houver um problema de setores incorretos, os dados do cliente devem ser verificados para ver se há alguma corrupção de arquivo. Para fazer isso, execute algum tipo de aplicativo ou programa que Leia todos os setores usados no espaço de LUN. O tipo de método mais comum é um backup completo dos dados. Não é recomendável executar simplesmente um FSCK (UNIX) ou um CHKDSK (Windows), pois esses utilitários só verificam a área de metadados dos arquivos. Se os setores não corrigível não estiverem no espaço de metadados, o cliente ficará à medida que os dados são OK quando, na verdade, talvez não sejam.

Outras perguntas frequentes:

Por que é necessário desativar a compactação de dados?
A compactação de dados é um recurso que analisa os dados em um disco e aplica algoritmos que reduzem o tamanho das sequências de bits repetitivas de bits inerentes a alguns tipos de arquivos. Durante a operação de compactação para um grupo de RAID LUN, o software migra e compacta os dados do LUN em um thin LUN em um pool. O LUN se torna uma LUN de thin compactada. As operações de compactação para LUNs de pool (grosso e thin) são executadas dentro do pool no qual o LUN que está sendo compactado reside. Sempre que os dados são compactados, há uma movimentação de dados dentro do pool que não nos ajudará a identificar os MLU corretos que estão sendo afetados devido a Uncorrectables ou coerência inesperada. O recurso precisa ser pausado.

Por que é necessário desativar o classificação automática por níveis?
O recurso de classificação automática por níveis faz a migração de dados entre os níveis de armazenamento ou a mídia de armazenamento diferente (EFD, & FC SATA). A finalidade do armazenamento hierárquico é manter os dados mais acessados ou importantes em unidades rápidas de alto desempenho (mais caras) e mover os dados menos acessados e menos importantes para unidades de desempenho baixo (menos caros). Semelhante à compactação de dados, há movimentação de dados envolvida em classificação automática por níveis, o que não ajudará a identificar o setor do MLU que é afetado devido a Uncorrectables ou coerência inesperada se ele não estiver desabilitado. A realocação precisa ser interrompida e o agendamento precisa ser desativado.

Por que é necessário desativar o Fast cache?
O Fast cache só precisa ser desativado se o erro de setor incorrigível for informado no fast cache

por que é necessário executar o ROBV em todo o grupo de RAID (RG) e não no LUN específico?
Você precisa executar o ROBV em todo o RG para certificar-se de que outras LUNs do cliente no mesmo RG não foram afetadas.

Por que é necessário executar o ROBV no pool e não apenas o grupo de RAID?
Você precisa executar o ROBV em um pool inteiro se um agendamento de classificação automática por níveis tiver sido executado desde que o tempo que um incorrigível foi informado e que o ROBV esteja agendado para começar.  Isso é necessário, uma vez que as fatias de dados podem mover o incorrigível para outro setor se essa fatia de dados for movida para outro nível.
 
Por que é necessário reunir informações sobre a tabela de alocação de armazenamento SAT?
As informações de SAT durante a execução por meio das ferramentas usadas pelo suporte Dell EMC, determinarão o cliente LUN/MLU de que o setor não corrigível esteja em.  Isso também indica se o problema está no espaço de dados ou no espaço de metadados da LUN do cliente.