Comment stocker des données sur une machine dont l'alimentation est coupée au hasard

13

J'ai une machine virtuelle (Debian) exécutée sur un hôte de machine physique. La machine virtuelle agit comme un tampon pour les données qu'elle reçoit fréquemment sur le réseau local (la période pour ces données est de 0,5 s, donc un débit assez élevé). Toutes les données reçues sont stockées sur la machine virtuelle et transmises à plusieurs reprises à un serveur externe via UDP. Une fois que le serveur externe reconnaît (via UDP) qu'il a reçu un paquet de données, les données d'origine sont supprimées de la machine virtuelle et ne sont plus envoyées au serveur externe. La connexion Internet qui connecte la machine virtuelle et le serveur externe n'est pas fiable, ce qui signifie qu'elle peut être interrompue pendant plusieurs jours.

La machine physique qui héberge la machine virtuelle obtient sa coupure de courant plusieurs fois par jour au hasard. Il n'y a aucun moyen de savoir quand cela est sur le point de se produire et il n'est pas possible d'ajouter un onduleur, une batterie ou une solution similaire au système.

À l'origine, les données étaient stockées sur une base de données HSQLDB basée sur des fichiers sur la machine virtuelle. Cependant, les coupures de courant fréquentes finissent par endommager le fichier de script de base de données (pas au niveau du système de fichiers, c'est-à-dire qu'il est lisible, mais HSQLDB ne peut pas le comprendre), ce qui conduit à ma question:

Comment les données doivent-elles être stockées dans un environnement où les coupures de courant peuvent et se produisent fréquemment?

Une option à laquelle je peux penser est d'utiliser des fichiers plats, en enregistrant chaque paquet de données en tant que fichier sur le système de fichiers. De cette façon, si un fichier est corrompu en raison d'une perte d'alimentation, il peut être ignoré et le reste des données reste intact. Cela pose cependant quelques problèmes, principalement liés à la quantité de données susceptibles d'être stockées sur la machine virtuelle. À 0,5 s entre chaque donnée, 1 728 000 fichiers seront générés en 10 jours. Cela signifie au moins utiliser un système de fichiers avec un nombre accru d'inodes pour stocker ces données (la configuration actuelle du système de fichiers a manqué d'inodes à ~ 250 000 messages et 30% d'espace disque utilisé). De plus, c'est difficile (pas impossible) à gérer.

Il y a-t-il des alternatives? Existe-t-il des moteurs de base de données fonctionnant sur Debian qui ne seraient pas corrompus par des coupures de courant? De plus, quel système de fichiers doit être utilisé pour cela? ext3 est ce qui est utilisé actuellement.

Le logiciel qui s'exécute sur la machine virtuelle est écrit en utilisant Java 6, donc j'espère que la solution ne serait pas incompatible.

debian filesystems corruption

— Sevas
source

14

«La machine physique qui héberge la machine virtuelle est coupée de son alimentation plusieurs fois par jour au hasard. Il n'y a aucun moyen de savoir quand cela va se produire et il n'est pas possible d'ajouter un onduleur, une batterie ou une solution similaire à la système." Je veux vraiment savoir comment c'est possible. Est-ce dans la Station spatiale internationale, donc il faut 20 millions de dollars pour envoyer un UPS ou quelque chose?

— ceejayoz

3

La machine a-t-elle au moins un contrôleur RAID avec cache sauvegardé par batterie?

— Zoredache

4

Nous pourrions recommander des solutions très intéressantes, créatives et peut-être théoriquement correctes à ce problème. Cependant , nous ne savons pas quel hyperviseur et quel matériel s'exécute sur l'hôte, il n'y a donc aucune garantie que les écritures sur disque soient réellement écrites ou écrites dans le bon ordre…

— pino42

5

@Sevas On dirait que ce n'est pas votre appel, mais je pense qu'il vaut la peine de souligner que 50 onduleurs basiques et bon marché coûteraient 2500 $ et n'ont pas besoin d'entretien (vous les remplacez après quelques années lorsque les batteries commencent à disparaître) ). Le coût d'essayer de résoudre ce problème dans le logiciel sera beaucoup plus élevé que cela, à moins que vous ne connaissiez un tas de codeurs qui travaillent gratuitement. Cela pourrait être utile pour amener la direction à résoudre ce problème pour 50 $ / unité, au lieu de dizaines ou de centaines d'heures de travail qualifiées @ 3 chiffres par heure.

— HopelessN00b

9

Cela ressemble en fait à un programme malveillant. L'utilisateur ne sait pas que la «VM» s'exécute sur son ordinateur. Il vole des données sur l'ensemble du réseau, puis les achemine via une connexion pour se cacher. L'utilisateur "éteint et rallume l'ordinateur" au hasard - vous ne pouvez donc pas simplement ajouter un onduleur.

— Laurence

23

Honnêtement, votre meilleure approche consiste à réparer les coupures de courant ou à déployer un système différent dans un meilleur emplacement.

Oui, il existe des systèmes tels que redis qui stockent les données dans un journal à ajouter uniquement pour la relecture, mais vous risquez la corruption à des niveaux inférieurs - par exemple, si votre système de fichiers est brouillé, les données sur le disque sont potentiellement à risque.

J'apprécie que toute amélioration vous soit utile, mais en réalité, le problème ne peut pas être résolu compte tenu du scénario que vous avez décrit.

8

+1 La bonne réponse est "Ne fais pas ça"

— Chris S

6

+1 Finalement, des coupures de courant aléatoires endommageront votre système de fichiers. L'électronique fait des choses imprévisibles étranges car leur alimentation est coupée.

— Grant

-1 (-1 virtuel). Je pense qu'un tel système doit être construit sur l'hypothèse que des coupures de courant se produisent de temps en temps. Cette hypothèse est un fait réel auquel vous devez faire face.

— Igal Serban

11

Votre approche peut fonctionner. Permettez-moi de suggérer quelques améliorations. Il y avait une question de débordement de pile lors de l'écriture atomique dans un fichier . Essentiellement, vous enregistrez chaque paquet de données dans un fichier temporaire, puis vous le renommez en son nom final. Le changement de nom est une opération atomique qui sera à l'abri des pannes de courant. De cette façon, vous êtes assuré que tous vos fichiers dans votre destination finale ont été enregistrés correctement sans corruption.

Ensuite, ce que vous pouvez faire pour résoudre le problème d'avoir des millions de fichiers. Est-ce que cron est un travail qui s'exécute peut-être toutes les heures, qui prend tous les fichiers plus d'une heure et les combine en un seul gros fichier en utilisant à nouveau les opérations de fichiers atomiques afin que ce travail s'exécute en toute sécurité même lors d'une panne de courant, puis supprime les anciens fichiers. Un peu comme la rotation du journal. Une heure de fichiers équivaut à environ 7 200 fichiers. Donc, à tout moment, vous ne devriez pas avoir plus de 20 000 fichiers sur le disque.

— Marwan Alsabbagh
source

1

Pas une mauvaise réponse, mais le problème est de supposer que l'écriture elle-même est une opération atomique, ce qui n'est pas le cas. Ainsi, une panne de courant au mauvais moment pourrait toujours créer des données ou une corruption de FS. Probablement sur la meilleure option, à moins de réparer l'alimentation ou de brancher la chose dans un onduleur, alors +1.

— HopelessN00b

@ Changement de nom de

— Marwan Alsabbagh

Oui, renommer le fichier une fois écrit est une opération atomique. Écrire le fichier en premier lieu ne l'est pas.

— HopelessN00b

3

@ HopelessN00b Peu importe que le nouveau fichier soit à moitié écrit ou corrompu. Vous avez l'ancien fichier qui est en bon état. Lorsque vous récupérez le système, vous détruisez le fichier à moitié écrit.

— DJClayworth

2

@ HopelessN00b Exactement! seuls les fichiers temporaires d'un répertoire temporaire permettent de dire qu'ils pourraient être à moitié écrits. Tous les fichiers de votre répertoire de destination finale seront toujours non corrompus et en toute sécurité sur le disque

— Marwan Alsabbagh

7

Vous installez un onduleur ou une carte RAID avec un cache d'écriture alimenté par batterie sur le système, et pour aussi peu que 49,95 $ , vous accomplissez ce qui est tout simplement impossible à accomplir dans le logiciel seul.

Votre affirmation selon laquelle il n'est pas possible de connecter ce serveur à un onduleur ou à une batterie ... n'est tout simplement pas crédible.

— HopelessN00b
source

9

La stupidité bureaucratique est toujours crédible.

— Dan est en train de jouer par Firelight

3

@DanNeely My PHB won't let me hook this up to a UPS/batteryest une chose très différente de it is not possible to add a UPS, a battery, or a similar solution to the system. Ne pas devenir trop pédant, mais c'est une distinction importante car elle change l'approche et les solutions disponibles.

— HopelessN00b

Ou, comme mentionné ailleurs, l'utilisateur de l'ordinateur détourné serait surpris si je demandais d'installer un onduleur. La situation est un peu incroyable sinon. N'importe qui accepterait, dans des limites raisonnables, un onduleur sur des données corrompues, étant donné l'analyse de rentabilisation appropriée.

— WernerCD

@WernerCD J'aimerais que vous rencontriez notre CIO. Bien que je convienne que le détournement de l'ordinateur de quelqu'un est un cas d'utilisation possible pour cela, je peux également penser à des cas légitimes, alors je donnerai au gars le bénéfice du doute. Pensez aux systèmes et contrôleurs intégrés, ou comme un Raspberry Pi - il peut certainement être le cas que "l'ordinateur" que vous utilisez vaut moins que les 50 $ qu'il faudrait pour le connecter à un onduleur.

— HopelessN00b

Même si l'ordinateur vaut moins que l'onduleur de 50 $ - ce sont les données de l'ordinateur qui valent réellement quelque chose. Google a été construit sur des ordinateurs "sans valeur". Plus important que le coût du CPU est le coût de la perte de données, de la perte de main-d'œuvre (cette aventure de programmation, la poursuite de la corruption de données, le suivi des bogues dans l'ancien système ainsi que cette nouvelle partie), la valeur perdue pour les clients (perdu mes données? Prochaine entreprise, s'il vous plaît.), Etc.

— WernerCD

5

Montez l'ensemble du système en lecture seule, à l'exception d'un périphérique bloc qui stocke toutes vos données. Utilisez ce périphérique de bloc directement et implémentez votre propre mécanisme de stockage de données à l'aide de ce périphérique de bloc brut.

— MikeyB
source

3

... et investissez dans une carte contrôleur de disque alimentée par batterie, et assurez-vous qu'il n'y a pas de cache d'écriture sur le disque, ou vous êtes toujours foutu.

— voretaq7

Je suis venu ici pour dire qu'ils devraient démarrer à partir d'un Live-CD ou d'un système ROM équivalent, avec un stockage à semi-conducteurs utilisé avec les solutions de fichiers plats.

— Mark Allen

Le cache d'écriture peut être désactivé. Cette approche est viable. Ajouter uniquement le mécanisme de stockage est conseillé. Les blocs sont écrits atomiquement (je suppose) de sorte que vous pouvez avoir deux blocs "pointeur" qui pointent vers le début et la fin de la section avec des données nouvelles / à faire. Les pointeurs sont mis à jour après l'écriture / la finition des données. NCQ devrait également être désactivé.

— sleeplessnerd