Sessions persistantes et réplication de session
J'évalue le cas d'utilisation de sessions collantes avec la réplication de session dans Tomcat. Dès mon évaluation initiale, je pensais que si nous activions la réplication de session, alors la session démarrée dans un nœud Tomcat serait copiée sur tous les autres nœuds Tomcat. Nous n'avons donc pas besoin de session collante pour poursuivre les sessions et la requête peut être prise en charge par n'importe quel nœud. .
Mais il semble que la réplication de session soit généralement utilisée avec des sessions persistantes, sinon l'identifiant de session doit être modifié chaque fois que la demande est envoyée à un autre nœud. ref: http://Tomcat.Apache.org/Tomcat-6.0-doc/cluster-howto.html#Bind_session_after_crash_to_failover_node
Quelqu'un peut-il expliquer quelle est l'utilisation réelle de la réplication de session si vous devez activer une session collante? Dans ce cas, vous copiez inutilement la session sur chaque nœud, lorsque la demande portant un identifiant de session donné est toujours adressée au même nœud. Cela pourrait être bénéfique en cas de panne d’un nœud, mais cela ne se produit pas souvent et l’utilisation de la réplication de session uniquement pour des raisons qui semblent excessives.
Je pense que le seul avantage réel est de pouvoir fermer les instances de Tomcat sans trop y penser. Cela vaut en particulier aujourd'hui dans le monde du cloud (pensez aux instances ponctuelles d'Amazon AWS) lorsque les nœuds peuvent être très souvent allumés et éteints. Une alternative à cela serait d’acheter un équilibreur de charge décent qui supporte le drainage des nœuds. Mais les équilibreurs de charge décents coûtent cher, et le drainage prend du temps.
Un autre scénario auquel je peux penser est une (mauvaise mise en œuvre du) panier dans lequel les articles sont conservés dans la variable HttpSession et où la fermeture obligerait l'utilisateur à les racheter (ce qui entraînerait probablement une perte de vente).
Mais dans la plupart des cas, vous avez raison: l'avantage d'avoir à la fois des sessions collantes et une réplication de session est très négligeable.
Comme Mindas l'expliquait auparavant:
Lorsque vous utilisez l'équilibrage de charge, cela signifie que vous avez plusieurs instances de Tomcat et que vous devez diviser les charges.
- Si vous utilisez une réplication de session sans session collante: Imaginez qu'un seul utilisateur utilise votre application Web et que vous disposiez de 3 Instances Tomcat. Cet utilisateur envoie plusieurs demandes à votre application, puis Le répartiteur de charge enverra certaines de ces demandes à la première instance de Tomcat , Et d'autres de ces demandes à la deuxième instance . et autres au troisième.
- Si vous utilisez une session collante sans réplication: Imaginez qu'un seul utilisateur utilise votre application Web et que vous ayez 3 instances de Tomcat . Cet utilisateur envoie plusieurs demandes à votre application, puis le répartiteur de charge Envoie la première demande à l'une des trois instances de Tomcat , Ainsi que toutes les autres demandes envoyées par ce utilisateur au cours de sa session sera envoyé à la même instance Tomcat. Au cours de ces demandes, si vous arrêtez ou redémarrez cette instance Tomcat (instance utilisée de Tomcat), le loadbalancer envoie le demandes restantes à une autre instance Tomcat toujours en cours d'exécution MAIS comme vous n'utilisez pas de réplication de session, l'instance Tomcat qui reçoit les demandes restantes ne dispose pas d'une copie de la session utilisateur puis pour ce Tomcat, l'utilisateur commence une session: l'utilisateur perd sa session et est déconnecté de l'application Web alors que l'application Web est toujours en cours d'exécution.
- Si vous utilisez une session rémanente AVEC la réplication de session: Imaginez qu'un seul utilisateur utilise votre application Web et que vous ayez 3 instances de Tomcat . Cet utilisateur envoie plusieurs demandes à votre application, puis le répartiteur de charge Envoie la première demande à l'une des trois instances de Tomcat , Ainsi que toutes les autres demandes envoyées par ce utilisateur au cours de sa session sera envoyé à la même instance Tomcat. Au cours de ces demandes, si vous arrêtez ou redémarrez cette instance Tomcat (instance utilisée de Tomcat), le loadbalancer envoie le demandes restantes à une autre instance Tomcat toujours en cours d'exécution , lorsque vous utilisez la réplication de session, l'instance Tomcat qui reçoit les demandes restantes a une copie de la session utilisateur, puis l'utilisateur conserve sa session: l'utilisateur continue à parcourir votre application Web sans être déconnecté, la fermeture de l'instance de Tomcat n'a aucune incidence sur la navigation de l'utilisateur.
Juste pour clarifier les problèmes de configuration sur JBoss 5.X dans la configuration de base "all" avec mod_jk. Définition de sessions persistantes dans le fichier workers.properties
worker.list=loadbalancer
... nodes configuration omitted
worker.loadbalancer.balance_workers=node1,node2
worker.loadbalancer.sticky_session=True
n'empêche pas la réplication de session. Afin de désactiver la réplication de session sur JBoss, nous devons définir dans $ JBOSS_HOME\server\YOUR_NODE_NAME\deploy\cluster\jboss-cache-manager.sar\META-INF\jboss-cache-manager-jboss-beans.xml cacheMode paramètre à LOCAL.
Habituellement, dans le scénario persistant, nous ne voulons pas de réplication de session, car nous ne voulons pas de temps système supplémentaire lié à un nombre important d'opérations d'E/S nécessaires à la réplication de sessions.
En fait, si vous utilisez des sessions persistantes, il n'est pas nécessaire d'exécuter JBoss dans une configuration "all", vous pouvez utiliser une configuration "par défaut" ou "standard".
La seule chose à faire est de changer dans $ JBOSS_HOME/server/YOUR_NODE_NAME/deploy/jbossweb.sar/server.xml:
<Engine name="jboss.web" defaultHost="localhost" jvmRoute="YOUR_NODE_NAME">