Répartition de charges avec LVS & KeepAlived

Cet article est une amélioration du précédent article sur LVS, nous voulons mettre en place un second LVS en Fail Over pour assurer une continuité de service. Ainsi même lorsque notre LVS principal tombe en panne le deuxième prend le relais et notre cluster web est toujours accessible. Le Fail Over sera assuré par KeepAlived.

I°) Préparation

Nous aurons besoin de deux serveurs web, de deux serveurs LVS avec KeepAlived.

On a également modifié l’adressage IP de la DMZ (tous les serveurs se trouve dans la DMZ).

 

Rôle

Hostname

@IP

LVS MASTER

lvsdir

172.17.0.2

LVS BACKUP

light

172.17.0.3

WEB N°1

lampe

172.17.0.4

WEB N°2

edison

172.17.0.5

CLUSTER WEB

172.17.0.6

Tout d’abord on vérifie les configurations de nos serveurs WEB, ils doivent être configurés comme dans cet article.

Remarque : Il faut aussi configurer correctement le pare-feu !

II°) LVS/KeepAlived

On commence par installer le paquet KeepAlived sur les deux serveurs LVS (LVS, (ipvsadm) est compris dans le paquet KeepAlived), puis, sur le serveur qui sera maitre, on va créer le fichier /etc/keepalived/keepalived.conf.

Dans ce fichier on commence par définir le groupe de serveur LVS (vrrp_sync_groupe) puis on définit les instances à surveiller (group { web1 }).

A la suite on définit l’instance que l’on va surveiller (vrrp_instance), on donne le rôle de notre serveur au sein de cette instance (state MASTER). L’option virtual_router_id est un identifiant pour l’instance, cet identifiant est arbitraire et sert à différencier les différentes instances.

On indique l’interface surveillée et support de l’IP virtuelle (interface enp2s0), la priorité du serveur dans le cluster (priority 100), le temps entre 2 messages de test entre les serveurs (advert_int 1) ainsi que la synchronisation de l’état des LVS via l’interface enp2s0 (lvs_sync_daemon_interface enp2s0).

Après nous avons les directives pour l’authentification des 2 serveurs, ils sont authentifiés par un mot de passe (auth_type PASS) et le mot de passe est « Ligfy! » (auth_pass Ligfy!). Puis on définis l’adresse IP virtuelle (virtual_ipaddress { 172.17.0.6/24 })

Toujours dans le même fichier, nous allons maintenant définir le serveur virtuel et les serveurs réels. La définition du virtuel se fait en précisant l’adresse IP virtuel et le port (virtual_server 172.17.0.6 80).

Option

Valeur

Rôle

delay_loop

6

Délais entre tests de présence

lb_algo rr

rr

Algorithme de Load Balancing (rr = round-robin)

lb_kind

DR

Façon d’accéder aux serveurs (DR = Direct Routing)

protocol

TCP

Protocole utilisé

real_server

172.17.0.4 80

Définition du serveur réel (@IP port)

weight

1

Le poids du serveur

TCP_CHECK

Test de vie

connect_port

80

Port ou le test est effectué

connect_timeout

3

Délais avant de considérer comme « mort »

On a finit d’écrire dans le fichier de configuration, on le sauvegarde et on redémarre le service KeepAlived (service keepalived restart), on vérifie la configuration en vérifiant que nous avons l’adresse virtuel (ip a), on vérifie la définition des serveurs virtuel (ipvsadm -l) et les logs. Les logs de KeepAlived se trouve dans le fichier /var/log/messages.

On fait le même fichier sur le deuxième serveur LVS, en adaptant la configuration (adpter les interfaces, etc.), et en changeant l’option state ainsi que la priorité.

On commence par vérifier que tout fonctionne, les même vérification que sur le serveur maitre, on vérifie que l’on arrive à joindre le cluster de serveur web.

Quand tout fonctionne on coupe le serveur maitre, tout en regardant les logs du serveur secondaire, nous voyons bien que le serveur backup passe maitre lorsque le maitre est coupé.

Tout est en place, maintenant nous pouvons tester d’autres algorithmes de Load Balancing, changer les priorités, etc.

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.