ThingWorx a disponibilità elevata
Panoramica di ThingWorx in ambienti a disponibilità elevata
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 questa guida vengono proposte considerazioni relative alla disponibilità elevata in riferimento a un sistema ThingWorx e vengono descritti i componenti inclusi in una distribuzione a disponibilità elevata di ThingWorx.
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.
Definizioni
• disponibilità elevata
Un sistema o un componente in grado di funzionare in modo continuativo per il periodo di tempo desiderato.
• attivo/attivo
Funzionamento simultaneo di istanze della stessa applicazione.
• attivo/passivo
Funzionamento di una sola istanza di un'applicazione alla volta. È possibile aggiungere altre istanze in base alle esigenze.
• leader o master
Il server attivo in una configurazione a disponibilità elevata attiva/passiva in cui viene instradato tutto il traffico.
• standby
Un server in una configurazione a disponibilità elevata attiva/passiva in attesa di sostituire il leader corrente in caso di errore.
• 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 all'applicazione pronta per accettarlo. Per una configurazione a disponibilità elevata attiva/passiva, il bilanciamento del carico indirizza il traffico al leader corrente. Per una configurazione a disponibilità elevata attiva/attiva, il bilanciamento del carico indirizza il traffico a una di numerose applicazioni.
• 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.
Architettura di riferimento ThingWorx per la disponibilità elevata
L'immagine riportata di seguito mostra una configurazione a disponibilità elevata di ThingWorx.
Di seguito sono riportati i componenti di questo tipo di configurazione e il relativo ruolo in una distribuzione a disponibilità elevata.
• 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 di connessione possono operare in una configurazione attiva/attiva. 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. ThingWorx Foundation opera in una configurazione attiva/passiva con un server leader e uno o più server di standby. Il server leader è in linea e riceve il traffico. I server di standby vengono eseguiti in uno stato di riscaldamento quando l'applicazione è in esecuzione, ma non presentano connessioni attive al database e non ricevono traffico. Un bilanciamento del carico instrada tutto il traffico al leader. Se il leader passa alla modalità non in linea, il server di standby viene promosso a leader e il traffico viene instradato a tale server.
• 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 a disponibilità elevata, i repository ThingWorx devono esistere in una posizione di archiviazione comune a cui tutti i server ThingWorx (leader e standby) possono accedere con la stessa facilità.
• Apache ZooKeeper - ZooKeeper è un servizio di coordinamento centralizzato utilizzato da ThingWorx per eleggere uno dei server ThingWorx come leader in un momento specifico. In ogni server ThingWorx è incorporato un client ZooKeeper pronto a reagire alle modifiche apportate alla configurazione, ad esempio in caso di errore del leader ThingWorx corrente.
• 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.
• DataStax Enterprise (DSE) - Per una configurazione a disponibilità elevata di ThingWorx non è obbligatoria un'implementazione DSE. Se è necessario soddisfare i requisiti di immissione dell'implementazione, assicurarsi che sia configurato per la disponibilità elevata. L'implementazione tipica di DSE soddisfa la maggior parte dei requisiti per la disponibilità elevata. Include più nodi Cassandra, che raccolgono contenuto, e almeno due nodi Solr. La progettazione DSE replica tutto il contenuto in almeno un altro nodo.
 | A partire dalla versione 8.5.0 di ThingWorx Platform, DataStax Enterprise non è più in vendita e non sarà supportato in una release futura. Per ulteriori informazioni, fare riferimento all'articolo relativo al
termine della commercializzazione. |
Requisiti per l'installazione
Note e avvertenze:
• I passi di questo processo ad alta disponibilità devono essere utilizzati da un amministratore di database (DBA) che abbia esperienza con i database relazionali nella configurazione a disponibilità elevata (PostgreSQL, Microsoft SQL Server e DataStax Enterprise). Le competenze richieste comprendono installazione, ottimizzazione e clustering a disponibilità elevata.
• Le indicazioni fornite qui riguardano la distribuzione di ambienti ad alta disponibilità. In un ambiente di produzione potrebbe essere necessario un'ulteriore ottimizzazione delle prestazioni, che, tuttavia, non viene qui indicata.
• I passi dettagliati sono esempi di riferimento, destinati solo a un ambiente di QA o sandbox. In un ambiente di produzione potrebbe essere necessario modificare i comandi e le impostazioni per ottenere prestazioni ottimali.
• Tutte le configurazioni di failover devono essere completamente testate e convalidate prima di essere utilizzate in produzione.
• I passi di questo processo non riguardano scenari di failback, in cui un leader che genera errore viene corretto e quindi restituito alla posizione di leader. Si presuppone che il componente in errore venga corretto e torni al servizio come componente non leader.
Sistemi operativi supportati
Requisiti generali della disponibilità elevata
Indirizzi IP virtuali
• Da utenti e asset ai server di connessione (se vengono utilizzati i server di connessione)
• Dai server di connessione a ThingWorx Foundation
• Da ThingWorx Foundation a PostgreSQL a disponibilità elevata (se si utilizza PostgreSQL)
• Da ThingWorx Foundation a Microsoft SQL Server a disponibilità elevata (se si utilizza Microsoft SQL Server)
Requisiti hardware
I passi qui indicati presuppongono che in una configurazione a disponibilità elevata di ThingWorx venga utilizzata la ridondanza hardware completa.
• Ogni istanza di un'applicazione deve essere in esecuzione su hardware separato per evitare singoli punti di errore a livello di hardware. Ad esempio i server ThingWorx, che siano fisici, virtuali o basati su cloud, non devono operare sullo stesso hardware fisico.
• Questo requisito è previsto per tutte le applicazioni della configurazione a disponibilità elevata di ThingWorx (ThingWorx, PostgreSQL, DataStax Enterprise, ZooKeeper e così via) per ridurre il rischio di errori hardware.
• Nel processo qui indicato si presuppone l'utilizzo di router, interruttori, alimentatori ridondanti e così via.
Proprietà di ThingWorx in una configurazione a disponibilità elevata
Per evitare la perdita di dati in caso di failover, è necessario impostare le proprietà di ThingWorx come persistenti. Se non sono persistenti, un failover dai server principali a quelli secondari cancella i valori in memoria.
Requisiti di PostgreSQL
• Pgpool-II e PostgreSQL DB installati in ambienti RHEL o Ubuntu.
• Minimo due server host DB che eseguono una versione supportata di PostgreSQL. Si consiglia di utilizzarne tre.
• La situazione tipica prevede due server che eseguono Pgpool-II 3.7.<più recente> con watchdog configurato. Questo è l'esempio qui fornito, ma sono possibili anche altre configurazioni a disponibilità elevata che non utilizzano Pgpool-II.
Requisiti di Microsoft SQL Server
• Minimo due server host DB che eseguono una versione supportata di Microsoft SQL Server.
• Microsoft SQL Server è configurato per operare tramite una delle seguenti metodologie a disponibilità elevata di Microsoft:
◦ Istanze dei cluster di failover Always On
◦ Gruppi di disponibilità Always On
Requisiti di DataStax Enterprise
• Minimo cinque nodi per un cluster DataStax Enterprise:
◦ Tre nodi Cassandra
◦ Due nodi Solr
◦ (Facoltativo) Un nodo DSE OpsCenter per il lavoro amministrativo, poiché OpsCenter non è fondamentale per il funzionamento e non richiede una configurazione a disponibilità elevata.
Requisiti di InfluxDB
• Minimo due metanodi; se ne consigliano tre per la maggior parte dei casi di utilizzo
• Minimo due nodi dati; si consiglia di averne un numero pari
• Una distribuzione tipica deve avere tre metanodi e un numero pari di nodi dati