Recentemente, examinei sistemas de arquivos avançados (Btrfs, ZFS) para redundância e disponibilidade de dados e fiquei interessado na funcionalidade adicional que eles fornecem, especialmente seus recursos de "auto-recuperaçã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 e disponibilidade do ZFS e impacto no desempenho) para uso doméstico geral/SMB, em comparação com um mdadm-Raid1 + convencional Solução Ext4. Um backup espelhado está disponível de qualquer maneira.
Vamos supor que eu tenha alguns servidores de arquivos que são usados para fins de arquivamento e têm recursos limitados, mas memória ECC e uma fonte de energia estável.
- Qual a probabilidade de eu encontrar corrupção de dados real, tornando os arquivos ilegíveis? Como?
- O Ext4 ou o gerenciador de arquivos do sistema já detectam erros de dados nas operações de copiar/mover, deixando-me pelo menos ciente de um problema?
- O que acontece se uma das unidades madam-Raid1 mantiver dados diferentes devido a uma unidade com setores defeituosos? Ainda poderei recuperar o arquivo correto ou o array não conseguirá decidir qual arquivo é o correto e o perderá completamente?
Sim, um sistema de arquivos com soma de verificação funcional é uma coisa muito boa. No entanto, a verdadeira motivação não se encontra no mítico "bitrot" que, embora aconteça , é muito raro. Em vez disso, a principal vantagem é que esse sistema de arquivos fornece uma soma de verificação de dados de ponta a ponta , protegendo ativamente você por comportamento errôneo do disco, como gravações mal direcionadas e corrupção de dados relacionada à falha do próprio cache DRAM privado do disco e/ou mau comportamento devido à fonte de alimentação problema.
Eu experimentei esse problema em primeira mão, quando uma matriz Linux RAID 1 ficou ruim devido a um problema na fonte de alimentação. O cache de um disco começou a corromper os dados e o ECC embutido nos próprios setores do 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 os danos; no entanto, alguns arquivos/diretórios estavam irremediavelmente corrompidos. Como esta era uma máquina de backup que não enfrentava nenhuma pressão imediata de tempo de inatividade, eu a reconstruí com o ZFS. Quando o problema voltou a ocorrer, durante a primeira depuração, 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 a pena notar que a soma de verificação de dados é tão valiosa que um mapeador de dispositivos para fornecê-la (emulando as especificações T-10 DIF/DIX), chamado dm-integrity , 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ê tem um ponto que qualquer vantagem potencial trazida por tal sistema de arquivos deve ser comparada à desvantagem que eles herdam. O principal problema do ZFS é que ele não é integrado ao kernel padrão, mas, por outro lado, é muito rápido e estável. Por outro lado, o BTRFS, embora em linha principal, tem muitos problemas importantes e problemas de desempenho (a sugestão comum para bancos de dados ou VMs é desabilitar o CoW que, por sua vez, desabilitou a soma de verificação - o que, francamente, não é uma resposta aceitável). Em vez de usar o BTRFS, eu usaria o XFS e esperaria o melhor, ou usaria dispositivos protegidos por dm-integrity.
Eu tinha um HDD Seagate que começava a falhar nas somas de verificação toda vez que eu estava executando o zfs scrub. Ele falhou depois de algumas semanas. ZFS e Btrfs têm somas de verificação para dados e metadados. ext4 tem apenas chcksums de metadados.
Apenas erros de CRC e erros de soma de verificação de metadados. A corrupção de dados pode acontecer.
Se tiver setores defeituosos, não é um problema. O disco inteiro será "falhou", mas você tem o outro disco que está "bem". O problema é quando os dados têm CRC correto, mas os dados estão corrompidos. Isso pode acontecer aleatoriamente devido a discos grandes.
Eu tenho usado o ZFS em produção, tanto para servidores quanto para um NAS de escritório doméstico, tanto no Linux quanto no FreeBSD, há mais de 6 anos. Descobri que é estável, rápido, confiável e pessoalmente o vi detectar e (quando possível) corrigir erros que um
md
dispositivo ou sistema deext4
arquivos simples não seria capaz de fazer.Em relação ao licenciamento, o ZFS é de código aberto, apenas 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 está em um estado de "limbo de licença por um tempo" nem significa que há qualquer incompatibilidade técnica . Significa simplesmente que a fonte do kernel linux principal não possui os módulos e eles precisam ser recuperados de algum lugar como https://zfsonlinux.org . Observe que algumas distribuições, 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 do ZFS de RAM para mim, está próximo de ext4 a ultrapassar ext4, dependendo da memória, do espaço disponível no pool e da compactação dos dados. A maior desvantagem do ZFS, na minha opinião, é 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 muito simplificada; há muitas informações on-line sobre os requisitos de memória para o ZFS. Eu pessoalmente corro um pool de 10 TB e um pool de 800 GB, juntamente com alguns pools de backup em um sistema linux de escritório doméstico com 32 GB de 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 autorrecuperação; seus instantâneos poderosos são muito melhores do que os instantâneos LVM e sua compactação lz4 inline pode realmente melhorar o desempenho reduzindo as gravações de disco. Pessoalmente, consigo 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 ZFS diminui quando o pool atinge 75% ou 80% de uso. Contanto que você permaneça abaixo desse ponto, o desempenho deve ser mais do que suficiente para uso doméstico geral/SMB.
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 incorreto. Eu também tenho memória ECC e uso um UPS, então não acredito que os dados tenham sido corrompidos na RAM. Na verdade, você precisa de RAM ECC para obter os benefícios das somas de verificação ZFS. No entanto, eu vi um punhado (~ 10-15) casos de blocos que falharam nas somas de verificação nos últimos 6 anos. Uma grande vantagem do ZFS sobre um md RAID é que o ZFS sabe quais arquivos são afetados por um erro de checksum . Portanto, nos casos em que um pool de backup sem redundância teve um erro de soma de verificação, o ZFS me informou os arquivos exatos que foram afetados, permitindo que eu substituísse esses arquivos.
Apesar da licença que o ZFS usa não ser compatível com o kernel 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 é simples. Apesar de muitas pessoas citarem o medo da perda total de dados com o ZFS na Internet, nunca perdi nenhum dado desde que mudei para o ZFS, e a combinação de instantâneos do ZFS e somas de verificação/redundância de dados pessoalmente me salvou de experimentar perda de dados várias vezes. É uma vitória clara e eu pessoalmente nunca vou voltar a uma
md
matriz.Com tempo suficiente, é quase certo que isso aconteça. Coincidentemente, aconteceu comigo semana passada. Meu servidor de arquivos doméstico desenvolveu alguma RAM ruim que estava causando travamentos periódicos. Eventualmente, decidi simplesmente aposentar a máquina (que estava ficando bastante antiga) e mudei as unidades para um gabinete em uma máquina diferente. A limpeza pós-importação encontrou e reparou 15 blocos com erros de soma de verificação, de um pool de 8 TB, que provavelmente foram causados por RAM ruim e/ou travamentos. Os próprios discos tinham um atestado de integridade da SMART e testaram bem em uma limpeza subsequente.
Não, na verdade não. Pode haver somas de verificação no nível do aplicativo em alguns formatos de arquivo, mas, por outro lado, nada está de olho no tipo de corrupção que aconteceu no meu caso.
Se você sabe definitivamente que uma unidade está com defeito, você pode deixar essa unidade fora do array e servir todas as leituras da unidade boa (ou, mais sensatamente, substituir a unidade defeituosa, que copiará os dados da unidade boa para a unidade de substituição). ). Mas se os dados nas unidades forem diferentes devido a inversões aleatórias de bits na gravação (o tipo de coisa que aconteceu comigo e com o shodanshok), não há uma maneira definitiva de escolher qual dos dois está correto sem uma soma de verificação.
Além disso, o md geralmente não notará que duas unidades em um espelho estão fora de sincronia durante a operação normal - ele direcionará as leituras para um disco ou outro da maneira que for obter o resultado mais rápido. Existe uma função 'check' que irá ler ambos os lados de um par de espelhos e reportar incompatibilidades, mas somente se você executá-la, ou se sua distribuição estiver configurada para executá-la periodicamente e relatar os resultados.
Posso acrescentar que o ZFS é incrivelmente robusto, principalmente graças às suas origens (foi desenvolvido pela Sun Microsystems em 2001). A versão de código aberto atualmente disponível é um fork 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 a fonte ZFS após adquirir a Sun Microsystems.
A própria Oracle ainda mantém uma versão de código fechado do ZFS que é usada em seus sistemas de armazenamento corporativo.
O ZFS tem um pouco de curva de aprendizado, pois é bastante poderoso, há muitas coisas que podem ser ajustadas. Também é 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 copiar os dados de volta. No ZFS, você anexa seu armazenamento secundário e copia o pool com um comando, reconfigura o array como desejar e copie o pool de volta com outro comando.
Porém, existem algumas pegadinhas:
Para iniciantes e ambientes domésticos, geralmente recomendo o FreeNAS, é muito bem conservado e simples de configurar, o que é bom para um iniciante.
Obviamente, dado o tempo infinito, você certamente o encontrará.
Realisticamente, porém, ainda é bastante provável, a menos que você tenha um hardware de nível empresarial muito caro e, mesmo assim, não é muito improvável.
Mais provavelmente, você acabará 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 de arquivo do que em metadados de arquivo). Quando isso acontece, você pode obter todos os tipos de comportamentos estranhos, como se tivesse hardware ruim (embora geralmente seja mais consistente e localizado do que hardware ruim). Se você tiver sorte, são alguns dados não críticos que são corrompidos e você pode facilmente descobrir coisas. Se você não tiver sorte, precisará reconstruir o sistema do zero. Se você está realmenteazar, você acabou de encontrar um erro que fez com que você falisse porque ele atingiu dados críticos em um sistema de produção e seu serviço agora está inativo enquanto você reconstrói tudo do zero e tenta colocar o banco de dados de volta do jeito que deveria ser.
Resposta curta, a corrupção de dados é provável o suficiente para que até mesmo os usuários domésticos devam se preocupar com isso.
Ext4 é notoriamente ruim neste ponto. O comportamento padrão deles ao executar um erro de consistência interna é 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 pegará tudo, as coisas simplesmente darão errado de maneiras estranhas.
Para obter algo mais, você precisa que o sistema de arquivos verifique suas próprias estruturas de dados internas com somas de verificação, códigos de correção de erros, codificação de eliminação ou alguma abordagem semelhante. Mesmo assim, a menos que faça o mesmo para dados de arquivos, você ainda corre um risco não negligenciável de perda de dados.
Depende do nível do RAID, da implementação exata do RAID e se você o definiu ou não para recuperação automática. Supondo que você tenha a recuperação automática em:
Para RAID1 e RAID10:
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 dos dispositivos restantes, se possível, ou a matriz é efetivamente perdida. O ZFS e o BTRFS neste caso apenas fornecem 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 que você escolha facilmente o 'correto', eles funcionam completamente, falham completamente ou retornam dados bons ou ruins alternadamente para a região fora de sincronia.
Para completar, gostaria de mencionar https://bcachefs.org , que reconhecidamente 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 seu sistema B-tree.
O desenvolvedor solitário trabalha em tempo integral, patrocinado via Patreon, e tem um forte foco na confiabilidade.
Não para os fracos de coração no momento, mas à medida que este comentário envelhece, os bcachefs devem melhorar :)