13 votos

Cómo almacenar datos en una máquina cuyo poder se corta al azar

Tengo una máquina virtual (Debian) que se ejecuta en una máquina física del host. La máquina virtual actúa como un buffer para los datos que recibe con frecuencia través de la red local (el período para este tipo de datos es de 0,5 s, lo bastante alto rendimiento). Los datos recibidos se almacenan en la máquina virtual y en varias ocasiones remiten a un servidor externo a través de UDP. Una vez que el servidor externo reconoce (UDP), que ha recibido un paquete de datos, los datos originales se eliminan de la máquina virtual y no se envían al servidor externo nuevo. La conexión a internet que se conecta la máquina virtual y el servidor externo no es fiable, lo que significa que podría ser hasta por días.

La física de la máquina que aloja la VM obtiene su poder de corte varias veces al día al azar. No hay manera de saber cuando esta está a punto de suceder y no es posible agregar un UPS, una batería o una solución similar a la del sistema.

Originalmente, los datos se almacenan en un archivo basado en la base de datos HSQLDB en la máquina virtual. Sin embargo, los frecuentes cortes de energía, eventualmente, causar el script de base de datos archivo dañado (no en el nivel de sistema de archivos, es decir, es legible, pero HSQLDB no puede hacer sentido de ella), lo que lleva a mi pregunta:

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

Una opción que se me ocurre es mediante archivos planos, el ahorro de cada paquete de datos como un archivo en el sistema. De esta forma, si un archivo está dañado debido a la pérdida de poder, se puede ser ignorado y el resto de los datos permanecen intactos. Esto plantea algunos problemas, sin embargo, relacionados principalmente con la cantidad de datos que puedan estar almacenados en la máquina virtual. En el 0,5 s entre cada pieza de datos, 1,728,000 se generarán los archivos en 10 días. Esto, al menos, significa que se utiliza un sistema de archivos con un mayor número de inodos para almacenar este tipo de datos (el sistema de archivos actual configuración corrió fuera de inodos en ~de 250.000 mensajes y un 30% de espacio de disco utilizado). También, es difícil (no imposible) para administrar.

Hay otras opciones? Hay motores de base de datos que se ejecutan en Debian, que no se corrompe por los cortes de energía? También, ¿qué sistema de archivos debe ser utilizado para este? ext3 es lo que se usa en el momento.

El software que se ejecuta en la máquina virtual está escrito en Java 6, así que espero que la solución no sería incompatible.

11voto

Marwan Alsabbagh Puntos 276

Su enfoque puede funcionar. Permítanme sugerir algunas mejoras. Había una pregunta en el desbordamiento de pila en la atómica escribir en el archivo. Esencialmente, puede guardar cada paquete de datos a un archivo temporal y, a continuación, cambiar el nombre al final del nombre. El cambio de nombre es una operación atómica que estará a salvo de fallos de alimentación. De esa manera se garantiza que todos sus archivos en su destino final se han guardado correctamente con ninguna corrupción.

Entonces, ¿qué se puede hacer para lidiar con el problema de tener millones de archivos. Es un trabajo cron que se ejecuta tal vez cada hora que toma todos los archivos de más de una hora y las combina en un archivo de gran tamaño utilizando de nuevo atómica operaciones de archivo, por lo que este trabajo se ejecuta de forma segura, incluso durante fallas de energía, y, a continuación, elimina los archivos antiguos. Como la rotación de registro. Una hora en la pena de archivos sería de alrededor de 7.200 archivos. De modo que en cualquier punto en los momentos que no debería tener más de 20.000 archivos en el disco.

7voto

HopelessN00b Puntos 38607

Instalar un SAI o una tarjeta RAID con una batería de caché de escritura con respaldo para el sistema, y por tan poco como $49.95, lograr lo que es simplemente imposible de llevar a cabo en el programa solo.

Su reclamo de que de alguna manera no es posible conectar a este servidor a través de un UPS o batería... es simplemente no es creíble.

5voto

MikeyB Puntos 26178

Monte el sistema de sólo lectura, a excepción de un dispositivo de bloque que almacena todos sus datos. El uso que el dispositivo de bloque directa e implementar su propio mecanismo de almacenamiento de datos utilizando primas de dispositivo de bloque.

1voto

Steve Kemp Puntos 1464

Honestamente tu mejor enfoque aquí es fijar bien el poder de los recortes, o implementar un sistema diferente en un lugar mejor.

Sí existen, tales como sistemas de redis que se va a almacenar los datos en un sólo anexar registro para la reproducción, pero se corre el riesgo de corrupción en los niveles más bajos, por ejemplo, si su sistema de archivos es revueltos, a continuación, los datos en el disco está potencialmente en riesgo.

Agradezco cualquier mejora podría ser útil para usted, pero realmente el problema no es uno que puede ser resuelto dada la situación que he descrito.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: