Routage par zone préférée

Avec le routage par zone préférée, vous pouvez définir la manière dont WebSphere eXtreme Scale envoie des transactions vers des zones.

Vous contrôlez l'insertion des fragments dans une grille de données. Voir Configuration de zones pour le positionnement de fragments réplique pour plus d'informations sur quelques scénarios de base et la configuration de votre stratégie de déploiement correspondante.

Le routage par zone préférée permet aux clients WebSphere eXtreme Scale de spécifier une préférence pour une zone particulière ou un ensemble de zones. En conséquence, les transactions client sont acheminées vers les zones préférées avant de tenter de les acheminer vers une autre zone.

Exigences concernant le routage par zone préférée

Avant d'utiliser le routage par zone préférée, vérifiez que l'application répond aux exigences de votre scénario.

Le placement de partition par conteneur est nécessaire pour pouvoir utiliser le routage par zone préférée. Cette stratégie de positionnement est adaptée aux applications stockant des données de session dans ObjectGrid. La stratégie de placement de partition par défaut de WebSphere eXtreme Scale est la partition fixe. Les clés sont hachées au moment de la validation de la partition, afin de déterminer quelle partition héberge la paire clé-valeur de la mappe par le biais du positionnement par partition fixe.

Le placement par conteneur affecte les données à une partition aléatoire lorsque la transaction est validée via l'objet SessionHandle. Vous devez pouvoir reconstruire l'objet SessionHandle pour récupérer vos données à partir de la grille de données.

Vous pouvez utiliser des zones pour contrôler plus précisément l'insertion des fragments primaires et de réplique dans votre domaine. L'utilisation de plusieurs zones dans le déploiement offre des avantages lorsque les données se trouvent dans plusieurs emplacements physiques. La séparation géographique des fragments primaires et des fragments de réplique est une façon de s'assurer que la perte irrémédiable d'un centre de données n'affecte pas la disponibilité des données.

Lorsque les données sont réparties dans plusieurs zones, il est probable que les clients soient également répartis dans la topologie. Le routage des clients vers leur zone locale ou leur centre de données local offre à l'évidence un avantage en terme de performance en réduisant la latence réseau. Routez les clients vers des zones locales ou des centres de données locaux lorsque cela est possible.

Configuration de votre topologie pour le routage par zone préférée

Réfléchissez au scénario suivant. Vous disposez de deux centres de données : Chicago et Londres. Pour réduire le temps de réponse des clients, vous souhaitez que les clients lisent et écrivent les données dans leur centre de données local.

Les fragments primaires doivent être placés dans chaque centre de données de sorte que les transactions puissent être écrites localement à partir de chaque emplacement. Les clients doivent avoir connaissance des zones pour pouvoir accéder à la zone locale.

Le placement par conteneur localise les nouveaux fragments primaires dans chaque conteneur qui est démarré. Des répliques sont placées en fonction des règles de zone et de placement définies par la stratégie de déploiement. Par défaut, une réplique est placée dans une zone différente de celle de son fragment primaire. Examinez la règle de déploiement suivante pour ce scénario.

<?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>

Chaque conteneur qui démarre avec la stratégie de déploiement reçoit trois nouveaux fragments. Chaque fragment primaire a un fragment de réplique asynchrone. Démarrez chaque conteneur avec le nom de zone approprié. Utilisez le paramètre -zone si vous démarrez le conteneur avec le script startOgServer.

Pour un serveur de conteneur à 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

Si vos conteneurs s'exécutent sur WebSphere Application Server, vous devez créer un groupe de noeuds et le nommer avec le préfixe ReplicationZone. Les serveurs qui s'exécutent sur les noeuds de ces groupes de noeuds sont placés dans la zone appropriée. Par exemple, les serveurs s'exécutant sur un noeud de Chicago peuvent appartenir au un groupe de noeuds nommé ReplicationZoneChicago.

Pour plus d'informations, voir Configuration de zones pour le positionnement de fragments réplique.

Les fragments primaires de la zone Chicago ont des répliques dans la zone London. Les fragments primaires de la zone London ont des répliques dans la zone Chicago.

Figure 1. Segments principaux et répliques dans les zones
Segments principaux et répliques dans les zones

Définissez les zones préférées pour les clients. Fournissez un fichier de propriétés client à votre machine virtuelle Java (JVM) client. Créez le fichier objectGridClient.properties et veillez à le placer dans le chemin d'accès aux classes.

Incluez la propriété preferZones dans le fichier. Définissez la valeur de propriété sur la zone appropriée. Les clients dans Chicago doivent avoir la valeur suivante dans le fichier objectGridClient.properties :

preferZones=Chicago

Le fichier de propriétés de clients de la zone London doit contenir la valeur suivante :

preferZones=London

Cette propriété donne l'instruction à chaque client d'acheminer les transactions vers la zone locale dans la mesure du possible. La topologie réplique de manière asynchrone les données insérées dans un fragment primaire dans la zone locale dans la zone externe.

Utilisation de l'interface SessionHandle pour le routage vers la zone locale

La stratégie de placement par conteneur n'utilise pas un algorithme basé sur le hachage pour déterminer l'emplacement de vos paires clé-valeur dans la grille de données. Vous devez utiliser des objet SessionHandle pour que les transactions soient acheminées vers l'emplacement correct lorsque vous utilisez cette stratégie de placement. Lorsqu'une transaction est validée, un objet SessionHandle est lié à la session si aucun objet n'a été défini. L'objet SessionHandle peut également être lié à la session en appelant la méthode Session.getSessionHandle avant de valider la transaction. Le fragment de code suivant montre un objet SessionHandle lié avant de valider la transaction.

Session ogSession = objectGrid.getSession();

// liaison du SessionHandle
SessionHandle sessionHandle = ogSession.getSessionHandle();

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

// tran est acheminé vers la répartition spécifiée par SessionHandle
ogSession.commit();

Supposez que le code précédent a été exécuté sur un client dans le centre de données de Chicago. L'attribut preferZones a la valeur Chicago pour ce client. Par conséquent, le déploiement routera les transactions vers l'une des partitions principales dans la zone, la partition 0, 1, 2, 6, 7 ou 8.

L'objet SessionHandle fournit un chemin de retour vers la partition qui stocke ces données validées. L'objet SessionHandle doit être réutilisé ou reconstruit et défini dans la session pour revenir à la partition contenant les données validées.

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

// la valeur renvoyée sera "mercury"
String value = map.get("planet1");
ogSession.commit();

Le code de cette transaction réutilise l'objet SessionHandle qui a été créé au cours de la transaction d'insertion. La transaction get est routée vers la partition contenant les données insérées. Sans l'objet SessionHandle, la transaction ne peut pas extraire les données insérées.

Conséquences des échecs de conteneur et de zone sur le routage basé sur zones

En règle générale, un client avec la propriété preferZones définie route toutes les transactions vers la zone ou les zones spécifiées. Cependant, la perte d'un conteneur entraîne la promotion d'un fragment de réplique comme fragment primaire. Un client qui routait ses transactions vers les partitions de la zone locale doit extraire les données précédemment insérées à partir de la zone distante.

Imaginez le scénario suivant. Un conteneur de la zone de Chicago est perdu. Il contenait précédemment des fragments primaires pour les partitions 0, 1 et 2. Les nouveaux fragments primaires de ces partitions sont ensuite placés dans la zone London, car cette zone contenait les répliques de ces partitions.

Un client de Chicago qui utilise un objet SessionHandle qui pointe vers l'une des partitions basculées reroute maintenant leurs transactions vers London. Les clients de Chicago qui utilisent les nouveaux objets SessionHandle routent leurs transactions vers les fragments primaires de Chicago.

De même, si l'ensemble de la zone Chicago est perdue, toutes les fragments de réplique de la zone London sont promues comme fragments primaires. Dans ce scénario, tous les clients de Chicago routent leurs transactions vers London.