Fournisseur de cache dynamique

L'API de cache dynamique est disponible pour les applications Java EE qui sont déployées dans WebSphere Application Server. Ce fournisseur de cache dynamique permet de mettre en cache les données métier et les fichiers HTML générés ou de synchroniser les données en cache de la cellule à l'aide du service DRS de réplication des données.

Présentation

Le seul fournisseur de services auparavant disponible était le moteur de cache dynamique par défaut intégré à WebSphere Application Server. Les clients peuvent utiliser l'interface du fournisseur de cache dynamique de WebSphere Application Server pour connecter eXtreme Scale au cache dynamique. En configurant cette fonction, vous permettez aux applications écrites avec l'API de cache dynamique ou aux applications utilisant la mise en cache au niveau des conteneurs (par exemple les servlets) d'utiliser les fonctions et les performances de WebSphere eXtreme Scale.

Vous pouvez installer et configurer le fournisseur de cache dynamique comme décrit dans Configuration du fournisseur de cache dynamique pour WebSphere eXtreme Scale.

Choix du mode d'utilisation de WebSphere eXtreme Scale

Les différentes fonctions de WebSphere eXtreme Scale permettent d'augmenter de manière significative les fonctions réparties de l'API de cache dynamique au-delà des possibilités offertes par le moteur de cache dynamique et par le service de réplication des données par défaut. Avec eXtreme Scale, vous pouvez créer des mémoires cache véritablement réparties entre plusieurs serveurs et non simplement répliquées et synchronisées d'un serveur à l'autre. Par ailleurs, les mémoires cache eXtreme Scale sont transactionnelles et hautement disponibles : chaque serveur voit ainsi le même contenu pour le service de cache dynamique. WebSphere eXtreme Scale offre une qualité de service en matière de réplication supérieure à celle proposée par DRS.

Tous ces avantages ne signifient cependant pas que le fournisseur de cache dynamique eXtreme Scale constitue la meilleure solution pour toutes les applications. Pour identifier la technologie la mieux adaptée à votre application, utilisez l'arbre de décision et la matrice de comparaison des fonctions.

Arbre de décision permettant de faire migrer des applications existantes de cache dynamique

Application existante de cache dynamique

Arbre de décision permettant de choisir un fournisseur de cache pour les nouvelles applications

Nouvelle application

Comparaison des fonctionnalités

Tableau 1. Comparaison des fonctionnalités
Fonctionnalités de cache Fournisseur par défaut Fournisseur eXtreme Scale API eXtreme Scale

Mise en cache local en mémoire

x

x

x

Mise en cache réparti

Imbriqué

Imbriqué, partitionné imbriqué et partitionné distant

Multiple

Evolutivité linéaire

 

x

x

Réplication fiable (synchrone)

 

ORB

ORB

Dépassement de capacité des disques

x

   

Expulsion

LRU/TTL/en fonction des segments

LRU/TTL (par partition)

Multiple

Invalidation

x

x

x

Relations

ID de dépendance, modèles

ID de dépendance, modèles

x

Recherches non-clés

   

Requête et index

Intégration dorsale

   

Chargeurs

Transactionnel

 

Implicite

x

Stockage à base de clés

x

x

x

Evénements et programmes d'écoute

x

x

x

Intégration à WebSphere Application Server

Une seule cellule

Plusieurs cellules

Indépendant des cellules

Prise en charge de Java Standard Edition

x

x

Surveillance et statistiques

x

x

x

Sécurité

x

x

x

Tableau 2. Intégration transparente à la technologie
Fonctionnalités de cache Fournisseur par défaut Fournisseur eXtreme Scale API eXtreme Scale

Mise en cache des résultats servlets/JSP WebSphere Application Server

V5.1+

V6.1.0.25+

 

Mise en cache des résultats (JAX-RPC) WebSphere Application Server Web Services

V5.1+

V6.1.0.25+

 

Mise en cache des sessions HTTP

   

x

Fournisseur de cache pour OpenJPA et Hibernate

   

x

Synchronisation de la base de données à l'aide d'OpenJPA et Hibernate

   

x

Tableau 3. Interfaces de programmation
Fonctionnalités de cache Fournisseur par défaut Fournisseur eXtreme Scale API eXtreme Scale

API à base de commandes

API de structure des commandes

API de structure des commandes

API DataGrid

API à base de mappes

API DistributedMap

API DistributedMap

API ObjectMap

API EntityManager

   

x

Pour plus d'informations sur le fonctionnement des mémoires caches réparties eXtreme Scale, voir les Planification de la topologie .

Remarque : Le cache eXtreme Scale réparti peut uniquement stocker des entrées dont la clé et la valeur implémentent toutes les deux l'interface java.io.Serializable.

Types de topologie

Un service de cache dynamique créé à l'aide du fournisseur eXtreme Scale peut être déployé dans l'une des trois topologies disponibles. Vous pouvez ainsi personnaliser cette mémoire en fonction de vos besoins en matière de performances, de ressources et d'administration. Ces topologies sont les suivantes : topologie imbriquée, topologie partitionnée imbriquée et topologie distante.

Topologie imbriquée

La topologie imbriquée est semblable au cache dynamique et au fournisseur de DRS par défaut. Les instances du cache réparti créées à l'aide de la topologie imbriquée conservent une copie complète de ce cache dans chaque processus eXtreme Scale qui accède au service de cache dynamique, ce qui permet à toutes les opérations de lecture de se faire localement. Toutes les opérations d'écriture passent par un processus serveur unique, au cours duquel les verrous transactionnels sont gérés. Elles sont ensuite répliquées sur les serveurs restants. Cette topologie convient par conséquent mieux aux charges de travail comptant davantage d'opérations de lecture que d'opérations d'écriture.

Avec la topologie imbriquée, les entrées nouvelles ou mises à jour ne sont pas immédiatement visibles sur tous les processus serveur unique. Une entrée de cache n'est pas visible, même pour le serveur l'ayant générée, tant qu'elle ne s'est pas propagée via les services de réplication asynchrones de WebSphere eXtreme Scale. Ces services sont aussi rapides que le matériel le permet, mais il existe toujours un léger décalage. Le graphique suivant présente une topologie imbriquée :

Topologie imbriquée

Topologie partitionnée imbriquée

Pour les charges de travail dans lesquelles les opérations d'écriture en cache sont plus fréquentes que les opérations de lecture, une topologie partitionnée imbriquée ou une topologie distante est recommandée. La première conserve toutes les données du cache dans les processus WebSphere Application Server qui accèdent à ce cache. Toutefois, chaque processus ne stocke qu'une partie de ces données. Toutes les opérations de lecture et d'écriture relatives aux données situées sur cette "partition" passent par ce processus, ce qui signifie que la plupart des demandes adressées au cache sont traitées à l'aide d'un appel de procédure distant. Il en découle un temps d'attente plus élevé pour les opérations de lecture qu'avec la topologie imbriquée, mais la capacité du cache réparti à gérer les opérations de lecture et d'écriture évolue de manière linéaire avec le nombre de processus WebSphere Application Server qui accèdent au cache. Par ailleurs, dans cette topologie, la taille maximale du cache n'est pas liée à la taille complète d'un processus WebSphere. Chaque processus en effet ne détenant qu'une partie du cache, la taille maximale de ce dernier est égale à la somme de la taille de tous les processus, moins la taille du processus lui-même. Le graphique suivant représente une topologie partitionnée imbriquée :

Topologie partitionnée imbriquée

Supposons par exemple que vous disposiez d'une grille de processus serveur dont chacun est associé à 256 mégaoctets de segments de mémoire disponibles pour héberger un service de cache dynamique. S'ils utilisaient une topologie imbriquée, le fournisseur de cache dynamique par défaut et le fournisseur eXtreme Scale seraient limités à une taille de cache interne égale à 256 mégaoctets moins la mémoire utilisée par eux-mêmes. Reportez-vous à la section relative à la planification de la capacité et à la haute disponibilité du présent manuel. S'il utilisait une topologie partitionnée imbriquée, le fournisseur eXtreme Scale serait limité à une taille de cache égale à un gigaoctet moins la mémoire utilisée par lui-même. Le fournisseur WebSphere eXtreme Scale permet ainsi de disposer d'un cache dynamique en mémoire plus grand qu'un simple processus serveur. Le fournisseur de cache dynamique par défaut utilise le cache-disque pour permettre aux instances du cache de croître au-delà de la taille d'un simple processus. Dans de nombreux cas, le fournisseur WebSphere eXtreme Scale rend superflue l'utilisation du cache-disque et des systèmes coûteux de stockage sur disque pour exécuter ces instances.

Topologie distante

La topologie distante rend également superflue l'utilisation du cache-disque. La seule différence entre la topologie distante et la topologie partitionnée imbriquée est qu'avec la première, toutes les données du cache sont stockées hors des processus WebSphere Application Server. WebSphere eXtreme Scale prend en charge les processus conteneur autonomes pour les données en cache. Ces processus utilisent moins de mémoire qu'un processus WebSphere Application Server et ils ne sont pas limités à l'utilisation d'une machine virtuelle Java donnée. Les données associées à un service de cache dynamique auquel un processus WebSphere Application Server 32 bits accède peuvent par exemple se trouver sur un processus conteneur s'exécutant sur une machine virtuelle Java eXtreme Scale. Les utilisateurs peuvent ainsi exploiter la capacité mémoire accrue des processus 64 bits pour la mise en cache, sans supporter la mémoire supplémentaire nécessaire aux processus serveur de l'application. Le graphique suivant représente une topologie distante :

Topologie distante

Compression des données

La compression est une autre fonction du fournisseur de cache dynamique WebSphere eXtreme Scale pouvant aider les utilisateurs à gérer l'excédent de mémoire généré par le cache. Le fournisseur de cache dynamique ne permet pas la compression en mémoire des données du cache. Avec le fournisseur eXtreme Scale, cette opération est possible. La compression du cache à l'aide de l'algorithme deflate peut être activée dans les trois topologies. Elle génère une charge supplémentaire pour les opérations de lecture et d'écriture, mais permet d'améliorer considérablement la densité de la mémoire cache pour les applications telles que les applications de mise en cache des servlets et de JSP.

Cache interne local

Le fournisseur de cache dynamique de WebSphere eXtreme Scale est utilisable également pour les instances de cache dynamique dans lesquelles la réplication est désactivée. Tout comme avec le fournisseur par défaut, ces caches peuvent stocker des données non sérialisables. Ils offrent également de meilleures performances sur les serveurs d'entreprise contenant multiprocesseurs car le codepath eXtreme Scale est conçu pour optimiser les accès simultanés en mémoire cache interne.

Moteur de cache dynamique et différences fonctionnelles avec eXtreme Scale

Lorsque la réplication est désactivée pour les caches locaux en mémoire, il n'existe aucune différence fonctionnelle réelle entre les caches du fournisseur de cache dynamique par défaut et WebSphere eXtreme Scale. Les utilisateurs ne constatent aucune différence, sinon que les caches WebSphere eXtreme Scale ne supportent pas le déchargement sur disque ni les statistiques ou opérations en rapport avec la taille du cache en mémoire.

Lorsque la réplication est activée, aucune différence notable ne pourra être observée dans les résultats renvoyés par la plupart des appels de l'API de cache dynamique lorsque le client utilise le fournisseur de cache dynamique ou lorsqu'il utilise le fournisseur eXtreme Scale. Pour certaines opérations, il est impossible d'émuler le comportement du moteur de cache dynamique à l'aide d'eXtreme Scale.

Statistiques du cache dynamique

Les statistiques de la mémoire cache dynamique sont générées via l'application CacheMonitor ou via le bean géré de cache dynamique. Lorsque le fournisseur de cache dynamique eXtreme Scale est utilisé, les statistiques sont générées via ces interfaces, mais le contexte des valeurs statistiques est différent.

Si une instance de cache dynamique est partagée entre trois serveurs nommés A, B et C, l'objet des statistiques renvoie des statistiques uniquement pour la copie du cache se trouvant sur le serveur à partir duquel l'appel a été lancé. Si les statistiques sont extraites à partir du serveur A, elles reflètent uniquement l'activité du serveur A.

Avec eXtreme Scale, il n'existe qu'un seul cache réparti partagé entre tous les serveurs : il est donc impossible d'effectuer un suivi de la plupart des statistiques serveur par serveur, contrairement à ce qui est le cas avec le fournisseur de cache dynamique par défaut. Vous trouverez ci-dessous une liste des statistiques générées par l'API Cache Statistics, ainsi que les explications correspondantes lorsque vous utilisez le fournisseur WebSphere eXtreme Scale de cache dynamique. Tout comme le fournisseur par défaut, ces statistiques ne sont pas synchronisées. Elles peuvent donc varier jusqu'à 10 % pour des charges de travail simultanées.

  • Réussites en cache : les réussites en cache font l'objet d'un suivi par serveur. Si le trafic enregistré sur le serveur A génère 10 réussites en cache et que le trafic enregistré sur le serveur B génère 20 réussites en cache, cette statistique fait état de 10 réussites en cache sur le serveur A et de 20 réussites en cache sur le serveur B.
  • Echecs en cache : comme les réussites, les échecs en cache font l'objet d'un suivi par serveur.
  • Entrées en cache : cette statistique renvoie le nombre d'entrées présentes dans le cache réparti. Chaque serveur qui accède au cache renvoie la même valeur, qui correspond au nombre total d'entrées en cache en mémoire pour tous les serveurs.
  • Taille du cache en Mo : cette mesure n'est actuellement prise en charge que pour les caches utilisant les topologies distantes, imbriquées ou partitionnées imbriquées. Elle indique combien de mégaoctets du segment de mémoire Java sont utilisés par le cache dans l'ensemble de la grille. Cette statistique ne porte que sur l'utilisation des segments de mémoire par les partitions primaires. C'est à vous de prendre en compte les fragments réplique. Le paramètre par défaut des topologies distantes et partitionnées imbriquées étant le fragment réplique asynchrone, il convient en effet de doubler ce chiffre pour connaître l'utilisation effective de la mémoire par le cache.
  • Suppressions dans le cache : nombre total d'entrées supprimées du cache par quelque méthode que ce soit. Agrégat des suppressions de l'ensemble du cache réparti. Si le trafic enregistré sur le serveur A génère 10 invalidations et que le trafic enregistré sur le serveur B génère 20 invalidations, la valeur correspondant à la somme des deux serveurs est 30.
  • Suppression LRU (Least Recently Used) du cache : tout comme les suppressions dans le cache, il s'agit d'un agrégat. Il représente le nombre d'entrées ayant été supprimées pour maintenir la taille du cache en deçà de sa taille maximale.
  • Invalidation pour dépassement du délai d'attente : agrégat du nombre des entrées qui ont été supprimées en raison d'un dépassement du délai d'attente.
  • Invalidations explicites : agrégat du nombre des entrées qui ont été supprimées du fait d'une invalidation directe par clé, ID dépendance ou modèle.
  • Statistiques étendues : le fournisseur de cache dynamique eXtreme Scale exporte les chaînes de clé de statistiques étendues suivantes.
    • com.ibm.websphere.xs.dynacache.remote_hits : nombre total de réussites en mémoire faisant l'objet d'un suivi dans le conteneur eXtreme Scale. Il s'agit d'une statistique agrégée. Sa valeur dans la mappe des statistiques étendues est une valeur longue.
    • com.ibm.websphere.xs.dynacache.remote_misses : nombre total d'échecs en mémoire faisant l'objet d'un suivi dans le conteneur eXtreme Scale. Il s'agit d'une statistique agrégée. Sa valeur dans la mappe des statistiques étendues est une valeur de type long.

Rapport sur la réinitialisation des statistiques

Le fournisseur de cache dynamique vous permet de réinitialiser les statistiques du cache. Avec le fournisseur par défaut, l'opération de réinitialisation efface uniquement les statistiques du serveur concerné. Le fournisseur de cache dynamique eXtreme Scale suit la plupart de ses données statistiques sur les conteneurs de cache distant. Ces données ne sont ni effacées ni modifiées lors de la réinitialisation des statistiques. Au contraire, le comportement du cache dynamique par défaut est simulé sur le client en signalant la différence entre la valeur actuelle d'une statistique donnée et sa valeur au moment du dernier appel de réinitialisation de ce serveur.

Si, par exemple, le trafic enregistré sur le serveur A génère 10 suppressions dans le cache, les statistiques concernant le serveur A et le serveur B indiquent 10 suppressions. Si les statistiques du serveur B sont réinitialisées et que 10 suppressions supplémentaires sont enregistrées sur le serveur A, les statistiques du serveur A indiqueront 20 suppressions et celles du serveur B indiqueront 10 suppressions.

Evénements du cache dynamique

L'API de cache dynamique permet aux utilisateurs d'enregistrer des programmes d'écoute d'événements. Lorsque vous utilisez eXtreme Scale en tant que fournisseur de cache, ces programmes fonctionnent comme prévu pour les mémoires cache internes.

Pour les mémoires cache réparties, le comportement des événements dépend de la topologie utilisée. Si la topologie est imbriquée, les événements sont générés sur le serveur qui gère les opérations d'écriture, également appelé fragment primaire. Ceci signifie qu'un seul serveur reçoit les notifications d'événements, mais qu'il recevra toutes les notifications normalement attendues par le fournisseur de cache dynamique. Comme WebSphere eXtreme Scale choisit le fragment primaire au moment de l'exécution, il est impossible de s'assurer qu'un processus serveur donné reçoit toujours ces événements.

Les mémoires cache partitionnées imbriquées génèrent des événements sur les serveurs hébergeant une partition du cache. Ainsi, si un cache contient 11 partitions et que chaque serveur d'une grille WebSphere Network Deployment constituée de 11 serveurs héberge l'une des partitions, chaque serveur reçoit les événements du cache dynamique relatifs aux entrées de cache qu'il héberge. Aucun processus serveur ne peut voir à lui tout seul tous les événements, à moins que les 11 partitions ne soient hébergées dans ce processus serveur. Comme dans le cas de la topologie imbriquée, il est impossible de s'assurer qu'un processus serveur donné va recevoir un ensemble donné d'événements ou aucun événement.

Les mémoires cache utilisant une topologie distante ne prennent pas en charge les événements du cache dynamique.

Appels des beans gérés

Le fournisseur de cache dynamique WebSphere eXtreme Scale ne prend pas en charge la mise en cache sur un disque. Les appels de beans gérés relatifs à une mise en cache sur un disque ne fonctionnent pas.

Mappage des règles de réplication du cache dynamique

Le fournisseur de cache dynamique pré-intégré de WebSphere Application Server prend en charge plusieurs règles de réplication du cache. Vous pouvez configurer ces règles de manière globale ou pour chaque entrée du cache. Pour obtenir une description de ces règles, consultez la documentation relative au cache dynamique.

Le fournisseur de cache dynamique eXtreme Scale n'honore pas directement ces règles. Les caractéristiques de réplication du cache sont déterminées par le type de topologie répartie eXtreme Scale configuré. Elles s'appliquent à toutes les valeurs placées dans cette mémoire, quelles que soient les règles de réplication définies par le service de cache dynamique pour l'entrée. Vous trouverez ci-dessous une liste de toutes les règles de réplication prises en charge par le service de cache dynamique et une description des topologies eXtreme Scale offrant des caractéristiques de réplication semblables.

Remarquez que le fournisseur de cache dynamique eXtreme Scale ignore les règles de réplication DRS sur un cache ou sur une entrée de cache. Les utilisateurs doivent choisir la topologie la mieux adaptée à leurs besoins en réplication.

  • NOT_SHARED – aucune des topologies actuellement proposées par le fournisseur de cache dynamique eXtreme Scale ne se rapproche de ces règles. Cela signifie que toutes les données stockées en cache doivent être associées à des clés et à des valeurs qui implémentent java.io.Serializable.
  • SHARED_PUSH : la topologie imbriquée se rapproche de ces règles de réplication. Lorsqu'une entrée de cache est créée, elle est répliquée vers l'ensemble des serveurs. Ceux-ci recherchent les entrées de cache localement uniquement. Si une entrée n'est trouvée localement, elle est supposée ne pas exister et les autres serveurs ne sont pas interrogés à son sujet.
  • SHARED_PULL et SHARED_PUSH_PULL : les topologies partitionnées imbriquées et les topologies distantes se rapprochent de ces règles de réplication. L'état réparti du cache est parfaitement cohérent sur tous les serveurs.

Ces informations sont destinées à vous aider à vérifier que la topologie choisie correspond à vos besoins en matière de cohérence répartie. Si, par exemple, la topologie imbriquée correspond parfaitement à vos besoins en matière de déploiement et de performances, mais que vous souhaitiez bénéficier du niveau de cohérence du cache apporté par SHARED_PUSH_PULL, vous pouvez envisager d'utiliser la topologie partitionnée imbriquée en dépit de ses performances légèrement inférieures.

Sécurité

Vous pouvez sécuriser les instances de cache dynamique qui s'exécutent dans des topologies imbriquées ou dans des topologies partitionnées imbriquées grâce à la fonction de sécurité intégrée à WebSphere Application Server. Consultez la documentation relative à la Sécurisation des applications dans leur environnement dans le centre de documentation de WebSphere Application Server.

Lorsqu'un cache s'exécute dans une topologie distante, un client eXtreme Scale autonome peut se connecter au cache et affecter le contenu de l'instance de cache dynamique. Le fournisseur de cache dynamique eXtreme Scale est doté d'une fonction légère de chiffrement pouvant empêcher la lecture ou la modification des données du cache par des clients autres que les clients WebSphere Application Server. Pour l'activer, associez le paramètre facultatif com.ibm.websphere.xs.dynacache.encryption_password à la même valeur pour chaque instance WebSphere Application Server qui accède au fournisseur de cache dynamique. La valeur et les métadonnées utilisateur de l'entrée de cache sont ainsi chiffrés à l'aide de la fonction de chiffrement AES 128 bits. Il est très important de définir la même valeur sur tous les serveurs, car ils ne parviendront pas à lire les données mises en cache par d'autres serveurs avec une valeur différente.

Si le fournisseur eXtreme Scale détecte différentes valeurs pour cette variable dans le même cache, il génère un avertissement dans le journal du processus conteneur eXtreme Scale.

Reportez-vous à la documentation eXtreme Scale sur Sécurité si SSL ou l'authentification SSL ou du client est nécessaire.

Informations supplémentaires