¿Qué es un par de servidores redundantes en SCADA?

Cómo se cablean y configuran los dos nodos

Un par de servidores redundantes son dos máquinas físicamente separadas que corren el mismo software SCADA con el mismo proyecto, conectadas a propósito para poder actuar como un solo sistema lógico. Cada servidor tiene su ruta de red normal hacia los dispositivos de campo y hacia los clientes de operador, así que cualquiera de los dos puede hacer el trabajo completo. Lo que los hace un par es un enlace adicional, por lo general dedicado, entre ellos, muchas veces una interfaz de red separada en cada servidor cableada directamente al otro o a través de un switch privado, reservado para mantener coordinados a los dos nodos. Mantener ese tráfico fuera de la red general lo protege de la congestión y mantiene a los dos servidores conversando aun cuando la red más amplia esté ocupada o degradada.

Del lado de la configuración, a ambos servidores se les dice que pertenecen a un par redundante y se les da la identidad de su pareja. El proyecto se despliega idéntico en los dos para que su visión del proceso sea la misma. Los clientes de operador y, donde es posible, las conexiones hacia el campo se configuran para alcanzar al servidor que en ese momento tenga el rol primario, de modo que cuando el rol se mueve de un nodo al otro, los clientes y dispositivos siguen al primario en lugar de quedarse atorados en un servidor muerto. El objetivo de todo esto es que el par presente un sistema único y continuo a los operadores aunque en realidad sean dos máquinas turnándose.

El enlace de sincronía, el latido y la asignación de rol

El enlace dedicado entre los dos nodos lleva dos trabajos relacionados. El primero es la sincronización: el primario transmite su estado en vivo, valores de tags, estado de alarmas, datos de tendencia, al respaldo para que el respaldo se mantenga al día. El segundo es el latido, una señal continua que cada nodo usa para confirmar que el otro está vivo. Mientras el respaldo escuche el latido del primario y reciba su estado, permanece pasivo. Cuando el latido se detiene y las verificaciones de salud coinciden en que el primario realmente se fue, el respaldo concluye que debe tomar el relevo, se promueve a primario y empieza a hacer el trabajo en vivo.

La asignación de rol, decidir cuál nodo es primario, puede manejarse de varias maneras. Muchas veces un servidor se designa como primario preferido y toma ese rol siempre que ambos estén sanos, con el otro por defecto en respaldo. Tras un failover, el nodo recuperado por lo general regresa como respaldo en lugar de reclamar el primario automáticamente, para evitar una segunda interrupción. El principio importante es que en todo momento exactamente un nodo debe tener el rol primario. Un par bien diseñado hace cumplir esto para que dos servidores nunca crean ambos que son primarios y empiecen a emitir comandos en conflicto al campo, la condición de cerebro dividido que los diseños redundantes trabajan duro para evitar.

Modos de falla del par como unidad

Mirando el par como un todo, importan tres patrones de falla. El más limpio es una falla de un solo servidor: el primario muere, el respaldo lo detecta y toma el relevo, y el sistema corre en un nodo hasta que se restaura el servidor fallido. Este es el caso para el que existe la redundancia, y debería ser casi transparente para los operadores. El segundo es la falla del enlace de sincronización y latido mientras ambos servidores siguen vivos. Ahora cada nodo puede perder de vista al otro, y a menos que el diseño tenga un desempate, ambos pueden decidir que la pareja está muerta e intentar volverse primarios, un cerebro dividido. Defensas como un testigo de quórum o rutas de latido redundantes existen justo para manejar este modo.

El tercer patrón es una dependencia compartida que tumba a ambos nodos a la vez, lo que derrota al par por completo. Si los dos servidores comparten la misma alimentación eléctrica, el mismo rack, el mismo switch de red o el mismo cuarto, entonces un solo evento allí puede tumbar a ambos. Por eso un par de servidores redundantes es solo tan fuerte como la independencia de sus dos nodos, y por eso los diseños serios separan la alimentación, las rutas de red y la ubicación física. En SCADA de nube la misma lógica de emparejamiento aplica pero la maneja la plataforma: las instancias redundantes se reparten en infraestructura independiente para que ninguna falla única tumbe a ambas, y Merobix presenta el par resultante como un sistema continuo sin que el cliente cablee ni mantenga los dos servidores él mismo.

Preguntas frecuentes