¿Cómo funciona el failover SCADA?

Volver al glosario

Detectar que el primario ha fallado

El failover empieza con la detección, y la detección es deliberadamente cautelosa porque cambiar cuando en realidad nada andaba mal es su propia clase de falla. El respaldo vigila el primario a través de un latido continuo llevado sobre el enlace dedicado entre ellos, más verificaciones de salud que confirman que el primario no solo está vivo sino realmente haciendo su trabajo - sondeando el campo, sirviendo clientes, y escribiendo al historiador. Un solo latido perdido no basta para actuar, porque un breve tropiezo de red puede causar uno. En su lugar el sistema espera una serie de latidos perdidos o una verificación de salud fallida sobre un intervalo definido antes de concluir que el primario está genuinamente caído.

Esta ventana de detección es un compromiso de ajuste. Fíjela demasiado corta y el sistema se vuelve nervioso, haciendo failover ante fallos transitorios y causando disrupción innecesaria. Fíjela demasiado larga y los cortes reales se arrastran mientras todos esperan el cambio. Los buenos diseños también distinguen entre tipos de falla: un primario que se ha caído del todo es un caso claro, pero un primario que está corriendo pero no puede alcanzar el campo o ha perdido el enlace de sincronización es más turbio, y la lógica tiene que evitar confundir un problema de comunicación entre los dos nodos con un primario muerto - la situación que puede llevar a un split-brain si ambos nodos concluyen que el otro se fue.

Decidir cambiar y entregar el control

Una vez que la detección concluye que el primario ha fallado, el sistema se compromete al cambio. El respaldo se promueve a primario: toma el rol de primario, empieza a sondear activamente los dispositivos de campo, y comienza a servir como la fuente autoritativa de la imagen del proceso. En un arreglo de hot standby este traspaso es rápido y limpio porque el respaldo ya sostiene una copia actual del estado - los valores de tag, las alarmas activas, y los búferes de tendencia cruzan así que nada tiene que reconstruirse. En arreglos más tibios o fríos el nuevo primario primero debe ponerse al día, reconectándose al campo y reconstruyendo una vista precisa antes de que se pueda confiar en él, lo que estira el traspaso de segundos a minutos.

Una parte crucial de decidir cambiar es asegurar que solo un nodo termine como primario. Si tanto el primario como el respaldo de alguna forma creen que deben estar a cargo - típicamente porque el enlace entre ellos se rompió en lugar del primario mismo - ambos podrían empezar a comandar el campo, lo cual es peligroso. El failover robusto por lo tanto se apoya en un desempate como un testigo de quórum, o en rutas de latido redundantes, para que la decisión de promover el respaldo solo se tome cuando el sistema pueda estar seguro de que el primario viejo está de verdad fuera de servicio y no seguirá actuando como uno.

Reconectar operadores y dispositivos de campo

Un failover completado no termina hasta que todo lo que hablaba con el primario viejo esté hablando con el nuevo. Los clientes operadores necesitan seguir el rol de primario hasta el servidor de respaldo, lo que por lo general se maneja apuntando los clientes a una dirección compartida o a una conexión consciente de la redundancia para que se reconecten automáticamente en lugar de necesitar que un operador inicie sesión en otro lado. En un sistema bien construido el operador ve poco más que una breve reconexión y quizá un indicador de estado que anota que el respaldo ahora está activo; las pantallas, tags y lista de alarmas que estaba mirando regresan pobladas porque el nuevo primario cruzó el estado. Del lado del campo, las RTU y PLC que reportaban al primario ahora deben ser sondeados por el nuevo primario, que o toma el mismo endpoint de comunicación o restablece sus propias sesiones con los dispositivos.

Aquí es donde el failover SCADA difiere del failover solo de comunicaciones como el failover celular. El failover celular intercambia un enlace de red roto por un enlace de respaldo y se limita a la conectividad - el mismo servidor sigue corriendo durante todo el proceso. El failover SCADA reemplaza el servidor o aplicación que es el cerebro del sistema supervisorio, así que tiene que mover un rol en ejecución entero, su estado, y cada relación de cliente y dispositivo de una máquina a otra. Con una plataforma SCADA en la nube como Merobix, toda esta secuencia la maneja el servicio: los dispositivos de campo reportan a un endpoint de nube estable y los operadores usan una sesión de navegador que sobrevive una falla de nodo subyacente, así que una instancia saludable que ya lleva el estado en vivo toma el control sin que nadie reconecte nada a mano.

Preguntas frecuentes