Routing an bevorzugte Zonen

Mithilfe des Routings an bevorzugte Zonen können Sie definieren, wie WebSphere eXtreme Scale Transaktionen an Zonen weiterleitet.

Sie können steuern, wohin die Shards eines Datengrids verteilt werden. Weitere Informationen zu einigen Basisszenarien und zur Konfiguration der entsprechenden Implementierungsrichtlinie finden Sie unter Zonen für die Verteilung von Replikaten konfigurieren.

Das Routing an bevorzugte Zonen gibt Clients von WebSphere eXtreme Scale die Möglichkeit, Vorgaben für eine bestimmte Zonen festzulegen. Auf diese Weise werden Clienttransaktionen zunächst an bevorzugte Zonen weitergeleitet, bevor versucht wird, sie an andere Zonen weiterzuleiten.

Voraussetzungen für das Routing an bevorzugte Zonen

Stellen Sie vor der Verwendung des Routings an bevorzugte Zonen sicher, dass die Anwendung die Voraussetzungen Ihres Szenarios zu erfüllen.

Für die Verwendung des Routings an bevorzugte Zonen ist eine containerbezogene Partitionsverteilung erforderlich. Diese Verteilungsstrategie eignet sich gut für Anwendungen, die Sitzungsdaten im ObjectGrid speichern. Die Standardverteilungsstrategie für WebSphere eXtreme Scale ist fixed-partition. Bei der Festschreibung einer Transaktion wird ein Hash-basierter Algorithmus für die Schlüssel verwendet, um zu bestimmen, welche Partition das Schlüssel/Wert-Paar der Map aufnimmt, wenn die Verteilung mit festen Partitionen verwendet wird.

Bei der containerbezogenen Verteilung werden Ihre Daten über das SessionHandle-Objekt einer zufälligen Partition zugeordnet, wenn die Transaktion festgeschrieben wird. Sie müssen das SessionHandle-Objekt rekonstruieren können, um Ihre Daten aus dem Datengrid abrufen zu können.

Wenn Sie Zonen verwenden, haben Sie mehr Kontrolle darüber, wohin die primären Shards und Replikat-Shards in der Domäne verteilt werden. Die Verwendung mehrerer Zonen in der Implementierung ist vorteilhaft, wenn Ihre Daten an mehreren physischen Standorten gespeichert sind. Die geographische Trennung von primären Shards und Replikaten ist eine Methode sicherzustellen, dass der katastrophale Verlust eines Rechenzentrums keine Auswirkung auf die Verfügbarkeit der Daten hat.

Wenn die Daten auf mehrere Zonen verteilt sind, ist es wahrscheinlich, dass auch die Clients in der Topologie verteilt werden. Das Routing von Clients an ihre lokalen Zonen oder Rechenzentren hat den offensichtlichen Vorteil einer kürzeren Netzlatenzzeit. Leiten Sie Clients, sofern möglich, an lokale Zonen oder Rechenzentren weiter.

Topologie für das Routing an bevorzugte Zonen konfigurieren

Stellen Sie sich das folgende Szenario vor: Sie haben zwei Rechenzentren: Chicago und London. Zur Minimierung der Clientantwortzeiten möchten Sie, dass Clients Daten aus ihrem lokalen Rechenzentrum lesen und ihre Daten auch dorthin schreiben.

Primäre Shards müssen in jedem Rechenzentrum verteilt werden, so dass Transaktionen lokal von jeder Position aus geschrieben werden können. Clients müssen die Zonen kennen, um Anforderungen an die lokale Zone weiterzuleiten.

Bei der containerbezogenen Verteilung werden neue primäre Shards auf jeden gestarteten Container-Server gefunden. Replikate werden entsprechend den Zonen- und Verteilungsregeln in der Implementierungsrichtlinie verteilt. Standardmäßig wird ein Replikat einer anderen Zone als das primäre Shard zugeteilt. Sehen Sie sich die folgende Implementierungsrichtlinie für dieses Szenario an:

<?xml version="1.0" encoding="UTF-8"?>
<deploymentPolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://ibm.com/ws/objectgrid/deploymentPolicy ../deploymentPolicy.xsd"
xmlns="http://ibm.com/ws/objectgrid/deploymentPolicy">
	<objectgridDeployment objectgridName="universe">
		<mapSet name="mapSet1" placementStrategy="PER_CONTAINER"
			numberOfPartitions="3" maxAsyncReplicas="1">
			<map ref="planet" />
		</mapSet>
	</objectgridDeployment>
</deploymentPolicy>

Jeder Container, der mit der Implementierungsrichtlinie gestartet wird, erhält drei neue primäre Shards. Jedes primäre Shard hat ein asynchrones Replikat. Starten Sie jeden Container mit dem entsprechenden Zonennamen. Verwenden Sie den Parameter -zone, wenn Sie Ihre Container mit dem Script startOgServer starten.

Für einen Container-Server in Chicago:

  • [Unix][Linux]
    startOgServer.sh s1 -objectGridFile ../xml/universeGrid.xml 
    -deploymentPolicyFile ../xml/universeDp.xml 
    -catalogServiceEndPoints MyServer1.company.com:2809 
    -zone Chicago
  • [Windows]
    startOgServer.bat s1 -objectGridFile ../xml/universeGrid.xml 
    -deploymentPolicyFile ../xml/universeDp.xml 
    -catalogServiceEndPoints MyServer1.company.com:2809 
    -zone Chicago

Wenn Ihre Container in WebSphere Application Server ausgeführt werden, müssen Sie eine Knotengruppe erstellen und dem Namen dieser Knotengruppe das Präfix ReplicationZone voranstellen. Auf den Knoten in diesen Knotengruppen ausgeführte Knoten werden an die entsprechende Zone verteilt. Server, die auf einem Knoten in Chicago ausgeführt werden, könnten beispielsweise in einer Knotengruppe mit dem Namen ReplicationZoneChicago enthalten sein.

Weitere Informationen finden Sie unter Zonen für die Verteilung von Replikaten konfigurieren.

Primäre Shards für die Zone "Chicago" haben Replikate in der Zone "London". Primäre Shards für die Zone "London" haben Replikate in der Zone "Chicago".

Abbildung 1. Primäre Shards und Replikate in Zonen
Primäre Shards und Replikate in Zonen

Legen Sie die bevorzugten Zonen für die Clients fest. Stellen Sie Ihrer Client-JVM eine Clienteigenschaftendatei bereit. Erstellen Sie eine Datei mit dem Namen objectGridClient.properties, und stellen Sie sicher, dass diese Datei im Klassenpfad enthalten ist.

Schließen Sie die Eigenschaft preferZones in die Datei ein. Setzen Sie den Eigenschaftswert auf die entsprechende Zone. Clients in Chicago müssen den folgenden Wert in der Datei objectGridClient.properties haben:

preferZones=Chicago

Die Eigenschaftendatei für London-Clients müssen den folgenden Wert haben:

preferZones=London

Diese Eigenschaft weist jeden einzelnen Client an, Transaktionen an seine lokale Zone weiterzuleiten, sofern dies möglich ist. Die Topologie repliziert die Daten, die in ein primäres Shard in der lokalen Zone eingefügt werden, asynchron in der fremden Zone.

Schnittstelle SessionHandle für das Routing an die lokale Zone verwenden

Die containerbezogene Verteilungsstrategie verwendet keinen Hash-basierten Algorithmus, um die Position der Schlüssel/Wert-Paare im Datengrid zu bestimmen. Sie müssen SessionHandle-Objekte verwenden, um sicherzustellen, dass Transaktionen an die richtige Position weitergeleitet werden, wenn Sie diese Verteilungsstrategie verwenden. Beim Festschreiben einer Transaktion wird ein SessionHandle-Objekt an die Sitzung gebunden, sofern noch keines definiert ist. Das SessionHandle-Objekt kann auch vor dem Festschreiben der Transaktion mit der Methode Session.getSessionHandle an die Sitzung gebunden werden. Das folgende Code-Snippet zeigt, wie ein SessionHandle-Objekt vor der Festschreibung der Transaktion an das Session-Objekt gebunden wird:

Session ogSession = objectGrid.getSession();

// SessionHandle-Objekt binden
SessionHandle sessionHandle = ogSession.getSessionHandle();

ogSession.begin();
ObjectMap map = ogSession.getMap("planet");
map.insert("planet1", "mercury");

// Transaktion wird an die vom SessionHandle-Objekt angegebene Partition weitergeleitet
ogSession.commit();

Angenommen, der vorherige Code wird in einem Client im Rechenzentrum Chicago ausgeführt. Das Attribut preferZones wird für diesen Client auf Chicago gesetzt. Deshalb leitet Ihre Implementierung Transaktionen an eine der primären Partitionen in der Zone "Chicago" weiter: Partition 0, 1, 2, 6, 7 oder 8.

Das SessionHandle-Objekt stellt einen Pfad zurück zu der Partition dar, in der diese festgeschriebenen Daten gespeichert sind. Das SessionHandle-Objekt muss wiederverwendet oder wiederhergestellt und im Session-Objekt gesetzt werden, um zu der Partition mit den festgeschriebenen Daten zurückzugelangen.

ogSession.setSessionHandle(sessionHandle);
ogSession.begin();

// Zurückgegebener Wert ist "mercury "
String value = map.get("planet1");
ogSession.commit();

Die Transaktion in diesem Code verwendet das SessionHandle-Objekt, das während der Einfügetransaktion erstellt wurde, wieder. Anschließend leitet die get-Transaktion Anforderungen an die Partition weiter, die die eingefügten Daten enthält. Ohne das SessionHandle-Objekt kann die Transaktion die eingefügten Daten nicht abrufen.

Auswirkung von Container- und Zonenfehlern auf das Routing an bevorzugte Zonen

Im Allgemeinen leitet ein Client mit definierter Eigenschaft preferZones alle Transaktionen an die angegebenen Zonen weiter. Der Verlust eines Container führt jedoch zur Hochstufung eines Replikat-Shards in ein primäres Shard. Ein Client, der Anforderungen zuvor an Partitionen in der lokalen Zone weitergeleitet hat, muss zuvor eingegebene Daten aus der fernen Zone abrufen.

Stellen Sie sich das folgende Szenario vor: Ein Container in der Zone "Chicago" geht verloren. Dieser Container enthält die primären Shards für die Partitionen 0, 1 und 2. Die neuen primären Shards für diese Partitionen werden dann an die Zone "London" verteilt, weil die Zone "London" die Replikate für diese Partitionen enthält.

Jeder Chicago-Client, der ein SessionHandle-Objekt verwendet, das auf eine der übernommenen Partitionen verweist, leitet Anforderungen jetzt an die Zone "London" um. Chicago-Clients, die neue SessionHandle-Objekte verwenden, leiten Anforderungen an Chicago-basierte primäre Shards weiter.

Wenn die gesamte Zone "Chicago" verloren geht, werden alle Replikate in der Zone "London" zu primären Shards. In diesem Szenario leiten alle Chicago-Clients ihre Transaktionen an die Zone "London" weiter.