redundancy, snelheid van dns of dyn. dns

[Dogooder]

Misschien is het al een keer langsgekomen want er staat heel veel over op GoT maar ik heb een bevredigend antwoord nog niet gevonden.

Ik wil inkomend verkeer loadbalancen over verschillende isp's nu kan dit via een AS en BGP maar dat is de dure optie. Waar ik naar zoek is misschien een oplossing via DNS. Nu is daar al het een en ander over beschreven. Zoals Round robin en het Service record (SRV). Maar wat ik me nu afvraag is hoe snel dit allemaal is. Stel er valt een isp uit. dan heb ik fail over nodig. hoesnel is dit wereldwijd doorgevoert via dns. Of gewoon de loadsharing. de tweede sessie over de ander isp. is dns daar snel genoeg voor?
Ik had al begrepen dat het niet zo is van de TTL op 0 zetten want dat werkt niet en mag niet van de SIDN.
Nu zijn er ook services als dynamische dns voor als je een dynamisch ip hebt. zijn deze wel snel en is met deze techniek misschien iets te bereiken voor loadsharing en failover bij verschillende isp's?

[Koffie]

Round Robin heeft nies met redundancy te maken.
Round Robin geeft gewoon elke keer een ander IP adres terug zodat de load over meerdere servers verdeeld word, het mechanisme kijkt echter totaal niet of die server toevallig ook nog wel in de lucht is.

[Dogooder]

Koffie schreef op 30 september 2004 @ 11:00:
Round Robin heeft nies met redundancy te maken.
Round Robin geeft gewoon elke keer een ander IP adres terug zodat de load over meerdere servers verdeeld word, het mechanisme kijkt echter totaal niet of die server toevallig ook nog wel in de lucht is.

Dat klopt helemaal. Misschien heb ik het dan niet helemaal goed uitgelegd. Maar wat ik wil is isp redundancy met dus failover en als er dan toch 2 lijnen liggen dan ook maar load sharing/ balancing erover om ze beide lijnen te benutten. Is dit haalbaar met een dns oplossing en dan ook is dat snel genoeg wereldwijd?

[Kippenijzer]

Nee, dit zal het nooit zijn, omdat wat jij ook voor regeltjes opgeeft qua dns refresh, er altijd isp's zijn die in hun dns hun eigen keuzes (refresh op 4 dagen veelal) forceren, en zich niets van jou wensen aangeven.
Overigens denk ik bij een ISP aan een internetverbindingaanbieder bij je thuis. Doe dan alsjeblieft niet moeilijk, en hang een degelijke bak neer bij een colocatie facility met 99.999% uptime garantie, probleem opgelost (en laat die loadbalancen tussen 2 machines ivm redundancy bla bla bla, je kent het wel.)
Thuis is geen optie, en DNS ook niet...

[Dogooder]

Kippenijzer schreef op 30 september 2004 @ 11:23:
Nee, dit zal het nooit zijn, omdat wat jij ook voor regeltjes opgeeft qua dns refresh, er altijd isp's zijn die in hun dns hun eigen keuzes (refresh op 4 dagen veelal) forceren, en zich niets van jou wensen aangeven.
Overigens denk ik bij een ISP aan een internetverbindingaanbieder bij je thuis. Doe dan alsjeblieft niet moeilijk, en hang een degelijke bak neer bij een colocatie facility met 99.999% uptime garantie, probleem opgelost (en laat die loadbalancen tussen 2 machines ivm redundancy bla bla bla, je kent het wel.)
Thuis is geen optie, en DNS ook niet...

Het is niet voor een thuissituatie, en is een ISP van een bedrijf niet gewoon een ISP? maar goed. Het gaat erom dat sommige bedrijven gewoon altijd online willen zijn. Niet alleen voor de webserver, dan begrijp ik ook dat een colocatie beter is. Maar het gaat om gewoon de medewerkers van het bedrijf dat die failover hebben. En als er dan toch 2 lijnen liggen dat dan de capaciteit ook vergroot wordt d.m.v. load balancing/sharing. Nu is uitgaand verkeer naar verhouding niet zo heel moeilijk te verdelen. Daar is wel een mooi bakje voor geregeld. Het gaat vooral om het inkomende verkeer, daar zit de moeilijkheid. En zoals ik eerder al zei is een AS met BGP niet de optie die ik zoek en bne ik dus op zoek naar alternatieve oplossingen. Maar DNS waarschijnlijk dus toch te langzaam. Geldt dit ook voor dynamische dns services, van de dynamische ip adressen enzo? Of de roundrobin of SRV dns records?

[Koffie]

Nogmaals .. RR en SRV hebben niets, maar dan ook niets met Redundancy te maken. RR *kan* je load verdelen maar kijkt puur naar het aantal IP adressen die erop staan en maakt daar dan een keuze uit. RR c.q. DNS gaat echt niet ff kijken of die ene bak nog wel up is en/of hoe hoog zijn load is. Hij zal gewoon random een bietje IP adressen retourneren (simpel gezegd).
Dus voor de duidelijkheid: nee voor zover ik weet is dit simpelweg NIET mogelijk.
Knal er een stuq hardware voor en je bent klaar.

Ik snap het echt niet met zulke bedrijven .. oh oh oh wat is onze site/server/service belangrijk, we MOETEN 2 lijnen en we MOETEN een 24/7 uptime hebben , maar owee als er extra hardware voor gebudgeteerd moet worden.

[Dogooder]

Koffie schreef op 30 september 2004 @ 12:31:
Nogmaals .. RR en SRV hebben niets, maar dan ook niets met Redundancy te maken. RR *kan* je load verdelen maar kijkt puur naar het aantal IP adressen die erop staan en maakt daar dan een keuze uit. RR c.q. DNS gaat echt niet ff kijken of die ene bak nog wel up is en/of hoe hoog zijn load is. Hij zal gewoon random een bietje IP adressen retourneren (simpel gezegd).
Dus voor de duidelijkheid: nee voor zover ik weet is dit simpelweg NIET mogelijk.
Knal er een stuq hardware voor en je bent klaar.

Ik snap het echt niet met zulke bedrijven .. oh oh oh wat is onze site/server/service belangrijk, we MOETEN 2 lijnen en we MOETEN een 24/7 uptime hebben , maar owee als er extra hardware voor gebudgeteerd moet worden.

Ok dat RR en SRV niks met redundancy te maken hebben snap ik. Maar is er nog een andere oplossing? Een stuk hardware zit er al tussen, aan 1 kant. een nokia of gewoon een server met secure platform en checkpoint. Het probleem is het hier om 2 verschillende isp's betreft, die willen waarschijnlijk niet met elkaar samenwerken voor fail over of load sharing. En nu wijst alles er op dat het gewoon niet mogelijk is om inkomend verkeer te bundelen. behalve dan BGP, maar dat behoorde niet tot de opties.

[Kippenijzer]

Er zijn volgens mij isp's die gewoon de uptime garantie aan kunnen bieden door dubbele lijnen aan te bieden, desnoods eentje lokaal via dsl en eentje naar timboektoe over een huurlijn bijvoorbeeld. Met Consumer grade ADSL lukt het niet iig, met dure zakelijke dsl en dergelijke lijnen is veel mogelijk, maar inderdaad wel *veel* makkelijker om de redundancy door 1 ISP te laten regelen.

[soepkip]

Koffie schreef op 30 september 2004 @ 12:31:

Ik snap het echt niet met zulke bedrijven .. oh oh oh wat is onze site/server/service belangrijk, we MOETEN 2 lijnen en we MOETEN een 24/7 uptime hebben , maar owee als er extra hardware voor gebudgeteerd moet worden.

Ho ho niet te snel een conclusie trekken.
Ikzelf ben ook op zoek naar een dergelijke oplossing,
2 servers, op verschillende locaties,
een op een Beveiligde co-locatie (eigen kooi) aan de AIX
maar de andere op een niet nader te noemen locatie waar ook inbel modembanken
aan hangen (inclusief noodnet)

De bedoeling is dat er een redundancy relatie bestaat tussen deze twee servers, voor de database, en bepaalde delen van het filesysteem.

Het is uitermate belangrijk dat juist de meest recente informatie op beide servers
is te vinden.

De reden hiervoor is dat er niet alleen aan gedacht moet worden dat een van deze server soffline is, maar ook dat bij een plaatselijke calamiteit
er vanaf locatie geen "normale" verbinding via de "normale" communicatiekanalen kan worden bewerkstelligd.

deze personen kunnen dus Of via de modembanken, of via het noodnet een verbinding moetten leggen. Andere gebruikers die wel via de normale
lijnen communiceren moetten ten alle tijden ook over de meest recente data kunnen beschikken die ook inbellende mensen kunnen hebbeb geplaatst (ergo de replicatie)

Het is NIET mogenlijk de data van de modembanken/noodnet door te sturen naar
de co-lokatie.

Het grote probleem nu is dat men nooit van te voren (hoeft) te weten wie wat en waar er een probleem met de server OF een communicatiekanaal kan voordoen.

Het ideale geval zou dus zijn dat er een "dubbele" DNS record zou bestaan die
door secundaire, enz enz automatisch zou worden overgenomen
welke in de Client de funtienaliteit zou brengen dat er eerst naar het primaire IP adres zou worden gekeken, volgt daaruit een timeout, dan wordt er naar het tweede IP adres gewezen.

Ik weet dat je zult denken.. nou als het zo'n kritische applicatie is, waarom leren die gebruikers niet gewoon 2 ip-adressen uit hun hoofd, of registreer naam1 en een naam2,
en vertel ze dat als naam1 niet werkt, gebruik naam2....
zucht..dat zou een heeeeel lang verhaal worden om uit te leggen,
dit probleem bevindt zich helaas tussen het keyboard en de stoel...
dus dat is geen optie

[Dogooder]

even een klein schopje en conclusie.

Ongeacht de doeleinde waarvoor het gebruikt wordt is het dus niet mogelijk om fail over en load sharing te doen bij inkomend verkeer via 2 verschillende isp's? Omdat DNS gewoon te langzaam hiervoor is. BGP met AS is niet van toepassing omdat niet ieder bedrijf dat wil, en het is interessanter om alternatieve mogelijkheden te onderzoeken. Weet iemand nog meer onderdelen om uit te zoeken die wellicht naar een oplossing leiden. Een stuk hardware aan de isp kant lijkt me ook lastig met 2 verschillende isp's maar als iemand hier een idee over heeft hoor ik het graag. En dat zogenaamde dynamische dns is gewoon net zo snel als gewoon dns. Dus als je pech heb dan staat de dns server met een refresh rate van 4 dagen?

[ Voor 12% gewijzigd door Dogooder op 01-10-2004 14:42 ]

[Coen Rosdorff]

Zoals ik al in je vorige topic schreef:

Domme load-balance kan met RR dns.

Een cheapass vorm van fail-over kan ook met dns. Geef de RR records een korte ttl (minuutje of 10) en verwijder 1 van de 2 records als 1 van de 2 lijnen plat gaat.

Vanaf het moment van wijzigen wordt er op dns queries altijd verwezen naar de lijn die up is. Hosts die net voor de wijziging een request gedaan hebben en het ip gekregen hebben van de lijn die plat is zullen het 10 minuten zonder verbinding moeten stellen. Na deze 10 minuten zullen ze opnieuw een dns-query doen en verwezen worden naar het werkende ip-adres.

Essentieel is wel dat je je dns niet achter een van de 2 bewuste lijnen zet.

offtopic:
Oh ja, nu gaan er weer mensen zeggen dat dit niet gaat werken.
Maar neem van mij aan, het werkt echt. Werkt alweer 5 jaar naar volle tevredenheid.