Architettura

Lo SKOOR Engine utilizza un database PostgreSQL per memorizzare i dati di configurazione e i dati storici e di cronologia. Supporta l'uso di una configurazione primaria/standby per replicare continuamente i contenuti del database. Vengono utilizzati i metodi di replica propri di PostgreSQL, il che significa che una copia esatta del database sul primario viene mantenuta sullo standby e tutti gli aggiornamenti del database sul server primario vengono replicati immediatamente sullo standby. Il server primario memorizza le istruzioni SQL in un registro binario e il server standby le richiede al server.

Questo assicura tempi di interruzione brevi in caso di guasti hardware. Tuttavia, NON protegge dagli errori di pilotaggio, come le dichiarazioni di cancellazione errate, che vengono sincronizzate immediatamente con il server standby. La replica non sostituisce i backup regolari.

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

Nella modalità predefinita il primario porta tutto il carico, tutte le richieste degli utenti sono risposte dal webserver Apache sul primario, i dati di misurazione sono 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 standby.

Caratteristiche principali della configurazione di replica

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

• Se è stata eseguita una replica in precedenza, gran parte dei file del database saranno probabilmente già sincronizzati. Lo script NON trasferirà le vecchie tabelle già sincronizzate. In questo modo si risparmia la larghezza di banda della rete nel caso in cui sia necessario eseguire una nuova inizializzazione.

• Non è previsto il failover automatico da primario a standby. È stato progettato per lasciare questa decisione all'uomo. Tuttavia, lo script supporta una modalità non interattiva che consente di emettere un failover da parte di uno script. (opzione -f ).

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

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

Requisiti

Per impostare la replica del database è necessario un secondo server SKOOR con le stesse prestazioni del primo. Anche se questo standby sarà in modalità standby per la maggior parte del tempo, deve essere in grado di sostenere l'intero carico quando la sua funzione passa da standby a primaria.

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 è identico sul server primario, su quello standby e su tutti i collettori. Ciò significa che tutti gli host coinvolti devono avere la stessa versione di SKOOR installata.

• Il file /etc/opt/eranger/eranger-replication.cfg è configurato correttamente ed è identico su primario, standby e 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 dei dati del collettore SKOOR) da tutti i collettori esterni al primario e allo standby.