Architettura

The SKOOR Engine uses a PostgreSQL database to store its configuration data, as well as historical values and data related to history. It supports the use of a primary/standby configuration to continuously replicate the database contents. Vengono utilizzati i metodi di replica propri di PostgreSQL, il che significa che sul server di standby viene conservata una copia esatta del database presente sul server primario e che tutti gli aggiornamenti apportati al database sul server primario vengono replicati immediatamente sul server di standby. Il server primario memorizza temporaneamente le istruzioni SQL in un log binario, mentre il server di standby richiede tali istruzioni al server primario.

Ciò garantisce tempi di inattività ridotti in caso di guasti hardware. Tuttavia, NON protegge da errori umani, come istruzioni di cancellazione errate, che verranno sincronizzate immediatamente sul server di riserva. La replica non sostituisce i backup regolari.

La figura seguente mostra un esempio di struttura di replica standard.

Nella modalità predefinita, il server primario gestisce tutto il carico: tutte le richieste degli utenti ricevono risposta dal server web Apache sul server primario, i dati di misurazione vengono inviati dai collettori al server primario corrente e memorizzati nel database. I servizi eranger-server, eranger-collector ed eranger-report NON vengono eseguiti sul server di riserva.

Caratteristiche principali della configurazione di replica

• La replica può essere implementata anche con SKOOR Collectors esterni.

• Se in precedenza è stata eseguita una replica, è probabile che gran parte dei file del database sia già sincronizzata. Lo script NON trasferirà le vecchie tabelle che sono già sincronizzate. Ciò consente di risparmiare larghezza di banda di rete nel caso in cui sia necessario eseguire una reinizializzazione.

• Non è previsto alcun failover automatico dal server primario a quello di standby. Il sistema è stato progettato per lasciare questa decisione a un operatore umano. Tuttavia, lo script supporta una modalità non interattiva che consentirebbe di eseguire un failover tramite script (opzione -f).

• Possibilità di monitorare il server primario dal server di standby (indipendentemente da SKOOR) inviando un’e-mail non appena si rileva che l’SKOOR Engine non è più in esecuzione sul server primario corrente.

• Possibilità di eseguire script o comandi personalizzati prima e/o dopo il cambio delle funzioni del server (da standby a primario e viceversa).

Requisiti

Per configurare la replica del database è necessario un secondo SKOOR Server con le stesse specifiche di prestazione del primo. Sebbene questo server di standby rimanga in modalità standby per la maggior parte del tempo, deve essere in grado di sostenere il carico completo quando la sua funzione passa da standby a primario.

Devono essere soddisfatti i seguenti prerequisiti:

• Sia sul server primario che su quello di standby deve essere installata la stessa versione di SKOOR.

• (Opzionale) i collettori esterni sono configurati correttamente e funzionanti

  • Il parametro server<n>_address deve essere impostato sullo stesso indirizzo IP del server primario

  • I collettori che utilizzano il protocollo HTTP non possono essere commutati automaticamente

• Il file /opt/eranger/bin/eranger-server-replication.pl deve essere identico sul server primario, su quello di standby e su tutti i collettori. Ciò significa che su tutti gli host coinvolti deve essere installata la stessa versione di SKOOR Server.

• Il file /etc/opt/eranger/eranger-replication.cfg è configurato correttamente ed è identico sul server primario, su quello di riserva e su tutti i collettori.

• Connettività di rete

  • Porta TCP 22 (ssh) dal server primario a quello di riserva, e viceversa, nonché dal server primario e da quello di riserva verso tutti i collettori esterni.

  • Porta TCP 50001 (trasmissione dei dati del SKOOR Collector) da tutti i collettori esterni al primario e allo standby.