Bien le bonjour,
 
Je m'interroge pas mal sur les possibilités impressionnantes (du moins je l'espère) de certains load balancers physiques au niveau applicatif tout particulièrement.
 
Tout d'abord, prenons le cas d'une archi J2EE comme suit :
- Un LB en frontal
- Puis 4 Apache
- Chaque Apache pointant sur un unique serveur d'application J2EE (les mêmes applis tournent sur les 4 serveurs d'application)
 
Le load balancer est évidemment chargé de répartir la charge sur les quatre Apache en fonction de différents critères mais aussi de créer une affinité de session permettant à un user lambda de toujours tomber sur le même Apache et donc, le même application server en back end tant que l'un des deux ne tombent pas.
Mais peut-il en faire plus ?
 
1. Certains LB proposent des modules supplémentaires (le font-ils à la base, je ne sais pas). Exemple chez F5, le "Link controller" censé checker régulièrement un lien de bout en bout ; mais fait-il ce que je recherche ?
Concrètement, est-il possible de créer une check rule cherchant à joindre une servlet bien précise directement sur le port de l'application server ? Si cette servlet répond mal ou pas du tout (possibilité de checker les codes erreurs ?), la route est coupée directement au niveau de l'Apache correspondant. Faisable ?
 
2. Le LB peut-il analyser parallèlement les deux couches : checker la santé des Apache, mais aussi effectuer le traitement décrit en 1 tout en analysant la santé de l'application server et réagir dynamiquement en fonction de tout cela ?
 
3. Existe-t-il d'autres protocoles spécifiques gérés par le LB ? RMI, IIOP, etc. ? Ceci permettrait d'affiner les check rules dont je parle plus haut.
 
4. Le LB est-il capable de gérer efficacement la mémorisation des sessions HTTP, ce qui permettrait d'affranchir les serveurs d'applications de cette lourde tâche (et surtout de la réplication de ces dernières) ? Si un user est affilié à l'Apache 1 et donc à l'AS1 et que ce dernier tombe, la session pourra directement être récupérée au niveau du LB et il redirigera le user sur l'Apache 2 (lié à l'AS2) ?
 
5. Des marques conseillées ? Des ordres de prix juste pour le fun ?
 
Voilà : D Je me rends compte que je suis un poil exigeant, mais si certains peuvent m'éclairer, je leur en serai reconnaissant car trouver des infos aussi précises sur les sites des différents constructeurs est difficile : /
 
Merci bien !  

Je passe sur les détails hein
 
1 - difficile, en général les probes concerne le service et le serveur qui est affecté au load balancer, c'est-à-dire le service web Apache. Aller contrôler l'état d'un serveur tierce pour mettre down un service est difiicile (à ma connaissance) même s'il me semble qu'on puisse faire un truc de ce gout là sur les cartes ACE Cisco, mais il te faut un 6500 et ça monte une config aux bas mots à 70k€ (à doubler pour redondance !). Par contre, on peut toujours aller contrôler éventuellement l'état de ton appli via le front end web à l'aide d'une probe évoluée...
 
2 - si le 1 est possible, alors 2) l'est aussi, on peut superposer des probes facilement sur les LB évolués.
 
3 - je sais pas
 
4 - normalement oui
 
5 - les deux grands constructeurs et leaders sur ce genre de produits sont F5 et Citrix (ex netscaler). En (gros) challenger, on trouve Cisco, et ensuite Nortel, Radware et d'autres... Pour du traitement applicatif avancé, NetScaler me semble devant suivi de près par F5 et plus loin Cisco...
 
Pour les tarifs :
 
pour du netscaler, du plus petit modèle au plus gros, ça va de 19000€ à 180 000€ HT. Et en plus faut rajouter éventuellement des options... Pour du F5, les prix sont identiques (grosso modo). Il va de soi que si tu es un grand compte, les constructeurs sont prêts à faire des rabais pour avoir la sacro sainte référence... Sans oublier bien sûr qu'il te faut deux LB pour redondance... (bon, le pack de 2 est moins cher que le prix de deux unités séparées) Je parle en prix publics...

dreamer->on est pas en assistance MOA, ni en avant-vente

j'ai juste répondu aux questions (et puis moi je suis support, pas avant vente )

je disais ça vis à vis de la fin de ton post que j'ai supprimée.

 
Merci pour toutes ces infos : )
 
Okay, ça paraît donc plus compliqué que je ne pensais...
Pourtant il me semblait qu'il était possible d'au moins définir une URL à checker et que le LB était capable d'analyser le code erreur (400, 500, 200, etc.) et de virer le chemin dynamiquement de sa "table de routage" (c'est pas le terme, mais on se comprend ; )) en cas de souci...
 
Tu parles de "probes évoluées" au niveau Apache ? Tu pourrais un peu détailler cet aspect car je ne vois pas trop à quoi ça correspond et si ça peut convenir à nos besoins...
 
Concernant les marques, c'est bien ce que je pensais : F5 et Netscaler.
Merci pour l'ordre de prix, après on a nos fournisseurs (qui vont d'ailleurs être ravis que l'on s'intéresse à ce genre de technos onéreuses : P).

oui c'est exactement ça

sinon avec openbsd 4.1 et pf/hostated/toussa tu peux faire de la répartition de charge conviviale, efficace et pas chère

contrat de support, maintenance 4h, RMA toussa....

Concernant le 4., si le but est de mettre en place une tolérance aux pannes, il y a de fortes chances qu'une réplication des sessions HTTP ne suffise pas à atteindre ce but. Ca dépend fortement de la partie du S.I. qui se trouve dans les AS. Et il y a de fortes chances qu'il faille répliquer le contexte d'un AS à un autre pour que ce soit transparent pour le "client" qui se trouve tout au bout de la chaîne.

 
Et donc faisable avec un LB "out of the box" ?
Les probes évoluées, ça ressemble à quoi alors ?
 
>black_lord : ouaip, mais tant qu'à faire, on cherche à optimiser l'infrastructure (accélaration http, etc.) puisqu'actuellement la solution en place fait déjà appel à du load balancing logiciel.
 
>Zzozo : en effet, je pense également qu'à ce niveau-là, la réplication entre les différents AS sera toujours nécessaire...
 
Merci : )

Une probe de niveau 7 effectue une vérification de niveau 7 et vérifie le code de retour. Sur un netscaler, par défaut, sur un service HTTP, le netscaler envoie une requête HEAD, et dans la réponse il cherche 200. Mais tu peux demander GET /, ou ou GET d'autre chose plus compliqué.
 
a+

Je remonte un peu le topic.
J'ai vu ça et là sur le net que les BigIP (F5) pouvaient spécifiquement analyser un serveur d'application WebSphere et régir le trafic en fonction de la santé de ce dernier.
 
En l'occurence, la santé d'un AS est défini par l'utilisation courante de la JVM au niveau CPU et mémoire, l'état des threads pools, etc.
 
Donc ma question : un LB de ce genre est-il capable d'assimiler les PMI (métriques de WebSphere) ?
Existe-t-il des modules de LB capables de prendre en compte des infos via JMX ?
 
Ca devient très spécifique là : )
 
Merci  

 
Je m'auto-réponds puisque j'ai eu réponse à toutes mes questions depuis.
 
En gros un BigIP (F5) est capable de faire un paquet de choses et s'avère super pratique lorsqu'il s'agit de faire plusieurs choses à la fois (toutes les fonctionnalités dans le même boîtier). Ainsi, on aura dans le même engin :
 
* Un reverse-proxy (iRules permettant de faire ce que l'on souhaite avec les paquets entrants)
* Un cache + fonctionnalités de compression
* Des fonctionnalités de proactive monitoring via des health checks qui peuvent être très précis. F5 met à disposition un SDK permettant de développer ses propres healthchecks pouvant se baser sur des protocoles tels que SOAP, CORBA, etc. Dans notre cas, il devient donc facile d'aller parser en live un petit fichier xml retourné par WebSphere indiquant la santé des différents process Java du serveur monitoré, et en fonction de cela, choisir le meilleur chemin (tout en recoupant ce test avec d'autres plus classiques)
Etc.
 
Pour peu que la machine soit bien dimensionnée, on bénéficie en plus de fonctionnalités de multiplexing, d'optimisation TCP/IP, etc.
Bref tout cela dans un même boîtier performant et évolutif.

F5 en compression c'est un peu de la merde quand même

 
J'ai en effet eu vent de critiques à ce niveau, mais étant donné que la compression est un "plus" pour nous, ce n'est pas une exigence.
C'est vraiment le côté hautement "personnalisable" qui est intéressant dans les produits F5.