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

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 ?
 
sinon +1 pour la solution avec openbsd : carp + pf + hostated (en prime) et tu auras un LB de niveau 7.

cadeau :
http://www.openbsd.org/cgi-bin/man [...] ormat=html
http://www.openbsd.org/cgi-bin/man [...] ormat=html
http://www.openbsd.org/cgi-bin/man [...] ormat=html

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

Tout d'abord, merci à tous pour vos réponses
 
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 ?

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

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

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  
 
Faudrais pouvoir faire de la VAL (Validation des acquis de la Lecture) en plus de la VAE  

 
pour mémoriser faut de la pratique

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

Y'a juste tout ce qu'il faut.
Suffit d'ajouter autofs et je vois pas ce qu'il te faut de plus
 
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.

oui, c'est ça qui est bon

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 ?

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

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 ?

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

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

Merci à vous
 
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 ?

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

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 ?

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

Merci beaucoup pour ces infos
 
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 ?

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

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!!
 
Ostead

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.
 

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
 
 
UP pour les alternatives

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...  

Merci pour ces explications, c'est gentil de vouloir m'aider
 
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

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...    
 

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

 
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.
 

 
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...    

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?

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    
 

 
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?    
 

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

 
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 <-    
 
je cherche le nom et je t'envoi ça.

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.

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.