Commentaires de news :
Maintenance dans la nuit du jeudi au vendredi

C'est vrai que l'idée d'un tuto pour ce genre de problème serait le bienvenu. Il pourrait être inclus dans un big tuto sur la gestion des serveurs (apache en particulier) ce qui bouclerait la boucle niveau formation web (un sur le langage de bas -XHTML/CSS-, un sur un langage dynamique -PHP/SQL- et un sur l'hébergement/les serveurs -apache/gestion BDD-).

Sinon, bon courage pour cette nouvelle nuit "commando".Et encore merci (je ne le dirai jamais assez) pour tout ce boulot.

C'est pas un nuit commando vous avez pas compris, on va tout administrer à distance. Physiquement ça change rien à l'architecture, c'est au niveau logiciel que ça va devenir (radicalement) différent !
Il ne devrait y avoir personne dans le datacenter ce soir-là.

Citation : M@teo21

Ça fait plaisir de voir qu'il existe encore des personnes qui ne pensent pas qu'à leurs bénéfices. Et je trouve la logique d'écriture de ce futur tuto très appréciable .

Moi je vais me contenter de dormir pendant que vous allez bosser comme des fous .

Bonne chance.

Super un loadbalancing, et tu as utilisé heartbeat ou pas ? Je dois en créer un, et je ne sais pas si je dois forcement l'utiliser ou non. J'ai commencé à créer ce load et j'ai quelques soucis : lorsque je tape ipvsadm j'obtiens :
IP Virtual Server version 1.2.0 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP IPV:www wlc
-> IP1:www Tunnel 1 0 0
-> IP2:www Tunnel 1 0 0

Alors que normalement je devrais avoir -> IP1:www Tunnel 1 2 0 et -> IP2:www Tunnel 1 2 0

Si quelqu'un peut m'aider, pouvez vous répondre ici : http://www.siteduzero.com/forum-83-256 [...] alancing.html

PS : c'est un vieux topic, j'ai beaucoup avancé depuis le temps, je vous expliquerai plus ou j'en suis, si vous me demandez des précisions!

Cordialement

Citation : Zanpakutoh
Y'a pas de risque, je te rappelle que les serveurs ne sont plus hébergés chez OVH (dans le fameux datacenter à la détection rétinienne qui mayrde §§ et aux 4 cadenas infernaux à codes différents =O ) mais chez Din'Hosting .

Bonne chance

Citation : M@teo21

A ce train là on va faire toute la ville de Springfield en serveurs...
A part ça, on peut compter combien de requêtes a la secondes sur les serveurs ?

Bon courage, c'est vrai qu'une meilleur répartition de la charge n'est pas de refus .
Je me suis toujours demandé comment des très gros sites s'organisaient, quelle stratégie ils utilisaient, et c'est vraiment sympa de nous faire part de vos études.

La répartition de charge (load balancing en anglais, littéralement équilibrage de charge) est une technique utilisée en informatique pour distribuer un travail entre plusieurs processus, ordinateurs, disques ou autres ressources.
C'est une forme d'optimisation. Les avantages sont nombreux :
 Augmentation de la qualité des services.
 Amélioration des temps de réponse des services.
 Capacité à palier la défaillance d'une ou de plusieurs machines.
 Possibilité d'ajouter des serveurs sans interruption de service.
Le principe de base consiste à interposer entre les consommateurs de la ressource et le pool de ressources un dispositif (le répartiteur) qui connaît l'état d'occupation de chaque ressource et qui est capable de diriger le consommateur vers la ressource la moins occupée, ou la plus facilement accessible. Les ressources peuvent ne pas avoir la même capacité à satisfaire les besoins du consommateur (en vitesse de traitement, en bande passante, etc.), ce qui influe sur le mode de calcul du répartiteur.
Un exemple de répartition de charge de type Round-robin est effectué au niveau des serveurs DNS : ainsi, pour un nom de domaine précis, le serveur DNS possède plusieurs adresses IP. À chaque requête, le serveur DNS choisit l'adresse IP à inclure dans la réponse de manière à ce que chaque adresse IP soit présente dans les réponses de manière équitable. Les différents accès au nom de domaine sont par conséquent répartis équitablement entre les différentes adresses IP.
Round Robin :
Round-robin est un algorithme d'ordonnancement courant dans les systèmes d'exploitation. Ce dernier attribue des tranches de temps à chaque processus en proportion égale, sans accorder de priorité aux processus.
Chaque processus reçoit du temps processeur appelé "quantum". Quand l'algorithme change de processus, cela prend du temps (de l'ordre de 1 ms). Il faut donc trouver le juste milieu entre:
 Un quantum court : changements de processus réguliers donc perte d'efficacité
 Un quantum long : le temps de réponse sera allongé

Solution pour un réseau :
Round Robin
ou
Linux virtual server : Site officiel de Linux Virtual Server : http://www.linuxvirtualserver.org


Mettre en place une solution de clustering et de load balancing permet d’accroître la disponibilité de votre application tel qu’un serveur web ou encore un serveur ftp. Pour effectuer cela, il existe plusieurs techniques :
 disposer d’un routeur de couche 4
 de mettre en place l’option Round Robin sur votre serveur DNS
 A l’aide de logiciel tel que Linux Virtual Server (LVS)
Fonctionnement LVS
LVS est un logiciel qui travaille sur les couches 3 et 4. Il fait des redirections sur différentes adresses IP et sur différents ports TCP. Nous pourrions dire que c’est un Round Robin évolué.
En effet, si l’on fait une symétrie entre LVS et Round Robin, dans le rôle du serveur ce sera le load balancer, et pour le reste cela reste la même chose.
Ainsi, lorsque l’on effectue une requête au load balancer c’est lui qui va déterminer quel serveur va répondre, en fonction de sa table répertoriant les serveurs réels et les services du serveur. Il se peut que ce load-balancer peut tomber en panne alors vous pouvez mettre un second load-balancer pour plus de sécurité. Ces deux répartiteurs de charge sont reliés par heartbeat. Les répartiteurs de charge forment un cluster, et chaque machine du cluster s’appelle un node.
Quel est l’intérêt par rapport à l’option Round Robin d’un serveur DNS ? Cela permet une meilleure adaptation au réseau et aux pannes car si un serveur réel tombe en panne, la table du load balancer est directement mis a jour par l’intermédiaire d’un logiciel nommé mon. De plus il existe beaucoup de logiciel de surveillance pour que votre application soit disponible à 99,9%.
(Pour être plus complet aller voir le site indiqué sur la première page)
Les différents algorithmes de LVS
LVS peut fonctionner sur tous les systèmes, du moment que celui-ci puisse fournir le service adéquat (comme http) car la répartition de charge se paramètre avec IPVS.
Il existe trois manières de faire du load balancing avec LVS :
1) En utilisant le NAT
2) En utilisant l’IP tunneling
3) En utilisant le routage direct
1) Le NAT
On dit qu'un routeur fait du Network Address Translation (NAT) (ce qu'on peut traduire de l'anglais en « traduction d'adresse réseau ») lorsqu'il fait correspondre les adresses IP internes non-uniques et souvent non routables d'un intranet à un ensemble d'adresses externes uniques et routables. Ce mécanisme permet notamment de faire correspondre une seule adresse externe publique visible sur Internet à toutes les adresses d'un réseau privé, et pallie ainsi la carence d'adresses IPv4 d'Internet.
Pour le cache ARP la solution la plus simple est en LVS- NAT. Ainsi pas besoin de gérer le cache ARP. Mais elle est limité car le serveur de répartition est durement mis à l’épreuve étant donné qu’il traite les paquets entrants, les réécrit et les transmet aux serveurs réels, puis reçoit leur réponse, la réécrit à nouveau avant de la renvoyer au client.

2) L’IP tunneling
ITP (Internet Tunneling Protocol) est un protocole (couche 3 du modèle OSI) permettant le transport de données sécurisées sur un réseau IP
ITP prend en charge la notion de NAT, il a été réalisé dans le but de fonctionner avec le protocole IPv6 tout en étant adapté pour l'actuel protocole IP : IPv4.
Son but est d'assurer l'intégrité et la confidentialité des données : le flux ne pourra être compréhensible que par le destinataire final (chiffrement) et la modification des données par des intermédiaires ne pourra être possible (intégrité).
ITP peut être un composant de VPN pour sa sécurité ou peut-être utilisé pour la répartition des charges.
L’intérêt est que l’IP Tuneling évite le point de congestion, c'est-à-dire que toutes les requêtes n’ont pas besoin de passer par le serveur de répartition aussi souvent qu’en mode LVS-NAT.

3) Le routage direct
Cette technique est la même que l’IP tuneling sauf que les serveurs réels se trouvent dans un même réseau local.
L’intérêt est le même que l’IP tuneling (évite le point de congestion) et l’encapsulation IP avec adressage IP virtuelle.
La solution LVS-DR (Direct Routing) est plus compliqué car il faut gérer le cache ARP, mais est beaucoup plus performante car 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.
Il y a d'autres outils comme Heartbeat et Ldirector qui peuvent renforcer le LVS:
- Heartbeat permet d'avoir plus de deux load balancers; si le load balancer primaire tombe en panne, le secondaire prend le relais automatiquement sans interruption de service
- Ldirector permet de verifier si les serveurs reels sont disponibles; si un des serveurs reels tombe en panne, il est automatiquement retire du LVS.
Les algorithmes de routage :
Différents algorithmes de répartition de la charge sont implémentés dans LVS. Ils définissent l'ordre dans lequel le load-balancer affectera les requêtes des clients aux différents reals servers proposant un service. Chaque service hébergé dans une ferme de serveurs LVS peut posséder son propre algorithme de répartition de charge. Voici ces algorithmes existants :

Round-Robin Scheduling : Par exemple, dans une configuration avec 2 real-servers, la première requête sera affectée au 1er serveur, la seconde au second serveur, la 3ème requête au 1er server, et ainsi de suite en boucle.

Weighted Round-Robin Scheduling : même technique, mais les real-serveurs peuvent être affectés par des poids, pour tenir compte des différentes capacités de traitement.

Least-Connection Scheduling : le load-balancer possède une table des connections actives. Il renverra toute nouvelle requête au serveur possédant le moins de connexions actives, dynamiquement.

Weighted Least-Connection Scheduling : même idée que l'algorithme précédent, en ayant la possibilité d'attribuer des poids aux serveurs.

Locality-Based Least-Connection Scheduling : Le load balancer choisit un real-server dans un groupe en fonction de l'adresse IP de destination. Il est utilisé dans les clusters de cache.

Locality-Based Least-Connection with Replication scheduling : Idem que le précedent, avec une fonctionnalité supplémentaire : si tous les serveurs du groupe sont surchargés ou indisponibles, il choisit un serveur dans un autre groupe pour l'affecter au 1er groupe de serveurs.
Destination Hashing Scheduling : affecte la requête arrivant à un serveur d'un groupe fixé dans une table de hashage, en fonction de l'adresse IP de destination.

Source Hashing Scheduling : affecte la requête à un real-server en fonction de l'adresse source.

- 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à ce que j'ai trouvé pour le moment
Bonne lecture

Citation : Zanpakutoh
Tout va se faire à distance par commandes SSH, pas besoin de se déplacer.

Bonne chnace pour la mise en place, n'oubliez pas le Coca pour tenir toute la nuit (comment ça je suis pessimiste ).

EDIT : pour l'imbécile qui a copié/collé le contenu de Wikipédia, tu pouvais pas tout simplement donner le lien vers la page.

Ouch j'ai tout compris mais fallait que je relise une ou deux fois

J'espère qu'il y'aura aucun problèmes majeures

Si je peut donner un petit conseil, n'oubliez pas la pallette d'aspirine ;p

En tout cas bonne chance pour cette haute voltige

Citation : Tortue facile
O RLY ?
Nan, mais j'ai dit "en cas de problèmes" tqvu. Je me doute que le load-balancing c'est pas de les mettre physiquement comme sur le schéma, avec des flèches étou

Si je me souviens bien, c'était quand même pas prévu la dernière fois quand ils ont forcé l'accès à Lisa. Stait un problème.
Donc en cas de problème...

BRAVO!

Je vous envie d'avoir la possibilité de vous "amuser" comme ça car c'est pas offert à tout le monde. Aussi j'aimerais avoir vos connaissances dans ces domaines, c'est fantastique!

Bon courage pour Jeudi soir, prenez la réserve de café et bonne manoeuvre

Bon courage pour tout ça !!

Citation : M@teo21

Je suis certain que cela servira à quelqu'un. Un tuto comme celui-là n'est pas - comme tu le dis justement - très répandu. Personnellement, je ne crois pas que j'attendrais d'en avoir besoin pour le lire. Merci pour tout ton dévouement en tout cas !!

C'est super tout ça Bonne chance pour la fameuse nuit

Citation : Zanpakutoh

Oué, un malencontreux petit shutdown -P, ou une coupure de courant .

Bonjours, vous comptez un jour faire un tuto ou autres choses sur la façon d'où vous avez procédé pour mettre en place ce système ?
Car je pense que cela peux intéressé certaine personnes. étant donné que vous avez galèré pour comprendre et que vous avez enfin réussi à le faire il serait bien d'expliquer.


Merci d'avance et bon courage

Citation : zolectronic
Euh, tu le fais exprès ?
Tu as le droit de lire les messages des autres gens.
J'aurais bien rajouté un mot désagréable, mais c'est pas cool.

Si m@teo, ça concerne au moins moi ce tuto, dans ma boite on a exactement le même problème que vous: Postgres, on a 4 serveurs (2 apache et 2 postgres), notre hébergeur nous avait promis qu'il y'aurait du load balancing, et au final rien du tout. On a 2 servers qui ne servent pas et on a pas de load balancing.

Citation : M@teo21

Repose toi bien avant de passer a l'action jeudi soir

Bon ben voilà, comme quoi y'a des gens qui utilisent PostgreSQL, on n'est pas les seuls \o/

Je suppose que pour répliquer votre base PostgreSQL vous allez faire ça avec Slony ?
(quoique de souvenir c'est de l'asychrone). Après je crois qu'on peut faire intervenir Heartbeat, etc...mais lui je ne maîtrise pas trop.
J'en avais fait un peu sur Linux, en étant archi débutant Linux. C'est chaud à comprendre et même si j'avais fait marcher la réplication en test, je n'avais pas pu mettre en production pour diverses raison.

J'avais fait un rapport de stage (enfin j'étais apprenti) la dessus..un peu casse tête. Je ne sais pas où en est Slony maintenant !

Et le tuto la dessus, ce serait absolument génial ! Ya pas mal de notions très intéressantes à voir avec des mots barbares : cluster, trigger, etc. C'est vrai que la doc (en français surtout) est rare ou pauvre la dessus.

En tout cas, bon courage... !

Merci de nous tenir informer de cette opération qui sera je le pense aussi très délicate.

En espérant que vous trouverez par la suite le temps de nous enseigner votre savoir dans un tuto.

Merde a toutes l'équipe (histoire de ne pas porter la pouasse ).

Petites questions avec MySql c'est possible ?? C'est plus simple ?? Pourquoi utiliser PostgreSQL ??

Merci d'avance

Vous êtes de vrais commandos :-p sans rire, je vous souhaite beaucoup de courage car ça ne doit pas être facile de s'occuper d'autant de serveur et tout ce qui va avec!

Jeudi soir, n'oubliez pas le café car je sent que vous allez en avoir besoin

Bon courage les commandos d'élites

Bonne chance pour cette opération quelque peu délicate !!!
Comme cela a déjà été dit plusieurs fois, ça montre bien que le site gagne en importance et en renommée !!!

Merci pour toutes ces explications =) .
Et bonne chance.

vous utilisez quoi comme programme pour faire les diagramme réseau ?
si non pour la réplication vous utilisez quoi ? Slony ?

Citation : zolectronic
Postgresql supporte mieu les charge que mysql, est plus rapide sous forte charge, et est plus complet

Pas slony, c'est asynchrone. Il s'agit de pgCluster.