Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
2891 connectés 

  FORUM HardWare.fr
  Linux et OS Alternatifs
  réseaux et sécurité

  Répartition de charge : LVS, alternative ?

 


 Mot :   Pseudo :  
 
 Page :   1  2
Page Précédente
Auteur Sujet :

Répartition de charge : LVS, alternative ?

n°1002675
Chti Manso​n
Steam: qL
Posté le 17-01-2008 à 16:21:18  profilanswer
 

Bonjour,
 
Je travail actuellement sur une solution qui vise à mettre en place un système de répartition de charge de serveur HTTP (Apache).
 
D'après de longues recherches, la solution de référence s'appel LVS (Linux Virtual Server). D'autres sont également citées comme OpenMosix. Mais je n'arrive pas à trouver précisément les avantages/inconvénients de ses solutions...
 
J'aurais aimé savoir les quelques avantages/inconvénients de ces solutions, pourquoi telle ou telle solution se différencie ?
 
Merci d'avance :jap:


Message édité par Chti Manson le 29-01-2008 à 22:35:23
mood
Publicité
Posté le 17-01-2008 à 16:21:18  profilanswer
 

n°1002897
Guignolo
éternel newbie
Posté le 18-01-2008 à 05:15:58  profilanswer
 

Pour OpenMosix, le projet stagne depuis un moment, donc il vaut mieux oublier.
 
Ceci pourrait t'intéresser :
http://linux-ha.org/HomePage
 
Sinon tu peux faire un truc tout bête avec OpenBSD (fonctionne probablement aussi avec FreeBSD et NetBSD) : Installer des load balancers utilisant CARP et synchronisés avec pfsync ;)

n°1002899
black_lord
Modérateur
Truth speaks from peacefulness
Posté le 18-01-2008 à 05:49:26  profilanswer
 

Guignolo a écrit :

Pour OpenMosix, le projet stagne depuis un moment, donc il vaut mieux oublier.
 
Ceci pourrait t'intéresser :
http://linux-ha.org/HomePage
 
Sinon tu peux faire un truc tout bête avec OpenBSD (fonctionne probablement aussi avec FreeBSD et NetBSD) : Installer des load balancers utilisant CARP et synchronisés avec pfsync ;)


tu aurais pas lu un certain magazine toi ? [:cupra]
 
sinon +1 pour la solution avec openbsd : carp + pf + hostated (en prime) et tu auras un LB de niveau 7.


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
n°1002900
black_lord
Modérateur
Truth speaks from peacefulness
Posté le 18-01-2008 à 05:55:23  profilanswer
 
n°1002933
Taz
bisounours-codeur
Posté le 18-01-2008 à 09:34:09  profilanswer
 

carp/vrrp c'est pas spécifique à openbsd, tu peux faire ça sur plein d'autres trucs. Ou juste avec un proxy en frontal

n°1002936
Chti Manso​n
Steam: qL
Posté le 18-01-2008 à 09:38:24  profilanswer
 

Guignolo a écrit :

Pour OpenMosix, le projet stagne depuis un moment, donc il vaut mieux oublier.
 
Ceci pourrait t'intéresser :
http://linux-ha.org/HomePage
 
Sinon tu peux faire un truc tout bête avec OpenBSD (fonctionne probablement aussi avec FreeBSD et NetBSD) : Installer des load balancers utilisant CARP et synchronisés avec pfsync ;)


Tout d'abord, merci à tous pour vos réponses :jap:
 
D'après ce que j'ai pu lire là-dessus c'est plus de la haute disponnibilité que de la répartition de charge à proprement parlé.
 
Je vais voir tes liens black_lord :)
 
Personne n'a de retour sur Linux Virtual Server ? Y a t-il d'autres solutions ?


Message édité par Chti Manson le 18-01-2008 à 09:40:08
n°1003004
gug42
Posté le 18-01-2008 à 11:40:53  profilanswer
 

http://freshmeat.net/search/?q=loa [...] x=0&Go.y=0
 
Je suis currieux d'avoir des retours ;)

n°1003108
Guignolo
éternel newbie
Posté le 18-01-2008 à 14:25:13  profilanswer
 

black_lord a écrit :


tu aurais pas lu un certain magazine toi ? [:cupra]
 
sinon +1 pour la solution avec openbsd : carp + pf + hostated (en prime) et tu auras un LB de niveau 7.


[:joce]

n°1003112
M300A
Sehr hopfen, vielen IBU, wow!
Posté le 18-01-2008 à 14:28:53  profilanswer
 

linux mag de septembre 2007 ? :o
 
L'article sur iSCSI est plus interressant :o

n°1003123
black_lord
Modérateur
Truth speaks from peacefulness
Posté le 18-01-2008 à 14:35:56  profilanswer
 

M300A a écrit :

linux mag de septembre 2007 ? :o
 
L'article sur iSCSI est plus interressant :o


non, je pensais à un HS linux mag


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
mood
Publicité
Posté le 18-01-2008 à 14:35:56  profilanswer
 

n°1003127
Guignolo
éternel newbie
Posté le 18-01-2008 à 14:39:11  profilanswer
 

black_lord a écrit :


non, je pensais à un HS linux mag


Exact, je l'avais plus sous la main, mais ça prouve qu'on est pas obligés d'avoir des exams chiants pour mémoriser :o  
 
Faudrais pouvoir faire de la VAL (Validation des acquis de la Lecture) en plus de la VAE  [:tinostar]

n°1003128
black_lord
Modérateur
Truth speaks from peacefulness
Posté le 18-01-2008 à 14:41:12  profilanswer
 

Guignolo a écrit :


Exact, je l'avais plus sous la main, mais ça prouve qu'on est pas obligés d'avoir des exams chiants pour mémoriser :o  
 
Faudrais pouvoir faire de la VAL (Validation des acquis de la Lecture) en plus de la VAE  [:tinostar]


 
pour mémoriser faut de la pratique :o


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
n°1003151
e_esprit
Posté le 18-01-2008 à 15:18:42  profilanswer
 

M300A a écrit :

linux mag de septembre 2007 ? :o
 
L'article sur iSCSI est plus interressant :o


Pour ma part je l'ai trouvé plus que moyen :/


---------------
Ce n'est point ma façon de penser qui a fait mon malheur, c'est celle des autres.
n°1003299
M300A
Sehr hopfen, vielen IBU, wow!
Posté le 18-01-2008 à 21:31:46  profilanswer
 

Y'a juste tout ce qu'il faut.
Suffit d'ajouter autofs et je vois pas ce qu'il te faut de plus :D
 
black_lord > dans ce numéro y'a un article sur la HA Linux.
Je crois que j'ai le hors série quelque part aussi, mais c'est 100% bsd, il me semble.

n°1003301
black_lord
Modérateur
Truth speaks from peacefulness
Posté le 18-01-2008 à 21:45:49  profilanswer
 

oui, c'est ça qui est bon [:zebra33]


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
n°1003718
arghbis
salops de dauphins
Posté le 20-01-2008 à 19:05:04  profilanswer
 

pour du load balancing/proxy de serveurs http, j'utilises haproxy (et openvz pour virtualiser les différents serveurs)
 
ça marche très bien

n°1003786
Chti Manso​n
Steam: qL
Posté le 20-01-2008 à 23:35:59  profilanswer
 

arghbis a écrit :

pour du load balancing/proxy de serveurs http, j'utilises haproxy (et openvz pour virtualiser les différents serveurs)
 
ça marche très bien


Et pourquoi cette solution plutôt qu'une autre ? :)

n°1004001
arghbis
salops de dauphins
Posté le 21-01-2008 à 19:06:07  profilanswer
 

openvz parce que la virtualisation de serveur c'est très pratique (abstraction du matos sous-jacent, gestion de ressources, isolation des services), haproxy, car il est très performant, peu groumand en ressources, très souple et configurable à souhait.
 
Je m'intéresse aussi à LVS, mais je connais pas encore trop

n°1004083
Chti Manso​n
Steam: qL
Posté le 22-01-2008 à 08:22:02  profilanswer
 

De ce que j'ai pu lire LVS à l'air pas mal, mais ne gère pas la répartition en fonction des temps de réponse (ce qui représente la charge réelle d'un serveur). HAproxy le fait ? :??: Sinon, quel autre programme est capable de le faire ?


Message édité par Chti Manson le 22-01-2008 à 09:48:53
n°1004400
Chti Manso​n
Steam: qL
Posté le 23-01-2008 à 09:32:44  profilanswer
 

:bounce:

n°1004705
arghbis
salops de dauphins
Posté le 23-01-2008 à 18:50:49  profilanswer
 

haproxy ne le fait pas encore me semble-t-il. Pour la répartition de charge, si les serveurs sont configurés avec un poids identique, il fait du round-robin (ou autre si besoin de sessions). Il doit bentôt incorporer la routine pour faire de la répartition en fonction de l'occupation des liens réseau

n°1004708
zzsurf
Posté le 23-01-2008 à 19:12:21  profilanswer
 

Bonjour,
 
J'utilise LVS avec en directeur http://www.keepalived.org/ , effectivement ça ne tient pas compte du la charge réel mais c'est très robuste.
 
Je l'utilise pour du serveur web et du serveur de BDD, le principe et la configuration est identique
 
Actuellement en exploitation, ça reparti la charge sur un vingtaine de serveurs


Message édité par zzsurf le 23-01-2008 à 19:15:33
n°1004831
Chti Manso​n
Steam: qL
Posté le 24-01-2008 à 09:56:06  profilanswer
 

Merci à vous :jap:
 
D'accord, personne n'a une piste pour prendre en compte le temps de réponse des requête ou l'état du serveur ?  
 
zzsurf > Peux tu me dire à quoi sert keepalived exactement ? C'est le même principe que ldirectord? Est-ce que parmis tes serveurs web tu as des serveurs windows ?

n°1005088
zzsurf
Posté le 24-01-2008 à 21:10:20  profilanswer
 

keepalived c'est comme ldirectord, mais il est entièrement personnalisable au niveaux des tests sur les serveurs du cluster, c'est lui qui décide ce serveur est en état de marche je lui envoi des clients, il gère les règles du LVS ou plus précisément d'IPVS.
Je n'est pas de serveur web windows mais avec LVS tu peux varier les systèmes ça ne pose pas de problème

n°1005120
Chti Manso​n
Steam: qL
Posté le 24-01-2008 à 23:20:56  profilanswer
 

Oui sauf que la gestion du problème ARP est je crois un peu différente, ce qui me posera peut etre problème lors de l'installation.
Sans vouloir abusé de tes services, aurais-tu un bon tuto pour keepalived en fr ?

n°1006025
Chti Manso​n
Steam: qL
Posté le 29-01-2008 à 09:35:47  profilanswer
 

:bounce:

n°1006053
ostead
Posté le 29-01-2008 à 11:25:01  profilanswer
 

Salut,
 
je suis en BTS IG et j'ai une action pro sur la répartition de charge. J'utilise LVS sur une debian etch qui réparti la charge entre 2 serveurs ou le service http est installé. Il y a un serveur Linux debian etch et un windows XP. Y'a aucun problème vu que la répartition se fait vers le service que tu paramètre dans IPVS. Tu peux donc mettre des Linux, des Windows, des ce que tu veux tant qu'ils peuvent fournir le service adéquate.  
Ensuite, pour le cache ARP, ça dépend de la solution que tu choisira niveau toplogie. Si tu pars sur une solution en LVS-NAT (Network Adress translation), tu n'auras pas à le gérer. C'est la solution la plus simple à mettre en oeuvre, avec une configuration minimale. Par contre elle a ses limites et je ne pense pas que cela soit judicieux à utiliser en environnement de production. En effet, le serveur de répartition est pas mal mis à l'épreuve étant donné qu'il traite les paquets entrants, les réecrits et les transmet aux serveurs réels, puis reçoit leur réponse, la réecrit à nouveau avant de la renvoyer au client. Par contre si tu pars sur une solution LVS-DR (Direct routing) tu auras à gérer le problème du cache ARP. Tu as suffisamment de docs sur le site officiel pour y faire face sans problèmes. Cette solution est beaucoup plus performante, étant donné qu'elle ne monopolise pas le serveur de répartition dans les deux sens. Les requêtes ne sont pas retraduites lors des réponses des serveurs réels vers le client, si tu me suis toujours.
 
@+
 
Ostead

n°1006147
Chti Manso​n
Steam: qL
Posté le 29-01-2008 à 15:41:21  profilanswer
 

Merci beaucoup pour ces infos :jap:
 
Par contre, d'après ce que j'ai pu lire, LVS ne prends pas en compte dans sa répartition le facteur "temps de réponse aux requêtes".
 
Connaissez vous une alternative à LVS capable de gérer ce type de facteur ?

n°1006152
gug42
Posté le 29-01-2008 à 15:56:24  profilanswer
 

Citation :


keepalived c'est comme ldirectord, mais il est entièrement personnalisable au niveaux des tests sur les serveurs du cluster, c'est lui qui décide ce serveur est en état de marche je lui envoi des clients, il gère les règles du LVS ou plus précisément d'IPVS.  


les règles de keepalived ne peuvent elles pas être des temps de réponses ?
 
Une idée :
Avec HTTP_GET + md5sum + utilisation du timeout  : Si la page met plus de X secondes à s'afficher completement alors le md5sum sera différent donc le serveur ne sera plus appelé ? ou alors j'ai rien pigé  mais ca m'interesse en tout cas


Message édité par gug42 le 29-01-2008 à 16:02:41
n°1006204
ostead
Posté le 29-01-2008 à 19:37:56  profilanswer
 

Je comprends pas pourquoi tu focalises autant sur le temps de réponse de ton serveur. En fait le répartisseur va, selon l'algorithme de répartition que tu choisis, orienter la requête vers le serveur réel qui correspond le mieux à tes priorités de traitement. Ainsi, voici les différents algorithmes que tu pourras paramétrer sur un LVS:
- Le Round-Robin (RR) considère avec égalité tous les serveurs réels sans se soucier du nombre de connections entrantes ou du temps de réponse de chacun. Il est qualifié d'algorithme de répartition sans condition d'état.
 
- Le Weighted Round-Robin (WRR) ajoute à la boucle du RR la notion de poids. Ainsi, il est plus performant que ce dernier dans le cas ou les capacités de traitement sont différentes. Cependant, il peut mener à une mauvaise gestion de la charge lorsque les puissances varient beaucoup. Il est en effet fréquent que les grosses requêtes soient dirigées vers le même serveur, déséquilibrant ainsi la balance.  
 
- Le Least-Connection (LC) dirige les requêtes vers le serveur ayant le moins de connexions établies. Il est dit dynamique, comptant le nombre de connexion de chaque serveur pour estimer sa charge. Il garde un état du nombre de connexion, incrémentant le compteur lors de l'assignation ou le décrémentant lors d'une déconnexion ou d'un timeout. Le Least-Connection (LC) est idéal lorsque les serveurs ont une puissance de traitement similaire.  
 
Note: TCP produit un phénomène de cache. L'état TIME_WAIT, d'une durée d'environ 2 minutes par défaut, est un état durant lesquels les requêtes reçues sont “conservées” afin d'empêcher que les paquets non-fiables ou avec des erreurs ne soient à nouveau traités. Cela surcharge ainsi virtuellement le serveur. Pendant une période d'attente de 2 minutes, un site surchargé peut recevoir des centaines de connexions. Ainsi, un serveur A (imaginons le 2 fois plus puissant qu'un serveur B) peut garder des requêtes déjà exécutées dans un état de TIME_WAIT alors que le serveur B aura du mal à se défaire de sa centaine de connexion en cours.
 
- Ainsi, le Weighted Least Connexion (WLC) gère bien mieux la répartition entre serveurs de puissances différentes. Les serveurs de la ferme sont classés par rapport à leur poids, et un pourcentage leur est attribué. Le système de répartition du LC s'y ajoute ensuite.  
 
 
Voilà, je t'ai fait part de longues recherches sur le sujet, étant donné qu'il est difficile de trouver des infos sur le fonctionnement de base de cette technologie. J'y ai passé pas mal de temps en recherches et traduction afin de pouvoir y piger assez pour répondre aux questions des jurés ;)
 
Allez bonne chance et n'hésites pas si tu as des questions, j'adore ce sujet!! :D
 
Ostead

n°1006206
gug42
Posté le 29-01-2008 à 19:41:13  profilanswer
 

merci :)  
apparement le meilleur serait donc WLC  ?

n°1006217
ostead
Posté le 29-01-2008 à 20:07:30  profilanswer
 

gug42 a écrit :

merci :)  
apparement le meilleur serait donc WLC  ?


 
En théorie, cela devrait être le meilleur. Maintenant, tiens bien compte du parc de serveurs réels (ceux qui traitent les requêtes) car s'il ne sont pas de puissance de traitement similaire, tu peux favoriser un autre algo.
Le plus fastidieux dans LVS c'est la recompilation du noyau pour activer cette fonction sur ton serveur de répartition. A part ça, l'installation ne prend que quelques instant, et tu as ensuite tout le loisir de configurer tes options d'IPVS (logiciel qui gère le LVS)
En gros, cela ressemble à ça une ligne de paramètrage LVS:
 
-> ajouter une ligne à la table LVS du serveur virtuel, sur un service http réparti en WLC
/sbin/ipvsadm -A -t 192.168.2.110:http -s wlc
 
-> traitement du serveur réel 1: faire suivre http au serveur reel 192.168.1.3 avec LVS/ NAT (-m), poids de 1
/sbin/ipvsadm -a -t 192.168.2.110:http -r 192.168.1.3:http -m -w 1
 
Donc tu fais ta mise en oeuvre et tu testes. Si ça ne convient pas, ben tu changes d'algo, ou de poids, et tu retestes.
 


---------------
Ostead
n°1006235
Chti Manso​n
Steam: qL
Posté le 29-01-2008 à 20:58:54  profilanswer
 

Merci pour ces éclaircissements
 
Je me focalise sur les alternatives à LVS et sur la prise en compte du temps de réponse tout simplement parce que ça rentre dans le cadre de mon projet, j'ai pas forcément le choix :p
 
 
UP pour les alternatives :jap:


Message édité par Chti Manson le 29-01-2008 à 20:59:19
n°1006347
ostead
Posté le 30-01-2008 à 08:58:40  profilanswer
 

SAlut,
 
je réflechissais à ce que tu dis: le temps de réponse est fonction de plusieurs paramètres qui ne peuvent pas être calculés à l'avance. Il peut se passer plein de choses entre l'émission du paquet et son arrivée au client. Donc je pense que le fait de se dire que c'est le serveur de répartition qui va choisir le serveur réel destinataire en fonction de sa charge actuelle, (qu'il connait puisqu'il tient une table des connections actives) de ses possibilités de réponse (qu'il connait car tu as assigné un poids, je te le rappelle, avec les algos en W... Ainsi, en prenant le WLC, tu as le temps de réponse le plus optimale en théorie (mais le temps de réponse sera toujours théorique à mon avis) car c'est le serveur qui a le moins de connections actives, et avec la notion de poids, en fonction de son poids en particulier, la charge occupée est calculée en pourcentage, c'est donc le plus apte à répondre, avec le plus de puissance de traitement disponible qui sera destinataire.
Voilà, j'espère que j'ai été clair...  :pt1cable:


Message édité par ostead le 30-01-2008 à 08:58:55

---------------
Ostead
n°1006377
Chti Manso​n
Steam: qL
Posté le 30-01-2008 à 10:29:08  profilanswer
 

Merci pour ces explications, c'est gentil de vouloir m'aider :jap:
 
Je pense avoir compris ce que tu dis mais la notion de charge actuelle me chagrine... Est-ce que le fait de recevoir plus de requête est systématiquement synonyme de charge plus conséquente ???
 
 
 
Problèmatique:
 
Si un serveur reçoit par exemple 50 requêtes, un autre 200 requêtes. Le serveur 1  qui reçoit 50 requêtes est mieux équipé en processeur et en mémoire que le serveur 2 qui reçoit, en plus, 200 requêtes.
 
Les temps de réponse sont plus rapides du côté du serveur 1 qui reçoit moins de requêtes, même si les latences des deux serveurs sont convenables.
 
Imaginons maintenant qu'une requête est envoyée au serveur 1, et qu'elle monopolise énormément de charge. Le serveur 1 passe à 51 requêtes mais le temps de réponse chute...
Le serveur 2 est toujours en bon état.
 
Une autre requête arrive, elle va où ? Sans examiner le temps de réponse je vois pas comment elle pourrait se rediriger vers le serveur 2.
 
 
 
 
Voilà pourquoi je me focalise sur le temps de réponse :)

Message cité 1 fois
Message édité par Chti Manson le 30-01-2008 à 10:30:17
n°1006381
ostead
Posté le 30-01-2008 à 10:50:58  profilanswer
 

Chti Manson a écrit :

Merci pour ces explications, c'est gentil de vouloir m'aider :jap:
 
Je pense avoir compris ce que tu dis mais la notion de charge actuelle me chagrine... Est-ce que le fait de recevoir plus de requête est systématiquement synonyme de charge plus conséquente ???
 
Problèmatique:
 
Si un serveur reçoit par exemple 50 requêtes, un autre 200 requêtes. Le serveur 1  qui reçoit 50 requêtes est mieux équipé en processeur et en mémoire que le serveur 2 qui reçoit, en plus, 200 requêtes.


Cette notion de serveur mieux équipé se caractérise par le poids que tu lui accorde dans ton paramétrage. De plus, comment le serveur 2, moins bien équipé, pourrais t'il recevoir 4 fois plus de requêtes? Cela résulterait d'un mauvais paramérage de ton système de répartition...  :non:  
 

Chti Manson a écrit :


Les temps de réponse sont plus rapides du côté du serveur 1 qui reçoit moins de requêtes, même si les latences des deux serveurs sont convenables.


CF ma remarque précédente, normallement ça ne devrait pas arriver.
 
 

Chti Manson a écrit :


Imaginons maintenant qu'une requête est envoyée au serveur 1, et qu'elle monopolise énormément de charge. Le serveur 1 passe à 51 requêtes mais le temps de réponse chute...
Le serveur 2 est toujours en bon état.
 
Une autre requête arrive, elle va où ? Sans examiner le temps de réponse je vois pas comment elle pourrait se rediriger vers le serveur 2.


 
Elle ira, à mon avis, selon la plupart des algorithmes de LVS sur le serveur 1, étant donné qu'il n'a que 51 requetes en cours de traitement, et qui plus est qu'il a de plus grosses possibilités de traitement que le serveur 2. Ramènes tout ça à un pourcentage comme le fait LVS et tu verras que le serveur 1 a encore des possibilités de traitement, suffisamment en tout cas pour traitre ces 52 requêtes.
 

Chti Manson a écrit :


Voilà pourquoi je me focalise sur le temps de réponse :)


 
A mon avis, il y a mécompréhension. Ce n'est pas le temps de réponse qui te préoccupe, c'est la capacité de traitement (somme des capacités CPU & RAM) qu'il reste au serveur, non?
 
Dis au fait, c'est dans le cadre de quel projet que tu fais ça? Cursus scolaire ou appli pro? Je sais je suis trop curieux...  :sweat:  


---------------
Ostead
n°1006385
Chti Manso​n
Steam: qL
Posté le 30-01-2008 à 11:15:16  profilanswer
 

Effectivement dans le cadre de LVS, 50 requêtes d'un côté et 200 de l'autre c'est pas vraiment possible. Mais le principe reste le même.
 
Reprenons,
J'ai deux serveurs, un serveur 1 un peu mieux équipé que mon serveur 2.
J'attribue donc un poids fort sur le serveur 1.
 
Le problème est qu'une requête peut consommer plus ou moins de ressources et influencer directement le temps de réponse. Ce que j'essaye d'expliquer c'est que ce n'est pas forcément le nombre de requête ou les caractéristiques physiques du serveur qui font les temps de réponse.
(donc je m'intéresse bien au temps de réponse et non à la capacité physique)
 
A un instant T le serveur 1 à qui ça sera le tour de recevoir une requête suivant le principe LVS,  
 
- parce qu'il a un poids fort
- parce que c'est du tour à tour et que c'est justement son tour (RR ou WRR)
- parce qu'il a moins de requête que l'autre serveur (LC ou WLC)
 
va recevoir une requête alors que la précédente requête qu'il a reçu l'a mis à mal...  
 
Résultat:  
Le serveur 1 ne répondra pas assez vite bien qu'il soit mieux équipé et et que ce soit son tour.
Le serveur 2 sera en attente bien qu'il soit capable de la traiter plus rapidement, parce qu'il est de poids faible, supporte plus de requêtes actuellement, etc.
 
Tu vois ce que je veux dire?

Message cité 1 fois
Message édité par Chti Manson le 30-01-2008 à 11:19:24
n°1006388
ostead
Posté le 30-01-2008 à 11:25:30  profilanswer
 

Chti Manson a écrit :

Effectivement dans le cadre de LVS, 50 requêtes d'un côté et 200 de l'autre c'est pas vraiment possible. Mais le principe reste le même.


Pour être tout à fait juste c'est possible si tu as un poids donnant un rapport de 4 contre 1. Cependant ce n'est pas possible de se mettre dans cette situation en paramétrant le bon serveur avec le bon poids. Mais ça pourrait arriver si tu paramètres ça un soir grosse fatigue  :sleep:  
 

Chti Manson a écrit :

Le problème est qu'une requête peut consommer plus ou moins de ressources et influencer directement le temps de réponse. Ce que j'essaye d'expliquer c'est que ce n'est pas forcément le nombre de requête ou les caractéristiques physiques du serveur qui font les temps de réponse.
(donc je m'intéresse bien au temps de réponse et non à la capacité physique)


 
Mais qu'est-ce qui fait pour toi le temps de réponse d'un serveur si celui-ci n'est pas caractérisé par la soustraction des sommes des charges qu'il rencontre à sa capacité de traitement totale?  :heink:  
 

Chti Manson a écrit :


Tu vois ce que je veux dire?


 
Tout à fait. Cela rejoint d'ailleurs le problème que je notais quelques messages plus haut:
 
Je m'auto-cite  :sol:

Citation :

Note: TCP produit un phénomène de cache. L'état TIME_WAIT, d'une durée d'environ 2 minutes par défaut, est un état durant lesquels les requêtes reçues sont “conservées” afin d'empêcher que les paquets non-fiables ou avec des erreurs ne soient à nouveau traités. Cela surcharge ainsi virtuellement le serveur. Pendant une période d'attente de 2 minutes, un site surchargé peut recevoir des centaines de connexions. Ainsi, un serveur A (imaginons le 2 fois plus puissant qu'un serveur B) peut garder des requêtes déjà exécutées dans un état de TIME_WAIT alors que le serveur B aura du mal à se défaire de sa centaine de connexion en cours.


 
Il faut me semble t'il coupler ta solution à une techno dont je ne me souviens plus le nom qui, dans les grandes lignes, va se charger de retirer un serveur réel non disponible de la ferme afin de ne pas fausser la distribution des requetes. Peut-être que cet outil peut ainsi aider le LVS à mieux aiguiller ses reqûetes avec une gestion plus fine de la charge <-  :whistle:  
 
je cherche le nom et je t'envoi ça.


---------------
Ostead
n°1006394
ostead
Posté le 30-01-2008 à 11:45:46  profilanswer
 

En fait c'est sur la page du site officiel du projet:
http://www.linuxvirtualserver.org/ [...] ility.html
 
Ils donnent pas vraiment de détails mais tu peux trouver des pistes avec les différentes implémentations de LVS dans des logiciels plus avancés.

n°1006396
Chti Manso​n
Steam: qL
Posté le 30-01-2008 à 11:48:03  profilanswer
 

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.

Message cité 1 fois
Message édité par Chti Manson le 30-01-2008 à 11:48:47
mood
Publicité
Posté le   profilanswer
 

 Page :   1  2
Page Précédente

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Linux et OS Alternatifs
  réseaux et sécurité

  Répartition de charge : LVS, alternative ?

 

Sujets relatifs
Prise en charge native de carte SCSIWifiway qui ne charge pas ipwraw (does not exist in /proc/modules)
Charge inquiétante en raid 5 logicielNoyau Linux et prise en charge des pilotes : du nouveau
prise en charge 3D sous open suse avec une radeon 9550Alternative à rdiff-backup
[mac OS X], quelle alternative à Iphoto ?Alternative à NeroLinux et fichier >4GO
[Résolu] Menu Grub qui ne se charge plus après un msconfiglecture pps/ppt, existe t il une alternative a open office
Plus de sujets relatifs à : Répartition de charge : LVS, alternative ?


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR