Différences

Ci-dessous, les différences entre deux révisions de la page.

--- 090_applicatifs:165dhcp:50-failover [le 16/02/2025 à 14:36] – ↷ Page déplacée de 050_applicatifs:165dhcp:50-failover à 090_applicatifs:165dhcp:50-failover prof
+++ 090_applicatifs:165dhcp:50-failover [le 24/03/2025 à 10:15] (Version actuelle) – [Kea et le Dynamic DNS] prof
@@ Ligne 1: / Ligne 1: @@
-====== Redondance ======
+====== Redondance etc.======
-''isc-dhcp-server'' supporte désormais la redondance et la répartition de charge, telles que décrites dans le [[http://tools.ietf.org/html/draft-ietf-dhc-failover-12|draft-ietf-dhc-failover-12]]. Bien que cette implémentation soit encore en cours de développement, il reste possible de la mettre en œuvre.
+<note important>**Note de l'auteur:**\\ Profitant désormais de ma retraite, j'ai autre chose à faire que me prendre la tête avec des solutions si compliquées. Cette page se bornera donc à dire qu'elles existent. À vous de chercher si ça vous tente 8-)</note>
-===== Principe =====
+Sur un réseau de qualité «professionnelle» il est de bon ton de gérer la tolérance de panne. Aussi est-il intéressant de prévoir un second serveur DHCP, mais de telle manière que les deux fonctionnent en bonne harmonie.
-Normalement, deux serveurs DHCP ne peuvent cohabiter sur le même réseau, le protocole initial n'ayant pas prévu que deux serveurs puissent coopérer en se communiquant mutuellement les adresses qu'ils ont distribuées.
-Désormais ceci devient possible. Il est vivement conseillé d'utiliser non seulement le même logiciel serveur mais également la même version :
+Si le réseau devenait plus complexe et comprenait des sous réseaux, plutôt que de multiplier les serveurs DHCP, placer plutôt des relais sur les routeurs vers les sous-réseaux.
-//This version of the ISC DHCP server supports the DHCP failover protocol as documented in draft-ietf-dhc-failover-12.txt.   This is not a final protocol document, and we have  not  done interoperability testing with other vendors' implementations of this protocol, so you must not assume that this implementation conforms to the standard.
+Enfin, pour simplifier (ou compliquer, façon de voir les choses) le tout, pourquoi ne pas envisager de mettre à jour dans un ou deux serveurs DNS la ou les zones correspondant à notre ou à nos sous-réseaux ? De cette manière, même des nœuds comme des imprimantes ou des NAS ou autres serveurs pourraient avoir des adresses IP non fixées à l'avance, tout en restant accessibles à leurs clients, connaissant juste leur FQDN ?
+====== Kea server HA ======
-If you wish to use the failover protocol, make sure that both failover peers are running the same version of the ISC DHCP server.//((extrait du manuel de ''dhcpd.conf'' pour ''isc-dhcp-server 5.2.4''))
+https://kb.isc.org/docs/kea-ha-quickstart-guide
-===== Configuration =====
+HA comme «Hot Availability» propose d'utiliser plusieurs serveurs coordonnée selon divers modes. Celui qui nous intéresse ici est le mode «Hot standby», avec deux serveurs. Un seul serveur est actif pour distribuer des baux. L'autre vois sa base de données synchronisée par le serveur actif. Si ce dernier se met hors service, le second, dès qu'il sen aperçoit, prend le relai.
-==== Serveur maître ====
-<code>
-authoritative;
-# Paramétrage du failover du DHCP Master
-failover peer "neoflow" {
-	primary; 			# Déclare ce serveur comme master.
-	address 192.168.142.2; 		# Adresse du serveur master.
-	port 520; 			# Port d'écoute du serveur master.
-	peer address 192.168.142.1; 	# Adresse du serveur slave.
-	peer port 520; 			# Port d'écoute du serveur slave.
-	max-response-delay 60; 		# Temps de non réponse en secondes.
-	max-unacked-updates 10;
-	mclt 3600;
-	split 128; 			# Répartition des plages d'adresses.
-	load balance max seconds 3;
-}
-ddns-update-style none;
+D'autres possibilités sont proposées: le «load balancing» surtout pour assurer une réponse plus rapide s'il y a un grand nombre de nœuds sur le réseau ou le «passive-backup» : //The "passive-backup" mode is not really a failover mode, as it merely provides a way to back up leases to another server. Manual intervention (a configuration change) must occur to switch to this server.//
-option domain-name "example.org";
+====== Kea et le Dynamic DNS ======
-option domain-name-servers 192.168.10.1;
+https://kea.readthedocs.io/en/latest/arm/ddns.html
-log-facility local7;
-subnet 192.168.142.0 netmask 255.255.255.0 {
-	pool {
-		failover peer "neoflow";
-		range 192.168.142.16 192.168.142.63;
-		default-lease-time 600;
-		max-lease-time 1200;
-	}
-}
-</code>
-==== Secondaire ====
-<code>
-authoritative;
-# Paramétrage du failover du DHCP Master
-failover peer "neoflow" {
-	secondary; 			# Déclare ce serveur comme master.
-	address 192.168.142.1; 		# Adresse du serveur master.
-	port 520; 			# Port d'écoute du serveur master.
-	peer address 192.168.142.2; 	# Adresse du serveur slave.
-	peer port 520; 			# Port d'écoute du serveur slave.
-	max-response-delay 60; 		# Temps de non réponse en secondes.
-	max-unacked-updates 10;
-	load balance max seconds 3;
-}
-ddns-update-style none;
+Là encore, cette page se bornera à signaler cette possibilité qui n'est probablement pas d'un intérêt majeur en regard de la complexité de la solution, sauf cas particuliers.
-option domain-name "example.org";
-option domain-name-servers 192.168.10.1;
-log-facility local7;
-subnet 192.168.142.0 netmask 255.255.255.0 {
-	pool {
-		failover peer "neoflow";
-		range 192.168.142.16 192.168.142.63;
-		default-lease-time 600;
-		max-lease-time 1200;
-	}
-}
-</code>