Bonjour,
Dans une ancienne vie, on avait monté une infra DHCP bien musclée d'un ensemble de paires de failovers, basée sur le vénérable serveur dhcpd d'ISC. Et nous fûmes ravis.
Dans ma nouvelle vie, j'envisage de faire de même mais vu que ISC semble avoir placé son énergie sur le dev de Kea, le remplaçant de dhcpd, je voulais savoir si certains d'entre vous l'utilisent, l'éprouvent, et s'il tient ses promesses ? Je ne suis pas particulièrement inquiets en terme de performances, mais plutôt sur le bon fonctionnement général, la _stabilité_, l'évolution au fur des mises-à-jour, le ressenti global (doc, communauté...)
Merci à vous.
Hello,
Dans une ancienne vie, on avait monté une infra DHCP bien musclée d'un ensemble de paires de failovers, basée sur le vénérable serveur dhcpd d'ISC. Et nous fûmes ravis.
Dans ma nouvelle vie, j'envisage de faire de même mais vu que ISC semble avoir placé son énergie sur le dev de Kea, le remplaçant de dhcpd, je voulais savoir si certains d'entre vous l'utilisent, l'éprouvent, et s'il tient ses promesses ?
Concernant la rapidité c'est pas mal. Car il n'y a plus l'infâme fichier dhcpd.leases...
Je ne suis pas particulièrement inquiets en terme de performances, mais plutôt sur le bon fonctionnement général, la _stabilité_, l'évolution au fur des mises-à-jour, le ressenti global (doc, communauté...)
Concernant la doc.... Là c'est la portion congrue, des updates pas toujours cool, des truc qui manquent, comme par exemple l'écriture des logs via syslog (jamais compris comment ce truc fonctionnait malgré la doc). Avant que tu te payes un mur : - 1 serveur SQL / instance kea pas de galera / cluster, tu vas droit au mur... - passe directement en 1.8.0 qui serait mieux quand il y a synchro entre masters.
Globalement "ca va" :) Mais entre kea et isc-dhcp pour des GROS setup avec plusieurs /16 a gérer c'est stable.
/Xavier
Déjà, grand merci à Xavier pour sa réponse, c'est fort cool.
Le 18/11/2020 à 17:33, Xavier Beaudouin a écrit :
Avant que tu te payes un mur :
- 1 serveur SQL / instance kea pas de galera / cluster, tu vas droit au mur...
- passe directement en 1.8.0 qui serait mieux quand il y a synchro entre masters.
Ne t'inquiète pas, comme toujours, je vais faire mes devoirs et RTFM, c'est toute l'histoire de ma (notre) vie. Mais, tant qu'à causer 2 secondes : J'aimais bien l'aspect asynchrone du failover de dhcpd : un pair meurt, l'autre prend en charge les 2 moitiés du pool, il ressuscite, ils discutent, ils se re-répartissent le pool.
Avec Kea, si chacun dispose de sa propre base, font-ils également un boulot propre de recover, une fois sortis de crash ?
Hello,
Déjà, grand merci à Xavier pour sa réponse, c'est fort cool.
Le 18/11/2020 à 17:33, Xavier Beaudouin a écrit :
Avant que tu te payes un mur :
- 1 serveur SQL / instance kea pas de galera / cluster, tu vas droit au mur...
- passe directement en 1.8.0 qui serait mieux quand il y a synchro entre
masters.
Ne t'inquiète pas, comme toujours, je vais faire mes devoirs et RTFM, c'est toute l'histoire de ma (notre) vie.
Justement y a pas de RTFM la dessus.... on a cru naïvement que c'était une bonne idée, mais vu qu'on a eu des moments en production assez.... hum... ou on se sent très seul je préfère te prévenir sur l'histoire de la base de données.
Mais, tant qu'à causer 2 secondes : J'aimais bien l'aspect asynchrone du failover de dhcpd : un pair meurt, l'autre prend en charge les 2 moitiés du pool, il ressuscite, ils discutent, ils se re-répartissent le pool.
Avec Kea, si chacun dispose de sa propre base, font-ils également un boulot propre de recover, une fois sortis de crash ?
Il ont un mécanisme de synchro... Sur les version < 1.8.0 c'était bloquant ... eg pendant cette (longue) période pas de possibilité d'avoir un lease DHCP... (ou c'est queué, on n'as pas vraiment eu de mauvaises remontées dans ce domaine...).
Sur la version >= 1.8.0 ils ont threadé la chose... a ce qu'il parait :)
/Xavier
-
Nicolas Ecarnot -
Xavier Beaudouin