Omitir para ir al contenido principal
  • Hacer pedidos rápida y fácilmente
  • Ver pedidos y realizar seguimiento al estado del envío
  • Cree y acceda a una lista de sus productos
  • Administre sus sitios, productos y contactos de nivel de producto de Dell EMC con Administración de la empresa.

Como lidar com perfurações (blocos danificados) nos discos virtuais para os servidores PowerEdge

Resumen: etapas de solução de problemas para (punção d)os blocos defeituosos em discos rígidos em servidores PowerEdge com controladores PERC. Especialmente quando não é possível fazer backup, as informações a seguir podem ajudar a trazer uma unidade virtual impactada de volta para um estado ideal. ...

Es posible que este artículo se traduzca automáticamente. Si tiene comentarios sobre su calidad, háganoslo saber mediante el formulario en la parte inferior de esta página.

Contenido del artículo


Síntomas

-

Causa

-

Resolución

Este artigo fornece as etapas de solução de problemas para (punção d)os blocos defeituosos em discos rígidos em servidores PowerEdge com controladores PERC. Especialmente quando não é possível fazer backup, as informações a seguir podem ajudar a trazer uma unidade virtual impactada de volta para um estado ideal.



Sumário:

  1. Descrições de falhas

  2. Qual é a causa

  3. Etapas para resolver o problema

  4. Informações adicionais


 



1. Descrições de falhas

 

Falha nº 1:


O OpenManage Server Administrator (OMSA) mostra uma cruz vermelha na frente de um disco virtual (Figura 1).  

SLN111146_en_US__11343098652871.1
Figura 1: Disco virtual com cruz vermelha no status (por exemplo, H800)

SLN111146_en_US__2icon Nota: O Dell Open Manage Server Administrator (OMSA) fornece uma solução de gerenciamento de sistemas completa e individualizada. O OMSA pode ser divido em dois aplicativos:
- Integrado - uma interface gráfica do usuário baseada em navegador da Web (GUI)
- Interface de linha de comando (CLI) - por meio do sistema operacional


 


Falha nº 2:


O log do sistema do Windows mostra erros de bloco defeituosos (Figura 2).  

SLN111146_en_US__31343098674763.2 
Figura 2: Erro de bloco defeituoso acusado no log do sistema do Windows
 


 


Falha nº 3:


O log do controlador RAID (TTYLOG) mostra erros como:  

02/26/15 13:43:39: EVT#131878-02/26/15 13:43:39: 97=Puncturing bad block on PD XX(e0x20/s2) at 180ca4a1f

Advertência: O log do controlador (TTYLOG) pode não apresentar erros.

Obtenha mais informações sobre como receber esses logs específicos em nosso artigo sobre como coletar logs.
 



2. Qual é a causa raiz:


Os arrays RAID não estão imunes aos erros de dados.  O controlador RAID e o firmware do disco rígido contêm funcionalidades para detectar e corrigir muitos tipos de erros de dados antes que eles sejam gravados em um array/disco.  Usar firmware desatualizado pode fazer com que dados incorretos sejam gravados em um array/disco porque ele pode não ter os recursos de gerenciamento/correção de erros disponíveis em versões mais recentes de firmware.
Erros de dados também podem ser causados por blocos físicos defeituosos.  Por exemplo, isso pode ocorrer quando a cabeça de leitura/gravação bate no prato giratório (conhecido como "Head Crash").  Os blocos também podem apresentar defeitos com o passar do tempo devido à degradação da capacidade do prato de armazenar bits magneticamente em um local específico.  Em geral, os blocos defeituosos devido à degradação do prato podem ser lidos com sucesso.  Esse bloco defeituoso pode ser detectado apenas de forma intermitente ou com um diagnóstico estendido dos discos.  

Um bloco defeituoso, também conhecido como um Endereço de Bloco Lógico (LBA) defeituoso, também pode ser causado por erros de dados lógicos.  Isso ocorre quando os dados são gravados incorretamente em um disco, mesmo que a gravação seja relatada como bem-sucedida.  Além disso, dados em bom estado armazenados em um disco podem ser alterados acidentalmente.  Um exemplo é um "bit flip", que pode ocorrer quando a cabeça de leitura/gravação passa ou grava em um local próximo e faz com que os dados na forma de zeros e uns mudem para um valor diferente.  Tal condição faz com que a consistência dos dados seja corrompida.  O valor dos dados em um bloco específico é diferente dos dados originais e pode não corresponder mais à soma de verificação (checksum) dos dados.  O LBA físico está em boas condições e pode ser gravado com sucesso, mas atualmente contém dados incorretos e pode ser interpretado como um bloco defeituoso.

Para obter mais informações, leia o artigo sobre Falhas duplas e perfurações em arrays RAID.
 



3. Etapas para resolver o problema:
 

SLN111146_en_US__2icon Nota: Os dados atuais no disco virtual estão corrompidos e terão que ser excluídos
  1. Crie um backup de dados validado em nível de arquivo
     

    • Um backup baseado em bloco transferiria o problema
    • Um backup em nível de arquivo indica arquivos corrompidos (esses arquivos falharão ao fazer backup)
    • Nunca há 100% de garantia de que todos os dados sejam mantidos se uma faixa de punção já estiver localizada
     

     

  2. Certifique-se de que todas as unidades com falha mostrando falhas preditivas sejam substituídas
     

  3. Excluir e recriar o disco virtual
     

    • Esta etapa excluirá todos os dados do DV
    • Excluir o array
    • Recriar o array conforme desejado
     

     

  4. Realize uma inicialização completa do DV
     

    • Certifique-se de que nenhuma inicialização rápida seja escolhida
    • Apenas uma inicialização completa (lenta) corrige o problema
     

     

  5. Realize uma verificação de consistência no novo DV criado
     

    • Se a operação de verificar consistência for concluída sem erros, o array agora está íntegro e a punção foi removida.
     

     

  6. Os dados podem agora ser restaurados para o VD íntegro
     

  7. Recomendação: Faça upgrade de todos os firmwares de discos rígidos para a versão mais recente
     



4. Informações adicionais

O OMSA oferece a capacidade de limpar os avisos de blocos defeituosos. Para limpar os blocos defeituosos, recomenda-se o seguinte procedimento:

  • Ao realizar um backup do disco virtual com a opção Verificar selecionada, dois cenários podem ocorrer:

    • A operação de backup falha em um ou mais arquivos. Nesse caso, restaure o arquivo a partir de um backup anterior. Depois de restaurar o arquivo, prossiga para a próxima etapa.
    • A operação de backup é concluída sem erros. Isso indica que não há blocos defeituosos na parte gravada do seu disco virtual.
    SLN111146_en_US__2icon Nota: Se você ainda receber avisos de blocos defeituosos, significa que os blocos defeituosos não estão em uma área de dados.

     
  • Execute o Patrol Read (em Tarefas de disco virtual no OMSA) e verifique o log de eventos do sistema para garantir que nenhum novo bloco defeituoso foi encontrado. Se os blocos defeituosos ainda existirem, prossiga para a próxima etapa. Caso contrário, haverá a limpeza da condição.

    SLN111146_en_US__2icon Nota: O Patrol Read automatizado deve ser desativado antes que a opção de executar manualmente essa ação seja exibida no OMSA.

     
  • Para limpar esses blocos defeituosos, execute a tarefa limpar discos defeituosos do disco virtual . Isso pode ser feito na GUI do OMSA ou com o uso o comando cli:
    omconfig storage vdisk action=clearvdbadblocks controller=id vdisk=id

    SLN111146_en_US__2icon Nota: Para obter os valores do ID do controlador e do ID do disco virtual, digite omreport storage controller para exibir os IDs do controlador e, em seguida, digite omreport storage vdisk controller=ID para exibir os IDs dos discos virtuais

     

Propiedades del artículo


Producto comprometido

Servers

Fecha de la última publicación

01 oct 2021

Versión

3

Tipo de artículo

Solution