Sie haben verschiedene Optionen bei der Auswahl der Topologie für Ihre Umgebung mit Multimasterreplikation.
Eine Replikationsdatengridinfrastruktur ist ein verbundener Graph von Katalogservicedomänen mit bidirektionalen Verbindungen zwischen den Domänen. Über eine Verbindung können zwei Katalogservicedomänen Datenänderungen austauschen. Die einfachste Topologie ist beispielsweise ein Paar von Katalogservicedomänen mit einer einzigen Verbindung zwischen ihnen. Die Katalogservicedomänen werden alphabetisch von links nach rechts benannt: A, B, C usw. Eine Verbindung kann ein Weitverkehrsnetz (WAN) durchqueren und große Distanzen überwinden. Selbst wenn die Verbindung unterbrochen wird, können Daten in jeder Katalogservicedomäne trotzdem geändert werden. Die Topologie gleicht die Änderungen ab, sobald die Verbindung die Katalogservicedomänen wieder verbindet. Verbindungen versuchen nach der Unterbrechung der Netzverbindung automatisch, die Verbindung wiederherzustellen.
Nachdem Sie die Verbindungen konfiguriert haben, versucht das Produkt zuerst, alle Katalogservicedomäne zu synchronisieren. Anschließend versucht eXtreme Scale, die identischen Zustände aufrecht zu erhalten, wenn Änderungen in einer Katalogservicedomäne vorgenommen werden. Das Ziel ist, dass jede Katalogservicedomäne ein exakter Spiegel jeder anderen Katalogservicedomäne ist, mit der sie verbunden ist. Durch die Replikationsverbindungen zwischen den Katalogservicedomänen wird sichergestellt, dass alle Änderungen, die in einer Katalogservicedomäne vorgenommen werden, in die anderen Katalogservicedomänen kopiert werden.
Obwohl es sich um eine sehr einfache Implementierung handelt, veranschaulicht die Reihentopologie einige Qualitäten der Verbindungen. Zunächst ist es nicht erforderlich, dass eine Katalogservicedomäne direkt mit jeder anderen Katalogservicedomäne verbunden ist, damit sie Änderungen empfängt. Die Katalogservicedomäne B extrahiert Änderungen aus Katalogservicedomäne A. Die Katalogservicedomäne C empfängt Änderungen von Katalogservicedomäne A über Katalogservicedomäne B, die Katalogservicedomänen A und C miteinander verbindet. Katalogservicedomäne D empfängt Änderungen von den anderen Katalogservicedomänen über Katalogservicedomäne C. Diese Funktionalität verlagert die Last der Verteilung von Änderungen von der Änderungsquelle.
Ringtopologien sind ein Beispiel für eine Topologie mit erhöhter Ausfallsicherheit. Wenn eine Katalogservicedomäne oder eine einzelne Verbindung ausfällt, können die verbleibenden Katalogservicedomänen trotzdem Änderungen abrufen. Die Katalogservicedomänen bewegen sich ringförmig vom Ausfall weg. Jede Katalogservicedomäne hat maximal zwei Verbindungen zu anderen Katalogservicedomänen, unabhängig davon, wie große die Ringtopologie ist. Die Latenzzeit für die Weitergabe der Änderungen kann hoch sein. Die Änderungen einer bestimmten Katalogservicedomäne müssen möglicherweise über mehrere Verbindungen übertragen werden, bevor sie in allen Katalogservicedomänen vorhanden sind. Eine Reihentopologie weist dasselbe Merkmal auf.
Sie können auch eine fortgeschrittenere Ringtopologie mit einer Stammkatalogservicedomäne in der Mitte des Rings implementieren. Die Stammkatalogservicedomäne dient als zentraler Abgleichspunkt. Die anderen Katalogservicedomänen dienen als ferne Abgleichspunkte für Änderungen, die in der Stammkatalogservicedomäne vorgenommen werden. Die Stammkatalogservicedomäne kann Änderungen zwischen den Katalogservicedomänen arbitrieren. Wenn eine Ringtopologie mehrere Ringe um eine Stammkatalogservicedomäne herum enthält, kann die Katalogservicedomäne Änderungen nur im inneren Ring arbitrieren. Die Ergebnisse der Arbitrierung werden jedoch über die Katalogservicedomänen in den anderen Ringen verteilt.
Mit einer Hub- und Peripherietopologie werden Änderungen über eine Hubkatalogservicedomäne übertragen. Weil der Hub die einzige angegebene zwischengeschaltete Katalogservicedomäne ist, haben Hub- und Peripherietopologien geringere Latenzzeiten. Die Hubkatalogservicedomäne wird über eine Verbindung mit jeder Peripheriekatalogservicedomäne verbunden. Der Hub verteilt Änderungen an die Katalogservicedomänen. Der Hub dient als Abgleichspunkt für Kollisionen. In einer Umgebung mit einer hohen Aktualisierungsrate, muss der Hub im Hinblick auf die Synchronizität möglicherweise auf mehr Hardware als die Peripherie ausgeführt werden. WebSphere eXtreme Scale ist für eine lineare Skalierung konzipiert, d. h., Sie können den Hub bei Bedarf ohne Schwierigkeit vergrößern. Wenn der Hub jedoch ausfällt, werden die Änderungen erst nach einem Neustart des Hubs wieder verteilt. Alle Änderungen in den Peripheriekatalogservicedomänen werden verteilt, nachdem die Hubverbindung wiederhergestellt ist.
Sie können auch eine Strategie mit vollständig replizierten Clients verwenden, eine Topologievariante, in der ein Serverpaar als Hub verwendet wird. Jeder Client erstellt ein eigenständiges Einzelcontainerdatengrid mit einem Katalog in der Client-JVM. Ein Client verwendet sein Datengrid, um die Verbindung zum Hubkatalog herzustellen. Die Verbindung bewirkt, dass sich der Client mit dem Hub synchronisiert, sobald die Verbindung zum Hub hergestellt ist.
Alle vom Client vorgenommenen Änderungen sind lokal und werden asynchron im Hub repliziert. Der Hub dient als Arbitrierungskatalogservicedomäne und verteilt Änderungen an alle verbundenen Clients. Die Topologie mit vollständig replizierten Clients ist ein zuverlässiger L2-Cache für einen objektrelationalen Mapper wie OpenJPA. Änderungen werden über den Hub schnell an die Client-JVMs verteilt. Solange die Cachegröße im verfügbaren Heapspeicher untergebracht werden kann, ist die Topologie eine geeignete Architektur für diesen L2-Stil.
Verwenden Sie bei Bedarf mehrere Partitionen für die Skalierung der Hubkatalogservicedomäne in mehreren JVMs. Weil alle Daten immer noch in eine einzige Client-JVM passen müssen, kann die Kapazität des Hubs für die Verteilung und Arbitrierung von Änderungen durch mehrere Partitionen erhöht werden. Die Verwendung mehrerer Partitionen ändert die Kapazität einer einzelnen Katalogservicedomäne jedoch nicht.
Sie können auch eine azyklische gerichtete Baumstruktur verwenden. Eine azyklische Baumstruktur hat keine Zyklen oder Schleifen, und ein gerichtetes Setup beschränkt Verbindungen auf vorhandene Verbindungen zwischen übergeordneten und untergeordneten Komponenten. Diese Konfiguration ist hilfreich für Topologien mit vielen Katalogservicedomänen. In diesen Topologien ist es nicht empfehlenswert, einen zentralen Hub zu verwenden, der mit jedem möglichen Peripheriegerät verbunden ist. Dieser Typ von Topologie kann auch hilfreich sein, wenn Sie untergeordnete Katalogservicedomänen hinzufügen müssen, ohne die Stammkatalogservicedomäne zu aktualisieren.
Eine Baumstrukturtopologie kann einen zentralen Abgleichspunkt in der Stammkatalogservicedomäne haben. Die zweite Ebene kann weiterhin als ferner Abgleichspunkt für Änderungen dienen, die in der darunter liegenden Katalogservicedomäne vorgenommen werden. Die Stammkatalogservicedomäne kann Änderungen zwischen den Katalogservicedomänen nur auf der zweiten Ebene arbitrieren. Sie können auch k-näre Baumstrukturen verwenden, die jeweils N untergeordnete Komponenten auf jeder Ebene haben können. Jede Katalogservicedomäne stellt n ausgehende Verbindungen her.
Diese Topologievariante beinhaltet ein Serverpaar, das als Hub ausgeführt wird. Jeder Client erstellt ein eigenständiges Einzelcontainer-Datengrid mit einem Katalog in der Client-JVM. Ein Client verwendet sein Datengrid, um die Verbindung zum Hub-Katalog herzustellen, was bewirkt, dass sich der Client mit dem Hub synchronisiert, sobald die Verbindung zum Hub hergestellt ist.
Alle vom Client vorgenommenen Änderungen sind lokal und werden asynchron im Hub repliziert. Der Hub dient als Arbitrierungskatalogservicedomäne und verteilt Änderungen an alle verbundenen Clients. Die Topologie mit vollständig replizierten Clients ist ein guter L2-Cache für einen objektrelationalen Mapper wie OpenJPA. Änderungen werden über den Hub schnell an die Client-JVMs verteilt. Solange die Cachegröße vom verfügbaren Heapspeicher der Clients untergebracht werden kann, ist diese Topologie eine geeignete Architektur für diesen L2-Stil.
Verwenden Sie bei Bedarf mehrere Partitionen für die Skalierung der Hubkatalogservicedomäne in mehreren JVMs. Da alle Daten weiterhin in eine einzige Client-JVM passen müssen, erhöht die Verwendung mehrerer Partitionen die Kapazität des Hubs für die Verteilung und Arbitrierung von Änderungen, aber nicht die Kapazität einer einzelnen Katalogservicedomäne.