Consideraciones sobre el tamaño de clúster de ThingWorx
Tamaño de los nodos de ThingWorx Foundation
En operaciones agrupadas, el tamaño de los nodos individuales de ThingWorx Foundation no cambia significativamente. Cada nodo de clúster debe tener suficiente memoria para cargar todo el modelo de cosa. Por lo tanto, el tamaño de cada nodo de clúster debe coincidir con el tamaño de un nodo de servidor único. Por ejemplo, un único servidor de tamaño medio tiene 16 vCPU y 32 GiB de RAM. De manera similar, para un clúster de dos nodos, cada nodo del clúster tendrá 16 vCPU y 32 GiB de RAM.
Si Apache Ignite se implementa por separado, el consumo de memoria del servidor Foundation se puede reducir ligeramente, ya que la información de estado de las propiedades se ha transferido a los nodos de Ignite.
La utilización de la CPU aumentará para ejecutar tareas de sincronización de clúster en segundo plano. Las operaciones individuales también pueden ser ligeramente más lentas en las configuraciones agrupadas debido a la latencia añadida de una caché compartida. Esto se compensa por la capacidad de ejecutar una escala en un número mayor de operaciones en paralelo (solicitudes de lógica de negocio y/o de usuario) en varios nodos.
Para obtener alta disponibilidad, una vez que se haya determinado el tamaño correcto de un nodo individual, se recomienda implementar al menos un nodo más de ThingWorx Foundation que los necesarios para gestionar el pico en la carga de la aplicación. De este modo, el clúster podrá seguir cumpliendo las expectativas de rendimiento en caso de que se produzca un error en un único nodo.
Tamaño de los nodos del servidor de conexión
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.
Al igual que los nodos de Foundation, se recomienda implementar al menos un servidor de conexión más que los necesarios para gestionar el recuento de dispositivos previsto. De este modo, los servidores de conexión podrán conservar la conectividad con todos los dispositivos si falla un único nodo de servidor de conexión.
Consulte el centro de ayuda de ThingWorx Connection Services para ver los requisitos del sistema para las opciones individuales de Connection Server.
Tamaño de los nodos de Apache Zookeeper
Apache ZooKeeper es una solución de código abierto para la sincronización de aplicaciones distribuidas. Se proporcionan la supervisión y la elección de nodo principal para los nodos de ThingWorx.
Se recomienda utilizar un grupo de tres nodos, cada uno con 2 vCPU y 2 GiB de RAM. Es necesario un número impar de instancias para conservar el quórum.
Revise los requisitos del sistema Apache Zookeeper para obtener más información: https://zookeeper.apache.org/doc/r3.1.2/zookeeperAdmin.html#sc_systemReq
Tamaño de los nodos de base de datos
Más allá de la alta disponibilidad, la carga de la base de datos aumenta en las configuraciones agrupadas de ThingWorx. Para ilustrar esto, se han realizado pruebas de carga idénticas con cinco implementaciones de medios diferentes con máquinas virtuales de Microsoft Azure:
|
Comparación del rendimiento del nodo único y el clúster (solo PostgreSQL)
|
|||||
|---|---|---|---|---|---|
|
Foundation
|
1 × F16s_v2
|
2 × F16s_v2
|
3 × F16s_v2
|
4 × F16s_v2
|
5 × F16s_v2
|
|
Ignite
|
Ninguno
|
3 × F8s_v2
|
3 × F8s_v2
|
3 × F8s_v2
|
3 × F8s_v2
|
|
PostgreSQL
|
1 × F16s_v2
|
1 × F16s_v2
|
1 × F16s_v2
|
1 × F16s_v2
|
1 × F16s_v2
|
|
InfluxDB
|
Ninguno
|
Ninguno
|
Ninguno
|
Ninguno
|
Ninguno
|
|
Resultados por nodo (promedio)
|
26.000 WPS
19 operaciones HTTP
|
12.000 WPS
10 operaciones HTTP
|
10.000 WPS
6 operaciones HTTP
|
7.000 WPS
6 operaciones HTTP
|
6.000 WPS
2 operaciones HTTP
|
|
Total de resultados
|
24.000 WPS
19 operaciones HTTP
|
30.000 WPS
24 operaciones HTTP
|
28.000 WPS
22 operaciones HTTP
|
30.000 WPS
12 operaciones HTTP
|
|
|
Recordatorio: Las recomendaciones del Manual sobre la definición de tamaño están pensadas para utilizar instantáneas iniciales para el tamaño de las implementaciones de ThingWorx. Los resultados individuales variarán en función de la configuración periférica, la carga de la aplicación, etc.
|
|||||
Mientras que en las pruebas anteriores se muestra una pequeña mejora de en la ingesta de datos, el rendimiento de solicitudes HTTP no mejora debido a recursos inadecuados de la base de datos.
Para solucionarlo, la escalabilidad puede mejorar con instancias de RDBMS de mayor tamaño y/o con InfluxDB, tal como se indica a continuación.
|
Comparación del rendimiento del nodo único y el clúster (PostgreSQL e InfluxDB)
|
|||||
|---|---|---|---|---|---|
|
Foundation
|
1 × F16s_v2
|
2 × F16s_v2
|
3 × F16s_v2
|
4 × F16s_v2
|
5 × F16s_v2
|
|
Ignite
|
Ninguno
|
3 × F8s_v2
|
3 × F8s_v2
|
3 × F8s_v2
|
3 × F8s_v2
|
|
PostgreSQL
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
|
InfluxDB
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
|
Resultados por nodo (promedio)
|
90.000 WPS
120 operaciones HTTP
|
53.000 WPS
187 operaciones HTTP
|
39.000 WPS
148 operaciones HTTP
|
31.500 WPS
127 operaciones HTTP
|
27.000 WPS
108 operaciones HTTP
|
|
Total de resultados
|
106.000 WPS
375 operaciones HTTP
|
118.000 WPS
445 operaciones HTTP
|
126.000 WPS
508 operaciones HTTP
|
135.000 WPS
540 operaciones HTTP
|
|
|
Recordatorio: Las recomendaciones del Manual sobre la definición de tamaño están pensadas para utilizar instantáneas iniciales para el tamaño de las implementaciones de ThingWorx. Los resultados individuales variarán en función de la configuración periférica, la carga de la aplicación, etc.
|
|||||
 |
Se ha utilizado el código abierto de InfluxDB para estas pruebas, que no proporciona alta disponibilidad. Se recomienda utilizar InfluxDB Enterprise para las implementaciones de clúster de ThingWorx de producción. Para el tamaño de InfluxDB Enterprise, planifique dos nodos de "datos" de InfluxDB como se indica, más tres nodos "meta", normalmente de 1 a 2 vCPU y 0,5-1 GiB de RAM cada una. Para obtener más información sobre el tamaño de InfluxDB, consulte https://docs.influxdata.com/influxdb/v1.8/guides/hardware_sizing/.
|
Tamaño de los nodos de Apache Ignite
En un clúster de ThingWorx, Apache Ignite proporciona una caché compartida para los valores de propiedades y los datos adicionales, tales como trabajos de transferencia de ficheros.
Ignite puede integrarse en el proceso de ThingWorx Foundation, que no requiere una instalación independiente. También se puede implementar Ignite como un clúster independiente para conseguir una mayor distribución de la carga.
Ignite también se puede ejecutar en uno de los dos modos siguientes:
• Modo PARTITIONED: los datos se dividen equitativamente en particiones y se dividen por igual entre los nodos participantes. Mejor rendimiento de la escritura en caché.
• Modo REPLICATED: cada instancia de Ignite tiene una copia de cada punto de datos. Mejor rendimiento de lectura de la caché.
Para obtener más información, consulte la documentación de Apache Ignite sobre los modos de almacenamiento en caché: https://apacheignite.readme.io/docs/cache-modes
La carga principal de Ignite es el rendimiento de la red entre cada instancia de ThingWorx Foundation e Ignite. Aunque los requisitos de CPU, disco o memoria pueden indicar tamaños menores de máquina virtual de los proveedores de nube, es importante supervisar el rendimiento limitado o reducido de la red.
Si se encuentran problemas de rendimiento, se pueden solucionar pasando a sistemas de mayor tamaño con mayor capacidad de red o mediante la adición de nodos de Ignite adicionales (con el modo particionado) para distribuir la carga.
Como punto inicial aproximado, un tamaño de memoria igual a los nodos de ThingWorx Foundation sería una estimación segura y conservadora.
Para calcular la superficie de memoria de la caché compartida con mayor precisión:
1. Calcule la superficie de memoria de VTQ (valor, fecha y calidad) para la caché de propiedades de ThingWorx.
a. Para cada tipo de cosa, determine el tamaño del tipo de datos en memoria. Por ejemplo, si la propiedad es una cadena de 50 caracteres y cada carácter requiere 2 bytes, esa cadena necesita 100 bytes de memoria.
b. Añada 8 bytes. (4 para la fecha y hora de ese valor y 4 para la calidad del valor).
c. Multiplique por 2. ThingWorx almacena en caché el valor actual y anterior de cada propiedad.
d. Multiplique por el número de cosas de ese tipo.
e. Sume el resultado de cada tipo de cosa.
2. Añada un 30 % para los índices de los valores en memoria de Ignite.
3. Multiplique por el número de copias de datos que desee en el clúster de Ignite. Por ejemplo, si se desea una copia de seguridad de los datos de modo que no se pierdan datos si falla un único nodo de Ignite, se debe multiplicar por 2.
4. Divida por el número de nodos de clúster de Ignite que se planean implementar.
5. Cada nodo de Ignite requerirá ~ 300 MB adicionales para su propio funcionamiento.
Para obtener más información, consulte la documentación de Apache Ignite: https://apacheignite.readme.io/docs/capacity-planning