Recentemente li algumas estatísticas alarmantes sobre taxas de corrupção em sistemas com RAM não ECC e sistemas de arquivos típicos. Pelo que posso pesquisar no Google, ter um sistema com RAM ECC rodando ZFS é provavelmente a melhor maneira de prevenir a corrupção. A maior parte dessas informações foi inserida no contexto das discussões sobre NAS.
Posso ver como esse sistema seria útil para arquivar arquivos, presumindo que eles ainda não estejam corrompidos na máquina de origem e sejam transferidos perfeitamente pela rede.
O que não consegui com o Google é o seguinte: qual é o sentido de ter arquivos de hospedagem NAS extremamente confiáveis (ou como backup) quando estou trabalhando com os arquivos em computadores menos confiáveis? Também não consigo encontrar boas informações sobre correção de erros no Samba (qualquer que seja a versão mais recente em um sistema operacional compatível com ZFS, como FreeNAS ou OpenIndiana) - se for propenso a erros, quase todo o resto será inútil (a menos que eu hash tudo pessoalmente e verifique todas as transferências).
Preciso (figurativamente) jogar fora meus sistemas atuais e substituí-los por (mini) hardware de nível de servidor se não quiser me preocupar com apodrecimento de bits e etc.? E se eu seguir esse caminho, poderia razoavelmente esperar ter recursos para qualquer coisa além de executar o ZFS? Sem gastar milhares de dólares?
Meu caso de uso:
Estou preocupado com mais do que apenas a reprodução (por exemplo, de filmes e outras mídias). Freqüentemente faço trabalhos de programação em meus computadores domésticos. Por exemplo, tenho um número cada vez maior de arquivos de banco de dados SQLite para vários projetos. Fazer com que um deles se torne corrupto pode ser um problema. Também tenho muitos gigabytes de fotos de família e de férias que não quero apenas arquivar, mas também organizar, marcar, etc. Portanto, embora não administre um banco, tenho coisas que seriam difíceis de substituir e odeio pensar nisso. eles sendo "corrompidos silenciosamente".
Responder1
O ZFS é bastante exigente quanto ao hardware em que é executado.
Não no sentido de que você precisa ter exatamente o chipset, a placa gráfica, a versão de firmware do disco corretos e assim por diante, mas no sentido dos recursos fornecidos pelo hardware. Lembre-se de que o ZFS foi projetado como uma solução de servidor de ponta e certas suposições feitas refletem isso.
Uma parte importante do que torna o ZFS tão excelente para armazenar dados importantes para você é que você pode configurá-lo de maneira que possa detectare corretoerros no armazenamento. Podem ser erros triviais, como uma única mudança de bit em algum lugar, ou erros catastróficos, como vários discos travando ao mesmo tempo. Contanto que você permaneça acima do limite de redundância do seu layout de armazenamento (por exemplo, não mais do que dois discos apresentando problemas simultaneamente em um vdev raidz2), o ZFS poderá corrigir qualquer erro usando dados redundantes. Outros erros, dependendo de onde e como ocorrem, podem levar a um pânico (semi) gracioso do sistema ou a um simples erro de E/S.
Se você fizer isso corretamente, também configurará seu sistema para limpar o(s) pool(s) ZFS em intervalos regulares. Isso detectará a degradação antes que ela se torne um problema e notificará você sobre isso para que você possa considerar a substituição dos dispositivos de armazenamento que estão tendo problemas para manter seus dados antes que isso se torne um problema.
No entanto, essa grandezadepende do fato de que a RAM pode ser confiável.Toda essa validação, correção, reescrita e assim por diante acontece principalmente na RAM. Em servidores de última geração, você não encontra nada além de RAM ECC.
O ZFS protege (e manipula) metadados de pool, metadados de sistema de arquivos e dados de usuário da mesma maneira.Não há diferença real aqui.
Se o sistema da sua estação de trabalho sofrer uma inversão de bits de RAM, quando você gravar os dados invertidos no ZFS, os dados invertidos serão a base para o que o ZFS eventualmente gravará no disco. Obviamente, isso é ruim, porque significa que seu arquivo estará corrompido. No entanto, os dados invertidos serãocorreto no que diz respeito ao ZFS. Isso é na verdadebom, porque significa que todos os métodos normais de recuperação do ZFS funcionarão. Sim, a cópia mais recente do arquivo em questão estará corrompida, masseria corrupto de qualquer maneira,não importa qual sistema de arquivos você estava usando.Você pode aproveitar os instantâneos do ZFSpara pelo menos poder voltar no tempo para uma cópia não corrompida. Configure algo comozfs-auto-snappara capturar instantâneos de seus sistemas de arquivos em intervalos regulares e próximos, manter um histórico mais grosseiro retrocedendo e esquecê-lo até precisar deles. (Por exemplo, mantenha dez instantâneos com intervalo de dez minutos; 50 instantâneos com intervalo de uma hora; 30 instantâneos com intervalo de seis horas; e assim por diante.) Os instantâneos são praticamente gratuitos no ZFS; se você usa ZFS,usar instantâneostambém.
Se o seu servidor de armazenamento que executa o ZFS apresentar RAM ruim, seja um bit flip ou um bit travado (um ou mais), e você tiver RAM ECC no servidor de armazenamento, isso será detectado e o evento será registrado ou o sistema irá ser interrompido (se o erro não puder ser corrigido). De qualquer forma, a integridade dos dados armazenados no servidor é preservada. Se o seu servidor de armazenamento ZFS tiver RAM não ECC,então um erro pode se propagar por todos os seus dados e metadadosenquanto o ZFS tenta "corrigir" os erros que na verdade são apenas produtos da imaginação do computador. Como pior cenário,o que realmente acontece com as pessoas, todo o seu pool será destruído por causa disso e todos os seus dados desaparecerão. A redundância em nível de armazenamento/vdev também não ajuda aqui. Com a maioria dos outros sistemas de arquivos (sem o comportamento de correção automática), apenas o local que foi diretamente afetado pela inversão de bits será corrompido e, se isso acontecer, os metadados do sistema de arquivos provavelmente serão facilmente corrigidos pelos verificadores e recuperação tradicionais do sistema de arquivos. ferramentas. O ZFS não possui essa saída de emergência;não há fsck.zfs.(Háesfoliante zpool, mas isso não funciona se o pool estiver quebrado sem possibilidade de reparo.)
O que não consegui com o Google é o seguinte: qual é o sentido de ter arquivos de hospedagem NAS extremamente confiáveis (ou como backup) quando estou trabalhando com os arquivos em computadores menos confiáveis?
Isso significa que você tem um repositório de dados confiável.Você sabe que, depois que os dados chegam ao seu NAS, eles estão protegidos contra corrupção. Qualquer corrupção será reparada automaticamente ou você será informado sobre o problema (no caso do ZFS, por meio de um erro de E/S). Os dados ainda podem estar corrompidos enquanto estão sendo trabalhados em sistemas menos confiáveis, mas você terá algum lugar para procurar uma cópia conhecida não corrompida. Isso é uma vantagem mesmo que apenas o sistema NAS tenha ECC RAM, ZFS e monitoramento e alertas de armazenamento de alta qualidade configurados.
Você pode então, se desejar, adicionar (particularmente) RAM ECC ao(s) seu(s) outro(s) sistema(s), conforme seu orçamento permitir, para tapar o último buraco.
Preciso (figurativamente) jogar fora meus sistemas atuais e substituí-los por (mini) hardware de nível de servidor se não quiser me preocupar com apodrecimento de bits e etc.? E se eu seguir esse caminho, poderia razoavelmente esperar ter recursos para qualquer coisa além de executar o ZFS? Sem gastar milhares de dólares?
Primeiro, você realmente não precisa de hardware de nível de servidor.O que você precisa é principalmente de RAM ECC (e uma CPU e controlador/chipset de memória que suporte RAM ECC),armazenamento permanente razoavelmente confiável e, idealmente, um gabinete que facilita a adição e remoção de discos enquanto o sistema está em execução. Isto não precisa ser muito caro e certamente não precisa custar “milhares de dólares”.
Em segundo lugar, o ZFS gosta de RAM, mas principalmente para armazenamento em cache. Com a maioria das cargas de trabalho, 8 a 16 GB de RAM devem ser suficientes, e 24 a 32 GB (facilmente obtidos mesmo com placas-mãe de "consumo") ainda têm um preço razoável, mesmo ao comprar RAM ECC de marca de alta qualidade. O ZFS não consome muita CPU; você pode fazer com que precise de muita CPU (como comZoL, configurando sha256, compactação gzip-9 e possivelmente desduplicação em combinação), mas você não precisa fazer isso. Meu próprio sistema roda ZFS, não é muito potente (CPU FX-6100 com clock baixo), eu uso sha256 em todos os lugares, e mesmo em E/S puramente sequencial, os discos são o fator limitante: uma vez que ultrapassa o pequeno inicial parte de leituras aleatórias do esfregaço, obtenho aproximadamente a mesma taxa de transferência em esfregaços que obtenho em bruto dddo dispositivo de armazenamento subjacente, com CPU de sobra.
Responder2
O que não consegui com o Google é o seguinte: qual é o sentido de ter arquivos de hospedagem NAS extremamente confiáveis (ou como backup) quando estou trabalhando com os arquivos em computadores menos confiáveis?
A chance de algo dar errado é cumulativa.
Em outras palavras (e com números falsos):
se houver 10% de chance de algo dar errado no NAS e
se houver 10% de chance de algo dar errado no outro dispositivo,
então você terá 20% de chance de falha quando lendo algo do NAS e reproduzindo em outro dispositivo.
Também não consigo encontrar boas informações sobre correção de erros no Samba
Qual versão do samba. Os protocolos mudaram bastante entre as três versões.
se estiver sujeito a erros, quase todo o resto será inútil (a menos que eu pessoalmente faça o hash de tudo e verifique todas as transferências).
Sempre existe o risco de erros. Isso simplesmente ocorre. E eles são detectados e corrigidos (por exemplo, por meio de somas de verificação). Isso nem sempre é verdade ao usar RAM, algo que você pode melhorar usando paridade e/ou ECC. No entanto, esses problemas são relativamente improváveis e você precisa encontrar um equilíbrio entre um design folheado a ouro (e caro) e "bom o suficiente".
Este equilíbrio será bastante diferente para alguns de nós (por exemplo, os bancos precisam das coisas perfeitamente). Eles provavelmente não garantem o uso do ECC em sistemas pessoais destinados à reprodução de filmes.
Responder3
A conexão:
Tentei ler a documentação no site do Samba, mas não consegui determinar se o Samba possui correção de erros. Tive que assumir o pior caso - que o Samba depende da rede subjacente para estar livre de erros. Se essa rede subjacente for TCP/IP, parece que a única proteção é uma soma de verificação fraca.
Acabei optando pelo iSCSI porque ele suporta cabeçalhos opcionais e resumos de dados que usam o algoritmo CRC32C. Isso vai além da verificação TCP/IP.
Existe algum benefício?
Para mim a resposta é “Sim, em pelo menos um cenário”. Posso fazer backup de arquivos em uma máquina ZFS de nível de servidor usando um programa em que confio. Então posso verificar periodicamente sesupostamentearquivos não modificados na máquina original sãona verdadenão modificado. Se houver uma discrepância, posso restaurar o backup do servidor.
O único ponto fraco é quando os arquivos estão sendo modificados intencionalmente em máquinas não confiáveis para consumo. Dado que a corrupção durante esses curtos períodos de tempo é tão improvável, considero isso aceitável. Se acontecer de eu descobrir que ocorreu corrupção durante a modificação, terei backups incrementais para recorrer.
Substituir meu computador por um servidor poderoso o suficiente para executar o ZFS e ter os recursos restantes para ser meu computador principal?
Talvez, mas seria extremamente caro. Estou satisfeito com o cenário descrito acima, então não tentarei fazer isso.