Come archiviare i dati su una macchina la cui potenza viene interrotta casualmente

13

Ho una macchina virtuale (Debian) in esecuzione su un host di macchine fisiche. La macchina virtuale funge da buffer per i dati che riceve frequentemente sulla rete locale (il periodo per questi dati è 0,5 s, quindi un throughput abbastanza elevato). Tutti i dati ricevuti vengono archiviati sulla macchina virtuale e inoltrati ripetutamente a un server esterno su UDP. Una volta che il server esterno riconosce (su UDP) di aver ricevuto un pacchetto di dati, i dati originali vengono eliminati dalla macchina virtuale e non vengono nuovamente inviati al server esterno. La connessione Internet che collega la VM e il server esterno non è affidabile, il che significa che potrebbe essere inattiva per giorni alla volta.

La macchina fisica che ospita la macchina virtuale viene interrotta più volte al giorno a caso. Non c'è modo di sapere quando sta per accadere e non è possibile aggiungere un sistema UPS, una batteria o una soluzione simile al sistema.

Inizialmente, i dati erano archiviati su un database HSQLDB basato su file sulla macchina virtuale. Tuttavia, le frequenti interruzioni di corrente alla fine causano il danneggiamento del file di script del database (non a livello di file system, cioè è leggibile, ma HSQLDB non può avere senso), il che porta alla mia domanda:

Come devono essere archiviati i dati in un ambiente in cui le interruzioni di corrente possono e si verificano frequentemente?

Un'opzione che mi viene in mente è l'utilizzo di file flat, salvando ogni pacchetto di dati come file sul file system. In questo modo se un file viene danneggiato a causa della perdita di potenza, può essere ignorato e il resto dei dati rimane intatto. Ciò pone tuttavia alcuni problemi, principalmente legati alla quantità di dati che probabilmente verranno archiviati nella macchina virtuale. A 0,5 secondi tra ogni dato, verranno generati 1.728.000 file in 10 giorni. Ciò significa almeno utilizzare un file system con un numero maggiore di inode per archiviare questi dati (l'attuale configurazione del file system ha esaurito gli inode con ~ 250.000 messaggi e il 30% di spazio su disco utilizzato). Inoltre, è difficile (non impossibile) da gestire.

Ci sono altre opzioni? Esistono motori di database in esecuzione su Debian che non verrebbero danneggiati dalle interruzioni di corrente? Inoltre, quale file system dovrebbe essere usato per questo? ext3 è ciò che viene utilizzato al momento.

Il software che gira sulla macchina virtuale è scritto usando Java 6, quindi spero che la soluzione non sia incompatibile.

debian filesystems corruption

— Sevas
fonte

14

"La macchina fisica che ospita la VM viene interrotta in modo casuale più volte al giorno. Non c'è modo di dire quando sta per accadere e non è possibile aggiungere un UPS, una batteria o una soluzione simile al sistema." Voglio davvero sapere come sia possibile. È nella Stazione Spaziale Internazionale quindi sono necessari 20 milioni di dollari per inviare un UPS o qualcosa del genere?

— Ceejayoz,

3

La macchina ha almeno un controller RAID con cache alimentata a batteria?

— Zoredache,

4

Potremmo raccomandare soluzioni molto interessanti, creative e forse teoricamente corrette a questo problema. Tuttavia , non sappiamo quale hypervisor e hardware sia in esecuzione sull'host, quindi non ci sarebbe alcuna garanzia che le scritture su disco siano realmente scritte o scritte nell'ordine corretto ...

— pino42

5

@Sevas Sembra che non sia la tua chiamata, ma suggerisco che vale la pena sottolineare che 50 UPS di base a basso costo costerebbero $ 2500 e non necessitano di manutenzione (li sostituisci dopo un paio d'anni quando le batterie iniziano a scaricarsi ). Il costo per provare a risolvere questo problema con il software sarà molto più alto di quello, a meno che tu non conosca un gruppo di programmatori che lavorano gratuitamente. Potrebbe essere utile per ottenere la gestione per risolvere questo problema per $ 50 / unità, invece di dozzine o centinaia di ore di manodopera qualificate a 3 cifre all'ora.

— HopelessN00b,

9

In realtà sembra un programma dannoso. L'utente non sa che la "VM" è in esecuzione sul proprio computer. Sta rubando dati da tutta la rete, quindi incanalandoli attraverso una connessione per nascondersi. L'utente "spegne e riaccende il computer" in modo casuale, quindi non puoi semplicemente aggiungere un UPS.

— Laurence,

23

Onestamente il tuo miglior approccio qui è quello di riparare le interruzioni di corrente o distribuire un sistema diverso in una posizione migliore.

Sì, ci sono sistemi come redis che memorizzeranno i dati in un registro di solo accodamento per la riproduzione, ma si rischia la corruzione a livelli inferiori, ad esempio se il file system è confuso, i dati sul disco sono potenzialmente a rischio.

Apprezzo che qualsiasi miglioramento possa esserti utile, ma in realtà il problema non è uno che può essere risolto dato lo scenario che hai delineato.

8

+1 La risposta corretta è "Non farlo"

— Chris S

6

+1 Eventuali interruzioni di corrente casuali danneggeranno il tuo filesystem. L'elettronica fa strane cose imprevedibili quando la loro potenza viene a mancare.

— Concedi il

-1 (virtuale -1). Penso che un tale sistema debba basarsi sul presupposto che di tanto in tanto si verificano interruzioni di corrente. Questa ipotesi è un fatto reale che devi affrontare.

— Igal Serban,

11

Il tuo approccio può funzionare. Vorrei suggerire alcuni miglioramenti ad esso. Si è verificata una domanda in overflow dello stack durante la scrittura atomica su file . In sostanza, si salva ogni pacchetto di dati in un file temporaneo e quindi si rinomina con il suo nome finale. La ridenominazione è un'operazione atomica che sarà al sicuro da interruzioni di corrente. In questo modo sei sicuro che tutti i tuoi file nella destinazione finale sono stati salvati correttamente senza corruzione.

Quindi cosa puoi fare per affrontare il problema di avere milioni di file. Cron è un lavoro che viene eseguito ogni ora che richiede tutti i file più vecchi di un'ora e li combina in un unico grande file usando di nuovo le operazioni dei file atomici in modo che questo lavoro venga eseguito in modo sicuro anche durante un'interruzione di corrente, quindi elimina i vecchi file. Un po 'come la rotazione del registro. Un'ora di file sarebbe di circa 7.200 file. Quindi in qualsiasi momento non dovresti avere più di 20.000 file sul disco.

— Marwan Alsabbagh
fonte

1

Non è una cattiva risposta, ma il problema è nel presupporre che la scrittura stessa sia un'operazione atomica, che non lo è. Quindi un'interruzione di corrente al momento sbagliato potrebbe comunque creare dati o corruzione di FS. Probabilmente sulla migliore opzione, a corto di potere, o collegare la cosa a un UPS, però, quindi +1.

— HopelessN00b

La ridenominazione di HopelessN00b sarà un'operazione atomica, questo è un requisito POSIX

— Marwan Alsabbagh

Sì, rinominare il file una volta scritto è un'operazione atomica. Scrivere il file in primo luogo, non lo è.

— HopelessN00b,

3

@ HopelessN00b Non importa che il nuovo file sia scritto a metà o danneggiato. Hai il vecchio file che è in buono stato. Quando ripristini il sistema, distruggi il file scritto per metà.

— DJClayworth,

2

@ HopelessN00b Esattamente! solo i file temporanei in una directory temporanea possono essere scritti a metà. Tutti i file nella directory di destinazione finale saranno sempre non corrotti e sicuri su disco

— Marwan Alsabbagh

7

Installi un UPS o una scheda RAID con una cache di scrittura supportata da batteria nel sistema e , per un minimo di $ 49,95 , realizzi ciò che è semplicemente impossibile da realizzare nel solo software.

La tua affermazione che in qualche modo non è possibile collegare questo server a un UPS o una batteria ... semplicemente non è credibile.

— HopelessN00b
fonte

9

La stupidità burocratica è sempre credibile.

— Dan è Fiddling by Firelight il

3

@DanNeely My PHB won't let me hook this up to a UPS/batteryè una cosa molto diversa da it is not possible to add a UPS, a battery, or a similar solution to the system. Non diventare troppo pedante, ma è una distinzione importante perché cambia l'approccio e le soluzioni disponibili.

— HopelessN00b,

Oppure, come menzionato altrove, l'utente del computer dirottato sarebbe sorpreso se chiedessi di installare un UPS. Altrimenti la situazione è un po 'incredibile. Chiunque accetterebbe, entro limiti ragionevoli, un UPS in caso di dati danneggiati, considerato il caso aziendale adeguato.

— WernerCD,

@WernerCD Mi piacerebbe che incontrassi il nostro CIO. Mentre sono d'accordo che dirottare il computer di qualcuno è un possibile caso d'uso per questo, posso pensare anche a quelli legittimi, quindi darò al ragazzo il beneficio del dubbio. Pensa ai sistemi e ai controller incorporati, o come un Raspberry Pi: può sicuramente essere il caso che il "computer" che stai usando valga meno di $ 50 per collegarlo a un UPS.

— HopelessN00b,

Anche se il computer vale meno di $ 50 UPS - sono i dati sul computer che in realtà valgono qualcosa. Google è stato costruito su computer "senza valore". Più importante del costo della CPU è il costo della perdita di dati, perdita di forza lavoro (Questa avventura di programmazione, inseguimento della corruzione dei dati, tracciamento dei bug nel vecchio sistema e questa nuova parte), perdita di valore per i clienti (Dati persi? Prossima compagnia per favore.), Ecc.

— WernerCD,

5

Montare l'intero sistema in sola lettura, ad eccezione di un dispositivo a blocchi che memorizza tutti i tuoi dati. Utilizzare direttamente quel dispositivo a blocchi e implementare il proprio meccanismo di archiviazione dei dati utilizzando quel dispositivo a blocchi non elaborato.

— MikeyB
fonte

3

... e investi in una scheda controller del disco con batteria, e assicurati che non ci sia cache di scrittura sul disco, o che tu sia ancora fregato.

— voretaq7,

Sono venuto qui per dire che avrebbero dovuto avviarsi da un Live-CD o un sistema ROM equivalente, con un po 'di memoria a stato solido usata con le soluzioni di file flat.

— Mark Allen,

La cache di scrittura può essere disabilitata. Questo approccio è praticabile. Si consiglia di aggiungere solo il meccanismo di archiviazione. I blocchi sono scritti atomicamente (presumo) in modo da poter avere due blocchi "puntatore" che puntano all'inizio e alla fine della sezione con nuovi dati / todo. I puntatori vengono aggiornati dopo aver scritto / terminato i dati. Anche NCQ dovrebbe essere disabilitato.

— sleeplessnerd