Verteilung und Partitionen

Sie können zwischen zwei Verteilungsstrategien für WebSphere eXtreme Scale wählen: feste Partitionsverteilung und containerbezogene Verteilung. Die Auswahl der Verteilungsstrategie hat Einfluss darauf, wie die Implementierungskonfiguration Partitionen im fernen Datengrid verteilt.

Feste Partitionsverteilung

Sie können die Verteilungsstrategie in der XML-Datei für Implementierungsrichtlinien festlegen. Die Standardverteilungsstrategie ist die feste Partitionsverteilung, die mit der Einstellung FIXED_PARTITION aktiviert wird. Die Anzahl primärer Shards, die auf die verfügbaren Container verteilt werden, entspricht der Anzahl der Partitionen, die Sie mit dem Attribut "numberOfPartitions" konfiguriert haben. Wenn Sie Replikate konfiguriert haben, wird die minimale Gesamtanzahl der verteilten Shards mit der folgenden Formel definiert: ((1 primäres Shard + Mindestanzahl synchroner Shards) * Anzahl definierter Partitionen). Die maximale Gesamtanzahl verteilter Shards wird mit der folgenden Formel definiert: ((1 primäres Shard + maximale Anzahl synchroner Shards + maximale Anzahl asynchroner Shards) * Partitionen). Ihre Implementierung von WebSphere eXtreme Scale verteilt die Shards auf die verfügbaren Container. Die Schlüssel jeder Map werden, basierend auf der definierten Gesamtanzahl der Partitionen, in den zugeordneten Partitionen verschlüsselt. Die Schlüssel werden auch dann in derselben Partition verschlüsselt, wenn die Partition aufgrund eines Failovers oder aufgrund von Serveränderungen verschoben wird.

Wenn numberPartitions beispielsweise den Wert 6 und minSync den Wert 1 für MapSet1 hat, ist die Gesamtanzahl der Shards für dieses MapSet 12, weil jede der 6 Partitionen ein synchrones Replikat erfordert. Wenn drei Container gestartet sind, verteilt WebSphere eXtreme Scale vier Shards pro Container für MapSet1.

Containerbezogene Verteilung

Die alternative Verteilungsstrategie ist die containerbezogene Verteilung, die mit der Einstellung PER_CONTAINER für das Attribut "placementStrategy" im MapSet-Element in der XML-Implementierungsdatei aktiviert wird. Bei dieser Strategie entspricht die Anzahl primärer Shards, die an jeden neuen Container verteilt wird, der Anzahl der Partitionen, P, die Sie konfiguriert haben. Die Implementierungsumgebung von WebSphere eXtreme Scale verteilt P Replikate jeder Partition für jeden verbleibenden Container. Die Einstellung von numInitialContainers wird ignoriert, wenn Sie die containerbezogene Verteilung verwenden. Die Partitionen werden größer, wenn die Container zunehmen. Die Schlüssel für Maps sind bei dieser Strategie nicht auf eine bestimmte Partition festgelegt. Der Client leitet Anforderungen an eine Partition weiter und verwendet eine wahlfreie primäre Partition. Wenn in Client die Verbindung zu derselben Sitzung wiederherstellen möchte, die er für die erneute Suche eines Schlüssels verwendet hat, müssen Sie ein Sitzungs-Handle verwenden.

Weitere Informationen finden Sie unter SessionHandle für Routing.

Wenn ein Failover stattfindet oder Server gestoppt werden, verschiebt die Umgebung von WebSphere eXtreme Scale die primären Shards in der containerbezogenen Verteilungsstrategie, wenn diese noch Daten enthalten. Wenn die Shards leer sind, werden sie verworfen. Bei der containerbezogenen Strategie werden alte primäre Shards nicht beibehalten, weil neue primäre Shards für jeden Container verteilt werden.

WebSphere eXtreme Scale lässt die containerbezogene Verteilung als Alternative zur so genannten "typischen" Verteilung zu, einer Lösung mit festgelegten Partitionen, bei der der Schlüssel einer Map verschlüsselt auf einer dieser Partitionen gespeichert wird. Im containerbezogenen Fall (den Sie mit PER_CONTAINER festlegen) verteilt die Implementierung die Partitionen auf die Gruppe der online befindlichen Container-Server und skaliert diese automatisch, wenn Container dem Datengrid des Servers hinzugefügt bzw. aus diesem entfernt werden. Ein Datengrid mit festen Partitionen eignet sich für schlüsselbasierte Grids, bei denen die Anwendung ein Schlüsselobjekt verwendet, um die Daten im Grid zu suchen. Die Alternative wird im Folgenden beschrieben.

Beispiel für ein containerbezogenes Datengrid

Datengrids mit der Verteilungsstrategie PER_CONTAINER sind anders. Sie legen die Verteilungsstrategie PER_CONTAINER für das Datengrid mit dem Attribut "placementStrategy" in der XML-Implementierungsdatei fest. Anstatt die gewünschte Gesamtpartitionsanzahl im Datengrid zu konfigurieren, geben Sie an, wie viele Partitionen Sie pro gestartetem Container wünschen.

Wenn Sie beispielsweise fünf Partitionen pro Container definieren, werden fünf neue anonyme primäre Partitions-Shards erstellt, wenn Sie diesen Container-Server starten, und die erforderlichen Replikate werden in den anderen implementierten Container-Servern erstellt.

Im Folgenden sehen Sie eine mögliche Folge in einer containerbezogenen Umgebung beim Anwachsen des Datengrids.

  1. Start von Container C0 mit 5 primären Shards (P0-P4)
    • C0 enthält P0, P1, P2, P3, P4
  2. Start von Container C1 mit 5 weiteren primären Shards (P5-P9). Die Replikat-Shards werden gleichmäßig auf die Container verteilt.
    • C0 enthält: P0, P1, P2, P3, P4, R5, R6, R7, R8, R9
    • C1 enthält: P5, P6, P7, P8, P9, R0, R1, R2, R3, R4
  3. Start von Container C2 mit 5 weiteren primären Shards (P10-P14). Die Replikat-Shards werden gleichmäßig neu verteilt.
    • C0 enthält: P0, P1, P2, P3, P4, R7, R8, R9, R10, R11, R12
    • C1 enthält: P5, P6, P7, P8, P9, R2, R3, R4, R13, R14
    • C2 enthält: P10, P11, P12, P13, P14, R5, R6, R0, R1

Das Muster wird fortgesetzt, wenn weitere Container gestartet werden. Bei jedem Start eines weiteren Containers werden fünf neue primäre Partitionen erstellt, und die Replkate werden gleichmäßig neu auf die verfügbaren Container im Datengrid verteilt.

Anmerkung: WebSphere eXtreme Scale verschiebt primäre Shards bei der Strategie PER_CONTAINER nicht, es werden nur Replikate verschoben.

Denken Sie daran, dass die Partitionsnummern beliebig sind, d. h. keinen Bezug zu Schlüsseln haben, und deshalb schlüsselbasiertes Routing nicht verwendet werden kann. Wenn ein Container gestoppt wird, werden die erstellten Partitions-IDs für diesen Container nicht mehr verwendet, und es entsteht eine Lücke in den Partitions-IDs. Wenn Container C2 in dem Beispiel ausfällt, sind die Partitionen P5-P9 nicht mehr verfügbar. Es bleiben nur die Partitionen P0-P4 und P10-P14 übrig. Somit ist ein schlüsselbasiertes Hashing nicht möglich.

Die Verwendung von Zahlen wie fünf oder 10 (was wahrscheinlicher ist) für die Anzahl der Partitionen pro Container empfiehlt sich, wenn man an die Auswirkungen eines Containerausfalls denkt. Damit die Last der Host-Shards gleichmäßig im Datengrid verteilt wird, benötigen Sie mehr als nur eine Partition pro Container. Wenn Sie nur eine einzige Partition pro Container verwenden und ein Container ausfällt, muss ein einziger Container (der mit dem entsprechenden Replikat-Shard) die volle Last des ausgefallenen primären Shards tragen. In diesem Fall verdoppelt sich sofort die Last für den Container. Wenn Sie jedoch fünf Partitionen pro Container haben, übernehmen fünf Container die Last des ausgefallenen Containers, was die Auswirkungen auf jeden Container um 80 Prozent reduziert. Die Verwendung mehrerer Partitionen pro Container verringert die potenziellen Auswirkungen auf jeden Container im Allgemeinen erheblich. Stellen Sie sich einen Fall vor, in dem die Last eines Containers unerwartet stark ansteigt. Die Replikationslast dieses Containers wird auf 5 Container und nicht nur auf einen einzigen verteilt.

Containerbezogene Richtlinie verwenden

Es gibt verschiedene Szenarien, in denen die containerbezogene Strategie eine ideale Konfiguration ist, z. B. bei der Replikation von HTTP-Sitzungen oder beim Status von Anwendungssitzungen. In einem solchen Fall ordnet ein HTTP-Router eine Sitzung einem Servlet-Container zu. Der Servlet-Container muss eine HTTP-Sitzung erstellen und wählt eines der fünf lokalen primären Partitions-Shards für die Sitzung auswählen. Die "ID" der ausgewählten Partition wird anschließend in einem Cookie gespeichert. Der Servlet-Container hat jetzt lokalen Zugriff auf den Sitzungsstatus, was einen Zugriff ohne Latenzzeit auf die Daten für diese Anforderung bedeutet, solange die Sitzungsaffinität aufrecht erhalten bleibt. eXtreme Scale repliziert alle Änderungen an der Partition.

Stellen sich die Auswirkungen eines Falls in der Praxis vor, in dem Sie mehrere Partitionen pro Container (sagen wir erneut 5) haben. Natürlich haben Sie mit jedem neuen Container, der gestartet wird, 5 weitere primäre Partitions-Shards und 5 weitere Replikat-Shards. Mit der Zeit müssen weitere Partitionen erstellt werden, und diese dürfen weder verschoben noch entfernt werden. So verhalten sich die Container aber in Wirklichkeit nicht. Wenn ein Container gestartet wird, enthält er 5 primäre Shards, die so genannten primären "Ausgangs-Shards". Wenn der Container ausfällt, werden die Replikate zu primären Shards,und eXtreme Scale erstellt 5 weitere Replikate, um die hohe Verfügbarkeit aufrecht zu erhalten (sofern Sie die automatische Reparatur nicht inaktivieren). Die neuen primären Shards befinden sich in einem anderen Container als dem, von dem sie erstellt wurden, und werden deshalb als "fremde" primäre Shards bezeichnet. Die Anwendung sollte neue Statusinformationen oder Sitzungen nie in einem fremden primären Shards speichern. Das fremde primäre Shard hat irgendwann keine Einträge mehr, und eXtreme Scale löscht dann dieses fremde Shard und die zugehörigen Replikate. Die fremden primären Shards unterstützen die weitere Verfügbarkeit vorhandener Sitzungen (aber keine neuen Sitzungen).

Ein Client kann weiterhin mit einem Datengrid interagieren, das nicht schlüsselbasiert ist. Der Client startet eine Transaktion und speichert Daten im Datengrid unabhängig von Schlüsseln. Er fordert bei der Sitzung ein SessionHandle-Objekt an, ein serialisierbares Handle, das dem Client bei Bedarf die Interaktion mit derselben Partition ermöglicht. WebSphere eXtreme Scale wählt eine Partition für den Client aus der Liste der primären Ausgangspartitions-Shards aus. Er gibt keine fremde primäre Partition zurück. Das SessionHandle kann beispielsweise in ein HTTP-Cookie serialisiert werden, das später wieder in ein Cookie konvertiert wird. Anschließend können die APIs von WebSphere eXtreme Scale eine Sitzung abrufen, die über das SessionHandle wieder an dieselbe Partition gebunden wird.

Anmerkung: Für die Interaktion mit einem PER_CONTAINER-Datengrid können keine Agenten verwendet werden.

Vorteile

Die vorherige Beschreibung weicht von einem normalen FIXED_PARTITION- oder Hash-Datengrid ab, weil der containerbezogene Client Daten an einer Stelle im Grid speichert, ein Handle für die Daten abruft und das Handle verwendet, um erneut auf die Daten zuzugreifen. Es gibt keinen von der Anwendung bereitgestellten Schlüssel wie im Fall mit festgelegten Partitionen.

Ihre Implementierung erstellt keine neue Partition für jede Sitzung. In einer containerbezogenen Implementierung müssen die Schlüssel, die zum Speichern von Daten in der Partition verwendet werden, deshalb innerhalb dieser Partition eindeutig sein. Sie lassen von Ihrem Client beispielsweise eine eindeutige Sitzungs-ID erstellen und verwenden diese als Schlüssel, um Informationen in den Maps dieser Partition zu suchen. Anschließend interagieren mehrere Clientsitzungen mit derselben Partition, so dass die Anwendung eindeutige Schlüssel verwenden muss, um Sitzungsdaten in jeder angegebenen Partition zu speichern.

In den vorherigen Beispielen wurden 5 Partitionen verwendet, aber der Parameter "numberOfPartitions" in der ObjectGrid-XML-Datei kann verwendet werden, um die gewünschte Anzahl an Partitionen anzugeben. Die Einstellung gilt nicht pro Datengrid, sondern pro Container. (Die Anzahl der Replikate wird wie bei der Richtlinie für festgelegte Partitionen angegeben.)

Die containerbezogene Richtlinie kann auch für mehrere Zonen verwendet werden. Wenn möglich, gibt eXtreme Scale ein SessionHandle für eine Partition zurück, deren primäres Shard sich in derselben Zone wie dieser Client befindet. Der Client kann die Zone als Parameter für den Container oder über eine API angeben. Die Clientzonen-ID kann mit serverproperties oder clientproperties festgelegt werden.

Die PER_CONTAINER-Strategie für ein Datengrid eignet sich für Anwendungen, die dialogbasierte Statusinformationen anstelle von datenbankorientierten Daten speichern. Der Schlüssel für den Zugriff auf die Daten ist eine Dialog-ID und bezieht sich nicht auf einen bestimmten Datenbanksatz. Diese Strategie bietet eine höhere Leistung (weil die primären Partitions-Shards beispielsweise mit den Servlets zusammengefasst werden können) und eine einfachere Konfiguration (ohne Partitionen und Container berechnen zu müssen).