Existe uma maneira de proteger o SSD da corrupção devido à perda de energia?


15

Temos um grupo de terminais de consumidores com o Linux, um servidor da Web local e o PostgreSQL instalado. Estamos recebendo relatórios de campo de máquinas com problemas e, sob investigação, parece que houve uma queda de energia e agora há algo errado com o disco.

Eu tinha assumido que o problema seria apenas com o banco de dados sendo corrompido ou arquivos com alterações recentes sendo embaralhadas, mas existem outros relatórios estranhos.

  • arquivos com permissões erradas
  • arquivos que se tornaram diretórios (por exemplo, index.phpagora é um diretório)
  • diretórios que se tornaram arquivos
  • arquivos com dados codificados

Há problemas com o banco de dados sendo corrompido, mas isso é algo que eu poderia esperar. O que mais me surpreende são os problemas mais básicos do sistema de arquivos - por exemplo, permissões ou alteração de um arquivo em diretório. Os problemas também estão acontecendo em arquivos que não foram alterados recentemente (por exemplo, o código e a configuração do software).

Isso é "normal" para corrupção de SSD? Originalmente, pensávamos que isso estava acontecendo em alguns SSDs baratos, mas temos isso em uma marca de nome (classe de consumidor).

FWIW, não estamos fazendo o autofsck na inicialização suja (não sei por que, eu sou novo). Temos no-breaks instalados em alguns locais, mas às vezes isso não é feito corretamente etc. Isso deve ser consertado, mas mesmo assim as pessoas podem desligar o terminal de maneira não limpa, etc. - para que não seja à prova de idiotas. O sistema de arquivos é ext4.

A questão: existe alguma coisa que possamos fazer para atenuar o problema no nível do sistema?

Encontrei alguns artigos referentes à desativação do cache de hardware ou à montagem da unidade no modo de sincronização, mas não tenho certeza se isso ajudaria nesse caso (corrupção de metadados e alterações não recentes). Também li uma referência sobre a montagem do sistema de arquivos no modo somente leitura. Não podemos fazer isso porque precisamos escrever, mas poderíamos criar uma partição somente leitura para o código e a configuração, se isso ajudasse.

Este é um exemplo de uma unidade sudo hdparm -i /dev/sda1:

Model=KINGSTON RBU-SMS151S364GG, FwRev=S9FM02.5, SerialNo=<deleted>
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=unknown, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=125045424
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes:  pio0 pio3 pio4
DMA modes:  mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=yes: disabled (255) WriteCache=enabled
Drive conforms to: Unspecified:  ATA/ATAPI-3,4,5,6,7

5
Você pode comprar SSDs melhores. Os SSDs corporativos típicos têm capacitores embutidos para fornecer energia suficiente ao dispositivo para concluir a gravação de dados em andamento no caso de uma falta de energia. O dinheiro que você economiza por não precisar se recuperar de um sistema de arquivos totalmente embaralhado justifica facilmente o modesto custo adicional.
Michael Hampton

1
Bem, ninguém disse que você tinha que substituir todos eles. Mas você pode usar os melhores SSDs para substituições e / ou novas instalações.
Michael Hampton

2
"Não é simples substituí-los todos" - é totalmente. Comece dizendo ao sujeito que toma a decisão de compra que ele é responsável pelo custo devido à negligência e incompetência brutais. Alguém cometeu algum erro substancial por não ser competente na fronteira.
TomTom

7
WriteCache=enabled. Este é um problema enorme. O cache de gravação nunca deve ser ativado em discos rígidos que possuem um banco de dados. Alguns fornecedores, por exemplo, a HP, na verdade, impedem a ativação do cache de gravação no disco rígido por esse motivo.
22818 Greg Askew

3
@Yehosef observe que desativar o cache de gravação no sistema operacional não corrigirá o fato de que sua unidade corrompe os dados com a perda de energia. Por uma questão de maior velocidade e durabilidade, os SSDs de consumo podem não gravar dados na memória não volátil quando você grava em um arquivo e, infelizmente, não há mecanismo de hardware para a unidade levar os dados do cache volátil para o armazenamento não volátil. falha de energia, apenas SSDs corporativos podem fazer isso. Acredite ou não, eu estava em uma situação semelhante em que alguém comprou muitos SSDs de consumo, nosso fornecedor que citou esse hardware não tinha ideia de que isso iria acontecer.
JRH

Respostas:


14

Ao perder energia repentinamente, os SSDs MLC / TLC / QLC têm dois modos de falha:

  • eles perdem as gravações em voo e somente em DRAM;
  • eles podem corromper qualquer dado em repouso armazenado na página inferior da célula NAND que está sendo programada.

A primeira condição de falha é óbvia: sem proteção de energia, todos os dados que não estiverem no armazenamento estável (por exemplo: NAND propriamente dito), mas somente no cache volátil (DRAM) serão perdidos. O mesmo acontece com os discos mecânicos clássicos (e isso por si só pode causar estragos no sistema de arquivos que não emite fsyncs).

A segunda condição de falha é um caso de MLC + SSDs: ao reprogramar o bit de página alta para armazenar novos dados, uma perda inesperada de energia pode destruir / alterar o bit inferior (ou seja: dados confirmados anteriormente ).

A única solução verdadeira e mais óbvia é integrar um cache DRAM protegido contra perda de energia (geralmente usando bateria / supercaps), como sempre feito pelos controladores RAID de ponta; isso, no entanto, aumenta o custo / preço da unidade. As unidades consumidoras normalmente não têm caches protegidos contra perda de energia; em vez disso, eles usam uma variedade de soluções mais econômicas como:

  • cache de gravação parcialmente protegido (ou seja: Crucial M500 / M550 / M600 +);
  • Diário de alterações NAND (por exemplo: unidades Samsung, consulte atributo SMART PoR);
  • regiões especiais SLC / pseudo-SLC NAND para absorver novas gravações sem dados anteriores em risco (por exemplo: Sandisk, Samsung, etc.).

Voltando à sua pergunta: suas unidades Kingstone são ultra baratas, usando um controlador não especificado e basicamente nenhuma especificação pública. Não me surpreende que uma súbita perda de energia tenha corrompido os dados anteriores. Infelizmente, mesmo a desativação do cache DRAM do disco (com a enorme perda de desempenho que ele comanda) não resolverá o seu problema, pois os dados anteriores (por exemplo: dados em repouso) podem e serão corrompidos por perdas de energia inesperadas. Se eles são baseados no antigo controlador Sandforce, até um bloco total de unidades pode ser esperado nas circunstâncias "corretas".

Sugiro fortemente que você revise seu no-break e, a médio prazo, substitua essas unidades antigas.

Uma última observação sobre o PostgreSQL e outros bancos de dados Linux: eles não desabilitam o cache do disco e não devem ser impedidos de fazer isso. Em vez disso, eles emitem fsyncs / FUAs periódicos / necessários para confirmar os dados principais para um armazenamento estável. É assim que as coisas devem ser feitas, a menos que exista uma razão muito convincente (por exemplo, uma unidade que se refira aos ATA FLUSHES / FUAs).

EDIT: se possível, considere migrar para um sistema de arquivos de soma de verificação como ZFS ou BTRFS. No mínimo, considere o XFS, que possui soma de verificação de diário e, ultimamente, mesmo soma de verificação de metadados. Se você for forçado a usar o EXT4, considere ativar o auto-fsck na inicialização (o fsck.ext4 é muito bom em reparar a corrupção).


Excelente resposta. Consulte minha pergunta relacionada serverfault.com/questions/924054/… - se você quiser copiar / adaptar esta resposta, ficarei feliz em fazer o voto positivo / seleção. Parece que desabilitar o cache de gravação ajudaria apenas no primeiro caso. Você tem mais detalhes sobre o segundo modo de falha? Está conectado ao reequilíbrio / coleta de lixo ou apenas à proximidade?
Yehosef

1
@Yehosef Dê uma olhada aqui, na seção "perda de energia": anandtech.com/show/8528/…
shodanshok

1
O problema com qualquer solução de software é que muitos SSDs mentem diretamente para o sistema operacional sobre se os dados são ou não armazenados com segurança ou não, inclusive em resposta aos comandos fsync / FUA. Para unidades corporativas que possuem armazenamento de energia suficiente para concluir a liberação de seu cache quando a energia é cortada, isso não é um problema.
BeowulfNode42

@ BeowulfNode42 Barreiras ATA e FUAs precisam ser respeitados. Enquanto nos dias de IDE / PATA, algumas unidades são falsificadas, hoje em dia qualquer unidade "mentirosa" não é compatível com SATA / SAS e deve ser descartada imediatamente.
shodanshok

e, no entanto, essas unidades não compatíveis são vendidas de qualquer maneira, principalmente no segmento de mercado consumidor.
BeowulfNode42

11

Sim. Não obtenha SSD super barato - qualquer coisa fora do mercado consumidor de baixo custo possui capacitores e proteção total contra perda de energia. A AMD realmente não custa muito mais.


Eles são Kingston - então eu não sei se esses itens são considerados baratos ou se é um lote defeituoso. O maior problema é que as unidades (~ 6k) já estão em campo e a maioria não está falhando (talvez apenas porque não tenham perda de energia). Portanto, substituí-los é um último recurso caro, que ainda não atingimos.
Yehosef 29/07

adicionou informações sobre a unidade à pergunta.
Yehosef 29/07

5
Eles são super baratos. São unidades de usuário final orientadas a preço. Procure por pequenas unidades empresariais. LEIA AS ESPECIFICAÇÕES. Geralmente, a proteção contra falha de energia é algo que está na especificação.
TomTom

1
Para adicionar ao @TomTom - às vezes, na verdade, não é chamado de proteção contra falha de energia - e às vezes, proteção contra falha de energia não é realmente uma proteção contra falha de energia! Você precisa ler um pouco para cada fabricante e descobrir como eles chamam para sua marca específica de SSDs corporativos. (Olhar, para cada mfr, para white papers que tenha escrito sobre como verdadeiramente superior suas próprias SSDs corporativos são.) E, eu descobri que, pelo menos para compras individuais, ele faz custar um pouco mais. Mas eu não faço compras a granel e poderia ser diferente para quantidades de 100 ou mais, suponho.
Davidbak 30/07/19

3
Pelo que li até agora, esses fabricantes têm os nomes desse recurso como: Kingston = "Pfail" como na série DC400; Samsung = "Proteção contra perda de energia"; Intel = "Proteção de dados aprimorada contra perda de energia"; Sandisk = "Proteção contra perda de dados com proteção contra falha de energia". Não sei o que outros fabricantes chamam, mas é necessária uma leitura aprofundada das folhas de especificações. Observe que também pode ser alcançado com o firmware, se o fabricante fornecer. Se você realmente tiver> 6.000 deles, entraria em contato com a Kingston e explicaria a situação e me ofereceria para pagar pelo firmware por unidade.
BeowulfNode42

7

A primeira coisa a fazer é definir o tempo de recuperação e os objetivos do ponto de recuperação. Quanto tempo você tem para recuperar um desses terminais e qual ponto de dados no tempo é aceitável? Talvez em algumas horas você precise recuperar o backup da semana passada.

Todos os tipos de coisas estranhas podem acontecer aos arquivos se as gravações em voo forem perdidas. A prioridade do sistema de arquivos é manter sua própria consistência de metadados; eles podem não fornecer as mesmas garantias para seus dados. Em outras palavras, fscknão é garantido recuperar seus dados. Seu trabalho é obter um sistema de arquivos que será montado.

Então, poder. Instale, configure e teste se o no-break desligará o sistema normalmente. Isso permite que os caches do sistema de arquivos e as próprias unidades gravem.

E durabilidade das gravações nos discos. Leia o capítulo de confiabilidade do PostgreSQL . Use o diskchecker.plscript vinculado lá para fazer um teste de falha e determinar se os SSDs estão mentindo sobre se as gravações chegaram ao armazenamento não volátil. Se houver perda, considere a substituição por SSDs que possuem proteção contra perda de energia.

Editar: você adicionou detalhes de que o cache de gravação foi ativado. Você pode tentar desativar isso: hdparm -W0 /dev/sdaou o comando apropriado para uma matriz de hardware. Referência: Guia de administração de armazenamento RHEL .

As barreiras de gravação do sistema de arquivos impõem uma ordem de confirmações do diário. Não é uma garantia que os dados estejam intactos, mas é mais seguro para o sistema de arquivos com um cache volátil. Embora seja o padrão, adicionar a opção de montagem "barreira" documenta claramente que você valoriza a consistência sobre o desempenho.

Finalmente, a última linha de defesa. Faça um teste de restauração para garantir que você possa obter seu aplicativo e banco de dados no momento desejado. Isso é útil para todos os tipos de perda de dados, não apenas para falta de energia.


Esse cache de gravação em disco é a resposta provável. Por alguma razão desconhecida, parece que o Postgres não desativa o cache de gravação em disco, que é uma configuração padrão terrível.
Greg Askew

1
Para esclarecer - temos backups diários e estamos sincronizando os dados com a nuvem, portanto o problema está menos conectado à perda de dados do Postgres (é uma preocupação, mas acho que existem opções de configuração de PG que podem ajudar). O problema mais preocupante é o fato de a máquina se tornar inutilizável, conectada à estranheza dos metadados. FWIW, geralmente a máquina é inicializada e podemos nos conectar a ela, mas o aplicativo falha porque seus arquivos foram embaralhados.
Yehosef 29/07

1
"parece que o Postgres não desativa o cache de gravação em disco, que é uma péssima configuração padrão." @GregAskew Demonstre como desativar o cache da DRAM no SSD do co-consumidor. Não pode ser desativado.
TomTom

4
Por causa da maneira como o SSD funciona. Sem cache de gravação, você queimaria o SSD muito mais rapidamente. As células SSD são grandes e sempre precisam ser completamente gravadas - portanto, a capacidade de combinar várias gravações pequenas é crucial para a vida útil do SSD. É por isso que você NÃO PODE desabilitá-lo em unidades consumidoras (as unidades mentem ou não permitem) E NÃO pode fazê-lo em unidades empresariais (as unidades basicamente podem mentir por não serem voláteis - elas têm reservas de energia suficientes para escrever a nota dramática. fora a piscar.
TomTom

3
@Yehosef Não, nem mesmo o Postgres confiável tem o poder da magia de recuperar se enviar dados para a unidade, a unidade diz “Bom, obteve seus dados” e, em seguida, a unidade nunca conseguiu gravar esses dados a partir de seu volátil temporário interno cache para o armazenamento não volátil real. É crucial usar apenas armazenamento de qualidade empresarial onde a unidade de unidade ou invasão tem seu cache interno suportado por bateria ou capacitor. O Postgres possui recursos (arquivo WAL, etc.) para proteger você contra a perda de dados ainda não enviados para a unidade, mas o Postgres não pode recuperar dados perdidos dentro da unidade.
Basil Bourque
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.