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

13

Eu tenho uma máquina virtual (Debian) em execução em um host de máquina físico. A máquina virtual atua como um buffer para os dados que recebe frequentemente pela rede local (o período para esses dados é de 0,5s, portanto, uma taxa de transferência bastante alta). Todos os dados recebidos são armazenados na máquina virtual e encaminhados repetidamente para um servidor externo pelo UDP. Depois que 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 ela pode ficar inativa por dias a fio.

A máquina física que hospeda a VM é cortada várias vezes por dia aleatoriamente. Não há como saber quando isso está prestes a acontecer e não é possível adicionar um no-break, bateria ou 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 frequentes cortes de energia acabam causando o corrompimento do arquivo de script do banco de dados (não no nível do sistema de arquivos, ou seja, é legível, mas o HSQLDB não consegue entender isso), o que leva à minha pergunta:

Como os dados devem ser armazenados em um ambiente em que os cortes de energia podem e ocorrem com frequência?

Uma opção em que posso pensar é 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. A 0,5s entre cada parte dos dados, 1.728.000 arquivos serão gerados em 10 dias. Isso pelo menos significa usar um sistema de arquivos com um número aumentado 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) de 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 roda na máquina virtual é escrito usando Java 6, portanto, esperamos que a solução não seja incompatível.

debian filesystems corruption

— Sevas
fonte

14

"A máquina física que hospeda a VM é cortada várias vezes por dia aleatoriamente. Não há como saber quando isso está prestes a acontecer e não é possível adicionar um no-break, bateria ou solução semelhante ao sistema." Eu realmente quero saber como isso é possível. Está na Estação Espacial Internacional e exige US $ 20 milhões para enviar uma UPS ou algo assim?

— ceejayoz

3

A máquina possui pelo menos um controlador RAID com cache com bateria?

— Zoredache

4

Poderíamos recomendar soluções muito interessantes, criativas e talvez teoricamente corretas para esse problema. No entanto , não sabemos o que hypervisor e hardware está em execução no host, então não haveria nenhuma garantia de que gravações em disco são realmente escrito, ou por escrito na ordem correta ...

— pino42

5

@Sevas Parece que não é sua decisão, mas eu sugiro que valha a pena ressaltar que 50 UPSs básicos e baratos custariam US $ 2500 e não precisam de manutenção (você os substitui após alguns anos quando as baterias começam a funcionar) ) O custo de tentar resolver isso no software será muito maior do que isso, a menos que você conheça um monte de codificadores que trabalham de graça. Pode ser útil para conseguir que a gerência resolva isso por US $ 50 / unidade, em vez de dezenas ou centenas de horas de trabalho hábeis a 3 dígitos por hora.

— precisa

9

Isso realmente soa como um programa malicioso. O usuário não sabe que a "VM" está sendo executada no computador. Ele está roubando dados de toda a rede - depois canalizando-os através de uma conexão para se esconder. O usuário "liga e desliga o computador" aleatoriamente - então você não pode simplesmente adicionar um no-break.

— Laurence

23

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 registro somente anexado para reprodução, mas você corre o risco de corrupção em níveis mais baixos - por exemplo, se o seu sistema de arquivos for embaralhado, os dados no disco estão potencialmente em risco.

Agradeço que qualquer melhoria seja útil para você, mas, na verdade, o problema não pode ser resolvido de acordo com o cenário que você descreveu.

8

A resposta correta é "Não faça isso"

— Chris S

6

+1 Eventualmente, cortes de energia aleatórios irão corromper seu sistema de arquivos. Os eletrônicos fazem coisas estranhas e imprevisíveis, pois seu poder falha.

— Grant

-1 (virtual -1). Penso que esse sistema deve ser construído com base no pressuposto de que os cortes de energia acontecem de tempos em tempos. Essa suposição é um fato do mundo real com o qual você precisa lidar.

— Igal Serban

11

Sua abordagem pode funcionar. Deixe-me sugerir algumas melhorias. Havia uma pergunta no estouro de pilha na gravação atômica no arquivo . Basicamente, você salva cada pacote de dados em um arquivo temporário e o renomeia para seu nome final. Renomear é uma operação atômica que estará protegida contra falhas de energia. Dessa forma, você garante que todos os seus arquivos no 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. O cron é um trabalho que pode ser executado a cada hora, que leva todos os arquivos mais antigos que uma hora e os combina em um arquivo grande usando novamente operações atômicas de arquivos para que esse trabalho seja executado com segurança mesmo durante uma falta de energia e exclua os arquivos antigos. Tipo como rotação de log. Uma hora de arquivos custaria cerca de 7.200 arquivos. Portanto, a qualquer momento, você não deve ter mais de 20.000 arquivos em disco.

— Marwan Alsabbagh
fonte

1

Não é uma resposta ruim, mas o problema é assumir que a própria gravação é uma operação atômica, o que não é. Portanto, uma falha de energia no momento errado ainda pode criar dados ou corrupção do FS. Provavelmente, sobre a melhor opção, a menos que seja consertar a energia ou conectar o aparelho a um no-break, então +1.

— precisa

@ HopelessN00b renomeação será uma operação atômica este é um requisito POSIX

— Marwan Alsabbagh

Sim, renomear o arquivo depois de gravado é uma operação atômica. Escrever o arquivo em primeiro lugar, não é.

— precisa

3

@ HopelessN00b Não importa que o novo arquivo esteja meio gravado ou corrompido. Você tem o arquivo antigo que está em bom estado. Quando você recupera o sistema, destrói o arquivo semi-escrito.

— quer

2

@ HopelessN00b Exatamente! somente arquivos temporários em um diretório temporário, digamos, poderiam ser meio gravados. Todos os arquivos em seu diretório destino final será sempre não-corrupto e com segurança no disco

— Marwan Alsabbagh

7

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

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

— HopelessN00b
fonte

9

A estupidez burocrática é sempre crível.

— Dan is Fiddling por Firelight

3

@DanNeely My PHB won't let me hook this up to a UPS/batteryé uma coisa muito diferente de it is not possible to add a UPS, a battery, or a similar solution to the system. Não ficar muito pedante, mas é uma distinção importante porque altera a abordagem e as soluções disponíveis.

— HopelessN00b

Ou, como mencionado em outro lugar, o usuário do computador seqüestrado ficaria surpreso se eu pedisse para instalar um no-break. A situação é um pouco inacreditável. Qualquer pessoa, dentro do razoável, aceitaria um no-break por dados corrompidos, considerando o caso comercial adequado.

— WernerCD

@WernerCD Gostaria que você conhecesse nosso CIO. Embora eu concorde que seqüestrar o computador de alguém é um possível caso de uso para isso, também posso pensar em legítimos, então darei ao cara o benefício da dúvida. Pense em sistemas e controladores embarcados, ou como um Raspberry Pi - pode ser que o "computador" que você está usando valha menos do que os US $ 50 necessários para conectá-lo a um no-break.

— HopelessN00b

Mesmo que o computador valha menos do que os US $ 50 UPS - são os dados no computador que realmente valem alguma coisa. O Google foi construído em computadores "sem valor". Mais importante que o custo da CPU é o custo de dados perdidos, mão-de-obra perdida (esta aventura de programação, perseguição à corrupção de dados, rastreamento de bugs no sistema antigo e também nesta nova parte), valor perdido aos clientes (perdeu meus dados? Próxima empresa, por favor.), Etc.

— WernerCD 8/12/12

5

Monte todo o sistema somente leitura, exceto um dispositivo de bloco que armazena 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.

— MikeyB
fonte

3

... e invista em uma placa controladora de disco com bateria e verifique se não há cache de gravação no disco ou se você ainda está ferrado.

— voretaq7

Vim aqui para dizer que eles deveriam estar inicializando a partir de um Live-CD ou sistema ROM equivalente, com algum armazenamento de estado sólido usado nas soluções de arquivos simples.

— Mark Allen

O cache de gravação pode ser desativado. Essa abordagem é viável. Anexar apenas mecanismo de armazenamento é recomendado. Os blocos são gravados atomicamente (presumo) para que você possa ter dois blocos "apontadores" que apontam para o início e o fim da seção com novos dados / todo. Os ponteiros são atualizados após a gravação / acabamento dos dados. O NCQ também deve ser desativado.

— 31513 sleeplessnerd