EP n°2 : Tolérance de pannes pour serveurs DHCP sous Linux

EP n°2 : Tolérance de pannes pour
serveurs DHCP sous Linux : failover
Présentation :
•
Compétences :
-
C22 : Installer et configurer un réseau
C25 : Installer un applicatif
C31 : Assurer les fonctions de base de l'administration d'un réseau
C32 : Assurer les fonctions de l'exploitation
•
Conditions du projet :
-
1 serveur DHCP Linux opérationnel, basé sur une Mandrake 10.0 et un
paquetage DHCPD x.x.x
-
un 2ème serveur Linux inopérant (Mandrake 10.0)
-
1 clients Microsoft Windows 2000 et 1 client Linux (Mandrake 10.0) pour
les tests
•
Objectifs :
-
Installer du DHCP sur le 2ème serveur Linux
-
Configurer les 2 serveurs et les clients
-
Effectuer les tests
Partie 1 : Présentation du DHCP :
Serveur DHCP :
DHCP signifie Dynamic Host Configuration Protocol. Il s'agit d'un protocole
qui permet à un ordinateur qui se connecte sur un réseau d'obtenir dynamiquement
(c'est-à-dire sans intervention particulière) sa configuration (principalement, sa
configuration réseau). Le but principal étant la simplification de l'administration d'un
réseau.
Fonctionnement du DHCP :
Le mécanisme de base de la communication est BOOTP (avec trame UDP).
Quand une machine est démarrée, elle n'a aucune information sur sa configuration
réseau, et surtout, l'utilisateur ne doit rien faire de particulier pour trouver une
adresse IP. Pour faire ça, la technique utilisée est le broadcast : pour trouver et
dialoguer avec un serveur DHCP, la machine va simplement émettre un paquet
spécial de broadcast (broadcast sur 255.255.255.255 avec d'autres informations
comme le type de requête, les ports de connexion...) sur le réseau local. Lorsque le
serveur DHCP recevra le paquet de broadcast, il renverra un autre paquet de
broadcast contenant toutes les informations requises pour le client.
Le premier paquet émis par le client est un paquet de type DHCPDISCOVER. Le
serveur répond par un paquet DHCPOFFER, en particulier pour soumettre une
adresse IP au client. Le client établit sa configuration, puis fait un DHCPREQUEST
pour valider son adresse IP (requête en broadcast car DHCPOFFER ne contient par
son adresse IP). Le serveur répond simplement par un DHCPACK avec l'adresse IP
pour confirmation de l'attribution. Normalement, c'est suffisant pour qu'un client
obtienne une configuration réseau efficace, mais cela peut être plus ou moins long
selon que le client accepte ou non l'adresse IP...
Les baux
Pour des raisons d'optimisation des ressources réseau, les adresses IP sont
délivrées avec une date de début et une date de fin de validité. C'est ce qu'on
appelle un "bail". Un client qui voit son bail arriver à terme peut demander au serveur
une prolongation du bail par un DHCPREQUEST. De même, lorsque le serveur verra
un bail arriver à terme, il émettra un paquet DHCPNAK pour demander au client s'il
veut prolonger son bail. Si le serveur ne reçoit pas de réponse valide, il rend
disponible l'adresse IP.
Partie 2 : Présentation du protocole de failover :
Le protocole failover permet à deux serveurs DHCP de partager une même
plage d’IP. Chaque serveur possède environ la moitié des adresses disponibles à
tout moment. Si un serveur tombe, l’autre serveur va continuer d’allouer des
adresses de sa plage. Il est aussi possible durant la coupure d’un serveur de
spécifier à l’autre son état afin qu’il puisse utiliser la plage d’adresse de son
partenaire. On appel cet état le « PARTNER-DOWN ».
Lorsque le serveur redevient actif, il sera automatiquement détecter et se mettra a
jour grâce a son partenaire puis les 2 serveurs recommencerons à travailler
ensemble. Il est risqué de laisser les serveurs dhcp se relancer automatiquement (au
démarrage) car si le serveur 1 tombe, le serveur 2 passe à l’état de «partner-down »
et si ce dernier tombe aussi avant que le serveur 1 se relance (en ayant attribuer des
adresses de la plage du serveur 2), il peut y avoir un problème d’allocation d’ip (car il
n’a pas été mis à jour).
Le protocole failover définit un serveur primaire et un serveur secondaire, la
différence est minime (cela agis sur le comportement des serveurs lors de la
synchronisation).
Lorsqu’un serveur se lance, il doit déjà se synchroniser avec son partenaire
avant de pouvoir allouer des ips. La procédure d’initialisation est conçue pour mettre
à jour la base de données des serveurs (les baux). Lorsqu’un serveur tombe et se
relance, il remet à jour sa base de données grâce à son partenaire et dès que la
mise à jour est effectuée son partenaire lui envoie un signal pour lui dire que le
transfert est terminé. Ensuite, le serveur qui était tombé attend un temps déterminé
(MCLT) avant que les 2 serveurs rebasculent en mode normal. Les serveurs ne
peuvent allouer des adresses s’ils ne se sont pas correctement synchronisés.
Partie 3 : Déroulement de l’épreuve :
Serveur secondaire
Installation du serveur DHCP
Configuration du serveur
Serveur primaire
Configuration du serveur
Tests
Synchronisation des serveurs
Principe du failover
Limites du failover