Round-Robin-DNS / Fail-Over DNS?

[Sinna]

Situatieschets: (server-)netwerk bereikbaar via TN en EDP via ZyXEL USG100 met 1:1 NAT voor beide wan-interfaces.
Momenteel enkel op naam bereikbaar via TN, zou ook via EDP moeten maar als dusdanig dat als één van beide verbindingen uitvalt (al dan niet gepland) name resolving sowieso het wél bereikbare IP-adres retourneert. Als beide verbindingen op zijn, zou het TN (of beide) moeten zijn.

Ik heb echter geen idee hoe ik dit moet instellen. De nameservers zijn deze van HostBasket (de provider waar onze webstek gehost wordt), TTL = 3600 en niet te wijzigen.
Ik heb al zitten zoeken in de richting van Round-Robin-DNS, en Fail-Over DNS maar geraak er niet echt wijs uit. Ik begrijp dat met RRDNS willekeurig één van de IP-adressen teruggekeerd wordt, los van of die bereikbaar is of niet. Fail-Over-DNS lijkt mij niet mogelijk met HostBasket.
Wat ik wil bereiken moet perfect mogelijk zijn (load-balancing), maar ik wil vermijden dat ik de DNS-records manueel moet gaan aanpassen (bij een geplande downtime).
Ik word heel graag op weg gezet...

[ubremoved_539]

Het enige wat je kan doen is beide IP-adressen onder dezelfde naam zetten... wil je meer dan ga je toch een load-balancer nodig hebben.

[Sinna]

Beide IP-adressen onder dezelfde naam zetten was ik al van plan. Probleem is dat ik dat niet echt op voorhand kan testen... donderdag heb ik een geplande onderbreking op TN, maar ik kan pas morgenavond het netwerk aanpassen en hopen dat die TTL niet teveel roet in het eten gooit.
Ik zal die ZyXEL tussen de TN-modem en de firewall plaatsen zodat ik zo weinig mogelijk configuratiewerk heb op het servernetwerk zelf. Dat ik hierdoor dubbele NAT introduceer, ben ik mij terdege van bewust. Die ZyXEL speelt zelf load-balancer.
Mijn initiële vraag was vooral: hoe zorg ik ervoor dat niet het IP-adres teruggekeerd wordt dat op dat moment niet bereikbaar is.

@r2504: wat versta jij onder een load-balancer? Waar staat dat toestel dan? Ergens in een datacenter waarbij dit toestel nameserver is voor het netwerk en zo gericht IP-adressen kan retouren? Indien wel, dan had ik misschien beter toch op Fusa's aanbod ingegaan om een Raspberry Pi in DCO(2?) te zetten.

[Splitter]

noch een load balancer, noch een round robin gaat het probleem oplossen...

je zit met 2 ip's (1 edp, 1 tn)...
dus je kan wel via round-robin gaan loadbalancen, maar hoe wil je het internet (efficient) zeggen dat er 1 route onbeschikbaar is?
via DNS is geen oplossing (zelfs al zet je de TTL laag, er is genoeg caching om het onbetrouwbaar te maken).

er is geen (goedkope) thuis manier om je een deftige redundancy te bieden mbt uplink uitval.
alles achter je ip's is nooit een probleem, maar het is naar het internet toe dat een goede redundancy moeilijker wordt.

je moet 1 static ip hebben dat voor beide routes aangekondigd zou worden over het internet, maar hoe je dat gaat aanpakken...
als het mission critical is: datacenter, daar zijn ze voor gebouwd


wat je trouwens aanhaalt kan je ook doen: als je volledig vertrouwt op het netwerk van het datacenter, en daar dan bv een raspberry zet,
kan je die idd wel (bv om de 2 minuten) beide verbindingen van je laten pingen.
je kan dan de raspberry laten load-balancen tussen de 2 verbindingen, en van zodra 1tje onbereikbaar is, zorgen dat hij enkel naar de beschikbare verbinding forward.

[Sinna]

@Splitter: ik begrijp de context volledig en dat die TTL niet zaligmakend is, daar was ik ook al achter.
Mijn voorstel voor de Pi was om inderdaad op één externe plaats te kunnen bepalen welke verbindingen beschikbaar zijn.

Ik zit echter door te denken: als ik primary en secondary name server intern zou hebben (de primary op TN, de secondary op EDP daar EDP eigenlijk als fallback bedoeld is) dan lijkt het mij duidelijk dat als de primary niet reageert, de secundary geraadpleegd wordt. Als de HostBasket-nameserver(s) dan als extra backup ingesteld zijn, dag mag de lokale infrastructuur helemaal down zijn, name resolving zou wel nog lukken (zij het uiteraard voor infra die niet intern staat).

Dankzij caching zal dat nog niet feilloos zijn, maar de vereiste om een Pi in een datacenter te hebben vervalt er wel mee.

Ik leer weer bij

[Sinna]

wat je trouwens aanhaalt kan je ook doen: als je volledig vertrouwt op het netwerk van het datacenter, en daar dan bv een raspberry zet,
kan je die idd wel (bv om de 2 minuten) beide verbindingen van je laten pingen.
je kan dan de raspberry laten load-balancen tussen de 2 verbindingen, en van zodra 1tje onbereikbaar is, zorgen dat hij enkel naar de beschikbare verbinding forward.

Begrijp ik dan goed dat je eigenlijk aangeeft dat die Pi als 'voordeur' fungeert voor het interne netwerk en dus de DNS-records naar die Pi verwijzen zodat alle inkomende verkeer langs die Pi verloopt? Zorgt dat niet voor extra vertraging en vormt die Pi dan niet de bottleneck?
Mijn voorgaande reactie omtrent die name servers lijkt mij dan robuuster, met dien verstande dat DNS-verkeer topprioriteit krijgt op het netwerk.

[ubremoved_539]

Ik zit echter door te denken: als ik primary en secondary name server intern zou hebben (de primary op TN, de secondary op EDP daar EDP eigenlijk als fallback bedoeld is) dan lijkt het mij duidelijk dat als de primary niet reageert, de secundary geraadpleegd wordt.

Ik denk dat je een verkeerd beeld hebt over primary/secondary DNS wat betreft fail over naar je eigen servers.

Maar inderdaad... ik was fout wat betreft loadbalancer... je hebt twee verbindingen, geen twee servers.

Trouwens met de RPI als reverse proxy heb je een nieuw single point of failure...

[Splitter]

je kan het idd een beetje vergelijken met de voordeur, idd
dat geeft geen (merkbare) vertraging en qua bottleneck.., sja, nog nooit een Rpi in die situatie gezet,
maar het lijkt me niet dat er veel te bottlenecken valt met enkel te controleren welke verbinding up is en te forwarden,
tenzij je echt een massa hits verwacht.

en zoals R2504 (waar staan die cijfers eigenlijk voor... vraag ik me al zolang af eigenlijk ) zegt, heb je een fout beeld van nameservers.
die nameservers, ongeacht dewelke nog up is, gaat zeggen "die 2 ip's ken ik voor de gevraagde naam" en de client kiest 1 van de 2 at random.
dus dan kan je nog steeds, ongeacht dat je 50 nameservers hebt, op een dode server uitkomen.

DNS is niets meer dan "de gouden gids" die je zegt welk nummer (ip) bij welke naam (domein) hoort.

en idd R2504, je maakt met de Rpi een nieuwe single point of failure... maar het ging hier niet persé om single point of failures,
maar een oplossing voor het gestelde probleem met de 2 verbindingen.
je kan alles redundant gaan uitvoeren... maar waar stop je? (oftewel: wat is de kostprijs...)

[ubremoved_539]

en zoals R2504 (waar staan die cijfers eigenlijk voor... vraag ik me al zolang af eigenlijk )

Ze zijn alvast niet random gekozen

en idd R2504, je maakt met de Rpi een nieuwe single point of failure... maar het ging hier niet persé om single point of failures, maar een oplossing voor het gestelde probleem met de 2 verbindingen.

Hij wil nochtans steeds bereikbaar blijven (en als beide lijnen up zijn de load balancen) ... en dat doe je alvast niet door extra single points of failure te introduceren (en ik zou niet teveel verwachten van een RPI wat network load betreft). Feit is dat correcte oplossingen voor dit probleem (kijk maar eens naar het BGP protocol en multi homing) al snel veel geld kosten vrees ik.

[Splitter]

nu weet ik dus nog niet wat ze zijn geboortedag+maand?

maar idd, BGP is de eigenlijke oplossing, maar ik vermoed dat ze dat budget er niet zullen willen insteken.
dat een extra point of failure -in dit geval- niet kan helpen wil ik tegenspreken.

ok, misschien is een vps/echte server beter dan een rpi, maar het lost het gevraagde probleem op:

- je laat alles wijzen naar de rpi
- die heeft de gegevens (elke x minuten, naargelang de instelling) welke server(s) up zijn
- de rpi stuurt je verder naar 1 van die servers, en de eigenlijke server doet de rest van het werk.

op deze manier, als 1 van de 2 verbindingen eruit gaat heb je max x minuten (gedeeltelijke) onbereikbaarheid.
als beide down zijn kan je ook een pagina tonen vanuit de rpi, dus ook dat is een toegevoegde waarde.

het enige waar je (realistische) zorgen over kan maken in een datacenter, zou dus de beschikbaarheid van de rpi zelf zijn,
gezien je mag uitgaan dat een beetje deftig datacenter zowel in orde is voor stroom als netwerk (uitzonderingen gelaten, i know).

ik denk eigenlijk dat dit -financieel en op korte termijn- de beste oplossing voor TS is.
want van zonder BGP (achtige toestanden) kom je er gewoon niet.

tenzij TS zo machtig is dat hij een akkoordje kan maken met EDP én TN om 1 ip te krijgen en ze allebei dat ip te laten announcen...

[Sinna]

Heel hartelijk bedankt voor alle uitvoerige reacties.
BGP is mij niet bekend, en neen, ik heb geen aandelen TN en/of EDP

Om terug te keren op die nameservers: ik zou één en dezelfde nameserver op de twee IP-adressen bereikbaar willen maken waarbij die nameserver weet welke verbindingen beschikbaar zijn. Ergens klinkt dat onlogisch - I know - maar het lijkt mij toch een valabele oplossing.

Even schetsen:
- ns1.foo.be heeft als A-record het IP-adres van de TN-verbinding
- ns2.foo.be heeft als A-record het IP-adres van de EDP-verbinding
ns1.foo.be en ns2.foo.be verwijzen intern naar dezelfde nameserver die monitort welke verbindingen beschikbaar zijn:
- als de TN-verbinding eruit ligt, is ns1.foo.be niet bereikbaar, maar ns2.foo.be wél. ns2.foo.be weet dat dan het EDP-IP teruggekeerd moet worden.
- als de EDP-verbinding eruit ligt, is ns2.foo.be niet bereikbaar, maar ns1.foo.be wél. ns1.foo.be keert dan het TN-IP terug.
Klinkt dit logisch, de caching-problematiek efkes buiten beschouwing gelaten of mag ik er niet zomaar van uit gaan dat als een nameserver niet beschikbaar is, automatisch een andere gekozen wordt?

[ubremoved_539]

mag ik er niet zomaar van uit gaan dat als een nameserver niet beschikbaar is, automatisch een andere gekozen wordt?

Hier mag je inderdaad vanuit gaan. Hier is bijvoorbeeld een link naar dergelijke oplossing.

Klinkt dit logisch, de caching-problematiek efkes buiten beschouwing gelaten?

Blijkbaar lost men dit op door van je "www" een sub-domain te maken... meer hier.

[Sinna]

@r2504: Bedankt voor de links! Het ziet ernaar uit dat het inderdaad dit is wat ik zoek...
Als ik de configuratie up-and-running heb, laat ik mijn relaas hier wel weten.

[ubremoved_539]

Ik veronderstel dat je dan louter een DNS server voor het subdomain zelf gaat hosten (zodat je manueel kan switchen)... of heb je software die ook de links kan monitoren, je DNS aanpassen en eventueel zelfs de load balancen over beide links ?

Ik blijf me trouwens afvragen of caching hier geen rol in blijft spelen.

[Sinna]

Ik voorzie zelf een nameserver op te zetten die controleert of de verbindingen nog actief zijn. Afhankelijk van dat resultaat wordt de dns-zone bijgewerkt.
Op basis van http://www.webhostingtalk.nl/techniek-b ... z2O3fNmoXj zou dat moeten lukken.

Caching zal sowieso met mijn voeten blijven rammelen. Dat kan ik niet opgelost krijgen zonder dat BGP-gedoe vrees ik.

[ubremoved_539]

Op basis van http://www.webhostingtalk.nl/techniek-b ... z2O3fNmoXj zou dat moeten lukken.

Ik lees daar niet veel... behalve een link naar LVS "wat het zou moeten kunnen"

De thread gaat ook over pure load balancing... één link, meerdere servers... da's iets helemaal anders dan wat jij wil.

[Sinna]

Wat ik uit het bash-script afleidde, was dat de dns-zone herschreven werd op basis van de bereikbaarheid van bepaalde IP-adressen. En da's wat ik hier nodig heb.

[ubremoved_539]

Ik heb er vermoedelijk te snel over gelezen en teveel naar LVS gekeken.

Het enige wat je nodig hebt in dit geval (met het script) is een Linux systeem (en dat hoeft geen LVS te zijn) met BIND.