Cluster à basculement de serveurs DHCP sous Windows Server 2019

I. Présentation

Dans ce tutoriel, nous allons voir comment configurer un cluster à basculement de serveurs DHCP sous Windows Server 2019. On peut parler aussi de la mise en place d'un DHCP failover sous Windows Server 2019.

- Tutoriel disponible au format vidéo :

Depuis Windows Server 2012, Microsoft permet aux administrateurs système de configurer un cluster à basculement DHCP facilement sans passer par la mise en place d'un cluster à basculement en tant que tel : le paramétrage est grandement simplifié.

Il y a deux modes possibles :

- Serveur de secours (actif/passif) : Un serveur actif, un second serveur de secours qui s'active en cas de panne du principal

- Équilibrage de charge (actif/actif) : Les deux serveurs sont actifs et une répartition de charge est effectuée (pas forcément à 50/50, tout dépend de la configuration).

Le service DHCP est critique en entreprise : s'il n'est pas redondé et qu'il est hors service suite à une panne, les postes clients en adresse IP dynamique ne seront pas capables de se connecter au réseau local. À l'exception de ceux qui sont déjà connectés au réseau et qui ont un bail valide / en cours.

II. Description du lab

Pour ce tutoriel et la démonstration, je me suis appuyé sur trois machines virtuelles dont deux serveurs sous Windows Server 2019 :

• SRV-ADDS-01
  • Rôles : contrôleur de domaine it-connect.local et serveur DHCP avec l'étendue "LAN_Virtuel" configurée, ce sera le serveur DHCP source qui sera utilisé pour mettre en place le basculement
  • Adresse IP : 192.168.1.50
• SRV-WS-01
  • Rôle : serveur DHCP, installé, mais sans aucune configuration : futur partenaire
  • Adresse IP : 192.168.1.51
• PC-W10
  • Poste client membre du domaine qui sert de client DHCP pour tester la configuration
  • Adresse IP : dynamique

Passons à la suite.

III. Mise en place du rôle DHCP

Ce tutoriel s'inscrit dans la continuité du précédent où l'on avait vu comment mettre en place un serveur DHCP sous Windows Server 2019. Retrouvez ce tutoriel à l'adresse suivante et la vidéo associée ci-dessous :

Tutoriel - Installation d'un serveur DHCP sous Windows Server 2019

À partir du moment où vous avez un serveur DHCP avec une étendue configurée et un deuxième serveur DHCP avec le rôle installé, mais vierge de configuration (bien que ce ne soit pas indispensable qu'il soit vierge), vous pouvez continuer.

IV. Configuration du cluster à basculement DHCP

La configuration s'effectue depuis le serveur SRV-ADDS-01 puisqu'il gère actuellement l'étendue DHCP "LAN_Virtuel".

Remarque : avant de mettre en place le basculement, configurez votre étendue, notamment les options d'étendue et les réservations. Ces informations seront répliquées lors de la synchronisation initiale de l'étendue vers le partenaire.

Ouvrez la console DHCP et effectuez un clic droit sur l'étendue, puis cliquez sur "Configurer un basculement" : un assistant va démarrer...

Nous avons la possibilité de configurer le basculement pour une ou plusieurs étendues. Dans notre cas, il y a en a qu'une seule donc on laisse l'option "Sélectionner tout".

Il faut que l'on spécifie le serveur DHCP à utiliser pour le basculement : l'objectif c'est de sélectionner le serveur SRV-WS-01. Cliquez sur "Ajouter un serveur" puis cochez "Ce serveur DHCP autorisé" (c'est-à-dire autorisé dans l'Active Directory) et sélectionnez le serveur.

Le serveur est bien sélectionné, on continue.

Voici l'étape de configuration du mode de fonctionnement du cluster à basculement DHCP. Voici des informations sur les paramètres :

• Nom de la relation : Donnez un nom à la relation entre ces deux serveurs, au choix ! Sachant qu'une relation est réutilisable.

Ensuite, nous avons le paramètre MCLT qui est précieux.

• MCLT

Ce paramètre spécifie la durée pendant laquelle un bail DHCP peut être renouvelé par l'un des partenaires de basculement sans contacter l'autre partenaire : ce qui sera le cas lors d'une panne, par exemple. Il a un deuxième rôle puisqu'il spécifie également la durée pendant laquelle le serveur actif restera dans l'état "partenaire en panne" avant de prendre le contrôle de la totalité de la plage d'adresses IP de l'étendue : très intéressant pour assurer une continuité de service si la panne dure.

Plus d'informations sur le fonctionnement de MCLT : IETF - MCLT

• Mode

Il faut choisir un mode, dans notre cas le choix "Équilibrage de charge" (load balancing), les deux serveurs seront actifs. Il faut définir le pourcentage de cet équilibrage de charge : 50/50, ou 70/30, par exemple. Cette valeur correspond au pourcentage d'adresses IP de la plage de l'étendue que devra gérer chaque serveur. Par exemple, si dans l'étendue la plage DHCP est de 10 adresses IP et que la répartition est de 50/50, chaque serveur va gérer 5 adresses IP.

Le mode "Serveur de secours" (Failover) sert à mettre en place une configuration actif/passif. Ensuite, on choisit le mode "Veille" : le serveur passif distribuera des adresses IP uniquement quand le partenaire sera HS.

Il faut en complément préciser le pourcentage d'adresses IP réservées au sein de la plage pour ce serveur de secours. Ainsi, en cas de basculement si le serveur principal est hors service, le serveur de secours est assuré d'avoir X% d'adresses IP disponibles et attribuables.

• Intervalle de basculement d'état

Si l'option est activée, elle permet d'indiquer au bout de combien de temps on considère que le partenaire est hors service si la communication avec lui est perdue. Si l'option n'est pas activée, le serveur DHCP va considérer que la communication est interrompue sans savoir réellement pour quelle raison avec son partenaire, et j'ai constaté qu'il devient actif pour assurer la continuité (sans délai pour le coup).

• Activer l'authentification du message

Saisissez un "Secret partagé" complexe qui sera utilisé pour chiffrer les échanges entre les deux serveurs DHCP du cluster. De cette façon, la synchronisation de la configuration entre les serveurs DHCP ne transitera pas en clair sur le réseau.

Poursuivez jusqu'à la fin : la configuration va se mettre en place et la progression s'affichera à l'écran. Si vous obtenez "Réussite de la configuration du basculement", c'est tout bon !

La configuration va permettre de synchroniser différents éléments entre les deux serveurs : baux DHCP, options de l'étendue, réservations DHCP. Néanmoins, cette synchronisation n'est pas automatique sauf pour la base de données des baux DHCP !

En faisant un clic droit sur l'étendue, on obtient l'option "Répliquer l'étendue" : une opération à réaliser lorsque vous modifiez la configuration de l'étendue sur un serveur DHCP. Prenez le réflexe de faire les modifications toujours depuis le même serveur, car la réplication fonctionne seulement dans un sens et va écraser la configuration du partenaire.

Peut-on faire une réplication automatique de la configuration de l'étendue DHCP ? La réponse est oui grâce à un outil supplémentaire pour synchroniser la configuration : DFACS (DHCP Failover Auto Config Sync). Malheureusement, il était en ligne sur le site TechNet Gallery qui n'existe plus et il n'a pas été remis sur Github : dès qu'il sera en ligne, je vous mettrai le lien ou je verrais pour mettre en ligne une copie.

Maintenant, au sein de la console DHCP du serveur principal, nous allons ajouter notre second serveur. De cette façon, on pourra gérer les deux serveurs depuis la même console.

Cliquez sur "DHCP" puis "Ajouter un serveur".

Sélectionnez le serveur secondaire et validez...

Voilà, les deux serveurs sont dans la console. D'ailleurs, si vous naviguez dans la configuration du second serveur, vous verrez qu'il a bien l'étendue désormais !

Avant de tester la configuration, je souhaitais attirer votre attention sur plusieurs options du menu lorsque l'on fait un clic droit sur l'étendue.

Pour modifier la configuration du basculement, vous devez la supprimer et la refaire. Dans ce cas, sélectionnez l'option "Annuler la configuration du basculement" sur le serveur principal. L'étendue sera supprimée du serveur partenaire et elle restera sur le serveur depuis lequel on effectue l'action (l'inverse est vrai aussi).

L'option "Afficher les statistiques" permet de connaître le pourcentage d'utilisation des adresses de la plage, ainsi que la répartition entre les deux serveurs.

La configuration du basculement sur une étendue peut être consultée dans les propriétés de l'étendue via l'onglet "Basculement".

V. Tester le cluster à basculement DHCP

Je vais vous décrire le processus de test, identique à celui montré dans la vidéo. Sur le poste client, on se connecte et on ouvre une console PowerShell pour libérer le bail DHCP en cours :

ipconfig /release

À partir de ce moment-là, le poste client n'a plus d'adresse IP et le bail est supprimé de la base de données des serveurs DHCP.

Maintenant, on va simuler une panne sur le serveur SRV-ADDS-01 (serveur DHCP qui gère 50% de la plage DHCP) : soit vous éteignez complètement la VM, soit vous arrêtez simplement le service DHCP.

À ce moment-là, le serveur SRV-WS-01 détecte que son partenaire est hors service et passe dans l'état "Perte du contact avec le partenaire".

Sur le poste client Windows 10, on lance une demande de bail DHCP sur le réseau grâce à la commande ci-dessous.

ipconfig /renew

Après quelques secondes, le poste récupère une adresse IP. En fait, il obtient l'adresse IP "192.168.1.209" alors qu'il avait "192.168.1.200" auparavant. Néanmoins, le serveur DHCP restant ne peut pas lui réattribuer cette adresse IP, car il n'en a pas encore la gestion : il pioche donc dans la partie de la plage DHCP qu'il gère.

On peut voir que c'est bien le serveur 192.168.1.51 qui a distribué l'adresse IP : grâce à la répartition de charge, nous avons aussi assuré la continuité du service DHCP sur notre réseau !

Au niveau de la console DHCP, le serveur principal est toujours arrêté, mais le serveur secondaire quant à lui a bien pris le relais et inscrit dans la base de données le bail du PC Windows 10.

La prochaine étape : remettre en ligne le serveur primaire. Il va se resynchroniser avec son partenaire et reprendre sa place de serveur actif. Le cluster à basculement va reprendre son fonctionnement normal en mode actif/actif.

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