Coherencia final en la alta disponibilidad de ThingWorx
Al ejecutar ThingWorx en modo de clúster, en última instancia, los cambios del modelo se hacen coherente en todo el clúster. Los cambios en el servidor A tardan un poco en sincronizarse con los servidores B, C, etc. Para sincronizar los cambios, se registran en el elemento sync_log que se mantiene en el proveedor de persistencia de modelos de ThingWorx. Cada servidor del clúster ejecuta un servicio de observador de cambios con una frecuencia configurable (con un valor por defecto de 100 ms) y vigila los cambios de entidad en sync_log. El observador de cambios descargará y volverá a cargar las entidades que cambian en ese servidor, suponiendo que la base de datos es la fuente de veracidad. Esta coherencia final solo se aplica a los cambios de modelo y configuración, mientras que el estado es coherente inmediatamente.
• HTTP: HTTP utiliza sesiones que se pueden recordar, de modo que un usuario individual esté vinculado a un único ordenador. De este modo, se garantiza que un usuario ve todos los cambios inmediatamente. Los cambios de otros usuarios en otros servidores serán coherentes.
• WebSocket: cuando se realiza un cambio de modelo a través de un WebSocket, la versión actual del modelo se almacena en la sesión de WebSocket. Las solicitudes de WebSocket pasan por diferentes servidores para ayudar con la distribución de la carga. La siguiente solicitud realizada en esa sesión de WebSocket se pausará hasta que el servidor al que está conectado sea como mínimo la versión almacenada en la sesión. Si el servidor no se puede sincronizar en un segundo aproximadamente, se agotará el tiempo de espera.
En los siguientes escenarios se describe un impacto reducido para los usuarios:
• Escenario 1: HTTP
Dispositivo > HAProxy > Platforma1...N
En este escenario, se conecta a la plataforma 1 y se realizan cambios en el modelo. Si, a continuación, se conecta otro usuario a la plataforma 2 y se verifican los cambios, estos se terminarán mostrando. En última instancia, el clúster es coherente con los cambios de modelo mediante un proceso de sincronización. Si se trata del caso de uso del usuario, se debe integrar un reintento para esperar a que los cambios estén disponibles.
• Escenario 2: WebSocket
Dispositivo > HAProxy > CXServer1...N = > Plataforma1...N
En este escenario, el dispositivo es de punto a punto con una instancia de Connection Server. Las solicitudes de la plataforma pasarán por los servidores. Si el dispositivo realiza un cambio en el modelo y, a continuación, realiza otra solicitud que va a otro servidor, los primeros cambios se realizan allí antes del procesamiento. La solicitud se retrasa hasta que la versión del modelo se sincronice al menos con la versión en la que se ha realizado el cambio. Si no se puede sincronizar en un período de tiempo, se agotará el tiempo de espera de la solicitud. Por lo tanto, este dispositivo puede comunicarse con cualquier servidor y obtendrá la respuesta adecuada.
Si se conecta un segundo dispositivo para que vea los cambios realizados por el primer dispositivo, la coherencia final se aplica también al segundo dispositivo. Solo se garantiza que el sistema esperará cambios en una única conexión.
• Escenario 3: la solicitud HTTP para cambiar el modelo activa una notificación a un dispositivo conectado
Dispositivo > HAProxy > CXServer1...N = > Plataforma1...N
Un usuario realiza un cambio de modelo y se notifica al dispositivo del cambio para que pueda volver a extraer las definiciones. El dispositivo tenía la posibilidad de extraer los datos de un servidor que todavía no ve el cambio. Ahora, la versión del modelo se inyecta en la sesión de WebSocket, de modo que si realiza una solicitud en un servidor con una versión de modelo inferior, esperará a que se sincronice hasta al menos esa versión del modelo antes de devolver resultados. Si no se puede sincronizar en el tiempo, se agota el tiempo de espera de la solicitud.
Por lo tanto, se ha añadido un nuevo valor de postCommitEventQueue. Los eventos añadidos, tales como cambios de propiedad, se activarán después de que se haya confirmado la transacción completa y se conozca la nueva versión del modelo. Cuando se notifica al dispositivo, la versión del modelo se inyecta en la sesión de WebSocket para garantizar que las solicitudes futuras de ese dispositivo esperarán a que el servidor sea coherente con los cambios originales.
Depuración de sync_log
A medida que se realicen cambios en el modelo de cosa, sync_log crecerá continuamente hasta que se depuren las entradas antiguas. Una vez realizados los cambios en el modelo, se pueden depurar las entradas asociadas en sync_log, lo que reduce el tamaño del clúster sync_log y mejora su rendimiento y estabilidad.
La depuración de Sync_log se configura en el subsistema de agrupación en clústeres de la ficha Configuración. Para activar la depuración automática, configure la programación de depuración y configure el tamaño de lote.
|
Configuración
|
Por defecto
|
Descripción
|
|
Activar
|
Verdadero (activado)
|
Esta configuración permite activar o desactivar la depuración automática.
|
|
Programar
|
0 30 0 * * ?
|
De este modo, se define la programación de la depuración sync_log.
|
|
Batch size for purge
|
10000
|
Se indica el número de registros que se deben borrar de sync_log, empezando por el más antiguo.
|