DHCP Failover : Équilibrage de la base de données
Afin de disposer d’un équilibrage de la base de données des baux, les serveurs DHCP doivent contrôler combien d’adresses ils possèdent, chacun. Pour cela, on utilise le compteur lts (Lease to Send) et le positionner à zéro, pour un équilibrage parfait.
Lorsqu’un serveur a trop d’adresses, il doit redonner des baux à son homologue. Par exemple, si l’on dispose de deux serveurs DHCP configurés en failover, actifs et disposant d’une plage de dix adresses. En effectuant une demande de huit clients pour remplir la base de données des baux correctement, on trouve dans les journaux de logs du serveur primaire le listing suivant :
Ici, les deux serveurs DHCP donnent tous les deux des adresses IP aux clients et estiment que certaines sont la propriété de l’autre serveur. Par exemple, le serveur primaire estime que l’adresse 192.168.1.100 appartient par le serveur DHCP esclave : d’où le message "lease owned by peer". Cela s’explique par le fait qu’il doit être pratiqué un équilibrage dans la répartition des adresses, puisque les serveurs doivent gérer autant de baux l’un que l’autre.
Dans le cas d’une étendue de dix adresses, on en déduit que les serveurs DHCP gèrent chacun cinq adresses IP. D’après l’exemple, le serveur secondaire s’occupe des adresses allant de 192.168.1.100 à 192.168.1.104 et les cinq autres, sont pour le serveur primaire.
Mais, si l’on éteint le serveur secondaire et que l’on effectue à nouveau les demandes d’adresses pour les clients, il se peut que le serveur primaire ne dispose pas d’assez d’adresses disponibles. Il va alors utiliser une ou plusieurs adresses du serveur secondaire et créer ainsi un déséquilibre, dans la répartition des baux. Dans l’exemple ci-dessus, l’adresse 192.168.1.102 est donc réaffectée.
Lorsque l’on rallume le serveur secondaire, celui-ci bascule de nouveau en mode normal et dialogue avec son serveur primaire, sur l’état de la balance du pool : il faut traduire par l’état de l’équilibrage et de la répartition des adresses. Mais, comme le serveur secondaire dispose d’une adresse en moins, la balance n’est plus équilibré, le compteur tls est passée à -1 (au lieu de zéro souhaité) :
REMARQUE : sur le serveur primaire, le compteur tls est, quant à lui, passé a +1, puisqu’il dispose d’une adresse supplémentaire. La première chose que va chercher à faire le serveur primaire, une fois que les deux services DHCP sont de nouveau actifs, c’est de faire en sorte d’équilibrer la balance. Il va donc céder une adresse à son homologue secondaire.
Avec le temps, les pannes aidant, si au départ de la construction d’une architecture DHCP failover, tout est correctement homogène, les baux sont très vite redistribués entre les différents serveurs DHCP du failover. Du coup, il n’y a pas systématiquement de logique dans la répartition des adresses IP entre les deux serveurs.
Cependant, il est impératif de définir le même pool d’adresses, sur les deux serveurs du failover. Sinon, cela engendrera des incohérences au sein de la base de données. Si l’on ne configure pas de façon identique les pools, dans le fichier de configuration, sur les deux serveurs, on obtient alors le message suivant :
"Got POOLREQ, answering negatively ! Peer may be out of leases or database inconsistent."
La base de données est incohérente, car les baux sont en dehors de la plage d’adresses définies au niveau du serveur primaire.
