Load balancing et failover
Bonjour,
Je réfléchis à un projet d'extarnilsation de services web pair à pair (mutualisé) pour des particuliers.
Je cherche des infos sur des notions architecturales sur le failover et le loadbalancing.
J'ai trouvé pas mal d'informations sur le sujet.
Par exemple la documentation de haproxy est très enrichissante sur le sujet.
Il y a beaucoups de notions et de protocoles que je ne maitrise pas encore.
Mais tout ce que j'ai lu pour le moment prétend qu'il faut introduire un loadbalancer en ammont, voir de le doubler, tripler…
Mais ca fait toujours un élément en plus à gérer et donc un facteur de panne supplémentaire.
Donc je veux faire une architecture réseau qui n'en utilise pas. Je veux que mes services réseaux aient leur propre capacité de répartition avec par exemple un loadbalancer en plus du serveur sur chaque serveur (charge en plus).
J'ai un peu réfléchis ca donne ca :
A prioris c'est possible mais il y a des problème :)
Le DNS pointera toujours sur Charlie même en cas d'innacessibilité de Charlie.
Donc je pensais travailler sur les requetes http de mon client (pour que cela pointe sur Tango en cas de problème) or je ne sais pas si ca va lui plaire.
Il y a pleinjs de RFC à lire mais tout ca c'est un peu la folie, non ? C'est un art mais dans mon cas je ne suis pas sur que cela m'aide car je ne sais pas où commencer :
http://www.bortzmeyer.org/7838.html me donne des idées.
Pour cela j'ai pensé créer un server avec socket.io sur le client qui recevra les header de forwarding de la part de Charlie ou de Tango. Tango peu très bien comme sur le schéma les envoyer directement au client qui pourrait enregistrer les serveurs de secours dans cookies.
Bon tout cela sent un peu le Gaz mais je me dis que ca pourrait fonctionner, peut-être y a t il des logiciels qui existent déjà et que je n'ai pas besoin de développer ma propre solution client basée sur socket.io, ou peut-être qu'il y a quelque chose de simple qui ne me saute pas aux yeux qui pourrait m'aider ?
# les problemes et quelques solutions.
Posté par NeoX . Évalué à 1.
tu peux avoir un DNS qui pointe vers plusieurs serveurs et donc avoir des arbres, qui cachent une foret de serveurs.
regarde un
dig google.frtu verras qu'il pointe vers plusieurs IPs
c'est ce que l'on appelle les frontaux, ceux qui accueillent reellement les demandent des utilisateurs.
ensuite ces frontaux ont des tests pour determiner qui est UP derriere eux (les backends), et envoyer selon certains algorithmes vers un backend ou un autre.
tu peux donc tres bien avoir
www.example.com A 1.1.1.1
www.example.com A 2.2.2.2
ensuite selon les puissances des machines :
ou bien avoir une double redondance (chaque frontal pouvant attaquer tous les backends)
c'est le principe du load balancing.
il faut evidemment eviter le single point de failure en mettre 2 ou plus frontaux.
evidemment ce n'est pas du "pair à pair", encore qu'il suffirait que les machines 3.3.3.3, 4.4.4.4, 5.5.5.5 et 6.6.6.6 se synchronisent entre elles…
[^] # Re: les problemes et quelques solutions.
Posté par n0wic . Évalué à -5.
Merci d'avoir pris le temps de me donner le principe de cette technique de loadbalancing par l'utilisation du DNS.
J'ai compris les deux architectures que tu proposes et j'aurai tendance à me diriger naturellement vers celle qui est redondée (2).
Si les machines que tu cites sont syncronisées alors on a de la redondance sur un niveau dans le premier cas et sur deux niveaux dans le deuxième cas.
- Du coup ca fait beaucoup d'espace disque utilisée dans l'achitecture 2.
Donc dans le cas d'une architecture distribuée entre tous les "backends" je devrai utiliser ton premier exemple.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.