PLANUNG
Um effiziente Replizierungen zu gewährleisten, sollten Sie einige Server als dedizierte Replizierungsserver konfigurieren. Das Verwenden von dedizierten Servern für Replizierungen reduziert die Arbeitslast der Datenbankserver für die Replizierung erheblich, da die Datenbankserver nur mit den Replizierungsservern replizieren müssen und nicht mit allen Servern, auf denen sich eine Kopie einer gegebenen Datenbank befindet. Um die Replizierung zu steuern, erstellen Sie Verbindungsdokumente, die angeben, mit welchen Servern wann repliziert werden soll.
Wie Sie Server für die Replizierung verbinden, hängt von vielen Faktoren ab, einschließlich des Layouts des physischen Netzwerks und der Größe Ihrer Organisation. Weiterhin entscheidend ist, in welchem Umfang Sie vorhandene Verbindungsdokumente erneut verwenden möchten, die für das Mail-Routing erstellt wurden. Es gibt mehrere unterschiedliche Konfigurationen oder Topologien, die Sie verwenden können, um zu steuern, wie die Replizierung zwischen Servern stattfindet:
Replizierungen mithilfe der Hub-and-Spoke-Topologie verwalten
Bei einer Hub-and-Spoke-Topologie handelt es sich im Allgemeinen um die effizienteste Replizierungstopologie, da insbesondere in größeren Organisationen der Netzwerkverkehr minimiert wird. Bei Hub-and-Spoke wird ein zentraler Server als Hub eingesetzt, der sämtliche Replizierungen der anderen Server (Spokes) plant und veranlasst. Die Spokes aktualisieren den Hub-Server durch Replizierung (und Mail-Routing), anschließend aktualisiert der Hub seinerseits alle Spokes. Hub-Server werden entweder miteinander repliziert oder mit übergeordneten Hub-Servern, falls die Organisationen mehr als einen Hub verwenden. Anders ausgedrückt fungiert der Hub-Server sozusagen als Datenverkehrsmanager des Systems, indem er die Systemressourcen beaufsichtigt, dafür sorgt, dass die Replizierung mit den einzelnen Spoke-Servern ordnungsgemäß abgewickelt wird und garantiert, dass die Änderungen auf alle Spoke-Server repliziert werden.
Zur Einrichtung der Replizierung in einem Hub-and-Spoke-System müssen Sie ein Verbindungsdokument für jede einzelne Hub-and-Spoke-Verbindung anlegen. Um sicherzustellen, dass die Replizierungsfunktion auf dem Hub, und nicht auf den Spokes, immer die Hauptarbeit übernimmt, geben Sie in allen Verbindungsdokumenten den Hub-Server als Quellenserver und den Spoke-Server als Zielserver und Pull-Push als Replizierungsmethode an.
Hub-and-Spoke-Topologien sind besonders bei großen Installationen mit mehreren Servern oder in einem Zentralbüro sinnvoll, das über Telefonleitungen oder Mietleitungen Verbindung zu kleineren Regionalbüros aufnehmen muss. Wenn Sie mit einer umfangreichen Installation arbeiten, können Sie auch mit einer Topologie-Kombination arbeiten, z. B. mit zwei Hub-and-Spoke-Anordnungen und einer Peer-to-Peer-Anordnung zwischen zwei Hub-Servern.
Der größte Nachteil der Hub-and-Spoke-Topologie liegt darin, dass sie nicht funktioniert, wenn der Hub ausfällt. Dieses Problem können Sie umgehen, wenn Sie einen Backup-Server bereitstellen, der den Hub repliziert und problemlos in einen Hub-Server umkonfiguriert werden kann, wenn der primäre Hub nicht mehr verfügbar ist.
Vorteile einer Hub-and-Spoke-Topologie
1. Installation mehrerer Protokolle auf Hub-Servern, um die Kommunikation in einem Domino-System mit mehreren Protokollen zu ermöglichen. Dabei werden Hub-Server in mehreren IBM Notes-Netzwerken eingesetzt, was wiederum ein gutes Beispiel für Effizienz darstellt. Hub-Server können mehrere Notes-Netzwerke verbinden, wobei ein Notes-Netzwerk oft aus einem Hub-Server mit Spoke-Servern besteht.
2. Überbrücken unterschiedlicher Netzwerkbereiche, wie beispielsweise LAN und WAN.
3. Zentralisieren der Verwaltung des Domino-Verzeichnisses, Standardisieren von Datenbank-ACLs und Beschränkung des Zugriffs auf den Hub. Sie können dem Hub Managerzugriff und den Spokes Lesezugriff zuweisen, sodass diese Änderungen an einer Replik des Hubs vorgenommen werden, mit deren Hilfe anschießend alle Spokes synchronisiert werden.
4. Zuweisen von spezifischen Aufgaben an Hubs, beispielsweise Replizierungs-Hubs und Mail-Hubs.
5. Einsetzen von Serverprogrammen wie zum Beispiel MTAs (Message Transfer Agents) auf Hubs, damit auf einfache Weise auf sie zugegriffen werden kann.
6. Verbinden von Remote-Standorten mit einem Hub-Server.
7. Minimieren des Netzwerkverkehrs und Optimierung der Netzwerkeffizienz.
8. Zentralisierung der Datensicherung auf dem Hub. Wenn Sie nur ein Backup der Datenbanken auf dem Hub erstellen, können Sie die Ressourcen auf dem Spoke-Server einsparen.
9. Verbesserung der Lastverteilung auf den Servern. Auf dem LAN-Segment des Hubs erhöht sich jedoch der Netzwerkverkehr. Wenn Sie mehr als 25 Server pro Hub haben, richten Sie verschiedene Hubs ein. Wenn ein Hub außer Betrieb ist, ist die Replizierung für diesen Hub und seine Spokes erst wieder möglich, wenn der Hub repariert oder ersetzt wurde.
Anmerkung: Verwenden Sie die Hub-and-Spoke-Replizierung nicht für Datenbanken, die größer sind als 100 MB und die Repliken auf weniger als vier Servern haben. Planen Sie die Replizierung dieser Datenbanken stattdessen so, dass sie getrennt von anderen Replizierungen stattfindet.
Replizierungen mithilfe der Peer-to-Peer-Topologie verwalten
In einer Peer-to-Peer-Topologie ist die Replizierung weniger zentralisiert als in einer Hub-and-Spoke-Konfiguration, da jeder Server mit jedem anderen Server verbunden ist. Da bei der Peer-to-Peer-Replizierung Änderungen schnell auf alle Server repliziert werden, eignet sie sich am besten für kleine Organisationen oder wenn wenige Server die Datenbanken lokal gemeinsam nutzen. Sie ist jedoch weniger effizient, wenn sich eine Datenbank auf mehreren Servern befindet.
Durch die Peer-to-Peer-Topologie werden mögliche Replizierungsprobleme reduziert, da nur zwei Server bei einer Replizierung miteinander kommunizieren und keine Hubs oder Vermittlungsserver erforderlich sind. Die Peer-to-Peer-Replizierung erfordert das Erstellen vieler Verbindungsdokumente und erhöht den Verwaltungsaufwand, da Überschneidungen bei den Replizierzeitplänen verhindert werden müssen. Ferner können Sie die ACL-Anforderungen nicht standardisieren.
Andere Topologie-Strategien
Eine weitere Methode der Verwaltung von Replizierungen ist die Clusterreplizierung. Die Clusterreplizierung stellt einen konstanten Zugriff auf Daten sicher, da die Daten eines Servers auf einem oder mehreren Mitgliedern des Clusters dupliziert werden. Wenn der primäre Server nicht mehr verfügbar ist, können die Daten von anderen Servern im Cluster abgerufen werden.
Weitere Replizierungstopologien umfassen Folgendes:
Beim Planen von Replizierungen sollten Sie in Erwägung ziehen, die Verbindungen zu verwenden, die Sie bereits für das Notes-Mail-Routing eingerichtet haben. Wenn Sie für das Mail-Routing bereits ein Verbindungsdokument erstellt haben, können Sie die Replizierungsfunktion problemlos für dieses Dokument aktivieren.
Anders als beim Mail-Routing, das in eine Richtung funktioniert und das zwei Verbindungsdokumente erfordert, um das Routing in beide Richtungen zu aktivieren, erfolgt die Replizierung zwischen Servern in beide Richtungen und erfordert nur ein Verbindungsdokument für jedes Serverpaar. Da der die Replizierung initiierende Server einen größeren Anteil an der Arbeitslast der Replizierung hat, sollten Sie, sofern Sie die Replizierung einem der bereits für das Mail-Routing zwischen zwei Servern verwendeten Verbindungsdokumente hinzufügen möchten, die Replizierungsfunktion dem Dokument auf dem leistungsfähigeren Server des Serverpaars hinzufügen.
Zugehörige Konzepte Cluster einrichten Datenbank-ACLs für Server-zu-Server-Replizierungen einrichten Zugriffsebenenberechtigungen in der ACL
Zugehörige Tasks LAN-Verbindung (Local Area Network) erstellen