Cluster dei Server Dr.Web

Conviene aggiornare i Server all'interno di un cluster soltanto da pacchetti d'installazione. In questo caso, occorre arrestare tutti i Server e aggiornarli uno dopo l'altro. Non si deve utilizzare l'aggiornamento tramite il Pannello di controllo (passaggio ad una nuova revisione), in quanto in caso di utilizzo di database comune dopo l'aggiornamento del primo Server tutti gli altri Server non potranno continuare a funzionare e ad aggiornarsi.

Se nella rete antivirus viene creato un cluster di Server Dr.Web, è necessario soddisfare i seguenti requisiti:

Su tutti i Server devono esserci le stesse chiavi di cifratura drwcsd.pub e drwcsd.pri.

Se le chiavi di cifratura non erano create precedentemente, allora durante l'installazione del primo Server del cluster le chiavi di cifratura verranno generate automaticamente.

Le chiavi di cifratura per l'installazione dei successivi Server del cluster possono essere ottenute attraverso il Pannello di controllo: menu Amministrazione → Chiavi di crittografia. A seconda di quello come il cluster viene installato successivamente, potrebbero essere necessarie entrambe le chiavi o soltanto drwcsd.pri:

•Se la chiave privata drwcsd.pri viene impostata durante l'installazione del Server, la chiave pubblica drwcsd.pub viene generata automaticamente.

•Se la chiave privata desiderata non viene impostata durante l'installazione di Server, dopo l'installazione è necessario sostituire entrambe le chiavi manualmente.

Il percorso dei file di configurazione è riportato nella sezione Server Dr.Web.

Per tutti i Server devono essere impostati gli stessi indirizzo IP o nome DNS di Server utilizzati nella generazione dei file di installazione di Agent per le postazioni della rete antivirus.

Questo nome viene impostato attraverso il Pannello di controllo: Amministrazione → Configurazione del Server Dr.Web → scheda Rete → scheda Download → il campo Indirizzo di Server Dr.Web. Le impostazioni di questa sezione vengono conservate nel file di configurazione download.conf (il file viene descritto nel documento Allegati, p. G3. File di configurazione download.conf).

Sul server DNS in rete è necessario registrare il nome comune di cluster per ogni singolo Server e impostare il metodo di bilanciamento del carico.

Affinché le impostazioni vengano applicate in modo automatico nel cluster di Server Dr.Web, è necessario utilizzare un apposito protocollo di cluster.

Per configurare il protocollo di cluster, è necessario per ciascuno dei Server nel Pannello di controllo passare al menu Amministrazione → Configurazione del Server Dr.Web e configurare le seguenti impostazioni:

a)Per attivare il protocollo di cluster, nella scheda Moduli spuntare il flag Protocollo di cluster dei Server Dr.Web.

b)Per configurare i parametri di interazione dei Server inclusi nel cluster, nella scheda Cluster configurare le impostazioni relative.

c)Dopo aver configurato tutti i parametri necessari, premere Salva e riavviare i Server.

In questo esempio per tutti i Server del cluster vengono configurati i trasporti per tutte le interfacce. In altri casi, per esempio quando una delle reti è esterna per il cluster e gli Agent si connettono attraverso di essa e la seconda rete è una all'interno del cluster, è preferibile aprire il protocollo di cluster soltanto per le interfacce della rete interna. In questo caso come le interfacce è necessario impostare gli indirizzi del tipo 192.168.1.1, ..., 192.168.1.N.

Per poter utilizzare un database unico, tutti i Server Dr.Web devono essere della stessa versione.

Tutti i Server Dr.Web all'interno di un cluster devono utilizzare lo stesso database esterno.

Come nel caso di utilizzo di database senza l'organizzazione di un cluster, ciascuno dei Server si connette al database in un modo indipendente, e tutti i dati dei Server vengono conservati separatamente. Ovunque dov'è applicabile, il Server prende dal database soltanto i record associati al suo ID il quale è unico per ciascun Server. L'utilizzo dello stesso database consente ai Server di interagire con gli Agent che inizialmente sono stati registrati sugli altri Server del cluster.

Quando viene creato un cluster dei Server con un unico database, è necessario tenere presente le seguenti caratteristiche:

•Il database può essere installato sia separatamente da tutti i Server che su uno dei computer su cui è installato un Server del cluster.

•Il database deve essere creato prima dell'installazione del primo Server del cluster o prima del momento della connessione del primo Server al database.

•Nel corso dell'aggiunzione di nuovi nodi al cluster (ad eccezione del primo Server), durante l'installazione dei Server non è consigliabile impostare subito il database unico che viene utilizzato in questo cluster. Altrimenti questo potrebbe provocare l'eliminazione delle informazioni già memorizzate nel database. È consigliabile installare inizialmente i Server con il database interno e dopo l'installazione connetterli con il database esterno unico.
È possibile riconfigurare i Server all'utilizzo del database esterno attraverso il Pannello di controllo: nel menu Amministrazione → Configurazione del Server Dr.Web → nella scheda Database o attraverso il file di configurazione dei Server drwcsd.conf.

•Ad eccezione del primo Server del cluster, non è consigliabile introdurre nel cluster i Server che già sono operativi nella rete antivirus utilizzando un altro database esterno o quello interno. Questo provocherà una perdita dei dati: le informazioni sulle postazioni, statistiche, impostazioni (salvo le impostazioni conservate nei file di configurazione) in quanto i dati nel database vengono eliminati completamente durante l'importazione. In questo caso è possibile soltanto un'importazione parziale di alcune informazioni.

Su tutti i Server del cluster i repository devono contenere gli aggiornamenti della stessa versione.

•Aggiornare simultaneamente tutti i Server del cluster da SAM. In questo caso tutti i Server avranno la versione più recente degli aggiornamenti. Inoltre è possibile configurare l'aggiornamento dei repository di tutti i Server dalla zona locale degli aggiornamenti da cui verrà distribuita la stessa versione confermata degli aggiornamenti dei prodotti o quella più recente in caso della creazione di un mirror di SAM.

•È possibile creare una struttura ibrida che combina sia un cluster di Server che una struttura gerarchica basata sulle relazioni tra server. In tale caso uno dei Server (potrebbe essere un Server del cluster o uno che non fa parte del cluster) viene nominato principale e riceve gli aggiornamenti da SAM. Gli altri Server del cluster – quelli subordinati – ricevono gli aggiornamenti dal Server principale attraverso la comunicazione tra server.

Se viene configurato che i Server del cluster ricevano gli aggiornamenti dalla zona locale (mirror di SAM) o dal Server principale, è necessario monitorare l'operatività di questa zona o del Server principale. Se il nodo che distribuisce gli aggiornamenti fallisce, è necessario riconfigurare uno degli altri Server al ruolo del Server principale o rispettivamente creare una nuova zona degli aggiornamenti per la ricezione degli aggiornamenti da SAM.

Per distribuire licenze tra i Server del cluster, è possibile utilizzare i seguenti approcci:

a)Creare una struttura ibrida che combina sia un cluster dei Server che una struttura gerarchica basata sulle relazioni tra i server. Tale struttura sarà utile se per l'interazione con gli Agent all'interno di un sistema a cluster dei Server viene utilizzata l'allocazione dinamica delle postazioni tra i Server del cluster. In questo caso il numero necessario di licenze viene propagato dal Server principale (potrebbe essere un Server del cluster o uno che non fa parte del cluster) ai Server subordinati attraverso la comunicazione tra i server direttamente durante il funzionamento.

In questo modo basta memorizzare sul Server principale un file di licenza con il numero di licenze corrispondente al numero di postazioni e distribuire il numero di licenze necessario sui Server subordinati durante il funzionamento del cluster. L'amministratore della rete antivirus configura manualmente la distribuzione sui Server subordinati del numero di licenze necessario per il periodo necessario.

Per configurare la distribuzione delle licenze sui Server adiacenti, utilizzare la Gestione licenze.

Per esempio, è possibile configurare una struttura gerarchica dei Server e allocare il Server principale (potrebbe essere un Server del cluster o uno che non fa parte del cluster) che distribuirà sia gli aggiornamenti del repository che le licenze dal file di licenza a tutti i nodi del cluster.

b)Quando si sceglie di non configurare la struttura gerarchica dei Server, non c'è la possibilità di distribuire licenze dall'unico file di licenza tra tutti i Server. In tale caso è necessario pianificare in anticipo la struttura della rete antivirus tenendo conto della disponibilità di un cluster di Server e utilizzare diversi file di licenza – uno per ciascun Server del cluster. Il numero totale di licenze in tutti i file di licenza è pari al numero totale di postazioni nella rete, però è necessario calcolare in anticipo la distribuzione del numero di licenze per i Server del cluster basandosi sul numero stimato di postazioni che si pianifica di connettere a ciascuno dei Server.

Per escludere la duplicazione delle query al database, è consigliabile eseguire soltanto su uno dei Server le seguenti task dal calendario del Server: Purge Old Data, Backup sensitive data, Purge old stations, Purge expired stations, Purge unsent IS events. Per esempio, sul Server che si trova sullo stesso computer del database esterno unico. O sul computer del cluster con le maggiori prestazioni se le configurazioni dei Server sono diverse e il database è installato su un computer separato.