Arquitecturas de implementación de ThingWorx
En las siguientes secciones se incluyen diagramas de implementaciones típicas de ThingWorx. Las arquitecturas van desde sistemas de desarrollo simples a clústeres de varios nodos, a sistemas de producción federados globales. Para obtener información sobre los componentes de ThingWorx, consulte Componentes de la implementación de ThingWorx Foundation.
 |
Para implementar ThingWorx en implementaciones híbridas y de varios sitios, consulte Implementación distribuida de ThingWorx.
|
Opciones de despliegue
• PTC Cloud Services: en una implementación de servicios gestionados, la aplicación de ThingWorx se aloja y gestiona en un servidor de terceros; a menudo, una nube privada. Una organización externa es responsable de gestionar la infraestructura necesaria y de garantizar el rendimiento.
Para las empresas preocupadas por la carga de TI y los conocimientos necesarios para gestionar ThingWorx, PTC proporciona una opción de implementación de servicios gestionados. Con PTC Cloud Services, las empresas que compran ThingWorx pueden acelerar la implementación, minimizar el coste y los requisitos de TI, y garantizar el rendimiento continuo. PTC Cloud Services aloja la solución de ThingWorx en un entorno seguro dentro de servicios comerciales de nube que tiene una gestión de aplicaciones, un ajuste del rendimiento y actualizaciones de forma continua. Para obtener más información, consulte www.ptc.com/services/cloud.
• Implementación local: el uso de una implementación local significa instalar y ejecutar el software de ThingWorx en servidores del sitio o centro de datos propios del usuario. El usuario es responsable del abastecimiento, la instalación y el mantenimiento de las aplicaciones de infraestructura y software, así como su soporte continuo en cuanto a integridad, disponibilidad y rendimiento.
Con una implementación local, el usuario puede realizar la implementación o contratar los servicios profesionales de PTC (o un socio certificado de PTC) para gestionar la implementación. Esta opción es adecuada para empresas con una organización de TI sólida y un fuerte deseo de mantener el control interno.
Consulte las siguientes secciones para obtener más información:
Sistema de producción básico de ThingWorx Foundation
Para un sistema de producción básico, se recomienda utilizar un servidor independiente para operar la base de datos en un servidor independiente. Se trata de un sistema empresarial pequeño a mediano o un sistema de fabricación de mediano a grande.
Lista de componentes | Número de componentes |
|---|---|
Equilibrador de la carga | 1 |
ThingWorx Connection Server | 1 |
Servidor ThingWorx Foundation | 1 |
Almacenamiento de ficheros conectado o NAS | 1 |
Base de datos | 1 |
Sistema de producción de gran tamaño de ThingWorx Foundation (no de alta disponibilidad)
En un sistema de producción de gran tamaño se incorporan componentes adicionales para soportar números superiores de dispositivos conectados y altas tasas de ingesta de datos.
Además de los componentes de la plataforma, en un sistema de producción de gran tamaño se pueden incluir una instancia de ThingWorx Connection Servers y una base de datos de serie temporal de InfluxDB.
El sistema InfluxDB ingiere datos procedentes de los activos, que ThingWorx gestiona como contenido de flujo de valor registrado.
Una base de datos relacional sigue siendo necesaria para conservar el modelo de ThingWorx.
InfluxDB se puede implementar en configuraciones de nodo único o de varios nodos (empresa) según los requisitos de ingesta y alta disponibilidad. Consulte Utilización de InfluxDB como proveedor de persistencia para obtener más información.
Lista de componentes | Número de componentes |
|---|---|
Equilibrador de la carga | 1 (distribuye el tráfico de dispositivo a servidores de conexión) |
ThingWorx Connection Server | 2..n (depende del número de dispositivos) |
Servidor ThingWorx Foundation | 1 |
Base de datos relacional | 1 |
InfluxDB (un solo nodo) | 1 |
Clústeres de producción de ThingWorx
Para una implementación de alta disponibilidad (HA), se añaden componentes adicionales para quitar puntos únicos de fallo en las capas de aplicación y de datos. Los siguientes componentes son necesarios para ThingWorx Platform:
• Un equilibrador de la carga de alta disponibilidad. Los grupos de nodos de servidores de conexión y del servidor Foundation requieren una instancia de equilibrador de la carga para distribuir la carga. Un clúster de Influx Enterprise también requiere una instancia si se utiliza. Muchas opciones de equilibrador de la carga pueden atender varias instancias: se puede utilizar un único dispositivo para atender a las tres instancias, si se configura correctamente.
• Dos (o más) instancias de ThingWorx Connection Servers. En operaciones agrupadas, se requieren servidores de conexión para distribuir la carga de dispositivos en el clúster, o para la redistribución si se produce un fallo de un nodo.
• Dos (o más) instancias de ThingWorx Foundation. Cada nodo está activo: la carga se distribuirá entre ellos.
• ThingWorxStorage es un almacenamiento en disco compartido (accesible para cada nodo).
| | Para una implementación completa de alta disponibilidad, los equilibradores de la carga y ThingWorxStorage compartido también deben tener implementada la redundancia. |
• Nodos de Apache Ignite para proporcionar la caché compartida para los nodos de ThingWorx Foundation.
• Tres nodos de Apache Zookeeper. Zookeeper supervisa los nodos de ThingWorx para decidir si cada uno responde y funciona según lo previsto. Los nodos de Zookeeper forman un quórum y deciden si un nodo de ThingWorx está fuera de línea. Si un nodo de ThingWorx Foundation se queda fuera de línea, Zookeeper reconfigura el equilibrador de la carga de ThingWorx para dirigir el tráfico a los otros nodos de Foundation.
Los siguientes componentes son necesarios para la base de datos PostgreSQL:
• Nodos de servidor PostgreSQL: se utiliza un mínimo de dos nodos, idealmente, tres.
• nodos pgpool-II: un mínimo de dos nodos, idealmente, tres que realizan tareas de conmutación por error y recuperación en caso de un fallo del servidor PostgreSQL. Estos nodos conservan conexiones entre el cliente (ThingWorx) y los servidores (PostgreSQL) y gestionan la replicación del contenido entre los nodos del servidor PostgreSQL.
Los siguientes componentes son necesarios para el sistema InfluxDB Enterprise:
• Metanodos de InfluxDB Enterprise: se recomienda una configuración de tres nodos para poder alcanzar un quórum y permitir que el clúster siga funcionando si falla un nodo.
• Nodos de datos de InfluxDB Enterprise: puede ser uno, pero se recomienda un mínimo de dos. Se recomienda un recuento de nodos que sea divisible por el factor de replicación de InfluxDB.
Para obtener más información sobre la implementación de ThingWorx en un entorno de alta disponibilidad, consulte Alta disponibilidad de ThingWorx.
Clúster de alta escala + alta disponibilidad
En este diagrama, cada componente del clúster reside en su propio ordenador físico, máquina virtual o contenedor. De este modo, se proporciona la máxima flexibilidad en cuanto a la escala de cada uno de los distintos grupos de componentes de forma independiente.
Lista de componentes | Número de componentes |
|---|---|
Conexión de ThingWorx Servidor | 2..n (basado en el recuento de dispositivos) |
Equilibrador de la carga | 2 o 3 instancias: • Distribución del tráfico de dispositivos a instancias de Connection Server • Distribución del tráfico entre los nodos de ThingWorx • Distribución del tráfico entre los nodos de datos de InfluxDB Enterprise (si se utiliza) |
Servidor ThingWorx Foundation | 2 .. n: según los requisitos de alta disponibilidad y escalabilidad |
Almacenamiento en red/empresa | Espacio en disco para almacenes de almacenamiento de ThingWorx compartidos con todos los servidores ThingWorx Foundation. |
Ignite | Dos opciones: • Integrado en los procesos de Foundation • 2 o más nodos independientes (depende de los requisitos de alta disponibilidad) |
ZooKeeper | Mínimo de 3. Debe ser en asignaciones con numeración impar. |
Base de datos | Depende de la base de datos: • PostgreSQL: 3 nodos de base de datos + 2 nodos pgpool-II • MS SQL Server (no hay imagen): mínimo de 2 como parte de una configuración de conmutación por error. |
Empresa InfluxDB | 5 (o más): • 3 metanodos • 2 o más nodos de datos, recuento total divisible por el factor de replicación |
Superficie de clúster mínima
En este diagrama, los componentes se empaquetan o agrupan en un conjunto más pequeño de ordenadores físicos/máquinas virtuales, o contenedores.
Esta configuración se puede utilizar para alta disponibilidad, pero será menos escalable en comparación con una configuración distribuida en la que los componentes compartan recursos.
Este diagrama también se puede utilizar para ver implementaciones donde varias implementaciones de ThingWorx independientes aprovechan la misma infraestructura compartida (Zookeeper, BD, almacenamiento de red).
Lista de componentes (por nodo de clúster) | Número de componentes |
|---|---|
ThingWorx Connection Server | 1 (por nodo de clúster) |
Servidor ThingWorx Foundation | 1 (por nodo de clúster) |
Ignite | Ninguno: se ejecuta en el modo integrado dentro de cada proceso del servidor Foundation. |
Lista de componentes (compartidos) | Número de componentes |
|---|---|
Instancias de equilibrador de la carga | 2 o 3 instancias: • Distribución del tráfico de dispositivos a instancias de Connection Server. • Distribución del tráfico entre los nodos de ThingWorx. • Distribución del tráfico entre los nodos de datos de InfluxDB Enterprise (si se utiliza). |
ZooKeeper | Mínimo de 3. Debe ser en asignaciones con numeración impar. |
Bases de datos | Consulte el diagrama anterior. |
Almacenamiento en red/empresa | Espacio en disco para almacenes de almacenamiento de ThingWorx compartidos con todos los servidores ThingWorx Foundation. |