O Linux Software Raid executa checkarray no primeiro domingo do mês? Por quê?

4

Parece que o Debian tem um padrão para executar checkarray no primeiro domingo do mês.

Isso causa grandes problemas de desempenho e uso pesado de disco por 12 horas no meu espelho de 2 TB. Fazer isso "apenas no caso" é bizarro para mim. Descobrir dados fora de sincronia entre os dois discos sem quorum seria uma falha de qualquer maneira.

Esta verificação maciça só poderia me dizer que eu tenho uma falha de unidade irrecuperável e dados corrompidos. O que é bom , mas não é tão útil. É necessário ?

Dado que não tenho erros de disco e não há razão para acreditar que meus discos falharam, por que essa verificação é necessária? Devo tirá-lo do meu cron?

/etc/cron.d# tail -1 /etc/cron.d/mdadm
57 0 * * 0 root [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ] && /usr/share/mdadm/checkarray --cron --all --quiet

Obrigado por qualquer ideia,

    
por mgjk 07.11.2010 / 15:20

4 respostas

3

Como parece que você está executando o RAID1, concordo que não é necessário verificar a sua situação, mas discordo de algumas das razões dadas pelo primeiro respondente.

1) O RAID é uma solução UPTIME / ACCESS SPEED, não uma solução de backup. Ter o RAID falhando não deve significar perda de dados, pois você não deveria usá-lo para isso.

2) Estou curioso porque você acha que o espelhamento de todo o disco é "Ineficiente". Por que adicionar complexidade e ter que confiar no computador não faltando algo quando você pode apenas espelhar tudo?

3) "Arriscado porque em caso de falhas de disco, a reconstrução de um espelho ou disco de paridade para matrizes grandes e ativas pode levar dias - nesse intervalo, se outro disco de matriz degradada falhar, isso significa perda de dados." Ao contrário do que, mantendo tudo em um único disco? O RAID não é perfeito, mas significa que você pode sobreviver a uma unidade inteira morrendo sem perder o acesso aos seus dados e pode REABILTAR sem perder o acesso aos seus dados. Além disso, em qualquer coisa diferente de RAID1, o teste periódico pode detectar uma unidade que está se tornando ruim (controla as falhas de bloqueio individuais de uma unidade específica e também usa dados SMART) e pode sinalizá-la como falha ANTES de perder o acesso à dados. A falha imediata e catastrófica do disco não é o único cenário de perda de dados.

    
por 07.11.2010 / 17:47
3

Verificar um RAID1 ainda faz sentido, e fazê-lo regularmente deve manter seus dados significativamente mais seguros.

Isso parece contra-intuitivo, até que você se aprofunde em como as unidades tendem a falhar. Concordo que, se os dois discos estiverem fora de sincronia, a verificação não fará nenhum bem. Mas e se um dos discos tiver um setor que falhou recentemente? Bem, a leitura dessa unidade durante a verificação produzirá um erro de leitura para essa unidade, correto? Esta é uma informação valiosa para o driver RAID, porque ele sabe das informações espelhadas armazenadas na segunda unidade o que deve ser armazenado no setor com falha. Assim, o driver RAID tentará agora reescrever o setor com falha (mesmo no modo de verificação, que usuários inexperientes supõem ser somente leitura). Essa reescrita pode funcionar ou não, mas os discos modernos têm setores sobressalentes que substituirão um setor com falha na gravação (e não após uma leitura - uma leitura relatará apenas uma falha de leitura). Assim, por uma combinação do driver RAID reescrevendo o setor, e o disco rígido realocando um setor reserva para o fracassado, o array RAID está sendo corrigido na hora. O driver RAID realmente não sabe (e não precisa saber) que a realocação ocorreu. Isso é feito dentro da própria unidade e, se configurado corretamente (consulte smartctl), o sistema operacional pode enviar um email para o administrador para informar que um setor foi realocado, o que significa que é hora de substituir o disco que está falhando lentamente. Discos grandes modernos têm uma tendência a produzir esses erros de leitura do "setor pendente", por exemplo, devido a flutuações de temperatura. Usá-los em uma matriz RAID melhorará significativamente a confiabilidade, e a execução de verificações regulares garantirá que setores questionáveis sejam atualizados automaticamente quando tiverem problemas de leitura. Essas gravações de atualização podem, na verdade, resultar em uma operação de gravação bem-sucedida no setor, caso em que um "setor pendente" não se torna um "setor realocado" ou, em outras palavras, o disco não é realmente ruim porque pode escreva o setor agora.

De qualquer forma, usando o smartctl e fazendo verificações regulares, você manterá sua matriz RAID muito mais confiável. Os comentários sobre zfs (por exemplo, zfs3 ou z3) também são importantes. À medida que os tamanhos das unidades aumentam, e como as informações são escritas mais densamente e a engenharia das unidades é mais direcionada pelos mercados de consumo em vez dos mercados de servidores, o risco geral de perda de dados por unidade de armazenamento aumenta drasticamente. A execução de um RAID5 em unidades de vários TB em tamanho é arriscado, devido aos longos tempos de reconstrução e à necessidade de ler extensivamente a partir de todas as outras unidades durante uma reconstrução. Considere um RAID6 com duas peças sobressalentes se você quiser se proteger contra a frequência de falhas catastróficas de perda de dados (sim, é apenas a probabilidade, e você precisa considerar outros fatores também, como falhas do controlador, falta de energia ... muito você tem que fazer para equilibrar a confiabilidade de muitos componentes diferentes). E mesmo o RAID6 pode ser centenas de vezes menos confiável do que ter três unidades de paridade, como em RAIDZ e / ou Z3.

    
por 11.04.2014 / 05:26
2

O fato de o pacote mdadm do Debian facilitar a desativação do checkarray mensal sugere que ele não é realmente crítico. Aqui está a mensagem relevante que você recebe de dpkg-reconfigure mdadm :

If the kernel supports it (versions greater than 2.6.14), mdadm can periodically check the redundancy of MD arrays (RAIDs). This may be a resource-intensive process, depending on the local setup, but it could help prevent rare cases of data loss. Note that this is a read-only check unless errors are found; if errors are found, mdadm will try to correct them, which may result in write access to the media.

Pessoalmente, não tenho um problema com o script checkarray sendo executado uma vez por mês no meu espelho de 1TB (um servidor de arquivos simples), já que leva menos de 3.5 horas em um domingo de manhã, enquanto nada mais acontece. Nos casos em que o checkarray está causando problemas de desempenho perceptíveis, eu não hesitaria em desativá-lo ou, quem sabe, programá-lo para que ele seja executado com menos frequência (por exemplo, a cada 6 meses, durante determinados feriados, etc.).

    
por 07.11.2010 / 17:47
2

Concordo zfs & O btrfs parece uma solução interessante comparado ao mdadm RAID5 normal (em algumas situações).

Mas ...

  • O btrfs não possui uma versão estável. você realmente quer arriscar esse?
  • O
  • zfs parece maduro - mas a solução para sistemas Linux ... é um pouco irregular. FUSÍVEL? Módulos de kernel nativo de terceiros?

Eu digo ficar com suporte nativo - no LVM2 no mdadm RAID1 / 5/6 ...

meus dois centavos.

    
por 02.01.2011 / 04:58