Haute disponibilité du service DHCP : Deuxième solution : configuration du service DHCP en Failover/Load-balancing

Pour avoir une vrai haute disponibilité, il faut bien disposer d’un seul service DHCP mais réparti sur 2 serveurs.

Cela présente deux avantages :

la continuité du service en cas de panne du serveur primaire (FAILOVER) ;
la répartition des charges au niveau des baux attribués (LOAD-BALANCING).

Vous allez configurer DHCP comme serveur primaire.

Contenu du fichier de configuration du service DHCP de DHCP /etc/dhcp/dhcpd.conf :

# Declaration du FAILOVER DHCP pour le serveur primaire#
failover peer "GSB" {
        primary;                    # Déclare ce serveur comme primaire
        address 192.168.150.1;      # Adresse du serveur primaire
        port 647;                   # Port d'écoute du serveur primaire.
        peer address 192.168.150.2; # Adresse du serveur secondaire.
        peer port 847;              # Port d'écoute du serveur secondaire.
        max-response-delay 60;      # Temps de non réponse en secondes.
        max-unacked-updates 10;
        mclt 3;                  # Temps de renouvellement du service
                                    # en cas d'incertitude.
        split 128;                  # Répartition des plages d'adresses.
        load balance max seconds 3;
}
# Les lignes suivantes servent à l'initialisation des deux serveurs DHCP.
#failover peer "GSB" state {
#    my state partner-down;
#}

ddns-update-style none;
option domain-name "gsb.local";
option domain-name-servers 172.16.0.10;
default-lease-time 600;
max-lease-time 7200;
authoritative;
log-facility local7;
# reseau VLAN Visiteurs
 subnet 192.168.150.0 netmask 255.255.255.0 {
 pool {
      failover peer "GSB";
   range 192.168.150.50 192.168.150.100;
      }
   option routers 192.168.150.1;
   option broadcast-address 192.168.150.255;
 }

Quelques précisions sur ce qui change :

En début de fichier est déclaré le Failover ; en précisant :
- le nom du Failover : GSB ;
- que ce serveur est le serveur primaire : primary ;
l’adresse IP de ce serveur primaire (192.168.150.1) et celle du serveur secondaire (192.168.150.2) ;
la valeur de split détermine ici le découpage en 2 de la plage d’adresse IP.

Dans la définition du sous-réseau, la plage d’adresse est définie comme un pool d’adresse du Failover GSB.

Vous allez configurer DHCP2 comme serveur secondaire.

Contenu du fichier de configuration du service DHCP de DHCP2 /etc/dhcp/dhcpd.conf :

# Declaration du FAILOVER DHCP pour le serveur secondaire#
failover peer "GSB" {
        secondary;             # Déclare ce serveur comme secondaire
        address 192.168.150.2;
        port 847;
        peer address 192.168.150.1;
        peer port 647;
        max-response-delay 60;
        max-unacked-updates 10;
        load balance max seconds 3;
}
# Les lignes suivantes servent à l'initialisation des deux serveurs DHCP.
#failover peer "GSB" state {
#    my state partner-down;
#}
ddns-update-style none;
option domain-name "gsb.local";
option domain-name-servers 172.16.0.10;
default-lease-time 600;
max-lease-time 7200;
#authoritative;
log-facility local7;
# reseau VLAN Visiteurs
 subnet 192.168.150.0 netmask 255.255.255.0 {
 pool {
      failover peer "GSB";
   range 192.168.150.50 192.168.150.100;
      }
   option routers 192.168.150.1;
   option broadcast-address 192.168.150.255;
 }

Quelques précisions sur ce qui change :

La définition du failover change :
- ce serveur est le serveur secondaire : secondary ;
- l’inversion des adresses IP et des ports entre serveur primaire et secondaire.
La directive authoritative est commentée.

Pour initialiser les serveurs DHCP en Failover, vous devez respecter une procédure précise.

Pourquoi ?

Les serveurs DHCP dialoguent entre eux pour échanger des signaux de vie et leur base de données.
Ils allouent indifféremment les adresses IP sur la plage d’adresses définie.
Lorsque l’un d’eux ne répond plus, l’autre renouvelle les baux de l’autre pendant le temps mtcl.
Une fois cette durée révolue, le serveur restant réalloue lui-même les baux.

Lorsque le serveur tombé en panne réapparaît, il synchronise sa base de données avec le serveur restant. De plus, il ne répond pas aux demandes d’adresses IP pendant le temps mtcl.

Les baux alloués ainsi que la trace des évènements se situent dans le fichier dhcpd.leases.

Lors du premier démarrage, le fichier dhcpd.leases doit être créé manuellement et doit être vide.

Lorsque les serveurs démarrent :

ils voient que leur base de données est vide.
Ils croient alors tous qu’ils sont tombés précédemment en panne et attendent.
Pour palier ce problème, il faut décommenter sur le primaire les lignes « failover … state ». Elles ont pour effet de dire au serveur que le serveur secondaire est en panne. Ainsi, le serveur primaire remplit sa base de données et l’on peut démarrer le secondaire si ce n’est pas déjà fait.
On arrête alors le primaire pour commenter les lignes « failover … state » et on le redémarre.

Les deux serveurs sont maintenant démarrés et échangent leurs informations.

La procédure à suivre est donc :

1) Lancez les serveurs DHCP sans activer le service DHCP

# update-rc.d isc-dhcp-server remove
# reboot

Pour vérifier que le service n'est plus lancé au démarrage de votre serveur, visualisez les ports actifs. Le port 67 (port utilisé par le service DHCP) ne doit plus apparaître :

# ss -nlut

Pour permettre à nouveau le lancement du service DHCP au démarrage du serveur utilisez la commande suivante :

# update-rc.d isc-dhcp-server defaults
# reboot

2) Décommentez ces trois lignes sur les deux serveurs DHCP et DHCP2.

# Les lignes suivantes servent à l'initialisation des deux serveurs DHCP.
failover peer "GSB" state {
    my state partner-down;
}

3) Lancer le service DHCP sur le serveur primaire DHCP seulement.

DHCP:~# systemctl start isc-dhcp-server

Le fichier /var/lib/dhcp/dhcpd.leases contient les informations suivantes :

# The format of this file is documented in the dhcpd.leases(5) manual page.
# This lease file was written by isc-dhcp-V3.1.1
failover peer "GSB" state {
  my state partner-down at 6 2012/10/27 15:24:56;
  partner state unknown-state at 6 2012/10/27 15:24:56;
}

4) Vos STAs Portable1 et Portable 2 ont dû obtenir une adresse IP. Si ce n’est pas le cas lancez la commande ifdown eth0 suivi de ifup eth0 ou ipconfig /renew. Cela doit permettre de remplir la base du serveur primaire. Visualisez cela dans le fichier dhcpd.leases.

DHCP:~# cat /var/lib/dhcp/dhcpd.leases
Contenu du fichier dhcpd.leases

# The format of this file is documented in the dhcpd.leases(5) manual page.
# This lease file was written by isc-dhcp-V3.1.1
failover peer "GSB" state {
  my state partner-down at 6 2012/10/27 15:24:56;
  partner state unknown-state at 6 2012/10/27 15:24:56;
}
lease 192.168.150.50 {
  starts 6 2012/10/27 15:25:47;
  ends 6 2012/10/27 15:35:47;
  tstp 6 2012/10/27 15:40:47;
  cltt 6 2012/10/27 15:25:47;
  binding state active;
  next binding state expired;
  hardware ethernet 96:21:9d:a1:69:db;
}
lease 192.168.150.51 {
  starts 6 2012/10/27 15:28:16;
  ends 6 2012/10/27 15:38:16;
  tstp 6 2012/10/27 15:43:16;
  cltt 6 2012/10/27 15:28:16;
  binding state active;
  next binding state expired;
  hardware ethernet 22:4e:a6:ec:58:0e;
}

5) Démarrez le serveur secondaire DHCP2.

DHCP2:~# systemctl start isc-dhcp-server

6) Arrêtez le serveur primaire DHCP.

DHCP:~# systemctl stop isc-dhcp-server

7) Commentez les lignes sur le serveur primaire DHCP.

# Les lignes suivantes servent à l'initialisation des deux serveurs DHCP.
#failover peer "GSB" state {
#    my state partner-down;
#}

8) Démarrez le serveur primaire DHCP.

DHCP:~# systemctl start isc-dhcp-server

9) Arrêtez le serveur secondaire DHCP2.

DHCP2:~# systemctl stop isc-dhcp-server

10) Commentez les lignes sur le serveur secondaire DHCP2.

# Les lignes suivantes servent à l’initialisation des deux serveurs DHCP.
#failover peer "GSB" state {
#    my state partner-down;
#}

11) Démarrez le serveur secondaire DHCP2.

DHCP2:~# systemctl start isc-dhcp-server

Faites des essais de renouvellement de configuration IP pour Portable1 Portable2 et vous constaterez les échanges d’informations entre les serveurs DHCP :

Dans le fichier /var/lib/dhcp/dhcpd.leases de DHCP vous voyez les baux pour les adresses allant de 192.168.150.50 à 192.168.150.75, deux de ces adresses étant attribuées aux portables (192.168.150.50 et 192.168.150.51) :

Lease 192.168.150.50 {
  starts 6 2012/10/27 15:48:55;
  ends 6 2012/10/27 15:58:55;
  tstp 6 2012/10/27 16:03:55;
  tsfp 6 2012/10/27 16:03:55;
  atsfp 6 2012/10/27 16:03:55;
  cltt 6 2012/10/27 15:48:55;
  binding state active;
  next binding state expired;
  hardware ethernet 96:21:9d:a1:69:db;
}
lease 192.168.150.51 {
  starts 6 2012/10/27 15:52:28;
  ends 6 2012/10/27 16:02:28;
  tstp 6 2012/10/27 16:07:28;
  tsfp 6 2012/10/27 16:07:28;
  atsfp 6 2012/10/27 16:07:28;
  cltt 6 2012/10/27 15:52:28;
  binding state active;
  next binding state expired;
  hardware ethernet 22:4e:a6:ec:58:0e;
}
lease 192.168.150.52 {
  starts 6 2012/10/27 15:37:03;
  tstp 6 2012/10/27 15:37:03;
  tsfp 6 2012/10/27 15:37:03;
  atsfp 6 2012/10/27 15:37:03;
  binding state backup;
}
   
}
lease 192.168.150.75 {
  starts 6 2012/10/27 15:37:03;
  tstp 6 2012/10/27 15:37:03;
  tsfp 6 2012/10/27 15:37:03;
  atsfp 6 2012/10/27 15:37:03;
  binding state backup;
}

Dans le fichier /var/lib/dhcp/dhcpd.leases de DHCP2 vous voyez que le serveur à repris les informations du serveur DHCP primaire, c’est à dire .les baux pour les adresses allant de 192.168.150.50 à 192.168.150.75, plus les baux accordés aux deux portables (192.168.150.50 et 192.168.150.51) par l’autre serveur DHCP DHCP :

   
lease 192.168.150.51 {
  starts 6 2012/10/27 15:37:32;
  ends 6 2012/10/27 15:47:32;
  tstp 6 2012/10/27 15:52:32;
  tsfp 6 2012/10/27 15:52:32;
  atsfp 6 2012/10/27 15:52:32;
  cltt 6 2012/10/27 15:37:32;
  binding state active;
  next binding state expired;
  hardware ethernet 22:4e:a6:ec:58:0e;
}
lease 192.168.150.50 {
  starts 6 2012/10/27 15:38:25;
  ends 6 2012/10/27 15:48:25;
  tstp 6 2012/10/27 15:53:25;
  tsfp 6 2012/10/27 15:53:25;
  atsfp 6 2012/10/27 15:53:25;
  cltt 6 2012/10/27 15:38:25;
  binding state active;
  next binding state expired;
  hardware ethernet 96:21:9d:a1:69:db;
}
lease 192.168.150.52 {
  starts 6 2012/10/27 15:37:03;
  tsfp 6 2012/10/27 15:37:03;
  atsfp 6 2012/10/27 15:37:03;
  binding state backup;
}
   
}
lease 192.168.150.75 {
  starts 6 2012/10/27 15:37:03;
  tsfp 6 2012/10/27 15:37:03;
  atsfp 6 2012/10/27 15:37:03;
  binding state backup;
}

Que ce soit en arrêtant DHCP ou DHCP2, les portables auront la même adresse renouvelée.

De même, en ajoutant de nouveaux hôtes sur ce VLAN Visiteurs et en arrêtant ou tel serveur DHCP, il n’y aura pas d’adresses attribuées en double sur le réseau.

Vous pouvez maintenant réaliser l’infrastructure présentée en début d’activité avec les deux serveurs DHCP situés dans le VLAN Serveurs.

Pour que l’agent relais transmettent bien les requêtes des clients à l’un ou l’autre des serveurs DHCP disponible, il suffira d’indiquer les deux adresses IP des serveurs DHCP dans la configuration du fichier /etc/default/isc-dhcp-relay.

# Defaults for isc-dhcp-relay initscript
# sourced by /etc/init.d/isc-dhcp-relay
# installed at /etc/default/isc-dhcp-relay by the maintainer scripts
#
# This is a POSIX shell fragment
#
# What servers should the DHCP relay forward requests to?
SERVERS="172.16.0.10 172.16.0.11"
# On what interfaces should the DHCP relay (dhrelay) serve DHCP requests?
INTERFACES=""
# Additional options that are passed to the DHCP relay daemon?
OPTIONS=""

Retour à l'activité

Activité : mettre en oeuvre une haute disponibilité de service DHCP