Architectures de déploiement de ThingWorx
Les sections suivantes incluent des diagrammes de déploiements ThingWorx classiques. Les architectures vont des simples systèmes de développement aux clusters multi-noeuds et aux systèmes de production fédérés globaux. Pour plus d'informations sur les composants ThingWorx, consultez la rubrique Composants de déploiement de ThingWorx Foundation.
 |
Pour déployer ThingWorx dans des déploiements hybrides et multi-sites, consultez la rubrique Déploiement ThingWorx distribué.
|
Options de déploiement
• Services Cloud PTC : dans un déploiement de services gérés, l'application ThingWorx est hébergée et gérée sur un serveur tiers (souvent un Cloud privé). Une organisation externe est responsable de la gestion de l'infrastructure requise et de la garantie des performances.
Pour les entreprises soucieuses de la charge et de l'expertise informatiques requises afin de gérer ThingWorx, PTC fournit une option de déploiement de services gérés. Avec les Services Cloud PTC, les entreprises qui achètent ThingWorx peuvent accélérer le déploiement, réduire le coût et les exigences informatiques et garantir des performances continues. Les Services Cloud PTC hébergent votre solution ThingWorx dans un environnement sécurisé au sein de services Cloud commerciaux qui bénéficie d'une gestion des applications, d'un réglage des performances et de mises à jour continus. Pour plus d'informations, consultez la page www.ptc.com/services/cloud.
• Déploiement sur site : l'utilisation d'un déploiement sur site implique l'installation et l'exécution du logiciel ThingWorx sur les serveurs de votre propre site ou centre de données. Vous êtes responsable de l'acquisition, de l'installation et de la maintenance de l'infrastructure et des applications logicielles ainsi que de leur prise en charge continue en matière d'intégrité, de disponibilité et de performances.
Avec un déploiement sur site, vous pouvez effectuer le déploiement vous-même ou faire appel aux services professionnels de PTC (ou à un partenaire certifié par PTC) pour gérer le déploiement. Cette option convient aux entreprises disposant d'une organisation informatique robuste et d'une forte volonté de maintenir le contrôle en interne.
Pour plus d'informations, consultez les sections suivantes :
Système de production de base ThingWorx Foundation
Pour un système de production de base, il est recommandé de faire fonctionner la base de données sur un serveur distinct. Il s'agit d'un bon système pour petites et moyennes entreprises, ou d'un système de fabrication de taille moyenne à grande.
Liste des composants | Nombre de composants |
|---|---|
Equilibreur de charge | 1 |
ThingWorx Connection Server | 1 |
ThingWorx Foundation Server | 1 |
Stockage de fichiers NAS ou attachés | 1 |
Base de données | 1 |
Système de production ThingWorx Foundation à grande échelle (sans haute disponibilité)
Un système de production à grande échelle intègre des composants supplémentaires pour prendre en charge un plus grand nombre d'appareils connectés et des taux d'ingestion de données élevés.
Outre les composants de plateforme, un système de production à grande échelle peut inclure des serveurs de connexion ThingWorx et une base de données de séries temporelles InfluxDB.
Le système InfluxDB ingère les données provenant des actifs, que ThingWorx gère en tant que contenu de flux de valeurs journalisés.
Une base de données relationnelle est toujours nécessaire pour conserver le modèle ThingWorx.
InfluxDB peut être déployé dans des configurations à un ou plusieurs noeuds (entreprise) en fonction des exigences en matière d'ingestion et de haute disponibilité. Pour plus d'informations, consultez la rubrique Utilisation d'InfluxDB en tant que fournisseur de persistance.
Liste des composants | Nombre de composants |
|---|---|
Equilibreur de charge | 1 (distribue le trafic des appareils vers les serveurs de connexion) |
ThingWorx Connection Server | 2..n (dépend du nombre d'appareils) |
ThingWorx Foundation Server | 1 |
Base de données relationnelle | 1 |
InfluxDB (noeud unique) | 1 |
Clusters de production ThingWorx
Pour un déploiement haute disponibilité, des composants supplémentaires sont ajoutés afin de supprimer les points de défaillance uniques dans les couches d'application et de données. Les composants suivants sont requis pour ThingWorx Platform :
• Un équilibreur de charge haute disponibilité. Les groupes de noeuds ThingWorx Connection Server et Foundation Server nécessitent une instance d'équilibreur de charge pour distribuer la charge. Un cluster Influx Enterprise nécessite également une instance s'il est utilisé. De nombreuses options d'équilibreur de charge sont capables de servir plusieurs instances : un dispositif unique peut être utilisé pour servir les trois instances s'il est configuré de manière appropriée.
• Deux (ou plusieurs) serveurs de connexion ThingWorx. 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.
• Deux (ou plusieurs) instances de ThingWorx Foundation. Chaque noeud est actif : la charge sera répartie entre eux.
• ThingWorxStorage est un stockage sur disque partagé (accessible par chaque noeud).
| | Pour un déploiement haute disponibilité complet, les équilibreurs de charge et le stockage ThingWorxStorage partagé doivent également bénéficier d'une redondance implémentée. |
• Des noeuds Apache Ignite afin de fournir un cache partagé pour les noeuds ThingWorx Foundation.
• Trois noeuds Apache ZooKeeper. ZooKeeper surveille les noeuds ThingWorx pour décider s'ils sont dynamiques et fonctionnent comme prévu. Les noeuds ZooKeeper forment un quorum et décident quand un noeud ThingWorx est hors ligne. Si un noeud ThingWorx Foundation est hors ligne, ZooKeeper reconfigure l'équilibreur de charge ThingWorx pour qu'il dirige le trafic vers les autres noeuds Foundation.
Les composants suivants sont requis pour la base de données PostgreSQL :
• Noeuds de serveur PostgreSQL : au moins deux noeuds (idéalement trois) sont utilisés.
• Noeuds pgpool-II : un minimum de deux noeuds (idéalement trois) qui effectuent des tâches de basculement et de récupération en cas de défaillance d'un serveur PostgreSQL. Ces noeuds maintiennent les connexions entre le client (ThingWorx) et les serveurs (PostgreSQL), tout en gérant la réplication du contenu parmi les noeuds de serveur PostgreSQL.
Les composants suivants sont requis pour le système InfluxDB Enterprise :
• Méta-noeuds InfluxDB Enterprise : une configuration à trois noeuds est recommandée afin qu'un quorum puisse être atteint et pour permettre au cluster de continuer à fonctionner en cas de défaillance d'un noeud.
• Noeuds de données InfluxDB Enterprise : il est possible de n'en utiliser qu'un, mais un minimum de deux est recommandé. Un nombre de noeuds divisible par votre facteur de réplication InfluxDB est recommandé.
Pour plus d'informations sur le déploiement de ThingWorx dans un environnement à haute disponibilité, consultez la rubrique Haute disponibilité ThingWorx.
Cluster à grande échelle + haute disponibilité
Dans ce diagramme, chaque composant du cluster réside dans sa propre machine physique, sa propre machine virtuelle ou son propre conteneur. Cela offre la plus grande flexibilité en matière de mise à l'échelle de chacun des différents groupes de composants de façon indépendante.
Liste des composants | Nombre de composants |
|---|---|
ThingWorx Connection Serveur | 2..n (en fonction du nombre d'appareils) |
Equilibreur de charge | 2 ou 3 instances : • Routage du trafic des appareils vers les serveurs de connexion. • Routage du trafic entre les noeuds ThingWorx. • Routage du trafic entre les noeuds de données InfluxDB Enterprise (s'ils sont utilisés). |
ThingWorx Foundation Server | 2 .. n : basé sur les exigences de haute disponibilité et d'évolutivité |
Stockage en réseau/entreprise | Espace disque pour les référentiels de stockage ThingWorx partagés avec tous les serveurs ThingWorx Foundation. |
Ignite | Deux options : • Intégration dans les processus Foundation • 2 noeuds séparés ou plus (selon les exigences HA) |
ZooKeeper | 3 minimum. Doit figurer dans des affectations à numéro impair. |
Base de données | Dépend de la base de données : • PostgreSQL : 3 noeuds de base de données + 2 noeuds pgpool-II • MS SQL Server (non illustré) : 2 au minimum dans le cadre d'une configuration de basculement. |
InfluxDB Enterprise | 5 (ou plus) : • 3 méta-noeuds • 2 noeuds de données ou plus, avec un nombre total divisible par le facteur de réplication |
Empreinte de cluster minimale
Dans ce diagramme, les composants sont rassemblés ou groupés dans un plus petit ensemble de machines physiques/virtuelles ou de conteneurs.
Cette configuration peut être utilisée à des fins de haute disponibilité, mais elle sera moins évolutive par rapport à une configuration distribuée dans laquelle les composants partagent les ressources.
Ce diagramme peut également être utilisé pour analyser les déploiements où plusieurs déploiements ThingWorx indépendants utilisent la même infrastructure partagée (ZooKeeper, base de données, stockage réseau).
Liste des composants (par noeud de cluster) | Nombre de composants |
|---|---|
ThingWorx Connection Server | 1 (par noeud de cluster) |
ThingWorx Foundation Server | 1 (par noeud de cluster) |
Ignite | Aucun : s'exécute en mode intégré dans chaque processus de serveur Foundation. |
Liste des composants (partagés) | Nombre de composants |
|---|---|
Instances d'équilibreur de charge | 2 ou 3 instances : • Routage du trafic des appareils vers les serveurs de connexion. • Routage du trafic entre les noeuds ThingWorx. • Routage du trafic entre les noeuds de données InfluxDB Enterprise (s'ils sont utilisés). |
ZooKeeper | 3 minimum. Doit figurer dans des affectations à numéro impair. |
Bases de données | Voir le diagramme précédent. |
Stockage en réseau/entreprise | Espace disque pour les référentiels de stockage ThingWorx partagés avec tous les serveurs ThingWorx Foundation. |