Cómo almacenar datos en una máquina cuya potencia se corta al azar

13

Tengo una máquina virtual (Debian) ejecutándose en un host de máquina física. La máquina virtual actúa como un búfer para los datos que recibe con frecuencia a través de la red local (el período para estos datos es 0.5s, por lo que un rendimiento bastante alto). Todos los datos recibidos se almacenan en la máquina virtual y se envían repetidamente a un servidor externo a través de UDP. Una vez que el servidor externo reconoce (a través de UDP) que ha recibido un paquete de datos, los datos originales se eliminan de la máquina virtual y no se envían nuevamente al servidor externo. La conexión a Internet que conecta la VM y el servidor externo no es confiable, lo que significa que podría estar inactiva durante días a la vez.

La máquina física que aloja la VM obtiene su corte de energía varias veces al día al azar. No hay forma de saber cuándo va a suceder esto y no es posible agregar un UPS, una batería o una solución similar al sistema.

Originalmente, los datos se almacenaban en una base de datos HSQLDB basada en archivos en la máquina virtual. Sin embargo, los frecuentes cortes de energía eventualmente causan que el archivo de script de la base de datos se corrompa (no a nivel del sistema de archivos, es decir, es legible, pero HSQLDB no puede tener sentido), lo que lleva a mi pregunta:

¿Cómo deben almacenarse los datos en un entorno donde los cortes de energía pueden y ocurren con frecuencia?

Una opción que se me ocurre es usar archivos planos, guardar cada paquete de datos como un archivo en el sistema de archivos. De esta manera, si un archivo está dañado debido a la pérdida de energía, puede ignorarse y el resto de los datos permanece intacto. Sin embargo, esto plantea algunos problemas, principalmente relacionados con la cantidad de datos que probablemente se almacenan en la máquina virtual. A 0.5s entre cada pieza de datos, se generarán 1,728,000 archivos en 10 días. Esto al menos significa usar un sistema de archivos con un mayor número de inodos para almacenar estos datos (la configuración actual del sistema de archivos se quedó sin inodos a ~ 250,000 mensajes y se utilizó el 30% de espacio en disco). Además, es difícil (no imposible) de administrar.

¿Hay más opciones? ¿Existen motores de base de datos que se ejecutan en Debian que no se corrompan por cortes de energía? Además, ¿qué sistema de archivos se debe utilizar para esto? ext3 es lo que se usa en este momento.

El software que se ejecuta en la máquina virtual está escrito con Java 6, por lo que esperamos que la solución no sea incompatible.

Sevas
fuente
14
"La máquina física que aloja la VM se corta la energía varias veces al día al azar. No hay forma de saber cuándo va a suceder esto y no es posible agregar un UPS, una batería o una solución similar a la sistema." Yo realmente quiero saber cómo eso es posible. ¿Está en la Estación Espacial Internacional, por lo que requiere $ 20 millones para enviar un UPS o algo así?
ceejayoz
3
¿La máquina tiene al menos un controlador RAID con caché respaldada por batería?
Zoredache
44
Podríamos recomendar soluciones muy interesantes, creativas y quizás teóricamente correctas a este problema. Sin embargo , no sabemos qué hipervisor y hardware se está ejecutando en el host, por lo que no hay garantía de que las escrituras en disco estén realmente escritas o escritas en el orden correcto ...
pino42
55
@Sevas Parece que no es su decisión, pero sugeriría que valga la pena señalar que 50 UPS básicos y baratos costarían $ 2500 y no necesitan mantenimiento (los reemplaza después de un par de años cuando las baterías comienzan a agotarse) ) El costo de tratar de resolver esto en el software será mucho más alto que eso, a menos que conozca a un grupo de codificadores que trabajan de forma gratuita. Puede ser útil para que la gerencia resuelva esto por $ 50 / unidad, en lugar de docenas o cientos de horas hábiles a 3 cifras por hora.
HopelessN00b
99
Esto en realidad suena como un programa malicioso. El usuario no sabe que la "VM" se está ejecutando en su computadora. Roba datos de toda la red y luego los canaliza a través de una conexión para ocultarse. El usuario "apaga y enciende la computadora" al azar, por lo que no puede simplemente agregar un UPS.
Laurence

Respuestas:

23

Honestamente, su mejor enfoque aquí es solucionar los cortes de energía o implementar un sistema diferente en una mejor ubicación.

Sí, hay sistemas como redis que almacenarán datos en un registro de solo agregar para reproducirlos, pero corre el riesgo de corrupción en niveles inferiores, por ejemplo, si su sistema de archivos está codificado, entonces los datos en el disco están potencialmente en riesgo.

Aprecio que cualquier mejora sea útil para usted, pero realmente el problema no se puede resolver dado el escenario que ha descrito.


fuente
8
+1 La respuesta correcta es "No hagas eso"
Chris S
66
+1 Eventualmente los cortes de energía al azar dañarán su sistema de archivos. La electrónica hace cosas extrañas e impredecibles ya que su poder falla.
Grant
-1 (virtual -1). Creo que dicho sistema debe basarse en el supuesto de que los cortes de energía ocurren de vez en cuando. Esta suposición es un hecho del mundo real con el que tienes que lidiar.
Igal Serban
11

Tu enfoque puede funcionar. Permítanme sugerirle algunas mejoras. Hubo una pregunta en el desbordamiento de la pila sobre la escritura atómica en el archivo . Esencialmente, guarda cada paquete de datos en un archivo temporal y luego cambia el nombre a su nombre final. El cambio de nombre es una operación atómica que estará a salvo de fallas de energía. De esa manera, tiene la garantía de que todos sus archivos en su destino final se han guardado correctamente sin daños.

Entonces, ¿qué puede hacer para lidiar con el problema de tener millones de archivos? ¿Es cron un trabajo que se ejecuta tal vez cada hora que toma todos los archivos anteriores a una hora y los combina en un archivo grande usando nuevamente operaciones de archivo atómico para que este trabajo se ejecute de manera segura incluso durante fallas de alimentación y luego borre los archivos antiguos. Algo así como la rotación del registro. Una hora de archivos sería de alrededor de 7.200 archivos. Entonces, en cualquier momento, no debería tener más de 20,000 archivos en el disco.

Marwan Alsabbagh
fuente
1
No es una mala respuesta, pero el problema es suponer que la escritura en sí misma es una operación atómica, que no lo es. Por lo tanto, una falla de energía en el momento equivocado aún podría crear datos o corrupción FS. Sin embargo, probablemente sea la mejor opción, aparte de arreglar la alimentación o enchufarlo a un UPS, por lo que +1.
HopelessN00b
Sí, renombrar el archivo una vez escrito es una operación atómica. Escribir el archivo en primer lugar, no lo es.
HopelessN00b
3
@ HopelessN00b No importa que el nuevo archivo esté medio escrito o dañado. Tiene el archivo antiguo que está en buen estado. Cuando recuperas el sistema, destruyes el archivo medio escrito.
DJClayworth
2
@ HopelessN00b ¡Exactamente! solo los archivos temporales en un directorio temporal, digamos, podrían escribirse a medias. Todos los archivos en su directorio de destino final siempre serán no corruptos y seguros en el disco
Marwan Alsabbagh
7

Instala un UPS o una tarjeta RAID con una memoria caché de escritura respaldada por batería en el sistema, y por tan solo $ 49.95 , logra lo que es simplemente imposible de lograr solo con el software.

Su afirmación de que de alguna manera no es posible conectar este servidor a un UPS o batería ... simplemente no es creíble.

HopelessN00b
fuente
99
La estupidez burocrática siempre es creíble.
Dan está jugando con Firelight el
3
@DanNeely My PHB won't let me hook this up to a UPS/batteryes algo muy diferente a it is not possible to add a UPS, a battery, or a similar solution to the system. No ser demasiado pedante, pero es una distinción importante porque cambia el enfoque y las soluciones disponibles.
HopelessN00b
O, como se mencionó en otra parte, el usuario de la computadora secuestrada se sorprendería si le pidiera instalar un UPS. La situación es un poco increíble de lo contrario. Cualquiera, dentro de lo razonable, aceptaría un UPS sobre datos corruptos dado el caso comercial adecuado.
WernerCD
@WernerCD Me gustaría que conocieras a nuestro CIO. Si bien estoy de acuerdo en que secuestrar la computadora de alguien es un posible caso de uso para esto, también puedo pensar en las legítimas, así que le daré al chico el beneficio de la duda. Piense en los sistemas y controladores integrados, o como un Raspberry Pi: definitivamente puede ser el caso de que la "computadora" que está usando vale menos de los $ 50 que se necesitarían para conectarla a un UPS.
HopelessN00b
Incluso si la computadora vale menos que el UPS de $ 50, son los datos en la computadora los que realmente valen algo. Google fue construido en computadoras "sin valor". Más importante que el costo de la CPU es el costo de la pérdida de datos, la pérdida de mano de obra (esta aventura de programación, la persecución de corrupción de datos, el seguimiento de errores en el sistema antiguo y esta nueva parte), el valor perdido de los clientes (¿Perdí mis datos? Próxima compañía por favor.), Etc.
WernerCD
5

Monte todo el sistema de solo lectura, excepto un dispositivo de bloque que almacena todos sus datos. Use ese dispositivo de bloque directamente e implemente su propio mecanismo de almacenamiento de datos usando ese dispositivo de bloque sin procesar.

MikeyB
fuente
3
... e invierta en una tarjeta controladora de disco con respaldo de batería, y asegúrese de que no haya caché de escritura en el disco, o todavía está jodido.
voretaq7
Vine aquí para decir que deberían iniciarse desde un Live-CD o un sistema ROM equivalente, con algo de almacenamiento de estado sólido utilizado con las soluciones de archivos planos.
Mark Allen el
El caché de escritura se puede deshabilitar. Este enfoque es viable. Agregar solo Se recomienda un mecanismo de almacenamiento. Los bloques se escriben atómicamente (supongo) para que pueda tener dos bloques de "puntero" que apuntan al inicio y al final de la sección con datos nuevos / todo. Los punteros se actualizan después de escribir / finalizar datos. NCQ también debe estar deshabilitado.
sleeplessnerd