Cluster von Dr.Web Servern

Server innerhalb des Clusters sollten nur mithilfe von Installationspaketen aktualisiert werden. Alle Server müssen hierbei angehalten werden und der Reihe nach aktualisiert werden. Sie sollten auf das Upgrade über das Verwaltungscenter (Umstieg auf eine neuere Revision) aus folgendem Grund verzichten: Bei der Verwendung einer gemeinsamen Datenbank können Sie nach der Aktualisierung des ersten Servers alle restlichen Server nicht mehr betreiben und aktualisieren.

Beim Erstellen eines Clusters von Dr.Web Servern müssen folgende Voraussetzungen erfüllt sein:

Alle Server müssen die gleichen Schlüssel drwcsd.pub und drwcsd.pri sowie das Server-Zertifikat drwcsd-certificate.pem haben.

Wenn die Schlüssel und das Zertifikat noch nicht erstellt sind, werden sie automatisch während der Installation des ersten Servers des Clusters generiert.

Wenn gewünscht, können Sie die erforderlichen Schlüssel und das Zertifikat für die Installation weiterer Server des Clusters über das Verwaltungscenter erstellen: Menü Administration → Verschlüsselungsschlüssel. In der Zukunft brauchen Sie ggf. sowohl den privaten Schlüssel als auch das Zertifikat: Bei der Angabe des privaten Schlüssels drwcsd.pri während der Installation des Servers werden der öffentliche Schlüssel drwcsd.pub und das Zertifikat drwcsd-certificate.pem zwar automatisch generiert, doch bei der Erstellung des Zertifikats wird seine neue Kopie generiert. Aus diesem Grund muss das Zertifikat auf allen Servern des Clusters durch die gleiche Version ersetzt werden (s. auch Tools zum Sichern von Verbindungen).

Informationen zum Speicherort der Konfigurationsdateien finden Sie im Abschnitt Dr.Web Server.

Für alle Server muss die gleiche IP-Adresse oder der gleiche DNS-Name des Servers festgelegt werden. Diese IP-Adresse oder dieser DNS-Name wird beim Generieren der Installationsdateien des Agents für Workstations des Antivirus-Netzwerks verwendet.

Der Name wird über das Verwaltungscenter festgelegt: Administration → Dr.Web Server-Konfiguration → Netzwerk → Registerkarte Download → Feld Dr.Web Server-Adresse. Die Einstellungen dieses Bereichs sind in der Konfigurationsdatei download.conf gespeichert (weitere Informationen zu dieser Datei finden Sie im Dokument Anhänge unter G3. Konfigurationsdatei download.conf).

Auf dem DNS-Server des Netzwerks muss ein gemeinsamer Clustername für jeden einzelnen Server registriert werden sowie eine Lastenausgleichsmethode festgelegt werden.

Damit die Einstellungen im Cluster von Dr.Web Servern automatisch übernommen werden, muss ein spezielles Cluster-Protokoll verwendet werden.

Um das Cluster-Protokoll einzurichten, müssen Sie im Verwaltungscenter unter Administration → Dr.Web Server-Konfiguration folgende Einstellungen für jeden Server festlegen:

a)Um das Cluster-Protokoll zu aktivieren, aktivieren Sie auf der Registerkarte Module das Kontrollkästchen Protokoll des Clusters von Dr.Web Servern.

b)Um die Einstellungen für die Kommunikation der Server innerhalb des Clusters zu konfigurieren, legen Sie auf der Registerkarte Cluster die erforderlichen Parameter fest.

c)Nachdem Sie alle notwendigen Parameter festgelegt haben, klicken Sie auf die Schaltfläche Speichern und starten Sie die Server neu.

Im obigen Beispiel sind für alle Server des Clusters die Transporteinstellungen für alle Schnittstellen konfiguriert. Es kann vorkommen, dass eines der Netzwerke nicht zum Cluster gehört und die Agents sich über dieses Netzwerk verbinden, während das andere Netzwerk zum Cluster gehört. In diesem Fall sollten Sie das Cluster-Protokoll nur an die Schnittstellen des internen Netzwerks binden. Geben Sie dafür nur interne Adressen, wie etwa 192.168.1.1, ..., 192.168.1.N, an.

Damit eine gemeinsame Datenbank verwendet werden kann, müssen alle Dr.Web Server von der gleichen Version sein.

Für alle Dr.Web Server des Clusters muss die gleiche externe Datenbank festgelegt sein.

Wie im Normalfall greift jeder Server auf die Datenbank unabhängig voneinander zu, und alle Daten der Server werden separat gespeichert. Da jeder Server über die eigene eindeutige ID verfügt, ruft der Server nur die Einträge ab, die an seine ID gebunden sind. Durch die Verwendung einer gemeinsamen Datenbank können die Server die Agents ansprechen, die ursprünglich auf anderen Servern des Clusters registriert wurden.

Bei der Erstellung eines Clusters von Servern mit einer gemeinsamen Datenbank müssen Sie Folgendes beachten:

•Die Datenbank kann sowohl isoliert von allen Servern als auch auf einem der Rechner, auf denen sich die Server des Clusters befinden, installiert werden.

•Die Datenbank kann vor der Installation des ersten Servers des Clusters oder vor der Herstellung der Verbindung des ersten Servers mit der Datenbank erstellt werden.

•Während neue Knoten dem Cluster (außer dem ersten Server) hinzugefügt werden, wird es nicht empfohlen, bei der Installation der Server eine gemeinsame Datenbank für den Cluster festzulegen. Anderenfalls können die bereits in der Datenbank gespeicherten Informationen gelöscht werden. Daher empfehlen wir Ihnen, eine eingebettete Datenbank bei der Installation der Server anzugeben und später eine gemeinsame externe Datenbank für die installierten Server festzulegen.
Um die Server an eine externe Datenbank einzubinden, wechseln Sie im Verwaltungscenter zu Administration → Dr.Web Server-Konfiguration → Datenbank. Alternativ können Sie die Konfigurationsdatei der Server drwcsd.conf entsprechend ändern.

•Sie sollten dem Cluster keine Server hinzufügen, die bereits innerhalb des Antivirus-Netzwerks mit einer anderen externen oder eingebetteten Datenbank betrieben werden (Diese Empfehlung betrifft nicht den ersten Server des Clusters). Das Nichtbeachten dieser Empfehlung führt dazu, dass Informationen über Workstations, Statistiken und Einstellungen (außer den Einstellungen in der Konfigurationsdatei) verloren gehen, da Daten in der Datenbank beim Import gelöscht werden. In diesem Fall können nur einige Einstellungen importiert werden.

Repositorys aller Server des Clusters müssen Updates der gleichen Version beinhalten.

•Alle Server des Clusters müssen gleichzeitig über das GUS aktualisiert werden. Dadurch erhalten alle Server die letzte Version der Updates. Updates für die Repositorys aller Server des Clusters können auch über eine lokale Update-Quelle bezogen werden, welche die gleiche freigegebene Version bzw. die letzte Version der Updates (im Fall der Spiegelung vom GUS) verteilt.

•Möglich ist auch eine hybride Netzwerkstruktur, die aus einem Cluster von Servern und hierarchisch miteinander verbundenen Servern besteht. Einer der Server (ein Server innerhalb oder außerhalb des Clusters) wird dabei als übergeordneter Server festgelegt, der Updates über das GUS bezieht. Andere (untergeordnete) Server des Clusters beziehen die Updates vom übergeordneten Server über die Server-zu-Server-Kommunikation.

Falls die Server des Clusters die Updates von einer lokalen Update-Quelle (von einem GUS-Spiegel) oder von dem übergeordneten Server beziehen, muss sichergestellt werden, dass die Update-Quelle bzw. der übergeordnete Server immer ordnungsgemäß funktioniert. Wenn der Update-Knoten ausfällt, müssen seine Aufgaben von einem anderen Server übernommen werden, der dann als übergeordneter Server festgelegt wird, bzw. muss ein neuer GUS-Spiegel erstellt werden.

Zur Verteilung der Lizenzen zwischen einzelnen Servern können folgende Ansätze angewendet werden:

a)Server innerhalb des Cluster werden nicht zu einem hierarchisch organisierten Verbund zusammengeschaltet. In diesem Fall reicht es aus, wenn Sie einen bzw. mehrere Lizenzschlüssel nur auf einem Server des Clusters ablegen. Informationen zum Schlüssel bzw. zu diesen Schlüsseln werden in die gemeinsame Datenbank geschrieben. Der Lizenzschlüssel kann dadurch gleichzeitig von allen Servern des Clusters verwendet werden. Die Gesamtzahl der in der Datenbank gespeicherten Lizenzen muss der Gesamtzahl der Workstations entsprechen, welche die Server des Clusters bedienen.

Damit der Lizenzschlüssel auf allen Servern des Clusters und nicht nur auf dem Server, auf dem er hinzugefügt wurde, verwendet werden kann, müssen Sie die restlichen Server des Clusters neu starten, nachdem der Lizenzschlüssel hinzugefügt wird.

b)Sie können eine hybride Struktur verwenden, die aus einem Cluster von Servern und hierarchisch miteinander verbundenen Servern besteht. Von dieser Struktur profitieren Sie, wenn die Agents von den Servern innerhalb des Clusters und außerhalb des Clusters bedient werden. In diesem Fall wird die erforderliche Anzahl der Lizenzen von einer Lizenzdatei über die Server-zu-Server-Kommunikation übertragen:

•Vom Server außerhalb des Clusters an einen der Server innerhalb des Clusters. Die verteilten Lizenzen werden von allen Servern des Clusters wie unter dem Punkt a) beschrieben verwendet.

•Von einem der Server innerhalb des Clusters (aus dem von allen Servern verwendeten Schlüssel) an den Server außerhalb des Clusters.

Die Verteilung der erforderlichen Anzahl der Lizenzen und die Dauer der Verteilung müssen manuell vom Administrator des Antivirus-Netzwerks konfiguriert werden (weitere Informationen finden Sie unter Lizenzen auf Server verteilen).

Sie können die Server hierarchisch organisieren und einen übergeordneten Server festlegen (z. B. einen Server innerhalb oder außerhalb des Clusters), der sowohl Updates des Repository als auch Lizenzen aus der Lizenzdatei verteilen soll.

Um unnötige doppelte Datenbankabfragen zu vermeiden, sollten Sie folgende Aufgaben aus dem Zeitplan des Servers nur auf einem der Server ausführen: Purge Old Data, Backup sensitive data, Purge old stations, Purge expired stations, Purge unsent IS events. Am besten passt dazu der Server, der sich auf dem Rechner befindet, auf dem die gemeinsame externe Datenbank installiert ist. Alternativ können Sie den leistungsstärksten Rechner des Clusters verwenden, wenn die Konfigurationen der Server nicht identisch sind und die Datenbank auf einem separaten Rechner installiert ist.