Architetture di distribuzione di ThingWorx
Nelle sezioni riportate di seguito vengono forniti i diagrammi di tipiche distribuzioni di ThingWorx. Le architetture vanno dai sistemi di sviluppo semplici ai cluster a più nodi fino ai sistemi di produzione federati globali. Per informazioni sui componenti di ThingWorx, vedere Componenti della distribuzione di ThingWorx Foundation.
 |
Per distribuire ThingWorx in distribuzioni ibride e multisito, fare riferimento a Distribuzione di ThingWorx distribuita.
|
Opzioni di distribuzione
• PTC Cloud Services - In una distribuzione di servizi gestiti, l'applicazione ThingWorx viene ospitata e gestita su un server di terze parti, spesso un cloud privato. Un'organizzazione esterna è responsabile della gestione dell'infrastruttura necessaria e della garanzia delle prestazioni.
Per le aziende preoccupate del carico di lavoro e delle competenze dell'IT necessari per gestire ThingWorx, PTC fornisce un'opzione di distribuzione di servizi gestiti. Con PTC Cloud Services, le aziende che acquistano ThingWorx possono accelerare la distribuzione, ridurre al minimo i costi e i requisiti dell'IT e garantire le prestazioni in corso. PTC Cloud Services ospita la soluzione ThingWorx in un ambiente sicuro all'interno di servizi cloud commerciali che prevede la gestione continua delle applicazioni, l'ottimizzazione delle prestazioni e gli aggiornamenti. Per ulteriori informazioni, vedere www.ptc.com/services/cloud.
• Distribuzione locale - L'utilizzo di una distribuzione locale implica l'installazione e l'esecuzione del software di ThingWorx sui server nel proprio sito o centro dati. L'utente è responsabile dell'approvvigionamento, dell'installazione e della manutenzione dell'infrastruttura e delle applicazioni software, nonché del supporto continuo in termini di stato, disponibilità e prestazioni.
Con una distribuzione locale è possibile eseguire la distribuzione autonomamente o coinvolgere i servizi professionali PTC (o un partner certificato PTC) in modo che si occupino della gestione della distribuzione. Questa opzione è adatta alle aziende con un'organizzazione IT robusta e un forte desiderio di mantenere il controllo internamente.
Per ulteriori informazioni, fare riferimento alle sezioni seguenti:
Sistema di produzione di base di ThingWorx Foundation
Per un sistema di produzione di base si consiglia un server separato per utilizzare il database. Può essere un sistema aziendale valido di piccole e medie dimensioni o un sistema di produzione medio-grande.
Elenco dei componenti | Numero di componenti |
|---|---|
Bilanciamento del carico | 1 |
ThingWorx Connection Server | 1 |
Server ThingWorx Foundation | 1 |
Archiviazione di file allegata o NAS | 1 |
Database | 1 |
Sistema di produzione su larga scala per ThingWorx Foundation (non a disponibilità elevata)
Un sistema di produzione su larga scala incorpora componenti aggiuntivi per supportare un numero maggiore di dispositivi connessi e velocità elevate di inserimento dei dati.
Oltre ai componenti della piattaforma, un sistema di produzione su larga scala può includere ThingWorx Connection Servers e un database di serie temporali InfluxDB.
Il sistema InfluxDB inserisce i dati provenienti dagli asset, che ThingWorx gestisce come contenuto dello stream di valori registrato.
È comunque necessario un database relazionale per mantenere il modello di ThingWorx.
InfluxDB può essere distribuito nelle configurazioni a nodo singolo o a più nodi (aziendale) in base ai requisiti di inserimento e di disponibilità elevata. Per ulteriori informazioni, fare riferimento a Utilizzo di InfluxDB come provider di persistenza.
Elenco dei componenti | Numero di componenti |
|---|---|
Bilanciamento del carico | 1 (distribuisce il traffico del dispositivo ai server connessioni) |
ThingWorx Connection Server | 2 ...n (a seconda del numero di dispositivi) |
Server ThingWorx Foundation | 1 |
Database relazionale | 1 |
InfluxDB (nodo singolo) | 1 |
Cluster di produzione di ThingWorx
Per una distribuzione a disponibilità elevata vengono aggiunti ulteriori componenti per rimuovere singoli punti di errore nei livelli di applicazione e dati. Per ThingWorx Platform sono necessari i componenti riportati di seguito.
• Un bilanciamento del carico a disponibilità elevata. I server connessioni e i gruppi di nodi del server Foundation richiedono entrambi un'istanza di bilanciamento del carico per distribuire il carico. Un cluster aziendale Influx richiederebbe anche un'istanza, se utilizzata. Molte opzioni di bilanciamento del carico sono in grado di servire più istanze: un singolo dispositivo può essere utilizzato per servire tutte e tre le istanze, se configurate in modo appropriato.
• Due (o più) ThingWorx Connection Servers. Nelle operazioni in cluster i server connessioni sono necessari per distribuire il carico dei dispositivi nel cluster oppure per ridistribuirlo in caso di errore di un nodo.
• Due (o più) istanze di ThingWorx Foundation. Ogni nodo è attivo e il carico viene distribuito tra di essi.
• ThingWorxStorage è uno spazio di archiviazione su disco condiviso (accessibile da ogni nodo).
| | Per una distribuzione a disponibilità elevata completa è necessario che anche i bilanciamenti del carico e gli spazi ThingWorxStorage condivisi abbiano la ridondanza implementata. |
• I nodi Apache Ignite forniscono la cache condivisa per i nodi ThingWorx Foundation.
• Tre nodi Apache ZooKeeper. ZooKeeper monitora i nodi ThingWorx per decidere se ciascuno di essi è dinamico e funziona come previsto. I nodi ZooKeeper formano un quorum e decidono quando un nodo ThingWorx non è in linea. Se un nodo ThingWorx Foundation è nella modalità non in linea, ZooKeeper riconfigura il bilanciamento del carico ThingWorx per indirizzare il traffico ad altri nodi Foundation.
Per il database PostgreSQL sono necessari i componenti riportati di seguito.
• Nodi del server PostgreSQL - Vengono utilizzati almeno due nodi, idealmente tre.
• Nodi pgpool-II - Si tratta di un minimo di due, idealmente tre, nodi che eseguono task di failover e ripristino in caso di errore del server PostgreSQL. Questi nodi mantengono le connessioni tra client (ThingWorx) e server (PostgreSQL) e gestiscono la replica del contenuto tra i nodi del server PostgreSQL.
Per il sistema InfluxDB Enterprise sono necessari i componenti riportati di seguito.
• Metanodi InfluxDB Enterprise - Si consiglia di impostare tre nodi in modo che sia possibile raggiungere un quorum e consentire al cluster di continuare a funzionare se un nodo restituisce un errore.
• Nodi di dati InfluxDB Enterprise - Può essere uno, ma ne sono consigliabili almeno due. Si consiglia di utilizzare un numero di nodi equamente divisibile per il fattore di replica InfluxDB.
Per ulteriori informazioni sulla distribuzione di ThingWorx in un ambiente a disponibilità elevata, vedere Panoramica del clustering a disponibilità elevata ThingWorx.
Cluster su larga scala e a disponibilità elevata
In questo diagramma, ogni componente del cluster risiede nella propria macchina fisica, nella propria macchina virtuale o nel proprio contenitore. Ciò offre la massima flessibilità in quanto è possibile scalare ciascuno dei diversi gruppi di componenti in modo indipendente.
Elenco dei componenti | Numero di componenti |
|---|---|
Connessione ThingWorx Server | 2 ...n (in base al numero di dispositivi) |
Bilanciamento del carico | 2 o 3 istanze: • Instradare il traffico del dispositivo ai server connessioni • Instradare il traffico tra i nodi ThingWorx • Instradare il traffico tra i nodi di dati InfluxDB Enterprise (se in uso) |
Server ThingWorx Foundation | 2 ... n: in base ai requisiti di disponibilità elevata e scalabilità |
Archiviazione in rete/aziendale | Spazio su disco per i repository di ThingWorxStorage condivisi con tutti i server ThingWorx Foundation. |
Ignite | Due opzioni: • Incorporato nei processi di Foundation • 2 o più nodi separati (a seconda dei requisiti di disponibilità elevata) |
ZooKeeper | Almeno 3. Devono essere in assegnazioni con numero dispari. |
Database | Dipende dal database: • PostgreSQL: 3 nodi di database + 2 nodi pgpool-II • Server MS SQL (non illustrato): almeno 2 come parte di una configurazione di failover. |
InfluxDB Enterprise | 5 (o più): • 3 metanodi • 2 o più nodi di dati, numero totale equamente divisibile per il fattore di replica |
Impronta minima del cluster
In questo diagramma, i componenti vengono compressi o raggruppati in un insieme più piccolo di macchine fisiche/virtuali o contenitori.
Questa configurazione può essere utilizzata per una disponibilità elevata ma è meno scalabile rispetto a una configurazione distribuita in cui i componenti condividono le risorse.
Questo diagramma può inoltre essere usato per esaminare le distribuzioni in cui più distribuzioni indipendenti di ThingWorx utilizzano la stessa infrastruttura condivisa (ZooKeeper, database, storage di rete).
Elenco dei componenti (per nodo di cluster) | Numero di componenti |
|---|---|
ThingWorx Connection Server | 1 (per nodo di cluster) |
Server ThingWorx Foundation | 1 (per nodo di cluster) |
Ignite | Nessuno - In esecuzione nella modalità incorporata all'interno di ciascun processo del server Foundation. |
Elenco dei componenti (condiviso) | Numero di componenti |
|---|---|
Istanze di bilanciamento del carico | 2 o 3 istanze: • Instradare il traffico del dispositivo ai server connessioni. • Instradare il traffico tra i nodi ThingWorx. • Instradare il traffico tra i nodi di dati InfluxDB Enterprise (se in uso). |
ZooKeeper | Almeno 3. Devono essere in assegnazioni con numero dispari. |
Database | Vedere il diagramma precedente. |
Archiviazione in rete/aziendale | Spazio su disco per i repository di ThingWorxStorage condivisi con tutti i server ThingWorx Foundation. |