Workers Control, system pattern
Cybermen - SPC (Services Platform in Cluster) es una plataforma de servicios y clúster de procesamiento distribuido, orientado principalmente al desarrollo de aplicaciones de supervisión, control y adquisición de datos (SCADA) y de control distribuido (DCS).
Cybermen de por sí, no hace a las aplicaciones SCADA o DCS, pero constituye una base para el desarrollo de este tipo de soluciones, basándose para las mismas en una arquitectura de servicios y operando en un clúster de procesamiento.
Para poder cumplir con estos objetivos, fue necesario repensar el "patrón" de director de procesos empleado como base en los sistemas DCS, para que el mismo fuese funcional en un clúster variable.
Este "patrón" (el de director de procesos), básicamente, trata de ver al piso de planta, de la misma forma en que un director observa a una orquesta sinfónica.
Cada instrumento en la orquesta posee sus propios tonos (información) acordes (funcionalidad) y partitura (siclo de proceso)
Es entonces la tarea del director de orquesta, indicar a cada instrumento (caudalimetros, balanzas, barreras, puertas, portones, lectores HID, lectores RFID, PLC, RPC, sistemas de negocio acoplados, y demás instrumentos) cuando, como y desde que parte, deben ejecutar su partitura, para que toda la planta opere al ritmo de la misma sinfonía.
Cada instrumento (o el músico / operador / Worker del mismo) por su parte, posee las capacidades de observar las instrucciones del director, ejecutar el programa indicado, y por final del mismo esperar una nueva orden por parte del Controller.
Cada Worker además, posee la capacidad de indicar un problema al Controller (se cortó una cuerda del violín, la quinta tecla del piano no funciona, falla eléctrica, sensor óptico de entrada en falla, etc.) en cualquier momento (y mientras el evento de falla persista), para que este decida el mejor curso de acción conforme a su propio programa.
Por su parte, cada Worker decidirá (conforme a su propio criterio / procedimiento / programación) si ante esa falla puntual, es capaz de seguir operando o debe entrar en siclo de "parada critica".
Se entiende que si es el propio director de orquesta (Controller) el que entra en falla (le dio un infarto) todos los músicos bajo su mando entraran en "parada critica".
En sistemas críticos, el tiempo de duración de este evento suele minimizarse al tener un segundo director (y hasta un tercero) observando a la orquesta por medio del director titular. De esa forma, no solo está en capacidad de relevar al Controller primario en el momento en que este se infarte (expulsándolo del púlpito), sino además de proseguir con la pieza musical desde el mismo punto en el que estaba antes de la falla. O al menos en teoría..
El principal problema de este enfoque, suele estar (por un lado) en tener que pagarle el sueldo a una o dos personas / servidores (director suplente y segundo suplente) por no hacer nada. Y (por el otro) que si el problema no es el director, sino el púlpito (el rack de servidores) no resolvimos nada.
Lo ideal sería no contar con un director, o mejor aún, que el Controller sea uno de los Worker. De esa forma (y ya sea porque al Controller le dio un infarto, o la orquesta no logra verlo como a un director), automáticamente otro Worker ocupe el papel de Controller desde otro lugar de la planta, cambiando tanto de púlpito (ahora el asiento del músico en la orquesta o nodo de procesamiento de un clúster) como de director.
Lo ideal, sería no contar con un solo Controller, si no poseer uno por cada grupo o familia de instrumentos operando desde el mismo nodo de procesamiento o (mejor aun) desde distintos nodos del clúster y de esa forma obtener un balanceo de carga.
Lo que acabamos de describir, es la definición conceptual del "patrón" Workers Control implementado en Cybermen, y disponible para aquellos servicios que implementen la interfaz ClusterService.
Estos servicios harán las veces de Controller, del mismo servicio, desde uno y solo uno de los nodos del clúster.
Como Controller, su tarea es ordenar la ejecución de los métodos del mismo servicio en el resto de los nodos de procesamiento (Workers) por medio de llamadas RPC.
Si el Controller desaparece del clúster de procesamiento, automáticamente otro tomará su lugar.
Si ese nodo reaparece (o si un nuevo nodo se suma al clúster) lo harán como Worker, no como Controller
Si un Worker desaparece del clúster (o se suma al clúster), le toca al Controller como director de procesos reordenar las tareas en ejecución conforme a sus propias reglas de negocio y la capacidad de procesamiento total disponible.
Dado que el modelo de comunicación para las notificaciones de eventos por cambio de constitución en el clúster es multipunto. Todos los nodos del clúster (Controller y Worker's), son notificados del evento de manera independiente.
Aquellas personas que conozcan los sistemas DCS podrán decir (y en el mejor de los casos) que lo descripto hasta el momento es de un reduccionismo extremo, debido a que estos sistema se ordenan en estructuras jerárquicas de maestro esclavos.
Lo cierto, es que cada maestro en la jerarquía se diferencia de otro en cuanto a información, funcionalidad, modelo de comportamiento o las tres cosas.
Por lo que en Cybermen deberán representarse como una serie de servicios interconectados por medio de una jerarquía de Workers Control
Como comentario final,
Es de destacarse que en instalaciones de alta complejidad, criticidad, o riesgo potencial, como es el caso de reactores nucleares, refinerías, fabricas de explosivos o fertilizantes (y solo por citar algunas de ellas). El foco está puesto en la confiabilidad, estabilidad, redundancia de controles y de hardware e infraestructura (tanto de procesamiento como de comunicaciones) en cada eslabón de la cadena de control.
De hecho el tipo de hardware e infraestructura empleado en esta clase de instalaciones y que está probado, homologado y certificado, poseen su propia plataforma de DCS , la cual forma parte de su certificación.
Cybermen, (como plataforma de servicios y clúster de procesamiento distribuido) bajo ningún concepto pretende reemplazar ese tipo de infraestructura o apunta a ese tipo de dependencias de alta criticidad y riesgo elevado.
De hecho, y por estar vasado en Java SE, Cybermen no solo es cross-platform, sino que al mantenerse dentro de Standard Edition y operar con un numero acotado de dependencias externas, funciona con bajos requerimientos de hardware. Tanto, que sus nodos de procesamiento son capases de operar en hardware con soporte para Java SE Embedded
Por lo que se vuelve ideal para soluciones a medida, de bajos recursos o de aplicaciones embebidas. Como es el caso de las capas de integración para sistemas de control de acceso, seguridad patrimonial, automatización de control de mercadería, telepeaje, estacionamiento medido, u otras dentro de esta línea.
Reader Comments (3)
Me ha interesado mucho este articulo, pero no soy capaz de encontrar ningún producto o proyecto relacionado con el.
Estoy haciendo búsquedas con combinaciones de Cybermen, DCS, ClusterService, java, etc. y solo me aparece el propio articulo.
Podrían por favor proporcionarme alguna referencia concreta (URL) sobre un producto o proyectos para poder seguir informándome sobre este asunto?
Hola, muy interesante, ¿Podrias poner algun link, por favor?
Ernesto.
Hola,
El objetivo de esta nota, no estaba en presentar a Cybermen - SPC como plataforma y herramienta de desarrollo (esto ocurrirá pronto).
Si no a Workers Control como un patrón de diseño alternativo al de director de procesos, que se emplea (de una u otra forma) para los sistemas de control distribuido.
De hecho la nota se pensó con miras a tres perfiles distintos,
Por un lado los responsables de logística, operaciones y laboratorio, quienes deben decidir o aprobar cuando y como van por una automatización completa, por un procedimiento manual o una mescla de ambos. Y esto en función de la confiabilidad, agilidad y estabilidad, tanto de los procedimientos como de la información que generan, al igual que de los costos operativos y de mantenimiento de los mismos.
Y por otro, a la gente de proyectos e instrumentación (por un lado) y de sistemas (por el otro) quienes tienen concepciones muy distintas de lo que es un desarrollo, como debe encararse y ejecutarse.
De allí esta idea de utilizar a una orquesta sinfónica como pivot para girar conceptos de uno a otro mundo y tratar de explicar como se pasa de una estructura de procesamiento jerárquico, con redundancia controlada, a un clúster elástico, y basándose en SOA.