Cluster von Dr.Web Servern

Server eines Clusters müssen nur mithilfe von Installationspaketen aktualisiert werden. Alle Server müssen angehalten werden und der Reihe nach aktualisiert werden. Sie sollten auf die Aktualisierung über das Verwaltungscenter (Umstieg auf eine neuere Revision) verzichten, da bei der Verwendung einer gemeinsamen Datenbank können nach der Aktualisierung des ersten Servers alle restlichen Server nicht mehr betrieben und aktualisiert werden.

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

Wenn noch keine Schlüssel erstellt wurden, werden diese automatisch während der Installation des ersten Servers des Clusters generiert.

Schlüssel, die für die Installation weiterer Server des Clusters notwendig sind, können über das Verwaltungscenter exportiert werden: Wechseln Sie dafür zu Administration → Schlüssel. Je nachdem, wie der Cluster bereitgestellt wird, brauchen Sie entweder beide Schlüssel oder nur den Schlüssel drwcsd.pri:

•Wenn Sie den privaten Schlüssel drwcsd.pri während der Installation des Servers angeben, wird automatisch der öffentliche Schlüssel drwcsd.pub generiert.

•Wenn Sie während der Installation des Servers den erforderlichen privaten Schlüssel nicht angeben, müssen Sie nach der Installation beide Schlüssel manuell ersetzen.

Der Speicherort der Konfigurationsdateien ist im Abschnitt Dr.Web Server angegeben.

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

Dieser Name wird in den Einstellungen des Verwaltungscenters unter Administration → Dr.Web Server-Konfiguration → Registerkarte Netzwerk → Registerkarte Herunterladen → Feld Adresse des Dr.Web Servers. 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 für jeden einzelnen Server ein gemeinsamer Clustername 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 für jeden Server folgende Einstellungen 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 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 wird empfohlen, das Cluster-Protokoll nur an die Schnittstellen des internen Netzwerks zu 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 werden.

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 dem sich der 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.

•Solange 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 abä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 aktuellste 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 aktuellste Version der Updates (im Fall eines GUS-Spiegels) 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 erhalten soll. 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)Sie können eine hybride Struktur verwenden, die aus einem Cluster von Servern und hierarchisch miteinander verbundenen Servern besteht. Diese Struktur macht Sinn, falls bei der Wartung der Agents innerhalb des Clusters der Server Workstations dynamisch zwischen den Servern des Clusters verteilt werden. In diesem Fall wird die erforderliche Anzahl der Lizenzen vom übergeordneten Server (einem Server innerhalb oder außerhalb des Clusters) auf die untergeordneten Server mithilfe der Server-zu-Server-Kommunikation übertragen.

Daher brauchen Sie auf dem übergeordneten Server nur eine Lizenzdatei mit genügender Anzahl der Lizenzen (muss der Anzahl der Workstations entsprechen) zu platzieren und dann die erforderliche Anzahl der Lizenzen auf die untergeordneten Server zu verteilen. Der Administrator des Antivirus-Netzwerks muss lediglich manuell die erforderliche Anzahl der zu verteilenden Lizenzen und die Dauer festlegen, für die sie an die untergeordneten Server ausgeliehen werden sollen.

Um die Verteilung der Lizenzen an Nachbar-Server zu konfigurieren, verwenden Sie den Lizenz-Manager.

Sie können beispielsweise 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 an alle Knoten des Clusters verteilen soll.

b)Wenn Sie die Server nicht hierarchisch organisieren, können Sie keine Lizenzen aus der Lizenzdatei an die Server verteilen. In diesem Fall müssen Sie beim Planen des Antivirus-Netzwerks eventuellen Cluster der Server berücksichtigen und mehrere Lizenzdateien verwenden – eine Lizenzdatei pro Server des Clusters. Die Gesamtzahl der Lizenzen in allen Lizenzdateien entspricht der gesamten Anzahl der Workstations im Netzwerk. Sie müssen aber vorab berechnen, wie viele Lizenzen voraussichtlich jeder Server des Clusters brauchen wird. Diese Zahl entspricht in der Regel der Anzahl der Workstations, die mit dem jeweiligen Server verbunden werden.

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.