Coerenza finale in ThingWorx a disponibilità elevata
Quando si esegue ThingWorx in modalità cluster, le modifiche al modello vengono uniformate nel cluster. La sincronizzazione delle modifiche apportate sul server A con i server B, C e così via richiede un po' di tempo. Per consentirne la sincronizzazione, le modifiche vengono registrate nel sync_log gestito nel provider di persistenza del modello ThingWorx. Ogni server del cluster esegue un servizio di monitoraggio delle modifiche a una frequenza configurabile (con un valore di default di 100 ms) e verifica eventuali modifiche alle entità nel sync_log. Il servizio di monitoraggio delle modifiche scaricherà e ricaricherà le entità che cambiano sul server, supponendo che il database sia la fonte dati di riferimento. Questa coerenza finale si applica solo alle modifiche al modello e alla configurazione, mentre lo stato risulta immediatamente coerente.
• HTTP - HTTP utilizza sessioni memorizzate in modo che un singolo utente sia associato a un singolo computer. Questo garantisce che un utente visualizzi immediatamente tutte le modifiche. Le modifiche apportate da altri utenti su altri server alla fine saranno coerenti.
• WebSocket - Quando una modifica del modello viene effettuata tramite un WebSocket, la versione del modello corrente viene memorizzata nella sessione di WebSocket. Le richieste WebSocket vengono instradate attraverso diversi server per favorire la distribuzione del carico. La richiesta successiva effettuata nella sessione di WebSocket verrà sospesa finché il server a cui è connessa non corrisponderà almeno alla versione memorizzata nella sessione. Se il server non è in grado di sincronizzarsi dopo circa un secondo, si verificherà il timeout.
Negli scenari riportati di seguito è descritto un impatto ridotto per gli utenti.
• Scenario 1: HTTP
Dispositivo > HAProxy > Piattaforma1..N
In questo scenario, si effettua la connessione alla piattaforma 1 e si apportano modifiche al modello. Se quindi si connette un utente diverso alla piattaforma 2 e si verificano le modifiche apportate, alla fine queste verranno visualizzate. Il cluster risulterà infine coerente relativamente alle modifiche del modello grazie a un processo di sincronizzazione. Se questo è il caso di utilizzo corrente, è necessario creare un nuovo tentativo per attendere che le modifiche siano disponibili.
• Scenario 2: WebSocket
Dispositivo > HAProxy > Server CX1..N = > Piattaforma1..N
In questo scenario, il dispositivo è punto a punto con un server connessioni. Le richieste della piattaforma vengono ciclizzate tra i server. Se il dispositivo apporta una modifica al modello e quindi effettua un'altra richiesta che passa a un altro server, le prime modifiche vengono apportate prima dell'elaborazione. La richiesta viene posticipata fino a quando la versione del modello non viene sincronizzata almeno con la versione in cui è stata apportata la modifica. Se non riesce a eseguire la sincronizzazione in un determinato periodo di tempo, si verificherà il timeout della richiesta. Di conseguenza, questo dispositivo potrà comunicare con qualsiasi server e ottenere la risposta appropriata.
Se si connette un secondo dispositivo per esaminare le modifiche apportate dal primo dispositivo, la coerenza finale verrà applicata anche al secondo dispositivo. L'attesa delle modifiche da parte del sistema è garantita solo in una singola connessione.
• Scenario 3: la richiesta HTTP di modifica del modello attiva una notifica a un dispositivo connesso
Dispositivo > HAProxy > Server CX1..N = > Piattaforma1..N
Un utente apporta una modifica al modello e il dispositivo riceve una notifica della modifica in modo che possa eseguire di nuovo il pull delle definizioni. Il dispositivo aveva la possibilità di eseguire il pull dei dati da un server che non visualizza ancora la modifica. A questo punto, la versione del modello viene inserita nella sessione di WebSocket, in modo che, se invia una richiesta a un server con una versione di modello inferiore, attenderà che questo si sincronizzi almeno alla versione del modello prima di tornare. Se non riesce a eseguire la sincronizzazione in tempo, si verifica il timeout della richiesta.
Di conseguenza, è stato aggiunto un nuovo postCommitEventQueue. Qualsiasi evento aggiunto, ad esempio le modifiche delle proprietà, verrà attivato dopo il commit della transazione completa e quando la nuova versione del modello sarà nota. Quando il dispositivo viene notificato, la versione del modello viene inserita nella sessione di WebSocket per garantire che le richieste future del dispositivo attendano che il server sia coerente con le modifiche originali.
Eliminazione dei dati del sync_log
Man mano che vengono apportate modifiche al modello di oggetto, le dimensioni del sync_log continuano ad aumentare, fino a quando non vengono eliminate le voci obsolete. Una volta apportate le modifiche al modello, è possibile eliminare le voci associate in sync_log per ridurre le dimensioni del sync_log e migliorare le prestazioni e la stabilità del cluster.
L'eliminazione di dati del Sync_log viene configurata nel sottosistema Clustering della scheda Configurazione. Per attivare l'eliminazione automatica, configurare la programmazione dell'eliminazione e le dimensioni dei batch.
|
Impostazione
|
Default
|
Descrizione
|
|
Enable
|
True (attivata)
|
Questa impostazione attiva o disattiva l'eliminazione automatica.
|
|
Schedule
|
0 30 0 * * ?
|
In questo modo viene impostata la programmazione dell'eliminazione dei dati nel sync_log.
|
|
Batch size for purge
|
10000
|
Indica il numero di record da eliminare dal sync_log, a partire dal meno recente.
|