Configure un failover DHCP et vérifie la continuité côté client

L’idée reçue

« Deux serveurs DHCP avec la même plage suffisent pour avoir de la haute disponibilité. »

Deux serveurs configurés séparément peuvent distribuer des baux incohérents ou se chevaucher. Le failover coordonne l’état des baux et la responsabilité des deux partenaires.

Topologie du TP

Le laboratoire utilise SRV-DHCP01 et SRV-DHCP02, joints au domaine corp.soria.test, plus un client sur le réseau 10.20.10.0/24. L’étendue existe d’abord uniquement sur DHCP01.

01Établis la baseline des deux serveurs

Sur chaque serveur :

Get-CimInstance Win32_ComputerSystem |
  Select-Object Name, Domain, PartOfDomain
Get-NetIPConfiguration
Get-WindowsFeature DHCP
Get-Service DHCPServer -ErrorAction SilentlyContinue

Sur SRV-DHCP01 :

Get-DhcpServerv4Scope -ComputerName 'SRV-DHCP01' |
  Select-Object ScopeId, Name, State, StartRange, EndRange

Get-DhcpServerv4Lease \
  -ComputerName 'SRV-DHCP01' \
  -ScopeId 10.20.10.0

Sur SRV-DHCP02, vérifie qu’aucune étendue 10.20.10.0/24 n’existe déjà :

Get-DhcpServerv4Scope -ComputerName 'SRV-DHCP02'

Microsoft exige que l’étendue source ne soit pas déjà créée indépendamment sur le partenaire avant la mise en place du failover. La relation créera la configuration correspondante sur le second serveur.

02Installe et autorise le partenaire

Si nécessaire sur SRV-DHCP02 :

Install-WindowsFeature DHCP -IncludeManagementTools -WhatIf

Après validation du serveur de laboratoire :

Install-WindowsFeature DHCP -IncludeManagementTools

Depuis une session disposant des droits nécessaires dans le domaine :

Add-DhcpServerInDC \
  -DnsName 'SRV-DHCP02.corp.soria.test' \
  -IPAddress 10.20.10.21

Get-DhcpServerInDC

Adapte les adresses aux IP réellement attribuées. Ne réutilise jamais ces valeurs par simple copier-coller dans un autre réseau.

03Crée la relation en load balance

Le mode load balance permet aux deux partenaires de servir des clients en fonctionnement normal.

$secret = Read-Host 'Secret temporaire de la relation DHCP'

Add-DhcpServerv4Failover \
  -ComputerName 'SRV-DHCP01.corp.soria.test' \
  -Name 'SORIA-DHCP-HA' \
  -PartnerServer 'SRV-DHCP02.corp.soria.test' \
  -ScopeId 10.20.10.0 \
  -LoadBalancePercent 50 \
  -SharedSecret $secret

Le secret n’est pas écrit dans le support ni dans une capture. Dans un environnement réel, il doit être géré conformément à la politique de secrets.

Vérifie la relation des deux côtés :

Get-DhcpServerv4Failover \
  -ComputerName 'SRV-DHCP01.corp.soria.test' |
  Format-List Name,PartnerServer,Mode,LoadBalancePercent,
              State,ScopeId,MaxClientLeadTime

Get-DhcpServerv4Failover \
  -ComputerName 'SRV-DHCP02.corp.soria.test' |
  Format-List Name,PartnerServer,Mode,LoadBalancePercent,
              State,ScopeId,MaxClientLeadTime

État attendu avant panne : Normal.

04Vérifie que l’étendue existe sur le partenaire

Get-DhcpServerv4Scope \
  -ComputerName 'SRV-DHCP02.corp.soria.test' |
  Select-Object ScopeId, Name, State, StartRange, EndRange

Get-DhcpServerv4OptionValue \
  -ComputerName 'SRV-DHCP02.corp.soria.test' \
  -ScopeId 10.20.10.0

Puis depuis le client :

ipconfig /release
ipconfig /renew
ipconfig /all

Consigne :

IPv4 obtenue
masque
passerelle
DNS
serveur DHCP indiqué par le client
heure du renouvellement

05Observe les baux avant la panne

Sur les deux serveurs :

Get-DhcpServerv4Lease \
  -ComputerName 'SRV-DHCP01.corp.soria.test' \
  -ScopeId 10.20.10.0 |
  Select-Object IPAddress, HostName, ClientId, AddressState

Get-DhcpServerv4Lease \
  -ComputerName 'SRV-DHCP02.corp.soria.test' \
  -ScopeId 10.20.10.0 |
  Select-Object IPAddress, HostName, ClientId, AddressState

Le but n’est pas d’obtenir des sorties strictement identiques à la milliseconde, mais de vérifier que les partenaires partagent l’état nécessaire au service failover.

06Provoque une panne contrôlée

Sur SRV-DHCP02 seulement, dans le laboratoire :

Stop-Service DHCPServer
Get-Service DHCPServer

Depuis SRV-DHCP01, observe la relation :

Get-DhcpServerv4Failover \
  -ComputerName 'SRV-DHCP01.corp.soria.test' \
  -Name 'SORIA-DHCP-HA' |
  Format-List Name,PartnerServer,State,Mode,ScopeId

L’état peut devenir CommunicationInterrupted après perte du partenaire.

Ne déclare pas immédiatement PartnerDown dans une vraie infrastructure : cette transition signifie que l’administrateur considère réellement le partenaire indisponible. Ici, elle fait partie d’un scénario de laboratoire borné.

Dans le TP, après avoir prouvé la panne du partenaire :

Set-DhcpServerv4Failover \
  -ComputerName 'SRV-DHCP01.corp.soria.test' \
  -Name 'SORIA-DHCP-HA' \
  -PartnerDown \
  -Confirm:$true

07Valide le service côté client

Le test important est côté consommateur du service :

ipconfig /release
ipconfig /renew
ipconfig /all

Resolve-DnsName corp.soria.test
Test-NetConnection 10.20.10.1

Le client doit recevoir une configuration valide malgré l’arrêt du service DHCP sur le partenaire.

Consigne précisément :

heure de début de panne
heure du renouvellement réussi
serveur DHCP observé
IPv4 / gateway / DNS obtenus
résolution DNS
connectivité vers la passerelle
nombre d'échecs éventuels

08Rétablis le partenaire et resynchronise

Sur SRV-DHCP02 :

Start-Service DHCPServer
Get-Service DHCPServer

Depuis DHCP01 :

Invoke-DhcpServerv4FailoverReplication \
  -ComputerName 'SRV-DHCP01.corp.soria.test' \
  -Name 'SORIA-DHCP-HA' \
  -Force

Get-DhcpServerv4Failover \
  -ComputerName 'SRV-DHCP01.corp.soria.test' \
  -Name 'SORIA-DHCP-HA' |
  Format-List Name,PartnerServer,State,Mode,ScopeId

Contrôle également le partenaire :

Get-DhcpServerv4Failover \
  -ComputerName 'SRV-DHCP02.corp.soria.test' \
  -Name 'SORIA-DHCP-HA' |
  Format-List Name,PartnerServer,State,Mode,ScopeId

Attends le retour à un état cohérent avant de considérer l’incident fermé. Une reprise de processus ne suffit pas : il faut contrôler relation, étendue, baux et client.

09Distingue les limites

Ce que le failover réduit

Ce qu’il ne supprime pas

perte d’un service DHCP partenaire

panne du réseau commun

indisponibilité d’un nœud

mauvaise option répliquée sur les deux

dépendance à un serveur unique

erreur de conception de l’étendue

interruption lors d’une maintenance bornée

perte de DNS, gateway ou VLAN

DHCP disponible ne signifie pas réseau disponible. Le client dépend encore de la passerelle, du DNS, du routage et des règles de sécurité distribuées dans le fil rouge.

Panne BTS

Prouve que le client survit à la perte d’un serveur DHCP

établis la baseline des deux serveurs et du client ;
montre la relation en état normal ;
arrête le service DHCP du partenaire ;
observe l’état de failover ;
déclare PartnerDown uniquement dans le laboratoire après preuve de panne ;
renouvelle la configuration du client ;
valide gateway et DNS ;
remets le partenaire en service ;
réplique et prouve le retour à un état sain ;
documente impact, durée, preuve et limite.

✓À retenir

Le failover DHCP coordonne deux serveurs autour des mêmes étendues et états de baux. La compétence ne se prouve pas uniquement dans la console serveur : elle se prouve en provoquant une perte contrôlée, en renouvelant un client et en démontrant le retour à un état sain.