Red Hat Training

A Red Hat training course is available for Red Hat JBoss Enterprise Application Platform

Chapitre 9. Clustering dans les applications web

9.1. Réplique de session

9.1.1. La réplique de session HTTP

La réplique de session veille à ce que les sessions client d'applications distribuables ne soient pas interrompues par des défaillances de noeuds dans le système. Chaque noeud du cluster partage des informations sur les sessions en cours, et peut les récupérer si le noeud d'origine disparaît.
La réplique de session est un mécanisme par lequel les clusters mod_cluster, mod_jk, mod_proxy, ISAPI, et NSAPI procurent une haute disponibilité.

9.1.2. Cache de session web

Le cache de session web peut être configuré quand vous utilisez l'un des profils HA, dont le profil standalone-ha.xml, ou les profils de domaine gérés ha ou full-ha. Les éléments les plus couramment configurés sont le mode cache et le nombre de propriétaires de cache pour un cache distribué.
Mode Cache

Le mode cache peut être REPL (par défaut) ou DIST.

REPL
Le mode REPL reproduit tout le cache à un nœud sur deux dans le cluster. Cela constitue l'option la plus sûre, mais elle introduit aussi plus de surcharge de temps.
DIST
Le mode DIST est semblable au buddy mode fourni dans les exécutions précédentes. Il réduit la surcharge de temps en répartissant le cache entre le nombre de nœuds indiqués dans le paramètre owners. Ce nombre de propriétaires est défini par défaut à 2.
Propriétaires

Le paramètre owners contrôle combien de nœuds de clusters détiennent des duplicata de la session. La valeur par défaut est 2.

9.1.3. Configurer le cache de session web

Par défaut, le cache de session web est REPL. Si vous souhaitez utiliser le mode DIST, exécutez les deux commandes suivantes dans l'interface CLI. Si vous utilisez un profil différent, changez le nom de profil dans les commandes. Si vous utilisez un serveur autonome, retirez la partie /profile=ha des commandes.

Procédure 9.1. Configurer le cache de session web

  1. Modifier le mode cache par défaut en DIST.

    /profile=ha/subsystem=infinispan/cache-container=web/:write-attribute(name=default-cache,value=dist)
    
  2. Définir le nombre de propriétaires de cache distribué.

    La commande suivante définit 5 propriétaires. La valeur par défaut est 2.
    /profile=ha/subsystem=infinispan/cache-container=web/distributed-cache=dist/:write-attribute(name=owners,value=5)
    
  3. Modifier le mode cache par défaut en REPL.

    /profile=ha/subsystem=infinispan/cache-container=web/:write-attribute(name=default-cache,value=repl)
    
  4. Relancer le serveur

    Après avoir modifié le mode cache du web, vous devez relancer le serveur.
Résultat

Votre serveur est configuré pour une copie de session. Pour utiliser une copie de session dans vos propres applications, veuillez vous référer au sujet suivant : Section 9.1.4, « Activer la copie de session pour votre application ».

9.1.4. Activer la copie de session pour votre application

Résumé

Pour profiter des fonctionnalités HA (High Availability) de JBoss EAP 6, configurer votre application de manière à ce qu'elle soit distribuable. Cette procédure vous montrera comment y parvenir puis vous expliquera certaines options de configuration avancées que vous pourrez utiliser.

Procédure 9.2. Rendez votre Application Distribuable

  1. Prérequis : indiquer que votre application est distribuable

    Si votre application n'apparaît pas comme distribuable, ses sessions ne seront jamais distribuées. Ajouter l'élément <distributable/> dans la balise <web-app> du fichier descriptif web.xml de votre application. Voici un exemple :

    Exemple 9.1. Configuration minimum pour une application distribuable

    <?xml version="1.0"?>
    <web-app  xmlns="http://java.sun.com/xml/ns/j2ee"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
              xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee 
                                  http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" 
              version="2.4">
              
          <distributable/>
        
    </web-app>
    
    
  2. Modifier le comportement de réplication par défaut si vous le souhaitez.

    Si vous souhaitez changer une des valeurs qui affectent la réplique de session, vous pouvez les changer dans l'élément <replication-config> qui est un dépendant de l'élément enfant de l'élément <jboss-web> du fichier jboss-web.xml de votre application. Pour un exemple donné, ne l'inclure que si vous souhaitez remplacer les valeurs par défaut. L'exemple suivant énumère tous les paramètres par défaut, et est suivi d'un tableau qui explique les options les plus fréquemment modifées.

    Exemple 9.2. Valeurs <replication-config> par défaut

    <!DOCTYPE jboss-web PUBLIC
        "-//JBoss//DTD Web Application 5.0//EN"
        "http://www.jboss.org/j2ee/dtd/jboss-web_5_0.dtd">
    
    <jboss-web>
       
       <replication-config>
          <cache-name>custom-session-cache</cache-name>
          <replication-trigger>SET</replication-trigger>
          <replication-granularity>ATTRIBUTE</replication-granularity>
          <use-jk>false</use-jk>
          <max-unreplicated-interval>30</max-unreplicated-interval>
          <snapshot-mode>INSTANT</snapshot-mode>
          <snapshot-interval>1000</snapshot-interval>
          <session-notification-policy>com.example.CustomSessionNotificationPolicy</session-notification-policy>
      </replication-config>
    
    </jboss-web>
    
    

Tableau 9.1. Options communes de réplication

Option
Description
<replication-trigger>
Contrôle quelles conditions doivent déclencher la réplication de données de session dans l'ensemble du cluster. Cette option est utile, quand un objet mutable (stocké comme attribut de session) est accessible à partir de la session, le conteneur n'a aucun moyen évident de savoir si l'objet a été modifié et s'il doit être reproduit, sauf si la méthode setAttribute() est appelée directement.

Valeurs valides pour <replication-trigger>

SET_AND_GET
Il s'agit de l'option de la façon la plus sécurisée, mais à moindre performance. Les données de session sont toujours répliquées, même si son contenu a été accédé, sans avoir été modifié. Cette configuration est préservée à but d'héritage uniquement. Éviter cette configuration et définir <max-unreplicated-interval> à 0, pour avoir le même comportement et une meilleure performance.
SET_AND_NON_PRIMITIVE_GET
La valeur par défaut. Les données de session ne sont répliquées que si on a accédé à un objet de type non primitif. Cela signifie que l'objet n'est pas d'un type Java connu comme Integer, Long, ou String.
SET
Cette option présume que l'application va explicitement appeler setAttribute sur la session quand les données auront besoin d'être répliquées. Cela empêche la réplication inutile et peut bénéficier à la performance dans son ensemble, mais il y a un problème de sécurité.
Quelle que soit la configuration, vous pourrez toujours déclencher la réplication de session en appelant setAttribute().
<replication-granularity>
Détermine la granularité des données répliquées. La valeur par défaut est SESSION, mais peut être définie à ATTRIBUTE à la place, pour augmenter la performance dans les sessions où la plupart des attributs restent inchangés.

Valeurs valides de <replication-granularity>

ATTRIBUTE
Uniquement for attributs compromis qui se trouvent dans la session ou pour des données de session comme la dernière date et heure d'accès.
SESSION
La valeur par défaut. Tout l'objet de la session est répliqué si un attribut est compromis. Les références d'objet partagé sont contenues dans des noeuds distants puisque la session dans son ensemble est sérialisée en une seule unité.

Note

FIELD n'est pas pris en charge dans JBoss EAP 6.
Les options suivantes ont rarement besoin d'être modifiées.

Tableau 9.2. Options les moins communément modifiées pour les réplications de session

Option
Description
<use-jk>
Présumons qu'un équilibreur de charge tel que mod_cluster, mod_jk, ou mod_proxy est utilisé. La valeur par défaut est false. Si définie comme true, le conteneur examine l'ID de session associé à chaque requête et remplace la partie jvmRoute de l'ID de session s'il y a un basculement.
<max-unreplicated-interval>
Le plus grand intervalle (en secondes) à attendre après qu'on ait pu accéder à une session avant de déclencher une réplication d'un horodateur de session, même s'il est considéré comme inchangé. Cela permet aux nœuds de cluster d'être informés de l'horodateur de chaque session et aux sessions non répliquées de ne pas expirer de manière incorrecte pendant un basculement. Cela vous permet également de vous fier à une valeur correcte pour les appels à méthode HttpSession.getLastAccessedTime() pendant un basculement.
Par défaut, aucune valeur n'est indiquée. Une valeur 0 entraîne une réplication de l'horodateur à chaque accès à la session. Une valeur -1 n'entraîne une réplication de l'horodateur que si une autre activité entraîne une réplication pendant la requête. Une valeur positive supérieure à HttpSession.getMaxInactiveInterval() est traitée comme une erreur de configuration et sera convertie à 0.
<snapshot-mode>
Indique quand les sessions sont répliquées vers d'autres nœuds. La valeur par défaut est INSTANT et l'autre valeur possible est INTERVAL.
En mode INSTANT, les modifications sont répliquées à la fin d'une requête, au moyen du thread de traitement des requêtes. L'option <snapshot-interval> est ignorée.
En mode INTERVAL, une tâche d'arrière-plan s'exécute à l'intervalle indiqué par <snapshot-interval>, et réplique les sessions modifiées.
<snapshot-interval>
L'intervalle, en millisecondes, pendant lequel les sessions modifiées doivent être répliquées si elles utilisent INTERVAL pour la valeur de <snapshot-mode>.
<session-notification-policy>
Nom complet de la classe de l'implémentation de l'interface ClusteredSessionNotificationPolicy qui contrôle si les notifications de spécification servlet sont émises vers un HttpSessionListener, HttpSessionAttributeListener, ou HttpSessionBindingListener enregistré.