HAPROXY - 14. Keepalived & Haute Disponibilité (vip)

Haproxy c'est bien mais à lui seul il ne suffit pas pour faire de la hatue disponibilité. En effet Haproxy est un spof dans une infrastructure sauf si l'on doublonne ce service et que l'on fait répondre à une VIP. C'est là que KeepAlived intervient et forme un jolie duo avec notre loadbalancer.

Keepalived va nous permettre de switcher une vip suivant l'état du service haproxy.

Playlists:

A bientôt !!

[jean-christophebruneau]

Je me suis fait la série dans la journée et j'ai installé et configuré HAProxy pour distribuer un cluster docker swarm en moins de 2h (en lab pour le moment)
80% d'apprentissage pour 20% d'exécution. Tes présentations sont très biens pour aborder un sujet avant de plonger dans la doc

[Hujino]

Merci pour tes vidéos,

Concernant la priorité, c'est pas mieux de mettre une priorité + basse sur le backup ?

Du genre :

100 --> master
90 --> Backup

[papaamadoubabandiaye]

Bonjour @Xavki merci pour ce tuto
Mon problème c'est lorsqu'on utilise un DNS comment pourrait on assurer la redondance genre si on a deux serveurs Haproxy (il y'a un nom de domaine sur chaque Haproxy)
Si aussi on avait fait une VIP (IP sur une LS) qu'on donne un nom de domaine si la LS est down comment avoir une redondance à ce niveau aussi

[leberremikael]

Merci pour cette vidéo.
Je ne connaissais pas le principe qui se cachait derrière une VIP et keepalived. C'est top. J'ai même réussi à le faire dans docker en modifiant un peu ton script "deploy"

[nicolasbejean]

Merci, ça fonctionne du 1er coup avec 3 noeuds HaProxy sous Debian 11.2 :)

[bbilal]

merci j avance toujours avec toi
encore merci

[MehdiGUIRAUD]

Merci pour ces vidéos !
Une question ou à d'autres :
Du coup les deux machines doivent etre dans la DMZ.
Désolé d'avance si la question est obvious.

[karemsalhi]

Bonjour et merci, mais lorsque j'ai installé keepalived et haproxy comme équilibreurs de charges interne dans un cluster kubernetes des 3 Masters, donc lorsque un de 3 masters tombe en panne cv il continue de gerer le cluster kubernetes mais lorsque 2 masters tombent en panne et reste un seul master, il ne gere pas le cluster kubernetes

[Adt_Corneille]

belle vidéo chef!!!! ça m’ait très utile en ce moment !! cependant je comprend pas trop le principe du VIP... t'as fais aussi une sorte de routage que je n'ai pas compris... en fait dans mon architecture, nous avons une application web déployée en local et donc consultable par tous les users du LAN... a t- on besoin du VIP et/ou du mini routage que tu as effectué ? merci d'avance

[terraingradignan]

Salut, Dans ta conf HAproxy, as tu ajouté l'option "tranparent" derriere le bind pour que le service haproxy accepte de demarrer sur le slave si l'IP flottante (ecrite dans la conf haproxy) n est pas montée ?

[anastas]

Merci pour la vidéo :)
Comment peut-on faire, si haproxy se trouve dans 2 datacenter diffèrent. Ainsi le fqdn redirige vers le bon haproxy si un est down

[enigmaan]

salut @xavki, je me pose une question: est ce utile d'avoir keepalived si on lance haproxy via un container docker-compose qui a le tag restart: always

[christianpernot-brouard]

Donc j'ai fait la manip sur Debian :), j'imagine que tu fais sur Ubuntu ?

Je rajoute pour les personnes qui sont interessé par les différences
Sur Debian 9.0

les paquets nécessaire

# apt-get install keepalived libipset3 psmisc
# apt-get install ipvsadm
# modprobe ip_vs
# echo ip_vs >> /etc/modules

La Conf MASTER :

global_defs {
enable_script_security
}

vrrp_script check_haproxy {
script "/usr/bin/killall -0 haproxy"
interval 1
}
vrrp_instance VI_1 {
virtual_router_id 100
state MASTER
priority 101
#Interval Check
advert_int 1
#interface de synchro entre les haproxy
lvs_sync_daemon_interface ens18
interface ens18
#Authentification
authentication {
auth_type PASS
auth_pass 2021
}
#Address VIP
virtual_ipaddress {
192.168.1.100
192.168.1.101
}
track_script {
check_haproxy
}
}

La conf SLAVE

global_defs {
enable_script_security
}

vrrp_script check_haproxy {
script "/usr/bin/killall -0 haproxy"
interval 1
}
vrrp_instance VI_1 {
virtual_router_id 100
state BACKUP
priority 100
#Interval Check
advert_int 1
#interface de synchro entre les haproxy
lvs_sync_daemon_interface ens18
interface ens18
#Authentification
authentication {
auth_type PASS
auth_pass 2021
}
#Address VIP
virtual_ipaddress {
192.168.1.100
192.168.1.101
}
track_script {
check_haproxy
}
}

Attention,
sur Debian il faut que la priority du MASTER doit être supérier à celle du BACKUP
sur Debian lvs_sync_daemon_interface est deprecié mais fonctionne encore :)

Christian