[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [linux] [cluster] load balancing
En réponse à Pascal Bleser <pascal.bleser@atosorigin.com>:
> 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.
Tu peux avoir plusieurs types de failover aussi (cascading ressource, mutual
failover,rotating ressource,...) et ca, toutes les solutions ne le proposent
pas (ex. HACMP/es sur AIX oui mais à 15000euro par node et propriétaire).
Compaq propose un soft de cascading failover pour les ProLiant sous Linux, mais
je ne suis pas sur que ce soit opensource... je dois l'implémenter dans les
semaines à venir donc je peux laisser de l'info à ce moment là si c'est
toujours nécessaire.
>
> 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".
>
Le heartbeat via un lien série ou mieux via le storage partagé est une
meiileure solution à un ping via eth...
> 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 (*)).
Ou utiliser une solution IBM SSA standard (moins cher que de l'EMC² ou un ESS
sur de la fibre). Un rack D/T-40 avec deux cartes SSA sur chaque node c'est
très bon (le système de boucle SSA élimine déja le SPOF sur le lien). SSA
fonctionne aussi bien pour de l'Intel que du RS/6000...
>
> (*) 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.
Attention que du failover c'est génial pour de l'Oracle ou HTTP standard ou
autres systèmes ou tu n'as pas de connexion sécurisée. Par compte, si tu as du
SSL ou du tunneling, tu perdras toutes les connexions établies avant le
takeover. Elles seront réétablies sur le nouveau node de prod. "à blanc" (ex:
shopping card à zéro pour le client...). Une des solutions là serait des
machines en front qui fait load balancer (comme stonebeat full cluster ou une
implémentation VRRP) avec le https et puis derrière les DB en mutual failover
(comme hacmp)...reste à le faire avec des solutions libres.
>
> 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...
solution bon marché: twin-tailed SCSI différentiel, mais là: attention à ce que
l'application gère bien les I/O locks sinon...
>
> --
> -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
>
>
-------------------------------------------------
This mail sent through Tiscali Webmail (http://webmail.tiscali.be)
_______________________________________________
Linux Mailing List
Archives: http://unixtech.be/mailman/listinfo/linux