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.
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 ».
Le fichier de configuration du service DHCP est le suivant :
Renommez le fichier de configuration afin de le garder par sécurité. Nous partirons d’un fichier de configuration vierge :
La base de données de gestion des adresses IP et des baux est située dans le fichier suivant :
En ce qui concerne la gestion du service, pour le démarrer, le redémarrer et l’arrêter on procède comme ceci :
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 :
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 de192.168.1.100 à 192.168.1.199 soit 100 adresses disponibles. La passerelle par défautsera 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.
Pour finir, on ajoute la directive « authoritative » en début de fichier pour indiquer que ce serveur DHCP fait autorité sur ce subnet :
En résumé vous devez obtenir ceci sur le serveur Master :
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.
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.
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 :
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.
- 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 serviceDHCP est bien actif :
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 DHCPconfiguré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 serveurDHCP 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.
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.
Aucun commentaire :
Enregistrer un commentaire