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 e inoltre il certificato Server drwcsd-certificate.pem.

Se le chiavi di cifratura e il certificato non sono stati precedentemente creati, essi verranno generati automaticamente durante l'installazione del primo Server del cluster.

È possibile ottenere le chiavi di cifratura e il certificato necessari per installare ulteriori Server del cluster attraverso il Pannello di controllo: menu Amministrazione → Chiavi di crittografia. In seguito possono essere richiesti sia la chiave privata che il certificato: quando viene impostata la chiave privata drwcsd.pri durante l'installazione di un Server, la chiave pubblica drwcsd.pub e il certificato drwcsd-certificate.pem vengono formati automaticamente, però a generazione del certificato viene creata una sua versione nuova, quindi il certificato deve essere sostituito con la stessa versione su tutti i Server di un cluster (v. Strumenti per la connessione sicura).

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 il pulsante 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 di 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 è univoco 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 i 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)All’interno di un cluster non viene configurata alcuna struttura gerarchica dei Server. Basta aggiungere una chiave (o più chiavi) di licenza su uno dei Server del cluster. Informazioni su questa chiave di licenza verranno registrate in un database comune. Così, la chiave di licenza verrà utilizzata da tutti i Server del cluster allo stesso tempo. Il numero totale di licenze memorizzate nel database comune deve corrispondere al numero totale di postazioni connesse a tutti i Server del cluster.

Per poter utilizzare una chiave di licenza su tutti i Server del cluster, e non solo sul Server su cui la chiave è stata aggiunta, è necessario riavviare gli altri Server del cluster dopo l’aggiunta della chiave.

b)È possibile creare una struttura ibrida che combini 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 vengono utilizzati Server sia inclusi che non inclusi nel cluster. In questo caso il numero di licenze necessario viene distribuito dal file della chiave attraverso la comunicazione tra i server direttamente durante il funzionamento:

•Da un Server che non è incluso nel cluster a uno dei Server del cluster. Le licenze distribuite verranno utilizzate da tutti i Server del cluster come descritto in p. a).

•Da uno dei Server del cluster (cioè da una chiave utilizzata da tutti i Server del cluster) su un Server non incluso nel cluster.

Per esempio, è possibile configurare una struttura gerarchica dei Server e contrassegnare un Server principale (può essere un Server del cluster o uno che non fa parte del cluster) che distribuirà sia gli aggiornamenti del repository che le licenze da un file di licenza.

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.