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.

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

Vous pouvez obtenir les clés de chiffrement nécessaires pour l’installation des autres Serveurs du cluster via le Centre de gestion : menu Administration → Clés de chiffrement. En fonction du déploiement du cluster, les deux clés peuvent être requises ou une seule clé drwcsd.pri :

•Si la clé de chiffrement privé drwcsd.pri est spécifiée lors de l’installation du Serveur, la clé de chiffrement publique drwcsd.pub est générée automatiquement.

•Si vous n’avez pas spécifié la clé privé nécessaire lors l’installation du Serveur, il faut remplacer les deux clés manuellement après l’installation.

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 trouverez la description du fichier dans le document 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 Sauvegarder 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 dépôts 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 dépôts 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)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 le fonctionnement des Agents au sein d’un système de clyster des Serveurs, il y a une répartition dynamiques des postes entre les Serveurs du cluster. Dans ce cas, le nombre nécessaire des licences est diffusé par les liaisons voisines depuis le Serveur principal (cela peut être un Serveur du cluster ou un Serveur non inclus dans le cluster) sur les Serveurs subordonnés pendant le fonctionnement.

Ainsi, il suffit de placer sur le Serveur principal un fichier de licence contenant le nombre suffisant de licences correspondant au nombre total des postes servis et de diffuser le nombre nécessaire de licences sur les Serveurs subordonnés pendant le fonctionnement du cluster. C’est l’administrateur du réseau antivirus qui configure manuellement la diffusion des licences sur les Serveurs subordonnés pour un délai nécessaire.

Pour configurer la diffusion des licences sur les Serveurs voisins, utilisez le Gestionnaire de licence.

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 dépôt et les licences depuis le fichier de licences sur tous les nœuds du cluster.

b)En cas de refus de la configuration de la structure hiérarchique des Serveurs, il n’est pas possible de partager les licences entre tous les Serveurs depuis un fichier de licence unique. Dans ce cas, il faut planifier la structure du réseau antivirus à l’avance en fonction de la disponibilité du cluster des Serveurs et utiliser plusieurs fichiers de licence : un fichier pour chaque Serveur du cluster. Le nombre total des licences dans tous les fichiers de licence est égal au nombre des postes sur le réseau, pourtant il faut calculer à l’avance la répartition du nombre des licences sur les Serveurs du cluster en fonction du nombre supposé des postes que vous comptez connecter à chaque Serveur.

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.