Nota previa:
Si bien lo descrito en este documento sigue vigente a nivel de montaje y configuración, desde un punto de vista de operaciones, a partir de Cimplicity v2024 hay cambios importantes en el comportamiento de la redundancia.
Aconsejamos revisar la documentación específica: Cimplicity v2024 - Redundant Configuration Update

Requerimientos previos de la redundancia
  • A nivel de licenciamiento
    • La licencia del servidor principal ha de tener capacidad de "development" y debe contar con la opción de "redundancy"
    • La licencia del servidor secundario ha de tener las mismas características que la del primario (con la excepción de que puede ser "runtime". No es necesario que tenga capacidad de "Development")
      Además de lo dicho anteriormente, puede ser una licencia del tipo "backup", lo que implica un 50% del coste de una licencia normal
  • A nivel de hardware, necesitaremos un PC idéntico al PC del servidor principal
    • Ambos servidores deben ser idénticos (disco, memoria, CPU, NIC, etc)
      • En un estado “estable”, ningún PC de la red Cimplicity debe sobrepasar el 40% de CPU ni un 10% de la memoria asignada
      • En un estado “estable”, no debe haber “page faulting” en la gestión de memoria
    • A nivel de conexión en red
      • Primario y secundario han de estar conectados al mismo switch o hub
      • Ping entre primario y secundario de menos de 10ms.  Entre viewer y server menos de 30ms.
      • Direcciones IP fijas en ambos servidores
      • Servidores y Viewers deben tener direcciones IP y nombres de máquina configurados en los respectivos archivos “host” de Windows (o en el servidor de DNS en caso que lo haya)
        Idealmente, todos deberían estar en la misma red
    • Ambos servidores deben tener la hora bien sincronizada (servidor de tiempos común)


Notas sobre la configuración de la Redundancia

Consideraciones Generales
En lo que a los detalles de la configuración se refiere, hay varias cosas a tener en cuenta. Pueden diferir ligeramente en función de la versión de Cimplicity que se esté usando. Yo en este caso voy a utilizar inicialmente la documentación de Cimplicity v10.0 (y ya saltaremos a la versión que sea, en cuanto me confirméis con cuál estáis trabajando)
  • Vale la pena aprovechar para actualizar el sistema a la última SIM disponible (se instalaría en ambos servidores y también en todos los clientes)
    Las pueden descargar gratuitamente en https://digitalsupport.ge.com
    En el caso de Cimplicity v10, la SIM más reciente sería esta
  • Es muy importante entender que SIEMPRE trabajaremos sobre el servidor primario (el que es recomendable que utilice una licencia con "development").
    Si la configuración de la redundancia es la correcta, los cambios se propagarán automáticamente al secundario, por lo que NUNCA deberemos editar directamente la configuración del servidor secundario o de backup
  • Limitaciones impuestas por la redundancia:
Activar la redundancia en el proyecto Cimplicity:
Global Parameters para gestionar la “Server Redundancy”
Existen 5 parámetros globales de proyecto que permiten definir detalles sobre el comportamiento de la redundancia:
  • REDUND_LINK_SLEEP 
    Tiempo de espera antes de que el Router cree un enlace al nodo latente (“standby” server)

  • REDUND_PROBE_COUNT 
    Número de bits de vida perdidos antes de lanzar el proceso de basculación (“failover”)

  • REDUND_PROBE_DELAY
    Tiempo entre bits de vida

  • REDUND_PROBE_PORT
    Puerto TCP/IP para implementar el intercambio de bits de vida entre servidores

  • SECONDARY_STARTUP_TIMEOUT
    Demora en el tiempo de arranque del servidor latente (“standby”) cuando se produzca un arranque de proyecto en ambas máquinas de forma simultánea.

Sobre los permisos entre los 2 servidores
En PCs que estén en Workgroup, es posible que a la hora de arrancar un proyecto (desde el primario) éste no tenga derechos para arrancar los servicios en el PC secundario.
Para resolver esto es necesario desactivar UAC y habilitar un servicio denominado “remote registry”.
Este enlace da indicaciones sobre cómo hacer esto en cada caso, junto con una serie de verificaciones a realizar en caso de problemas con la redundancia 

Sobre del Datalogging en SQL (si lo hubiere)
En condiciones normales, ambos servidores guardan alarmas (o points) en sus respectivas destinaciones ODBC. 
Es necesario que cada servidor tenga su propia BDD, que se llamen ambas igual, pero que los ODBC tengan nombres distintos en cada servidor.
Cada servidor debe tener DSN apuntando a su propia BDD y también DSN apuntando a la BDD del compañero.

Si uno de los servidores vuelve de un paro, es necesario ejecutar la utilidad “datamerge.exe” para sincronizar ambas bases de datos 

Database Logging in Server Redundancy
Re-synchronize (Datamerge) Database Logging Files


Fuentes de información adicionales

Atentamente,