Reprise du message précédent :
L'outil dont tu parles est probablement heartbeat ou un programme du même genre. Cela permet de compléter LVS en y ajoutant la haute disponibilité.
Si un serveur ne répond plus, toutes les requêtes vont être réparties sur les autres serveurs qui répondent. La haute disponibilité ne rentre pas dans le cadre de ce projet.
 
 
Pour moi, la charge effective peut être impacter par la requête que reçoit le serveur.
Un serveur sur-équipé peut recevoir 50 requêtes et un autre moins bien équipé peut en recevoir 51.
Si parmi les 50 premières requêtes du serveur 1 il y a (par exemple) des accès à de grosses base de données qui augmentent les temps de réponse (sans pour autant rendre les serveurs timeout, donc la haute dispo n'est pas une solution), et que les 51 requêtes de l'autre serveur sont "faciles" à traiter,
 
on est bien dans un cas ou le serveur 1 qui présente sur le papier que des avantages pourra éventuellement fournir des temps de réponses moins bon que le serveur 2 pour une situation particulière, parce que certaines requêtes sont plus conséquentes que d'autres.
 
Dans ce genre de cas précis c'est bien les requêtes qui influent sur les performances, et seul une répartition de charge qui prend en compte la notion de temps de réponse peut répartir la/les requête(s) sur le bon serveur.

Le cluster HeartBeat faut l'utiliser sur la machine qui fait la répartition.
 
@Chti : j'avais regardé à une époque et je n'avais pas trouvé grand chose  qui prennent en compte la charge réel de la machine(proc, ram) etc...
Un mécanisme où la machine chargée de répartir les requêtes dispose d'une table d'état (charge machine) des serveurs derrières ... Ca combiné avec les algos de répartition me semblerait suffisant. Pas forcément besoin d'analyser un temps de requête ahma

Oui, c'est ça.  
 

Partons du principe que les reqûetes sont réparties 1 à 1, sur un poids de 1 et 1 sur des serveurs similaires.
 - la requete 1 est très lourde en traitement. Le serveur 1 est occupé pendant plusieurs secondes, indiquant au LVS un état de connection active à 1 pendant une durée de plusieurs secondes.
 - la requete 2 est légère et est très rapidement traité par le serveur 2. Ainsi son état de connection active passe à 1 puis revient à 0 très rapidement.  
Donc en choisissant l'algo WLC, notion de poids, avec le moins de connections actives tu arrives donc a une solution ou le temps de réponse sera inférieur sur le serveur 2 étant donné qu'il n'aura plus rien à traiter, non?
 

C'est le principe de la durée des connections et de la table des connections actives qui régit cela.
 

Pour moi la notion de temps de réponse est calculée, et le serveur de répartition ne peut pas la connaitre. Il ne peut que l'estimer selon les informations qu'il possède. Maintenant, je peux te fournir les algos simplifiés des algos de répartition et tu peux essayer de voir si ça prend en compte le temps de réponse.
je t'envois ça par MP après ma pause déjeuner.
 
@+

Je suis d'accord, mais le choix de la solution et de ses alternatives ne dépendant pas que de moi
 
Je suis étonné de pas réussir à trouver plus d'alternatives à LVS notamment dans le système de répartition de charge. Passé le (W)Round Robin et (W)Least Connection je trouve plus rien  

Cette notion de connection active est très intéressante. Faut que je me penche dessus.
Effectivement ça pourrait compenser le rapport avec le temps de réponse !

Hum effectivement
 
D'ailleurs je serais aussi intéressé par les algos simplifiés si c'est possible

Ah, je savais bien que je t'aurais à l'usure LOL.
 
@gug42: rends-toi à cette adresse: http://www.linuxvirtualserver.org/docs/scheduling.html
 
Tu trouveras ton bonheur je pense.
 
 

Hum je vais deja lire tout ca   ; apparement ca a quand même été pas mal repris dans ce topic

Ben ouai, j'ai pas la science infuse LOL et j'ai pas écrit le programme non plus.
Mais je te garanti que tu gagnes du temps en recherche/ compilation d'infos sur le sujet. Dis merci à tonton LOL

A l'occasion je vous fournirai mon rapport si ça vous intéresse, mais pas avant 3/4 semaines

Oui, ça m'intéresserait pas mal, je veux bien. Je te filerais mon action si tu veux, mais pas avant que tu ais fini ton projet histoire de pas t'influencer.
Bon courage
 
@+

Je ne m'avou pas vaincue
 
Après réflexions, j'ai pas l'impression que cette notion de connection active règle mon problème.
 
 
 
Reprenons un exemple. Un serveur A de poids fort (config musclé) gère 10 connections, dont plusieurs qui font de gros accès à des bases de données.
 
D'un autre côté un serveur B de poids faible gère lui aussi 10 connections mais avec de petites requêtes.
 
Le serveur A est fortement ralentie par ses gros traitements. Une autre requête arrive...
Si LVS dit que d'après ces algorithmes (poids fort? à qui le tour?), c'est au serveur A de recevoir la requête.  
 
Est-ce que LVS est capable de dire, "nan le serveur A effectue un traitement trop gourmand, alors malgré le fait qu'il soit de poids fort et que se soit son tour de recevoir la requête, on la balance sur le serveur B moins surchargé avec ses simples requêtes" ????

LOL oui, parceque les petites requetes vont se succèder tellement vite que son état de connexions actives (au serveur B) sera redevenu vide bien avant que le serveur A ait tout traité.
En fait pourquoi tu te fais pas l'install pour t'en convaincre? Ca serait mieux non?

Avant de l'installer faut que je règle ce problème de temps de réponse; l'installation et le test c'est la dernière partie de mon projet, le choix de la solution ce fait pendant l'audit
 
 
 
D'accord le serveur B va se vider plus rapidement. Mais dans un contexte de milliers de requêtes; à un instant T où on se trouve dans mon cas de figure:
 
C'est au serveur A de recevoir la requête, alors qu'il peine. Si LVS n'agit pas à cet instant (en tenant compte du temps de réponse); le serveur A se retrouve submergé (par je le rappel les requêtes précédentes imposantes) avec cette nouvelle requête qui arrive.
 
Alors oui le serveur B va se vider plus rapidement de ses connexions actives, MAIS il va aussi se remplire beaucoup plus vite puisque le serveur A est submergé... Du coup cet effet de soulagement n'est pas viable et dans ce cas précis le serveur A continue de recevoir des requêtes alors qu'il sature.
 
ps: J'espère que je ne suis pas trop lourd en insistant. Faut bien comprendre que derrière moi il y a une pression qui veut que les serveurs applicatifs soient capable de répondre  rapidement aux milliers de requêtes des utilisateurs, et que certaines requêtes sont très lourdes et consomment énormément de charge par rapport à d'autres. Si une requête fait souffrir un serveur (sans qu'il y ai de timeout), la solution doit être capable de ne plus lui envoyer de requêtes...

Salut,
 
pourquoi ne pas orienter les jobs importants vers des serveurs que tu dédies à cela, et selon un système de batch. En gros, les applications qui bouffent de la ressource, tu imposes de les faire passer sur les serveurs les plus puissants, avec un système de file. quand la tache N est passée, la tache N+1 y va etc...
 
Je sais que la ou je bosse on utilise ça. Bon, c'est un contexte d'applis de simulation nucléaires en même temps LOL Mais l'idée est la même.
 
++

Effectivement c'est une bonne idée que je soumettrais. Mais à priori, je dois -toujours- trouver cette éventuelle solution miracle en fonction du temps de réponse

Bonjour,
 
J'aimerai savoir si LVS est capable de faire de la repartition de charges sur des VM (VirtaulMachine), par exemple XEN.
 
Je suppose qu'il faille modifier un peu l'yperviseur pour arriver à ses fins, mais est-ce réellement possible ?

SAlut,
 
à mon avis c'est possible. LVS oriente simplement une requete vers un service sur une IP donnée. Si tu arrives à donner une IP à une VM, pourquoi ne pourrais-tu pas répartir la charge. Dans la théorie, ça devrait marcher. A tester. Sachant par contre que le répartisseur, dans les cas les plus simples, est toujours une machine différente des serveurs réels.
 
Voilà,
 
@+
 
Ostead

J'ai peut-être trouvé ma solution dans un mod proxy balancer pour Apache
http://httpd.apache.org/docs/2.2/m [...] #proxypass
 
Affaire à suivre...
 
Si vous avez d'autres idées