Serveur High Availability : créer un load balancer avec une IP flottante

Après la réplication des bases de données et la réplication des fichiers, passons maintenant à la mise en place d’un load balancer avec keepalived et une IP flottante.

Voici le principe général de ce que nous cherchons à accomplir, avec une petite animation:

Voici ce dont vous avez besoin pour ce tutoriel:

• deux serveurs, VPS, ou Droplets si chez Digital Ocean;
• une IP flottante (gratuite chez DO).

Installation et paramétrage de keepalived

Keepalived est une application de routage qui permet de fournir un moyen simple et robuste de mettre en place des solutions de load balancing et de haute disponibilité sur des systèmes Linux. Cela se passe au niveau de la couche 4 du modèle OSI :

Concrètement, keepalived va vérifier toutes les quelques secondes que notre serveur de fichier est bien actif sur notre serveur MASTER. Si jamais le serveur est down, l’IP flottante sera assignée au serveur BACKUP. L’enregistrement DNS A du site doit pointer vers l’IP flottante. Cela permet de rediriger le trafic automatiquement et de manière transparente sur le serveur BACKUP.

Sur le serveur MASTER

1. On installe donc keepalived:

apt-get install keepalivedCode language: JavaScript (javascript)

et on édite sa configuration init:

nano /etc/init/keepalived.conf

On y ajoute :

description "load-balancing and high-availability service"

start on runlevel [2345]
stop on runlevel [!2345]

respawn
exec /usr/local/sbin/keepalived --dont-forkCode language: JavaScript (javascript)

2. On obtient l’adresse IP privée du serveur:

curl http://169.254.169.254/metadata/v1/interfaces/private/0/ipv4/address && echoCode language: JavaScript (javascript)

Résultat:

10.134.23.164Code language: CSS (css)

3. Passons maintenant à la configuration de keepalived :

nano /etc/keepalived/keepalived.conf

On y ajoute :

vrrp_script chk_nginx {
    script "pidof nginx"
    interval 2
}

vrrp_instance VI_1 {
    interface eth1
    state MASTER
    priority 200

    virtual_router_id 33
    unicast_src_ip 10.134.23.164
    unicast_peer {
        10.134.4.220
    }

    authentication {
        auth_type PASS
        auth_pass keepalivedpls!
    }

    track_script {
        chk_nginx
    }

    notify_master /etc/keepalived/master.sh
}Code language: PHP (php)

Notez les informations suivantes :

• on vérifie toutes les 2 secondes que nginx possède bien un PID.
• State : MASTER
• unicast_src_ip pointe vers 10.134.23.164 (master)
• unicast_peer pointe vers10.134.4.220 (backup)
• le mot de passe est keepalivedpls!

Sur le serveur BACKUP

Ce sont les mêmes étapes que sur le serveur MASTER, donc j’abrège un peu :

apt-get install keepalived
nano /etc/init/keepalived.confCode language: JavaScript (javascript)

ajoutez:

 description "load-balancing and high-availability service"

 start on runlevel [2345]
 stop on runlevel [!2345]

 respawn
 exec /usr/local/sbin/keepalived --dont-forkCode language: JavaScript (javascript)

Configuration :

nano /etc/init/keepalived.conf

Ajoutez:

vrrp_script chk_nginx {
    script "pidof nginx"
    interval 2
}

vrrp_instance VI_1 {
    interface eth1
    state BACKUP
    priority 100

    virtual_router_id 33
    unicast_src_ip 10.134.4.220
    unicast_peer {
        10.134.23.164
    }

    authentication {
        auth_type PASS
        auth_pass keepalivedpls!
    }

    track_script {
        chk_nginx
    }

    notify_master /etc/keepalived/master.sh
}Code language: PHP (php)

Notez ce qui change :

• State : BACKUP
• priority 100
• unicast_src_ip pointe vers 10.134.4.220 (backup)
• unicast_peer pointe vers 10.134.23.164 (master)

C’est assez parlant. La priorité est moindre car on préférera toujours le MASTER au BACKUP.

Gestion de l’IP flottante chez Digital Ocean

Digital Ocean (DO) offre une IP flottante, que l’on peut assigner à un VPS. Chez d’autres hébergeurs, c’est ce que l’on appelle une IP failover. Il suffit d’y associer un nom de domaine et ce domaine pourra être redirigé très facilement vers une autre machine. Cela permet de s’affranchir des délais de propagation DNS habituels.

1. On récupère donc le script assign-ip chez Digital Ocean, sur nos deux serveurs :

cd /usr/local/bin
curl -LO http://do.co/assign-ipCode language: JavaScript (javascript)

2. Ensuite, on se rend sur le site de Digital Ocean > API.

Cliquez sur le bouton Generate new token et donnez un nom facilement identifiable:

> HA-nginx

Cochez les cases Reading et Writing.

3. Sauvegardez la chaîne de caractères qui vous est présentée.

4. Vous devez connaître l’identifiant de vos droplets chez Digital Ocean :

droplet_ID master : ubuntu-master
droplet_ID backup : ubuntu-backup

et l’adresse de votre IP flottante :

floating IP : 138.xxx.xxx.177Code language: CSS (css)

5. Voici la syntaxe utilisée pour lancer le script assign-ip:

python /usr/local/bin/assign-ip floating_ip droplet_ID

6. On passe maintenant au script qui va attribuer l’IP flottante au bon serveur. On commence par créer le script :

nano /etc/keepalived/master.sh

Et on y met :

export DO_TOKEN=' CHAINE TROUVEE EN ETAPE 3'
IP='138.xxx.xxx.177'
ID=$(curl -s http://169.254.169.254/metadata/v1/id)
HAS_FLOATING_IP=$(curl -s http://169.254.169.254/metadata/v1/floating_ip/ipv4/active)

if [ $HAS_FLOATING_IP = "false" ]; then
    n=0
    while [ $n -lt 10 ]
    do
        python /usr/local/bin/assign-ip $IP $ID && break
        n=$((n+1))
        sleep 3
    done
fiCode language: JavaScript (javascript)

Vous avez à modifier :

• la chaîne de votre API token
• l’IP flottante

Rendez maintenant le script exécutable:

chmod +x /etc/keepalived/master.sh

7. Répétez l’étape 6 sur le serveur BACKUP : copie du script et droits d’exécution.

8. On lance le service keepalived, sur nos deux serveurs:

service keepalived start

9. Au niveau des enregistrements DNS du domaine, j’ai modifié cet enregistrement qui pointait vers le serveur MASTER:

A example.com	 directs to 104.xxx.xxx.133 1800Code language: CSS (css)

pour un pointage vers l’IP flottante, avec un délai beaucoup plus court :

A 	example.com 	directs to 138.xxx.xxx.177 10Code language: CSS (css)

Test de la configuration du load balancing

Il ne nous reste plus qu’à tester pour voir si l’IP est bien attribuée ! Je me suis créé un petit protocole de test pour voir ce qui se passe en temps réel.

1. on crée une page HTML sur MASTER :

export HOSTNAME=$(curl -s http://169.254.169.254/metadata/v1/hostname)
export PUBLIC_IPV4=$(curl -s http://169.254.169.254/metadata/v1/interfaces/public/0/ipv4/address)
echo Droplet: $HOSTNAME, IP Address: $PUBLIC_IPV4 > /var/www/html/load.htmlCode language: JavaScript (javascript)

2. on crée une page HTML sur BACKUP:

export HOSTNAME=$(curl -s http://169.254.169.254/metadata/v1/hostname)
export PUBLIC_IPV4=$(curl -s http://169.254.169.254/metadata/v1/interfaces/public/0/ipv4/address)
echo Droplet: $HOSTNAME, IP Address: $PUBLIC_IPV4 > /var/www/html/load.htmlCode language: JavaScript (javascript)

3. On lance une boucle dans un terminal qui va afficher le contenu de notre fichier toutes les secondes, en donnant le nom du droplet et son adresse IP :

while true; do curl https://www.example.com/load.html; sleep 1; doneCode language: JavaScript (javascript)

Ne fermez pas ce terminal.

4. Ouvrez une autre fenêtre de terminal sur le serveur MASTER et stoppez nginx:

service nginx stop

Au bout de quelques secondes, l’IP est assignée au serveur BACKUP, automatiquement et de manière transparente.

Bonus : pour savoir si un serveur possède une IP flottante, il suffit d’ouvrir un terminal sur ce serveur et lancer:

curl -s http://169.254.169.254/metadata/v1/floating_ip/ipv4/activeCode language: JavaScript (javascript)

Voilà, vous venez de créer un système simple mais efficace de load balancing entre deux VPS, qui attribue une IP flottante à l’un d’entre eux si jamais nginx est hors service.

Articles conseillés :

• Créer un serveur High Availability : la réplication des fichiers
• Créer un serveur High Availability : la réplication des bases de données
• MariaDB : résoudre l’erreur 1062 (duplicate entry for key PRIMARY) lors de la réplication des bases de données
• MariaDB : résoudre l’erreur “Column count of mysql.proc is wrong”
• MariaDB ne veut plus redémarrer : quelques solutions
• WordPress : changer le mot de passe d’un utilisateur depuis le serveur SQL