Comportamientos esperados cuando se producen fallos
En esta sección se describen las acciones que se producen en una configuración de alta disponibilidad de ThingWorx como respuesta a un fallo de uno o más de los componentes.
Fallos del servidor ThingWorx
Falla el nodo principal de ThingWorx
Procedimiento de alta disponibilidad aprobado
1. ZooKeeper no recibe ninguna respuesta del nodo principal.
2. ZooKeeper elige un nuevo nodo principal de la agrupación de servidores en espera de ThingWorx.
3. ZooKeeper notifica al nodo en espera que se convierta en el principal.
4. El nuevo nodo principal se conecta completamente a la base de datos e inicializa el modelo de ThingWorx.
5. El nuevo nodo principal envía la confirmación al equilibrador de la carga para que todas las solicitudes de ThingWorx se ruteen hacia él.
6. El equilibrador de la carga enruta todo el tráfico de ThingWorx al nuevo nodo principal.
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 de nodo de ZooKeeper
Fallo de un nodo de ZooKeeper
Si falla uno de los tres 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.
• No se debe influir en ningún servidor ThingWorx. Permanecen activos y accesibles.
Fallo de dos nodos de ZooKeeper
• 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
• La instancia de ZooKeeper restante no es una instancia principal ni en espera.
• El nodo principal de ThingWorx se cerrará, ya que no se puede comunicar con ZooKeeper para elegir un nodo principal.
• El servidor en espera de ThingWorx seguirá intentando comunicarse con ZooKeeper hasta que al menos un nodo de ZooKeeper vuelva a estar activo.
• Cuando dos o más nodos de ZooKeeper vuelvan a estar en línea, se producirá la elección del nodo principal de ZooKeeper. El nodo en espera de ThingWorx volverá a conectarse a ZooKeeper y será el principal.
• El nodo principal de ThingWorx anterior debe reiniciarse para que sea el nodo en espera.
Fallo de ThingWorx y ZooKeeper
Cuando los nodos principales de ZooKeeper y ThingWorx fallan, sucede lo siguiente:
• Todas las condiciones que se indican en "Fallo de un nodo de ZooKeeper". En primer lugar, debe determinarse el nuevo nodo principal de ZooKeeper, para que luego elija el nuevo nodo principal de ThingWorx.
• Todas las condiciones que se indican en "Nodo principal de ThingWorx".
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.
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.