Reprise du message précédent :
est ce grave si pendant 10 minutes tu ne peux mettre à jour tes entrées DNS ?
 
Je n'en suis pas si sûr ...
 
un DNS se doit avant tout d'être accessible pour donner l'IP d'un nom DNS. 1 DNS maître et des DNS secondaires pour la redondance conviennent tout à fait ( tu les mets dans la listes des serveurs DNS, tout comme le fait un FAI ).
 
Tu peux difficilement gérer plusieurs DNS maîtres pour la même zone car tu as un problème de cohérence des données. Si un logiciel doit gérer cette cohérence, la charge de ton réseau augmente car le logiciel doit discuter entre les différents maître pour valider les nouvelles entrées et vérifier les incohérences.
 
Cependant un DNS ne se met pas à jour toutes les 10 minutes. Normalement on met un DNS à jour :
- lorsque l'on ajoute un hôte au réseau ( ordi, imprimante, etc ... ) et que celui-ci n'était pas dans le DNS
- lorsqu'on utilise les mises à jours dynamique via DHCP du DNS et qu'un ordinateur est allumé sur le réseau ( et donc enregistré par le DNS )

mmm ... en fait y'a bien une solution "élégante" je pense ....
suffit de bien analyser la chose ...
Allez je te laisse un peu gamberger, histoire que ça tombe pas tout cuit dans le bec    
 
 
EDIT : En fait, c'est même évident comme façon d'aborder le pb .. je pense que c'est même la voie la plus "logique" maintenant que j'y pense  

Ne pas faire de DNS dynamique ?
 
Sérieusement, j'ai pas trop trop le temps, sur le sujet, de jouer à cache-cache... donc si tu as l'idée, balance

Papy punaise t'abuses

je reviens sur un post en page 1 pour la mise à jour du DNS
 
Si tu mets SERVER_DNS_1 forwarder du SERVER_DNS_2 et inversement, ca ne peut pas permettre une mise à jour automatique du SERVER_DNS_1 si il tombe un jour ?

ce topic m'interesse en tout cas, c'est vrai que c'est la merde a configurer en dynamique, j'y comprend rien

Pareil...
 
je suis en train de me demander si l'idée de papy zozzo n'est pas de gérer une zone de prod et une zone différente en backup... ce qui serait LOIN d'être con... si le DHCP peut détecter que la MAJ dynamique ne s'est pas faite... ou faire l'update sur les deux zones... bingo.

 
oh la jolie boucle infinie ...
 
forwarder = faire suivre à un autre DNS les requêtes que je ne peux traiter.
 
si tu fais DNS1 faire suivre à DNS2 et que DNS ne acha,nt pas traiter fait suivre à DNS1, alors DNS1 fera suivre à DNS2, etc ...

he ho ... faut bien que tu justifies de ton salaire hein

En gros, faut séparer la partie "Service DNS" (qui répond aux requtes de résolution de noms) de la partie "Mise à jour du DNS" suite à l'attribution d'un bail DHCP ...
Comment ?
 
  Ben tu peux avoir deux serveurs DNS type djbdns, qui sont indépendants l'un de l'autre (y'a une variante (1)  de ce scénario plus compliquée avec fake mais bon on verra plus tard )
 
  Leur (un seul et même pour les deux) ficher de config (enregistrements quoi) est généré de temps en temps (mettons toutes les 5-10 voire 15 mn  ca sert à rien plus fréquent je pense) par un script qui extrait les données d'une base Mysql (là aussi, il peut y avoir une variante (2) avec 2 bases MySQL répliquées) mise à jour par les DHCP
 
  Les serveurs DNS en eux même ne gèrent pas les mises à jours dues au DHCP ... c'est fait en amont par un script qui extrait le nécessaire et construit un fichier d'enregistrements unique pour les deux ... après, charge à chaque DNS de le "digérer" et de construire le fichier binaire dont il va se servir pour répondre aux requêtes .. là y'a rien à faire, c'est déjà "livré" avec djbdns sous forme d'un "make" ... Sachant que le make en question, vérifie la syntaxe, et arrete la création du nouveau fichier binaire pour ne pas se retrouver avec un DNS de "travers" et perdre ce qui marche déjà ...
 
donc :
 
1/ Même si ta(tes) base(s) tombe(nt) derrière, le service DNS ne s'arrete pas, même si tu ne disposes plus d'une "image fraiche" de ton réseau, c'est déjà un bon point ... tu peux même prendre le luxe de faire la maitenance de ton système pendant la jourée tranquillement, en figeant les baux DHCP (genre tu les passes à 1 voire 2 jours de validité) et donc les enregistrements DNS associés ... pendant ce temps là, tu peux te payer le luxe d'arreter la/les bases de données, un des DHCP et un des DNS
 
2/ La réplication, si tu souhaites toujours la faire, tu la fais faire à un SGBDR, chose pour lequel ils sont bien concus en général, maintenant ... au lieu de  
devoir te taper un mécanisme de réplication que tu dois écrire toi même et réinventer la roue, avec tout ce que ça implique ... "Chacun son métier et les vaches seront bien gardées"  
 
3/ En principe, une base mysql sur ta baie "Raid 500 000" suffit   ... mais bon, si tu es trop frileux encore, tu créés deux bases MySQL (cé le (2) que j'ai évoqué auparavant) ... Tu en désignes une Maitre qui réplique vers l'esclave ... Si la Maitre tombe, l'esclave prend la main (des scripts à écrire quoi, pas bien compliqués ma foi) et devient Maitre, et vice versa ...   les scripts de maj de la base avec les nouveaux baux DHCP doivent toujours travailler sur la base considérée comme maitre à un instant T (c'est juste un tour de passe-passe avec des variables bien tenues à jour lors des basculement maitre-esclave)
 
4/ Tu t'en tires entre 2 et 4 machine suivant le scénario retenu ... pas de grosse machines je dirais ... des machines avec de l'IDE, un proc tout bête, niveau RAM avec 256 (DHCP/DNS) 512 Mo (MySQL) dans le cas de 4 machines, 1 Go dans le cas de 2 machines seulement ...
 
  Par contre, y'a un peu de scripts à écrire pour créer la "glue" qui va faire marcher tout ça   (Mais bon y'a des exemples qui existent sur le net concernant djbdns et MySQL déjà ... ça devrait pas être sorcier)
 
  Si t'as 5000 (et t'as de la marge pour pousser loin à mon avis là ) renouvellement de baux DCHP/jour, tu risques pas de casser MySQL , encore moins djbdns ... seule inconnue, les srveurs DHCP en eux même   mais bon  je m'inquiète pas plus que ça pour eux     au pire  tu testes/benches  un peu  
 
  Ah vi, j'allais oublier ... Avec cette solution, t'es pas obligé d'utiliser fake ou autre ruse de sioux du genre ... pourquoi ?   ben tu déclares les 2 DNS (chacun avec leur IP propre) dans la config IP de tes clients (via DHCP donc ... et y'a même une astuce là pour répartir la charge sur les deux, bonus en passant, je m'en rend compte en écrivant cette remarque   ), et du coup, ben qd un client veut faire une résolution de nom, il demande au premier DNS inscrit dans sa config ... s'il répond pas au bout d'un certain temps (timeout qu'on peut définir au niveau des clients je crois), il fait sa demande au 2ème DNS, tout seul comme un grand
Donc pas besoin de "fake" ou autre, le boulot est fait par le client pour nous ... ...  
  M'enfin (cé le fameux (1) ) si tu y tiens, tu peux toujours utiliser fake, mettre en place une seule IP pour les DNS, mais bon, tu vas te compliquer la vie et tu devras écrire tous les scripts en plus pour gérer le basculement d'un dns à l'autre, quand le "Active" tombe en rade ...

 

 
ça c'est de la solution    

Beaucoup trop bidouille malheureusement la solution de Zozzo... on va pas s'amuser à mettre en place un truc pareil. Mon opinion à moi, la voilà

Après, ce premier jet est facilement peaufinable, mais je pense que c'est une bonne base pour constituer un service "DHCP/DNS Dynamique" costaud et pouvant monter en charge ...
Avec ce système, tu peux même te payer le luxe de "multiplier les DNS à gogo"  (enfin te laches pas trop qd même, faut les maintenir après ), sans rajouter de bases de données supplémentaires ... vu que cé le même fichier d'enregistrements qui sera distribué à tous les DNS pour "digestion" ... Ca peut même marcher sur un DNS un peu "lointain" en envoyant le fichier "à digérer" via Rsync  (incrémental)

  Y'a aucune bidouille, je m'appuie sur des éléments existants et éprouvés ...
J'ai vu pas mal de scripts déjà écrits, notamment par des FAI qui utilisent ces serveurs, de par le monde, déjà ...
 
  M'enfin j'ai l'impression que ca va se terminer par  "un DNS, un DHCP" et voilà ... la redondance ?  elle est cachée derrière l'église  
 
Faut savoir ce qu'on veut dans la vie
 

En fait, si je résume bien le problème, pose concrètement la chose, en gros, si je cerne bien le bordel :
-haute disponibilité du DNS
-haute dispo du DHCP
-Pas besoin de haute dispo des MAJ DNS faites par le DHCP si on a un moyen de les récupérer.
 
En gros, si à un moment T tel poste n'est pas dans le DNS pendant 1/2 heures, m'en fous. Par contre, que l'on perde definitivement les infos sur ce poste vu la durée du bail, la oui, ca me gène beaucoup plus !
 
Bref, je me demande si un bête DHCP qui est capable d'engranger les MAJ de DNS qui n'ont pas réussies en attendant que le DNS maitre revienne ne règlerait pas notre problème... rien lu la dessus jusqu'à présent.

 
Redondance coté esclave et co, coté DHCP oui absolument.
 
DNS maitre, je me pose la question en ce moment.

Y'a une question à te poser déjà :  Est ce qu'un poste garde toujours la même IP (vous la "forcez" ) ou ca change systmtiquement à chaque renouvellement de bail ?

Bah cé déjà fait çà  .. réfléchis un peu  

tu peux rajouter d'autres forwarder, c'est une proposition, j'essaye de faire avancer le schimililili...enfin le truc quoi

[citation=639842,40,16,56693]Bah cé déjà fait çà  .. réfléchis un peu  [/citation]
 
Je ne connais aps le comportement d'un DHCPD en cas de crash DNS à l'heure actuelle

[citation=639841,40,15,56693]Y'a une question à te poser déjà :  Est ce qu'un poste garde toujours la même IP (vous la "forcez" ) ou ca change systmtiquement à chaque renouvellement de bail ?[/citation]
Evidemment non, on ne gère pas de bail.

[citation=640020,40,19,49367]Evidemment non, on ne gère pas de bail.[/citation]
euh .. tu mélanges tout là ...
Non, vous "forcez" pas toujours la même IP cé bien ça ?  Dans ce cas, vous gérez des baux ...

[citation=640018,40,18,49367]Je ne connais aps le comportement d'un DHCPD en cas de crash DNS à l'heure actuelle [/citation]
si tu ne forces pas toujours la même adresse IP, alors tu gères un bail ...
et, ISC DHCPD, garde trace de tous les baux ... indépendamment du DNS ou quoi que ce soit ...

[quote=640028,40,20,56693][citation=640020,40,19,49367]Evidemment non, on ne gère pas de bail.[/citation]
euh .. tu mélanges tout là ...
Non, vous "forcez" pas toujours la même IP cé bien ça ?  Dans ce cas, vous gérez des baux ...[/quote]
 
Ouai, il était 23h, j'ai marqué bail au lieu de réservation... fatigue

[quote=640030,40,21,56693][citation=640018,40,18,49367]Je ne connais aps le comportement d'un DHCPD en cas de crash DNS à l'heure actuelle [/citation]
si tu ne forces pas toujours la même adresse IP, alors tu gères un bail ...
et, ISC DHCPD, garde trace de tous les baux ... indépendamment du DNS ou quoi que ce soit ...[/quote]
 
Il garde la trace, mais essaie t'il de mettre à jour le DNS pendant une période donnée ?

non

C'est très con ca
 
Donc y a pas moyen de récupérer la MAJ perdue... à part faire redémarrer le poste ?

L'idée de mettre un tampon (ici une bdd mysql) entre le DNS et le DHCP est vraiment intéressante, tu devrais la considérer sans la rejetter immédiatement à cause de la complexité apparente.
Et tout cas moi j'aime bien le principe.

[quote=640276,40,26,94434]L'idée de mettre un tampon (ici une bdd mysql) entre le DNS et le DHCP est vraiment intéressante, tu devrais la considérer sans la rejetter immédiatement à cause de la complexité apparente.
Et tout cas moi j'aime bien le principe.[/quote]
Non pour plusieurs raisons :
-on a pas le temps de gérer un développement maison... plus c'est standardisé, mieux c'est ( en gros, moins on fait despécifique, mieux c'est)
-on a pas de mysql en prod ici
-on va pas faire du dev spécifique  
 
Le seul dev spécifique que je pourrais faire est un log "formaté" des MAJ dns foirée... et un script qui traite ce fichier d'erreurs pour remettre le DNS sur pied.
 
On a besoin de cette architecture assez rapidement, et moins on bidouille, mieux c'est

[quote=640280,40,27,49367]Non pour plusieurs raisons :
-on a pas le temps de gérer un développement maison... plus c'est standardisé, mieux c'est ( en gros, moins on fait despécifique, mieux c'est)
-on a pas de mysql en prod ici
-on va pas faire du dev spécifique  
 
Le seul dev spécifique que je pourrais faire est un log "formaté" des MAJ dns foirée... et un script qui traite ce fichier d'erreurs pour remettre le DNS sur pied.
 
On a besoin de cette architecture assez rapidement, et moins on bidouille, mieux c'est [/quote]
Dans ce cas là, tu peux tout de suite oublier la piste Linux car à ma connaissance, il n'existe pas de solution "tout intégré" out of the box pour ce que tu cherches à faire, cad DHCP + maj DNS correspondante, le tout redondant ...
 
Essaies de jeter un coup d'oeil à power DNS, sait on jamais ... http://www.powerdns.com/products/powerdns/index.php
 
Petite question qui me vient à l'esprit ... Pourquoi vous voulez absolument mettre toutes les ip attriubuées par le dhcp, dans le DNS ?

[quote=640280,40,27,49367]Non pour plusieurs raisons :
-on a pas le temps de gérer un développement maison... plus c'est standardisé, mieux c'est ( en gros, moins on fait despécifique, mieux c'est)
-on a pas de mysql en prod ici
-on va pas faire du dev spécifique  
 
Le seul dev spécifique que je pourrais faire est un log "formaté" des MAJ dns foirée... et un script qui traite ce fichier d'erreurs pour remettre le DNS sur pied.
 
On a besoin de cette architecture assez rapidement, et moins on bidouille, mieux c'est [/quote]
C'est pas de la bidouille ce que je te propose ... faut arreter 30 secondes ...
C'est une réponse spécifique à ton problème, avec des devéloppements de scripts/autres à la clef ... honnetement, à vue de nez, je pense pas qu'il y ait plus de 3-4 jours de dev de script à faire ... plus une recette sur un pilote, genre sur 15 jours ...
 
Y'a pas de MySQL en prod chez vous, ok, ça je peux comprendre comme contrainte
 
EDIT :  
Petite remarque bête mais sans appel ... Si tu n'as pas de compétences, en interne, pour de la maintenance sur Linux, oublies tout de suite cette voie ... et ce conseil est valable pas seulement pour Linux, mais pour tout OS ou technologie ... avant de vouloir prendre le volant, il faut passer son permis ... ca parait peut être évident comme ça, mais je ne compte plus le nombre de fois où j'ai vu des boites s'embarquer, comme ça à la va comme je te pousse, sur des nouvelles archis/technos, sans aucun préalable et mal se terminer ...

[quote=640096,40,23,49367]Il garde la trace, mais essaie t'il de mettre à jour le DNS pendant une période donnée ?[/quote]
Non ... et c'est normal  ... c'est pas son boulot de faire ça ...
Faut bien séparer les "genres", sinon tu aboutis vite à des usines à gaz "ingérables" car tout est lié, et un pb qqpart dans la chaîne se transmet tout de suite au reste de la chaîne, effet domino quoi ... et doit y'a avoir un corollaire d'une des lois de Murphy qui dit "Plus ton usine à gaz est grosse, plus elle a de chances d'attirer un fumeur à elle"
 
Enfin bon, si tu as la trace des réservations faites par le DHCP lors de l'attribution des adresses IP, tu peux sans trop de difficultés "reconstituer le DNS", au cas où celui ci "lacherait"

Le iench ...
Petite question : t'es chanceux dans la vie en général ?
T'as le cul bordé de nouilles ou pas ?
 
Réponds moi, c'est très sérieux ... y'a une sucette à gagner

[quote=640280,0,67,49367]Non pour plusieurs raisons :
-on a pas le temps de gérer un développement maison... plus c'est standardisé, mieux c'est ( en gros, moins on fait despécifique, mieux c'est)
-on a pas de mysql en prod ici
-on va pas faire du dev spécifique  
 
Le seul dev spécifique que je pourrais faire est un log "formaté" des MAJ dns foirée... et un script qui traite ce fichier d'erreurs pour remettre le DNS sur pied.
 
On a besoin de cette architecture assez rapidement, et moins on bidouille, mieux c'est [/quote]
on a rien sans rien  

[quote=640364,40,32,5865]on a rien sans rien  [/quote]
A mon humble avis, Zzozo va nous montrer que parfois, dans de rares cas, on a ce qu'on veut sans rien...

[quote=640354,40,31,56693]Le iench ...
Petite question : t'es chanceux dans la vie en général ?
T'as le cul bordé de nouilles ou pas ?
 
Réponds moi, c'est très sérieux ... y'a une sucette à gagner [/quote]
tu te proposes ?

[quote=640568,40,34,12999]tu te proposes ? [/quote]
Nan ...
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
En fait, je pensais à toi plutot ...  

Réduire le projet linux-ha à "heartbeat, c'est de la grosse bidouille" me paraît bien présomptueux, vu son utilisation par nombre d'isp et de boîtes de tailles importantes.

 
La grosse bidouille, après réflexion, est plus coté propal SQL que heartbeat ^^
 

 
Pour la maintenance des postes, vu que l'on aura plus de correspondance nom de poste/IP. Y a très peu d'accès inter-postes en dehors de la maintenance, mais vu notre structure, c'est vital ( htline centralisée et o, répartition géographique énorme, etc).
 
On a les compétences pour faire de la maintenance linux. Seulement les contraintes sont claires : la solution doit être simple à maintenir. Pas du dev entièrement fait à la mano quoi. Clairement. Donc ta solution SQL me semble risquée, personellement, surtout que le fonctionnement de base me semble convenir, avec le bémol "je dois récupérer les updates perdues pendant que le maitre est mort". Même si objectivement parlant je la trouve élégante, elle est très risquée et otentiellement consommatrice de temps
 
Bref... on oubliera pas ce projet, il est vital. Mais on ne va pas développer n'importe quoi, on a une grosse contrainte de temps, pas de MySQL en prod, et surtout, pas envie de maintenir du script maison pour que ca en devienne à l'avenir inmaintenable.
 
Si tu veux mon avis, les scripts du genre m'ont toujours paru de la bidouille, et on ne peut pas se le permettre Qu'on fasse un script pour automatiser une tache oui, pour gérer des configs et co, nan C'est mon opinion eprso qui vaut ce qu'elle vaut hein.
 
En gros : on veut un truc robuste avec le minimum de developpement spécifique. pas de gros script, pas de BDD, et si on doit pour ca se passer de redondance coté serveur DNS maitre, on le fera... si on peut récupérer les MAJ d'une autre facon.
 
Bref !
 
PS : les baux DHCP auront une durée de vie d'une semaine à priori ( contrainte coté sécurité, pour faciliter la tracabilité ).

Dommage   j'avais trouvé un truc intéressant en prod ... tant pis ... amuses toi bien et prépares les €€€ pour des solutions "plus commerciales"
 
Bon courage