arquitectura para alta disponibilidad

Question

Tengo este escenario:

Tiene una línea de proceso de fábrica que funciona 24/7. El tiempo de inactividad es extremadamente caro. El software que controla todas las partes debe usar una forma compartida de almacenamiento de base de datos La razón principal para esto es saber en qué estado está la fábrica. Por ejemplo, algunos productos pueden mezclarse cuando se usa el mismo equipo y otros DEFINITIVAMENTE .

requisitos:

• que quieren el software será capaz de detectar que un error en una parte de la planta debe resultar en una máquina de apagado más de 1 km de distancia. por lo que almacenar datos en el plc no es una opción.
• Las actualizaciones y mejoras en el entorno de fábrica son frecuentes
• carga (en términos informáticos) será realmente bajo.

El sistema maneja algunas asignaciones de hunderd por día para las cuales se realizan cálculos/verificaciones seguidas de instrucciones enviadas para las máquinas de fábrica. Los sistemas se aburrirán la mayor parte del tiempo. El requisito más importante es que el central sistema de la computadora debe ser correcto y siempre funcionando.

estaba pensando usar una base de datos basada dínamo (riak o Cassandra), donde los datos se escriben en varias máquinas con cada máquina que tiene toda la base de datos

Cuando un sistema se pone bajará unoticed. Un databse SQL tradicional puede ser más difícil de actualizar cuando las tablas cambian y este esclavo maestro es más difícil de configurar.

¿Cuál sería su solución?

La red se ha vuelto redundante y la mayoría de los otros puntos únicos de falla. El sistema de base de datos es crítico porque el tiempo de inactividad del DB significa tiempo de inactividad para toda la planta, no solo una de las máquinas, lo cual es aceptable.

• Cómo resolver el problema del estado compartido.
• complejidad en la base de datos no será un problema. Seré más como una simple tienda de valores clave para obtener la información más actualizada y correcta.

Answer 1

No creo que esta sea una pregunta sql/nosql. Todos los servidores Postgres, MySQL y MS SQL tienen algún tipo de clúster o opción de espera activa.

La configuración es algo único, pero cualquier opción NoSQL te dará dolores de cabeza desde el principio hasta el final del código, si estás tratando de hacer algo fundamentalmente relacional en una plataforma que ha dejado de relacionarse con el propósitos de ejecutar cosas como Amazon o Facebook. La configuración es una vez, la codificación es para siempre.

Así que yo diría que se quede con una solución probada y verdadera y que la replicación funcione.

Esto también proporciona una solución para las actualizaciones. La secuencia típica es "conmutar" al modo de espera, actualizar el maestro, volver al maestro, actualizar el modo de espera y reanudar. Con detalles específicos de la situación, por supuesto.

Answer 2

utilizar un RDBMS establecido que soporta de forma nativa tales cosas

¿Realmente desea ejecutar un sistema crítico 24/7 misión en algo que puede ser constante en cualquier punto en el tiempo?

Answer 3

Debe evitar los puntos únicos de error.

Todos los jugadores importantes en nuestro mundo de dbms ofrecen al menos una forma de evitar que la base de datos en sí sea un punto único de falla. Podría cuestionar si pueden propagar cambios lo suficientemente rápido para sus procesos de fabricación. (¿O la actualización de datos no es realmente un problema? Realmente no puedo decir a partir de su pregunta.) Mi trabajo de DB en la fabricación se limita al automóvil y la industria química. Microsegundos no les importaba.

Pero el dbms no es lo único que puede fallar. "Siempre trabajando" significa que los clientes siempre deben estar trabajando también. El hardware del cliente, las conexiones a la red, la red y los servidores de red en sí mismos probablemente tengan puntos únicos de falla. Los servidores tolerantes a fallas tienen múltiples fuentes de alimentación, múltiples NIC, etc.

"Siempre funcionando" es realmente costoso. Tengo la sensación de que la base de datos no será el mayor problema para su empresa.