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:

If encryption keys have not been created before, during installation of the first Server of a cluster, encryption keys 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, depending on the following cluster establishing way, either both keys or only drwcsd.pri may be needed:

•If the drwcsd.pri private encryption key is specified during the Server installation, the drwcsd.pub public key is generated automatically.

•If the necessary private key is not specified during the Server installation, when you must replace both of the keys manually after the installation.

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)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 within Servers cluster system, the dynamic allocation of stations between Servers of a cluster is performed. In this case, the necessary number of licenses are propagated from a parent Server (may be either the Server within a cluster or not included into a cluster) to child Servers via the interserver connection directly during operation.

Thus, on a parent Server can be located only one license file containing the number of licenses that corresponds the total number of served stations, and the necessary number of licenses to child Servers is propagated during operation of a cluster. Administrator of anti-virus network should manually configure donation of necessary number of licenses to child Servers for a necessary time period.

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 all nodes of a cluster.

b)In case of refusal to configure hierarchical structure of the Servers, opportunity to donate licenses from a single license file between all the Servers is not supported. In this case, you must plan the structure of anti-virus network considering cluster of the Servers beforehand, and use several license files—one for each Serves of a cluster. Total number of licenses in all license files is equal to the total number of stations in the network, but distribution the number of licenses between Servers of a cluster you must calculate beforehand considering the assumed number of stations that are planned to be connected to each Server.

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.