DHCP med failover

[uppsalanet]

Hmm, som jag funderat och vägt olika alternativ med för och nackdelar.
Om man sätter upp två dhcp-server (primär och sekundär) så vill man bara ändra i konfigurations-filerna på den primära och sedan skicka över dom till sekundära.

Någon som har en djupare religiös fundering om detta?

//uppsalanet

[Osprey]

Konfigurationsfiler ska ju inte vara några problem att skicka över, men å andra sidan så förstår jag inte riktigt varför det skulle behövas. Däremot skulle det ju kunna vara bra om den sekundära kunde få reda på vilka adresser den primära har delat ut...

Och har den dessutom en riktig DNS-server och inte bara en Gateway till en, så är det förmodligen ännu mer som borde kunna skickas över...

Eller menar du bara att den statiska konfigurationen ska skickas över mellan två dhcp-servrar...??

Vet inte om jag hänger med riktigt.......

[uppsalanet]

Att dhcpn delar på poolen (rangen) är konfigurerat och därmed lease-filens hantering mellan primär och sekundär.

Det är precis som du nämner den statiska konfigurationen ofta en dhcpd.conf samt några *.incl filer som ska finnas på båda servrarna vid eventuellt avbrott.

Det som förvånar mig ar att det inte finns någon "standard". Här är några förslag från google:

• inotify som triggar en ändring och sedan kör scp från pri --> sek.
  rsync i crontab
  pipa en ström via ssh till sek.
  github
  ...

Många förslag finns det. Men om man vill ha hög säkerhet och loggning så hittar jag inget självklart sätt. Har inga problem med att skriva eget heller men är jag den enda som funderat på detta?

[Osprey]

Det som förvånar mig ar att det inte finns någon "standard". Här är några förslag från google:

• inotify som triggar en ändring och sedan kör scp från pri --> sek.
  rsync i crontab
  pipa en ström via ssh till sek.
  github
  ...

Det där verkar vara sällsynt dåliga förslag eftersom inget av dem går i (riktig) realtid, dvs. utför kopieringen precis när förändringen sker. För att det ska funka bra med en failover så krävs ju en spegling mellan burkarna...

Men för övrigt så hittar jag massor av till synes bra förslag om jag söker i Google på "linux dhcp server failover", vad är det för fel på de förslagen..?

[uppsalanet]

Förslagen som erbjuds via "linux dhcp server failover" sökning innefattar failover konfigurationen för lease-databasen och det är inga problem.

Första träffen säger inget om detta:

Edit the DHCP configuration /etc/dhcpd.conf on the master 192.168.1.2 and add the following, read the comments to understand the options:
..
..
Edit the DHCP configuration /etc/dhcpd.conf on the slave 192.168.1.3 and add the following, read the comments to understand the options:

Jag vill inte ändra på både master och slaves config varje gång jag ändrar i /etc/dhcpd.conf på master.

träff nummer tre på google föreslår:

here’s a small program that can accomplish the synchronization without you even remember that you must copy the files…
iwatch is a small program that monitors wherever you want (files, directories) and upon changes, it can perform several actions.

Är du med mig?

[Osprey]

Du säger att:

Jag vill inte ändra på både master och slaves config varje gång jag ändrar i /etc/dhcpd.conf på master.

Men med det följer ju ytterligare ett antal frågor som är värda att fundera över:

• När något fel har uppstått och en failover skett, ska då slaven som tog över arbetet övergå till att bli master och ska isåfall de ändringar du gör där automatiskt replikeras den motsatta vägen?
• Vilka tidskrav på replikeringen har du och ska servrarna klara av en "hot failover", dvs. ska dhcp-ansvaret automatiskt kunna övergå från den ena till den andra utan att någon manuell aktion ska behöva göras och ska det ske utan att övriga delar "märker något"?
• Det du skriver om ovan är ju den statiska konfigurationen. Hur är det egentligen med den och när aktiveras den? Förmodligen måste man starta om dhcpd för att det ska slå igenom och då innebär det att även detta måste ske automatiskt på slaven.

När jag har jobbat med failover-lösningar så har det ofta rört sig om "hot failover" mellan ännu mer komplexa system och då har speglade RAID-diskar ofta varit det enda alternativet. Tidigare när jag jobbade mycket med OpenVMS så var ju även clusterteknik mycket aktuellt i detta sammanhang och det finns ju numera även i Linux.

Jag tror att jag är med dig, eller har jag missat något?

[uppsalanet]

De tre punkter som du nämner behöver jag inte fundera nämnvärt mycket över förutom att ha korrekta konfigurationer på dhcp maskinerna.

DHCP kan bara vara redundant med 1+1 många kallar det för lastbalansering men det är även en failover i den meningen eftersom dom kommunicerar med varandra "keep alive" om någon går ner så tar den andra automatisk över och blir primär, börjar sedan dela ut ipnummer från sin halva(eller hur man konfigurerat) av poolen. Om den som gått ner inte kommer tillbaka inom en viss tid (konfigurerat) så ska den "nya" primära börja dela ut ipadresserna på hela poolen (enl. en alogoritm som jag inte kan finns att läsa på ipam).

Men för att det inte bara ska vara en lastbalanseering utan det ska fungera vid bortfall så måste dhcp.conf samt dess eventuella *.incl filer finnas i dubbel uppsättning, en på vardera server. Man brukar även ha en dhcp.failover som är unik för varje server och INTE synkas.

Härifrån önskar jag diskussionen om hur man enklast och på ett säkert sätt synkroniserar filer mellan servrarna samt varför det inte finns mer information om detta på nätet. I teorin borde det vara samma problem för en DNS server som ska skicka zonfilerna till slavar?!

[Osprey]

Vid en snabb sökning på nätet så verkar det som att det vanligaste sättet att lösa det här är OpenLDAP. Det ser också ut att finnas en hel del dokumentation och exempel av DHCP med LDAP på nätet, så kanske är det här den vägen du kan gå...?