[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [linux] [cluster] load balancing
vincent@namurlug.org wrote:
l'equivalent du soft StoneBeat ..
http://www.stonesoft.com/document/art/312.html
c'est plutôt du "load balancing" pour l'application BEA Tuxedo que l'on
voudrait faire
http://www.bea.com/products/tuxedo/index.shtml
Je penses aussi que tuxedo gère lui même un certain "balacing"
Oui, utilise ça.
Mais je voulais savoir ce qu il existe comme soft pour la distribution des
connections IP
Ca ne te servira pas à grand-chose, à cause du failover.
Tu "passes à côté" de Tuxedo qui gère déjà ce genre de choses.
Ca pourrait notamment faire des problèmes pour le redémarrage de nouveaux
serveurs selon la charge, etc...
Tu dois utiliser le load-balancing et le failover intégré de Tuxedo.
Il le fait bien mieux d'ailleurs (évidemment, c'est spécifique à l'application),
car il surveille la charge des queues de requêtes et fait le load-balancing
en fonction de cela, ce qui est bien meilleur qu'un round-robin au niveau IP.
Tu peux même définir un "poids" par service, qu'il utilise pour calculer la
charge de chaque queue: en effet, les différents services ont chacun un temps
d'éxécution et une charge au niveau CPU et I/O différents.
> ..(et si une machine ne reponds plus ...)
Ca, c'est du failover et plus du load-balancing.
C'est déjà nettement plus complexe.
Là encore, la seule bonne façon de faire dans ton cas et de le faire via Tuxedo.
Il fait ça très bien, d'ailleurs (je sais de quoi je parle, je fais ça (entre-
autres ;-)) depuis 3 ans et j'ai eu pas mal de formations Tuxedo ;-)).
On a notamment un très gros système en production avec 4 noeuds (2x Tuxedo
+ WebLogic Server, 2x Oracle) chez VISA (en Autriche)...
Ce sont des grosses HP SMP (la charge est très conséquente).
Tuxedo incorpore un "heartbeat" (un ping de surveillance entre les noeuds) et
reprend pour lui les requêtes lorsque l'autre noeud est "mort".
Evidemment, il faut aussi faire un takeover de l'adresse IP au niveau de l'OS.
Jette un oeil à "heartbeat" sur http://linux-ha.org pour ça.
Mais il y a encore bien d'autres problèmes, principalement les données persistantes
(= disques). Soit il faut synchroniser les disques des 2 noeuds (très difficile),
soit utiliser un disque partagé physiquement (GFS/OpenGFS avec de la fibre optique
= très cher), soit tout stoquer dans une DB sur un noeud à part (qui devient par
la même un SPOF (*)).
(*) Single Point of Failure
Crois-moi, c'est loin d'être simple ces trucs-là.
Et des softs comme StoneBeat et consors ne t'aident *en rien*.
Ils font juste le heartbeat, la surveillance des noeuds entre eux (ce que "heartbeat"
ou "mon" sous Linux fait aussi).
Pour le takeover proprement dit, tu dois quand même écrire tes scripts...
Si il y a bien un domaine pour lequel il n'y a pas de solutions "out-of-the-box",
c'est bien le failover.
Je te conseille fortement de d'abord configurer Tuxedo pour faire le load-balancing
et le failover et de voir ce qu'il sait faire.
Le takeover IP est plutôt facile à faire via "heartbeat" de Linux-HA.org: une 2ème
carte réseau sur chaque noeud pour un réseau back-end du cluster (conseillé de toute
façon pour une meilleure performance au niveau de la communication entre les noeuds),
une ligne série entre les noeuds pour un heartbeat supplémentaire, des scripts de
surveillance des services (écrire un petit client Tuxedo qui fait une requête à un
service très simple et très rapide, à écrire aussi éventuellement), un peu de
configuration pour heartbeat et c'est bon.
Mais le gros problème, ce sont les data = les disques...
--
-o) Pascal Bleser ATOS Origin/Aachen(DE) |
/\\ <pascal.bleser@atosorigin.com> |
_\_v <guru@linuxbe.org> |
---------------------------------------------|
Jesus saves,Buddha makes incremental backups :
---------------------------------------------'
_______________________________________________
Linux Mailing List
Archives: http://unixtech.be/mailman/listinfo/linux