Placement et partitions

Vous disposez de deux stratégies de placement pour WebSphere eXtreme Scale : partition fixe et par conteneur. Le choix de la stratégie de placement affecte la manière dont la configuration de votre déploiement place les partitions dans la grille de données distante.

Placement sur partition fixe

Vous pouvez définir dans le fichier XML de règles de déploiement la stratégie de positionnement. La stratégie par défaut est la stratégie de positionnement sur partition fixe, qui est activée avec le paramètre FIXED_PARTITION. Le nombre de fragments primaires qui sont placés dans les conteneurs disponibles est égal au nombre de partitions que vous avez configurées avec l'attribut numberOfPartitions. Si vous avez configuré des fragments réplique, le nombre total minimum de fragments placés est défini par la formule suivante : ((1 fragment primaire + minimum de fragments synchrones)*partitions définies). Le nombre total maximum de fragments placés est défini par la formule suivante : ((1 fragment primaire + maximum de fragments synchrones + maximum de fragments asynchrones)*partitions définies). Votre déploiement WebSphere eXtreme Scale dissémine ces fragments dans les conteneurs disponibles. Les clés de chaque mappe sont hachées en partitions attribuées en fonction du nombre total de partitions que vous avez définies. Ces clés hachent vers la même partition même si celle-ci est déplacée pour cause de basculement ou de changement de serveur.

Si, par exemple, la valeur de numberPartitions est de 6 et celle de minSync est de 1 pour MapSet1, le nombre total de fragments pour ce groupe de mappes sera de 12 car chacune des 6 partitions requiert un fragment réplique synchrone. Si trois conteneurs sont démarrés, WebSphere eXtreme Scale placera quatre fragments par conteneur pour MapSet1.

Placement par conteneur

L'autre stratégie de placement est le placement par conteneur qui est activé avec le paramètre PER_CONTAINER de l'attribut placementStrategy dans l'élément mapset du fichier XML de déploiement. Avec cette stratégie, le nombre de fragments primaires qui sont placés dans chaque nouveau conteneur est égal au nombre P de partitions que vous avez configuré. L'environnement de déploiement de WebSphere eXtreme Scale place P répliques de chaque partition pour chaque conteneur restant. Le paramètre numInitialContainers est ignoré lorsqu'on utilise le positionnement par conteneur. Les partitions grandissent en même temps que les conteneurs. Dans cette stratégie, les clés des mappes ne sont pas fixées à une partition données. C'est le client qui route vers une partition en utilisant une partition primaire aléatoire. Pour pouvoir se reconnecter à une session qu'il a déjà utilisée pour trouver une clé, le client doit utiliser un descripteur de session.

Pour plus d'informations, voir SessionHandle pour le routage.

En cas de basculement ou d'arrêt de serveur, dans la stratégie de positionnement par conteneur, l'environnement WebSphere eXtreme Scale déplace les fragments primaires si ces fragments contiennent encore des données. S'ils sont vides, ils sont éliminés. Dans la stratégie par conteneur, les anciens fragments primaires ne sont pas conservés car de nouveaux fragments primaires sont placés pour chaque conteneur.

WebSphere eXtreme Scale permet d'utiliser le placement par conteneur comme une alternative à ce qu'on peut appeler une stratégie de placement "type", une approche reposant sur le partitionnement fixe avec la clé d'une mappe hachée dans l'une de ces partitions. Dans le cas du placement par conteneur (que vous pouvez définir à l'aide de PER_CONTAINER), votre déploiement place les partitions dans l'ensemble des serveurs de conteneur en ligne et les étend ou les réduit à mesure que des conteneurs sont ajoutés ou supprimés de la grille de données des serveur. Une grille de données avec l'approche partition fixe fonctionne bien pour les grilles à base de clés, si l'application utilise un objet key pour localiser es données dans la grille. Ici, nous allons voir l'autre approche.

Exemple de grille de données par conteneur

Les grilles de données PER_CONTAINER sont différentes. Vous indiquez que la grille utilise la stratégie de placement PER_CONTAINER avec l'attribut placementStrategy dans le fichier XML de déploiement. Au lieu de définir le nombre total de partitions dans la grille de données, vous pouvez définir le nombre de partitions nécessaires pour chaque conteneur que vous démarrez.

Par exemple, si vous définissez cinq partitions par conteneur, cinq nouvelles partitions primaires anonymes sont créées lorsque vous démarrez ce serveur de conteneur, et les répliques nécessaires sont créées sur les autres serveurs de conteneur déployés.

Voici une séquence possible dans un environnement par conteneur à mesure que la taille de la grille augmente.

  1. L'on démarre le conteneur C0 qui héberge 5 partitions primaires (P0-P4).
    • C0 héberge P0, P1, P2, P3, P4.
  2. L'on démarre le conteneur C1 qui héberge 5 autres partitions primaires (P5-P9). Des fragments réplique sont répartis de manière équilibrée sur les conteneurs.
    • C0 héberge P0, P1, P2, P3, P4, R5, R6, R7, R8, R9.
    • C1 héberge P5, P6, P7, P8, P9, R0, R1, R2, R3, R4.
  3. L'on démarre le conteneur C2 qui héberge 5 autres partitions primaires (P10-P14). Là aussi, des fragments réplique sont répartis de manière équilibrée sur les conteneurs.
    • C0 héberge P0, P1, P2, P3, P4, R7, R8, R9, R10, R11, R12.
    • C1 héberge P5, P6, P7, P8, P9, R2, R3, R4, R13, R14.
    • C2 héberge P10, P11, P12, P13, P14, R5, R6, R0, R1.

Le schéma continue au fur et à mesure que d'autres conteneurs sont ajoutés en créant cinq nouvelles partitions primaires chaque fois et en rééquilibrant les fragments réplique sur les conteneurs disponibles dans la grille de données.

Remarque : WebSphere eXtreme Scale ne déplace pas les fragments primaires lors de l'utilisation de la stratégie PER_CONTAINER, mais uniquement les fragments de réplique.

Ne perdez pas de vue que, le nombre des partitions étant arbitraire et n'ayant rien à voir avec des clés, il est impossible d'utiliser un routage à base de clés. Si un conteneur s'arrête, les ID de partitions créés pour ce conteneur ne sont plus utilisés, ce qui fait qu'il y a un trou dans les ID de partitions. Dans notre exemple, en cas de défaillance du conteneur C2, il n'y aurait plus de partitions P5-P9 et il ne resterait plus que les partitions P0-P4 et P10-P14, ce qui rend impossible tout hachage à base de clés.

L'utilisation de valeurs, telles que cinq ou plus probablement 10 pour le nombre de partitions par conteneur, fonctionne mieux si vous tenez compte des conséquences de la défaillance d'un conteneur. Pour répartir la charge d'hébergement des fragments dans la grille de données, vous avez besoin de plusieurs partitions pour chaque conteneur. Si l'on n'a qu'une seule partition par conteneur, en cas de défaillance de l'un des conteneurs, c'est un seul conteneur (celui qui héberge le fragment réplique correspondant) qui devra porter toute la charge du fragment primaire perdu. Dans ce cas, la charge est immédiatement doublée pour le conteneur. Toutefois, si vous avez cinq partitions par conteneur, alors cinq conteneurs recueillent la charge du conteneur perdu en réduisant l'impact sur chacun d'entre eux de 80 %. L'utilisation de plusieurs partitions par conteneur diminue de manière substantielle l'impact potentiel sur chacun des conteneurs. Plus directement, l'on peut envisager le cas où un conteneur connaît de manière inopinée des pics d'utilisation. La charge de la réplication sur ce conteneur sera alors répartie sur 5 autres conteneurs et non uniquement sur un seul.

Utiliser la stratégie par conteneur

Plusieurs scénarios font de la stratégie par conteneur la configuration idéale, pour la réplication de sessions HTTP, par exemple, ou pour l'état de session d'application. Dans un pareil cas, un routeur HTTP affecte une session à un conteneur de servlet. Ce dernier a besoin de créer une session HTTP et il choisit l'une des 5 partitions primaires locales. L'"ID" de la partition choisie est alors stocké dans un cookie. Le conteneur de servlet peut désormais accéder en local à l'état de la session, ce qui signifie un temps d'attente nul pour l'accès aux données dans le cadre de cette demande aussi longtemps que l'on maintient l'affinité de session. Une grille eXtreme Scale réplique toutes les modifications apportées à la partition.

Dans la pratique, rappelez-vous ce que nous disions plus haut des conséquences avantageuses entraînées par le fait d'avoir plusieurs partitions (nous disions 5) par conteneur. Naturellement, chaque nouveau conteneur qui démarre ajoute 5 nouvelles partitions et 5 autres fragments réplique. Au fil du temps, d'autres partitions doivent normalement être créées et elles ne doivent ni être déplacées ni être détruites. Mais ce n'est pas ainsi que se comportent en fait les conteneurs. Lorsqu'un conteneur démarre, il héberge 5 fragments primaires, que l'on peut appeler des fragments primaires "home", et qui existent dans les conteneurs respectifs qui les ont créés. En cas de défaillance du conteneur, les fragments réplique deviennent des fragments primaires et eXtreme Scale crée 5 autres fragments réplique afin de conserver la haute disponibilité (à moins que l'on n'ait désactivé la réparation automatique). Les nouveaux fragments primaires se trouvant sur un conteneur autre que celui qui les a créés, on peut les appeler des fragments primaires "externes". L'application ne doit en aucun cas placer un nouvel état ou de nouvelles sessions dans un fragment primaire externe. Au final, le fragment primaire externe ne comporte aucune entrée et eXtreme Scale le supprime automatiquement ainsi que les fragments réplique qui lui sont associés. Les fragments primaires externes n'ont de raison d'être que de permettre aux sessions existantes d'être toujours disponibles (aux sessions existantes, mais non à de nouvelles sessions).

Un client peut toujours interagir avec une grille de données qui ne s'appuie pas sur des clés. Le client commence simplement une transaction et il stocke les données dans la grille de données indépendamment des clés. Il réclame à la session un objet SessionHandle, qui est un descripteur sérialisable lui permettant d'interagir avec la même partition lorsque c'est nécessaire. WebSphere eXtreme Scale choisit une partition pour le client dans la liste des partitions primaires home. Il ne retourne jamais de partition primaire externe. SessionHandle peut être sérialisé en cookie HTTP, par exemple, et le cookie peut ultérieurement être reconverti en SessionHandle. Ensuite, les API WebSphere eXtreme Scale peuvent obtenir une liaison Session à la même partition de nouveau, à l'aide de SessionHandle.

Remarque : Vous ne pouvez pas utiliser d'agents pour interagir avec une grille de données PER_CONTAINER.

Avantages

La description antérieure est différente d'une grille FIXED_PARTITION normale ou des données de hachage, parce que le client par conteneur stocke les données dans un endroit de la grille, obtient un descripteur pour ces données et utilise ce descripteur pour accéder à nouveau aux données. Il n'existe aucune clé fournie par application comme c'est le cas dans la partition fixe.

Le déploiement ne crée pas de nouvelle partition pour chaque session. De ce fait, dans un déploiement par conteneur, les clés qui servent à stocker les données dans la partition doivent exister en un seul exemplaire au sein de cette partition. L'on peut, par exemple, faire générer par le client un SessionID unique que l'on utilisera comme clé afin de trouver les informations dans les mappes de cette partition. De multiples sessions clients interagissent avec la même partition ; c'est pourquoi l'application a besoin d'utiliser des clés uniques pour stocker les données de session dans chacune des partitions concernées.

Les exemples donnés plus haut utilisaient 5 partitions, mais le paramètre numberOfPartitions du fichier XML objectgrid permet de spécifier autant de partitions que l'on veut. Le paramètre n'est pas par grille de données, mais par conteneur. (Le nombre de fragments réplique est spécifié de la même manière qu'avec la stratégie de partition fixe).

La stratégie par conteneur est également utilisable avec des zones multiples. Dans la mesure du possible, eXtreme Scale retourne un SessionHandle à une partition dont le fragment primaire est situé dans la même zone que le client. Celui-ci peut spécifier la zone au conteneur comme paramètre ou à 'aide d'une API. L'ID de zone du client peut être défini à l'aide de serverproperties ou de clientproperties.

La stratégie PER_CONTAINER est adaptée aux applications qui stockent un état de type transactionnel et non pas des données orientées base de données. La clé permettant d'accéder aux données sera un ID de conversation et non un enregistrement spécifique de base de données. Cette stratégie permet des performances plus élevées (car les partitions primaires peuvent cohabiter, avec des servlets, par exemple) et une configuration plus facile (pas besoin de calculer les partitions et les conteneurs).