Mi cliente fabrica un dispositivo médico que toma varias medidas de una muestra determinada y escribe los resultados en una base de datos. La cantidad de datos generados es relativamente pequeña.
En la configuración actual, cada dispositivo tiene su propia computadora y esa computadora ejecuta una instancia de un servidor de base de datos. Los dispositivos no están conectados en red.
El cliente quiere modificar el dispositivo de modo que aproximadamente cincuenta de ellos puedan conectarse a una red de área local.
Los dispositivos utilizan varios consumibles que están numerados en lotes y una vez utilizados no se pueden volver a utilizar. Estos números de lote se escriben en la base de datos cuando se mide una muestra. Este requisito es notable porque en la configuración actual un dispositivo no tiene forma de saber si un dispositivo diferente ha utilizado un consumible. En la configuración de red propuesta, existe la expectativa de que cada dispositivo tenga acceso inmediato a información sobre los consumibles utilizados por otros dispositivos.
Los dispositivos también necesitan rastrear la cantidad de diversos productos químicos que se utilizan en el proceso de prueba. Cada botella de producto químico tiene un lote numerado y un código de barras. Cuando se inserta una botella en la máquina, la máquina lee la base de datos para determinar cuánto líquido se ha consumido de la botella. Existe la expectativa de que se pueda insertar una botella numerada de lote en cualquier máquina y que la máquina pueda evaluar con precisión la cantidad de líquido en la botella.
El cliente quiere una recomendación sobre cuál de las dos arquitecturas se debe utilizar:
1.) Cada dispositivo escribirá datos en su propia base de datos local como lo hace ahora. Se instalará software de sincronización en cada dispositivo y la sincronización se realizará en tiempo real. Cada dispositivo transmitirá periódicamente un latido (se han propuesto intervalos de 1 a 5 minutos) y este latido contendrá una suma de verificación CRC. Todos los dispositivos de la red escucharán los latidos del corazón. Un dispositivo iniciará una sincronización si el CRC del latido difiere del suyo. El software de sincronización debe ser externo e independiente del software que ejecuta las pruebas. Por lo tanto, es teóricamente posible, pero no probable, que un dispositivo se ejecute mientras está desconectado de la red o mientras el software de sincronización no se está ejecutando.
2.) Se eliminará el servidor de base de datos de cada dispositivo y en su lugar se utilizará un servidor de base de datos.
Al cliente le preocupa que si se utiliza un servidor de base de datos, todos los dispositivos de la red quedarán inutilizables en caso de falla del servidor. ¿El uso de una topología de pares mitiga eficazmente este riesgo? En otras palabras, si un par de la red falla, ¿el resto de pares sigue como de costumbre? ¿Hay algún peligro o beneficio para la integridad de los datos asociado con cualquiera de los enfoques?
Edite en respuesta a las respuestas de iag y MikeyB:
Puedo ver cómo mi pregunta deja lugar a la ambigüedad, así que aquí está nuevamente, con suerte redactada de una manera más significativa.
En un entorno cliente-servidor, la falla del servidor es catastrófica porque si el servidor falla, todos los clientes se apagan. Dada esa característica de diseño, ¿por qué algunos sistemas médicos, financieros, de inventario y de información altamente críticos implementan una arquitectura cliente-servidor en lugar de una arquitectura de igual a igual?
Tenga en cuenta que NO estoy preguntando "¿Cómo mitigo el riesgo de falla del servidor?" ESTOY preguntando "¿Es la arquitectura peer-to-peer una forma eficaz de mitigar el riesgo de fallo del servidor?" ¿Por qué o por qué no? ¿La topología de la red influye en el diseño de la aplicación? ¿El intercambio entre pares introduce la posibilidad de corrupción de datos o resultados ambiguos?
¿Es el siguiente un ejemplo realista de lo que podría ocurrir en una topología de red peer-to-peer?
DeviceA, DeviceB y DeviceC son computadoras en una red de pares que comparten un agente común llamado agente R. Siempre que un par necesita verificar cuánto R está disponible, se sincroniza con otros pares y calcula la disponibilidad. Un día, aproximadamente a la 1:00 p.m., el técnico de laboratorio inserta una botella de R en el DispositivoB. DeviceB se sincroniza inmediatamente con DeviceC y confirma que DeviceC nunca ha consumido R de esa botella. El dispositivo A, sin embargo, no ha respondido a los pings desde el mediodía. ¿Puede DeviceB calcular de manera confiable la cantidad de R disponible en la botella?
Soy ingeniero de software y escribiré la aplicación que permite a estos dispositivos compartir datos a través de una red. Sinceramente tengo una opinión sobre la pregunta que hago pero mi cliente no confía en mi experiencia. Quiero conocer la experiencia de mis compañeros, de ahí mi publicación aquí. No quiero poner palabras en boca de nadie, así que intento no ser lo más general posible y aun así explicar el problema.
Respuesta1
Una arquitectura de software de igual a igual puede ser una forma eficiente y tolerante a fallas de difundir información entre nodos, suponiendo que ya tenga redundancia en la red subyacente.
La arquitectura peer to peer también puede protegerlo contra la pérdida de datos si varios nodos conservan los datos. En los sistemas típicos de igual a igual, los nodos guardan datos debido a su propio interés. Lo que desea es diferente, ya que desea que conserven los datos debido a que se adhieren a una política y no a un interés individual.
Cada nodo almacena todo lo que vio es simple siempre que la cantidad de datos sea limitada. Pero almacenar todo puede no ser práctico debido al espacio de almacenamiento (o en algunos escenarios debido a requisitos legales). Entonces hay que tener cuidado con qué eliminar y qué conservar. Éste es uno de los mayores escollos.
Pero todo esto no contribuye en nada a abordar la cuestión de la integridad y la coherencia de los datos. Si simplemente cambia a una arquitectura peer to peer sin pensar en la exactitud de los datos, entonces la solidez del sistema a ese respecto disminuirá. Simplemente hay muchos más lugares donde se puede introducir la corrupción.
Para implementar una solución de este tipo, es necesario descubrir cómo validar la integridad de un dato.
Un dato que sólo puede ser actualizado por un nodo específico del sistema es el más fácil de manejar. Pero aún hay que preguntarse cuál es el comportamiento aceptable del sistema, si ese nodo comienza a comportarse mal. Hacer que el nodo firme criptográficamente cada actualización no es suficiente, si podría enviar erróneamente una actualización firmada para eliminar todo lo que escribió anteriormente o enviar múltiples actualizaciones firmadas que no estén de acuerdo sobre cuál es el nuevo valor de los datos. Una vez más, un enfoque simple es almacenar todo y requerir intervención manual, si aparecen actualizaciones conflictivas. Pero si alguna vez necesita tomar algún tipo de decisión automatizada basada en los datos, entonces eso es insuficiente.
Si solo un nodo puede actualizar los datos, pero usted tiene un requisito estricto de que todos los demás estén de acuerdo sobre qué actualización realizó, entonces el problema se vuelve un poco más difícil.
La solución a este problema todavía no es extremadamente complicada y da una buena idea de los tipos de métodos utilizados para resolver dichos problemas de integridad de datos.
- El nodo de actualización firma datos actualizados y los distribuye a través de la red de igual a igual
- Los nodos receptores firman la primera versión recibida y la envían de regreso al nodo de actualización
- Una vez que el nodo de actualización tiene firmas de más de 2/3 de todos los nodos (incluido él mismo), distribuye los datos a través de la red de igual a igual nuevamente con la recopilación de firmas.
- Cada nodo que reciba esta versión validada por firmas de 2/3 seguirá retransmitiendo (con retroceso exponencial) a todos los nodos que aún no hayan confirmado que han almacenado permanentemente la versión final de los datos.
El nodo al que se le permitió enviar la actualización en primer lugar podría fallar de manera que impidiera que los datos se actualizaran nuevamente. Pero siempre que envíe una actualización consistente, terminará almacenándose de manera consistente en toda la red de igual a igual.
Puede parecer que la gran cantidad de firmas necesarias en cada dato requerirá mucho espacio de almacenamiento. Afortunadamente, esto se puede evitar mediante un método conocido como firmas de umbral.
Pero si desea reemplazar una base de datos, no es suficiente que un nodo pueda actualizar un dato. Tiene varios nodos, a los que se les permite actualizar el mismo dato, pero necesita que toda la red se ponga de acuerdo sobre quién fue primero. Aquí es donde el acuerdo bizantino entra en escena.
Las soluciones a esto son un orden de magnitud más complicadas que las que describí anteriormente. Pero puedo mencionar algunos resultados clave a tener en cuenta.
Hay que elegir entre dos modelos de fracaso. Se puede suponer que un nodo defectuoso simplemente deja de comunicarse y nunca envía un solo mensaje corrupto. Este modelo requiere menos hardware, pero solo se necesita un bit invertido para desactivar el sistema.
Alternativamente, puede elegir el modelo de falla bizantina, que permite que un nodo defectuoso haga cualquier cosa y el sistema aún sobrevivirá. Para tolerar tfallas en este modelo, necesita 3t+1nodos en total. En otras palabras, para tolerar un único nodo defectuoso se necesitan cuatro nodos. Si tiene 10 nodos en total, es posible tolerar el fallo de 3 nodos.
También hay que elegir entre el modelo de comunicación síncrono o asíncrono. La comunicación sincrónica significa que usted hace suposiciones sobre el momento de la comunicación. Si los paquetes tardan más de lo previsto en llegar a su destino, el sistema falla. Además, si un nodo falla, debe esperar el retraso máximo permitido antes de que el sistema pueda continuar.
Los modelos asincrónicos complican el diseño del software, pero tienen algunas ventajas claras. No tiene que esperar a que se agoten los tiempos de espera, sino que simplemente debe esperar hasta haber recibido noticias de más de 2/3 de los nodos antes de poder continuar; esto puede ser mucho más rápido que un modelo sincrónico en el que necesita un tiempo de espera grande.
Otro inconveniente del modelo asincrónico es que debe ser aleatorio. El tiempo de ejecución del algoritmo se convierte en una variable estocástica sin límite en el peor de los casos. Existe una posibilidad teórica de que una actualización tarde un tiempo infinito, pero se puede demostrar que la probabilidad de que esto ocurra es cero. Y, de hecho, se puede demostrar que el número medio de viajes de ida y vuelta de comunicación es constante. Para mí, esto parece mucho más favorable en comparación con el modelo sincrónico, que puede fallar en caso de retraso en la comunicación.
Como puedes imaginar, lograr que un sistema de este tipo funcione correctamente no es una tarea fácil. Se necesita un esfuerzo de desarrollo dedicado para implementar esto. Además, un error de software aún puede provocar la caída del sistema. Si fallan menos de un tercio de los nodos, el sistema sobrevivirá. Pero si existe un error en el software, es muy posible que instale ese software defectuoso en más de un tercio de los nodos.
Respuesta2
Veo muchos problemas posibles aquí.
En primer lugar, se le han proporcionado dos soluciones a medias para su consideración, que son difíciles de gestionar tal como se presentan e intolerantes a fallos.
En segundo lugar, parece estar confundido sobre cómo construir servicios de datos. Esto es más preocupante.
No estoy seguro de cuál es su situación de compromiso con el entorno descrito, pero recomendaría no hacer nada y tener mejores requisitos definidos y un mejor plan para lograrlos que cajas aleatorias que ejecutan muchas bases de datos sin copias de seguridad (en vivo o no).
Si su preocupación es el inventario de laboratorio, existenlotesde software que se ocupa de esto. Si está trabajando con rarezas patentadas de un proveedor, establezca sus requisitos ambientales, encuentre una manera de acceder y retener estos datos con cierto nivel de seguridad. Os aseguro que ya se ha hecho antes.
Nada de esto sucederá si publicamos preguntas vagas exclusivamente en este foro. Si se siente fuera de su alcance, debería dedicar unas horas a un consultor para que le ayude.
Respuesta3
En el entorno dado, parece esencial que exista una única fuente de información para los datos. ¿Es eso cierto? No podemos decirlo.
Siempre habrá puntos de falla; es necesario diseñar en torno a lo que es aceptable.
Tienes que idear las limitaciones de tu sistema. ¿Debe haber una única fuente de datos? ¿Puede un dispositivo utilizar el inventario sin conexión? ¿Se puede tolerar la falla de un solo servidor? ¿Puede el sistema tolerar el funcionamiento en modo de sólo lectura durante un breve periodo de tiempo?
Una vez que tenga esas restricciones, encontrará que elcómode diseñar el sistema surge de las restricciones.