Que escala de perda ou corrupção de dados corro o risco de ativar o buffer de gravação em um servidor de arquivos?

Question

Encontrei muitos artigos on-line alertando sobre o risco de perda ou corrupção de dados em unidades com buffer de gravação ativado no caso de perda de energia. No entanto, não encontrei nenhum que realmente se refira à escala do risco.

Estou procurando criar um servidor de arquivos espelhado nos Espaços de Armazenamento no Windows Server 2016 para os propósitos de um pequeno escritório de edição de vídeo. O desempenho é muito importante (daí a consideração do buffer de gravação), e nosso servidor lida principalmente com dois tipos de gravações importantes: Carregar gravações e salvar um arquivo de projeto ou documento.

Isso me leva a imaginar qual seria o pior cenário possível em caso de perda inesperada de energia.

Para fazer upload de material, esperaria que qualquer interrupção no servidor causasse uma falha de rede visível em qualquer transferência de arquivos em andamento. Portanto, a menos que a falha de energia ocorra segundos após a conclusão da parte de rede da transferência de arquivos, eles estarão cientes da necessidade de reiniciar a transferência de arquivos quando o servidor estiver on-line novamente. Como eu ficaria ciente de que o servidor estava inativo, eu poderia avisar o escritório para usar um programa de sincronização para, presumivelmente, substituir quaisquer arquivos corrompidos pelas cópias mestras locais.

Quanto a salvar documentos e arquivos de projeto, a maioria deles deve ser tão pequena a ponto de ter um risco mínimo de estar no buffer no momento da falha. E se esse não fosse o caso, ter autosaves ou uma versão aberta ainda no computador do usuário lhes daria uma segunda chance. O único risco que posso realmente ver é se a falha de energia ocorreu à medida que eles salvaram o e fechou o arquivo, e esse programa não armazenou o autosave.

A minha avaliação é acurada ou desconsiderei alguma coisa? A corrupção nesta situação pode afetar mais dados do que o que estava sendo escrito?

Obrigado

Editar: Devo salientar que não estou particularmente à procura de conclusões sobre o que devo fazer neste cenário. Eu apenas quero entender adequadamente as possibilidades para poder tomar uma decisão informada sobre a realidade desse risco.

As muitas páginas da web que eu li sobre o assunto até agora têm sido frustrantemente ambíguas, particularmente no que diz respeito à diferenciação entre 'write caching' e 'write-cache buffer flushing'.

    

Answer 1

Você precisava distinguir entre o buffer de gravação ativado e o desativado o buffer de liberação . Para entender completamente a diferença, vamos começar do básico.

HDDs e SSDs quase que universalmente têm um cache DRAM privado usado para armazenar e unir rapidamente as gravações recebidas, acelerando muito seu desempenho de gravação. Como referência, considere que um SSD rápido SATA bombeou > 500 MB / s de gravações seqüenciais com seu buffer ativado e apenas ~ 5 MB / s com o buffer desativado. Os HDDs mostram uma degradação de desempenho menos severa, mas ainda assim.

Ao mesmo tempo, se esses caches DRAM privados não forem protegidos contra perda de energia, poderá ocorrer corrupção de dados grave (até a perda de todo o sistema de arquivos). Para evitar esse problema sem destruir totalmente o desempenho, existem algumas possibilidades:

• use unidades com caches de gravação protegidos pelo powerloss (isto é: SSD corporativo e algum disco rígido mecânico habilitado para NV mais recente)
• use um controlador RAID de hardware com cache protegido pelo powerloss, desabilitando o cache DRAM do disco privado
• usa hardware de consumidor barato com cache DRAM desprotegido habilitado, mas emitindo liberações periódicas para garantir consistência no sistema de arquivos (mas não em dados, pois o impacto no desempenho seria muito grande).

Ao usar abordagens semelhantes a software RAID (por exemplo: Linux MDRAID, ZFS, espaços de armazenamento, ecc), você deve nunca desativar os caches de disco, a menos que esteja pronto para pagar um alto desempenho. Em vez disso, sua melhor opção é deixar o cache de gravação ativado e deixar seu sistema de arquivos / SO livre para emitir comandos DRAM sync / flushes sempre que quiser. Dessa maneira, você ganha o aumento de velocidade de desempenho do cache ativado sem arriscar a nuke seu sistema de arquivos inteiro. Observe que os dados do aplicativo não são protegidos automaticamente: qualquer aplicativo que queira garantir a durabilidade dos dados deve emitir o próprio esvaziamento periódico (os bancos de dados são um bom exemplo).

Por outro lado, você deve NUNCA desativar a limpeza do cache DRAM, a menos que você tenha 200% de certeza de que suas unidades / placa RAID tenham um cache de write-back protegido . No entanto, nesse caso, deixar os flushes ativados não causaria grandes danos, já que quase qualquer unidade / cartão recente simplesmente ignora os flushes quando seu cache DRAM protegido está em um estado íntegro.

    

Answer 2

Can corruption in this situation affect more data than that which was being written?

Sim. As gravações podem estar atualizando o próprio sistema de arquivos. O pior caso é a perda de dados em basicamente qualquer arquivo. O aviso é inespecífico porque literalmente tudo pode ser perdido, e o impacto varia dependendo da aplicação.

As horas de recuperação de um evento de perda de dados não prejudicam a produtividade do usuário? Aceite este aviso e não desative a limpeza do buffer do cache de gravação.

Uma solução melhor: obtenha mais e mais rápido armazenamento em estado sólido até obter um desempenho satisfatório.

Editar: para ser claro, estou me referindo à opção mais agressiva "desativar a limpeza do buffer do cache de gravação". "Ativar o cache de gravação", ativado por padrão para muitos tipos de discos internos, geralmente é um compromisso aceitável porque o Windows está tentando esvaziar o buffer e endurecer as gravações.