Alta disponibilidad de ThingWorx
Resumen de la alta disponibilidad de ThingWorx
Para reducir la duración de las interrupciones de los sistemas importantes de Internet de las cosas (IoT), se puede configurar ThingWorx para que funcione en un entorno de alta disponibilidad. En este manual, se describen las consideraciones de alta disponibilidad necesarias para un sistema ThingWorx y los componentes que componen una implementación de alta disponibilidad de ThingWorx.
Todas las implementaciones de alta disponibilidad requieren recursos adicionales en comparación con una implementación diseñada solo para cumplir con los requisitos funcionales y de escala. Estos recursos adicionales se basan en el hardware (como servidores, discos, equilibradores de la carga, etc.) y en el software (como los servicios de sincronización y los equilibradores de la carga). Los recursos adicionales se configuran para garantizar que no haya puntos únicos de fallo en la implementación de alta disponibilidad.
Todas las implementaciones de alta disponibilidad deben basarse en un SLA (contrato de nivel de servicio) en el que se hayan analizado los requisitos de tiempo de actividad de la aplicación para la implementación. Por ejemplo, ¿cuántas horas por mes puede estar fuera de línea el sistema? ¿Está permitido el tiempo de inactividad para fallos del sistema, para las actualizaciones de la aplicación o para ambos? El número de recursos adicionales necesarios para un sistema de alta disponibilidad depende de lo que se ha diseñado que el SLA consiga. En general, a medida que el SLA crece, también lo hace la necesidad de recursos para satisfacerlo.
Definiciones
• alta disponibilidad
Sistema o componente que está continuamente operativo durante un período prolongado de tiempo.
• activo/activo
Instancias de la misma aplicación que pueden funcionar simultáneamente.
• activo/pasivo
Una instancia de una aplicación que puede funcionar a la vez. Hay instancias adicionales disponibles y pueden hacerse cargo del servicio, según sea necesario.
• Nodo principal o maestro
El servidor activo en una configuración de alta disponibilidad activo/pasivo donde se distribuye todo el tráfico.
• en espera
Un servidor de una configuración de alta disponibilidad activo/pasivo que está a la espera de hacerse cargo del servicio en caso de que falle el nodo principal actual.
• dirección IP virtual
Dirección IP que representa una aplicación. Los clientes que utilizan la dirección IP virtual se suelen enrutar a un equilibrador de la carga que, a continuación, dirige la solicitud al servidor que ejecuta la aplicación.
• equilibrador de la carga
Un dispositivo que recibe el tráfico de red y lo distribuye a la aplicación lista para aceptarlo. Para una configuración de alta disponibilidad activo/pasivo, el equilibrador de la carga dirige el tráfico al nodo principal actual. Para una configuración de alta disponibilidad activo/activo, el equilibrador de la carga dirige el tráfico a una de varias aplicaciones.
• conmutación por error
Modo de funcionamiento de copia de seguridad en el que componentes del sistema secundarios asumen las funciones de un componente del sistema (como un procesador, un servidor, una red o una base de datos) cuando el componente principal deja de estar disponible debido a un fallo o a un tiempo de inactividad programado.
Arquitectura de referencia de ThingWorx para alta disponibilidad
En la siguiente imagen se muestra ThingWorx en una configuración de alta disponibilidad.
A continuación, se indican los componentes de esta configuración y su rol en una implementación de alta disponibilidad:
• Usuarios y dispositivos: ningún rol en la funcionalidad de alta disponibilidad. Desde su perspectiva, no cambia nada. Siempre utilizan los mismos URL y direcciones IP, incluso si hay un cambio en el servidor ThingWorx principal.
• Barreras de seguridad: ninguna función de alta disponibilidad y se puede considerar opcional. A menudo, se colocan barreras de seguridad para implementar requisitos de seguridad.
• Equilibradores de la carga: los equilibradores de la carga gestionan una dirección IP virtual para la aplicación a la que soportan. Todo el tráfico ruteado a esa dirección IP virtual se dirige a la aplicación activa que puede recibirla.
• ThingWorx Connection Servers: recibe el tráfico de socket Web de los activos y lo rutea a ThingWorx Platform. Los servidores de conexión pueden funcionar en una configuración activo/activo. Una vez que un activo se dirige a una instancia de Connection Server específica, siempre debe utilizar el mismo servidor de conexión. Si el servidor se queda fuera de línea, el activo debe redirigirse a otra instancia de Connection Server disponible.
• ThingWorx Foundation: recibe todo el tráfico de usuarios y activos. ThingWorx Foundation funciona en una configuración activo/pasivo con un servidor principal y uno o varios servidores en espera. El servidor principal está en línea y recibe tráfico. Los servidores en espera se ejecutan en estado preparado cuando se ejecuta la aplicación, pero no hay ninguna conexión activa a la base de datos y no recibe el tráfico. Un equilibrador de la carga enruta todo el tráfico al nodo principal. Si el nodo principal se queda fuera de línea, el nodo en espera se promueve a principal y el tráfico se dirige a él.
• Almacenes de ThingWorx: ubicaciones de almacenamiento necesarias, tales como ThingworxPlatform, ThingworxStorage y ThingworxBackupStorage, y cualquier ubicación de almacenamiento adicional que se haya añadido para soportar la implementación. Para un entorno de alta disponibilidad, los almacenes de ThingWorx deben existir en una ubicación de almacenamiento común donde todos los servidores ThingWorx (principal y en espera) puedan acceder a ellos por igual.
• Apache ZooKeeper: ZooKeeper es un servicio de coordinación centralizado que ThingWorx utiliza para elegir uno de los servidores ThingWorx como principal en un momento dado. Un cliente ZooKeeper se integra en cada servidor ThingWorx para mantener un latido y reaccionar a los cambios en la configuración, como el fallo del nodo principal actual de ThingWorx.
• PostgreSQL: en una configuración de alta disponibilidad, PostgreSQL funcionará a través de dos o más nodos de servidor en una configuración en espera activa. Un nodo recibe todo el tráfico de escritura y uno de los demás nodos puede recibir todo el tráfico de lectura. Se activa la replicación del flujo entre todos los nodos para mantener actualizado cada nodo.
• Pgpool-II: solo se utiliza en configuraciones de alta disponibilidad de PostgreSQL. Los nodos de Pgpool-II reciben las solicitudes de ThingWorx (lecturas y escrituras) y las dirigen al nodo de PostgreSQL adecuado. También supervisa la integridad de cada nodo PostgreSQL y puede iniciar tareas de conmutación por error y cambio de destino de tareas cuando uno de los nodos se queda fuera de línea.
• Microsoft SQL Server (no se encuentra en la imagen): se utiliza la conmutación por error de Microsoft para garantizar que al menos una instancia de MS SQL Server esté en línea y disponible.
• DataStax Enterprise (DSE): no se requiere una implementación de DSE para una configuración de alta disponibilidad de ThingWorx. Si se necesita para satisfacer los requisitos de ingesta de la implementación, asegúrese de que esté configurado para la alta disponibilidad. La implementación típica de DSE satisface la mayoría de los requisitos de alta disponibilidad. Tiene varios nodos de Cassandra que recopilan contenido y al menos dos nodos de Solr. El diseño de DSE replica todo el contenido en al menos otro nodo.
 | A partir de la versión 8.5.0 de ThingWorx Platform, DataStax Enterprise deja de estar en venta y no se soportará en una versión futura. Para obtener más información, consulte el artículo
End of Sale. |
Requisitos previos a la instalación
Notas y avisos:
• Los pasos de este proceso de alta disponibilidad están pensados para que los utilice un administrador de bases de datos (DBA) con experiencia previa con bases de datos relacionales en la configuración de alta disponibilidad (PostgreSQL, Microsoft SQL Server y DataStax Enterprise). El conocimiento necesario incluye la instalación, optimización y agrupación de alta disponibilidad.
• La guía que se proporciona en este documento es para implementar entornos de alta disponibilidad. Es posible que sea necesario un ajuste adicional del rendimiento en un entorno de producción, pero no se proporciona aquí.
• Los pasos detallados son ejemplos a modo de referencia y están destinados únicamente a un entorno de control de calidad o de sandbox. Es posible que los instaladores tengan que editar los comandos y la configuración para obtener un rendimiento óptimo en un entorno de producción.
• Todas las configuraciones de conmutación por error se deben probar y validar completamente antes de utilizarlas en la producción.
• En los pasos de este proceso no se describen los escenarios de conmutación por recuperación, donde se corrige un nodo principal fallido y luego se devuelve a la posición de principal. Se supone que el componente fallido se corrige y vuelve al servicio como componente no principal.
Sistemas operativos soportados
Requisitos generales de alta disponibilidad
Direcciones IP virtuales
• Usuarios y activos para servidores de conexión (si se utilizan servidores de conexión)
• Servidores de conexión para ThingWorx Foundation
• ThingWorx Foundation para la alta disponibilidad de PostgreSQL (si se utiliza PostgreSQL)
• ThingWorx Foundation para la alta disponibilidad de Microsoft SQL Server (si se utiliza Microsoft SQL Server)
Requisitos de hardware
En los pasos que se proporcionan en esta sección se supone que se utiliza la redundancia de hardware completa en una configuración de alta disponibilidad de ThingWorx.
• Cada instancia de una aplicación debe ejecutarse en hardware independiente para evitar puntos únicos de fallo en el nivel de hardware. Por ejemplo, los servidores ThingWorx, ya sean físicos, virtuales o basados en la nube, no deben funcionar en el mismo hardware físico.
• Se espera que se cumpla este requisito para todas las aplicaciones de configuración de alta disponibilidad de ThingWorx (ThingWorx, PostgreSQL, DataStax Enterprise, ZooKeeper, etc.) para mitigar el riesgo de fallos de hardware.
• En el proceso que se proporciona en esta sección se suponen los enrutadores, conmutadores, fuentes de alimentación redundantes, etc.
Propiedades de ThingWorx en una configuración de alta disponibilidad
Las propiedades de ThingWorx se deben definir en persistentes para evitar la pérdida de datos en el caso de una conmutación por error. Si no son persistentes, una conmutación por error de los servidores principales a los secundarios despejará los valores en memoria.
Requisitos de PostgreSQL
• Bases de datos Pgpool-II y PostgreSQL instaladas en entornos RHEL o Ubuntu.
• Un mínimo de dos servidores host de la base de datos que ejecuten una versión soportada de PostgreSQL. Se recomiendan tres.
• Lo típico es dos servidores que ejecuten Pgpool-II 3.7 <más reciente> con guardián configurado. Este es el ejemplo que se presenta en esta sección, pero también se puede optar por otras configuraciones de alta disponibilidad que no utilicen Pgpool-II.
Requisitos de Microsoft SQL Server
• Un mínimo de dos servidores host de la base de datos que ejecuten una versión soportada de Microsoft SQL Server.
• Microsoft SQL Server debe estar configurado para funcionar a través de una de las siguientes metodologías de alta disponibilidad de Microsoft:
◦ Instancias de clúster de conmutación por error AlwaysOn
◦ Grupos de disponibilidad Always On
Requisitos de DataStax Enterprise
• Un mínimo de cinco nodos para un clúster de DataStax Enterprise:
◦ Tres nodos de Cassandra
◦ Dos nodos de Solr
◦ (Opcional) Un nodo de DSE OpsCenter para el trabajo administrativo, ya que OpsCenter no es crítico para el funcionamiento y no requiere una configuración de alta disponibilidad.
Requisitos de InfluxDB
• Mínimo de dos metanodos, se recomiendan tres para la mayoría de los casos de uso.
• Mínimo de dos nodos de datos, se recomienda tener números pares de nodos de datos
• Una implementación típica debe tener tres metanodos y un número par de nodos de datos.