Architettura

The SKOOR Engine uses a PostgreSQL database to store its configuration data, as well as historical values and historical data. It supports the use of a primary/standby configuration to continuously replicate the database contents. PostgreSQL's own replication methods are used, which means that an exact copy of the database on the primary is kept on the standby and all updates to the database on the primary server are replicated immediately on the standby. Il server primario bufferizza le istruzioni SQL in un log binario, mentre il server secondario richiede queste istruzioni al server.

Ciò garantisce tempi di interruzione brevi in caso di guasti hardware. Tuttavia, NON protegge da errori pilota come istruzioni di cancellazione errate che verranno sincronizzate immediatamente con il server secondario. La replica non sostituisce i backup regolari.

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

Nella modalità predefinita, il server primario sostiene tutto il carico, tutte le richieste degli utenti ricevono risposta dal server web Apache sul server primario, i dati di misurazione vengono consegnati 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 standby.

Caratteristiche principali della configurazione di replica

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

• Se una replica è stata emessa in precedenza, gran parte dei file del database saranno probabilmente già sincronizzati. Lo script NON trasferirà le vecchie tabelle che sono già sincronizzate. Ciò consente di risparmiare larghezza di banda di rete se è necessario eseguire una reinizializzazione.

• Non è previsto il failover automatico dal primario allo standby. È stato progettato per lasciare questa decisione all'uomo. Tuttavia, lo script supporta una modalità non interattiva che consentirebbe di eseguire un failover tramite uno script. (opzione -f ).

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

• Possibilità di eseguire script o comandi personalizzati prima e/o dopo il passaggio 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 prestazioni del primo. Sebbene questo server secondario rimarrà in modalità standby per la maggior parte del tempo, deve essere in grado di sostenere il carico completo quando la sua funzione cambia da secondario a primario.

Devono essere soddisfatti i seguenti prerequisiti:

• La stessa versione di SKOOR è installata sul primario e sullo standby.

• (Opzionale) I collettori esterni sono configurati correttamente e funzionano

  • Il parametro server<n>_address deve essere impostato sullo stesso 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, sul server di standby e su tutti i collettori. Ciò significa che tutti gli host coinvolti devono avere 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 standby e su tutti i collettori.

• Connettività di rete

  • Porta TCP 22 (ssh) dal primario allo standby, viceversa e dal primario e dallo standby a tutti i collettori esterni.

  • Porta TCP 50001 (consegna dati del SKOOR Collector) da tutti i collettori esterni al primario e al secondario.