Intégration de HCL Commerce version 9 avec WebSphere eXtreme Scale

Intégrez WebSphere eXtreme Scale pour améliorer les performances à volume élevé.

Présentation

Avant de décider d'intégrer HCL Commerce à WebSphere eXtreme Scale, passez en revue les avantages de l'intégration, les conditions préalables et les étapes de configuration nécessaires. Vous pouvez intégrer IBM WebSphere eXtreme Scale à IBM HCL Commerce version 9.0.0.7 et les versions ultérieures pour améliorer les performances de votre implémentation à volume élevé. Le programme sous licence WebSphere eXtreme Scale est une grille de données élastique, évolutive et en mémoire que vous pouvez utiliser comme cache avancé pour WebSphere Commerce. WebSphere eXtreme Scale traite un volume de transactions massif avec une grande efficacité et une évolutivité linéaire. L'intégration de WebSphere eXtreme Scale peut offrir des avantages de performance significatifs aux clients HCL commerce à volume élevé.

WebSphere eXtreme Scale a été utilisé dans HCL Commerce version 7.x et 8.x comme fournisseur de cache externe.

Prérequis

Pour intégrer WebSphere eXtreme Scale à HCL Commerce, les versions suivantes sont requises :
  • Le serveur WebSphere eXtreme Scale nécessite la version 8.6.1.2 ou une version ultérieure. À partir de cette version, les clients WebSphere eXtreme Scale qui s'exécutent à la fois dans la version standard WebSphere Application Server et dans WebSphere Application Server Liberty peuvent accéder simultanément au même serveur WebSphere eXtreme Scale.
  • HCL Commerce nécessite la version 9.0.0.7 ou une version ultérieure. À partir de cette version, le client WebSphere eXtreme Scale est inclus dans le Docker de serveur d'applications (pour le serveur de trasactions, de magasin et de recherche HCL Commerce).
En outre, vous devez sélectionner une instance de cache pour WebSphere eXtreme Scale. Le cache interne de WebSphere Commerce est développé à l'aide de l'API WebSphere Application Server DynaCache, et ce cache est organisé par des instances de cache. WebSphere eXtreme Scale fournit une prise en charge transparente de l'API DynaCache, de sorte qu'elle peut être utilisée comme fournisseur de cache pour n'importe quelle instance de cache HCL Commerce.
Important : Ne placez pas toutes vos instances de cache dans WebSphere eXtreme Scale. Si vous placez des instances de cache inappropriées dans WebSphere eXtreme Scale, cela peut entraîner une perte de fonctionnalité ou de graves problèmes de performances. Les instances de cache sont appropriées pour être mises dans WebSphere eXtreme Scale dans les circonstances suivantes :
  • Le taux d'échec dans le cache est beaucoup plus élevé que le taux d'accès au cache, ce qui signifie que l'amélioration du taux d'accès au cache peut améliorer considérablement les performances.
  • L'objet de cache est de grande taille, ou le nombre total d'entrées de cache est très important (par exemple, des millions d'entrées de cache). Dans ces circonstances, le stockage de l'instance de cache dans la machine virtuelle Java locale du serveur d'applications nécessite une très grande taille de segment de mémoire.
  • Lorsque les événements d'invalidation du cache ne se produisent pas fréquemment, ce qui signifie qu'il n'y a pas un grand nombre d'appels d'invalidation délivrés à WebSphere eXtreme Scale.
Les critères utilisés pour déterminer si une instance de cache convient à une utilisation dans WebSphere eXtreme Scale sont déterminés par votre modèle de charge de travail réel. Par conséquent, vous devez effectuer des tests de performances pour déterminer si une instance de cache convient à WebSphere eXtreme Scale. Certaines instances de cache (par exemple, services/cache/SearchCatHierarchyDistributedMapCache sur le serveur de recherche) utilisent une source de données qui n'est pas stockée de manière centralisée (c'est-à-dire pas une base de données). Ce type d'instance de cache ne doit pas être placé dans WebSphere eXtreme Scale pour éviter un problème d'invalidation du cache.
Avant de commencer
Bien que le client WebSphere eXtreme Scale soit inclus dans des conteneurs Docker d'application, la connexion WebSphere eXtreme Scale n'est pas activée par défaut. Pour activer l'intégration WebSphere eXtreme Scale, vous devez effectuer les étapes de configuration de ce tutoriel.
En outre, il existe des commandes Run Engine dans HCL Commerce qui peuvent simplifier la procédure de configuration si vous construisez un conteneur Docker personnalisé.
Important : Ces commandes peuvent être exécutées lors de tests ou de création d'une image Docker personnalisée, mais ces commandes ne doivent pas être exécutées dans un conteneur de production.

Procédure

1. Configuration du serveur de transactions

La procédure de configuration du serveur de transactions est différente de celle utilisée pour configurer le serveur de recherche et de magasin, car l'environnement du serveur est le serveur d'applications WebSphere traditionnel plutôt que Liberty.

  1. Exécutez la commande Run Engine create-xs-domain pour créer un domaine WebSphere eXtreme Scale. Le nom d'hôte et le port du catalogue WebSphere eXtreme Scale sont nécessaires pour exécuter la commande Run Engine create-xs-domain. Par exemple :
    run create-xs-domain test.cn.ibm.com 2809

    Dans cet exemple, test.cn.ibm.com est le nom hôte du serveur de catalogue WebSphere eXtreme Scale, et 2809 est le port d'écoute.

    Cette étape crée le fichier de configuration catalogservice.xml dans le référentiel de configuration du serveur d'applications WebSphere.

    Remarque : Exécutez l'étape 1 une seule fois.
  2. Connectez l'instance de cache spécifique à WebSphere eXtreme Scale. Vous avez besoin du nom d'instance du cache Java Naming and Directory Interface et de la nouvelle taille du cache pour exécuter la commande Run Engine connect-basecache-wxs.
    • Pour le BaseCache, appelez connect-basecache-wxs. Par exemple :
      run connect-basecache-wxs 5000
      Dans cet exemple, 5000 est la nouvelle taille de cache pour baseCache. Le fichier de configuration baseCache est server.xml, et le fichier de configuration pour d'autres instances de cache est resources-pme502.xml.
      Remarque : La commande de baseCache est différente pour d'autres instances de cache, car le fichier de configuration mis à jour est différent.
    • Pour d'autres instances de cache, appelez connect-objectcache-wxs. Par exemple : 
      run connect-objectcache-wxs services/cache/WCLayoutDistributedMapCache 1000
      Dans cet exemple, services/cache/WCLayoutDistributedMapCache est le nom de l'instance de cache cible Java Naming Directory Interface et 1000 est la nouvelle taille de cache.

      Vous devez spécifier la nouvelle taille du cache lorsque vous connectez une instance de cache spécifique à WebSphere eXtreme Scale, car le calcul total du nombre d'entrées du cache est différent lors de l'utilisation du fournisseur de cache par défaut (local) que lors de l'utilisation du fournisseur de cache WebSphere eXtreme Scale. Lorsque le fournisseur de cache par défaut est utilisé, le nombre total d'entrées du cache est déterminé uniquement par le paramètre CacheSize de l'instance de cache.

      Lorsque le fournisseur de cache WebSphere eXtreme Scale est utilisé, le nombre total d'entrées du cache est égal à CacheSize*Partition-number/Replica-number. Dans ce scénario, Patition-number et Replica-number sont déterminés par la configuration parallèle du serveur WebSphere eXtreme Scale.

      Par conséquent, lorsque vous placez une instance de cache dans WebSphere eXtreme Scale, le paramètre CacheSize doit être ajusté en fonction de la configuration parallèle du serveur WebSphere eXtreme Scale.
      Important : Ignorer la spécification de taille du cache peut provoquer un comportement inattendu, tel qu'une erreur de dépassement de mémoire sur le serveur WebSphere eXtreme Scale.

      En outre, dans cette procédure, l'étape 2 ne place qu'une seule instance de cache dans WebSphere eXtreme Scale. Si vous devez placer plusieurs instances de cache dans WebSphere eXtreme Scale, exécutez l'étape 2 une fois pour chaque instance de cache nécessaire.

    Il s'agit d'un exemple de fichier Docker pour personnaliser l'image Docker du serveur de transactions en utilisant les commandes Run Engine pour activer l'intégration de WebSphere eXtreme Scale :
    FROM repname/library/ts-app:tsapp

RUN run create-xs-domain test.cn.ibm.com 2809 && \

run connect-basecache-wxs 2000 && \

run connect-objectcache-wxs services/cache/DM_UserCache 10000 && \

run connect-objectcache-wxs services/cache/WCPriceDistributedMapCache 5000 && \

...

2. Configuration des serveurs de recherche et de magasin

La procédure de configuration des serveurs de recherche et de magasin est différente de celle utilisée pour configurer le serveur de transactions, car l'environnement du serveur est Liberty, et non le serveur d'applications WebSphere traditionnel.

  1. Activez la fonction de cache élastique. Le nom d'hôte et le port de catalogue de WebSphere eXtreme Scale sont nécessaires pour exécuter la commande Run Engine enable-xs-feature. Par exemple : 
    run enable-xs-feature test.cn.ibm.com 2809
    Dans cet exemple, test.cn.ibm.com est le nom hôte du serveur de catalogue WebSphere eXtreme Scale, et 2809 est le port d'écoute.

    Cette étape crée un fichier de configuration (elasticCache.xml) dans le dossier Liberty configDropins. Le contenu du fichier comprend l'activation de la fonctionnalité elasticCacheClient-1.0 et la définition d'une valeur par défaut elasticCacheClient (avec le nom d'hôte et le port de WebSphere eXtreme Scale spécifiés).

  2. Connectez l'instance de cache spécifique à WebSphere eXtreme Scale. Le nom d'instance du cache Java Naming Directory Interface et la nouvelle taille du cache sont nécessaires pour exécuter les commandes connect-searchcache-wxs et connect-crscache-wxs.
    • Pour le serveur de recherche, appelez connect-searchcache-wxs. Par exemple :
      run connect-searchcache-wxs services/cache/SearchFacetDistributedMapCache 2000
      Dans cet exemple, services/cache/SearchFacetDistributedMapCache est le nom de l'instance de cache cible Java Naming Directory Interface et 2000 est la nouvelle taille de cache.
      Remarque : La commande du serveur de recherche est différente de la commande du serveur de magasin, car le modèle de configuration du fichier de configuration est différent.
    • Pour le serveur de magasin, appelez connect-crscache-wxs. Par exemple : 
      run connect-crscache-wxs services/cache/WCLayoutDistributedMapCache 2000
      Dans cet exemple, services/cache/WCLayoutDistributedMapCache est le nom de l'instance de cache cible Java Naming Directory Interface et 2000 est la nouvelle taille de cache.
      Remarque : Contrairement au serveur de transactions, il n'y a pas de différenciation entre baseCache et d'autres instances de cache. Par conséquent, vous utilisez la même commande Run Engine pour le serveur de recherche et le serveur de magasin, et le nom Java Naming Directory Interface de baseCache est baseCache.
    Il s'agit d'un exemple de fichier Docker pour personnaliser l'image Docker du serveur de recherche en utilisant les commandes Run Engine pour activer l'intégration de WebSphere eXtreme Scale :
    FROM repname/library/search-app:searchapp

RUN run enable-xs-feature test.cn.ibm.com 2809 && \

run connect-searchcache-wxs services/cache/SearchFacetDistributedMapCache 2000 && \

...
    Il s'agit d'un exemple de fichier Docker pour personnaliser l'image Docker du serveur de magasin en utilisant les commandes Run Engine pour activer l'intégration de WebSphere eXtreme Scale :
    FROM repname/library/crs-app:crsapp

RUN run enable-xs-feature test.cn.ibm.com 2809 && \

run connect-crscache-wxs baseCache 2000 && \

run connect-crscache-wxs services/cache/WCLayoutDistributedMapCache 1000 && \

...

3. Configuration avancée

Lorsque vous effectuez les étapes de configuration de base (étape 1 et étape 2), toutes les instances de cache sont placées dans la grille WebSphere eXtreme Scale par défaut nommée DYNACACHE_REMOTE. Différentes instances de cache sont placées dans différentes mappes, et le modèle de nom est IBM_DC_PARTITIONED_ plus le nom de l'instance de cache.

En fonction des performances ou d'autres considérations, vous pouvez placer des instances de cache dans une grille et une mappe WebSphere eXtreme Scale. Dans ce scénario, deux autres paramètres sont requis lorsque vous exécutez les commandes Run Engine pour l'étape 2.

Par exemple :
run connect-searchcache-wxs services/cache/SearchFacetDistributedMapCache 2000 searchGrid MapA
Dans cet exemple, searchGrid est le GridName cible et MapA est le MapName cible.

Limitations

Ces hypothèses ont été faites lors du développement des commandes Run Engine, ce qui peut limiter votre utilisation des commandes. Pour contourner ces limitations, vous devez configurer HCL Commerce différemment (par exemple, en mettant à jour directement le fichier de configuration).

Invalidation du cache entre le serveur de transactions et le serveur de magasin
Lorsqu'une instance de cache du serveur de magasin est placée dans WebSphere eXtreme Scale, l'instance de cache correspondante (avec le même nom Java Naming Directory Interface) du serveur de transactions doit également être mise dans WebSphere eXtreme Scale (en utilisant le même serveur de catalogue, la même grille et la même mappe). Sinon, le contenu du cache généré par le serveur de magasin ne peut pas être correctement invalidé par un message d'invalidation du serveur de transactions.
Limitation du serveur de catalogue WebSphere eXtreme Scale unique
L'implémentation actuelle de la commande Run Engine ne crée qu'un catalogue WebSphere eXtreme Scale par défaut (nom d'hôte et port) dans le fichier de configuration. Par conséquent, toutes les instances de cache doivent accéder au même serveur de catalogue WebSphere eXtreme Scale. Vous souhaitez peut-être que différentes instances de cache accèdent à différents serveurs de catalogue WebSphere eXtreme Scale pour des raisons de disponibilité. Dans ce scénario, vous pouvez effectuer l'implémentation à l'aide d'une adresse IP virtuelle ou d'un DNS dynamique. Toutefois, si vous souhaitez spécifier un autre nom d'hôte du serveur WebSphere eXtreme Scale pour différentes instances de cache, vous ne pouvez le faire que dans l'environnement Liberty pour les serveurs de magasin et de recherche. En outre, vous devez modifier le fichier de configuration directement pour créer plusieurs entrées elasticCacheClient.
Limites concernant l'utilisation de gridName et de mapName dans l'environnement Liberty
Pour la configuration avancée dans l'environnement Liberty, les paramètres gridName et mapName doivent être uniques. Cela signifie que vous ne pouvez pas placer deux instances de cache différentes du serveur de recherche ou de magasin dans la même grille non par défaut.
Remarque : Il n'y a pas de limites similaires sur le serveur de transactions dans l'environnement du serveur d'applications WebSphere traditionnel.

Problèmes connus

Exception d'outil de diagnostic de premier niveau dans le serveur de transactions
Pour la configuration avancée, lorsque le paramètre gridName est spécifié dans le serveur de transactions dans un environnement de serveur d'applications WebSphere, une exception d'outil de diagnostic de premier niveau concernant le paramètre gridName se produit dans le journal. Voici un exemple du message d'exception est :
FFDC Exception:java.lang.NoSuchFieldException SourceId:com.ibm.ws.util.FieldInitializer ProbeId:133 Reporter:java.lang.Class@fdc0cd34

java.lang.NoSuchFieldException: grid_name

...
Cette exception peut être ignorée car la fonctionnalité fonctionne toujours et l'exception ne se produit que lors du démarrage du serveur.
Problème de moniteur de cache dans le serveur de transactions
Le moniteur de cache étendu est utilisé pour analyser le comportement du cache dans un environnement de serveur d'applicatinos WebSphere traditionnel. Toutefois, lorsqu'une instance de cache utilise WebSphere eXtreme Scale comme fournisseur de cache, vous ne pouvez pas afficher le contenu du cache (une page vide s'affiche) même s'il n'y a pas de problème dans le moniteur de cache Liberty.
Pour contourner ce problème, extrayez le fichier contents.jsp de webCacheMonitor-1.0.tar.gz (qui est inclus dans les serveurs de recherche et de magasin Docker). Ce fichier se trouve dans com.ibm.ws.dynacache.cachemonitor_1.0.13.jar. Remplacez ce fichier par un fichier ayant un nom similaire dans le serveur d'applications WebSphere traditionnel CacheMonitor.war.
Avertissement sur la configuration des conflits dans les serveurs de recherche et de magasin
La configuration WebSphere eXtreme Scale est placée dans le fichier elasticCache.xml sous le dossier configDropins Liberty. En outre, la même valeur de configuration (par exemple, cacheSize) réside dans le fichier de configuration par défaut (server.xml). Voici un exemple du message d'avertissement de conflit de configuration dans le journal Liberty :
com.ibm.ws.config.xml.internal.ConfigValidator A CWWKG0102I: Found conflicting settings for baseCache instance of distributedMap configuration.

Property memorySizeInEntries has conflicting values:

Value 1000 is set in file:/opt/WebSphere/Liberty/usr/servers/default/server.xml.

Value 2000 is set in file:/opt/WebSphere/Liberty/usr/servers/default/configDropins/overrides/elasticCache.xml.

Property memorySizeInEntries will be set to 2000.
Cet avertissement est attendu et peut être ignoré.

Résultat

Vous avez intégré HCL Commerce à WebSphere eXtreme Scale afin d'améliorer les performances de votre implémentation à volume élevé.