Dr.Web Server Cluster

When creating a Dr.Web Server cluster in the anti-virus network, follow the directions below:

Parameters	Values
<passwd-salt value=''/> Cryptographic salt value to encrypt the administrator password in the database	the same
<id value=''/> Unique Dr.Web Server identifier from license key	different

Tabs	Parameters	Values
General	Dr.Web Server name	empty or different
	Dr.Web Server language, Number of parallel requests from clients, Number of backups for the Dr.Web Server versions	irrelevant
	other	the same
Traffic	Updates and Installations	the same
Network	DNS, Proxy	irrelevant
	Transport: Encryption, Compression; settings related to the Multicasting mode	the same
	Transport: other	irrelevant
	Email, Cluster, Download	the same
	Multicast updates	recommended to leave it on one server of the cluster and turn it off on the other servers
Statistics, Security, Cache, Modules, Licenses	all	the same
Location, Log	all	irrelevant
Database	Number of connections, Restore corrupted image automatically	irrelevant
Database	other	the same

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 the encryption keys and certificate have not been created before, they will be generated automatically during installation of the first Dr.Web Server of a cluster.

You can get the encryption keys for installation of the next Dr.Web Servers of a cluster via the Control Center: Administration → Encryption keys menu. Both the private key and the certificate may be needed later on: 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 generation, a new version is created, so the certificate must be replaced with the same version on all Dr.Web Servers of a cluster (see Tools to Ensure Secure Connection).

For all Dr.Web Servers, the same DNS name of Dr.Web Server must be specified to be used for generating Dr.Web Agent installation files for the anti-virus network stations.

This name is specified via the Control Center: Administration → Dr.Web Server configuration → Network tab → Download tab → 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, F3. Download.conf Configuration File).

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

For automatic application of settings in a Dr.Web Server cluster, the cluster protocol must be used.

To configure the cluster protocol, open the Administration → Dr.Web Server configuration menu in the Control Center of each Dr.Web Server and specify the following settings:

a)To enable the 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, specify the corresponding parameters on the Cluster tab.

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

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

As in the case of database use outside of a cluster, each of Dr.Web Servers calls the database independently and all Dr.Web Server data is stored separately. Wherever relevant, a Dr.Web Server only gets database records for its ID, which is unique for each Dr.Web Server. Usage of the same database allows Dr.Web Servers to communicate with Dr.Web Agents that were initially registered on other Dr.Web Servers of a cluster.

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

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

•The database must be created before the 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 to the cluster (except the first Dr.Web Server), it is not recommended to set the common database which is used in this cluster during the Dr.Web Server installation. Otherwise, it may cause deletion of the information already stored into the database. It is recommended to install Dr.Web Servers with the embedded database at first and to switch them to the common external database after the installation.
You can switch Dr.Web Servers to the external database via the Control Center: in the Administration → Dr.Web Server configuration → on the Database tab or via the drwcsd.conf Dr.Web Server configuration file.

•Except for the first Dr.Web Server of a cluster, it is not recommended to add Dr.Web Servers already operating within an anti-virus network with another external or embedded database to a cluster. It will cause the loss of data, such as information on stations, statistics, settings (except the settings stored in the configuration files), because data is completely erased from the database during the import. In this case, only some 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, F1. 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. All Dr.Web Servers repositories can also be configured to update from a local update zone (GUS mirror) which will distribute the same confirmed version of product updates, or the latest version if the GUS mirror is created.

•You can create a hybrid structure that combines both a cluster of Dr.Web Servers and a hierarchical structure based on interserver connections. In this case one Dr.Web Server (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. The other Dr.Web Servers of the 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 or from the parent Dr.Web Server, it is necessary to monitor the functionality of this zone or the parent Dr.Web Server. If a host that distributes updates stops functioning, 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 for receiving 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 a hierarchical structure of Dr.Web Servers within the cluster. It is enough to add a license key (or several keys) on one of the Dr.Web Servers of a cluster. Information on this license key will be added to the common database. Thus, the license key will be 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 Dr.Web Servers of the cluster.

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

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

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

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

For example, you can configure a 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 propagate both repository updates and licenses from a license file.

To avoid duplicates in queries to the database, make sure to execute the following tasks from the Dr.Web Server schedule only on one of Dr.Web Servers: Purge old records, Back up critical Dr.Web Server data, Purge old stations, Purge unsent events. For example, execute them on the Dr.Web Server located on the same computer as the common external database, or on the most powerful computer of a cluster if the configurations of the Dr.Web Servers are different and the database is located on a separate computer.