Dr.Web Servers Cluster

You must upgrade Servers within the cluster from installation packages only. At this, you must stop all the 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 Server in using the common database, all other Servers will not be able to operate and upgrade.

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

All Servers must have the same drwcsd.pub and drwcsd.pri encryption keys and the drwcsd-certificate.pem Server certificate.

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

You can get necessary encryption keys for installation of the next 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 Server installation, the drwcsd.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 the Servers of a cluster (see Tools to Ensure Secure Connection).

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

For all Servers, the same IP address or DNS name of the 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 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 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 the Servers within a cluster, on the Cluster tab specify the corresponding parameters.

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

In this example, for all 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 the Servers calls the database independently and all Servers data is stored separately. Wherever relevant, Server gets from the database only records for its ID which is unique for each Server. Usage of the same database allows the Servers operate with the Agents, firstly registered on other Servers of a cluster.

When you creating a Servers cluster with the same database, please consider the following features:

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

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

•When adding new hosts into the cluster (except the first Server), during the 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 Servers firstly with an embedded database and after the installation to switch them to the common external database.
Switch the 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 Servers configuration file.

•Except the first Server of a cluster, it is not recommended to add the 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.

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

•Update all Servers of a cluster from the GUS simultaneously. In this case, all Servers contain the latest version of updates. Update all 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 the Servers and hierarchical structure based on interserver connections. At this, on of the Servers (may be either the Server within a cluster or not included into a cluster) is assigned as a parent and receives updates from the GUS. Other Servers of a cluster are the child hosts and receive updates from the parent Server via the interserver connections.

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

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

a)Do not configure hierarchical structure of the Servers within the cluster. It is enough to add the license key (or several keys) on one of the cluster Servers. Information on this license key will be added into the common database. Thus, the license key is used by all the 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 the cluster Servers.

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

b)Create hybrid structure that combines both cluster of the Servers and hierarchical structure based on interserver connections. Such structure is useful if for serving the Agents you use the 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 the Server outside the cluster to one of the cluster Servers. Propagated licenses are used by all cluster Servers as described in the step a).

•From the one of the cluster Servers (i.e. from the key used by all cluster Servers) to the 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 Servers and allocate the parent Server (may be either the 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 Server schedule only on the one of the Servers: Purge Old Data, Backup sensitive data, Purge old stations, Purge expired stations, Purge unsent IS events. For example, on the 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 the Servers are differ and the database is located on the separate computer.