En r�ponse � Pascal Bleser <[EMAIL PROTECTED]>: > [EMAIL PROTECTED] 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) | > /\\ <[EMAIL PROTECTED]> | > _\_v <[EMAIL PROTECTED]> | > ---------------------------------------------| > 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)
