Como um único disco em uma matriz SATA RAID-10 de hardware pode levar a matriz inteira a uma parada brusca?

Question

Prelúdio:

Sou um macaco de códigos que está cada vez mais recebendo tarefas do SysAdmin para minha pequena empresa. Meu código é nosso produto e, cada vez mais, fornecemos o mesmo aplicativo que o SaaS.

Cerca de 18 meses atrás, mudei nossos servidores de um fornecedor central de hospedagem premium para um empurrador de rack barebone em um data center de nível IV. (Literalmente do outro lado da rua.) Este trabalho faz muito mais nós mesmos - coisas como rede, armazenamento e monitoramento.

Como parte da grande mudança, para substituir nosso armazenamento alocado direto da empresa de hospedagem, eu construí um NAS de dois nós de 9TB baseado em chassi SuperMicro, placas 3ware RAID, Ubuntu 10.04, duas dúzias de discos SATA, DRBD e. Tudo está cuidadosamente documentado em três posts: Criando & testando um novo NAS 9TB SATA RAID10 NFSv4: Parte I , Parte II e Parte III .

Também configuramos um sistema de monitoramento Cacit. Recentemente, adicionamos mais e mais pontos de dados, como valores SMART.

Eu não poderia ter feito tudo isso sem o incrível boffins em ServerFault . Tem sido uma experiência divertida e educativa. Meu chefe está feliz (economizamos um monte de dólares) , nossos clientes estão felizes (os custos de armazenamento estão em baixa) , estou feliz (divertido, divertido, divertido) .

Até ontem.

Interrupção & Recuperação:

Algum tempo depois do almoço, começamos a receber relatórios de desempenho lento de nosso aplicativo, um CMS de mídia de streaming sob demanda. Mais ou menos na mesma época, nosso sistema de monitoramento Cacti enviou uma enxurrada de e-mails. Um dos alertas mais reveladores foi um gráfico de iostat aguardando.

OdesempenhoficoutãodegradadoqueoPingdomcomeçouaenviarnotificações"servidor inativo". A carga total foi moderada, não houve pico de tráfego.

Depois de fazer login nos servidores de aplicativos, clientes NFS do NAS, confirmei que praticamente tudo estava passando por tempos de espera de IO altamente intermitentes e insanamente longos. E uma vez que eu pulei no próprio nó NAS primário, os mesmos atrasos ficaram evidentes ao tentar navegar pelo sistema de arquivos do array com problemas.

Hora de reprovar, tudo correu bem. Dentro de 20 minutos tudo foi confirmado para estar de volta e funcionando perfeitamente.

Post-Mortem:

Após todas e quaisquer falhas no sistema, eu faço um post-mortem para determinar a causa da falha. A primeira coisa que fiz foi o ssh de volta à caixa e começar a revisar os logs. Estava offline, completamente. Tempo para uma viagem ao centro de dados. Reinicialização de hardware, backup e execução.

Em /var/syslog , encontrei esta entrada assustadora:

Nov 15 06:49:44 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_00], 6 Currently unreadable (pending) sectors
Nov 15 06:49:44 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_07], SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 171 to 170
Nov 15 06:49:45 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_10], 16 Currently unreadable (pending) sectors
Nov 15 06:49:45 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_10], 4 Offline uncorrectable sectors
Nov 15 06:49:45 umbilo smartd[2827]: Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
Nov 15 06:49:45 umbilo smartd[2827]: # 1  Short offline       Completed: read failure       90%      6576         3421766910
Nov 15 06:49:45 umbilo smartd[2827]: # 2  Short offline       Completed: read failure       90%      6087         3421766910
Nov 15 06:49:45 umbilo smartd[2827]: # 3  Short offline       Completed: read failure       10%      5901         656821791
Nov 15 06:49:45 umbilo smartd[2827]: # 4  Short offline       Completed: read failure       90%      5818         651637856
Nov 15 06:49:45 umbilo smartd[2827]:

Então eu fui verificar os gráficos do Cacti para os discos na matriz. Aqui vemos que, sim, o disco 7 está escorrendo como o syslog diz. Mas também vemos que o SMART Read Erros do disco 8 está flutuando.

Não há mensagens sobre o disco 8 no syslog. Mais interessante é que os valores flutuantes do disco 8 se correlacionam diretamente com os altos tempos de espera de IO! Minha interpretação é a seguinte:

• O disco 8 está passando por uma falha estranha de hardware que resulta em tempos de operação longos e intermitentes.
• De alguma forma, essa condição de falha no disco está bloqueando toda a matriz

Talvez exista uma descrição mais precisa ou correta, mas o resultado líquido é que o disco afeta o desempenho de toda a matriz.

A (s) pergunta (s)

• Como um único disco em uma matriz SATA RAID-10 de hardware pode levar a matriz inteira a uma parada brusca?
• Estou sendo ingênuo em pensar que a placa RAID deveria ter lidado com isso?
• Como posso impedir que um único disco com comportamento inadequado influencie toda a matriz?
• Estou sentindo falta de algo?

Answer 1

Eu odeio dizer "não use SATA" em ambientes de produção críticos, mas eu já vi essa situação com bastante frequência. As unidades SATA geralmente não são destinadas ao ciclo de serviço que você descreve, embora você tenha especificado unidades específicas para 24x7. operação em sua configuração. Minha experiência tem sido que os discos SATA podem falhar de formas imprevisíveis, muitas vezes afetando todo o storage array, mesmo quando você usa o RAID 1 + 0, como você fez. Às vezes, as unidades falham de uma maneira que pode parar o barramento inteiro. Uma coisa a notar é se você está usando expansores SAS em sua configuração. Isso pode fazer diferença em como os discos restantes são afetados por uma falha na unidade.

Mas pode ter sido mais sensato seguir com os drives SAS midline / nearline (7200 RPM) versus SATA . Há um pequeno prêmio de preço sobre o SATA, mas os drives operam / falham de maneira mais previsível. A correção de erros e o relatório na interface / protocolo SAS são mais robustos que o conjunto SATA. Portanto, mesmo com as unidades cuja mecânica é a mesma , a diferença do protocolo SAS pode ter evitado a dor que você sentiu durante a falha do seu drive.

    

Answer 2

Como um único disco pode derrubar o array? A resposta é que não deveria, mas depende do que está causando a interrupção. Se o disco fosse morrer de uma maneira que se comportasse, ele não deveria derrubá-lo. Mas é possível que ele esteja falhando de uma forma que o controlador não pode manipular.

Você é ingênuo para pensar que isso não deveria acontecer? Não, eu não penso assim. Uma placa RAID de hardware como essa deveria ter lidado com a maioria dos problemas.

Como evitar isso? Você não pode antecipar casos estranhos como este. Isso faz parte de ser um administrador de sistema ... mas você pode trabalhar em procedimentos de recuperação para impedir que ele cause impacto em seus negócios. A única maneira de tentar corrigir isso agora é tentar outra placa de hardware (provavelmente não o que você gostaria de fazer) ou alterar suas unidades para unidades SAS em vez de SATA para ver se o SAS é mais robusto. Você também pode entrar em contato com seu fornecedor do cartão RAID, contar o que aconteceu e ver o que eles dizem; Afinal de contas, eles são uma empresa que deveria especializar-se em conhecer os meandros da eletrónica incómoda. Eles podem ter mais conselhos técnicos sobre como as unidades funcionam, bem como a confiabilidade ... se você conseguir falar com as pessoas certas.

Você perdeu alguma coisa? Se você quiser verificar se a unidade está tendo uma falha de borda, retire-a da matriz. A matriz será degradada, mas você não deve ter mais lentidão e erros estranhos (além do status da matriz degradada). Você está dizendo que agora parece estar funcionando bem, mas se estiver tendo erros de leitura de disco, você deve substituir a unidade enquanto puder. Unidades com alta capacidade às vezes podem ter erros de URE (melhor motivo para não executar o RAID 5, nota lateral) que não aparecem até que outra unidade falhe. E se você está experimentando um caso de borda a partir dessa unidade, não deseja que dados corrompidos sejam migrados para as outras unidades da matriz.

    

Answer 3

Eu não sou um especialista, mas vou dar um tiro no escuro com base na minha experiência com controladores RAID e storage arrays.

Os discos falham de muitas maneiras diferentes. Infelizmente, os discos podem falhar ou estar com defeito, de maneiras em que seu desempenho é seriamente afetado, mas o controlador RAID não vê como uma falha.

Se um disco falhar de maneira óbvia, qualquer software de controlador RAID deve ser muito bom em detectar a falta de resposta do disco, removê-lo do pool e disparar todas as notificações. No entanto, meu palpite sobre o que está acontecendo aqui é que o disco está sofrendo uma falha incomum que, por algum motivo, não está provocando uma falha no lado do controlador. Portanto, quando o controlador está conduzindo um flush de gravação ou uma leitura do disco afetado, está demorando muito para voltar e, por sua vez, está suspendendo todo o I / O operacional e, portanto, o array. Por alguma razão, isso não é suficiente para o controlador RAID ir "ah, disco com falha", provavelmente porque os dados acabam voltando eventualmente.

Meu conselho seria substituir imediatamente o disco com falha. Depois disso, eu daria uma olhada na configuração da sua placa RAID (é 3ware, achei que eles eram muito bons) e descubra o que considera um disco com falha.

P.S. boa ideia importando o SMART em cactos.

    

Answer 4

Você precisa dos recursos de dispositivos de armazenamento de classe empresarial. Especificamente, os discos corporativos WD RE 4 possuem dois recursos necessários para evitar esse comportamento em matrizes RAID. A primeira tecnologia listada abaixo evita que a vibração harmônica rotacional cause desgaste desnecessário nos componentes mecânicos do disco rígido. A segunda tecnologia é o que causou o seu problema, o protocolo SATA não possui esse recurso. Para obter esses recursos, você precisa do SAS e, se insistir em unidades SATA, poderá adquirir placas SAS para SATA Interposer, como a LSISS9252.

Tecnologia RAFF aprimorada Eletrônicos sofisticados monitoram o inversor e corrigem a vibração linear e rotacional em tempo real. O resultado é uma melhoria significativa no desempenho em ambientes de alta vibração em relação à geração anterior de unidades.

TLER (time-limited error recovery) específico para RAID Impede a queda de unidade causada pelos processos estendidos de recuperação de erros do disco rígido comuns às unidades de desktop.

link

Veja também o link abaixo:

link

Veja também: Documento TLER da Western Digital explicando o processo de recuperação de erros em profundidade. Recuperação de Erros Prevenção de Falhas nos Discos Rígidos Serial ATA WD Caviar RAID Edition:

link

    

Answer 5

Apenas um palpite: os discos rígidos são configurados para repetir erros de leitura em vez de relatar um erro. Embora esse seja um comportamento desejável em uma configuração da área de trabalho, ele é contraproducente em um RAID (em que o controlador deve reescrever qualquer setor que falha na leitura dos outros discos, para que a unidade possa remapá-lo).

    

Answer 6

meu tiro no escuro:

• a unidade 7 está falhando. tem algumas janelas de falha onde não está disponível.

• a unidade 8 também possui alguns erros 'mais leves'; corrigido tentando novamente.

• RAID10 é geralmente "um RAID0 de vários pares RAID1", são unidades 7 e 8 membros do mesmo par?

se assim for, então parece que você acertou o caso "não deveria acontecer" de falha de dois discos no mesmo par. quase a única coisa que pode matar um RAID10. infelizmente, isso pode acontecer se todas as suas unidades forem do mesmo lote de remessa, então é mais provável que elas morram simultaneamente.

Acho que durante uma falha na unidade 7, o controlador redirecionou todas as leituras para a unidade 8, portanto, qualquer tentativa de erro causou grandes atrasos que causaram uma avalanche de tarefas congeladas, matando o desempenho por um tempo.

você tem sorte que a unidade 8 não parece estar morta ainda, então você deve ser capaz de consertar sem dataloss.

Eu começaria mudando as duas unidades e não se esqueça de verificar o cabeamento. uma conexão solta pode causar isso e, se não for roteada com firmeza, é mais provável que aconteça em unidades adjacentes. Além disso, algumas placas multiportas possuem vários conectores de duas portas, se a unidade 7 e a unidade 8 estiverem na mesma, pode ser a fonte do seu problema.

    

Answer 7

As placas de interposição SATA são outra solução.

Eu recentemente experimentei exatamente o mesmo destino e encontrei este tópico. O tenor geral é que o protocolo do SAS é mais adequado para o RAID do que o SATA, porque o SATA não possui recursos. É por isso que as mesmas unidades físicas são equipadas com controladores SAS e, em seguida, são vendidas como Nearline SAS.

Pesquisando mais, achei:

link

Estou investigando a atualização de um dos meus armazenamentos com um lote desses. Neste momento, a diferença de preço entre 3 TB SATA vs SAS é de 400% (preço de baunilha, mesma marca, especificações e loja, Alemanha). Obviamente, não posso dizer se essa estratégia funciona bem, mas vale a pena tentar.

Comentários muito bem vindos: -)

    

Answer 8

Eu vi um disco SATA com componentes eletrônicos quebrados travar o firmware de um Areca 12something solidamente, não havia como acessar o BIOS e muito menos inicializar o computador de qualquer mídia até que o disco rígido agressor fosse encontrado retirando os discos em uma forma de pesquisa binária.