DHCP : Synchronisation du failover de serveurs

Si l’on souhaite que la structure soit efficiente, on doit également synchroniser les deux configurations maitre et esclave pour qu’elles disposent des mêmes éléments. Cela peut être fait via la commande rsync et un script programmé en tâche planifiée via la crontab pour s’exécuter toutes les dix minutes:

*/10             *  *  *  * root       /root/sync-dhcp.sh

Le script doit disposer des instructions suivantes et permet alors de disposer, en cas de problème d’un backup de la configuration dans le répertoire /root/backup :

#! /bin/bash

rsync -Haurov --stats --delete --backup --backup-dir=/root/backup/

root@srvdhcp1:/etc/dhcp/dhcpd.conf /etc/dhcp/

service dhcpd force-reload

A ce stade, on peut alors démarrer le service dhcpd sur les deux machines maître et esclave en exécutant les commandes suivantes :

# systemctl start dhcpd

# systemctl enable dhcpd

Dans le cas où le pare-feu local est actif, on peut ajouter les règles suivantes :

# firewall-cmd --add-service=dhcp --permanent

# firewall-cmd --reload

On peut suivre l’évolution des journaux de logs, en temps réel et afficher les dernières lignes écrites dans le fichier /var/log/syslog (pour une distribution Debian) ou /var/log/messages (pour une distribution CentOS).

Lorsque les serveurs sont démarrés et configurés en failover, ils doivent établir une communication avec leur homologue DHCP afin de se synchroniser. Cela, avant même de commencer à distribuer des adresses aux clients. En effet, ils doivent connaître l’état de la base de données des baux et savoir si leur homologue est prêt à dialoguer.

Normalement, on doit voir des messages échangés avec succès entre les deux serveurs appariés : "Sent update done message to dhcp-failover" .lorsque la mise à jour est complète on obtient alors le message "Peer update complete". Après la synchronisation terminée, le serveur bascule en état normal, en changeant d’état du mode "recover" au mode "startup"  et pour finir au mode normal.

Les différents états d’un serveur opérationnel sont les suivants :

• STARTUP : état d’un serveur lorsqu’il démarre.
• RECOVER : état d’un serveur lorsqu’il attend l synchronisation.
• NORMAL : état d’un serveur opérationnel et synchronisé.
• COMMUNICATIONS-INTERRUPTED : état d’un serveur ayant eu une interruption de communication.
• PARTNER-DOWN : état permettant d’indiquer la perte de la paire en attendant la synchronisation.

On peut facilement vérifier que le service sur chacune des machines est opérationnel et qu’il n’y a aucune erreur lors du démarrage :

• Sur la machine DHCP maître :

• Sur la machine DHCP esclave :

Ainsi, depuis n’importe quel client Windows, on peut effectuer une demande d’adresse IP pour vérifier que le service DHCP est bien actif et fournira bien une adresse parmi celles de la plage réservée :

$ ipconfig /release (pour relacher le bail)

$ ipconfig /renew (pour renouveler le bail)

$ ipconfig /all (pour visualiser la nouvelle configuration TCP/IP)

Toutefois, on a commencé ce cours en utilisant majoritairement le système GNU/Linux. Alors, poursuivons avec un client Linux. On va créer une machine et lui attribuer une adresse IP depuis nos deux serveurs DHCP. Après son installation, notre client ne possède aucun réseau configuré :

Mais, une fois la configuration de notre carte hôte (ici, il s’agit de VirtualBox) en lui précisant l’adresse IP de notre serveur DHCP maître et de la plage d’adresses,, on constate qu’au démarrage du réseau sur le client, on dispose alors de la configuration réseau suivante :

L’attribution d’adresse a bien eu lieu et ce, avec celle que l’on souhaitait distribuer pour nos clients. On peut même renouveler le bail et s’assurer que l’on récupère toujours l’adresse souhaitée :

# dhclient

ATTENTION : on ne saurait trop insisté sur le fait que la configuration des deux côtés : maitre et esclave doit être exactement la même. C’est pourquoi il faut vraiment mettre en place le script décrit ci-dessus permettant de s’affranchir de cette synchronisation, de façon automatique.