Várias vezes em minha carreira, encontrei conjuntos RAID mdadm (RAID1 + 0, 5, 6 etc.) em vários ambientes (por exemplo, caixas CentOS/Debian, NASes Synology/QNAP) que parecem simplesmente incapazes de lidar com falhas no disco. Esse é um disco que não está totalmente morto, mas possui dezenas de milhares de setores defeituosos e é simplesmente incapaz de lidar com E/S. Mas não está totalmente morto, ainda está funcionando. O log do kernel normalmente está cheio de erros UNC.
Às vezes, a SMART identificará o disco como falha, outras vezes não há outros sintomas além de E/S lenta.
A E/S lenta na verdade faz com que todo o sistema congele. A conexão via ssh leva uma eternidade, a webGUI (se for um NAS) para de funcionar normalmente. A execução de comandos sobre ssh também leva uma eternidade. Isso até que eu desconecte / "falhe" propositalmente o disco fora do array, então as coisas voltam ao "normal" - isso é o mais normal possível com um array degradado.
Só estou me perguntando: se um disco está demorando tanto para ler/gravar, por que não simplesmente retirá-lo da matriz, colocar uma mensagem no log e continuar? Parece que todo o sistema está paralisado porque um disco é meio maluco e anula totalmente um dos principais benefícios do uso do RAID (tolerância a falhas - a capacidade de continuar funcionando se um disco falhar). Eu posso entender que em um cenário de disco único (por exemplo, seu sistema tem um único disco SATA conectado e não é capaz de executar leituras/gravações corretamente) isso é catastrófico, mas em um conjunto RAID (especialmente as "personalidades" tolerantes a falhas) isso parece não apenas irritante, mas também contrário ao bom senso.
Existe uma boa razão para o comportamento padrão do mdadm ser basicamente paralisar a caixa até que alguém a acesse remotamente e a conserte manualmente?
Responder1
Em geral, o propósito de umATAQUE, dependendo do nível de Raid escolhido, proporciona um equilíbrio diferente entre os objetivos principais redundância de dados, disponibilidade, desempenhoecapacidade.
Com base nos requisitos específicos, é oresponsabilidade do proprietário do armazenamentodecidir qual o equilíbrio dos vários factores que é o correcto para o objectivo determinado, para criar umaconfiávelsolução.
A função da solução Raid escolhida (aqui neste caso falamos do software mdadm) é garantir, em primeiro lugar, a proteção dos dados. Com isso em mente, fica claro que não é função da solução raid dar maior importância à continuidade dos negócios do que à integridade dos dados.
Em outras palavras: o trabalho do mdadm é evitar uma invasão fracassada. Contanto que um “disco com comportamento estranho” não esteja completamente quebrado, ele ainda contribui para o ataque.
Então, por que não simplesmente retirar do array um disco com comportamento estranho, colocar uma mensagem no log e continuar?Porque isso aumentaria o risco de perda de dados.
Quer dizer, você tem razão, no momento, do ponto de vista empresarial, parece que a melhor solução é continuar. Na realidade, porém, a mensagem que foi descartada no log pode permanecer sem ser detectada, de modo que o estado degradado do ataque permanece sem ser detectado. Algum tempo depois, eventualmente outro disco no mesmo ataque falha e, como resultado, os dados armazenados no ataque com falha acabam.
Além disso: é difícil definir exatamente o que é um "disco com comportamento estranho". Expressado de outra forma: qual ainda é um comportamento operacional aceitável de um único disco, operado dentro de uma matriz de discos?
Alguns de nós podem responder “o disco mostra alguns erros”. Outros poderão responder: “Desde que os erros possam ser corrigidos, está tudo bem”. Outros podem responder: “Desde que o disco responda a todos os comandos em um determinado momento, está tudo bem”. Outros dizem "no caso de a temperatura do disco diferir mais de 5°C em comparação com a temperatura média de todos os discos dentro do mesmo array". Outra resposta poderia ser "desde que uma limpeza não revele erros" ou "desde que o SMART não mostre erros".
O que está escrito não é uma lista longa e também não é completa.
A questão é que a definição de "comportamento aceitável de um disco" é uma questão de interpretação e, portanto, também de responsabilidade do proprietário do armazenamento, e não algo que o mdadm deva decidir por conta própria.
Responder2
O principal problema é que uma unidade de disco SATA com falha pode, às vezes, congelar todo o barramento durante o procedimento de recuperação de erros internos. Por esta razão, deve-se usarHabilitado para TLERunidades apenas em matrizes RAID (e de preferência em um modelo de nível empresarial).
As unidades SAS sofrem menos com esse problema, mas também não estão totalmente livres dele.
Responder3
Além do que foi dito, quero acrescentar meu centavo, mas esta é uma consideração importante.
O queuma viagemfaz quando o setor demora para ler?
Supostamente unidades projetadas para operar sozinhas, por exemplo, unidades típicas de “desktop”, presumem que não há outra maneira de recuperar os dados armazenados naquele setor defeituoso. Eles tentarão recuperar os dados a todo custo, repetindo-os continuamente, por um longo período de tempo. É claro que eles também marcarão esse setor como falho, então o remapearão na próxima vez que você escrever para ele, mas você deve escrever para isso. Até que você o reescreva, eles vão engasgar cada vez que você ler daquele lugar. Em uma configuração RAID, isso significa que para o RAID a unidade ainda funciona e não há razão para expulsá-la, mas para a aplicação o array ficará lento.
Por outro lado, unidades "empresariais", especialmente as de "marca", muitas vezes supõem que são sempre usadas na configuração RAID. Um controlador de "marca", vendo uma unidade de "marca", na verdade pode aténotificarseu firmware sobre a presença do RAID. Portanto, a unidade irá parar mais cedo e reportar erro de E/S, mesmo que tenha sido possível fazer mais algumas tentativas e ler o setor. Então o controlador tem a chance de responder mais rápido, espelhando a instrução de leitura para uma unidade irmã (e expulsando a unidade ruim da matriz). Quando você retira e explora/testa aquele drive acionado completamente, você não encontra problemas aparentes - ele apenas ficou lento por um momento e isso foi o suficiente para parar de usá-lo, de acordo com a lógica do controlador.
Eu especulo que isso pode sera únicadiferença entre unidades "desktop" e unidades NL-SAS e SATA "de marca"/"empresariais". É provavelmente por isso que você paga três vezes mais quando compra uma unidade "HPE", que na verdade foi fabricada pela Toshiba, em comparação com a compra de uma unidade da marca "Toshiba".
No entanto, algumas unidades suportam alguns controles genéricos disso. É chamado SCT ERC que entrega paraControle de recuperação de erros de transporte de comando SMART. É assim que parece smartctl:
sem suporte
# smartctl --all /dev/sda
=== START OF READ SMART DATA SECTION ===
SCT capabilities: (0x3037) SCT Status supported.
SCT Feature Control supported.
SCT Data Table supported.
suportado
=== START OF READ SMART DATA SECTION ===
...
SCT capabilities: (0x003d) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
Se você tiver sorte, poderá controlar esse recurso com o smartctl. Você pode recuperar ou definir dois tempos limite, quanto tempo tentar reler e quanto tempo tentar reescrever:
# smartctl -l scterc /dev/sda
SCT Error Recovery Control:
Read: 70 (7.0 seconds)
Write: 70 (7.0 seconds)
# smartctl -l scterc /dev/sde
SCT Error Recovery Control:
Read: Disabled
Write: Disabled
# smartctl -l scterc /dev/sdd
Warning: device does not support SCT Error Recovery Control command
smartctl -l scterc,120,60 /dev/sde
O que significa: 120 décimos de segundo para tentar ler novamente; 60 décimos de segundo para tentar escrever novamente. Zero significa “tentar novamente até morrer”. Unidades diferentes têm configurações padrão diferentes para isso.
Portanto, se você usar apenas a unidade "RAID edition", é melhor definir os tempos limite do ERC como zero ou você poderá perder dados. Por outro lado, se você usar unidades em RAID, é melhor definir alguma configuração razoavelmente baixa, diferente de zero.
Fonte de amarao @ Habrahabr, em russo.
PS E uma observação sobre o SAS. Use sdparm, ele suporta mais controles disso.
Responder4
Já tive situações em que um disco não funcionou, mas de alguma forma destruiu o controlador.
Historicamente, isso era possível com o PATA, onde as unidades mestre e escrava estavam no mesmo cabo, e a falha de uma unidade poderia interferir no acesso à outra unidade ainda em boas condições. A remoção da unidade defeituosa pode reativar o acesso à unidade restante ou pode ser necessário desligar e ligar a energia, mas o ataque pode ficar degradado e a recuperação pode começar.
SATA é menos vulnerável a isso, mas ainda é possível que o controlador seja afetado. Pela minha experiência em ataques de software, há mais entranhas sangrentas expostas que seriam escondidas por um controlador de ataque dedicado mais sofisticado.
Não experimentei isso com SAS ou NVME, mas SAS geralmente significa controladores raid de hardware que possuem mais inteligência de manipulação de disco internamente.