Der Container-Server speichert Anwendungsdaten für das Datengrid.
Diese Daten werden gewöhnlich in Teile, so genannte Partitionen, aufgeteilt, die
von mehreren Container-Servern gehostet werden.
Jeder Container-Server wiederum hostet einen Teil der Gesamtdaten.
Eine JVM kann einen oder mehrere Container-Server hosten, und jeder Container-Server kann mehrere Shards hosten.
Hinweis: Planen Sie die Größe des Heapspeichers für die Container-Server, die alle Daten hosten.
Konfigurieren Sie die Einstellungen für den Heapspeicher entsprechend.
Abbildung 1. Container-Server
Partitionen enthalten einen Teil der Daten des Grids.
WebSphere eXtreme Scale stellt
automatisch mehrere Partitionen in einen einzigen Container-Server und verteilt die Partitionen dann breiter, wenn weitere
Container-Server verfügbar werden.
Wichtig: Sie müssen die Anzahl der Partitionen vor der endgültigen
Implementierung sorgfältig auswählen, da sie nicht dynamisch geändert werden kann.
Ein Hash-Mechanismus wird verwendet, um Partitionen im Netz zu suchen, und
eXtreme Scale hat nach der Implementierung der Daten
keine Möglichkeit, ein erneutes Hashing für die gesamten Daten durchzuführen.
Als allgemeine Regel gilt, dass die Anzahl der Partitionen zu hoch geschätzt werden kann.
Shards sind Instanzen von Partitionen und haben eine von zwei Rollen: primäres Shard oder Replikat-Shard.
Das primäre Shard und seine Replikate bilden die physische Manifestation der Partition.
Jede Partition hat mehrere Shards, die jeweils alle in dieser Partition vorhandenen Daten enthalten.
Ein Shard ist das primäre Shard, und die anderen Shards sind Replikate oder Replikat-Shards, d. h. redundante Kopien der Daten im primären Shard.
Ein primäres Shard ist die einzige Partitionsinstanz, die Transaktionen das Schreiben in den Cache erlaubt.
Ein Replikat-Shard ist eine "gespiegelte" Instanz der Partition. Es empfängt synchron oder asynchron Aktualisierungen vom primären Shard.
Das Replikat-Shard erlaubt Transaktionen nur das Lesen von Daten aus dem Cache.
Replikate befinden sich nie in demselben Container-Server wie das primäre Shard und normalerweise nicht einmal auf derselben
Maschine wie das primäre Shard.
Um die Verfügbarkeit der Daten oder die Persistenzgarantien zu erhöhen, replizieren Sie die Daten.
Die Replikation bedeutet jedoch einen höheren Aufwand für die Transaktion und damit Leistungseinbußen zu Gunsten der Verfügbarkeit.
Mit eXtreme Scale können Sie den Aufwand steuern, da
synchrone und asynchrone Replikation sowie Hybridreplikationsmodelle unterstützt werden, die
synchrone und asynchrone Replikationsmodi verwenden. Ein synchrones Replikat-Shard empfängt Aktualisierungen
im Rahmen der Transaktion des primären Shards, um die Datenkonsistenz zu gewährleisten.
Ein synchrones Replikat kann die Antwortzeit verdoppeln, da die Transaktion
sowohl im primären Shard als auch im synchronen Replikat festgeschrieben werden muss, bevor sie beendet werden kann. Ein
asynchrones Replikat-Shard empfängt Aktualisierungen nach der Transaktionsfestschreibung, um die Auswirkungen auf die Leistung zu begrenzen,
birgt aber das Risiko eines Datenverlusts, da das asynchrone Replikat mehrere Transaktionen hinter dem primären Shard zurückliegen kann.