Como armazenar dados em uma máquina cuja energia é cortada aleatoriamente

Question

Eu tenho uma máquina virtual (Debian) rodando em um host de máquina física. A máquina virtual atua como um buffer para dados que recebe frequentemente na rede local (o período para esses dados é de 0,5s, portanto, um throughput razoavelmente alto). Qualquer dado recebido é armazenado na máquina virtual e repetidamente encaminhado para um servidor externo por UDP. Quando o servidor externo reconhece (por UDP) que recebeu um pacote de dados, os dados originais são excluídos da máquina virtual e não são enviados ao servidor externo novamente. A conexão à Internet que conecta a VM e o servidor externo não é confiável, o que significa que pode estar inativo por dias a fio.

A máquina física que hospeda a VM recebe seu corte de energia várias vezes ao dia aleatoriamente. Não há como saber quando isso está prestes a acontecer e não é possível adicionar um no-break, uma bateria ou uma solução semelhante ao sistema.

Originalmente, os dados eram armazenados em um banco de dados HSQLDB baseado em arquivo na máquina virtual. No entanto, os freqüentes cortes de energia fazem com que o arquivo de script do banco de dados seja corrompido (não no nível do sistema de arquivos, ou seja, é legível, mas o HSQLDB não faz sentido), o que leva à minha pergunta:

Como os dados devem ser armazenados em um ambiente onde cortes de energia podem acontecer com frequência?

Uma opção que posso imaginar é usar arquivos simples, salvando cada pacote de dados como um arquivo no sistema de arquivos. Dessa forma, se um arquivo estiver corrompido devido à perda de energia, ele poderá ser ignorado e o restante dos dados permanecerá intacto. Isso coloca alguns problemas, no entanto, principalmente relacionados à quantidade de dados que provavelmente estão sendo armazenados na máquina virtual. Em 0,5s entre cada dado, 1.728.000 arquivos serão gerados em 10 dias. Isso significa, pelo menos, usar um sistema de arquivos com um número maior de inodes para armazenar esses dados (a configuração atual do sistema de arquivos ficou sem inodes com ~ 250.000 mensagens e 30% de espaço em disco usado). Além disso, é difícil (não impossível) gerenciar.

Existem outras opções? Existem mecanismos de banco de dados executados no Debian que não seriam corrompidos por cortes de energia? Além disso, qual sistema de arquivos deve ser usado para isso? ext3 é o que é usado no momento.

O software que é executado na máquina virtual é escrito usando o Java 6, portanto, esperamos que a solução não seja incompatível.

    

Answer 1

Honestamente, sua melhor abordagem aqui é corrigir os cortes de energia ou implantar um sistema diferente em um local melhor.

Sim, existem sistemas como o redis, que armazenam dados em um log somente de anexação para reprodução, mas você corre o risco de corrupção em níveis mais baixos - por exemplo, se o seu sistema de arquivos estiver embaralhado, os dados no disco estarão potencialmente em risco.

Eu aprecio que qualquer melhoria seria útil para você, mas realmente o problema não é aquele que pode ser resolvido, dado o cenário que você descreveu.

    

Answer 2

Sua abordagem pode funcionar. Deixe-me sugerir alguns aprimoramentos para isso. Houve uma pergunta no estouro da pilha em gravação atômica no arquivo . Essencialmente, você salva cada pacote de dados em um arquivo temporário e renomeia para o seu nome final. A renomeação é uma operação atômica que estará protegida contra falhas de energia. Dessa forma, você tem a garantia de que todos os seus arquivos em seu destino final foram salvos corretamente sem corrupção.

Então, o que você pode fazer para lidar com a questão de ter milhões de arquivos. É cron uma tarefa que roda talvez a cada hora que leva todos os arquivos mais de uma hora e os combina em um arquivo grande usando novamente operações de arquivo atômico para que esse trabalho seja executado com segurança mesmo durante falhas de energia e exclua os arquivos antigos. Tipo como a rotação de log. Um valor de horas de arquivos seria de cerca de 7.200 arquivos. Então, a qualquer momento, você não deve ter mais de 20.000 arquivos no disco.

    

Answer 3

Você instala um no-break ou uma placa RAID com um cache de gravação com bateria no sistema, e por apenas $ 49.95 , você realiza o que é simplesmente impossível de realizar apenas no software.

Sua alegação de que, de alguma forma, não é possível conectar esse servidor a um no-break ou a uma bateria ... simplesmente não é crível.

    

Answer 4

Monte todo o sistema somente leitura, exceto por um dispositivo de bloco que armazene todos os seus dados. Use esse dispositivo de bloco diretamente e implemente seu próprio mecanismo de armazenamento de dados usando esse dispositivo de bloco bruto.