Wenn man mehrere Server in einer Domino-Infrastruktur betreibt, muss man sich auch Gedanken über die Servertopologie, also die Platzierung und die vorgegebenen Kommunikationsverbindungen zwischen den verschiedenen Servern machen.
Beim Aufbau einer solchen Topologie spielen die Verbindungsdokumente, die im Domino Directory abgelegt werden, eine zentrale Rolle. Sie legen fest, zwischen welchen Servern welche Verbindungen aufgebaut werden sollen. Diese Verbindungsdokumente sind darüber hinaus auch die Basis für das Mail-Routing. Dort gibt es aber insofern einen wichtigen Unterschied, als dass beim Mail-Routing unidirektional gearbeitet wird. Für eine bidirektionale Kommunikation sind daher zwei Verbindungsdokumente erforderlich, während für die „normale“ Replikation mit jeweils nur einem solchen Verbindungsdokument gearbeitet werden muss.
Die Planung einer Replikationstopologie ist vor allem deshalb von Bedeutung, weil sich damit die Last auf Servern deutlich reduzieren lässt. Die Replikation hat einen nicht unerheblichen Anteil an der Last, die auf Servern entsteht. Wenn man diese durch Vermeidung unnötiger Replikationsvorgänge reduzierten kann, lässt sich auch die Last auf den Servern reduzieren.
Replikationstopologien
Es gibt verschiedene gängige und häufig diskutierte Ansätze für die Gestaltung von Replikationstopologien. Der bekannteste ist die Hub-and-Spoke-Struktur. Bei dieser wird mit wenigen zentralen Servern gearbeitet, den Hubs. Die Spokes sind mit jeweils einem Hub gekoppelt. Zwischen den Hubs erfolgt eine direkte Kommunikation, während die Spokes jeweils nur auf dem Umweg über einen oder mehrere Hubs miteinander kommunizieren.
Dieses Modell stammt aus einer Zeit, als externe Verbindungen noch teuer waren und man häufig mit Wählleitungen gearbeitet hat. In Zeiten günstiger Internetverbindungen und hoher Bandbreiten besteht dieses Problem so nicht mehr.
Auf der anderen Seite ist das Konzept deshalb interessant, weil man eine klare Struktur für die Kommunikation zwischen Servern hat. Die Nachteile sind die zwangsläufig hohe Replikationslast auf den Hub-Servern und die Abhängigkeit vom Funktionieren dieser Server. Auf der anderen Seite kann man dort beispielsweise zentrale Instanzen von Datenbanken halten und nur an dieser Stelle sichern.
Peer-to-Peer- und Ring-Topologie als Alternativen
Der Gegenentwurf zu diesem Modell ist die Peer-to-Peer-Topologie, bei der alle Server miteinander verbunden sind. Das ist vor allem in kleinen Infrastrukturen sinnvoll, um eine schnelle Replikation sicherzustellen.
Ein weiterer Ansatz ist eine Ring-Topologie, bei der beispielsweise Server A mit Server B, Server B mit Server C, Server C mit Server D und dieser wiederum mit Server A kommuniziert. Bei „benachbarten“ Servern im Ring ist dieser Ansatz effizient, bei vielen Servern wird er dagegen aufwendig. Hier ist die Analogie zum Active Directory interessant. Dort wird standardmäßig mit einem Ring gearbeitet. Ab sieben Servern werden aber zusätzlich Abkürzungen definiert, um beispielsweise von Server C direkt zu Server A replizieren zu können.
Weitere Ansätze sind Binärbäume und End-to-End- oder Ketten-Topologien. Auch hier gilt, dass diese Konzepte deutliche Schwächen aufweisen.
Die beiden sinnvollsten Ansätze
Wenn man sich die verschiedenen Ansätze betrachtet, dann bleiben eigentlich nur zwei Konzepte übrig:
-
Die Hub-and-Spoke-Struktur für Infrastrukturen, bei denen eine Replikation über schmalbandige oder teure Verbindungen mit anderen Standorten erfolgen muss und bei denen die Optimierung der Netzlast noch heute eine wichtige Rolle spielt.
-
Die Peer-to-Peer-Replikation in allen anderen Szenarien.
Bei Letzterer ist aber wichtig, dass man sich über die Platzierung von Datenbanken auf Servern Gedanken macht, um die Replikationslast auf diese Weise zu verringern. In den meisten Fällen kann man durch eine sinnvolle Platzierung einer kleinen Zahl von Repliken auf wenigen Servern die Replikationslast wesentlich besser begrenzen als durch noch so ausgefeilte Replikationstopologien. Denn weniger Repliken bedeuten effektiv auch weniger Replikationslast, weil die Änderungen von und zu weniger Servern transportiert werden müssen.
Sonderfälle lassen sich durch die Erstellung zusätzlicher Verbindungsdokumente abdecken, die die Replikation nur von ausgewählten Datenbanken steuern.
Die Replikation
Die Standardform der Replikation zwischen Servern ist die bidirektionale Replikation. Dabei wird zu einem definierten Zeitpunkt ein Server von einem anderen angesprochen. In der Regel wird mit einer Pull-Push-Replikation gearbeitet. Der „anrufende“ Server holt zunächst die Änderungen vom anderen Server ab und sendet anschließend seine Änderungen an diesen.
Bevor die Replikation startet, überprüfen beide Server die Identität des jeweils anderen Systems, indem sie Schlüssel austauschen und ein gemeinsames Zertifikat auf Echtheit prüfen.
Anschließend werden die Listen von Datenbanken analysiert, um die gemeinsam vorhandenen Datenbanken anhand einer identischen Replika-ID zu erkennen. Außerdem wird die Uhrzeit der letzten Replikation ermittelt. Nur wenn Änderungen vorliegen, erfolgt auch eine Replikation.
Für die zu replizierenden Datenbanken werden die geänderten Elemente ermittelt. Dazu gehören sowohl Dokumente als auch Gestaltungselemente und Änderungen an den ACLs. Diese werden anschließend übertragen und in der jeweils anderen Datenbank gespeichert. Falls Konflikte erkannt werden, werden diese protokolliert. Auf die Erkennung und Behandlung von Replikationskonflikten wird an dieser Stelle nicht näher eingegangen.
Nachdem die Replikation durchgeführt wurde, werden entsprechende Informationen im Replikationsprotokoll erfasst. Damit erfolgt der nächste Abgleich nur noch ab dem Zeitpunkt, bis zu dem die Änderungen im Rahmen der aktuellen Replikation übertragen wurden.
Gesteuerte Replikation
Das Standardverfahren für die Replikation zwischen zwei Servern ist die gesteuerte Replikation. Dafür muss ein Verbindungsdokument zwischen zwei Servern erstellt werden, in dem festgelegt wird, wann und wie eine Replikation erfolgen soll. Dieses Dokument wird im Domino Directory abgelegt. Um die Last im Netzwerk nicht zu hoch werden zu lassen, sollten keine unnötigen Verbindungsdokumente erstellt werden. So sind beispielsweise keine Dokumente für die Kommunikation zwischen Domino-Servern erforderlich, wenn diese keine gemeinsam genutzten Datenbanken besitzen.
Die Verbindungsdokumente können im Bereich Configuration innerhalb des Menüs Replication – Connections angepasst werden. Dort erstellen Sie auch neue Verbindungsdokumente oder modifizieren bestehende Dokumente.
Im Register Basics wird zunächst der Verbindungstyp festgelegt. In den meisten Fällen ist das heute ein Local Area Network. Als Port kommt normalerweise TCP/IP zum Einsatz. Wichtig ist, dass die Namensauflösung bei TCP/IP so konfiguriert sein muss, dass der jeweils andere Server auch gefunden wird. Es bietet sich an, zur Sicherheit den DNS-Namen oder die IP-Adresse des Zielsystems bei Optional network address einzugeben.
Weitere Angaben sind die Festlegungen der Quell- und Zieldomäne und der jeweiligen Server. Erwähnenswert ist außerdem die Usage priority. Diese wird nur benötigt, wenn man eine Backup-Verbindung hat, die beim Ausfall der normalen Verbindung verwendet werden soll. Die normale Verbindung erhält in diesem Fall die Priorität Normal, die andere Verbindung dagegen Low.
Replikationseinstellungen
Das Register Replication/Routing enthält die Details für den Abgleich. Dazu kann zunächst der Replikations-Task aktiviert werden. Anschließend lässt sich steuern, welche Priorität Datenbanken haben müssen, damit sie repliziert werden. Außerdem kann der Replikationstyp angepasst werden. Bei allen drei Einstellungen reichen in der Regel die Standardeinstellungen.
Interessant sind die beiden Optionen Files/Directory paths to replicate und Files/Directory paths to NOT replicate. Damit können gezielt einzelne Datenbanken in die Replikation einbezogen oder von ihr ausgeschlossen werden. Falls man also Sonderfälle der Replikation beachten muss, um die gewählte Replikationstopologie effizienter zu strukturieren, kann man spezielle Verbindungsdokumente definieren, in denen mit diesen Parametern gesteuert wird, dass sie nur für ausgewählte Datenbanken gelten.
Außerdem lässt sich noch ein Zeitlimit für die Replikation konfigurieren. Das kann in komplexeren Infrastrukturen erforderlich sein, um die Netzlast für andere Tasks freizuhalten. Im Register Schedule kann schließlich der Zeitplan festgelegt werden, nach dem die Replikation erfolgt. Hier gilt es, den Kompromiss zwischen Aktualität und Netzlast zu finden. Grundsätzlich geht die Tendenz heute zu kürzeren Replikationsintervallen.
Sofortiger Austausch mit der ad-hoc-Replikation
Erwähnenswert im Zusammenhang mit der Replikation ist noch die ad-hoc-Replikation, die wichtige Änderungen außerhalb des definierten Zeitplans zwischen Servern austauscht. Ein typisches Beispiel dafür sind Änderungen im Domino Directory, die schnell zu anderen Servern übertragen werden sollen. Aber auch die Replikation nach größeren Modifikationen oder Korrekturen an anderen Datenbanken können eine solche sofortige Replikation erforderlich machen.
Für die ad hoc-Replikation werden drei Serverbefehle genutzt:
-
Replicate repliziert Änderungen bidirektional zwischen den Datenbanken und verwendet dabei das bereits erwähnte Pull-Push-Schema.
-
Pull fordert nur die Änderungen von einem anderen Server an.
-
Push sendet dagegen Änderungen zu einem anderen Server.
Die Befehle werden an der Konsole des Domino-Administrators angegeben. Als Parameter sind jeweils der Servername des Replikationspartners sowie optional der Name einer Datenbank erforderlich. (mja)