Quel est l'inconvénient des sessions persistantes avec des équilibreurs de charge?

Nous avons une ferme Web de machines IIS7 qui fonctionnent très bien. Devant eux se trouve un équilibreur de charge matériel F5 Big-IP , qui fonctionne également très bien :)

_{(source: www.f5.com )}

Actuellement, nous utilisons un ASP.NET State Servicepour gérer notre état OutProc . Cela est nécessaire lorsque vous disposez d'une batterie de serveurs Web pour gérer tout type d'informations de session.

Je me demandais si nous pouvions avoir des sessions collantes sur le F5 Big-IP et donc passer d'OutProc à InProc? Si oui, quel est l'inconvénient de cela? Je connais les inconvénients d'InProc vs OutProc, alors ne vous inquiétez pas d'expliquer cela. Je suis plus intéressé par les avantages / inconvénients des sessions persistantes sans F5 Big-IP .

Quelqu'un peut-il apporter de la lumière et / ou de l'expérience?

Il y a deux principaux inconvénients:

1. Votre charge n'est pas répartie uniformément. Les sessions collantes resteront, d'où le nom. Bien que les demandes initiales soient distribuées de manière égale, vous pourriez vous retrouver avec un nombre important d'utilisateurs passant plus de temps que d'autres. Si tous ces éléments sont initialement définis sur un seul serveur, ce serveur aura beaucoup plus de charge. En règle générale, cela n'a pas vraiment un impact énorme et peut être atténué en ayant plus de serveurs dans votre cluster.

2. Les proxys regroupent les utilisateurs en IP uniques, qui seraient toutes envoyées à un seul serveur. Bien que cela ne fasse généralement pas de mal, autre que l'augmentation de la charge des serveurs individuels, les proxys peuvent également fonctionner dans un cluster. Une demande dans votre F5 à partir d'un tel système ne serait pas nécessairement renvoyée au même serveur si la demande provient d'un autre serveur proxy dans leur cluster proxy.

AOL était à un moment donné en utilisant des clusters de proxy, et vraiment foutu avec des équilibreurs de charge et des sessions collantes. La plupart des équilibreurs de charge proposeront désormais des sessions persistantes basées sur des plages nettes de classe C, ou avec le cas de F5, des sessions persistantes basées sur des cookies qui stockent le nœud final dans un cookie de requête Web.

Bien que les sessions basées sur les cookies devraient fonctionner, j'ai eu quelques problèmes avec elles et je choisis généralement des sessions basées sur IP. GRAND CEPENDANT: Je travaille principalement sur des applications internes - le kilométrage DMZ peut varier.

Cela étant dit, nous avons eu un grand succès avec les sites fonctionnant derrière F5 avec des sessions persistantes et des sessions In-Proc.

Vous voudrez peut-être également jeter un œil à l'un des systèmes de mise en cache distribuée en mémoire comme Memcached ou Velocity pour une alternative au stockage de session en SQL ou au service de mémoire hors proc. Vous vous rapprochez de la vitesse de la mémoire in-proc avec la possibilité de l'exécuter sur plusieurs serveurs.

J'ai récemment lu un excellent article dans TechNet concernant "Fournir l'évolutivité pour les applications ASP.NET". Il est entré dans les avantages et les inconvénients de chaque solution possible. Lisez:

TechNet juin 2009 - Fournir l'évolutivité pour les applications ASP.NET

En plus de l'excellente réponse de Christopher, les sessions persistantes signifient que vous avez perdu quelques-uns des énormes avantages des serveurs redondants - la possibilité de supprimer un ou plusieurs pour la maintenance et la transparence face à la défaillance du système.

Je considère les sessions persistantes comme un indicateur fort d'une mauvaise architecture d'application et / ou d'une mauvaise programmation. "Evitez à tout prix" est ma devise.