Sie haben verschiedene Optionen bei der Auswahl der Topologie für Ihre Umgebung mit mehreren Verbünden.
Eine Replikationsdatengridinfrastruktur ist ein verbundener Graph von Verbünde mit bidirektionalen Verbindungen zwischen den Domänen. Über eine Verbindung können zwei Verbünde Datenänderungen austauschen. Die einfachste Topologie ist beispielsweise ein Paar aus Verbünde mit einer einzigen Verbindung zwischen ihnen. Die Verbünde 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 die Daten in einer Verbund trotzdem geändert werden. Die Topologie gleicht die Änderungen ab, sobald die Verbindung die Verbünde wieder verbindet. Von den Verbindungen wird nach der Unterbrechung der Netzverbindung automatisch versucht, wieder eine Verbindung herzustellen.
Nach dem Definieren der Verbindungen wird vom Produkt zuerst versucht, jede Verbund zu synchronisieren. Anschließend versucht eXtreme Scale, die identischen Zustände aufrecht zu erhalten, wenn Änderungen in einer Verbund vorgenommen werden. Das Ziel ist, dass jede Verbund ein exakter Spiegel jeder anderen Verbund ist, mit der sie verbunden ist. Die Replikationsverbindungen zwischen den Verbünde stellen sicher, dass alle Änderungen, die in einer Verbund vorgenommen werden, in die anderen Verbünde 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 Verbund direkt mit jeder anderen Verbund verbunden ist, damit sie Änderungen empfängt. Verbund B extrahiert Änderungen aus Verbund A. Verbund C empfängt die Änderungen von Verbund A über Verbund B, die mit Verbünde A und C verbunden ist. Analog empfängt Verbund D Änderungen von anderen Verbünde über Verbund C. Diese Funktion entlastet die Quelle der Änderungen durch die Verteilung der Last.
Ringtopologien sind ein Beispiel für eine Topologie mit erhöhter Ausfallsicherheit. Wenn eine Verbund oder eine einzelne Verbindung ausfällt, können die verbleibenden Verbünde trotzdem Änderungen abrufen. Die Verbünde bewegen sich ringförmig vom Ausfall weg. Jede Verbund hat maximal zwei Verbindungen zu anderen Verbünde, unabhängig davon, wie groß eine Ringtopologie ist. Die Latenzzeit für die Weitergabe der Änderungen kann hoch sein. Die Änderungen einer bestimmten Verbund müssen möglicherweise über mehrere Verbindungen übertragen werden, bevor sie in allen Verbünde vorhanden sind. Eine Reihentopologie weist dasselbe Merkmal auf.
Sie können auch eine fortgeschrittenere Ringtopologie mit einer Verbund in der Mitte des Rings implementieren. Die als Stammelement verwendete Verbund dient als zentraler Abgleichspunkt. Die anderen Verbünde dienen als ferne Abgleichspunkte für Änderungen, die in der Verbund vorgenommen werden, die als Stammelement verwendet wird. Die als Stammelement verwendete Verbund kann Änderungen zwischen den Verbünde arbitrieren. Wenn eine Ringtopologie mehrere Ringe um eine als Stammelement verwendete Verbund herum enthält, kann die Verbund Änderungen nur im inneren Ring arbitrieren. Die Ergebnisse der Arbitrierung werden jedoch über die Verbünde in den anderen Ringen verteilt.
Mit einer Hub- und Peripherietopologie werden Änderungen über eine als Hub verwendete Verbund übertragen. Weil der Hub die einzige angegebene zwischengeschaltete Verbund ist, haben Hub- und Peripherietopologien geringere Latenzzeiten. Die als Hub verwendete Verbund wird über eine Verbindung mit jeder Verbund in der Peripherie verbunden. Der Hub verteilt Änderungen an die Verbünde. 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 DataPower XC10 Appliance 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 Verbünde in der Peripherie werden verteilt, nachdem die Hub-Verbindung wieder hergestellt 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 Einzelcontainer-Daten-Grid mit einem Katalog in der Client-JVM. Ein Client verwendet sein Daten-Grid, 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 Verbund für die Arbitrierung 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 als Hub verwendeten Verbund 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 Verbund 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 für Topologien nützlich, die über viele Verbünde verfügen. In diesen Topologien ist es nicht empfehlenswert, einen zentralen Hub zu verwenden, der mit jeder möglichen Peripheriekomponente verknüpft ist. Dieser Topologietyp kann auch hilfreich sein, wenn Sie untergeordnete Verbünde hinzufügen müssen, ohne die als Stammelement verwendete Verbund zu aktualisieren.
Eine Strukturbaumtopologie kann trotzdem über einen zentralen Abgleichspunkt in der als Stammelement verwendeten Verbund verfügen. Die zweite Ebene kann weiterhin als ferner Abgleichspunkt für Änderungen dienen, die in der darunter liegenden Verbund vorgenommen werden. Die als Stammelement verwendete Verbund kann Änderungen zwischen den Verbünde 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 Verbund stellt n ausgehende Verbindungen her.
Diese Topologievariante umfasst ein Serverpaar, das als Hub ausgeführt wird. Jeder Client erstellt ein eigenständiges Einzelcontainer-Daten-Grid mit einem Katalog in der Client-JVM. Ein Client verwendet sein Daten-Grid, 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 Verbund für die Arbitrierung und verteilt Änderungen an alle verbundenen Clients. Die Topologie mit vollständig replizierten Clients ist ein guter L2-Cache für einen objektbezogenen 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 als Hub verwendeten Verbund 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 Verbund.