Comportamenti previsti quando si verificano errori
In questa sezione vengono descritte le azioni che si verificano in una configurazione a disponibilità elevata di ThingWorx in risposta a un errore di uno o più componenti.
Errori del server ThingWorx
Errori del nodo leader ThingWorx
Procedura a disponibilità elevata attuata
1. ZooKeeper non riceve alcuna risposta dal nodo leader.
2. ZooKeeper elegge un nuovo nodo leader dal pool di server di standby ThingWorx.
3. ZooKeeper notifica al nodo di standby che deve diventare il nodo leader.
4. Il nuovo nodo leader si connette al database e inizializza il modello ThingWorx.
5. Il nuovo nodo leader invia conferma al bilanciamento del carico per ricevere l'instradamento di tutte le richieste di ThingWorx.
6. Il bilanciamento del carico instrada tutto il traffico ThingWorx al nuovo nodo leader.
Errori del bilanciamento del carico
Le azioni e i risultati dipendono dalla soluzione a disponibilità elevata del bilanciamento del carico distribuita. Le sessioni attive non devono essere interrotte se il bilanciamento del carico ha la capacità di condividere il contenuto della sessione in tutti i nodi del bilanciamento del carico.
Errore del server HAProxy
In caso di errore dell'unico nodo o di tutti i nodi HAProxy, si verifica quanto descritto di seguito.
• Il nodo leader ThingWorx sarà comunque accessibile tramite il relativo indirizzo IP, ma non tramite l'indirizzo IP HAProxy.
• Le richieste a ThingWorx tramite HAProxy non raggiungono ThingWorx.
In caso di errore di uno di più nodi HAProxy, si verifica quanto descritto di seguito.
• Le sessioni utente esistenti vengono riconosciute in ThingWorx Composer una volta che il bilanciatore HAProxy di backup diventa il nuovo master. L'utente non deve effettuare nuovamente l'accesso.
• I mashup non vengono caricati finché il bilanciatore HAProxy di backup non diventa il master.
• Le entità di navigazione in Composer non vengono caricate finché il bilanciatore HAProxy di backup non diventa il master.
• Le richieste non raggiungono ThingWorx finché il bilanciatore HAProxy di backup non diventa il master.
Errori dei nodi ZooKeeper
Errore di un nodo ZooKeeper
In caso di errore di uno dei tre nodi ZooKeeper, si verifica quanto descritto di seguito.
• Gli altri nodi ZooKeeper rilevano la mancata risposta.
• Se il nodo interessato dall'errore è il nodo leader corrente, viene eletto un nuovo nodo leader ZooKeeper.
• I server ThingWorx non vengono coinvolti, rimangono attivi e accessibili.
Errore di due nodi ZooKeeper
• L'elezione del nodo leader per ZooKeeper non può avere luogo poiché l'impostazione originale di ZooKeeper, che prevede tre nodi, richiede che siano disponibili due server per formare un quorum. Numero massimo di errori consentito = ceil(N/2) - 1
• L'istanza ZooKeeper rimanente non è né un nodo leader né di standby.
• Il nodo leader ThingWorx viene chiuso, poiché non è in grado di comunicare con ZooKeeper per l'elezione del nodo leader.
• Il server di standby ThingWorx continua a provare a comunicare con ZooKeeper finché non torna attivo almeno un altro nodo ZooKeeper.
• Quando due o più nodi ZooKeeper sono di nuovo in linea, viene eletto il nodo leader ZooKeeper. Il nodo di standby ThingWorx viene riconnesso a ZooKeeper e torna a essere il nuovo nodo leader.
• Per diventare nodo di standby, il nodo leader ThingWorx precedente deve essere riavviato.
Errore di ThingWorx e ZooKeeper
In caso di errore di entrambi i nodi leader, per ZooKeeper e ThingWorx, si verifica quanto descritto di seguito.
• Tutte le condizioni elencate in "Errore di un nodo ZooKeeper". È necessario stabilire prima il nuovo nodo leader ZooKeeper, in modo che elegga il nuovo nodo leader ThingWorx.
• Tutte le condizioni elencate in "Errore del nodo leader ThingWorx".
Errori di PostgreSQL
Questa descrizione degli errori di PostgreSQL si basa sulla configurazione descritta di seguito.
• Tre nodi PostgreSQL (writer, reader e standby)
• Utilizzo della replica di streaming tra i nodi PostgreSQL
• Due nodi Pgpool-II che gestiscono l'accesso del client ai nodi PostgreSQL e le procedure di ripristino di PostgreSQL
In caso di errore di un server PostgreSQL, il nodo Pgpool-II attivo rileva l'errore e interrompe l'instradamento delle richieste a quel server. I dati utente o dispositivo salvati al momento dell'errore potrebbero andare persi, se le informazioni non sono state salvate e replicate in altri nodi prima dell'errore.
In caso di errore del nodo PostgreSQL master (partendo dal presupposto che i nodi di sincronizzazione e potenziali siano attivi e in esecuzione), si verifica quanto descritto di seguito.
• Failover del nodo di sincronizzazione tramite Pgpool-II. Il nodo potenziale diventa ora il nodo di sincronizzazione per il nuovo nodo master. È ancora possibile scrivere nel database (ad esempio creare nuove entità e scrivere dati in BDWS).
• Se il master originale torna attivo, è necessario eseguire manualmente il cleanup e configurare l'ambiente in modo che utilizzi il master originale.
In caso di errore di entrambi i nodi di standby (partendo dal presupposto che il nodo master sia ancora attivo e in esecuzione), si verifica quanto descritto di seguito.
• Non si verifica alcun failover e il nodo master deve avere zero nodi per la replica.
• Composer resta accessibile. Le entità vengono caricate e possono essere visualizzate ma non salvate. È possibile visualizzare i log.
• Le azioni che richiedono la scrittura nel database (ad esempio la creazione e il salvataggio di un'entità, l'impostazione di valori su proprietà persistenti e l'aggiunta di una voce di stream) non riescono in quanto PostgreSQL deve replicare i dati in un nodo di standby.
In caso di errore del nodo master e del nodo di standby di sincronizzazione, si verifica quanto descritto di seguito.
• Failover del nodo potenziale. Il nodo potenziale è ora il nodo master con zero nodi per la replica.
• Composer è accessibile. Le entità vengono caricate e possono essere visualizzate ma non salvate. È possibile visualizzare i log.
• Le azioni che richiedono la scrittura nel database (ad esempio la creazione e il salvataggio di un'entità, l'impostazione di valori su proprietà persistenti e l'aggiunta di una voce di stream) non riescono in quanto la scrittura viene bloccata e restituisce un errore.
In caso di errore di tutti e tre i nodi, si verifica quanto descritto di seguito.
• Il failover non si verifica poiché non sono disponibili nodi.
• Composer non ha accesso al database. Di conseguenza le entità non devono essere caricate, la maggior parte dei servizi non funziona (i servizi sottosistema come il sottosistema piattaforma potrebbero continuare a funzionare) e la funzionalità di sistema è limitata (i log, il monitoraggio di sistema e i mashup potrebbero funzionare).
• Non è possibile eseguire operazioni di scrittura e lettura nel database.
Errore di ThingWorx e PostgreSQL
In caso di errore del nodo leader ThingWorx e del master PostgreSQL, si verifica quanto descritto di seguito.
• L'istanza di ThingWorx di standby diventa il nodo leader dopo che il nodo leader ThingWorx diventa inattivo e il nodo di sincronizzazione del database PostgreSQL diventa il nodo master di PostgreSQL.
◦ Il nodo potenziale del database PostgreSQL diventa il nuovo nodo di sincronizzazione.
◦ ThingWorx Composer è disponibile e sono possibili le operazioni di scrittura nel database PostgreSQL (è possibile creare, modificare ed eliminare entità e aggiungere dati).
• Se il nodo master PostgreSQL originale deve essere reimpostato come nodo master, è necessario eseguire manualmente il cleanup dei nodi PostgreSQL e Pgpool-II.
Errore del nodo Pgpool-II
Errore del nodo Pgpool-II attivo
In caso di errore del nodo Pgpool-II attivo, il backup lo rileva e prende in carico la gestione di tutte le richieste ai server PostgreSQL. Gli utenti che hanno effettuato l'accesso al server ThingWorx attivo potrebbero riscontrare dei ritardi nelle applicazioni e potrebbe verificarsi una perdita dei dati utente o dispositivo che avrebbero dovuto essere salvati quando si è verificato l'errore del nodo Pgpool-II.
Errore di tutti i nodi Pgpool-II
In caso di errore di tutte le istanze Pgpool-II, ThingWorx perde l'accesso al contenuto PostgreSQL e la maggior parte delle funzioni non riesce. Potrebbero essere disponibili alcune funzionalità limitate nelle aree riportate di seguito.
• Registrazione - Il log applicazioni potrebbe essere comunque aggiornato con messaggi di errore.
• Monitoraggio di sistema (ad esempio il mashup MonitoringPlatformStats).
• Mashup - I widget che non si basano sui servizi o sui dati del database potrebbero continuare a funzionare.
• Valori di proprietà non persistenti.
• I servizi che non coinvolgono il database.
Errore di ThingWorx e Pgpool-II
In caso di errore simultaneo del nodo leader ThingWorx e delle istanze del master PostgreSQL, si verifica quanto descritto di seguito.
• Il nodo leader ThingWorx perde la leadership, pertanto diventa leader uno dei nodi di standby.
• Il master Pgpool-II perde l'indirizzo IP virtuale. Uno dei nodi di standby Pgpool-II diventa master e a esso viene riassegnato l'indirizzo IP virtuale.
• Il server di standby ThingWorx prova a connettersi al database e vi riesce quando viene stabilito il nuovo master Pgpool.
Errore di Pgpool-II e PostgreSQL
In caso di errore di PostgreSQL e Pgpool-II, si verifica quanto descritto di seguito.
• Il nodo di standby PostgreSQL diventa il nodo master.
• Il nodo di standby Pgpool-II diventa il nodo master e a esso viene trasferito l'indirizzo IP virtuale.
• I servizi rimangono non disponibili per un breve periodo durante il failover.