Redondance de serveurs DHCP sous Linux

I. Présentation

Le service DHCP est très répandu dans les entreprises afin de distribuer une configuration réseau dynamiquement aux clients du réseau. Ce service permet une souplesse dans l’administration et la gestion des adresses IP au sein d’un réseau d’entreprise. Toutefois, il se peut que pour une raison ou pour une autre le serveur DHCP de votre entreprise tombe en panne, et là c’est le drame, vos clients n’obtiennent plus d’adresses IP dynamiquement et donc ne peuvent pas se connecter au réseau.

Pour parer à cela, on peut mettre en place de la redondance de serveurs DHCP. La redondance consiste à avoir deux serveurs DHCP, ainsi dans le cas où il y en a un qui tombe en panne, le second peut assurer la continuité de service.

La redondance de DHCP assure deux fonctionnalités :

- Répartition de la charge / loadbalancing : Les deux serveurs sont actifs, chacun d’entre eux gère une partie de la plage d’adresses devant être distribuées aux clients.

- Continuité de service / failover : Lorsqu’un serveur  tombe en panne, le second prend le relais est assure la continuité de service.

L’application DHCP utilisée est « isc-dhcp-server » sous Linux.

II. Préparation des serveurs

Avant de passer à la configuration, il faut installer les paquets nécessaires sur les serveurs Unix. Faisons une mise à jour des paquets puis on installe « isc-dhcp-server » via le paquet « dhcp3-server ».

apt-get update
apt-getinstall dhcp3-server

Le fichier de configuration du service DHCP est le suivant :

/etc/dhcp/dhcpd.conf

Renommez le fichier de configuration afin de le garder par sécurité. Nous partirons d’un fichier de configuration vierge :

mv /etc/dhcp/dhcpd.conf /etc/dhcp/dhcpd.conf.defaut
touch /etc/dhcp/dhcpd.conf

La base de données de gestion des adresses IP et des baux est située dans le fichier suivant :

/var/lib/dhcp/dhclient.leases

En ce qui concerne la gestion du service, pour le démarrer, le redémarrer et l’arrêter on procède comme ceci :

service isc-dhcp-serverstart|restart|stop

III. Architecture

Voici un schéma de l’architecture vous permettant d’avoir l’adresse IP de chacun des serveurs.

IV. La directive MCLT

Cette directive qui signifie « Max Client Lead Time » et qui est présente lors de la configuration du service DHCP en mode « failover » correspond au temps maximum, pendant lequel le serveur peer peut renouveler des requêtes après avoir perdu contact avec son partenaire.

V. La directive SPLIT

La directive « SPLIT » est également présente dans la configuration du service DHCP en mode « failover » tout comme la directive MCLT. Elle permet de « splitter » c'est-à-dire de diviser la plage d’adresses IP disponible en deux parties, afin de répartir la charge sur les deux serveurs.

Lorsque cette directive a la valeur « 128 », on part sur une répartition 50%/50%, c’est-à-dire que chaque serveur gère 50% de la plage d’adresses disponible.

VI. Configuration du serveur DHCP Master

Commençons par configurer le serveur DHCP Master, c'est-à-dire le serveur actif et maitre. Stoppez le service DHCP le temps de la configuration puis éditez le fichier de configuration vierge « dhcpd.conf » que nous avons créé.

Commencez par ajouter ceci à votre fichier de configuration :

# Paramétrage du failover du DHCP Master
failoverpeer "neoflow" {
primary            ; # Déclare ce serveur comme master.
address 192.168.1.201    ; # Adresse du serveur master.
port 520        ; # Port d'écoute du serveur master.
peeraddress 192.168.1.202 ; # Adresse du serveur slave.
peer port 520        ; # Port d'écoute du serveur slave.
max-response-delay 60 ; # Temps de non réponse du slave.
max-unacked-updates 10 ;
mclt 3600        ;
split 128        ; # Répartition des plages d'adresses.
load balance max seconds 3;
}

Le bloc de configuration ci-dessus, permet de configurer la paire de failover appelée « neoflow » (appelez la vôtre comme vous le souhaitez).

Le port d’écoute peut être changé comme vous le souhaitez mais vous devez être cohérent dans la façon dont vous allez configurer le second serveur selon le numéro de port indiqué dans la configuration du premier serveur.

La seule directive qui permet d’indiquer que ce serveur est le master/primaire est la présence de la ligne « primary » qui sera remplacée par « secondary » sur le serveur slave/secondaire. De plus, les directives « split » et « mclt » sont présentes uniquement sur le serveur maitre.

Ensuite, vous remarquerez qu’il manque une partie de la configuration où l’on indique les paramètres à distribuer aux postes clients. Je ne l’ai pas oubliée, nous allons justement s’y intéresser.

Mes postes clients se verront attribuer une adresse sur la plage d’adresses IP allant de 192.168.1.100 à 192.168.1.199 soit 100 adresses disponibles. La passerelle par défaut sera 192.168.1.1, le serveur DNS 8.8.8.8 et le bail quant à lui sera 6 heures pouvant être prolongé jusqu’à 10 heures si besoin.

subnet 192.168.1.0 netmask 255.255.255.0 {
pool{
failoverpeer "neoflow";            # Indique la configuration du failover
optionrouters 192.168.1.1;        # Passerelle par défaut
optiondomain-name-servers 8.8.8.8;    # Serveur DNS
range 192.168.1.100 192.168.1.199;    # Plage d'adresses IP
default-lease-time 21600 ;         # Bail de 6 heures par défaut
max-lease-time 36000 ;             # Bail pouvant aller jusqu'à 10 heures
}
}

Pour finir, on ajoute la directive « authoritative » en début de fichier pour indiquer que ce serveur DHCP fait autorité sur ce subnet :

authoritative;

En résumé vous devez obtenir ceci sur le serveur Master :

authoritative;

# Paramétrage du failover du DHCP Master
failoverpeer "neoflow" {
primary              ; # Déclare ce serveur comme master.
address 192.168.1.201      ; # Adresse du serveur master.
port 520          ; # Port d'écoute du serveur master.
peeraddress 192.168.1.202 ; # Adresse du serveur slave.
peer port 520          ; # Port d'écoute du serveur slave.
max-response-delay 60      ; # Temps de non réponse en secondes.
max-unacked-updates 10      ;
mclt 3600          ;
split 255          ; # Répartition des plages d'adresses.
load balance max seconds 3;
}

# Paramétrage de la configuration à distribuer aux postes clients
subnet 192.168.1.0 netmask 255.255.255.0 {
pool{
failoverpeer "neoflow";                # Indique la configuration du failover
optionrouters 192.168.1.1;        # Passerelle par défaut
optiondomain-name-servers 8.8.8.8 ;    # Serveur DNS
range 192.168.1.100 192.168.1.199;    # Plage d'adresses IP
default-lease-time 21600 ;         # Bail de 6 heures par défaut
max-lease-time 36000 ;         # Bail pouvant aller jusqu'à 10 heures
}
}

VII. Configuration du serveur DHCP Slave

Passons maintenant à la configuration du serveur DHCP Slave, on se basant sur la configuration du serveur DHCP Master. En effet, la configuration est quasiment identique sur les deux serveurs. Pensez à inverser les adresses IP indiquant l’adresse du serveur master et celle du slave, remplacer « primary » par « secondary » et supprimer les directives « mclt » et « split ». Pour le reste, rien ne change.

# Paramétrage du failover du DHCP Slave
failoverpeer "neoflow" {
secondary          ; # Déclare ce serveur comme slave.
address 192.168.1.202      ; # Adresse du serveur slave.
port 520          ; # Port d'écoute du serveur slave.
peeraddress 192.168.1.201 ; # Adresse du serveur master.
peer port 520          ; # Port d'écoute du serveur master.
max-response-delay 60      ; # Temps de non réponse en secondes.
max-unacked-updates 10      ; # Nombre de mises à jour avant de déclarer le pair en échec
load balance max seconds 3; # Durée max avant de décharger la requête vers le pair
}

# Paramétrage de la configuration à distribuer aux postes clients
subnet 192.168.1.0 netmask 255.255.255.0 {
pool{
failoverpeer "neoflow";                # Indique la configuration du failover
optionrouters 192.168.1.1;        # Passerelle par défaut
optiondomain-name-servers 8.8.8.8;    # Serveur DNS
range 192.168.1.100 192.168.1.199;    # Plage d'adresses IP
default-lease-time 21600 ;         # Bail de 6 heures par défaut
max-lease-time 36000 ;         # Bail pouvant aller jusqu'à 10 heures
}
}

VIII. Démarrez le service

Nous pouvons désormais passer le service en phase de test, démarrez le sur chacun de vos serveurs en commençant par le démarrer sur le serveur master puis sur le slave.

service isc-dhcp-server start

IX. Consultez les logs

Suivez l’évolution des logs en temps réel en affichant les dernières lignes écrites dans le fichier syslog grâce à la commande suivante :

tail –f /var/log/syslog

X. Que se passe-t-il une fois les serveurs démarrés ?

Quand un serveur configuré en mode failover démarre et qu’il n’a jamais communiqué avec sa paire, il doit établir une communication avec l’autre serveur afin de se synchroniser. Cela avant même de commencer à distribuer des adresses aux clients, pour la simple et bonne raison qu’il doit connaître l’état de la base de données des baux, mais aussi, pour savoir dans quel état est le serveur paire.

On peut voir que des messages sont envoyés et échangés avec succès entre les serveurs grâce à « Sent update done message to neoflow » et que la mise à jour est bien complète « Peer update completed. ». Une fois la synchronisation terminée, le serveur passe à l’état « normal » puisqu’il est opérationnel et qu’il communique avec sa paire, comme le montre le message « I move from recover-done to normal ».

XI. Les différents états

Je vous parlez précédemment de l’état « normal » qui est l’état dans lequel est un serveur opérationnel qui communique parfaitement avec sa paire. Toutefois, il existe d’autres états. Faisons le point.

- STARTUP : État d’un serveur lorsqu’il démarre
- RECOVER : État d’un serveur lorsqu’il attend la synchronisation
- NORMAL : État d’un serveur opérationnel et synchronisé
- COMMUNICATIONS-INTERRUPTED : État d’un serveur lorsqu’il y a une interruption dans la communication avec le second serveur
- PARTNER-DOWN : État qui permet d’indiquer la perte de la paire et donc  que le serveur va gérer seul le service DHCP. Cela en attendant que la paire revienne en ligne et se resynchronise.

XII. Demande de configuration avec un client

Depuis un client Windows, j’effectue une demande d’adresse pour vérifier que le service DHCP est bien actif :

ipconfig /release     # Relâcher le bail actuel
ipconfig /renew        # Renouveler le bail
ipconfig /all         # Voir la configuration TCP/IP détaillée

La configuration obtenue correspond bien à ce qu’on a défini dans le fichier dhcpd.conf.

On peut également voir dans les logs du serveur DHCP primaire la demande du client avec les différentes étapes « DHCP DISCOVER », « DHCP OFFER », « DHCP REQUEST » et « DHCP ACK ».

XIII. L’équilibrage de la base de données

Afin que l’équilibrage de la base de données des baux soit fait les serveurs doivent contrôler combien d’adresses ils possèdent chacun, pour cela il y a en quelque sort un compteur qui doit être à « 0 » pour un équilibrage parfait. Ceci est représenté par la valeur « lts » qui signifie « Lease To Send » c’est-à-dire « Baux à envoyer… à l’autre serveur ». Dans le cas où il y a un déséquilibrage le serveur qui a trop de baux doit en redonner à l’autre serveur.

Prenons un exemple pour illustrer et expliquer tout ça. Prenons nos deux serveurs DHCP configurés en mode "failover", actifs, et disposant d’une plage de 10 adresses. On effectue une demande avec 8 clients afin de bien remplir la base de données des baux... Les logs du DHCP primaire :

On peut voir que les serveurs DHCP donnent tous les deux des adresses IP aux clients et estiment que certaines adresses IP sont la propriété de l'autre serveur. Par exemple, le serveur primaire estime que l'adresse IP 192.168.1.100 appartient, est gérée, par le serveur secondaire : "lease owned by peer".

Cela s'explique par le fait qu'il doit y avoir un équilibre dans la répartition des adresses parce que les serveurs doivent gérer autant d'adresses l'un que l'autre (rappel : la valeur "lts" doit être à 0 pour un équilibre parfait).

Dans le cas d’une page de 10 adresses IP, on peut donc déterminer qu'ils gèrent chacun 5 adresses IP, visiblement le serveur secondaire gère les adresses IP de 192.168.1.100 à 192.168.1.104 et le primaire les adresses IP de 192.168.1.105 à 192.168.1.109.

Maintenant, passons sur cet état : Le serveur DHCP primaire est actif, le serveur DHCP secondaire est éteint.

Lorsque que l'on éteint le serveur DHCP secondaire et que l'on renouvelle la demande d'adresse IP avec plusieurs clients, il se peut que le serveur DHCP primaire ne dispose pas de suffisamment d’adresses IP, il va utiliser donc une ou plusieurs adresses IP du serveur secondaire et donc créer un déséquilibre dans la répartition de la plage d’adresses. Dans le cas de mon test, il lui « pique » l’adresse 192.168.1.102.

Désormais, le DHCP primaire est toujours actif, on remet en ligne le DHCP secondaire.

Le DHCP secondaire repasse en mode "normal", il discute avec le serveur DHCP primaire sur l'état actuel de la balance du pool c'est à dire l'équilibre dans la répartition des adresses. Étant donné que le serveur DHCP primaire à prit une adresse IP gérée par le serveur secondaire comme on l'a vu à l'étape précédente, le serveur DHCP secondaire se retrouve avec une adresse de moins.

La balance n'est plus équilibrée, le LTS est passé à "-1" au lieu de "0" pour indiquer qu'il y a une adresse de différence entre  les deux. Autrement dit, que le serveur primaire doit une adresse au serveur secondaire afin de retrouver un équilibre.

Note : Sur le serveur primaire, le LTS passe à « +1 » puisqu’il a une adresse de plus que le serveur secondaire. A l’inverse, sur le serveur secondaire il passe à « -1 » pour indiquer qu’il a une adresse de moins.

On se retrouve donc avec nos deux serveurs DHCP actifs…

Les deux serveurs sont actifs et on sait que le serveur DHCP secondaire gère une adresse de moins que le serveur DHCP primaire grâce à la valeur LTS. On va désormais refaire une demande d'adresse IP avec plusieurs clients pour voir le comportement… Dans les journaux du serveur secondaire, on peut voir qu’il « pique » l’adresse 192.168.1.9 au serveur primaire, ceci dans le but de rééquilibrer. On peut d’ailleurs voir que la valeur LTS est repassée à « 0 » suite à l’équilibrage :

Au début, les serveurs se partagent la moitié de la plage d’adresses en la divisant en deux mais, avec le temps, avec les pannes, on peut voir que les adresses peuvent être redistribuées entre les serveurs afin de retrouver un équilibre de 50/50.

XIV. Incohérences dans la base de données

Il est impératif de définir le même pool d’adresses sur les deux serveurs sinon cela créera des incohérences dans la base de données. Si vous ne configurez pas de façon identique les pools, vous obtiendrez un message de ce type pour vous l’indiquer :

Got POOLREQ, answering negatively ! Peer may be out of leases or database inconsistent

La base de données est incohérente car des baux sont en dehors de la plage d’adresses définies sur le serveur primaire.

Le tutoriel est désormais terminé, n'hésitez pas à donner votre avis, à noter l'article et à utiliser notre forum si besoin.

Florian BURNEL Co-founder of IT-Connect

Ingénieur système et réseau, cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture.

See Full Bio