Bekijk Volledige Versie : Re: Round-robin DNS
frank@openminds.be
27/01/04, 13:09
a <anonymous@nospam.thanks.be> wrote:
> Round-robin DNS is een erg eenvoudige en goedkope oplossing,
> en ook een effectieve.
Ik betwijfel dat dus het "effectieve" eraan.
Stel dat webserver DNS-RR doet tussen 2 server: 10.0.0.1 en 10.0.0.2.
Je hebt dan:
www.example.tld IN A 10.0.0.1
www.example.tld IN A 10.0.0.2
Vooreerst zijn hier al problemen mee als je servers wel zouden werken.
Je hebt namelijk niks van persistent session handling. Je moet dan al
gaan zorgen dat al je sessie data op een shared medium tussen .1 en .2
staat, en dat je niet met cookies werkt (veel browsers gaan cookies van
server 1 niet willen terugsturen naar server 2).
Stel, uw .1 gaat kapot. Tenzij je dan een systeem hebt dat automatisch
uw dns-records gaat aanpassen en dat die op een zeer lage TTL staan, en
dat de dns-caching servers van de provider van uw klanten zich houden
aan deze zeer lagen TTL's, gaat nog altijd 50% van de klanten merken dat
uw site down is, omdat die nog altijd op .1 gaan terechtkomen. Meer nog:
veel kans dat hun OS/hun proxy/... gaat blijven proberen op .1 te
connecteren.
> Maar er zijn inderdaad ook andere meer "dedicated" load
> balancing oplossingen. Die zijn gesofisticeerder (en beter),
> maar ook complexer en vaak ook duur. Cfr. de Cisco Content
> Services Switch (vroeger de Localdirector).
Er bestaan andere goedkope oplossingen (er bestaan een aantal zeer
goede, meestal zelfs open source) voor Linux... Natuurlijk halen die
niet de performantie van een Cisco CSS of een Altheon, maar vaak is dat
niet nodig.
> Round-robin DNS als load balancer "voor arme mensen" is
> meestal nog niet zo'n slechte oplossing.
Zelfs hier durf ik dus aan twijfelen :)
> Ja, maar is er een verband? Is het OMDAT hij twee A records
> heeft dat hij een slechte hoster is?
Neen, maar de posting waarop ik reageerde was een beetje van "als je
iets deftigs wil, ga bij een hoster die aan RR DNS doet". Ik wou
aantonen dat RR DNS meestal zeker geen goede manier is, dat je zeker
niet mag van uitgaan "hoster X doet dit, t zal dus wel goed zijn".
Verder moet men zich afvragen wat het nut is van een RR DNS als je
configuratie zo is dat alle data op 1 NFS doos staat die tegelijk ook
web/mail/db server is, en die crasht van zodra ook maar 1 client crasht
....
Om samen te vatten, mijn mening over RR DNS:
1) t is strikt gezien een manier om aan load balancing te doen
2) t is meestal een zeer slechte
3) problemen met dynamische sites, persistente sessies
4) er zijn veel betere manieren om load balancing te doen
5) er zijn veel effectievere manieren om als hoster uw uptimes,
performantie en betrouwbaarheid te verhogen dan loadbalancing!
Just my .02 EUR of course...
Vriendelijke groeten,
Frank Louwers
--
Openminds bvba www.openminds.be
Tweebruggenstraat 16 - 9000 Gent - Belgium
frank@openminds.be
27/01/04, 13:10
a <anonymous@nospam.thanks.be> wrote:
> Round-robin DNS is een erg eenvoudige en goedkope oplossing,
> en ook een effectieve.
Ik betwijfel dat dus het "effectieve" eraan.
Stel dat webserver DNS-RR doet tussen 2 server: 10.0.0.1 en 10.0.0.2.
Je hebt dan:
www.example.tld IN A 10.0.0.1
www.example.tld IN A 10.0.0.2
Vooreerst zijn hier al problemen mee als je servers wel zouden werken.
Je hebt namelijk niks van persistent session handling. Je moet dan al
gaan zorgen dat al je sessie data op een shared medium tussen .1 en .2
staat, en dat je niet met cookies werkt (veel browsers gaan cookies van
server 1 niet willen terugsturen naar server 2).
Stel, uw .1 gaat kapot. Tenzij je dan een systeem hebt dat automatisch
uw dns-records gaat aanpassen en dat die op een zeer lage TTL staan, en
dat de dns-caching servers van de provider van uw klanten zich houden
aan deze zeer lagen TTL's, gaat nog altijd 50% van de klanten merken dat
uw site down is, omdat die nog altijd op .1 gaan terechtkomen. Meer nog:
veel kans dat hun OS/hun proxy/... gaat blijven proberen op .1 te
connecteren.
> Maar er zijn inderdaad ook andere meer "dedicated" load
> balancing oplossingen. Die zijn gesofisticeerder (en beter),
> maar ook complexer en vaak ook duur. Cfr. de Cisco Content
> Services Switch (vroeger de Localdirector).
Er bestaan andere goedkope oplossingen (er bestaan een aantal zeer
goede, meestal zelfs open source) voor Linux... Natuurlijk halen die
niet de performantie van een Cisco CSS of een Altheon, maar vaak is dat
niet nodig.
> Round-robin DNS als load balancer "voor arme mensen" is
> meestal nog niet zo'n slechte oplossing.
Zelfs hier durf ik dus aan twijfelen :)
> Ja, maar is er een verband? Is het OMDAT hij twee A records
> heeft dat hij een slechte hoster is?
Neen, maar de posting waarop ik reageerde was een beetje van "als je
iets deftigs wil, ga bij een hoster die aan RR DNS doet". Ik wou
aantonen dat RR DNS meestal zeker geen goede manier is, dat je zeker
niet mag van uitgaan "hoster X doet dit, t zal dus wel goed zijn".
Verder moet men zich afvragen wat het nut is van een RR DNS als je
configuratie zo is dat alle data op 1 NFS doos staat die tegelijk ook
web/mail/db server is, en die crasht van zodra ook maar 1 client crasht
....
Om samen te vatten, mijn mening over RR DNS:
1) t is strikt gezien een manier om aan load balancing te doen
2) t is meestal een zeer slechte
3) problemen met dynamische sites, persistente sessies
4) er zijn veel betere manieren om load balancing te doen
5) er zijn veel effectievere manieren om als hoster uw uptimes,
performantie en betrouwbaarheid te verhogen dan loadbalancing!
Just my .02 EUR of course...
Vriendelijke groeten,
Frank Louwers
--
Openminds bvba www.openminds.be
Tweebruggenstraat 16 - 9000 Gent - Belgium
Oelewapperke
27/01/04, 13:10
frank@openminds.be wrote:
> Om samen te vatten, mijn mening over RR DNS:
> 1) t is strikt gezien een manier om aan load balancing te doen
> 2) t is meestal een zeer slechte
> 3) problemen met dynamische sites, persistente sessies
> 4) er zijn veel betere manieren om load balancing te doen
> 5) er zijn veel effectievere manieren om als hoster uw uptimes,
> performantie en betrouwbaarheid te verhogen dan loadbalancing!
Damn dat wist ik niet.
Zijn er browsers die verschillende requests op verschillende ips doen dan ?
Oelewapperke
frank@openminds.be
27/01/04, 13:10
Oelewapperke <oelewapperke@wol.be> wrote:
> frank@openminds.be wrote:
>> Om samen te vatten, mijn mening over RR DNS:
>> 1) t is strikt gezien een manier om aan load balancing te doen
>> 2) t is meestal een zeer slechte
>> 3) problemen met dynamische sites, persistente sessies
>> 4) er zijn veel betere manieren om load balancing te doen
>> 5) er zijn veel effectievere manieren om als hoster uw uptimes,
>> performantie en betrouwbaarheid te verhogen dan loadbalancing!
> Damn dat wist ik niet.
> Zijn er browsers die verschillende requests op verschillende ips doen dan ?
?? Bedoel je "zijn er resolvers die bij verschillende lookups niet
steeds dezelfde A record geven"? JA
Indien ironisch bedoeld: ignore :)
Vriendelijke groeten,
Frank Louwers
--
Openminds bvba www.openminds.be
Tweebruggenstraat 16 - 9000 Gent - Belgium
Oelewapperke
27/01/04, 13:10
frank@openminds.be wrote:
> Om samen te vatten, mijn mening over RR DNS:
> 1) t is strikt gezien een manier om aan load balancing te doen
> 2) t is meestal een zeer slechte
> 3) problemen met dynamische sites, persistente sessies
> 4) er zijn veel betere manieren om load balancing te doen
> 5) er zijn veel effectievere manieren om als hoster uw uptimes,
> performantie en betrouwbaarheid te verhogen dan loadbalancing!
Damn dat wist ik niet.
Zijn er browsers die verschillende requests op verschillende ips doen dan ?
Oelewapperke
frank@openminds.be
27/01/04, 13:10
Oelewapperke <oelewapperke@wol.be> wrote:
> frank@openminds.be wrote:
>> Om samen te vatten, mijn mening over RR DNS:
>> 1) t is strikt gezien een manier om aan load balancing te doen
>> 2) t is meestal een zeer slechte
>> 3) problemen met dynamische sites, persistente sessies
>> 4) er zijn veel betere manieren om load balancing te doen
>> 5) er zijn veel effectievere manieren om als hoster uw uptimes,
>> performantie en betrouwbaarheid te verhogen dan loadbalancing!
> Damn dat wist ik niet.
> Zijn er browsers die verschillende requests op verschillende ips doen dan ?
?? Bedoel je "zijn er resolvers die bij verschillende lookups niet
steeds dezelfde A record geven"? JA
Indien ironisch bedoeld: ignore :)
Vriendelijke groeten,
Frank Louwers
--
Openminds bvba www.openminds.be
Tweebruggenstraat 16 - 9000 Gent - Belgium
frank@openminds.be wrote:
> Er bestaan andere goedkope oplossingen (er bestaan een aantal zeer
> goede, meestal zelfs open source) voor Linux... Natuurlijk halen die
> niet de performantie van een Cisco CSS of een Altheon, maar vaak is dat
> niet nodig.
Laat eens een paar namen vallen :p
frank@openminds.be
27/01/04, 22:05
HoliemaN <spam@eendje.be> wrote:
> frank@openminds.be wrote:
>> Er bestaan andere goedkope oplossingen (er bestaan een aantal zeer
>> goede, meestal zelfs open source) voor Linux... Natuurlijk halen die
>> niet de performantie van een Cisco CSS of een Altheon, maar vaak is dat
>> niet nodig.
> Laat eens een paar namen vallen :p
Wij gebruiken voor enkele klanten bv een keepalived setup ... tevreden
van.
Vriendelijke groeten,
Frank Louwers
--
Openminds bvba www.openminds.be
Tweebruggenstraat 16 - 9000 Gent - Belgium
Nog enkele kleine opmerkingen...
> Vooreerst zijn hier al problemen mee als je servers wel zouden werken.
Oei oei, zelfs als het wel werkt is het niet goed... Maar
gelukkig zal het wel niet zo erg zijn zeker (grapje :-)
> Je hebt namelijk niks van persistent session handling. Je moet dan al
> gaan zorgen dat al je sessie data op een shared medium tussen .1 en .2
> staat, en dat je niet met cookies werkt (veel browsers gaan cookies van
> server 1 niet willen terugsturen naar server 2).
Eigenlijk is dit fout-tolerantie en dat is wat anders dan
load-balancing. Maar goed, we willen beide.
De sessie variabelen ben je inderdaad kwijt als de server
crashed. Maar dat heeft niets met round-robin DNS per se te
maken, want met andere technieken heb je net hetzelfde probleem.
Zoals iemand anders al antwoordde: cookies werken met de
server naam (domain name), en niet met het IP adres, dus dat
is het probleem niet.
> Stel, uw .1 gaat kapot. Tenzij je dan een systeem hebt dat automatisch
> uw dns-records gaat aanpassen en dat die op een zeer lage TTL staan, en
> dat de dns-caching servers van de provider van uw klanten zich houden
> aan deze zeer lagen TTL's, gaat nog altijd 50% van de klanten merken dat
> uw site down is, omdat die nog altijd op .1 gaan terechtkomen. Meer nog:
> veel kans dat hun OS/hun proxy/... gaat blijven proberen op .1 te
> connecteren.
Bij round-robin DNS raadt men daarom aan de TTL op
bijvoorbeeld 60 seconden te zetten.
> Neen, maar de posting waarop ik reageerde was een beetje van "als je
> iets deftigs wil, ga bij een hoster die aan RR DNS doet". Ik wou
> aantonen dat RR DNS meestal zeker geen goede manier is, dat je zeker
> niet mag van uitgaan "hoster X doet dit, t zal dus wel goed zijn".
Daar ben ik het helemaal mee eens: round-robin DNS is geen
substituut voor een goed geconfigureerde en beheerde server,
en voor kennis van zaken.
En kritisch zijn ten aanzien van marketing praatjes is
altijd aan te bevelen, zeker als er met jargon gegoocheld wordt.
> Verder moet men zich afvragen wat het nut is van een RR DNS als je
> configuratie zo is dat alle data op 1 NFS doos staat die tegelijk ook
> web/mail/db server is, en die crasht van zodra ook maar 1 client crasht
Akkoord, maar dit heeft eigenlijk niets met round-robin DNS
te maken. Die ene doos is dan een "single point of failure"
en als die crashed dan werkt het niet meer. Of je nu
round-robin DNS gebruikt of wat anders: zelfde probleem.
En als je een "dedicated" load-balancing doos gebruikt dan
mag die op zich geen "single point of failure" zijn: dus een
cluster met "IP takeover" of zoiets. En dat maakt het dus
(relatief) ingewikkeld en (potentieel) duur.
>> Zijn er browsers die verschillende requests op verschillende ips doen dan ?
> ?? Bedoel je "zijn er resolvers die bij verschillende lookups niet
> steeds dezelfde A record geven"? JA
De browser vraagt aan DNS: wat is het IP adres van www.ibm.com?
DNS zoekt dat op en antwoordt dan: er zijn er zes en wel de
volgende: ...
Dat kan je trouwens manueel opvragen met het "nslookup"
commando:
C:\WINDOWS>nslookup www.ibm.com
Server: ns.wanadoo.be
Address: 195.74.212.12
Non-authoritative answer:
Name: www.ibm.com
Addresses: 129.42.21.99, 129.42.16.99, 129.42.17.99,
129.42.18.99
129.42.19.99, 129.42.20.99
Doe dat een tweede keer en je krijgt dezelfde adressen terug
(uiteraard), maar in een andere volgorde, eentje opgeschoven
(vandaar de naam round-robin, haasje over).
Nu kent de browser de verschillende IP adressen, en probeert
hij die in volgorde tot er één "lukt" (de ene na de andere,
niet parallel).
A.
frank@openminds.be
28/01/04, 12:45
a <anonymous@nospam.thanks.be> wrote:
> Nog enkele kleine opmerkingen...
>> Vooreerst zijn hier al problemen mee als je servers wel zouden werken.
> Oei oei, zelfs als het wel werkt is het niet goed... Maar
> gelukkig zal het wel niet zo erg zijn zeker (grapje :-)
>> Je hebt namelijk niks van persistent session handling. Je moet dan al
>> gaan zorgen dat al je sessie data op een shared medium tussen .1 en .2
>> staat, en dat je niet met cookies werkt (veel browsers gaan cookies van
>> server 1 niet willen terugsturen naar server 2).
> Eigenlijk is dit fout-tolerantie en dat is wat anders dan
> load-balancing. Maar goed, we willen beide.
> De sessie variabelen ben je inderdaad kwijt als de server
> crashed.
Wie zegt je dat als je PC op tijdstip T een request doet voor een server
met dns rr lb, en je op ip 10.0.0.1 uitkomt, je op tijdstip T+10 min
naar dezelfde url surft, en daar niet bv op 10.0.0.2 uitkomt (zelfs als
..1 dus niet gecrashed is). Ook daar: sessie stuff kwijt, tenzij dat in
een centrale DB terecht komt, of shared nfs partitie voor sessie-data,
met alle syncronisatie gevolgen vandien.
> Maar dat heeft niets met round-robin DNS per se te
> maken, want met andere technieken heb je net hetzelfde probleem.
Dus wel :) Zelfs als server .1 en .2 alle 2 draaien, kan je met RR DNS
niet weten op welke je gaat uitkomen.
>> Stel, uw .1 gaat kapot. Tenzij je dan een systeem hebt dat automatisch
>> uw dns-records gaat aanpassen en dat die op een zeer lage TTL staan, en
>> dat de dns-caching servers van de provider van uw klanten zich houden
>> aan deze zeer lagen TTL's, gaat nog altijd 50% van de klanten merken dat
>> uw site down is, omdat die nog altijd op .1 gaan terechtkomen. Meer nog:
>> veel kans dat hun OS/hun proxy/... gaat blijven proberen op .1 te
>> connecteren.
> Bij round-robin DNS raadt men daarom aan de TTL op
> bijvoorbeeld 60 seconden te zetten.
1) er zijn proxies/resolvers die zich hier niet aan houden
2) bij elke failure heb je dan nog gemiddeld (los van lokale caching) 30
seconden dat je site down is
3) old-skool dns-mensen gaan u natuurlijk vervloeken om voor zoiets uw
ttl op 60 sec te zetten
>> Verder moet men zich afvragen wat het nut is van een RR DNS als je
>> configuratie zo is dat alle data op 1 NFS doos staat die tegelijk ook
>> web/mail/db server is, en die crasht van zodra ook maar 1 client crasht
> Akkoord, maar dit heeft eigenlijk niets met round-robin DNS
> te maken. Die ene doos is dan een "single point of failure"
> en als die crashed dan werkt het niet meer. Of je nu
> round-robin DNS gebruikt of wat anders: zelfde probleem.
jaja, maar dit paste ook in het kader van "er is een bepaalde hoster die
...." :)
> En als je een "dedicated" load-balancing doos gebruikt dan
> mag die op zich geen "single point of failure" zijn: dus een
> cluster met "IP takeover" of zoiets. En dat maakt het dus
> (relatief) ingewikkeld en (potentieel) duur.
die relatief is relatief hoor :)
> Nu kent de browser de verschillende IP adressen, en probeert
> hij die in volgorde tot er één "lukt" (de ene na de andere,
> niet parallel).
er zijn dus zowel browsers (al denk ik dat dit nu wel gefixt is) maar
zeker proxies die dit dus mooi niet doen :)
Vriendelijke groeten,
Frank Louwers
--
Openminds bvba www.openminds.be
Tweebruggenstraat 16 - 9000 Gent - Belgium
HoliemaN wrote:
> frank@openminds.be wrote:
>
>> Er bestaan andere goedkope oplossingen (er bestaan een aantal zeer
>> goede, meestal zelfs open source) voor Linux... Natuurlijk halen die
>> niet de performantie van een Cisco CSS of een Altheon, maar vaak is
>> dat niet nodig.
>
> Laat eens een paar namen vallen :p
linux virtual server (uitermate performant, voor vele services)
pen (voor tcp, non-sticky services)
Zo genoeg? :-)
EJ
--
Remove the obvious part (including the dot) for my email address.
http://www.vanwesten.net for examples of ipf and pf.