ThingWorx a disponibilità elevata
Panoramica del clustering a disponibilità elevata di ThingWorx
Per ridurre la durata delle interruzioni per i sistemi Internet of Things (IoT) critici, è possibile configurare ThingWorx per il funzionamento in un ambiente a disponibilità elevata (HA) in modalità cluster. Il clustering offre ulteriore scalabilità e disponibilità elevata, a condizione che tutti i componenti siano configurati correttamente.
 |
Il clustering a disponibilità elevata non deve essere utilizzato per una soluzione di ripristino di emergenza.
|
|
|
L'utilizzo di più zone di disponibilità per una distribuzione a disponibilità elevata non è supportato. La latenza di rete tra le zone può essere troppo elevata per consentire per una comunicazione costante tra i nodi ThingWorx e Apache Ignite.
|
Le sezioni riportate di seguito illustrano l'impostazione e la configurazione di un ambiente di clustering e i componenti e le considerazioni per una distribuzione di ThingWorx a disponibilità elevata.
Tutte le distribuzioni a disponibilità elevata richiedono risorse aggiuntive rispetto a una distribuzione progettata per soddisfare esclusivamente i requisiti funzionali e di scalatura. Tali risorse sono basate su hardware (ad esempio server, dischi, servizi di bilanciamento del carico e così via) e su software (ad esempio servizi di sincronizzazione e servizi di bilanciamento del carico). Le risorse aggiuntive vengono quindi configurate in modo da garantire che non esistano singoli punti di errore all'interno della distribuzione a disponibilità elevata.
Tutte le distribuzioni a disponibilità elevata devono basarsi su un contratto SLA (Service Level Agreement) in cui siano stati analizzati i requisiti di uptime dell'applicazione per la distribuzione specifica. Ad esempio, per quante ore al mese il sistema può restare non in linea? Si tratta del tempo di inattività consentito per gli errori di sistema, gli aggiornamenti dell'applicazione o entrambi? Il numero di risorse aggiuntive necessarie per un sistema a disponibilità elevata dipende dal contratto SLA su cui si basa. In generale, con l'aumentare dei requisiti del contratto SLA, aumenta anche la necessità di aggiungere risorse.
Glossario dei termini
• disponibilità elevata
Un sistema o un componente in grado di funzionare in modo continuativo per il periodo di tempo desiderato.
• scalabilità
Possibilità di incrementare il carico che un sistema può supportare aumentando la memoria, il disco o la CPU o aggiungendo server.
• cluster
Funzionamento simultaneo di istanze della stessa applicazione. Un cluster offre elevata disponibilità e scalabilità.
• singleton
Il server singleton è un server nel cluster che gestisce i comportamenti nei vari cluster, ad esempio timer e scheduler. Garantisce che i task vengano eseguiti una sola volta all'interno del cluster.
• indirizzo IP virtuale
Un indirizzo IP che rappresenta un'applicazione. I client che utilizzano l'IP virtuale vengono in genere instradati a un bilanciamento del carico che a sua volta indirizza la richiesta al server che esegue l'applicazione.
• bilanciamento del carico
Dispositivo che riceve il traffico di rete e lo distribuisce alle applicazioni pronte per accettarlo.
• failover
Modalità operativa di backup in cui le funzioni di un componente di sistema (ad esempio un processore, un server, una rete o un database) vengono assunte dai componenti del sistema secondario quando il componente principale diventa non disponibile a causa di un errore o al termine di un tempo di attesa programmato.
• coerenza finale
La propagazione delle modifiche a tutti i server di un ambiente cluster richiede tempo.Per ulteriori informazioni, vedere Coerenza finale.
• stato condiviso
Stato condiviso tra più server nel cluster, che si presenta sempre uguale indipendentemente dal server in cui viene visualizzato.I dati delle proprietà sono un esempio di stato condiviso, dove il valore della proprietà corrente è lo stesso in tutti i server.
Architettura di riferimento ThingWorx per la disponibilità elevata
L'immagine riportata di seguito mostra una configurazione cluster di ThingWorx.
Una distribuzione cluster può includere i componenti elencati di seguito.
• Utenti e dispositivi - Nessun ruolo nella funzionalità a disponibilità elevata. Non sono interessati da alcun cambiamento. Utilizzano sempre gli stessi URL e gli stessi indirizzi IP, anche in caso di modifiche nel server ThingWorx principale.
• Firewall - Nessuna funzione a disponibilità elevata può essere considerata facoltativa. I firewall vengono spesso posizionati per implementare i requisiti di protezione.
• Servizi di bilanciamento del carico - Gestiscono un indirizzo IP virtuale per l'applicazione che supportano. Tutto il traffico instradato all'indirizzo IP virtuale viene indirizzato all'applicazione attiva in grado di riceverlo.
• ThingWorx Connection Servers - Riceve il traffico WebSocket dagli asset e lo instrada a ThingWorx Platform. I server connessioni possono operare in una configurazione cluster. Una volta indirizzato a un server connessioni specifico, un asset deve utilizzare sempre lo stesso server connessioni. Se il server va in modalità non in linea, l'asset deve essere reindirizzato a un altro server connessioni disponibile.
• ThingWorx Foundation - Riceve tutto il traffico di utenti e asset.
• Repository ThingWorx - Le posizioni di archiviazione obbligatorie, ad esempio ThingworxPlatform, ThingworxStorage e ThingworxBackupStorage e tutte le posizioni di archiviazione che vengono aggiunte per supportare l'implementazione. Per un ambiente cluster, le cartelle di archiviazione devono trovarsi in una posizione di archiviazione comune a cui tutti i server ThingWorx possono accedere in modo analogo.
• Apache ZooKeeper - ZooKeeper è un servizio di coordinamento centralizzato utilizzato da ThingWorx Connection Server e Ignite per l'individuazione del servizio, l'elezione del singleton e il coordinamento distribuito.
• Apache Ignite - Ignite fornisce una cache di memoria distribuita per la condivisione dello stato tra i server del cluster.
• PostgreSQL - Per una configurazione a disponibilità elevata, PostgreSQL opera attraverso due o più nodi del server in una configurazione standby a caldo. Un nodo riceve tutto il traffico di scrittura e uno degli altri nodi può ricevere tutto il traffico di lettura. Viene attivata la replica di streaming tra tutti i nodi per mantenere ogni nodo aggiornato.
• Pgpool-II - Viene utilizzato solo nelle configurazioni a disponibilità elevata di PostgreSQL. I nodi Pgpool-II ricevono le richieste di ThingWorx (letture e scritture) e le indirizzano al nodo PostgreSQL appropriato. Pgpool-II inoltre monitora lo stato di ogni nodo PostgreSQL e può avviare il failover e l'assegnazione di nuove destinazioni dei task quando uno dei nodi passa in modalità non in linea.
• Microsoft SQL Server (non illustrato) - Viene utilizzato il failover Microsoft per garantire che almeno un server MS SQL sia in linea e disponibile.
• InfluxDB - Per una configurazione di clustering di ThingWorx non è richiesta un'implementazione di InfluxDB. Se è necessario soddisfare i requisiti di immissione dell'implementazione, assicurarsi che sia configurato per la disponibilità elevata.