Configuration Serveur · 6 min read · Oct 08, 2025

Le Cluster Web Parfait Équilibré et Haute Disponibilité Avec 2 Serveurs Exécutant Xen Sur Ubuntu 8.04 Hardy Heron - Page 6

12. Configuration des équilibreurs de charge (lb1, lb2)

12.1 Activer IPVS Sur Les Équilibreurs de Charge

Tout d’abord, nous devons activer IPVS sur nos équilibreurs de charge. IPVS (IP Virtual Server) implémente l’équilibrage de charge au niveau de la couche de transport à l’intérieur du noyau Linux, ce qu’on appelle le commutateur de couche 4.

echo ip_vs_dh >> /etc/modules
echo ip_vs_ftp >> /etc/modules
echo ip_vs >> /etc/modules
echo ip_vs_lblc >> /etc/modules
echo ip_vs_lblcr >> /etc/modules
echo ip_vs_lc >> /etc/modules
echo ip_vs_nq >> /etc/modules
echo ip_vs_rr >> /etc/modules
echo ip_vs_sed >> /etc/modules
echo ip_vs_sh >> /etc/modules
echo ip_vs_wlc >> /etc/modules
echo ip_vs_wrr >> /etc/modules

Ensuite, nous faisons ceci :

modprobe ip_vs_dh
modprobe ip_vs_ftp
modprobe ip_vs
modprobe ip_vs_lblc
modprobe ip_vs_lblcr
modprobe ip_vs_lc
modprobe ip_vs_nq
modprobe ip_vs_rr
modprobe ip_vs_sed
modprobe ip_vs_sh
modprobe ip_vs_wlc
modprobe ip_vs_wrr

12.2 Installer Ultra Monkey (paquets) Sur Les Équilibreurs de Charge

Installez Ultra Monkey (paquets) sur les équilibreurs de charge en procédant comme suit :

apt-get install ipvsadm ldirectord heartbeat

12.3 Activer le Transfert de Paquets Sur Les Équilibreurs de Charge

Les équilibreurs de charge doivent être capables de router le trafic vers les nœuds Apache. Par conséquent, nous devons activer le transfert de paquets sur les équilibreurs de charge. Ajoutez les lignes suivantes à /etc/sysctl.conf :

vi /etc/sysctl.conf

# Active le transfert de paquets
net.ipv4.ip_forward = 1

Ensuite, faites ceci :

sysctl -p

12.4 Configurer heartbeat Et ldirectord

Maintenant, nous devons créer trois fichiers de configuration pour heartbeat (attention aux espaces et aux tabulations si vous éditez dans certains éditeurs de texte, ldirectord est très exigeant !) :

sur lb1 et lb2

vi /etc/ha.d/ha.cf

logfacility local0
bcast eth0 # Linux
mcast eth0 225.0.0.1 694 1 0
auto_failback on
node lb1.example.com
node lb2.example.com
respawn hacluster /usr/lib/heartbeat/ipfail
apiauth ipfail gid=haclient uid=hacluster

Important : En tant que noms de nœuds, nous devons utiliser la sortie des deux :

uname -n

vi /etc/ha.d/haresources

lb1.example.com \
 ldirectord::ldirectord.cf \
 LVSSyncDaemonSwap::master \
 IPaddr2::192.168.1.106/24/eth0/192.168.1.255 \
 IPaddr2::192.168.1.107/24/eth0/192.168.1.255

Les IP 192.168.1.106 et 107 seront utilisées plus tard pour les sites web (example.com et yoursite.com).

Ce fichier doit être identique sur les deux nœuds, peu importe si vous commencez à créer le fichier sur lb1 ou lb2 !

vi /etc/ha.d/authkeys

auth 3 3 md5 somerandomstring

somerandomstring est un mot de passe que les deux démons heartbeat sur lb1 et lb2 utilisent pour s’authentifier l’un l’autre. Utilisez votre propre chaîne ici. Vous avez le choix entre trois mécanismes d’authentification. J’utilise md5 car je crois que c’est le plus sécurisé.

/etc/ha.d/authkeys doit être lisible uniquement par root, donc nous faisons ceci :

chmod 600 /etc/ha.d/authkeys

ldirectord est l’équilibreur de charge réel. Nous allons configurer nos deux équilibreurs de charge (lb1.example.com et lb2.example.com) dans une configuration active/passive, ce qui signifie que nous avons un équilibreur de charge actif, et l’autre est un standby chaud et devient actif si le premier échoue. Pour que cela fonctionne, nous devons créer le fichier de configuration ldirectord /etc/ha.d/ldirectord.cf qui doit à nouveau être identique sur lb1 et lb2.

vi /etc/ha.d/ldirectord.cf

checktimeout=5
checkinterval=5
autoreload=no
logfile="/var/log/ldirectord.log"
quiescent=no
#fork=yes

#POUR SMTP
virtual=192.168.1.106:25
        real=192.168.1.104:25 gate
        fallback=192.168.1.105:25 gate
        service=none
        scheduler=wlc
        protocol=tcp
        checktype=connect
virtual=192.168.1.107:25
        real=192.168.1.104:25 gate
        fallback=192.168.1.105:25 gate
        service=none
        scheduler=wlc
        protocol=tcp
        checktype=connect

#POUR DNS - CONNECT NE FONCTIONNE PAS, DOIT ÊTRE PATCHÉ MAIS PING EST OK
virtual=192.168.1.106:53
        real=192.168.1.104:53 gate
        fallback=192.168.1.105:53 gate
        service=none
        scheduler=wlc
        checktype=ping
        protocol=udp
virtual=192.168.1.106:53
        real=192.168.1.104:53 gate
        fallback=192.168.1.105:53 gate
        service=dns
        scheduler=wlc
        checktype=ping
        protocol=tcp
#POUR HTTP
virtual=192.168.1.106:80
        real=192.168.1.104:80 gate
        real=192.168.1.105:80 gate
        service=http
        request="ldirectord.php"
        receive="Connecté à MySQL"
        scheduler=wlc
        protocol=tcp
        checktype=negotiate
        persistent=28800
virtual=192.168.1.107:80
        real=192.168.1.104:80 gate
        real=192.168.1.105:80 gate
        service=http
        request="ldirectord.php"
        receive="Connecté à MySQL"
        scheduler=wlc
        protocol=tcp
        checktype=negotiate
        persistent=28800

#POUR WEBMAIL
virtual=192.168.1.106:81
        real=192.168.1.104:81 gate
        fallback=192.168.1.105:81 gate
        service=http
        request="ldirectord.php"
        receive="Connecté à MySQL"
        scheduler=wlc
        protocol=tcp
        checktype=negotiate
virtual=192.168.1.107:81
        real=192.168.1.104:81 gate
        fallback=192.168.1.105:81 gate
        service=http
        request="ldirectord.php"
        receive="Connecté à MySQL"
        scheduler=wlc
        protocol=tcp
        checktype=negotiate
#POUR POP3
virtual=192.168.1.106:110
        real=192.168.1.104:110 gate
        fallback=192.168.1.105:110 gate
        service=pop
        checktype = connect
        scheduler=wlc
        protocol=tcp
#POUR IMAP
virtual=192.168.1.106:143
        real=192.168.1.104:143 gate
        fallback=192.168.1.105:143 gate
        service=imap
        scheduler=wlc
        protocol=tcp
#POUR HTTPS
###Décommentez cette partie si vous allez utiliser HTTPS
#virtual=192.168.1.106:443
#        real=192.168.1.104:443 gate
#        real=192.168.1.105:443 gate 2
#        service=http
#        request="ldirectord.php"
#        receive="Connecté à MySQL"
#        scheduler=wlc
#        protocol=tcp
#        checktype=negotiate
#        persistent=28800
#
#virtual=192.168.1.107:443
#        real=192.168.1.104:443 gate
#        real=192.168.1.105:443 gate 2
#        service=http
#        request="ldirector.html"
#        receive="Page de Test"
#        scheduler=wlc
#        protocol=tcp
#        checktype=negotiate
#        persistent=28800
#POUR IMAP SSL
virtual=192.168.1.106:993
        real=192.168.1.104:993 gate
        fallback=192.168.1.105:993 gate
        service=imaps
        scheduler=wlc
        protocol=tcp
#POUR POP3 SSL
virtual=192.168.1.106:995
        real=192.168.1.104:995 gate
        fallback=192.168.1.105:995 gate
        service=pops
        checktype = ping
        scheduler=wlc
        protocol=tcp
#POUR MONIT SURVEILLANCE #1
virtual=192.168.1.106:10001
        real=192.168.1.104:10001 gate
        checktype = on
#POUR MONIT SURVEILLANCE #2
virtual=192.168.1.106:20001
        real=192.168.1.105:20001 gate
        checktype = on

virtual est l’IP virtuelle des services (par exemple 192.168.1.106 et 107)

real sont les IP des serveurs réels dans le cluster (192.168.1.104 et 105)

fallback est le serveur de secours. Si l’IP réelle échoue, les requêtes sont transférées à l’IP de secours mais elles ne sont pas équilibrées.

Cette configuration est basée sur mon expérience personnelle. Certains services sont équilibrés, d’autres ne le sont pas. Tout ce qui concerne le courrier n’est pas équilibré. Vous ne voulez pas qu’un message arrive sur le premier serveur et le second sur l’autre (à moins que vous n’ayez un stockage partagé). Si vous n’avez pas un trafic de courrier très élevé, il n’est pas nécessaire d’équilibrer le courrier (mais il est toujours hautement disponible), c’est la même chose pour DNS. Plus tard, nous synchroniserons les messages sur le deuxième serveur afin d’avoir une sauvegarde en cas d’échec du premier serveur.

À propos du port 81. Nous l’utiliserons pour le webmail. Je l’utilise également pour l’administration de notre site web de commerce électronique en raison du téléchargement d’images. Plus tard, nous mettrons en place rsync de web1.example.com à web2.example.com mais pas dans l’autre sens. Fondamentalement, vous ne voulez pas télécharger un fichier sur web2.example.com (à moins que vous n’utilisiez un stockage partagé).

Si vous souhaitez obtenir plus d’informations sur le sujet, recherchez “ldirectord man”.

Ensuite, nous créons les liens de démarrage du système pour heartbeat et supprimons ceux de ldirectord car ldirectord sera démarré par le démon heartbeat :

update-rc.d -f ldirectord remove

Enfin, nous démarrons heartbeat (et avec lui ldirectord) :

/etc/init.d/ldirectord stop
/etc/init.d/heartbeat start

12.5 Tester les équilibreurs de charge

Vérifions si les deux équilibreurs de charge fonctionnent comme prévu :

ip addr sh eth0

L’équilibreur de charge actif lb1.example.com devrait lister les adresses IP virtuelles (192.168.1.106 et 192.168.1.107) :

2: eth0:  mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.102/24 brd 192.168.1.255 scope global eth0
    inet 192.168.1.106/24 brd 192.168.1.255 scope global eth0
    inet 192.168.1.107/24 brd 192.168.1.255 scope global secondary eth0

Le hot-standby (lb2.example.com) devrait afficher quelque chose comme ceci :

2: eth0:  mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:0c:29:34:d7:7e brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.103/24 brd 192.168.1.255 scope global eth0

Essayez maintenant :

ldirectord ldirectord.cf status

Sortie sur l’équilibreur de charge actif (lb1) :

ldirectord pour /etc/ha.d/ldirectord.cf fonctionne avec pid: 5321

Sortie sur l’équilibreur de charge hot standby (lb2) :

ldirectord est arrêté pour /etc/ha.d/ldirectord.cf

Vérifions maintenant si les ports sont redirigés correctement :

ipvsadm -L -n | grep :80

Vous devriez voir quelque chose comme ceci sur lb1.example.com :

  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.1.106:80 wlc
  -> 192.168.1.104:80               Route   1      0          0         
  -> 192.168.1.105:80               Route   0      0          0
TCP  192.168.1.107:80 wlc
  -> 192.168.1.104:80               Route   1      0          0         
  -> 192.168.1.105:80               Route   0      0          0

Et rien sur lb2.example.com.

Un dernier test :

/etc/ha.d/resource.d/LVSSyncDaemonSwap master status

Sortie sur l’équilibreur de charge actif :

master running (ipvs_syncmaster pid: 5470)

Sortie sur le hot-standby :

master stopped

12.6 Tester le basculement des équilibreurs de charge

lb1.example.com

/etc/init.d/heartbeat stop

La commande ipvsadm :

ipvsadm -L -n | grep :80

devrait ne rien afficher.

Sur lb2.example.com

ipvsadm -L -n | grep :80

et vous devriez voir ce qui suit :

  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.1.106:80 wlc
  -> 192.168.1.104:80               Route   1      0          0         
  -> 192.168.1.105:80               Route   0      0          0
TCP  192.168.1.107:80 wlc
  -> 192.168.1.104:80               Route   1      0          0         
  -> 192.168.1.105:80               Route   0      0          0

Redémarrez le service heartbeat sur lb1.example.com :

/etc/init.d/heartbeat start

Si vous réessayez la commande ipvsadm sur les deux, vous verrez que lb1.example.com est maintenant actif tandis que lb2.example.com est revenu en mode standby.

Si votre test s’est bien passé, vous pouvez continuer.

Share: X/Twitter LinkedIn
#Configuration Serveur

Recevez de nouveaux articles dans votre boîte de réception.

Aucun spam. Désabonnez-vous à tout moment.