Dr.Web Servers Cluster

You must upgrade Dr.Web Servers within the cluster from installation packages only. At this, you must stop all Dr.Web Servers and upgrade them one after another. Upgrading via the Control Center (transition to a new revision) should not be used because after you upgrade the first Dr.Web Server in using the common database, all other Dr.Web Servers will not be able to operate and upgrade.

For creation of the Dr.Web Servers cluster in the anti-virus network, the following prescriptions must be implemented:

All Dr.Web Servers must have the same public (*.pub) and private (drwcsd.pri) encryption keys and the drwcsd-certificate.pem Dr.Web Server certificate.

If encryption keys and certificate have not been created before, during installation of the first Dr.Web Server of a cluster, they will be generated automatically.

You can get necessary encryption keys for installation of the next Dr.Web Servers of a cluster, via the Control Center: Administration → Encryption keys menu. At this both private key and certificate may be needed: if the drwcsd.pri private encryption key is specified during the Dr.Web Server installation, the *.pub public key and the drwcsd-certificate.pem certificate are generated automatically, but at the certificate generating, the new version is created and the certificate must be replaced with the same version on all Dr.Web Servers of a cluster (see Tools to Ensure Secure Connection).

Location of configuration files is given in the Dr.Web Server section.

For all Dr.Web Servers, the same IP address or DNS name of Dr.Web Server must be specified to use it for generating Agent installation files for an anti-virus network stations.

This name is specified via the Control Center: Administration → Dr.Web Server configuration → the Network tab → the Download tab → the Dr.Web Server address field. Settings of this section are stored in the download.conf configuration file (description of the file is given in the Appendices document, p. G3. Download.conf Configuration File).

At the network DNS server, the common cluster name must be registered for each Dr.Web Server and load balancing must be set.

For automatically applying of the settings in Dr.Web Servers cluster, the specific cluster protocol must be used.

To configure cluster protocol, it is necessary for each Dr.Web Server in the Control Center open the Administration → Dr.Web Server configuration menu ans specify the following settings:

a)To enable cluster protocol, on the Modules tab, set the Dr.Web Servers cluster protocol flag.

b)To configure parameters for interaction of Dr.Web Servers within a cluster, on the Cluster tab specify the corresponding parameters.

c)After configuring of the necessary parameters, click Save and restart Dr.Web Servers.

In this example, for all Dr.Web Servers of a cluster, transports for all interfaces are configured. In other cases, e.g., if one of the networks is external for the cluster and the Agents are connected from it, and the second network is intercluster, when cluster protocol is better to open only for interfaces of the internal network. In this case, the following addresses must be set as an interfaces: 192.168.1.1, ..., 192.168.1.N.

To be able to work with a common database, all Dr.Web Servers must be the same version.

All Dr.Web Servers within one cluster, must operate with the same external database.

As in the case of the database without cluster, each of Dr.Web Servers calls the database independently and all Dr.Web Servers data is stored separately. Wherever relevant, Dr.Web Server gets from the database only records for its ID which is unique for each Dr.Web Server. Usage of the same database allows Dr.Web Servers operate with the Agents, firstly registered on other Dr.Web Servers of a cluster.

When you creating a Dr.Web Server cluster with the same database, please consider the following features:

•The database may be installed either separately from all Dr.Web Servers or on the one of the computers on which Dr.Web Server of a cluster in installed.

•The database must be created before installation of the first Dr.Web Server of a cluster or before the connection of the first Dr.Web Server to the database.

•When adding new hosts into the cluster (except the first Dr.Web Server), during the Dr.Web Servers installation it is not recommended to set the common database which is used in this cluster directly. Otherwise, it may cause the deletion of the information already stored into the database. It is recommended to install the Dr.Web Servers firstly with an embedded database and after the installation to switch them to the common external database.
Switch the Dr.Web Servers to the external database usage you can via the Control Center: in the Administration → Dr.Web Server configuration → on the Database tab or via the drwcsd.conf Dr.Web Servers configuration file.

•Except the first Dr.Web Server of a cluster, it is not recommended to add the Dr.Web Servers already operating within anti-virus network with other external or embedded database to a cluster. It will cause the loss of data: information on stations, statistics, settings (except the settings which are stored in the configuration files), because data are completely erased from the base during the import. In this case, only a part of some of the settings can be imported.

•By default, after installation or upgrade of Dr.Web Servers from previous versions, a cryptographic salt value is randomly generated in the configuration file (drwcsd.conf) to encrypt the administrator password stored in the database. To prevent any authentication issues, make sure to manually set the same salt value on every Dr.Web Server included in the cluster. See the required configuration parameter in the Appendices document, Appendix G1. Dr.Web Server Configuration File.

On all Dr.Web Servers of a cluster, repositories must contain updates of the same version.

•Update all Dr.Web Servers of a cluster from the GUS simultaneously. In this case, all Dr.Web Servers contain the latest version of updates. Update all Dr.Web Servers repositories is also can be configured from the local update zone which will distribute the same confirmed version of products updates or the latest version in case if the GUS mirror is created.

•It is allowed to create hybrid structure that combines both cluster of Dr.Web Servers and hierarchical structure based on interserver connections. At this, on of Dr.Web Servers (may be either a Dr.Web Server within a cluster or not included into a cluster) is assigned as a parent and receives updates from the GUS. Other Dr.Web Servers of a cluster are the child hosts and receive updates from the parent Dr.Web Server via the interserver connections.

If Dr.Web Servers of a cluster are configured to receive updates from the local zone (GUS mirror) or from the parent Dr.Web Server, it is necessary to track functionality of this zone of the parent Dr.Web Server. If a host that distributes updates is denied of service, it is necessary to reconfigure one of the other Dr.Web Servers to operate as a parent Dr.Web Server or create a new update zone to receive updates from the GUS correspondingly.

To distribute licenses between Dr.Web Servers of a cluster, you can use the following approaches:

a)Do not configure hierarchical structure of Dr.Web Servers within the cluster. It is enough to add the license key (or several keys) on one of the cluster Dr.Web Servers. Information on this license key will be added into the common database. Thus, the license key is used by all Dr.Web Servers of the cluster simultaneously. The total number of licenses stored in the common database must correspond to the total number of stations served by all cluster Dr.Web Servers.

To use a license key on all Dr.Web Servers of a cluster, not only on the one on which the key was added, the other Dr.Web Servers of a cluster must be restarted after the key is added.

b)Create hybrid structure that combines both cluster of Dr.Web Servers and hierarchical structure based on interserver connections. Such structure is useful if for serving the Agents you use Dr.Web Servers both included into the cluster and outside the cluster. In this case, the necessary number of licenses are propagated from a license key via the interserver connection directly during operation:

•From Dr.Web Server outside the cluster to one of the cluster Dr.Web Servers. Propagated licenses are used by all cluster Dr.Web Servers as described in the step a).

•From the one of the cluster Servers (i.e. from the key used by all cluster Dr.Web Servers) to Dr.Web Server outside the cluster.

Administrator of the anti-virus network should manually configure propagation of necessary number of licenses for a necessary time period (for more details, see Licenses Propagation via Interserver Connections).

For example, you can configure hierarchical structure of Dr.Web Servers and allocate the parent Dr.Web Server (may be either a Dr.Web Server within a cluster or not included into a cluster) which will be propagate both repository updates and licenses from a license file.

To avoid duplicates in queries to the database, it is recommended to execute the following tasks from the Dr.Web Server schedule only on the one of Dr.Web Servers: Purge Old Data, Backup sensitive data, Purge old stations, Purge expired stations, Purge unsent IS events. For example, on the Dr.Web Server which is located on the same computer as the common external database. Or on the most productive computer of a cluster, if configuration of Dr.Web Servers is different, and the database is located on a separate computer.