Je suis étudiant en informatique et dans le cadre d'un projet tutoré sur la haute disponibilité et la répartition de charge j'ai été amené à déployer un load balanceur sous LVS (CentOS 5).
Mon répartiteur de charge principal ainsi que celui de backup fonctionnent mais il me reste quelques soucis à régler :
1/ Lorsque j'arrête un serveur réel celui-ci est naturellement retiré de la liste des serveurs disponibles mais lorsqu'il est à nouveau en marche, il ne retrouve pas sa place dans la liste des serveurs disponibles, une idée du problème ?!?!
2/ Mon infrastructure doit gérer le protocole HTTPS, j'ai donc utilisé le système de firewall marks couplé à la persistance et ça marche bien. Cela dit, je me demande s'il existe une solution n'utilisant pas la persistance ?
J'ai pensé à centraliser Apache et les certificats sur un NFS et de n'activer que les firewall marks mais ça ne fonctionne pas, j'ai une erreur avec la fonction HELLO lors de la négociation.
Quelqu'un peut-t-il m'expliquer le fonctionnement exacte du mod_ssl ? Ca exploite des données de la machine en plus des certificats pour générer le chiffrement ?
Le seul avantage de centraliser le tout sur NFS est de gérer les sessions PHP sans avoir recours à la persistance.
3/ Dans piranha, il est possible d'activer le contrôle de la charge des serveurs réels (load avrage), quelles sont les répercutions de cela sur les algorithmes de répartition ? Le load balanceur choisira le serveur le moins chargé ou il retirera de la liste le serveur débordé ? J'aimerais comprendre le mécanisme.
Voici mon fichier lvs.cf :
serial_no = 279
primary = 192.168.0.1
service = lvs
backup_active = 1
backup = 192.168.0.2
heartbeat = 1
heartbeat_port = 539
keepalive = 6
deadtime = 18
network = nat
nat_router = 192.168.1.200 eth1:1
nat_nmask = 255.255.255.0
debug_level = NONE
monitor_links = 0
syncdaemon = 0
virtual HTTP {
active = 1
address = 192.168.0.100 eth0:1
vip_nmask = 255.255.255.0
fwmark = 80
port = 80
persistent = 10
send = "GET / HTTP/1.0\r\n\r\n"
expect = "HTTP"
use_regex = 0
load_monitor = none
scheduler = rr
protocol = tcp
timeout = 6
reentry = 15
quiesce_server = 0
server web2 {
address = 192.168.1.2
active = 1
port = 80
weight = 1
}
server web1 {
address = 192.168.1.1
active = 1
port = 80
weight = 1
}
}
virtual HTTPS {
active = 1
address = 192.168.0.100 eth0:2
vip_nmask = 255.255.255.0
fwmark = 80
port = 443
send = "GET / HTTP/1.0\r\n\r\n"
expect = "HTTP"
use_regex = 0
load_monitor = none
scheduler = rr
protocol = tcp
timeout = 6
reentry = 15
quiesce_server = 0
server web1 {
address = 192.168.1.1
active = 1
port = 443
weight = 1
}
server web2 {
address = 192.168.1.2
active = 1
port = 443
weight = 1
}
}
Je vous remercie !
# HA
Posté par Fabien . Évalué à 2.
Stocker des sessions PHP sur disque est contre-performant et s'oppose au principe de HA/répartition de charge. Tu peux utiliser une base de données, ceci réglera ton problème de répartition mais pourra te mener à de plus graves soucis : plus ton trafic augmentera, plus la base de données sera sollicitée, et c'est sûrement l'un des points les plus difficiles à solutionner dans une archi HA. Je te conseille de regarder du coté de memcache et php5-memcache. Tu peux en 2 lignes de conf utiliser un stockage memcache (redondé ou pas) pour les sessions.
Pour le load balancing ssl sans persistance, il n'existe qu'une seule solution : utiliser des certificats ssl multi-domaines (plusieurs SubjectAltName).
Pour ton souci de load-balancing, je te conseille de regarder Haproxy. Tu assures ça redondance avec heartbeat ou ucarp.
[^] # Re: HA
Posté par HAVOC . Évalué à 1.
Effectivement, là je suis entrain d'étudier une solution à base de Memcached pour centraliser les sessions PHP, le NFS déjà déployé ne servira plus qu'à centraliser les fichiers du site.
Il y a aussi Sharedance qui semble être une des meilleures solutions mais qui souffre d'un manque de documentation.
Pour les certificats multi-domaines je ne savais pas que ça existait, je vais étudier cette piste.
Pour ce qui est de HaProxy, je compte bien le rester... d'ailleurs dis-moi, si j'ai bien compris HaProxy fait du loadbalancing en jouant le rôle d'un reverse-proxy, c'est bien ça ?
Merci !
[^] # Re: HA
Posté par Fabien . Évalué à 2.
Haproxy n'est pas un reverse proxy, c'est un load balancer tcp/http.
Pour faire du reverse proxy, j'aime bien nginx.
Et si tu as du temps pour tester d'autres solutions, tu peux t'intéresser à OpenBSD.
En plus de prendre très au sérieux la sécurité informatique, cet OS dispose d'outils réseau performants :
- interface trunk pour agréger tes interfaces réseau permettant de redonder les switchs
- interface carp permettant des bascules automatiques (ou manuelles) avec une configuration simple mais puissante
- interface pfsync (lié au parefeu PF) pour synchroniser les tables d'état
....
Des équivalents existent sous linux, mais je les trouve trop "compliquées" par rapport à celle-ci.
Par exemple, tu peux faire un load-balancer IP avec 2 OpenBSD, leur parefeu PF+pfsync et relayd qui surveille les backends.
[^] # Re: HA
Posté par HAVOC . Évalué à 1.
1000 merci !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.