Cluster des Serveurs Dr.Web

La mise à jour des Serveurs au sein d’un cluster doit être effectuée uniquement depuis les packages d’installation. Dans ce cas, il faut arrêter tous les Serveurs et les mettre à jour l’un après l’autre. Il ne faut pas utiliser la mise à jour via le Centre de gestion (passage vers la nouvelle révision), car en cas d’utilisation de la base de données commune, après la mise à jour du premier Serveur, les autres Serveurs ne pourront pas fonctionner et se mettre à jour.

Lors de la création du cluster des Serveurs Dr.Web dans le réseau antivirus, il faut respecter les conditions suivantes :

Tous les Serveurs doivent avoir les mêmes clés de chiffrement drwcsd.pub et drwcsd.pri, ainsi que le certificat du Serveur drwcsd-certificate.pem.

Si les clés de chiffrement et le certificat n’ont pas été créés avant, ils seront générés automatiquement lors de l’installation du premier Serveur du cluster.

Vous pouvez obtenir les clés de chiffrement nécessaires et le certificat pour l’installation des Serveurs suivants du cluster via le Centre de gestion : menu Administration → Clés de chiffrement. Dans ce cas, la clé privée et le certificat peuvent être requis plus tard : lors de la spécification de la clé privée drwcsd.pri pendant l’installation du Serveur, la clé publique drwcsd.pub et le certificat drwcsd-certificate.pem sont générés automatiquement, pourtant une nouvelle version du certificat est créée lors de sa génération, c’est pourquoi le certificat doit être remplacé par la même version sur tous les Serveurs du cluster (voir Instruments assurant une connexion sécurisée).

Vous pouvez consulter le placement des fichiers de configuration dans la rubrique Serveur Dr.Web.

L’adresse IP et le nom DNS du Serveur doivent être les mémés pour tous les Serveurs. Ils sont utilisés pour générer les fichiers d’installation de l’Agent sur les postes du réseau antivirus.

Ce nom est spécifié via le Centre de gestion : Administration → Configuration du Serveur Dr.Web → onglet Réseau → onglet Téléchargement → champ Adresse du Serveur Dr.Web. Les paramètres de cette section sont sauvegardés dans le fichier de configuration download.conf (vous pouvez consulter la description du fichier dans les Annexes, p. G3. Fichier de Configuration download.conf).

Le nom commun du cluster doit être enregistré sur le Serveur DNS dans le réseau pour chaque Serveur séparément et la méthode de répartition de la charge doit être spécifiée.

Pour appliquer automatiquement les paramètres dans le cluster des Serveurs Dr.Web, il faut utiliser le protocole spécial du cluster.

Pour configurer le protocole de cluster pour chaque Serveur dans le Centre de gestion, ouvrez le menu Administration → Configuration du Serveur Dr.Web et spécifiez les paramètres suivants :

a)Pour activer le protocole du cluster, cochez la case Protocole du cluster des Serveurs Dr.Web dans l’onglet Modules.

b)Pour configurer les paramètres d’interaction des Serveurs au sein d’un cluster, spécifiez les paramètres suivants dans l’onglet Cluster.

c)Après avoir spécifié tous les paramètres nécessaires, cliquez sur le bouton Enregistrer et redémarrez les Serveurs.

Dans cet exemple, les transports pour toutes les interfaces sont configurés pour tous les Serveurs du cluster. Dans les autres cas, par exemple, quand un des réseaux est externe par rapport au cluster et les Agents se connectent via ce réseau et le deuxième réseau est interne, il vaut mieux ouvrir le protocole du cluster uniquement pour les interfaces du réseau interne. Dans ce cas, il faut spécifier les adresses du type 192.168.1.1, ..., 192.168.1.N en tant qu’interfaces.

Pour pouvoir fonctionner avec une seule base de données, tous les Serveurs Dr.Web doivent avoir la même version.

Tous les Serveurs Dr.Web au sein d’un cluster doivent fonctionner avec la seule base de données.

Comme dans le cas de l’utilisation de la base de données sans l’organisation du cluster, chaque Serveur s’adresse à la base de données indépendamment et toutes les données des Serveurs sont sauvegardées séparément. Là ou cela est valable, le Serveur prend dans la base de données seulement les entrées liées à son ID qui est unique pour chaque Serveur. L’utilisation d’une base de données unique permet aux Serveurs d’utiliser les Agents qui ont été d’abord enregistrés sur d’autres Serveurs du cluster.

Lors de la création d’un cluster des Serveurs avec la base de données unique, veuillez prendre en compte les particularités suivantes :

•La base de données peut être installée séparément de tous les Serveurs ou sur un des ordinateurs sur lequel est installé le Serveur du cluster.

•La base de données doit être créée avant l’installation du premier Serveur du cluster ou avant la connexion du premier Serveur à la base de données.

•Lors de l’ajout de nouveaux nœuds au cluster (excepté le premier Serveur) pendant l’installation des Serveurs, il n’est recommandé de spécifier la base de données unique qui est utilisée dans ce cluster. Sinon les informations qui sont déjà sauvegardées dans ce cluster peuvent être supprimées. Il est recommandé d’installer les Serveurs avec la base de données interne et, après l’installation, les connecter à la base de données externe unique.
Vous pouvez connecter les Serveurs à la base de données externe via le Centre de gestion : menu Administration → Configuration du Serveur Dr.Web → onglet Base de données ou via le fichier de configuration des Serveurs drwcsd.conf.

•Il n’est pas recommandé d’ajouter à un cluster des Serveurs qui fonctionnent déjà dans le réseau antivirus avec une autre base de données interne ou externe (excepté le premier Serveur du cluster). Cela peut provoquer la perte de données : des informations sur les postes, sur les statistiques et sur les paramètres (sauf les paramètres sauvegardés dans les fichiers de configuration), car les données dans la base sont complètement supprimées lors de l’importation. Dans ce cas, seule l’importation partielle de certains paramètres est possible.

Sur tous les Serveurs du cluster, les référentiels doivent contenir les mises à jours de la même version.

•Mettre à jour tous les Serveurs du cluster depuis le SGM en même temps. Dans ce cas, tous les Serveurs auront la dernière version des mises à jour. Vous pouvez configurer la mise à jour des référentiels de tous les Serveurs depuis la zone locale des mises à jour. Dans ce cas, une version approuvée des mises à jour sera diffusée depuis la zone locale ou, en cas de création du miroir du SGM, ce sera la dernière version des mises à jour.

•Il est possible de créer la structure hybride associant le cluster des Serveurs et la structure hiérarchique à la base des liaisons voisines. Ainsi, un des Serveurs (un Serveur du cluster ou un Serveur non inclus au cluster) est désigné comme principal et il obtient les mises à jour depuis le SGM. Les autres Serveurs du clustes sont considérés comme subordonnés et ils obtiennent les mises à jour par les liaisons voisines depuis le Serveur principal.

En cas de configuration de la mise à jour des Serveurs du cluster depuis la zone locale (le miroir du SGM) ou depuis le Serveur principal, il est nécessaire de surveiller le fonctionnement de cette zone ou du Serveur principal. Si le nœud diffusant les mises à jour tombe en panne, il est nécessaire de reconfigurer un des Serveurs et le désigner Serveur principal ou créer une nouvelle zone des mises à jour pour obtenir des mises à jour depuis le SGM.

Pour diffuser les licences sur les Serveurs du cluster vous pouvez agir d’une des façons suivantes :

a)La structure hiérarchique de Serveurs n’est pas configurée au sein du cluster. Il suffit d’ajouter une clé de licence (ou plusieurs clés) sur un des Serveurs du cluster. Les informations sur cette clé de licence seront enregistrées dans la base de données commune. Ainsi, tous les Serveurs du cluster utiliseront en même temps la clé de licence. Le nombre total des licences sauvegardées dans la base de données commune doit correspondre au nombre total des postes servis par tous les Serveurs du cluster.

Pour pouvoir utiliser la clé de licence sur tous les Serveurs du cluster, et non seulement sur celui qui contient la clé ajoutée, il faut redémarrer les autres Serveurs du cluster après avoir ajouté la clé.

b)Il est possible de créer une structure hybride associant le cluster des Serveurs et la structure hiérarchique à la base des liaisons voisines. Cette structure sera utile si, pendant la maintenance des Agents les Serveurs inclus dans cluster et les Serveurs non inclus dans le cluster sont utilisés. Dans ce cas, le nombre nécessaire des licences est distribué depuis le fichier de licence par les liaisons voisines pendant le travail :

•Depuis un Serveur non inclus dans le cluster sur un des Serveurs du cluster. Les licences distribuées seront utilisées par tous les Serveurs du cluster, comme cela est décrit dans le p. a).

•Depuis un des Serveurs du cluster (c’est-à-dire, depuis une clé utilisée par tous les Serveurs du cluster) sur le Serveur non inclus dans le cluster.

La configuration de la distribution du nombre nécessaire des licences pour un délai nécessaire se fait manuellement par l’administrateur du réseau antivirus (pour plus d’informations, voir la rubrique Distributions des licences par les liaisons entre les serveurs).

Par exemple, vous pouvez configurer la structure hiérarchique des Serveurs et déterminer le Serveur principal (cela peut être un Serveur du cluster ou un Serveur non inclus dans le cluster) qui va distribuer les mises à jour du référentiel et les licences depuis le fichier de licence.

Pour exclure la duplication des requêtes à la BD, il est recommandé d’exécuter les tâches suivantes de la planification du Serveur seulement sur un des Serveurs : Purge Old Data, Backup sensitive data, Purge old stations, Purge expired stations, Purge unsent IS events Par exemple, sur le Serveur qui est placé sur le même ordinateur que la base de données externe ou sur le plus puissant ordinateur du cluster, si les configurations des Serveurs sont différentes et la base de données est installée sur un ordinateur à part.