Considérations relatives au dimensionnement des clusters ThingWorx
Dimensionnement des noeuds ThingWorx Foundation
Dans un environnement en cluster, le dimensionnement des noeuds ThingWorx Foundation reste essentiellement inchangé. Chaque noeud de cluster doit disposer de suffisamment de mémoire pour charger l'intégralité du modèle d'objet. Par conséquent, la taille de chaque noeud de cluster doit correspondre à la taille d'un noeud de serveur unique. Par exemple, un serveur unique de taille moyenne est constitué de 16 vCPU et de 32 Gio de RAM. De même, pour un cluster à deux noeuds, chaque noeud serait composé de 16 vCPU et de 32 Gio de RAM.
Si Apache Ignite est déployé séparément, la consommation de mémoire du serveur Foundation peut être réduite légèrement, dans la mesure où les informations d'état de propriété ont été transférées vers les noeuds Ignite.
La sollicitation des ressources CPU augmentera pour exécuter les tâches de synchronisation du cluster en arrière-plan. Les opérations individuelles peuvent également être légèrement plus lentes dans les configurations en cluster en raison de la latence supplémentaire induite par un cache partagé. Ce phénomène est compensé par la capacité d'exécuter à l'échelle un plus grand nombre d'opérations en parallèle (logique applicative et/ou requêtes utilisateur) sur plusieurs noeuds.
A des fins de haute disponibilité, une fois que la taille correcte d'un noeud individuel a été déterminée, il est recommandé de déployer au moins un noeud ThingWorx Foundation de plus que nécessaire pour absorber les pics de charge de votre application. Cela permettra au cluster de continuer à répondre aux attentes de performance en cas de défaillance d'un noeud.
Dimensionnement des noeuds de serveur de connexion
Dans un fonctionnement en cluster, des serveurs de connexion sont nécessaires pour répartir la charge des appareils au sein du cluster ou pour la redistribuer en cas de défaillance d'un noeud.
Comme pour les noeuds Foundation, il est recommandé de déployer au moins un serveur de connexion de plus que nécessaire pour gérer le nombre d'appareils attendus. Cela permettra aux serveurs de connexion de maintenir la connectivité avec tous les appareils en cas de défaillance d'un noeud de serveur de connexion.
Reportez-vous au Centre d'aide ThingWorx Connection Services pour connaître la configuration système requise pour chaque option de serveur de connexion.
Dimensionnement des noeuds Apache ZooKeeper
Apache ZooKeeper est une solution open source permettant de synchroniser des applications distribuées. Cette solution fournit des capacités de surveillance et d'élection de leader pour les noeuds ThingWorx.
Il est recommandé d'utiliser un ensemble de trois noeuds, chacun avec 2 vCPU et 2 Gio de RAM. Le nombre d'instances doit être impair pour conserver un quorum.
Pour plus d'informations, consultez la configuration requise pour Apache ZooKeeper : https://zookeeper.apache.org/doc/r3.1.2/zookeeperAdmin.html#sc_systemReq
Dimensionnement des noeuds de base de données
Au-delà de la haute disponibilité, la charge des bases de données augmente dans les configurations ThingWorx en cluster. Pour illustrer cela, des tests de charge identiques ont été effectués avec cinq déploiements de taille intermédiaire différents à l'aide de machines virtuelles Microsoft Azure :
|
Comparaison des performances avec cluster et noeud unique (PostgreSQL uniquement)
|
|||||
|---|---|---|---|---|---|
|
Foundation
|
1 × F16s_v2
|
2 × F16s_v2
|
3 × F16s_v2
|
4 × F16s_v2
|
5 × F16s_v2
|
|
Ignite
|
Aucun
|
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
|
Aucun
|
Aucun
|
Aucun
|
Aucun
|
Aucun
|
|
Résultats par noeud (moy.)
|
26 000 WPS
19 ops HTTP
|
12 000 WPS
10 ops HTTP
|
10 000 WPS
6 ops HTTP
|
7 000 WPS
6 ops HTTP
|
6 000 WPS
2 ops HTTP
|
|
Total des résultats
|
24 000 WPS
19 ops HTTP
|
30 000 WPS
24 ops HTTP
|
28 000 WPS
22 ops HTTP
|
30 000 WPS
12 ops HTTP
|
|
|
Rappel : les recommandations du guide de dimensionnement sont destinées à servir de base initiale pour le dimensionnement des implémentations ThingWorx. Les résultats réels peuvent varier en fonction de la configuration Edge, de la charge de l'application, etc.
|
|||||
Bien que les tests ci-dessus présentent une légère amélioration de l'ingestion des données, les performances des requêtes HTTP ne s'améliorent pas en raison de ressources de base de données inadéquates.
Pour résoudre ce problème, l'évolutivité peut s'améliorer avec des instances de SGBDR plus conséquentes, et/ou en utilisant InfluxDB comme indiqué ci-dessous.
|
Comparaison des performances avec cluster et noeud unique (PostgreSQL + InfluxDB)
|
|||||
|---|---|---|---|---|---|
|
Foundation
|
1 × F16s_v2
|
2 × F16s_v2
|
3 × F16s_v2
|
4 × F16s_v2
|
5 × F16s_v2
|
|
Ignite
|
Aucun
|
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
|
|
Résultats par noeud (moy.)
|
90 000 WPS
120 ops HTTP
|
53 000 WPS
187 ops HTTP
|
39 000 WPS
148 ops HTTP
|
31 500 WPS
127 ops HTTP
|
27 000 WPS
108 ops HTTP
|
|
Total des résultats
|
106 000 WPS
375 ops HTTP
|
118 000 WPS
445 ops HTTP
|
126 000 WPS
508 ops HTTP
|
135 000 WPS
540 ops HTTP
|
|
|
Rappel : les recommandations du guide de dimensionnement sont destinées à servir de base initiale pour le dimensionnement des implémentations ThingWorx. Les résultats réels peuvent varier en fonction de la configuration Edge, de la charge de l'application, etc.
|
|||||
 |
La version utilisée pour ces tests est la version open source d'InfluxDB, qui n'assure pas une haute disponibilité. InfluxDB Enterprise est la version recommandée pour les implémentations de production de ThingWorx en cluster. Pour le dimensionnement sur InfluxDB Enterprise, planifiez deux noeuds de "données" InfluxDB comme indiqué, plus trois noeuds "méta", avec typiquement 1 à 2 vCPU et 0,5 à 1Gio de RAM chacun. Pour plus d'informations sur le dimensionnement d'InfluxDB, consultez la page https://docs.influxdata.com/influxdb/v1.8/guides/hardware_sizing/.
|
Dimensionnement des noeuds Apache Ignite
Dans un cluster ThingWorx, Apache Ignite fournit un cache partagé pour les valeurs de propriété et les données supplémentaires liées par exemple aux tâches de transfert de fichiers.
Ignite peut être intégré dans le processus ThingWorx Foundation, ce qui ne nécessite pas d'installation distincte. Pour une meilleure répartition de la charge, Ignite peut également être déployé sous forme de cluster séparé.
Ignite peut également être exécuté dans l'un des deux modes suivants :
• Mode PARTITIONED : les données sont divisées en partitions égales et réparties également entre les noeuds participants. Ce mode offre les meilleures performances en matière d'écriture dans le cache.
• Mode REPLICATED : chaque instance Ignite possède une copie de chaque point de données. Ce mode offre les meilleures performances en matière de lecture dans le cache.
Pour plus d'informations, consultez la documentation Apache Ignite concernant les modes de cache : https://apacheignite.readme.io/docs/cache-modes
La charge principale d'Ignite est le débit réseau entre chaque instance ThingWorx Foundation et Ignite. Bien que la configuration requise en matière de ressources CPU, de disques ou de mémoire puisse indiquer des tailles de VM plus petites chez les fournisseurs de Cloud, il est important de vérifier si le débit réseau est limité.
Si des problèmes de débit sont détectés, ils peuvent être résolus soit en migrant vers des systèmes plus grands avec une capacité réseau supérieure, soit en ajoutant des noeuds Ignite supplémentaires (avec le mode PARTITIONED) afin de répartir la charge.
Comme départ approximatif, une taille de mémoire égale à vos noeuds ThingWorx Foundation peut être considérée comme une estimation prudente et sûre.
Pour calculer plus précisément l'empreinte mémoire de votre cache partagé :
1. Calculez l'empreinte mémoire VTQ (valeur, horodatage et qualité) de votre cache de propriétés ThingWorx.
a. Pour chaque type d'objet, déterminez la taille du type de données en mémoire. Par exemple, si votre propriété est une chaîne de 50 caractères et que chaque caractère représente 2 octets, cette chaîne nécessitera 100 octets de mémoire.
b. Ajoutez 8 octets. (4 pour la date/heure de cette valeur et 4 pour la qualité de la valeur).
c. Multipliez par 2. ThingWorx met en cache la valeur actuelle et la valeur précédente de chaque propriété.
d. Multipliez par le nombre d'objets de ce type.
e. Additionnez les résultats obtenus pour les différents types d'objet.
2. Ajoutez 30 % pour les index de valeurs en mémoire d'Ignite.
3. Multipliez par le nombre de copies de données souhaitées dans le cluster Ignite. Par exemple, si vous souhaitez une sauvegarde des données afin de ne risquer aucune perte de données en cas de défaillance d'un noeud Ignite, multipliez par 2.
4. Divisez par le nombre de noeuds de cluster Ignite que vous envisagez de déployer.
5. Chaque noeud Ignite nécessitera environ 300 Mo supplémentaire pour son propre fonctionnement.
Pour plus d'informations, consultez la documentation Apache Ignite : https://apacheignite.readme.io/docs/capacity-planning