it-swarm-pt.tech

Qual é o benefício dos sistemas de arquivos auto-reparáveis ​​para uso geral?

Recentemente, analisei sistemas de arquivos avançados (Btrfs, ZFS) em busca de redundância e disponibilidade de dados e me interessei pela funcionalidade adicional que eles fornecem, especialmente pelos recursos de "autocorreção" contra corrupção de dados.

No entanto, acho que preciso dar um passo atrás e tentar entender se esse benefício supera suas desvantagens (bugs do Btrfs e problemas não resolvidos, disponibilidade do ZFS e impacto no desempenho) para uso doméstico/SMB em geral, em comparação com o mdadm-Raid1 + convencional Solução Ext4. Um backup espelhado está disponível de qualquer maneira.

Vamos supor que eu tenho alguns servidores de arquivos usados ​​para fins de arquivamento e com recursos limitados, mas memória ECC e uma fonte de energia estável.

  1. Qual a probabilidade de eu encontrar corrupção de dados real, tornando os arquivos ilegíveis? Quão?
  2. O Ext4 ou o gerenciador de arquivos do sistema já pode detectar erros de dados nas operações de copiar/mover, deixando-me pelo menos ciente de um problema?
  3. O que acontece se uma das unidades madam-Raid1 possui dados diferentes devido a uma unidade ter setores defeituosos? Ainda poderei recuperar o arquivo correto ou a matriz não poderá decidir qual arquivo é o correto e perdê-lo totalmente?
29
Prototype700

Sim, um sistema de arquivos funcional com soma de verificação é uma coisa muito boa. No entanto, a verdadeira motivação não pode ser encontrada no mítico "bitrot" que, enquanto acontece acontece, é muito raro. Em vez disso, a principal vantagem é que esse sistema de arquivos fornece e soma de verificação de dados de ponta a ponta , protegendo-o ativamente pelo comportamento incorreto do disco, como gravações e dados mal direcionados corrupção relacionada ao cache DRAM particular do disco falhar e/ou se comportar mal devido a um problema de fonte de alimentação.

Eu experimentei esse problema em primeira mão, quando um array RAID 1 do Linux ficou ruim devido a um problema de fonte de alimentação. O cache de um disco começou a corromper os dados e o ECC incorporado nos próprios setores de disco não pegou nada, simplesmente porque os dados gravados já estavam corrompidos e o ECC foi calculado nos próprios dados corrompidos.

Graças ao seu diário de soma de verificação, que detectou algo estranho e suspendeu o sistema de arquivos, o XFS limitou o dano; no entanto, alguns arquivos/diretórios foram irremediavelmente corrompidos. Como se tratava de uma máquina de backup sem nenhuma pressão imediata de inatividade, eu a reconstruí com o ZFS. Quando o problema voltou a ocorrer, durante a primeira limpeza, o ZFS corrigiu o bloco afetado lendo as cópias boas dos outros discos. Resultado: sem perda de dados e sem tempo de inatividade. Estas são duas boas razões para usar um sistema de arquivos de soma de verificação.

Vale ressaltar que a soma de verificação de dados é tão valiosa que um mapeador de dispositivo alvo para fornecê-la (emulando as especificações T-10 DIF/DIX), chamado dm-integridade , foi desenvolvido precisamente para estender essa proteção a dispositivos de bloco clássicos (especialmente os redundantes como RAID1/5/6). Em virtude do projeto Stratis , ele será integrado a uma CLI/API de gerenciamento abrangente.

No entanto, você acredita que qualquer vantagem potencial trazida por esse sistema de arquivos deve ser comparada à desvantagem que eles herdam. O principal problema do ZFS é que ele não é incorporado ao kernel padrão, mas, por outro lado, é muito rápido e estável. Por outro lado, o BTRFS, embora destacado, tem muitos problemas importantes e problema de desempenho (a sugestão comum para bancos de dados ou VMs é desativar o CoW, que, por sua vez, desabilitou a soma de verificação - o que, francamente, não é um resposta aceitável). Em vez de usar o BTRFS, eu usaria o XFS e esperaria o melhor, ou usando dispositivos protegidos pela integridade do dm.

27
shodanshok
  1. Eu tinha um disco rígido da Seagate que começou a falhar nas somas de verificação cada vez que executava o zfs scrub. Falhou depois de algumas semanas. O ZFS e o Btrfs possuem somas de verificação para dados e metadados. O ext4 possui apenas chcksums de metadados.

  2. Apenas erros CRC e erros de soma de verificação de metadados. A corrupção de dados pode acontecer.

  3. Se houver setores defeituosos, não há problema. O disco inteiro estará "com falha", mas você tem o outro disco que está "bom". O problema é quando os dados têm CRC correto, mas os dados estão corrompidos. Isso pode acontecer aleatoriamente devido a discos grandes.

10
Mircea Vutcovici

Uso o ZFS na produção, tanto para servidores quanto para um NAS de escritório doméstico, no Linux e no FreeBSD, há mais de 6 anos. Descobri que é estável, rápido, confiável e pessoalmente o vi detectar e (quando capaz) corrigir erros que um simples dispositivo md ou ext4 _ sistema de arquivos não teria sido capaz.

No entanto, acho que preciso dar um passo atrás e tentar entender se esse benefício supera suas desvantagens (bugs do Btrfs e problemas não resolvidos, disponibilidade do ZFS e impacto no desempenho)

Com relação ao licenciamento, o ZFS é de código aberto e acaba de ser lançado sob a licença CDDL, que não é legalmente compatível com a licença GPLv2 sob a qual o kernel Linux é lançado. detalhes aqui . Isso não significa que ele esteja em um estado de "liminar por um tempo", nem significa que haja alguma incompatibilidade técnica . Significa simplesmente que a fonte principal do kernel do linux não possui os módulos e eles precisam ser recuperados de algum lugar como https://zfsonlinux.org . Observe que algumas distros, como o debian, incluem o ZFS em sua distribuição A instalação do ZFS no Debian/Ubuntu normalmente pode ser feita com um único apt comando.

Quanto ao desempenho, dado o desempenho suficiente RAM ZFS para mim é algo entre quase ext4 e superando ext4, dependendo da memória, espaço disponível no pool e compressibilidade dos dados. A maior desvantagem do ZFS, na minha opinião, é uso de memória: se você tiver menos de 16 GiB de RAM para um servidor de produção, convém evitar o ZFS. Essa é uma regra excessivamente simplificada de Existem muitas informações on-line sobre os requisitos de memória para o ZFS. Pessoalmente, eu executo um pool de 10 TB e um pool de 800 GB, juntamente com alguns pools de backup em um sistema linux de escritório em casa com 32 GB RAM e o desempenho é ótimo Este servidor também executa o LXC e possui vários serviços em execução.

Os recursos do ZFS vão muito além dos recursos de soma de verificação de dados e autocorreção; seus snapshots poderosos são muito melhores que os snapshots do LVM e sua compactação lz4 inline pode realmente melhorar o desempenho reduzindo as gravações em disco. Pessoalmente, obtenho uma economia de 1,55x no pool de 10 TB (armazenando 9,76 GiB de dados em apenas 6,3 GiB de espaço em disco)

Na minha experiência, o desempenho do ZPF atende quando o pool atinge 75% ou 80% de uso; portanto, desde que você permaneça abaixo desse ponto, o desempenho deve ser mais do que suficiente para o uso doméstico/SMB em geral.

Nos casos em que vi o ZFS detectar e corrigir dados incorretos, a causa raiz não era clara, mas provavelmente era um bloco de disco defeituoso. Também tenho memória EEC e uso um no-break, então não acredito que os dados estejam corrompidos na RAM. De fato, você precisa de EEC RAM para obter o benefício das somas de verificação do ZFS. No entanto, já vi vários casos (~ 10-15) de blocos que falharam nas somas de verificação nos últimos 6 anos. Uma grande vantagem do ZFS sobre um RAID md é que o ZFS sabe quais arquivos são afetados por um erro de soma de verificação .Por isso, nos casos em que um pool de backup sem redundância possui uma soma de verificação erro, o ZFS me disse os arquivos exatos que foram afetados, permitindo que eu os substituísse.

Apesar da licença que o ZFS usa não ser comparável ao kernel do linux, a instalação dos módulos é muito fácil (pelo menos no Debian) e, uma vez familiarizado com o conjunto de ferramentas, o gerenciamento é direto. Apesar de muitas pessoas citarem o medo de perda total de dados com o ZFS na Internet, eu nunca perdi nenhum dado desde que mudei para o ZFS e a combinação de snapshots e somas de verificação de dados/a redundância pessoalmente me salvou da perda de dados várias vezes. É uma vitória clara e, pessoalmente, nunca voltarei a uma matriz md.

6
Josh

Qual a probabilidade de eu encontrar corrupção de dados real, tornando os arquivos ilegíveis? Quão?

Com tempo suficiente, é quase certo que isso aconteça. Coincidentemente, aconteceu comigo semana passada. Meu servidor de arquivos domésticos desenvolveu alguns RAM ruins que estavam causando bloqueios periódicos. Por fim, decidi simplesmente aposentar a máquina (que estava ficando velha) e mudei as unidades para um gabinete em outra máquina. A limpeza pós-importação localizou e reparou 15 blocos com erros de soma de verificação, em um pool de 8 TB, que provavelmente foram causados ​​pelos RAM ruins e/ou pelos bloqueios. Os próprios discos tinham um atestado de integridade limpo pela SMART e testaram bem em uma limpeza subsequente.

O Ext4 ou o gerenciador de arquivos do sistema já pode detectar erros de dados nas operações de copiar/mover, deixando-me pelo menos ciente de um problema?

Não, na verdade não. Pode haver somas de verificação no nível do aplicativo em alguns formatos de arquivo, mas, caso contrário, nada está atento ao tipo de corrupção que aconteceu no meu caso.

O que acontece se uma das unidades madam-Raid1 possui dados diferentes devido a uma unidade ter setores defeituosos? Ainda poderei recuperar o arquivo correto ou a matriz não poderá decidir qual arquivo é o correto e perdê-lo totalmente?

Se você souber definitivamente que uma unidade está com defeito, poderá falhar nessa unidade e servir todas as leituras da unidade boa (ou, mais sensivelmente, substituir a unidade ruim, que copiará os dados da unidade boa para a substituição) ) Mas se os dados nas unidades diferirem devido a inversões aleatórias de bits na gravação (o tipo de coisa que aconteceu comigo e shodanshok), não há maneira definitiva de escolher qual dos dois está correto sem uma soma de verificação.

Além disso, o md geralmente não aviso que duas unidades em um espelho estão fora de sincronia durante a operação normal - ele direciona as leituras para um disco ou outro da maneira que for obter o resultado mais rápido. Existe uma função 'check' que lê os dois lados de um par de espelhos e relata incompatibilidades, mas apenas se você a executar, ou se sua distribuição estiver configurada para executá-la periodicamente e reportar os resultados.

4
hobbs

Qual a probabilidade de eu encontrar corrupção de dados real, tornando os arquivos ilegíveis? Quão?

Obviamente, dado um tempo infinito, você certamente o encontrará.

Realisticamente, ainda é bastante provável, a menos que você tenha um hardware de nível corporativo muito caro e, mesmo assim, não é muito improvável.

O mais provável é que você acabe encontrando corrupção de dados que apenas altera o conteúdo do arquivo, mas não os torna ilegíveis (a menos que você tenha números insanos de arquivos minúsculos, estatísticas simples significam que é mais provável que você tenha corrupção em dados do arquivo que nos metadados do arquivo). Quando isso acontece, é possível obter todos os tipos de comportamentos estranhos, como se você tivesse um hardware ruim (embora geralmente seja mais consistente e localizado que o hardware ruim). Se você tiver sorte, são alguns dados não críticos que são corrompidos e você pode facilmente encontrar coisas. Se você tiver um azar moderado, precisará reconstruir o sistema do zero. Se você é realmente azarado, você acabou de encontrar um erro que o levou à falência porque atingiu dados críticos em um sistema de produção e seu serviço está inoperante enquanto você reconstrói tudo. arranhe e tente colocar o banco de dados de volta do jeito que deveria ser.

Resposta curta, é provável que a corrupção de dados seja suficiente para que até os usuários domésticos se preocupem com isso.

O Ext4 ou o gerenciador de arquivos do sistema já pode detectar erros de dados nas operações de copiar/mover, deixando-me pelo menos ciente de um problema?

Ext4 é notoriamente ruim nesse ponto. O comportamento padrão deles, ao executar um erro interno de consistência, é marcar o sistema de arquivos para verificação na próxima remontagem e continuar como se nada estivesse errado. Perdi sistemas inteiros no passado por causa desse comportamento.

Mais genericamente, na maioria dos casos, o melhor que você pode esperar de um sistema de arquivos não projetado especificamente para verificar seus dados é remontar somente leitura se ocorrer um erro interno com suas próprias estruturas de dados ou metadados de arquivo. O problema é que, a menos que o sistema de arquivos lide especificamente com a verificação de suas próprias estruturas internas, além de coisas simples, como verificação de limites, isso não vai pegar tudo, as coisas vão dar errado de maneiras estranhas.

Para obter mais alguma coisa, você precisa do sistema de arquivos para verificar suas próprias estruturas de dados internas com somas de verificação, códigos de correção de erros, codificação de apagamento ou alguma abordagem semelhante. Mesmo assim, a menos que faça o mesmo com os dados do arquivo, você ainda corre um risco não negligenciável de perda de dados.

O que acontece se uma das unidades madam-Raid1 reter dados diferentes devido a uma unidade ter setores defeituosos? Ainda poderei recuperar o arquivo correto ou a matriz não poderá decidir qual arquivo é o correto e perdê-lo totalmente?

Depende do nível do RAID, da implementação exata do RAID e se você configurou ou não a recuperação automática. Supondo que você tenha recuperação automática em:

Para RAID1 e RAID10:

  • Com o RAID de hardware e apenas duas réplicas, geralmente escolhe a primeira réplica e sincroniza a matriz com ela.
  • Em alguns sistemas RAID de hardware com mais de duas réplicas, ele verifica se a maioria das réplicas corresponde e, se houver, substitui os que não coincidem com isso.
  • Com o RAID de software, geralmente faz o mesmo que com o RAID de hardware, a menos que haja uma indicação clara de que a discrepância é resultado de uma falha na gravação (nesse caso, ele escolhe a cópia que sabe que foi completamente escrita).
  • Com o BTRFS, ele analisa qual cópia possui uma soma de verificação correta e substitui a que não possui.
  • Acredito que o ZFS funcione como o BTRFS aqui.

Para RAID4/5/6 e outros casos de codificação de apagamento, quase tudo se comporta da mesma forma quando se trata de recuperação, ou os dados são reconstruídos a partir dos dispositivos restantes, se possível, ou a matriz é efetivamente perdida. O ZFS e o BTRFS nesse caso oferecem apenas uma maneira mais rápida (em termos de E/S total) de verificar se os dados estão corretos ou não.

Observe que nenhum deles opera em uma base por arquivo e a maioria não permite escolher facilmente o 'correto'; eles funcionam completamente, falham completamente ou retornam dados bons ou ruins para a região fora de sincronização.

1
Austin Hemmelgarn

Para completar, eu gostaria de mencionar https://bcachefs.org , que ainda não está no kernel, mas o IMHO está programado para suplantar o ZFS e o btrfs assim que o fizer.

É baseado no bcache, que já está no kernel há muito tempo, construindo recursos do sistema de arquivos com o sistema B-tree.

O desenvolvedor solitário trabalha em período integral, patrocinado pelo Patreon, e tem um forte foco na confiabilidade.

Não é para os fracos de coração no momento, mas à medida que esse comentário envelhece, o bcachefs deve melhorar :)

0
w00t

Posso acrescentar que o ZFS é incrivelmente robusto, principalmente devido às suas origens (ele foi desenvolvido pela Sun Microsystems em 2001). A versão de código aberto atualmente disponível é uma bifurcação de uma das últimas versões de código aberto lançadas pela Sun Microsystems há cerca de 10 anos, que foi desenvolvida pela comunidade de código aberto depois que a Oracle fechou o código ZFS após adquirir a Sun Microsystems.

A própria Oracle ainda mantém uma versão de código fechado do ZFS usada em seus sistemas de armazenamento corporativo.

No entanto, o ZFS tem uma curva de aprendizado, pois é bastante poderoso e há muitas coisas que podem ser aprimoradas. Além disso, é um dos poucos sistemas de arquivos de armazenamento em que trabalhei, onde a manutenção é realmente fácil. Eu tive um caso em que um pool precisava ser migrado de uma configuração RAID5 para um RAID6 (ou mais corretamente, um RAID-Z1 para um RAID-Z2). Normalmente, uma operação como essa significaria copiar todos os dados, reconfigurar o RAID e voltar a copiar os dados. No ZFS, você anexa o armazenamento secundário e copia o pool com um comando, reconfigura a matriz como desejar e copie o pool novamente com outro comando.

Existem algumas dicas:

  1. Para obter qualquer benefício do ZFS, você precisará permitir que o ZFS manipule os discos. Portanto, seu controlador de unidade precisa oferecer suporte ao JBOD, para que o ZFS veja os discos diretamente. Todas as configurações de RAID são tratadas no ZFS, pois ele usa os dados de paridade para limpeza e outras tarefas, e não pode ocultá-los por um controlador RAID.
  2. Como outros já declararam, a memória ECC é fortemente recomendada. O ZFS não exige isso, mas espera totalmente que qualquer coisa gravada em RAM seja imutável e não seja corrompida. Portanto, se você executá-lo em um sistema com código não-ECC RAM e sua memória fica ruim, o ZFS pode realmente corromper seus dados enquanto estiver limpando a matriz (a limpeza significa que o ZFS lê dados do pool, calcula o que deveria ter lido das informações de paridade salvas em outras unidades e corrige os erros encontrados).
  3. Embora o ZFS seja excelente na prevenção de perda de dados, seu RAID-Z1 ainda sofre dos mesmos problemas que o RAID5, também conhecido como. que matrizes grandes de unidades grandes (1 TB +) podem falhar completamente após uma única falha no disco ao reconstruir a matriz se a taxa de URE das unidades for muito alta, basta ler todos os dados da paridade do restante das unidades e reconstruir matematicamente quase garante um erro de leitura irrecuperável devido ao tamanho das unidades. Execute o RAID6/RAID-Z2 se você não é especialista em sistemas de armazenamento operacional e sabe o que está fazendo.

Para iniciantes e ambientes domésticos, geralmente recomendo o FreeNAS, é muito bem conservado e simples de configurar, o que é bom para iniciantes.

0
Stuggi