Comportamientos esperados cuando se producen fallos
En este tema se describen las acciones que se producen en una configuración de agrupación de ThingWorx como respuesta a un fallo de uno o más de los componentes.
Fallos del equilibrador de la carga
Las acciones y los resultados dependerán de la solución de alta disponibilidad implementada del equilibrador de la carga. Las sesiones activas no se deben interrumpir si el equilibrador de la carga tiene la capacidad de compartir el contenido de la sesión entre todos los nodos del equilibrador de la carga.
Fallo del servidor HAProxy
Si falla el único nodo de HAProxy o todos los nodos de HAProxy, sucede lo siguiente:
• El nodo principal de ThingWorx seguirá siendo accesible a través de su dirección IP, pero no a través de la dirección IP de HAProxy.
• Las solicitudes para ThingWorx realizadas a través de HAProxy no alcanzarán a ThingWorx.
Si falla uno de varios nodos de HAProxy, sucede lo siguiente:
• Las sesiones de usuario existentes se reconocerán en ThingWorx Composer una vez que la copia de seguridad de HAProxy se convierta en la instancia maestra. El usuario no tiene que volver a conectarse.
• Los mashups no se cargarán hasta que la copia de seguridad de HAProxy se convierta en la instancia maestra.
• Las entidades de inspección de Composer no se cargarán hasta que la copia de seguridad de HAProxy se convierta en la instancia maestra.
• Las solicitudes no alcanzarán ThingWorx hasta que la copia de seguridad de HAProxy se convierta en la instancia maestra.
Fallos del servidor ThingWorx
Cuando un servidor de ThingWorx falla, se produce lo siguiente:
• El servidor se quita del equilibrador de la carga, ya que el ping de verificación de integridad fallará. El tiempo de eliminación depende de la frecuencia de verificación.
• ZooKeeper detectará que el servidor ha fallado, lo quitará de la detección interna de servicios y lo notificará a los observadores, como Connection Server.
• Si se trata del servidor singleton, ZooKeeper lo notificará a los demás servidores y seleccionará un nuevo servidor singleton.
Los clientes conectados al servidor pueden recibir errores durante la conmutación, pero luego se reconectarán a un servidor nuevo.
Es posible que se pierdan datos en un fallo de servidor o si se anula el servidor. En estos casos, se perderán los datos de las colas de lotes. Si el servidor se cierra en lugar de fallar, lo anterior ocurre al anular el registro del servidor y purgar las colas de lotes.
Los nodos de ThingWorx Platform están inactivos
Siempre y cuando al menos una instancia de Platform se encuentre en buen estado, otros nodos se pueden reiniciar sin afectar al sistema. Sin embargo, si todos los nodos de Platform se quedan inactivos o en un estado incorrecto, el estado almacenado en Ignite se volverá incoherente. En este caso, es necesario detener todos los nodos de Platform y detener todos los nodos de Ignite antes de reiniciar.
1. Detener todos los nodos de Platform.
2. Detener todos los nodos de Ignite.
3. Reiniciar todos los nodos de Ignite.
4. Reiniciar todos los nodos de Platform.
Si no se reinicia Ignite, los mapas de enlace y otros datos almacenados en Ignite no serán correctos y provocarán comportamientos extraños a lo largo del tiempo.
Fallos de ZooKeeper
Fallo de nodo
Si falla uno de los nodos ZooKeeper, sucede lo siguiente:
• Los demás nodos de ZooKeeper detectan el fallo para responder.
• Se elige un nuevo nodo principal de ZooKeeper si el nodo fallido era el principal.
Fallo de varios nodos
Si fallan varios nodos y ZooKeeper pierde su quórum, se colocará en modo de solo lectura y se rechazarán las solicitudes de cambios.
• No se puede realizar la elección de nodo principal de ZooKeeper ya que la configuración original de tres nodos de ZooKeeper espera que estén disponibles dos servidores para tener quórum. Máximo de fallos permitidos = ceil(N/2) - 1
• Las instancias de ZooKeeper restantes no son instancias principales ni en espera.
• Todos los clientes recibirán el estado SUSPENDED y finalmente LOST.
Servidores ThingWorx
• El rol de singleton estará sin asignar mientras esté en el estado SUSPENDED. Durante este tiempo, no se ejecutarán temporizadores ni programadores.
• En el estado LOST, se cerrarán todos los nodos.
• Si ZooKeeper se recupera antes de que se agote el tiempo de espera del sistema, se elegirá un nuevo singleton y el procesamiento continuará.
Connection Server
• Si Connection Server obtiene un estado LOST de ZooKeeper, se cerrará, porque no conoce el estado de los servidores ThingWorx.
Ignite
• Se supone que el clúster de ZooKeeper siempre está visible para todos los nodos del clúster. Si un nodo se desconecta de ZooKeeper, se cierra, y los demás nodos lo tratan como fallido o desconectado.
Fallos de Ignite
El impacto de los fallos de Ignite se basa en el nivel de replicación de datos. Ignite siempre debe configurarse para almacenar datos en al menos dos nodos del clúster. Por lo tanto, si se pierde algún nodo, no hay ningún impacto en el sistema.
Si se pierden varios nodos, es posible que se pierdan datos, lo que puede dejar al sistema en un estado incoherente. Si ocurre esto, se recomienda el cierre completo de Ignite y ThingWorx. A continuación, se puede reiniciar Ignite y ThingWorx. Ignite es la memoria de la aplicación y, si se pierde, el comportamiento del procesamiento puede ser muy incoherente.
Si hay un fallo total de Ignite en el que ThingWorx no se pueda conectar a ningún nodo de Ignite, ThingWorx se cerrará.
Para obtener información sobre las copias de seguridad de datos, consulte lo siguiente:
Fallos de PostgreSQL
Esta explicación de los fallos de PostgreSQL se basa en la siguiente configuración:
• Tres nodos de PostgreSQL (escritor, lector y en espera)
• Uso de la replicación de flujo entre nodos de PostgreSQL
• Dos nodos de Pgpool-II que gestionan el acceso del cliente a los nodos de PostgreSQL y gestionan los procedimientos de recuperación de PostgreSQL.
Si falla un servidor PostgreSQL, el nodo de Pgpool-II activo detecta el fallo y detiene las solicitudes de distribución a ese servidor. Los datos de usuario o de dispositivo que se guardan en el momento del fallo se pueden perder si la información no se ha confirmado y replicado en otros nodos antes del fallo.
Cuando se produce un error en el nodo maestro de PostgreSQL (suponiendo que la sincronización y los nodos potenciales estén en funcionamiento), sucede lo siguiente:
• La conmutación por error al nodo de sincronización se produce a través de Pgpool-II. El nodo potencial se convierte ahora en el nodo de sincronización para el nuevo nodo maestro. Las escrituras en la base de datos siguen siendo posibles (como la creación de entidades nuevas y la escritura de datos en BDWS).
• Si el maestro original vuelve a activarse, es necesario limpiar y configurar manualmente el entorno para utilizar el maestro original.
Cuando ambos nodos en espera fallan (suponiendo que el nodo maestro esté en ejecución), sucede lo siguiente:
• No se produce ninguna conmutación por error y el nodo maestro debe tener cero nodos para la replicación.
• Composer seguirá siendo accesible. Las entidades se cargarán y se podrán ver, pero no guardar. Se pueden ver los registros.
• Las acciones que requieren escritura en la base de datos (como la creación y el almacenamiento de una entidad, la definición de valores en propiedades persistentes y la adición de una entrada de flujo) no se realizarán correctamente, puesto que PostgreSQL debe replicar los datos en un nodo en espera.
Cuando el nodo maestro y el nodo en espera de sincronización fallan, sucede lo siguiente:
• Se produce una conmutación por error al nodo potencial. El nodo potencial es ahora el nodo maestro con cero nodos para la replicación.
• Se podrá acceder a Composer. Las entidades se cargarán y se podrán ver, pero no guardar. Se pueden ver los registros.
• Las acciones que requieren escritura en la base de datos (como la creación y el almacenamiento de una entidad, la definición de valores en propiedades persistentes y la adición de una entrada de flujo) no se realizarán correctamente porque las escrituras se bloquearán y finalmente fallarán.
Cuando fallan los tres nodos, sucede lo siguiente:
• La conmutación por error no se producirá porque no hay nodos disponibles.
• Composer no tiene acceso a la base de datos. Por lo tanto, las entidades no se cargarán, la mayoría de los servicios no funcionarán (puede que los servicios de subsistema, como el subsistema de plataforma, sigan funcionando) y la funcionalidad del sistema estará limitada (puede que los registros, la supervisión del sistema y los mashups funcionen).
• No se permitirán operaciones de escritura ni lectura en la base de datos.
Fallo de ThingWorx y PostgreSQL
Cuando el nodo principal de ThingWorx y el maestro de PostgreSQL fallan, sucede lo siguiente:
• La instancia de ThingWorx en espera se convierte en principal después de que la principal de ThingWorx se desactive y el nodo de sincronización de la base de datos de PostgreSQL se convierte en el nodo maestro de PostgreSQL.
◦ El nodo potencial de la base de datos de PostgreSQL se convierte en el nuevo nodo de sincronización.
◦ ThingWorx Composer está disponible y se pueden realizar escrituras en la base de datos de PostgreSQL (se pueden crear, editar y borrar entidades, y se pueden añadir datos).
• Si se debe redefinir el nodo maestro de PostgreSQL original como nodo maestro, se deben limpiar manualmente los nodos de PostgreSQL y Pgpool-II.
Fallo del nodo de Pgpool-II
Fallo del nodo activo de Pgpool-II
Si el nodo activo de Pgpool-II falla, la copia de seguridad lo detectará y se hará cargo de todas las solicitudes para los servidores PostgreSQL. Los usuarios conectados al servidor ThingWorx activo pueden experimentar demoras en sus aplicaciones y pueden perderse los datos de usuario o de dispositivo que se están guardando cuando se produce el fallo del nodo de Pgpool-II.
Fallo de todos los nodos de Pgpool-II
Cuando fallan todas las instancias de Pgpool-II, ThingWorx perderá acceso al contenido de PostgreSQL y fallarán la mayoría de las funciones. Puede que esté disponible alguna funcionalidad limitada en las siguientes áreas:
• Registro: el registro de la aplicación se puede seguir actualizando con mensajes de error.
• Supervisión del sistema (por ejemplo, el mashup MonitoringPlatformStats)
• Mashups: los widgets que no dependen de los servicios o datos de la base de datos pueden seguir funcionando.
• Valores de propiedades no persistentes
• Servicios que no impliquen la base de datos.
Fallo de ThingWorx y Pgpool-II
Cuando el nodo principal de ThingWorx y el maestro de Pgpool-II fallan, sucede lo siguiente:
• El nodo principal de ThingWorx pierde el liderazgo, por lo que uno de los nodos en espera se convierte en principal.
• El maestro de Pgpool-II pierde la dirección IP virtual. Uno de los nodos en espera de Pgpool-II se convertirá en maestro y se le reasignará la dirección IP virtual.
• El servidor en espera de ThingWorx intentará conectarse completamente a la base de datos y podrá hacerlo correctamente una vez se haya establecido el nuevo maestro de Pgpool.
• Se aplicarán el procedimiento y el comportamiento enumerados en el fallo del nodo principal de ThingWorx.
Fallo de Pgpool-II y PostgreSQL
Cuando PostgreSQL y Pgpool-II fallan, sucede lo siguiente:
• El nodo en espera de PostgreSQL se convierte en el nodo maestro.
• El nodo en espera de Pgpool-II se convierte en el nodo maestro y se le transfiere la dirección IP virtual.
• Los servicios no están disponibles momentáneamente durante la conmutación por error.